Space Shuttle - Bugfixes

[GinGin]

In reality you can execute 2EO BLUE during stage 1 and I believe you would operationally do that [...] the abort that should be flown depends on the failure time of the engines

You are right.
I had another look in the Ascent/Abort Handbook.


They arm and select the contigency abort in first stage if failures occur there




The logic commands a loft in the pitch schedule ( That is now well covered in autolaunch.nas) and an OMS dump starting at 70000 feet



Then the 2EO Blue logic kicks in immediately at SRB sep

And like you mentionned, color depends on failures timeline ( Blue on the left / Green on the right)




I did an other tests with 51.6° Inc, full payload (250000 pounds at MECO) and failures after liftoff.
I just armed with item 2 and the String was then blocked in Blue for later activation even if hdot drops below the boundary, so that is nice.

With the autoloft thing, the pull out is quite smooth even at heavy weight




It seems then to be fixed, and we just need to arm it in first stage to freeze the Color String before Stage 2 activation to be well in a 2EO Blue.


I pushed a small fix commit for the Nz hold actication ( 2.5 G instead of 1.6 G) // It avoids an itinial pitch up at 1.6G to catch the Nz target and then go high on G's

[Thorsten]

I just armed with item 2 and the String was then blocked in Blue for later activation even if hdot drops below the boundary, so that is nice.

I wasn't actually aware that this already works, but if it does all the better...

I guess I still need to look at the 'instant explosion' issue when I find the time to test more, it seems annoying.

[GinGin]

I wasn't actually aware that this already works

I discovered that by pure luck while I was late to press item 4
Though we can still add a global flag variable in autolaunch.nas if 2EO loft occured to enforced the contigency Blue/Green conditionnal.
Something like that:

Code: Select all

if ((abort_region == "BLUE") and (hdot > -SpaceShuttle.ascent_abort_boundary.hdot_2eo) and (SRB_status == 0) and [b](SpaceShuttle.first_stage_ca_flag == 0)[/b])
      {setprop("/fdm/jsbsim/systems/abort/contingency-abort-region", "GREEN");}


I will check that tomorrow

the 'instant explosion' issue

I haven't experienced that today. I have a bit of free time until Tuesday, I will try to trigger it again.




I am almost at the end of my long haul space trip.
Everyhting worked really well, I even forgot the FC purges and had some Mn Volts alarms, quite nice.
The last save/resume parameters are really handy.

A few things I noted while playing with everyhting in the cockpit:

-Would it be possible in Spec 2 to set a Down Countdown with item 9 and a minus entry ? Like with item 23 when we a burn is loaded




-Save/resume parameters

ADI error / rate might interesting to be saved. I think the ADI attitude is already a saved parameter.
Maybe some RMS switches also and the payload lights
Is it feasible to save the RMS position ?


I even found a nice Deorbit Burn datas thanks to your REI/TIG/Theta optimizer .
Nominal entry interface parameters and 800 Nm of cross range .
Looking forward to test that

[Thorsten]

Though we can still add a global flag variable in autolaunch.nas if 2EO loft occured to enforced the contigency Blue/Green conditionnal.

I don't think we should do that - if we lock the abort region by arming the abort, that's sufficient to do it right.

[GinGin]

I don't think we should do that - if we lock the abort region by arming the abort, that's sufficient to do it right.

Sure.

I remarked that if we depressed item 2 and 4 in Stage1, it will trigger the contigency guidance and then jammed the abort as we loose the stage 1 guidance until SRB sep.
I will add a first stage 2eo blue guidance function in contigency.nas then.

Like that we will be able to the 2 eo blue properly; abort declared in Stage 1 (autoloft and oms dump at 70000 feet), and 2eo blue guidance kicking in at SRB sep.

[Thorsten]

I've checked in the PDRS changes - if you execute the auto-sequence items without sequence number, the DPS parser fails, but the display loop runs on. If you want to assign the first i-loaded sequence to the AUTO 1 slot, do

ITEM 13 + 1 EXEC

and it should be available.

I guess the lifting of the HST out of the payload bay might be a worthy target for an auto sequece. It's not so easy with simple operator commanded movement - if you just enter the grab position, it runs into software stop

[GinGin]

the DPS parser fails, but the display loop runs on

Nice, thanks.


The function thing for 2EO blue during first stage works well, I will push it then.

Left, 2EO Blue declared in stage 1. Auto lofting
Center, 70000 feet, OMS dump
Right, SRB sep and 2EO Blue guidance kicks in automatically





I did some tests with really heavy payload and aft CoG, didnt end well. Entertaining as it was in real a problem in some STS missions with bad CoG/payload for Contigency aborts. More Black Zones.
Really interesting to test those things at the limits

