Board index FlightGear Development Spaceflight

Space Shuttle - Bugfixes

Discussion about development and usage of spacecraft

Re: Space Shuttle - Bugfixes

Postby GinGin » Mon Mar 29, 2021 7:56 pm

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


Left real weight, center heavy weight.
REI Ok
Image


Which we do, because we don't target anything using PEG-7, so we have no EI point


By adding the expected burn time (oms_burn_target.burn_time_duration) into the rei correction, it seems to be an acceptable approximation for the REI (?)
I tried it on different entry deorbit scenarios.

Code: Select all
if (oms_burn_target.peg4 == 0) # need to estimate REI
      {
      #print("Extrapolated state reduced vel: ", v[0], " ", v[1], " ", v[2]);
      var rei = SpaceShuttle.get_rei(r,v);

      # correct REI for empirics and time to interface

      var rei_correction = 375.0 + 3.6556 * periapsis_nm;
      rei_correction = rei_correction - (oms_burn_target.time_to_burn + oms_burn_target.burn_time_duration)  * norm(v) * 0.000164578833693;
      # also Earth rotates while we coast, this is very naive

      var lat = getprop("/position/latitude-deg");
      var rot_correction =  math.cos(math.pi * lat/180.0) * 465.0 * (oms_burn_target.time_to_burn + oms_burn_target.burn_time_duration) * 0.000539956803456;

      oms_burn_target.rei = rei + rei_correction + rot_correction;
      }


Still the weight issue affecting the Perigee hence the REI for the left picture that we can disregard as the targeted Perigee is false ( but 22 Nm ish of Perigee really expected gives the REI expected by PEG4 in the right picture)

Image



*For the weight thing, I might have found something interesting.

I never really noticed it before because of the small burn duration differences weightwise for a 200 Nm Orbit. It does matter much more at 500 Nm with burn time going from 7:30 up to 8:30 with a 30000 pounds difference.
I looked then for a burn time variable in the Oms_burn_future computations as Targeted Apsis computations are not affected by weight/accel for an instantaneous burn withtout TIG.

In oms_burn_logic, that line adds a burn_time --> accel --> weight dependency for a forecasted burn computations and might be at the origin of the Perigee discrepancy observed.

Code: Select all
SpaceShuttle.targeting_manager.set_evolution_time(time + burn_time + 10.0);


Just for a rough test, I removed the line above fixing the max_evolution_time to a constant 8000 in the targeting manager hash.
And it works out ok.

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

Re: Space Shuttle - Bugfixes

Postby Thorsten » Tue Mar 30, 2021 11:27 am

Just for a rough test, I removed the line above fixing the max_evolution_time to a constant 8000 in the targeting manager hash.


Why did you imagine this would work? What is this supposed to test?

What is does it to compute the orbital elements not 'now' but for a time 2.2 hours in the future. While the apses conceptually don't drift, the location over Earth is different, since Earth is not a sphere but an ellipsoid that means you might take altitude over the the pole instead of altitude over the equator.

Still the weight issue affecting the Perigee


I'm not sure what the issue is - are you wondering why you get wrong values if you run navigation based on a wrong orbiter weight? Or is there more to it?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Tue Mar 30, 2021 2:08 pm

I'm not sure what the issue is


I am wondering why we get wrong targeted perigee values when we input the correct weight (216000 pounds for the examples above).
The heavier the weight entered is, closer we are to a correct estimated Perigee (the one we really have after the burn occured). In the examples above, perigee after deorbit burn is around 20 Nm and we got 40 Nm targeted with correct weight.

Burn_time variable is the only one I found that takes into account a weight dependency due to acceleration differences. That time variable is used by the evolve function in targeting_manager.
For me, what ever is the weight, Dv tot is the same, hence should be the Perigee forecasted // just the length of the burn would change.



Why did you imagine this would work? What is this supposed to test?


That was supposed to remove the burn time/acceleration dependency from the target_manager burn computation loop; just to see the outcome.

For PEG4, it outputted a correct Perigee (Maybe there is a max_evolution_time specified in a peg 4 computation function ? )
For PEG7, as forecasted, it ouputted something wrong but at least Perigee were the same what ever the weight. (That was the aim of that rough test)



If I take the acceleration for a mean weight (230 klbs) / (1.7 ft.s² for 2 OMS burn)

Code: Select all
var acceleration_mean = thrust_lb / 230000;

var burn_time_mean_s = dvtot/(acceleration_mean * 32.17405);
burn_time_mean_s *= 0.99; # better to err on the short side



And make the evolve function runned with that mean burn time, I find that we got a better targeted Perigee approximation by taking a mean acceleration for weights below 230000

Code: Select all
SpaceShuttle.targeting_manager.set_evolution_time(time + oms_burn_target.burn_time_duration_mean + 10);



I did some tests with that mean_acceleration on a more nominal Orbit ( ISS scenario)

Left PEG 4 and Right PEG 7 (Targeted Perigee is 15 and after the burn we had 13 )

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

Re: Space Shuttle - Bugfixes

Postby Thorsten » Tue Mar 30, 2021 5:45 pm

I am wondering why we get wrong targeted perigee values when we input the correct weight (216000 pounds for the examples above).


I see - because you corrected the weight of the Shuttle downwards at some past point and

Code: Select all
SpaceShuttle.targeting_manager.set_acceleration(0.51);


assumes that the old higher weight is relevant. That seems to be a proof of concept leftover, so what we should do is to attach the real acceleration that's computed upstream

Code: Select all
var acceleration = thrust_lb/weight_lb;


to the OMS burn target and simply use it here rather than the constant value.

That was supposed to remove the burn time/acceleration dependency from the target_manager burn computation loop; just to see the outcome.


It does not, it just increases the evolution time after the burn while leaving the burn time and duration the same.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Tue Mar 30, 2021 7:08 pm

what we should do is to attach the real acceleration that's computed upstream


Ok perfect.
I overlooked the accel value as I was blindly looking for something in ft.s² and not in m.s².
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby GinGin » Tue Mar 30, 2021 10:27 pm

I push the small commit with correct accel into the set_acceleration function, it works Ok for the Perigee.
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby Thorsten » Wed Mar 31, 2021 6:55 am

I'm guessing it would have been broken before also for single engine and RCS burns (which also have a different acceleration).

I overlooked the accel value as I was blindly looking for something in ft.s² and not in m.s².


Internally the whole code works pretty strictly in SI units only - imperial units are only computed for outputs (JSBSim unfortunatly makes heavy use of them...).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Bugfixes

Postby Thorsten » Wed Mar 31, 2021 1:12 pm

I've now successfully tested 2EO BLUE and 2EO GREEN (missed Bermuda by 30 miles for the last one :( ) - a couple of comments:

* engaging contingency guidance inevitably seems to create an acceleration spike - I've had limit and failure callouts on for just that purpose and every time got an acceleration limit warning (which suggests the instant death really is an acceleration limit failure). Could you observe what maneuver exactly triggers that (and perhaps make guidance kick in somewhat less agresssively)? It does seem weird though...

* the whole abort boundary computation does not seem to be repeated for the changed weight if I add a payload via the menu, aka just start the default mission and configure my Shuttle on the launch pad. This we should probably do, similarly if we change the target inclination using the menu.

* lofting of the trajectory worked very nicely, but didn't seem to drive the ADI needles - perhaps we should forward that also to the ADI?

* resuming from HORIZ SIT to MM 603 didn't work, I just fixed that, a simple omission...

Otherwise the aborts work rather nice, BDA targeted using some prebank and manual steering, rather crushing g-forces and a hard entry - I thoroughly enjoyed both tests.

I've also noticed that standard callouts terminated when the abort was initiated - nicely done.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Thu Apr 01, 2021 9:10 am

Could you observe what maneuver exactly triggers that (and perhaps make guidance kick in somewhat less agresssively)?


Sure, I will have a look into that. I am out of the computer for a week at least. Do you remember in which axes was the drag spike ?

the whole abort boundary computation does not seem to be repeated for the changed weight


There is not (yet) a weight dependency for the abort boundaries ( just Inc, and Vi for redesignated ones)
Weight is based on a 250000 lbs ish Shuttle after MECO ( 35000 pounds payload by taking into account the oms used for oms assist ).


perhaps we should forward that also to the ADI


Indeed, well spotted. I added the ADI Errors for RTLS and TAL but not for the contigency aborts .



