Board index FlightGear Development Spaceflight

Space Shuttle - Entry/TAEM rework

Discussion about development and usage of spacecraft

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Sun Feb 21, 2021 9:41 am

My suspicion would have been that it assumed a zero radius


I thought about it, but I dont see why.

Wp1 calculation
Code: Select all
# the WP 1 aim HAC entry point depends of the angle we have to fly at entry of the HAC (radius from 4.5 Nm to 2.3 Nm)
TAEM_WP_1.set_latlon(TAEM_HAC_center.lat() + m_to_lat * wp1_vec[1] * hac_radius * hac_factor_wp1, TAEM_HAC_center.lon() + m_to_lon * wp1_vec[0] * hac_radius * hac_factor_wp1);


Hac radius is 4270m and hac factor is always greater than zero

Code: Select all
<!-- hac-radius-factor-wp1 for TAEMguidance.nas Waypoint 1 distance from HAC center depending on Turn degree at entry// independant of MEP/NEP -->
      <fcs_function name="systems/ap/taem/hac-radius-factor-wp1">
      <function>
         <table>
              <independentVar lookup="row">systems/taem-guidance/turn-hac-degrees</independentVar>
              <tableData>
            90      1.0
            180      1.21
            270      1.52
            359      1.87
              </tableData>
               </table>
      </function>
      </fcs_function>



It used to be computed at transition to TAEM phase


Yes, it is still the case, handled by stages.nas

