Space Shuttle - Bugfixes

[GinGin]

I'm actually surprised you don't see it at all

Indeed, I don't remember to have experienced that one
Thanks for the Entry scenario, I will test that tomorrow.
I am setting up a nice polar mission at the limits, playing with Insertion parameters ( I aim for 320 Nm, 30000 lbs payloads, 80° Inc). I will go for a long haul mission to test the last save/resume changes and RMS ops.


I think I found a small bug with the trajectory map canvas.
When Orbital Target is defined as false in the mission.xml

Code: Select all

<orbital-targets>
  <section-defined type="bool">false</section-defined>
  <object-label type="string">HST</object-label>


The traj map crashes

[Thorsten]

I guess I'll look at the map tomorrow then. There's two more issues - it should show a programmed burn but doesn't always do that, and the history is borked when starting a scenario.

Do you take care of the log issue in the time prediction - I saw you had added some more codepaths there...

[GinGin]

since we have BFS and PASS specific CWS messages, we might actually implement a check whether the system is actually available before firing a message

I implemented the check you suggested and it worked out ok, I will push it tomorrow

I saw you had added some more codepaths there

Ah yes, I added a conditionnal for a rough OPS6 RTLS MECO computation, but I didnt change your original MECO code for OPS 1 computation.

[Thorsten]

Map should be fixed now.

[GinGin]

Map should be fixed now.

1)Yep, it seems to work well ( especially for the OMS burn time), thanks.


2)I pushed the commit for no fault messages and Backup C/W light if no SM in BFS or PASS.
The Class 2 red alarm plus F7 associated light will still illuminate as it is a hardware thing and not related to SM software

3)The Freon loop works much better, evap out is always between 15 and 35 °F without any particuliar attention given to monitor it
We might then lower the low Freon alarm trigger to 10°F instead of 20°F .

4)Some feedbacks on my current mission.
I really like the new save/ resume parameters, it works really well.

A couple of parameters that might be interesting to implement in the saved state:

-Display setting for screens ( on/off and which pages we were on)
-Ac bus sensors
-RCS X feed valves ( I saw the OMS X feed valves were saved), I often use RCS X feed to save RCS propellants in Orbit
-Fes heaters state to avoid fault messages triggering when saved state is resumed

[Thorsten]

A couple of parameters that might be interesting to implement in the saved state:

-Display setting for screens ( on/off and which pages we were on)
-Ac bus sensors
-RCS X feed valves ( I saw the OMS X feed valves were saved), I often use RCS X feed to save RCS propellants in Orbit
-Fes heaters state to avoid fault messages triggering when saved state is resumed

Seems reasonable, I'll see to it.

Unfortunately droop guidance remains broken for me - I explicitly tried first engine failure at 5000 ft/s and second engine at 12200 like in your test.

The sequence of events in the test was as follows:

* first engine fails
* TAL guidance engaged a few seconds later
* after verifying TAL engaged, I start OMS propellant dump
* OMS propellant dump progresses nominally
* second engine fails
* SERC engages
* for a split second DROOP flashes on the DPS page, then is gone, DROOP ALT is frozen
* Shuttle does not change attitude
* inspection of /fdm/jsbsim/systems/ap/launch/droop-guidance-active in the property browser revelas 'false'
* I set the property manually to 'true', but it reverts to 'false'
* nevertheless, Shuttle pitches up
* using SPEC 51, I set thrust to 109%
* Shuttle refuses to pitch down after approaching nominal trajectory
* i take pitch axis to manual and fly the Shuttle onto the nominal trajectory
* I change TAL site from Banjul to Capo Verde
* flight proceeds to 3% propellant remaining, then MECO occurs
* automatic ET-sep
* hasty roll to entry attitude and OPS 301-> 304
* I immediately engage low E logic
* nevertheless I end up about 400 miles short

So there's two problems - droop guidance definitely did not engage, and the MECO targeting did not make use of the remaining 3% propellant which could have bridged the 400 miles that were missing..

I'm not sure *why* droop guidance didn't engage (or rather, immediately diengaged without doing anything) - I checked the log file and didn't see an error this time. So... before I go into a lengthy analysis - could it be that there's another instance of a new JSBSIm conditional involved here which makes it work for you but not for me? Something like that seems the most likely scenario at this point...

As for the MECO targeting... perhaps it was never optimized for low Mach numbers and we need to change landing site only during the entry phase?

[GinGin]

Seems reasonable, I'll see to it.

Thank you.
Last one I forgot and I find pretty handy is the Payload Fload Lights.
For the rest and especially all the GPC configurations, it's really a nice save/resume function

Shuttle refuses to pitch down after approaching nominal trajectory

Weird, above 12kfts, it should move to stage 4 and follow hdot guidance for TAL

- could it be that there's another instance of a new JSBSIm conditional involved here which makes it work for you but not for me?

