Board index FlightGear Development Spaceflight

Space Shuttle - Bugfixes

Discussion about development and usage of spacecraft

Re: Space Shuttle - Bugfixes

Postby GinGin » Fri Mar 26, 2021 12:41 pm

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

Image


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

Image

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)

Image


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

Image


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

Re: Space Shuttle - Bugfixes

Postby Thorsten » Fri Mar 26, 2021 3:38 pm

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... 8)

I guess I still need to look at the 'instant explosion' issue when I find the time to test more, it seems annoying.
Thorsten
 
Posts: 12056
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Fri Mar 26, 2021 5:00 pm

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

Image


-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

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

Re: Space Shuttle - Bugfixes

Postby Thorsten » Fri Mar 26, 2021 5:46 pm

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.
Thorsten
 
Posts: 12056
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Sat Mar 27, 2021 1:43 pm

Thorsten wrote in Fri Mar 26, 2021 5:46 pm: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.
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby Thorsten » Sat Mar 27, 2021 3:14 pm

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 8)
Thorsten
 
Posts: 12056
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Sat Mar 27, 2021 4:21 pm

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

Image



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

Re: Space Shuttle - Bugfixes

Postby GinGin » Sun Mar 28, 2021 8:54 pm

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

Image


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)

Image

Is it possible to have the same accuracy for REI computations we have with LEO tool but in the sim ?
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby Thorsten » Mon Mar 29, 2021 5:47 am

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.
Thorsten
 
Posts: 12056
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Mon Mar 29, 2021 7:21 am

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)

Image

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)

Image


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

Image


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 (?)
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby Thorsten » Mon Mar 29, 2021 10:35 am

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.
Thorsten
 
Posts: 12056
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Mon Mar 29, 2021 10:48 am

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 (?)
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby Thorsten » Mon Mar 29, 2021 11:00 am

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...)
Thorsten
 
Posts: 12056
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Mon Mar 29, 2021 4:13 pm

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 (?)

Image




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 (?)
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby Thorsten » Mon Mar 29, 2021 4:59 pm

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.
Thorsten
 
Posts: 12056
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 2 guests