Space Shuttle Ultra 1.25 Revision B development

[SiameseCat]

I suspect range would be good enough, but taking speed/alt into account would help. IIRC, the real shuttle eesentially flies a velocity/drag profile which is adjusted during entry to compensate for errors.

 

[Urwumpe]

I suspect range would be good enough, but taking speed/alt into account would help. IIRC, the real shuttle eesentially flies a velocity/drag profile which is adjusted during entry to compensate for errors.

First it is a pure drag profile, later it becomes replaced by more complex energy management and takes in account altitude and speed, to get the total energy of the Shuttle.

 

[Poscik]

Ok, so I'm preparing to operate on drag to maintain correct path. Path will be calculated from range vs. (altitude + speed). If within acceptable error, maintain current drag, if not, increase/decrease by modifying roll. Is that closer to succeed?

 

[Urwumpe]

Ok, so I'm preparing to operate on drag to maintain correct path. Path will be calculated from range vs. (altitude + speed). If within acceptable error, maintain current drag, if not, increase/decrease by modifying roll. Is that closer to succeed?

No, you have to understand the algorithm as "increase or decrease bank to one side for keeping deceleration at 16 m/s²" and "flip the side to which you bank when the error between your course and the azimuth to the base grows bigger than 10.5°".

The lines on the ENTRY CRT screen look initially a bit confusing, but they have no effect on the autopilot, they exist only for detecting errors. The real trajectory, if employed properly, will be close to the data in the ENTRY screen, but it will not try to slavishly follow the line.

When the Shuttle drops below Mach 8 (I am not sure, could be also at 5000 fps), the guidance transits to the TAEM, the terminal area energy management, there the shuttle starts to control its energy directly for intercept the HAC at the right conditions.

 

[Poscik]

Ok, thank you all, I'll try to do something. But can't promise instant results, as I'm quiet busy on uni right now.

 

[SiameseCat]

No, you have to understand the algorithm as "increase or decrease bank to one side for keeping deceleration at 16 m/s²" and "flip the side to which you bank when the error between your course and the azimuth to the base grows bigger than 10.5°".

The lines on the ENTRY CRT screen look initially a bit confusing, but they have no effect on the autopilot, they exist only for detecting errors. The real trajectory, if employed properly, will be close to the data in the ENTRY screen, but it will not try to slavishly follow the line.

When the Shuttle drops below Mach 8 (I am not sure, could be also at 5000 fps), the guidance transits to the TAEM, the terminal area energy management, there the shuttle starts to control its energy directly for intercept the HAC at the right conditions.

TAEM starts at Mach 2.5, not Mach 8. Like Urwumpe said, you also need to monitor DelAz (the error between you current direction and the direction to the landing site) and do a roll reversal if this value gets too big. BTW, the AerojetDAP class has a CalculateRangeAndDELAZ function which you can use.

For converting a target drag into a desired bank angle, one idea I had was this:

1. Calculate the altitude at which the drag will be equal to the desired drag assuming the shuttle's speed is unchanged). The target descent rate can be calculated based on data from 2 timesteps.
2. Based on the target descent rate and altitude error, change the descent rate by increasing or decreasing the bank.

There are probably other ways of doing this, but this seems (to me) relatively simple to implement.

 

[DaveS]

Based on a report by SiameseCat here, I have been going though and checking the the SRB segments and have found that all of them were off in length to various degrees. This has now been corrected and they all have the correct lengths.

I will check the new meshes in once I have gone through them one last time.

---------- Post added at 10:40 PM ---------- Previous post was at 10:25 PM ----------

New steel SRM segments checked in. Lengths should now be correct.

 

[Poscik]

In preparation for introducing reentry autopilot, I made small research and found this:

Also AOA profile with equations is depicted:

Full document: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19800018907_1980018907.pdf

I think It's the answer for drag and roll questions. If this is what are we looking for, the very next objective is to execute oms burn in right time, and right place.

In that case, method can be only one - lookup table relative vel vs. drag and banking to keep drag at value obtained from table. Or second option: rewrite all those algorithms described in document. But at the moment I'm more likely to use first option, and slowly introduce the second one.

Any thoughts?

 

[Donamy]

