Space Shuttle

[legoboyvdlp]

No, if you read the discussion back then, I believe this is not a bug, the behavior is now correct as discussed and you're not operating the page correctly. The discussed signal to the avionics to stop acceleration sensing is to leave the current OPS, not to compute a new solution.

Understood

To release the payload, I had to set systems/mechanical/pb-mechanical-sys1-pwr to true in the property browser manually. Not exactly sure where this switch is. It didn't seem to be in any of the dialogs, or maybe I am just a bit dense today?

Otherwise, everything has gone well - this release is extremely stable and works great!

[eatdirt]

had to set systems/mechanical/pb-mechanical-sys1-pw to true in the property browser manually

You need full cockpit view, and there are (from memory) 4 power switches for the payload. 2 of them are on the right of the power switches of the doors, named "payload bay mechanical power", the 2 you're looking for may be under the label "Payload retention logic power", straight down the aft screen, under the aft window. These 4 allow you to release all latches named "payload retention latches". The payload should be attached to the arm at that point, unless you decide doing a new kind of payload unloading powered only by RCS jets

[legoboyvdlp]

Thanks! I'll take a look shortly.

I used the dialog switches for logic power... the properties systems/mechanical/pb-mechanical-sys1-pwr and systems/mechanical/pb-mechanical-sys2-pwr in the property browser never changed ..?

[Thorsten]

You're searching for payload bay mechanical power - logic is different again (I didn't invent the layout, I'm just coding it...) They're close to the payload bay door power switches.

[GinGin]

Wiki updated for TAL

http://wiki.flightgear.org/Flying_the_Shuttle_-_Transoceanic_Abort_Landing_TAL


A question about Wiki, I can't recall how I can show the Contents with subparts like that:




I think I use the correct formatting for each part, like that :

='''From Lift off to MECO''' =

[Gijs]

Thanks for your wiki contributions! See http://wiki.flightgear.org/Help:Formatt ... ubheadings It's added automatically if there are more than four headings. The help article explains how to force one if you have four or less headings

