Space Shuttle

[Thorsten]

DAP CONFIG utility (SPEC 20) just joined the avionics - this is used to configure rates and deadbands for the orbital DAPs. Currently only partially functional since I need to change the AP simulation to take the properties into account:



But should be interesting to experiment with...

[Thorsten]

For those who want to explore some of the Shuttle in orbit but don't want to read through the manuals, I've started a tutorial covering MECO to orbital insertion via OMS-2 burn.

Welcome to Space

Feedback appreciated.

[wlbragg]

This is greatly appreciated!

[legoboyvdlp]

Lovely! I'll have another go sometime. Thank you very much.

[legoboyvdlp]

Man. Do you mean to say... I can do the OSM2 burn on the equivilent of an autopilot? Just by typing in some commands I can manage to do it all automatically?
*faints*

[Thorsten]

Man. Do you mean to say... I can do the OSM2 burn on the equivilent of an autopilot? Just by typing in some commands I can manage to do it all automatically?

Yes - it can be controlled almost like in the real thing - except in reality one would enter PEG-4 targets and have a timer for the burn - I haven't gotten around to implement these yet.

By now you can do a lot in orbit on autopilot - you can point the payload bay at New York and watch the Shuttle change attitude to keep th ebay centered on NY as you overfly it just for the fun of it.

Well, it still has quirks... But insertion and de-orbit burn can be done fully automatic.

[legoboyvdlp]

That's excellent. I would consider this the most advanced avionics package in FlightGear.

[Thorsten]

I would consider this the most advanced avionics package in FlightGear.

I'm curious - why?

(I don't fly airliners much, so I don't know what kind of avionics they usually come with). Technically, designing orbital DAPs is much easier than an in-atmosphere autopilot for a plane because space is a no-perturbation environment, so the DAP never has to cope with instabilities - it may be inefficient, but that's all.

I suppose in terms of raw information content (with sometimes close to 100 properties displayed) the DPS screens are sort of record-breaking (but then again, no one today would design interfaces that way any more).

[legoboyvdlp]

Well, an airliner just follows a route at a constant altitude. While the DAP may not have to cope with instabilities, I'm quite sure it is pretty complex. The DPS screens indeed show a heck of a lot of stuff, and are implemented very nicely, if you ask me.
An Airbus is the type of aircraft I am most familiar with, and all it really does is fly along a route at a constant speed and altitude. The ND may look nicer than the DPS screen, but those screens do show.... a lot.

[Thorsten]

Yeah, they do - to the point that I start being concerned about the performance impact of 100+ getprop() statements per display update...

(I suppose once we support more displays, we have to run them asynchonously to avoid peak loads during the update frames.)

[Thorsten]

Oh well, track prediction is a bitch...

I've started to work on support for entering an OMS burn target with a future ignition time - so the avionics should give you the expected changes to the orbit given the burn parameters and the ignition time (right now it shows you what you'd get for starting the burn right now).

Since the burn can be an extended time duration, I want to simulate this numerically rather than do an instantaneous change of an analytical orbit (not quite there yet...). To get sufficient accuracy, the timestep needs to be small (there's also the fact that JSBSim doesn't approximate Earth as a pointmass, so we get an intrinsic deviation on that). To compute a trajectory fast-forward with a small timestep without delaying a single frame too much means just computing a fixed number of steps per frame, then moving to the next frame.

Okay, now I get a solution for where the Shuttle will be a full orbit later (i.e. at the same position - within a hundred meters error margin) within 10 seconds computation time. Which is okay - the real avionics doesn't converge to a burn solution immediately either. So I have the future state vector - except of course in general the burn target vector decomposition in terms of Dv-components doesn't fit any more, since the future direction of 'prograde' is in general different from the current direction.

So to be able to do the apses calculation, I need to reconstruct the full future coordinate system of prograde, radial and normal vectors, decompose my burn targets into that, and then apply it to the apses calculation.

This is a mess...

[wlbragg]

Thorsten, thank you for the orbit tutorial, a bit of knowledge really make a difference.

So much fun this is.

[Hooray]

Space Shuttle

I suppose in terms of raw information content (with sometimes close to 100 properties displayed) the DPS screens are sort of record-breaking (but then again, no one today would design interfaces that way any more).
[...]
I start being concerned about the performance impact of 100+ getprop() statements per display update...

(I suppose once we support more displays, we have to run them asynchonously to avoid peak loads during the update frames.)

For the time being, it would be better not to use/update Canvas asynchronously, the underlying property tree APIs are not threadsafe - while getprop() is a read-only operation, there is no locking taking place. It would be better to extend the Canvas system to directly support a new "property mode" using sprintf-style format strings that are assembled/updated in C++ space, i.e. without any Nasal overhead, which would benefit other efforts, too - including the PFD/ND efforts, re-implementing HUD/2D panels on top of Canvas, but even pui2canvas

I have posted a follow up here: viewtopic.php?f=71&p=266721#p266721

(what you describe, should be possible to do, but using native C++ code, without going through Nasal space, seems preferable overall)

Depending on how much progress Stuart is making with HLA/RTI, another option might be having a private property tree NODE (instance) for the Canvas system, or even each Canvas - which would make it possible to update things using a dedicated thread, including even Nasal threads.

[wlbragg]

Not much feedback yet as I work through the tutorial, but I keep finding myself shaking my head mumbling, incredible!

Absolutely incredible, is there anything out there that is even close to this, besides the real thing that is?

Totally immersive.

Thank's to Richard too for the interior and panels.

I'm trying to take pictures along the way if you want any more of the internal screens for the tutorial. Not that they are needed.

[legoboyvdlp]

FWIW, I took a screeny of dumping fuel. Mind if I upload it as an illustration... and nice screenshot? Loveky work on the effects (Earthview, ALS, AND spaceshuttle)