SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[Urwumpe]

Added Smart Speed Brake logic to Autoland Guidance, so touchdowns should be a bit more precise, even with wind, although the Density Altitude effects aren't being calculated as I don't have enough info on how to calculate it... :shrug:

What do you mean with density altitude? You mean the barometric altitude?

 

[GLS]

What do you mean with density altitude? You mean the barometric altitude?

With temperature in the mix. It probably uses the ALTM value in SPEC 50, but I can't do more without more info.

 

[Urwumpe]

With temperature in the mix. It probably uses the ALTM value in SPEC 50, but I can't do more without more info.

Well, the standard formula for density altitude is on wikipedia, so I assume, this isn't the problem. What is lacking?

 

[GLS]

Well, the standard formula for density altitude is on wikipedia, so I assume, this isn't the problem. What is lacking?

The downrange delta for density altitude is added to account for the fairly significant effect it has on T/D energy.
The density altitude is calculated as the squared ratio of filtered EAS divided by the filtered TAS. The Air Data
Subsystem Operating Program (ADSOP) calculates the EAS and TAS used in guidance. There are slight errors in
this calculation onboard, since the TAS is a function of temperature, and temperature is a table lookup from
onboard I-loads instead of the air-data-probe-measured temperature. The accuracy of the density altitude
prediction depends on the slope of the actual atmosphere being similar to the 1962 standard atmosphere slope.
This slope is used to predict the density at the surface. The downrange delta term is recalculated at 500 ft to
account for any temperature and density slope changes since 3000 ft.
There is an interrelationship between the wind calculation and density altitude calculation. This relationship is
advantageous; if one under compensates, the other over compensates. Approximately half the downrange delta
prediction error due to density altitude is counterbalanced by an error in wind speed calculation. These errors are
due to using one ADSOP temperature profile for all flights.

 

[Urwumpe]

So, the formula is approximately (EAS/TAS)²?

Still don't see what goes wrong there...

 

[GLS]

So, the formula is approximately (EAS/TAS)²?

Still don't see what goes wrong there...

It always gives values close to 1, instead of thousands of ft... :uhh:

 

[Urwumpe]

It always gives values close to 1, instead of thousands of ft... :uhh:

It should be a correction factor - factor suggests its dimensionless and and correction that it should be close to 1....

 

[indy91]

Just updated my SSU install again and was looking at some of your guidance related tickets for fun. About ticket #192, when the target HA/HP are first calculated (Item 22) it simply adds the DV vector to the velocity:

postBurnState.vel = ConvertBetweenLHAndRHFrames(equVel + equDeltaV);

And then every 60 seconds it updates those HA/HP values (first few lines of OMSBurnSoftware::OnPreStep), but for that it then assumes constant acceleration, which was calculated when the Item 22 was done and was given to the omsBurnPropagator. So for long duration burns there can a significant update in the target HA/HP values between the initial calculation and the first update (anywhere between 0 and 60 seconds after the Item 22). With non-spherical gravity and everything disabled I am then only seeing changes below 1 meter of the HA/HP in any update after that.

So maybe the problem is just the difference between the initial calculation (assuming impulsive burn) and the later ones (assuming constant acceleration burn).

 

[GLS]

Just updated my SSU install again and was looking at some of your guidance related tickets for fun. About ticket #192, when the target HA/HP are first calculated (Item 22) it simply adds the DV vector to the velocity:

postBurnState.vel = ConvertBetweenLHAndRHFrames(equVel + equDeltaV);

And then every 60 seconds it updates those HA/HP values (first few lines of OMSBurnSoftware::OnPreStep), but for that it then assumes constant acceleration, which was calculated when the Item 22 was done and was given to the omsBurnPropagator. So for long duration burns there can a significant update in the target HA/HP values between the initial calculation and the first update (anywhere between 0 and 60 seconds after the Item 22). With non-spherical gravity and everything disabled I am then only seeing changes below 1 meter of the HA/HP in any update after that.

So maybe the problem is just the difference between the initial calculation (assuming impulsive burn) and the later ones (assuming constant acceleration burn).

I haven't looked at this yet, but from usage and from the OMS TVC work I did awhile back, I know there are some issues in the orbit department...
One thing I'd like to have in SSU (that the real Shuttle had.... and I think the CSM as well) is the capability to point and track a place on the Earth's surface (e.g., your home town). I looked at the UNIV PTG code, but it assumes some things that make a rewrite needed... meanwhile there are more important things to do like "get to the runway", so that went to the wish list. :shrug:

 