Also note that you should preferably use two equal signs on either side for the highest heading level in your articles. The article's title is the first level (one =), so anything in the article should be lower than that. And don't make it bold (the ''' characters); wiki-wide styling is taken care of automatically.

[Thorsten]

Shuttle avionics should now use the orbital targeting class rather than impulse approximation to get HA and HP, which ought to improve accuracy for long burns. I hope I haven't broken anything else with the change (like PEG-4 fitting) - I'll still run some tests, but let me know if anything unusual happens.

[GinGin]

That looks awesome
Could you explain a bit more what are the changes?

I will test that

[eatdirt]

Shuttle avionics should now use the orbital targeting class rather than impulse approximation to get HA and HP, which ought to improve accuracy for long burns

Great!!! I'll test.

I have been playing with leo_targetting in trying to get back from HA~1300 HP~120, but I think it is hopeless, never succeeded to get a peg4 successful fit. I have also discovered that my crazy long OMS-1 burn moved the periapsis out of KSC, but almost exactly above Banjul Airport, so I may try some simplistic calculations to land there with something closer as possible to STS c1 and c2 values. If you have any advise, please let me know before I burn

Cheers,
Chris.

[Thorsten]

I don't think there's any particular reason to deorbit directly from such a high orbit (it would seem rather difficult to get the right flightpath angle...).

[Thorsten]

Could you explain a bit more what are the changes?

Internally the prediction is not done by the old code any more but by the orbital_targeting class (which is a lightweight version of LEO targeting).

Previously the trajectory was fast-forwarded to the ignition point and then the Delta v components were added, now the simulation runs ten seconds beyond the burn and then computes orbital elements, i.e. finite burn time is taken into account (come to think of it, this probably does not yet work for single engine burns...)

From the Shuttle cockpit, it should all look and feel the same, just under the hood it's different.

[GinGin]

Alright thanks. I guess it is some precious work for rendez vous implementation ?

[GinGin]

@Gijs : I completely forgot to thank you for the link
Very instructive



Playing with 2EO Bermuda for the wiki, almost spot on the numbers ( double failure around 11 k, in FDF between 11 k and 12 K, it should be no bailout ) and indeed





Even some extra energy to dissipate





No flare xD

[eatdirt]

don't think there's any particular reason to deorbit directly from such a high orbit (it would seem rather difficult to get the right flightpath angle...).

Yes, I was trying to play it with "some" rules. It was remaining only 28% of OMS fuel from the extra fuel payload I took from the beginning, so the only option was to reenter from elliptical orbit. Since I have explored out-of-the manual stuff, here a list of other funny things, and less funny bugs that have happened

1) The MCC is confused with mass estimate, the extra implicit payload being actually burnt, it reported all the time super-heavy Shuttle. No issue though, because the mass in ITEM 9 was going down as expected even after I manually refill the OMS tank! So Shuttle mass works fine even when refuelling, well done! But I am wondering, does MCC / DPS knows about an explicit payload being released? And for implicit, how does that work?

2) Very weird report in SPEC 22 in the star table, one of the star report a Delta Min of 1923 (never seen such a high number before there)


3) In OPS 3, never succeeded to get a REI, but I am not surprised with such an elliptic orbit (I had e>0.1). So I solved equations on a piece of paper up there for re-entry to know what velocity to add at apoapsis to enter the EI with the correct c1 and c2. That does not give any information on the range afterwards, neither a way to target an landing site, but for bailout, it should fixed the flightpath angle right (in spherical trivial gravity and spherical earth). Here it is:

reentry.py

4) @Thorsten, I got again (after 3 days) the bug for the burn attitude. This time, I did not align IMU at all to check if there were involved in creating the issue. Then I tried to align IMU to see it that would improve the situation (was still running S2 on G4 in OPS 3), not a change at all. Please, give me a list of things to monitor for my next flight to chase this bug, that is quite annoying
An idea: would it be possible that "pausing" flightgear is a cause, I am doing it for a cumulated tens of minutes in these long runs, so...

Then, I have followed your advice. I switched to INRTL just after OMS ignition to put the shuttle into something close to what it could be. That is quite-hard, shuttle rotations while OMS are running are very weird!
I've also anticipated that I would screw the thing during 30 seconds, so I added a velocity component to take into account my screwing time. My reentry calculation targeted something around HP=25nm, my extra burn time moved it to HP=-5, and... here we go!! That is quite some luck, especially if you see on the ADI ball in which position I was retro-firing... And, 4% left in the OMS tank.



5) I think the antenna gets stowed with the final dish orientation depending on the one at which the stowing starts, so yea, I see what direct stow is made for

6) Please, remove from the menu that thing called "Map (Canvas)", 5 minutes before reaching EI, I clicked on this menu hoping to find an airport nearby in case I could manually fly there instead of bailing out. My fg session froze totally, black screen. I am super frustrated, will never know if I could have survived re-entry, arrrrrrg!!!


Gonna fix my sadness by going back on super elliptical next time, maximal charge on the payload (still have to check what is the maximum payload weights)

Cheers.

[Thorsten]

Yes, I was trying to play it with "some" rules. It was remaining only 28% of OMS fuel from the extra fuel payload I took from the beginning, so the only option was to reenter from elliptical orbit

The region where a PEG-4 solution 'makes sense' within available propellant gets narrower and narrower for higher orbits. Since the LEO Targeting solver explores the linearized region 'close' to a solution, it will fail for too narrow regions.

You can still use LEO targeting to guesstimate a PEG-7 burn and tune parameters by hand to what you need - this is still feasible as a PEG-7 solution can be computed within a few seconds (much faster than FG anyway), so you ought to be able to get 'close' to a good solution that way (I think I used this to get the starting point for a PEG-4 de-orbit from 1200 km altitude once).

But I am wondering, does MCC / DPS knows about an explicit payload being released? And for implicit, how does that work?

The avionics knows the i-loaded initial value from the mission file, and when the OMS is firing, it computes the propellant needs and subtracts what has been spent at the end of the burn. The rest is your job - if you carry a payload, the additional weight needs to be i-loaded, if you release the payload you need to subtract the weight yourself and enter the new value (you can always ask MCC for a mass estimate though... - it'll inspect what JSBSim currently has as your mass and give you something close).

2) Very weird report in SPEC 22 in the star table, one of the star report a Delta Min of 1923 (never seen such a high number before there)

Wipe the star table? No idea what that could be... (except perhaps a variant of the attitude bug?)

3) In OPS 3, never succeeded to get a REI

Yeah, you need something better than Shuttle avionics to do this from such an elliptic orbit.

Please, give me a list of things to monitor for my next flight to chase this bug, that is quite annoying

I wish I could, but I have no idea really. Opening a Nasal console can querying the value of some variables to compare with pen and paper is the only way I can think of debugging this, but it requires quite some Nasal coding knowledge.

If it is somehow position related, you could try to do a state vector export. Otherwise you could try to save the state, and resume some other time to see whether the issue persists or not (in this way, we at least know whether it's something that happens over time or at a given position.

5) I think the antenna gets stowed with the final dish orientation depending on the one at which the stowing starts, so yea, I see what direct stow is made for

Not sure, I think there was some bit of code that made the 'normal' stow mode not work under some conditions, so that's part of the simulation (but I forgot what triggered this...) As long as direct stow works, I'm going to pretend we're doing fine here...

6) Please, remove from the menu that thing called "Map (Canvas)", 5 minutes before reaching EI, I clicked on this menu hoping to find an airport nearby in case I could manually fly there instead of bailing out.

That's what it normally does here.

I can only assume that after a few days something weird accumulates - but there's very few test data how FG behaves for sessions exceeding 10 hours (long-haul flights...) so there may be all sorts of bugs lurking we've never seen.