Sounds great, I also have an idea on a new reentry effect. Kinda like the ssme animation I did.

 

[DaveS]

Sounds great, I also have an idea on a new reentry effect. Kinda like the ssme animation I did.

Any screenshot of this effect? Also, could you make the plasma effect that streams upward solid instead of striped like it is now?

This is a view from the PPOV camera during entry of STS-114:

 

[Donamy]

what does the effect look like now?

 

[DaveS]

what does the effect look like now?

Here's one from STS-107, right before the tape starts to degrade and end:

How the effect looks like now in Orbiter. The white stripes coming from the bottom should be solid.

 

[Donamy]

Here's one from STS-107, right before the tape starts to degrade and end:

How the effect looks like now in Orbiter. The white stripes coming from the bottom should be solid.

Could you send me that scenario ?

 

[DaveS]

Could you send me that scenario ?

You already have it. It is Space Shuttle Ultra\Historic missions\STS-107\De-orbit.scn.

 

[Poscik]

Ok, time for some progress. At the moment I'm looking for function that will return needed vertical speed to maintain tergeted deceleration. Any thoughts? All what I did till now is enabled AUTO button for ROLL/YAW DAP, so If I hardcode f.e 70 degrees of roll, and then click AUTO, shuttle rolls to 70 degrees and keeps it. Now only physical aspect left. I think that can be just one function that return needed roll angle. Any tips, ideas? I can try to do that as SCOM says - if deceleration goes too high, shuttle banks to f.e. h-double-dot of 0.5m/s*s to reduce vertical speed. She keeps that h-double-dot untill she notices, that at current vertical speed our deceleration is constant. Then shuttle banks again to reduce h-double-dot to 0 and keep this vertical speed. Should I go this way and code it like that?

 

[SiameseCat]

I had a more complex solution in mind - based on the desired drag value, calculate the altitude (assuming velocity & AOA don't change). The change in target alt. over multiple timesteps will give us a target hdot. We can then add a correction factor to compensate for error between the actual and desired hdot.

Calculating the desired altitude will require a lookup table to get atmoshperic density at a given altitude, but I don't think this will be difficult.

The problem with your solution is that drag depends on altitude and velocity, not vertical speed. As a result, the shuttle is likely to constantly overshoot or undershoot the target drag.

 

[Poscik]

Ok, I'm trying to imagine your solution. If I'm wrong, then correct me. Just want to be sure If I'm thinking good. We calculate drag which is caused by speed in air, then if drag is too small, we're adding some hdot to make it as close as possible to desired drag?

 

[SiameseCat]

Not quite. The main idea is to convert the target drag into a target altitude/descent rate, and then try to achieve the desired altitude. If the drag is too small, we need to descend. We do NOT always need to increase the descent rate.

The idea is: we have a target altitude and a target descent rate calculated from the target drag. If we are above the target altitude, we want to descend faster than the target hdot, so we reach the target altitude.

 

[Poscik]

Ok, so I'm still trying to figure out your method - I mean, why in conclusion you got such method. I already tried my last method with drag lookup table - yes, it failed. Tomorrow I'm gonna give a try a lookup table v.rel vs. altitude. I'll create table from entry cue card available f.e. in STS-135 Entry Checklists. Also have to find some free time to gradually analyze algortihms and charts from pdf found on ntrs. There are 60 pages of algorithms and formulas, that describe how GNC works and what does it do in every phase, from pre-reentry to taem. This is our goal, if I understand idea of SSU correctly

 

[SiameseCat]

I haven't actually tried this method, so I might be missing something. The problem is that the shuttle can't directly change the drag level; the only way to increase/decrease drag is by ascending or descending (for the moment, let's pretend velocity is constant). Therefore, we need to calculate a target altitude from the target drag, and ascend/descend until we reach the target altitude.

Since the velocity is changing, our target altitude will also change, even if the target drag is constant. As a result, we need to calculate a target hdot, and add an offset to this target hdot to compensate for altitude errors. Then we can change the roll angle to give us the required hdot.

One last recommendation: first, calculate the target drag, and fly the shuttle manually (use the debug string to display required and actual drag). Once you know your drag profile is correct, you can write the autopilot code to maintain the target drag.