Code: Select all
#Distance/Mach trigger for TAEM (OPS3) // Entry traj 5 boundaries

      if (((d_remain < 60.0) or (mach < 2.5)) and (deorbit_stage_flag == 3))
         {
         SpaceShuttle.compute_TAEM_guidance_targets();
         glide_loop();


can you remind me why we have to reload the target manually?


I observed that sometimes ( actually for Large HACs and long distances), the waypoint1 calculation was slighty off when the Shuttle was still manoeuvring and acquiring the correct course towards the landing site.
To reload the TAEM target with item 41/3/4/6/7 in those case updates well the WP1 position and the course to it.

I dont remember if I observed that before, I will check on the stable version in same HAC conditions to see if it is new.
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Sun Feb 21, 2021 11:51 am

I observed that sometimes ( actually for Large HACs and long distances), the waypoint1 calculation was slighty off when the Shuttle was still manoeuvring and acquiring the correct course towards the landing site.


That's odd, because as far as I remember the computed solution is a) exact (errors are added only later when things are displayed, and they only affect where the Shuttle is, the tangent point is on a fixed earth-relative position) and b) proceeds from touchdown point outward (so it is completely independent of the Shuttle state). Only the intercept course is computed from Shuttle position to tangent point, but the only thing that changes is the Shuttle position.

Conceptually it doesn't change with anything the Shuttle does - only changing the requested approach geometry should lead to different results.

Where guidance thinks the tangent point to approach is relative to the Shuttle is a different matter - but the way the scheme works is that display and guidance should be in agreement, i.e. no nav error should lead you to a tangent point that's visibly not on the drawn line.

So there's something decidedly odd about the need to recompute anything.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Sun Feb 21, 2021 1:38 pm

I repoduced it for HAC turn angles more than 300 °ish (stable one time also)

I suspect that the WP1 might have been calculated for the other OVHD HAC entry point ( in red) when the first calculation (TAEM interface) occurs


Image

I got that, left first calculation aiming for the wrong wp1 // right after 45 Nm recalculation and the OHVD HAC switching to the correct Wp 1 way

Image


Might it be link to that ?

Code: Select all
var runway_perp_vec = [math.sin((TAEM_threshold.heading + 90) * math.pi/180.0), math.cos((TAEM_threshold.heading + 90) * math.pi/180.0)];

var approach_dot_rwyperp = SpaceShuttle.dot_product_2d(approach_vec, runway_perp_vec);
var approach_mode = getprop("/fdm/jsbsim/systems/taem-guidance/approach-mode-string");

if ((approach_mode == "OVHD") and (approach_dot_rwyperp < 0.0)) # we need to flip direction
   {
   runway_perp_vec = [-runway_perp_vec[0], -runway_perp_vec[1]];
   }
if ((approach_mode == "STRT") and (approach_dot_rwyperp > 0.0)) # we need to flip direction
   {
   runway_perp_vec = [-runway_perp_vec[0], -runway_perp_vec[1]];
   }
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Sun Feb 21, 2021 7:19 pm

I suspect that the WP1 might have been calculated for the other OVHD HAC entry point ( in red) when the first calculation (TAEM interface) occurs


I'm still not getting how the display and what guidance steers are at odds as they're supposed to use the same data. If we calculate the wrong point somewhere (which could of course happen), we'd still draw the thing we computed - the case that guidance steers to a point but the display shows another point would need two different data sets somehow.

I've also tested when originally implementing this cases ranging from 0 deg (flying straight into the final approach) to 360 deg (doing a full circle) and I am pretty confident there's no funky angular region.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Sun Feb 21, 2021 11:56 pm

I solved that one, quite strange. It is not a display or visualisation problem.
With the following code, at first TAEM computation, Course is directly to HAC center. It needs a second TAEM computation to have the correct WP1 position

Code: Select all
var turn_degrees = math.abs(approach_dir - TAEM_threshold.heading);

if ((turn_degrees < 180.0) and (approach_mode == "OVHD"))
   {
   turn_degrees = 360.0 - turn_degrees;
   }
else if ((turn_degrees > 180.0) and (approach_mode == "STRT"))
   {
   turn_degrees = 360.0 - turn_degrees;
   }

#Turn degrees stored for WP 1 construction depending on Turn degrees as radial will vary with it.

setprop("/fdm/jsbsim/systems/taem-guidance/turn-hac-degrees", turn_degrees);

.
.
.
.
var hac_factor_wp1 = getprop("fdm/jsbsim/systems/ap/taem/hac-radius-factor-wp1");

TAEM_WP_1.set_latlon(TAEM_HAC_center.lat() + m_to_lat * wp1_vec[1] * hac_radius * hac_factor_wp1, TAEM_HAC_center.lon() + m_to_lon * wp1_vec[0] * hac_radius * hac_factor_wp1);


The turn_degrees is stored to be used in the hac-radius-factor-wp1 to output a factor based on the forecasted turn_degrees

Code: Select all
<!-- hac-radius-factor-wp1 for TAEMguidance.nas Waypoint 1 distance from HAC center depending on Turn degree at entry// independant of MEP/NEP -->
      <fcs_function name="systems/ap/taem/hac-radius-factor-wp1">
      <function>
         <table>
              <independentVar lookup="row">systems/taem-guidance/turn-hac-degrees</independentVar>
              <tableData>
            90      1.0
            180      1.21
            270      1.52
            359      1.87
              </tableData>
               </table>
      </function>
      </fcs_function>



If I do it directly in nasal without input/output before the WP1 calculation , it works like intended at first TAEM computation

Code: Select all
var   hac_factor_wp1_test = 1.0;

if (turn_degrees > 350) {hac_factor_wp1_test = 1.87;}
# the WP 1 aim HAC entry point depends of the angle we have to fly at entry of the HAC (radius from 4.5 Nm to 2.3 Nm)
TAEM_WP_1.set_latlon(TAEM_HAC_center.lat() + m_to_lat * wp1_vec[1] * hac_radius * hac_factor_wp1_test, TAEM_HAC_center.lon() + m_to_lon * wp1_vec[0] * hac_radius * hac_factor_wp1_test);




Edit : with the first method , it seems that it takes the previous stored value for the hac factor wp1 ( hence 0 at first taem initialization because I didn’t specify a basic value in common.xml // and wp1=Hac center like you said Thorsten )

It always takes the previous stored value at every taem computation .

I guess I will go with the nasal only method for the wp1 construction based on turn degrees
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Mon Feb 22, 2021 4:44 pm

It always takes the previous stored value at every taem computation .


A chicken and egg problem it seems :D

Anyway, I've managed to fly a complete de-orbit today and it basically worked okay. Some lessons learned:

* a Shuttle with 70% OMS fuel and FRCS tanks full can do an entry (I wasn't quite sure of that one...) but it costs plenty of RCS propellant

* the revision of MCC to account for the new FDM seems to work okay, the entry solution into which the MCC-advised de-orbit burn brought me was quite good

* I need to check the initial water supply for the APU spray boilers, I nearly ran out of cooling water before landing... or maybe they consume too much?

* the AP is again rather agressiv - about 2/3 through ENTRY TRAJ 1 is tries to increase sinkrate, and that typically leads to a roll oscillation around the desired value - at times the maneuvering is rather scary. In fact, entering ENTRY TRAJ 2 I found myself in inverted flight for about 10 seconds (bank angle > 90 deg). That seems... unnecessary, especially in light of the fact that the next 20 seconds I spent with 0 bank angle to recover from the high sinkrate. It seems specifially this phase of the flight, the first and last part of the entry is much more quiet

* TAEM works fine when the recomputation is forced via ITEM 3 EXEC, the flight around the spiral was without any oscillations

* the TAEM AP at one point pulled up steeply, reducing airspeed to 210 kts, then pushed the nose down again immediately to increase it again. Very odd - I was looking at the diamond, and this was actually commanded by guidance and not an external perturbation
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Mon Feb 22, 2021 9:45 pm

How much RCS fuel did it cost ?

Nice for the MCC solution , no more problems with illegal entry ?

For the entry oscillations , what was the scenario or initial conditions ( rei vrel).
Was the Shuttle a bit left of the third line close to the far left boundary ? I observed the same when close to the thermal boundary where the ap is more agressive to avoid getting into that zone ( mid end traj 1 and top of traj2 )
I will adjust then the drag required in those regions to have a more stable path and less aggressive recovery to the nominal path .

I will check also the WSB consumption with post flight data’s .
I usually finish abort once around with 20/30 pour-cent of waters and I got the fault messages . How much did you have ?

Good for the TAEM and the spiral . It is quite resilient with the radius based on altitude . I will fix like said above the recomputation thing .


For the pitch up you had , it is a pull up manœuver to enter the HAC below Mach 1 ( Low energy bias introduced in the guidance to lead to that pitch up)
It was quite agressive in real also ( it is described up to 2 gs and then up to 30 degrees pitch down to recover the path )
It still needs some tuning, but the fact to enter the hac subsonic to trigger the speedbrakes energy modulation logic and reduce the radius turn required with a lower ground speed is quite important for good hac cross range compliance
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Tue Feb 23, 2021 8:07 am

How much RCS fuel did it cost ?


I think about half.

For the entry oscillations , what was the scenario or initial conditions ( rei vrel).


I haven't measured. but I have a saved state just before EI. Basically it was a de-orbit burn from the standard orbit SpaceShuttle-mission gives you, with a retrograde -279 fps burn and a REI of 4100 miles shown. On the display the shuttle marker was dead center from the beginning and initially no hard maneuvering was needed at all - it was really the transition to a different regime which caused it (and pushed the track even below centerline). So this is a dynamical issue, not caused by the initial state.

Actually the inverted flight occurred just after switching to ENTRY TRAJ 2 and there I fell below the centerline. So it didn't look like thermal protection.

The bad CoG might have complicated things somewhat, I have little experience with that, but I didn't observe anything like control surface saturation - not even close.

I will check also the WSB consumption with post flight data’s .


I'm not sure they were full to begin with (I'm just trying to cook-up a scenario...) - I remember I had to adjust the excess heat by the APUs to make AOA possible, I have the power consumption of the APUs as well as the water consumption of the boilers for a given cooling performance, and it's clear this doesn't work out for an AOA, but... we know the hydraulic pressure isn't taken to high then, so the APUs require less powers, but not precisely how much less that is.

So it's a problem of matching the things we don't know with what we know must be possible...

For the pitch up you had , it is a pull up manœuver to enter the HAC below Mach 1 ( Low energy bias introduced in the guidance to lead to that pitch up)


Ah, okay. Fine in this case then :D
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Tue Feb 23, 2021 4:30 pm

Interesting those tests with off nominal CoG. It almost doubles the rcs consumption compared to a more nominal CoG

Ok for the entry ap, I will fine tuned the drag required for the concerned region to make the recovery less agressive; and smoothened the transition between thermal phase ( above 17 kfeet) and equilibrium one ( below 17 kfeet).
I will have an eye also on the alpha modulation activation conditions and bring it back when the actual drag is above the required one ( Mainly during roll reversal )


For the AOA indeed, it makes a big difference in the model you implemented with Hydraulic pumps on low or high , realistic.
I am struggling to find post flight data’s for WSB waters consumption ( I have got for APU fuel , the model we have is pretty accurate )
I
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Tue Feb 23, 2021 4:53 pm

I will have an eye also on the alpha modulation activation conditions and bring it back when the actual drag is above the required one ( Mainly during roll reversal )


I literally used it for damping oscillations around the desired drag value - you know the drag error and the drag error speed of change - so if you are below the desired sinkrate but are still going down, you're oscillating and you can use alpha modulation to reduce drag - if you're above and are going up, you can use it to decrease drag. If you just do that, the roll to a bank angle can be more relaxed because the alpha modulation takes away the need for agressive corrections - oscillations tend to be much more mild.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Wed Feb 24, 2021 4:25 pm

Ok good, I will just adjust the trigger then, and base it on drag error instead of vrel error .
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Tue Mar 02, 2021 11:30 pm

I pushed some commits concerning some slight changes to the Entry/TAEM code.

Entry

Some smoother Drag error corrections for early entry part ( 22 kfts-16kftsish)
I tested it with the 3 scenarios (KSC 4200Nm, lakebed and High energy), and I find that it is more stable now, let me know how were the runs for you.
The KSC 4200 Nm is really an optimal for entry, well done for the entry interface parameters.(20% of RCS used)



TAEM

1)All the Energy/Weight values ( Sturn/Nominal/MEP) and Glideslope path are extended up to 110 Nm to cover the early part of the RTLS TAEM ( earlier handover to TAEM guidance/ 100Nm/ to initiate early S turn to deplete energy).

2)The recomputation needed during TAEM is fixed, the hac factor radius for Wp 1 depending on hac turn degrees made in Nasal only works nicely.