I will dig that and gave first another run following exactly what you did.

perhaps it was never optimized for low Mach numbers and we need to change landing site only during the entry phase

I remember having changed the TAL site during ECAL test, and the output was weird sometimes yes; like a bit prematured MECO.

Maybe some transient condition with the dist_ballistic computation as landing site is changed (?)
I will run tests on that also then.


Edit:

1)I did a run 1EO 6000 / 2 EO 12000 and same procedures than yours.
That works ok.

2)Same verdict for the TAL redesignation
I tried the Cape Verde redesignation quite far (2300 Nm / 13300 ft/s) and it was okish. I had the 3/4 % prop remaining and I was short on range actually during latest part of entry.
I remember Cape Verde MECO speed was around 19000 ft/s and on STS 125 cue cards, the Low energy Cape verde TAL starts at 21700 ft/s, so we miss indeed some speeds for those kind of redesignated TAL

[Thorsten]

Maybe some transient condition with the dist_ballistic computation as landing site is changed (?)

The targeting with the ballistic impact point makes assumptions about the available centrifugal force, so we can simply require a few hundred miles more when we are at lower Mach numbers and not alter the higher Mach cutoff condition.

That works ok.

It smells like a version dependence, since we very likely run the same Shuttle... Well, if there's nothing obvious, it can't be helped, I'll have to read through the code in detail and insert debug breakpoints.

[Thorsten]

Trying to wrap my head around the DROOP issue by code inspection, I've noticed the rather unfortunate implementation of the abort boundaries as part of the AP.

