Board index FlightGear Development Spaceflight

Space Shuttle - Bugfixes

Discussion about development and usage of spacecraft

Re: Space Shuttle - Bugfixes

Postby Thorsten » Sun Mar 21, 2021 5:05 pm

Tests turned out that my idea was right, so the fix is now pushed... Didn't get much else done on the Shuttle this weekend, but such is life.
Thorsten
 
Posts: 12058
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

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

the fix is now pushed


The fix TAL worked ok for me, MECO speed is a bit higher and it is doable with Low Energy Logic like in your mission feedback.
All good for the droop.
Also the trajectory map works really nicely now


I pushed the Abort boundaries thing made in Nasal.
It is that commit if you want to check the new logic sanity:

https://sourceforge.net/p/fgspaceshuttledev/code/ci/c5ba57f4b3d4160b0f2a056176fc0dd1673c151a/
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby Richard » Mon Mar 22, 2021 1:05 pm

Thorsten wrote in Sun Mar 21, 2021 7:28 am:Theoretically (I haven't tried) it should be possible to do a one-time channel in JSBSim


I can confirm that a single shot channel works fine; it's been in the F-15 since I added damage and in the F-14 since I moved damage to a JSBSim system

Code: Select all
<channel name="reset-damage" execute="systems/flyt/damage-reset">
        <fcs_function name="systems/flyt/tied/damage-reset">
            <function>
                <v>0</v>
            </function>
            <output>systems/flyt/damage-reset</output>
        </fcs_function>
        <fcs_function name="systems/flyt/tied/damage-reset-flaps-main-damage-rate-manuv">
            <function>
                <v>0</v>
            </function>
            <output>systems/flyt/flaps-main-damage-rate-manuv</output>
        </fcs_function>
        <fcs_function name="systems/flyt/tied/damage-reset-flaps-main-damage-rate">
            <function>
                <v>0</v>
            </function>
            <output>systems/flyt/flaps-main-damage-rate</output>
        </fcs_function>
    </channel>


Using the <fcs_function name="systems/tied" is only necessary on older versions of JSBSim; I think since 2018.3.4 you can use the actual name and it'll still work - but the <output> I think is still required.
Richard
 
Posts: 802
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Space Shuttle - Bugfixes

Postby GinGin » Mon Mar 22, 2021 4:56 pm

@Richard: Thanks for the example, I didnt find it in the manual.


@Thorsten: I had a crash when I tried to use an automatic sequence for the RMS through spec 94

Image


line 241:

Code: Select all
if (SpaceShuttle.pdrs_auto_seq_manager.sequence_slot_array[0] > 0)



The automatic sequence that is in the mission file:

Code: Select all
<rms-auto-sequences>
  <section-defined type="bool">true</section-defined>
  <num-sequences type="int">1</num-sequences>
  <sequence>
   <num-points type="int">4</num-points>
   <point>
      <x type="double">12.0</x>
      <y type="double">2.0</y>
      <z type="double">0.0</z>
      <pitch type="double">0.0</pitch>
      <yaw type="double">0.0</yaw>
      <roll type="double">0.0</roll>
      <delay type="double">0.0</delay>
   </point>
   <point n="1">
      <x type="double">10.0</x>
      <y type="double">2.0</y>
      <z type="double">0.0</z>
      <pitch type="double">0.0</pitch>
      <yaw type="double">0.0</yaw>
      <roll type="double">0.0</roll>
      <delay type="double">0.0</delay>
   </point>
   <point n="2">
      <x type="double">10.0</x>
      <y type="double">2.0</y>
      <z type="double">0.0</z>
      <pitch type="double">3.0</pitch>
      <yaw type="double">0.0</yaw>
      <roll type="double">0.0</roll>
      <delay type="double">0.0</delay>
   </point>
   <point n="3">
      <x type="double">13.0</x>
      <y type="double">1.0</y>
      <z type="double">0.0</z>
      <pitch type="double">0.0</pitch>
      <yaw type="double">0.0</yaw>
      <roll type="double">0.0</roll>
      <delay type="double">0.0</delay>
   </point>
  </sequence>
</rms-auto-sequences>



Also, following the discussion about jsbsim channels, I had a look during Orbit to the systems where functions were running when it was not necessary.
I noticed the entry_guidance.xml is runned even in Orbit, I will add then the same execute conditions than for the ap/entry and taem channels.
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby GinGin » Wed Mar 24, 2021 11:53 am

@Thorsten: I have tried the Entry scenario you linked. Very interesting one, and a first time in Hawai for me.

It is indeed really at the limits. I dug a bit.

At Entry Interface, we have the following parameters:

flight path angle = -2.24°
Vi = 26500 ft/s
Vr = 26050 ft/s
Range to runway = 4000 Nm

A bit above the steep target line.

Image


It was actually close to a very high energy TAL.
Like suspected, the high positive hdot commanded comes from the thermal bias (263 ft/s upward commanded at maximum) and also from the drag error factor ( 188 ft/s upward commanded) due to the high actual drag rising fast like in a TAL first pullout.

Image


Path displayed was then closed to what we could have observed during a TAL.
A huge drag spike followed eventually by a comeback on nominal path reached after several phugoids.

Image

Manual input were required at the beginning, I will try it again with High Energy TAL logic ( first pullout done in manual with an AOA close to 50 °, then back to auto guidance). A kind of AOA hold phase with max thermal boundary on one side and max g's on the other.
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby GinGin » Wed Mar 24, 2021 12:06 pm

I tried the last save commits.

I had a small error with RCS valve state when resuming

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

Re: Space Shuttle - Bugfixes

Postby Thorsten » Wed Mar 24, 2021 1:05 pm

@Thorsten: I had a crash when I tried to use an automatic sequence for the RMS through spec 94


The most probable scenario for that one is a user-side input error. Item 13 expects you to do a slot assignment, if you do

ITEM 13 EXEC

the slot gets the sequence number NIL assigned, the display tries to read out and display the assigned number, discovers it is not a number and crashes.

If you do

ITEM 13 + 1 EXEC

it should display that you just assigned the sequence 1. Now, I agree that we should make it fail more gracefully than that and that the sequence indexing isn't really well defined/explained anywhere, so I'll do modifications to

* let the crash happen in the DPS command parser (that merely prevents command execution and doesn't terminate the display loop
* internally let the first sequence be [0], but display-side let the first i-loaded sequence be 1

(we could try to catch the NIL and return ILLEGAL ENTRY - but that holds for pretty much all items you can execute anywhere, most of the time we don't do sanity checks on the input).

I had a small error with RCS valve state when resuming


I tested save/resume without any problems, so the most probabe cause is that you saved with the previous code state that had less parameters and resumed with the new state that has more, so the resume function discovers the hard way that the saved state does not contain the desired parameter

(That happens every time we add items to save/resume, which is why I warn that you'll lose saved states before and try to do it all in a relatively short period of time - dependent on where in the sequence the items are added, resuming might nearly work or not at all, usually I insert new items in the end, but valves belong to valves...)
Thorsten
 
Posts: 12058
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Wed Mar 24, 2021 3:00 pm

The most probable scenario for that one is a user-side input error. Item 13 expects you to do a slot assignment, if you do

ITEM 13 EXEC


I see thanks. Indeed, I didnt load it properly at all, I will re try with the correct method, and have a look in the DPS dictionnary for the RMS display pages. I didnt remember that there were so many things about it in FG, very nice.


the most probabe cause is that you saved with the previous code state that had less parameters and resumed with the new state that has more


I deleted the saves, did a new one and try to resumed and still that error at the following line (1377)

Code: Select all
setprop("/fdm/jsbsim/systems/rcs-hardware/helium-right-rcs-valve-A-status", helium_right_rcs_A);


The right valve is not written in the save.xml, but the left valve two (line1367) above is well written in the save.xml

Code: Select all
<valve-helium-left-rcs-A type="double">1</valve-helium-left-rcs-A>
  <valve-helium-left-rcs-B type="double">1</valve-helium-left-rcs-B>

right missing


  <valve-tank-left-rcs-12 type="double">1</valve-tank-left-rcs-12>
  <valve-tank-left-rcs-345A type="double">1</valve-tank-left-rcs-345A>


It seems they are not written during save state at line 439 in save.nas

Code: Select all
var helium_right_rcs_A = getprop("/fdm/jsbsim/systems/rcs-hardware/helium-right-rcs-valve-A-status");
var helium_right_rcs_B = getprop("/fdm/jsbsim/systems/rcs-hardware/helium-right-rcs-valve-B-status");

setprop("/save/valve-helium-left-rcs-A", helium_left_rcs_A);
setprop("/save/valve-helium-left-rcs-B", helium_left_rcs_B);

var tank_left_rcs_12 = getprop("/fdm/jsbsim/systems/rcs-hardware/tank-left-rcs-valve-12-status");
var tank_left_rcs_345A = getprop("/fdm/jsbsim/systems/rcs-hardware/tank-left-rcs-valve-345A-status");
var tank_left_rcs_345B = getprop("/fdm/jsbsim/systems/rcs-hardware/tank-left-rcs-valve-345B-status");
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby Thorsten » Wed Mar 24, 2021 3:08 pm

It seems they are no written during save state at line 439 in save.nas


So it would seem...

I'm apparently getting overworked - I've been testing this with the Nasal console open, specifically looking for errors like this. No idea why it didn't show.

***

In other matters, Contingency BLUE is broken for me - I've tested two times the scenario of 2 engines failing during stage 1. During stage 1, abort is armed, throttle is increased to 109%, after SRB SEP abort is declared - and the Shuttle detonates.

My preliminary analysis is that... once again... the trajectory at this point is altered sufficiently by the FDM/guidance changes that the previous logic engages too agressively and causes g-overstress. Though it's not really clear to me why exactly that would be the case.

*sigh*

Seems whatever maneuver I test doesn't work out of the box.
Thorsten
 
Posts: 12058
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Wed Mar 24, 2021 5:12 pm

Contingency BLUE is broken for me - I've tested two times the scenario of 2 engines failing during stage 1


I didnt do those for a while. I will give them a try also to see that.





On an another matter, I managed to do quite easily something pretty nice.

After Spartan released as a payload, I wanted it to be an Orbital object to do some prox ops. I just put the correct altitude and inclination in the mission.xml for the orbital target mission file. Then correct values in the save.xml for saved orbital target parameters ( LAN / target anomaly with initial ones and met at zero)
A bit of save/ resume ( especially for the target anomaly) to match perfectly the above parameters to have some close enough state vectors and it works quite nicely

On the left just after setting up the new orbital object ( ungrappled lets say with a fast separation rate) and on the right after 2 hours of simulation and a bit of OMS burn for spacing to perform eventually another rendez-vous.

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

Re: Space Shuttle - Bugfixes

Postby GinGin » Thu Mar 25, 2021 2:40 pm

Contingency BLUE is broken for me


Main differences between Stable and Dev are:

1)Pitch schedule : minimum pitch of 40° in dev when engine(s) is(are) failed during stage 1 vs. 45° ish for Stable

2)EO Blue/ Green boundary after SRB sep: In stable it is when hdot is below 1330 ft/s // in dev it depends of inclination ( 1850 ft/s for 51.6° Inc and 1330 ft/s for 28.5° Inc)

Image

So after SRB sep, we might be now already in 2 EO Green logic and not Blue for higher Inc launch

A couple of tests

Stable Branch

Inclination 30°
Double engines failure just after lift off ---> Loss of Control after MECO
Double engines failure 1 mn after lift off ---> Nominal 2EO Blue and Bailout.


Inclination 51°
Double engines failure just after lift off ---> Loss of Control after MECO
Double engines failure 1 mn after lift off ---> 2EO Blue and Loss of control before Nz Hold



Dev Branch


Inclination 30°
Same behavior
Double engines failure just after lift off ---> Loss of Control after MECO
Double engines failure 1 mn after lift off ---> Nominal 2EO BLUE and Bailout.


Inclination 51.6°
Double engines failure just after lift off ---> Loss of Control after MECO
Double engines failure at 1 mn ----> After SRB sep 2EO GREEN as hdot was lower than 1850 ft/s and Loss Of Control a bit before Nz Hold ( Beta was around 20 degrees)

Then I brought back the 2EO Blue/Green to 1330 in contigency_abort.nas to check above situation with a 2 EO Blue
Double engines failure at 1 mn ----> After SRB sep 2EO BLUE as hdot was lower than 1850 ft/s and Loss Of Control due too early TAEM handover ( during alpha recovery)





There seems to have several things.

1)Transition to TAEM while in Alpha recovery due to low distance with RTLS site ( < 100 Nm) I will add a condition in stages.nas ( Alpha_recovery == 0 in addition of the Nz_hold == 0)

2)The early 2EO Green logic for high Inc Launches that seems to not handle as efficiently the abort than the 2EO Blue logic: We might go back to the 1330 ft/s hdot boundary (?)
I have the feeling that at the end of the 2EO blue, beta is closer to zero than during an early 2EO Green guidance

3)A much lower flight path at SRB sep that with previous guidance, I will add a specific bias in autolaunch.nas in case of 2 EO ( 50 ° of pitch minimum instead of 40 ° for 1 EO and 22 ° for 3 engines on)
That allows to have a 2000 ft/s ish hdot at SRB sep even for high inc launches, hence a 2EO blue even with new hdot boundary logic




abort is declared - and the Shuttle detonates.


I had that one time on 10 tests, very weird.
Item 4 depressed and explosion. No idea about that.
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby Thorsten » Thu Mar 25, 2021 2:45 pm

Item 4 depressed and explosion. No idea about that.


I had it two times in a row - unfortunately I had the failure messaging off, that would have spelled it out. Usually these are (spurious?) acceleration spikes which happen to trigger the 'save acceleration exceeded' condition - they very rarely also occur during RTLS pitcharound.

I've briefly considered that it was the droop condition mistakenly evaluated, but the code seems okay. I didn't have any time to test today, so it remains speculation.
Thorsten
 
Posts: 12058
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby GinGin » Thu Mar 25, 2021 3:06 pm

I had it two times in a row - unfortunately


I will try to trigger it again, very strange indeed.

I pushed a commit with autolaunch and stages.nas changes mentionned above.
For failures after 1 mn, it works quite nicely.

I will run other tests with earlier failures also


Edit: It runs ok for me now, failures starting at 30 seconds, from 28.5 to 51.6 Inc for the tests and 2EO blue
I think I saw a 2 EO pitch tables in the documentation where I found the 1EO table for stage 1, I will check that.
GinGin
 
Posts: 1417
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Bugfixes

Postby GinGin » Thu Mar 25, 2021 4:24 pm

Failures just after liftoff

For 28.5° Inc, 2EO Blue worked.

For 51.6° Inc, Hdot is closed to 1850, 2EO Blue window moves quickly to 2EO Green after SRB Sep (like 10 seconds)
If 2EO Blue triggered , it works nicely also.
If 2 EO Green triggered, it does not work as nicely. The culprit comes from the fact that between MECO and Alpha recovery, the AP does not command a zero beta condition like with Blue guidance ( 30 ° of Beta ) / huge yaw steering error guidance that is not nulled after MECO

So either we set back to 1330 fps the hdot boundary , or set a condition to null the yaw steering error after MECO in case of 2EO Green.
When I null it manually with a bit of yaw prior to Alpha Recovery, the rest is uneventfull.
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 6:55 am

In reality you can execute 2EO BLUE during stage 1 and I believe you would operationally do that. We can't easily do that inside the current guidance framework, but we could use the ARM signal to determine what abort to fly.

It seems to me one problem you describe is that we fly a GREEN abort for something that really is a clear BLUE case for the simple reason that we can't declare BLUE before SRB Sep.

Aka, the abort that should be flown depends on the failure time of the engines, not on the time we can push the button.
Thorsten
 
Posts: 12058
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 3 guests