3)Sturn conditions vary if in OPS 3 or 6
OPS 3: Sturn between 25 and 55 Nm and if HAC Turn angle is forecasted to be less than 200°
OPS6: Sturn above 35Nm

4)Adjusted Speedbrakes schedule below Mach 1 ( deadband is tighter, less energy exceedance, better HAC lateral accuracy)

I also upgraded a bit the Speedbrakes setting at 3000 feet QFE following the Approach/Landing Handbook findings .

The setting will be a mix of the following things:

Wind / EAS
Targeted EAS at 3000 feet is 300 kts.
If Indicated airpseed is above or below that value ( due to Winds or low on energy for example), initial SB setting will vary


Weight
Lightweight below 222 klbs ( 10% Speedbrakes more if above)

Aiming point
10% Speedbrakes more if close in aim point is selected ( 1000 feet less of distance to runway for the flare, hence additional energy to deplete)


Speedbrakes mode ( item 39 in Spec 50)
Nominal: Touchdown zone at 2500 feet / Lightweight speed targted 195kts / Heavy 205kts
Short: Touchdown zone at 1500 feet / Lightweight speed 195kts / Heavy 205 kts ( plus 10% Speedbrakes to land shorter)
ELS: Touchdown zone at 1000 feet / Heavyweight only 195kts (plus 25% speedbrakes to land slower and shorter) // Mainly for Abort with heavy weight