Abort boundaries are something we typically need to compute 'once' (or, if we customize a mission runtime, we need to recompute after adding a payload or changing the inclination.

The way this is implemented, we re-compute everything 120 times each second - even when we are safe in orbit or doing TAEM inside the atmosphere, so... we're computing the results a few hundred thousand times more than we actually need them.

The Shuttle FDM has still a few such computations (the RTLS guidance was done by a time when I wanted to try whether a pure JSBSim would be faster) - but they're not run unconditionally, the channels are only run when needed. The lesson learned from this was that we should not do such things - things we need 'once' we should let Nasal do 'once' (or if something changes, set a listener and re-run).

So please let's not have this as JSBSim system and port it into a Nasal one-time affair.

Also, the abort boundary callouts are "help", but I was under the impression they were really done on Shuttle missions - if so they should be "real" - "help" is for things we put in as reminder for beginners.

[Thorsten]

Weirdly enough, the next droop test I did worked out okay.

That (in combination with screenshots I took when it didn't work) has given me an idea what is happening.

We're dealing with emergence in a complex system (which is incidentially why I insisted in doing excessive testing after FDM changes...). From my screenshot, it seems that 12.200 ft/s inertial velocity happens to be right at arctop - in the shot I took right after droop guidance did not properly engage the engine has been off a few seconds and I'm going down by a mere 85 ft/s.

The crucial observation is that at the point where droop guidance engaged, I must have still been going upward. That's... highly relevant, because a non-zero upward speed is the criterion for disengaging droop guidance. So... if the engine failure happens while the Shuttle is going up, droop guidance engages properly, but then decides it can disengage because, well, we're not going down. And of course it never engages again, and the normal TAL logic can't stabilize the altitude.

So any engine failure before arctop is reached does not properly trigger droop guidance (therefore my attempt at 11900 failed and 12200 failed, but 12700 worked).

Why are we seeing this only now? That's where some older screenshots come in handy - we used to have a launch trajectory that hit arctop much earlier, well before the droop region, so when droop guidance was originally coded, the Shuttle was alwas descending in the droop region, thus a non-zero upward velocity was an eminently reasonable criterion when to disengage it.

However, when you re-shaped the trajectory, you moved arctop into the droop region, thus allowing for the possibility that the Shuttle is going upward at the moment this should engage, thus disabling droop guidance for a fraction of the region where it should engage.

Of course nobody could have forseen that - which is why this is an example of emergence - two seemingly reasonable and harmless actions communicate in a way that creates something quite unexpected.

So it seems the criterion for disengaging droop guidance has to also check the sign of the vertical acceleration - and then I guess it should work again as intended.

(Still need to fix the low Mach number targeting correction...)

[GinGin]

so we can simply require a few hundred miles more when we are at lower Mach numbers and not alter the higher Mach cutoff condition.

That seems to be a good option.

let's not have this as JSBSim system and port it into a Nasal one-time affair.

Ah yes, I originally wanted to had an execute condition and forgot.
Even though, I didnt think of the extra calculations generated; thanks for the explanations.

So just to clarify, even if I put those computations in a jsbsim channel with an execute thing that will be runned just for ascent ( like you did for RTLS guidance), it is way more efficient to do that king of "on time computation" in Nasal ?
I will put that in the stage.nas with a linear scale variable to have a similar linear interpolation than with a jsbsim table and a hash with boundary global variables to use them where it is needed instead of jsbsim input/output then

I was under the impression they were really done on Shuttle missions

Indeed, real might be more appropriate. I will fix that.

I must have still been going upward. That's... highly relevant, because a non-zero upward speed is the criterion for disengaging droop guidance.

However, when you re-shaped the trajectory, you moved arctop into the droop region, thus allowing for the possibility that the Shuttle is going upward at the moment this should engage,

Well spotted.
That is an interesting debugging reading

[Hooray]

it is way more efficient to do that king of "on time computation" in Nasal ?

it seems, the channel mentioned above is executed "unconditionally" at FDM rate - while its computation/results won't change/be relevant.

So you're basically doing hundreds/thousands of unnecessary calculations during each time step.

Moving the calculation into scripting space (Nasal) means that the calculation is at most executed once per frame, and that it can be easily triggered to only run "on demand" - and otherwise keep it "disabled".

That way you could run the calculation/function only ONCE rather than actually running it hundreds of times per simulation cycle.

Nasal isn't good for deterministic stuff or for stuff that needs to run at high/reliable rates, because it runs interleaved with a ton of other FlightGear code (subsystems), many of which may utilize different amount of time (slices) during each second/frame. That is why you get to see frame rate/frame spacing "jumping" around.

But for simple stuff that only need to run rarely, or at low frequencies, Nasal is well-suited. Unless of course you're creating a ton of data/variables which need to be recycled, because at that point the so called "garbage collector" kicks in, which basically:

- STOP ALL Nasal code
- TRAVERSE THROUGH ALL Nasal VARIABLES/OBJECTS
- MARK REACHABLE ONES (those referenced/used elsewhere)
- DELETE/FREE UNREACHABLE STUFF
- ADD IT TO A FREE LIST FOR NEW ALLOCATIONS
- CONTINUE NASAL EXECUTION

JSBSim systems run much closer to native code (no garbage collector, no other subsystems interfering with jsbsim), because it's just an XML layer and some C++ data structures that are directly mapped to compiled code - but the default execution models runs several FDM iterations per frame (60-120 iterations/frame).

In other words, if your channel isn't activated by some external flag/condition, it will also run its calculations at 60-120 times per frame.
Suppose you have a frame rate of 40 hz (fps), that's 40 x 120 = 4800 computations/second - and if those don't provide any necessary/relevant results, it's just a waste of computation power.

[eatdirt]

which is why this is an example of emergence

Simply amazing! Well done for having found that!!!!

[Thorsten]

So just to clarify, even if I put those computations in a jsbsim channel with an execute thing that will be runned just for ascent ( like you did for RTLS guidance), it is way more efficient to do that king of "on time computation" in Nasal ?

Yes - JSBSIm channels will (usually (*)) be executed 120 times per second when they're active. So the RTLS-guidance solution isn't optimal - although it only affects the performance if you actually fly RTLS. Basically we don't feel heavy JSBSim systems that much on a good computer - unless of course we accelerate time. In the old days with lean systems, I used to be able to do 16x time compression for the Shuttle - now we're computing so much in the background I only manage 4x. While for Spaceflight high numbers would of course be nice, the wait for the next apsis can grow lengthy...

Look at the leakage manager - that's a 'modern' system. It calculates leakage flows once when and only when an event occurs. That event might be a leak, or a valve-closing, there's listeners to the relevant properties - but if no event occurs, the system sits in the background and does precisely nothing. That's how I could have set up other systems as well if I had had all design experience before (the electrical system is a prime example that could have been different...)


(*) using 'execrate' in the channel definition you can clock down a channel to run only every nth iteration - which also helps reducing performance footprint. Theoretically (I haven't tried) it should be possible to do a one-time channel in JSBSim - it executes based on a property being true but sets the property to false itself at the end of the channel, so it doesn't execute the next time and needs an external trigger to process again. If you like the tables and shy away from doing them in Nasal, you could try to set it up that way.

Simply amazing! Well done for having found that!!!!

A good 30 years of experience in what kind of weird things computer code can do helps in that respect. It doesn't even come to the weirdest one I've ever had...

[GinGin]

@Hooray and @Thorsten: Thanks for the explanations, I learnt some interesting things.

Look at the leakage manager

Ok, I will do that.

If you like the tables and shy away from doing them in Nasal, you could try to set it up that way.

I will do an hybrid.

1)Nasal for the boundaries that are calculated prior to liftoff with inclination setting ( hash, function and a setlistener in launch part at stage 0)
2)jsbsim for the redesignation tables as they are multiple entry tables // I wiil put them in Stage 3 TAL subchannel with execrate setting and the one time running jsbsim thing if I find something about.