[indy91]

I haven't looked at this yet, but from usage and from the OMS TVC work I did awhile back, I know there are some issues in the orbit department...
One thing I'd like to have in SSU (that the real Shuttle had.... and I think the CSM as well) is the capability to point and track a place on the Earth's surface (e.g., your home town). I looked at the UNIV PTG code, but it assumes some things that make a rewrite needed... meanwhile there are more important things to do like "get to the runway", so that went to the wish list. :shrug:

I remember ticket #95 being a problem from trying OMS burns some years ago, but that ticket is closed now, so that might be fixed for good.

And yeah, that feature got added to the CMC software with Apollo 15, even is called universal pointing as well (EDIT: well close, it's called universal tracking). Works quite similar to the implementation for the Shuttle computer, minus the user interface, haha. It was used quite a bit for pointing the SIM Bay equipment at the Moon. Skylab and ASTP CMCs had the same feature. I know quite well how it works in the AGC, I'll take a look at the SSU code.

 

[GLS]

I remember ticket #95 being a problem from trying OMS burns some years ago, but that ticket is closed now, so that might be fixed for good.

Yeah, that was the OMS TVC work I did. The engines were in the wrong place, plus the pointing the thrust vector thru the c.g part wasn't correct.

And yeah, that feature got added to the CMC software with Apollo 15, even is called universal pointing as well (EDIT: well close, it's called universal tracking). Works quite similar to the implementation for the Shuttle computer, minus the user interface, haha. It was used quite a bit for pointing the SIM Bay equipment at the Moon. Skylab and ASTP CMCs had the same feature. I know quite well how it works in the AGC, I'll take a look at the SSU code.

It has been some time since I looked at that, but I remember the way the "maneuver/pointing/tracking" state is saved/loaded to/from the scenario was one of the issues. M50 and LVLH was another.

 

[Wolf]

Question for the "cargo department":
Would it be possible to have updated STS payloads for SSU (at least for the ISS missions)?

I talked about it with Donamy a while ago and I seem to remember he mentioned a problem related to Orbiter2016 rotation issues (or something like that). Does this issue prevent the possibility to have payloads at all? I thought the problem was only showing when the payload is grappled and moved with the RMS..

 

[Donamy]

Having payloads in the bay work fine. The problem is with the RMS's rotation attachment wondering. :thumbsdown:

 

[Urwumpe]

Having payloads in the bay work fine. The problem is with the RMS's rotation attachment wondering. :thumbsdown:

Did somebody already check if the problem also takes place with other attachments?

 

[GLS]

Did somebody already check if the problem also takes place with other attachments?

Not that I've seen. It appears that only the RMS is complex enough to show this issue. All the other attachments are static or only move in one direction.
This has been reported to the boss: https://www.orbiter-forum.com/project.php?issueid=1324

 

[Urwumpe]

Not that I've seen. It appears that only the RMS is complex enough to show this issue. All the other attachments are static or only move in one direction.
This has been reported to the boss: https://www.orbiter-forum.com/project.php?issueid=1324

And we still use VERTEXLIST there, right? Maybe its a numeric issue.

 

[GLS]

And we still use VERTEXLIST there, right? Maybe its a numeric issue.

I remember that we don't change the direction vector coming from Orbiter, which should be set based on the animation data we define, and we just set the attachment direction with it. So either that vector isn't properly calculated, or the set attachment parameters function only works when it wants. I did all I could on this side, plus this happens on other addons, so for now I say it is an Orbiter internal issue

 

[Urwumpe]

I remember that we don't change the direction vector coming from Orbiter, which should be set based on the animation data we define, and we just set the attachment direction with it. So either that vector isn't properly calculated, or the set attachment parameters function only works when it wants. I did all I could on this side, plus this happens on other addons, so for now I say it is an Orbiter internal issue

I know. I also did some tests there, and agree that it takes place inside Orbiter. But maybe it is a problem that comes from numerics and could be circumvented by using our own forward kinematics.

 

[Donamy]

SiameseCat fixed it with the SSRMS. If you un-grapple and re-grapple it snaps to where it should be. So I think, (I could be wrong) SiameseCat has it attach and reattach as it rotates.

 

[Wolf]

Having payloads in the bay work fine. The problem is with the RMS's rotation attachment wondering. :thumbsdown:

Would you be willing to release some? lease: