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 8: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: 1256
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Sun Feb 21, 2021 10: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: 11885
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Sun Feb 21, 2021 12: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: 1256
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Sun Feb 21, 2021 6: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: 11885
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Sun Feb 21, 2021 10: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: 1256
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Mon Feb 22, 2021 3: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: 11885
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Mon Feb 22, 2021 8: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: 1256
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Tue Feb 23, 2021 7: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: 11885
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Entry/TAEM rework

Postby GinGin » Tue Feb 23, 2021 3: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: 1256
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Entry/TAEM rework

Postby Thorsten » Tue Feb 23, 2021 3: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: 11885
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Entry/TAEM rework

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

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

Previous

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 1 guest