[GinGin]

I finished the long haul tests.
What a trip, Deorbit/Entry/TAEM went smoothly.

A couple of things I have noted.


The REI calculated by the LEO tool is really spot on




The REI calculated in sim seems to be off for the first computation and far from the entry interface

Left picture during the Deorbit burn (6335 forecasted vs 4500)
Right is after the burn when I reload a dummy target ( 4764, better)



Is it possible to have the same accuracy for REI computations we have with LEO tool but in the sim ?

[Thorsten]

Is it possible to have the same accuracy for REI computations we have with LEO tool but in the sim ?

I've noticed the same thing for coming back from the high orbit - we'd have to understand what isn't working in-sim for starters In principle we should have the same algorithm available in-sim but in practice it doesn't always yield the same results.

[GinGin]

I saved before the deorbit burn to do some checks.

I dug a bit.

Before the burn

One thing I noticed: If correct weight is used ( left), Perigee forecasted hence REI forecasted are quite different than with an heavier weight, though still off)



After the burn


The targeted Perigee with real weight is then off after the burn ( we have the current 20 Nm Per like forecasted with the 250 klbs burn datas // which seems to be the one calculated by LEO tool also)




Just after the burn, I reload with a dummy target and get then the correct REI




It might be something in the forecasted computation loop; the Perigee targeted depending of the weight might affect the pre-burn forecasted REI in return (?)

[Thorsten]

It occurred to me that the REI prediction might use impulse approximation (instantaneous burn), which for an 8 minute burn is particularly bad - in the event, that'd be some 4 minutes worth of orbital speed off, aka round about a thousand miles - and of course it'd not be an issue after the burn.

I can issue a warning here - issues in the numerics which are not immediately obvious and are just on the level of accuracy are very hard to find. I have a list of things that - at some point - should be improved, there's for instance an issue with PEG 4 convergence, it's too slow and might run into a non-converging corner, the close range targeting doesn't work overly well,...

We can start fixing those, but if 'we' means 'I' have to do the debugging, we're shifting any release back to June/July - optimistically. These usually involve hard-core debug sessions with a whole helper framework that needs to be constructed to compare intermediate results against analytical solutions - at my current rate of perhaps 1-2 h uninterrupted coding per day, that kind of work takes really really long.

[GinGin]

I can issue a warning here - issues in the numerics which are not immediately obvious and are just on the level of accuracy are very hard to find

That seems like a nice idea.
A warning that REI might be different than the true one forecasted by the LEO tool, before the burn occured.
I will test again with more normal operations ( 200 Nm), I dont remember it was really off for those operations.

We can start fixing those

We might share

we're shifting any release back to June/July - optimistically

Alright, we might postpone that after the Stable Release then, as it is not a game breaker, especially with the LEO tool + the warning message (?)

[Thorsten]

A warning that REI might be different than the true one forecasted by the LEO tool, before the burn occured.

Actually that was not what I meant - it was a warning to you - since that's the second numerics issue you put up - that these might be really involved problems.

You can check whether the forecast uses impulse approximation - if so, we can simply correct for an offset of half the burn duration at orbital speed, that should give an acceptable result.

(Eventually we can also simulate using a finite-duration burn, there's probably a reason that's not done at the moment despite being supported by the targeting code...)

[GinGin]

You can check whether the forecast uses impulse approximation

Ah ok , I see ( I think)

If I put in item 10 the initial TIG + time duration of the burn ( 8mn later here), the output is the correct REI. (Perigee is still a bit off and weight depending)
So it seems that for the REI at least, we could add to the oms_burn_target.time_to_burn used for rei correction the burn_time_s (?)






Edit: The thing to add the burn duration time to the time to burn works nicely for the REI, it is spot on like Leo tool. One thing done.


I dont find from where might come from the weight dependency into the Perigee computation though.
The weight affects the acceleration hence the burn duration like you did in the oms_burn_logic, but the dV total is the same . It should output the same Perigee targeted.
Maybe there is an acceleration dependency (hence the weight) in the Apsis computations compute_apses function (?)

[Thorsten]

If I put in item 10 the initial TIG + time duration of the burn ( 8mn later here), the output is the correct REI.

That would be wrong then - it should be half the time duraction to be more than a lucky accident.

Which it seems to be... looking at the code, you get the exact solution when the PEG-4 solver has been run, but a rather approximated version when you enter a PEG-7 target. Which we do, because we don't target anything using PEG-7, so we have no EI point.

So - what happens when you actually enter the PEG-4 parameters?

I dont find from where might come from the weight dependency into the Perigee computation though.

From running the burn in the targeting manager probably.