That is interesting to compare those touchdown zones to the landing marks available on a standard runway.

Normally, the big Aiming point mark is at 400 m ( 1500feetish) but can vary between 300 and 450m // The distance between the small marks is always the same (150m)
On that standard ICAO runway below, the red zone would correspond to an ELS touchdown zone ( 300 m) // the green to a Short SB touchdown zone ( 450m) // the pink to a nominal one ( 700m)

Image


A more familiar case, runway 15 at KSC ( non standard with a Aiming point mark at 300 m, replacing the second small touchdown zone marking)

Hence the following touchdown zones forecasted with the SB mode setting ( same colors than above)

Image


An example of ELS speedbrakes setting ( 50% of SB at 3000 feet), aim is 300 meters and 195 kts at touchdown.
By following the HUD cues, it is quite easy and rewarding for shorter runway than KSC

Image
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Wed Mar 03, 2021 8:42 am

Very good - seems the number of oddities encountered is slowly decreasing (I suspect a fair number are actually caused by not following procedures to the letter - to which the systems sometimes respond in subtly unforseen ways...) But my last experiences with entry, TAEM and landing have been good.

For instance, I've entertained the hypothesis that the lack of manual control after subsonic takeover might have to do with having controls not centered during entry on auto - I'm not sure about this yet unfortunately.

@GinGin - since you seem to have more time for testing, would you be in a position to establish when the NO Y JET mode actually works and when not? Apparently you did get it to work at least once after the FDM improvements - which is more than I can say for myself. That could hopefully give us a clue what the problem actually is that needs to be addressed.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Wed Mar 03, 2021 8:37 pm

, would you be in a position to establish when the NO Y JET mode actually works and when not?


I remember from the tests made 2 weeks ago that it worked well when engaged above 22 kfps and below 15 kfps ( same results on the stable).
I will do some more specific tests for that.
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Sun Mar 14, 2021 12:18 am

Small commit to introduce one of the last things missing to the entry display: the guidance Box.
More informations about it in the Entry Handbook 5-10 / page 116

It is a small square with its trailers ( 6 points) showing the variation of actual drag over range.
It indicates how well the guidance is working, and if we are going to be Low/High energy in the near future.
It is based mainly on the difference between actual drag experienced by the Shuttle and the drag required by the AP to make it safely to the field.


Some examples.

Required drag and actual drag are almost overlapping on the vertical ladder, hence the guidance box is matching the Shuttle marker indicating that we are on path drag wise

Image



Left picture, actual drag slightly is lower than required one, box is moving to the left of the display indicating that : if we do nothing, we are going to finish high on energy ( high altitude/ short range)

Right picture, actual drag is higher than required one, box is moving to the right of the display indicating that : if we do nothing, we are going to finish low on energy ( low altitude/ high range)

Image
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Previous

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 5 guests