Otherwise the aborts work rather nice, BDA targeted using some prebank and manual steering, rather crushing g-forces and a hard entry - I thoroughly enjoyed both tests.


Nice, same for me.
That’s really entertaining to go that deep in abort simulation .

The automation of ECAL/BDA part with energy/weight guidance is on my to do list for post stable dev.
I found some tables that will extend the E/W tables from 120 Nm up to 200 Nm.
That will allow us to have an efficient energy management between Nz hold and Taem interface. And a greater chance to make it to an ECAL site .





Concerning the REI peg 7. I found that below 10 mn for tig ( supposed to be 180 degrees from landing site ), REI is becoming quite coherent .

To not go into heavy things before stable is released , I was thinking to a few points.

1) Eventually the correction for the distance travelled during the burn in Nm : burn_time * Vt * 0.00016

2)A help message saying that above tig - 10 mn, the peg 7 REI might be not relevant and a «  please use peg 4 or Leo tool for better accuracy »

3)A slow update function ( once to twice per minute ) to update the REI if peg 7 is loaded and Tig is more than 10 mn away from met
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby Thorsten » Thu Apr 01, 2021 2:45 pm

To not go into heavy things before stable is released , I was thinking to a few points.


Eventually we'll add a function to the targeting manager to return the intersection point with 400.000 ft also for PEG-7. For the moment we don't need to do anything because the only plausible way you got PEG-7 values to enter is via LEO targeting or via MCC - both will deliver you fine into a valid solution.

You absolutely should not use the MNVR EXEC page to do entry targeting aboard the Shuttle...

Do you remember in which axes was the drag spike ?


Can reasonably only be a lateral axis, usually these things are too hard gains for the gimbals (at least that was the problem with the powered pitcharound).

I've been doing some tests with the carrier aircraft today:

* ammonia boilers need to be ON - I've fixed that
* the CWS low energy messages should probably be suppressed as long as we're connected with the carrier as they're meaningless when not in free flight

So mostly nuisance, nothing serious...

@wlbragg: I'm seeing an O8-covers object not available for animation error - seems like some renamed mesh part (?) - can you check please?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Bugfixes

Postby wlbragg » Thu Apr 01, 2021 3:03 pm

I'm seeing an O8-covers object not available for animation error

Oops, I remember hiding them in the blend file when working on the new O8 switches. I'll fix them and push later today.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7587
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Bugfixes

Postby GinGin » Fri Apr 02, 2021 3:18 pm

Eventually we'll add a function to the targeting manager to return the intersection point with 400.000 ft also for PEG-7.


Ok, even better.


You absolutely should not use the MNVR EXEC page to do entry targeting aboard the Shuttle


I agree. I use peg 7 inputs with Leo tools data’s when iterations are over 50 ( in sim peg 4 limit).
That was more a help message for beginners troubleshooting thing.
But you are right , Leo tool /peg 4 / MCC deorbit are the methods to deal with OPS 3


I've been doing some tests with the carrier aircraft today


Noted for the nuisance alarms, we can deactivate them when not ungrappled from the Jumbo Jet.
I never try it. I will give it a try overhead Edward :)
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby GinGin » Sun May 02, 2021 3:22 pm

I got a few returns about an error at loading with the Stable release over the past year (previous Shuttle stable or current one // FG version 2018 or latest stable).
I thought it was linked first to a low RAM and initialisation problems ( < 8 Go)
But it seems to happen on some higher rigs also.

Would you have an idea ?

Image



@EatDirt: I remember you had that one in the past .

May 2020, do you remember how did you get rid of it ?
Hi Gingin,
I was trying to test your fork, but with 2020.2.* a lot of errors pops out and it crashes on some oms_hardware thing. A lot of warnings pops out as well.
Dunno if you have done your testing under 2018.* or 2020.*, or if this is just me!?

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

Re: Space Shuttle - Bugfixes

Postby Thorsten » Sun May 02, 2021 6:30 pm

Would you have an idea ?


I'd do the obvious and check oms_hardware.xml line 974 whether there is a function with more than one argument.:D
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Bugfixes

Postby wlbragg » Sun May 02, 2021 8:55 pm

See, now that's genius! :-)
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7587
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 2 guests