News The Space Shuttle for Flightgear 3.6

[Thorsten]

Not sure if it makes sense that way. Alone because before you would need this, the five center displays would have to fail first.

We are modeling something with a high degree of redundancy built in. Truth is, I don't know if the IDP does this or not, but it begs the question what would happen otherwise if you'd select DPS MENU via the edgekeys on every MDU. My guess is that you'd see duplicated displays because each IDP feeds 'its' DPS page to all MDUs at the respective port, but it's equally possible that the screen blanks.

But the idea with the Auroras is nice, I wonder if a rendering client for Orbiter could also do that.

Sure - as far as I know, DirectX and OpenGL aren't that different in the algorithms they use, it's just on the level of syntax.

The aurora is basically painted on an otherwise transparent cylinder going through Earth as a projection surface

Vertex shader is basically a pass-through:

https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Shaders/planet-aurora.vert

Fragment shader takes the desired visual characteristcs as uniforms and paints (knowing the geometry of the projection cylinder in model space):

https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Shaders/planet-aurora.frag

It calls my GLSL noise lib for 2d Perlin noise:

https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Shaders/noise.frag

If you have a DirectX shader savvy person around, it should be easy to port.

 

[Thorsten]

The DPS screens miss the IDP number and the coloured bar for the controlling keyboard.

No longer...

Some love for the MEDS layer was pleasantly easy to do - I really can't take much credit for that, we have a wonderful 2d rendering API called 'canvas' for things like displays, so internally FG creates the display just like the Shuttle - the DPS content is just rendered into the MEDS frame via canvas compositing (and the page-specific DPS content inside a general DPS mask). So to edit colors, layout and insert the box and keyboard bars was some 45 minutes...

Also, the first MEDS displays are arriving and being wired up with the sim:

(here's a test of a He regulator failure with subsequent automatic shutdown of the central engine)

 

[Urwumpe]

Some love for the MEDS layer was pleasantly easy to do - I really can't take much credit for that, we have a wonderful 2d rendering API called 'canvas' for things like displays, so internally FG creates the display just like the Shuttle - the DPS content is just rendered into the MEDS frame via canvas compositing (and the page-specific DPS content inside a general DPS mask). So to edit colors, layout and insert the box and keyboard bars was some 45 minutes...

Yeah, we need to do this ourselves right now in SSU directly to texture (similar to a canvas in case of the drawing functions, but the drawing code is called for every MFD refresh), which is a major PITA in terms of maintenance and performance. Also the ad-hoc architecture behind is a major annoyance since presentation and business logic are not separated, but part of the same classes - every OPS needs its own drawing code, even OPS that use the same static critical format data and only needs new static or new dynamic data.

Even the Real One solved this better with 1970s technology - but a replacement of the MEDS drawing code is already scheduled for the next release of SSU.

 

[Thorsten]

Hm, out of curiosity - may I ask how technology sharing works between addon developers? I'd imagine virtually everyone working on a spacecraft has the problem of rendering a display. SSU at least is LGPL, so the licensing aspect should be unproblematic.

I usually try to generalize things and push them straight into the mainline code whenever this makes sense - which sometimes gives this feeling of spaceflight creating lots of spin-offs. I originally wrote a thruster flame GLSL shader to get the SSME exhaust plume widening as a function of ambient pressure, but I made that xml-configurable - now it's become the standard tool for military jet afterburner flames and some people figured out it can also be used for vapor streaks in high-g maneuvering, something I've never thought of.

Is your work picked up /considered for mainline development at all, or does this just not happen?

 

[Urwumpe]

Hm, out of curiosity - may I ask how technology sharing works between addon developers? I'd imagine virtually everyone working on a spacecraft has the problem of rendering a display. SSU at least is LGPL, so the licensing aspect should be unproblematic.

Well, depends on how formal you want it. Usually it is a matter of "here, take this code snippet, it might solve your problem". We aren't very formal here. If its open-source without any license, it is usually a matter of just asking politely.

SSU essentially started out like this, there was an add-on, which had an open source code and somebody improved something on this source code and released a new fork/add-on of this. And then we decided to join this into a full open-source project, with the question of how to license it, or how to let people outside the core team contribute.

 

[Thorsten]

Thanks.

My question wasn't so much about license but about, well, let's say collaboration. Since everyone needs displays, it could make sense to just code a display rendering module which everyone uses for instance so there'd be no need to share any code (or to be even able to code). But you answered that on the side.

We're strictly GPL - which sort of makes sense with commercial applications involved. Also, I've come to appreciate the virtue of work not being lost in case a contributor moves on to something different (or dies) and you can't ask any more. And of course the Linux distributions also take licensing pretty seriously, so there's some effort in content auditing for license complicance done.

 

[Thorsten]

Proximity ops with semi-realistic state vector management is slowly coming into shape... I'm fairly proud of that one since there's a holy mess of coordinate transformations involved in maintaining not only the proper state vectors for the approach and docking but also approximations for all the error sets for the propagated, the filtered and the measured state.

Approaching ISS pointing orbiter -z direction towards the station.

SPEC 33 shows the approach parameters - (list below SV SEL) for instance range (RNG) and approach rate (Rdot).

However, this is based on internally propagated state vectors for the Shuttle and ISS which may or may not reflect the real state of affairs, so we'd like to be sure. Now the Ku-antenna is added into the fray, providing actual measurements for the range, approach rate, inertial angular position in the sky and apparent angular movement:

It becomes apparent that measured range differs from propagated range and also there's some velocity drift. By switching the filter to use the radar ranging data we can provide information for a filtered state vector characterized by the various residuals displayed in the lower half of the screen.

The filter could now be used to be displayed in the approach data column rather than the propagated data, or it could replace the state vector if we believe it to be better.

This is probably going to drive the average user nuts, so it's possible to switch the sim to perfect navigation. But it's instructive to deal with all these navigational problems in a semi-plausible way.

It's also possible to dock and undock from the station now (only one docking port supported) and also (not advisable) to use the RCS to yank ISS around. As you can see, for flight testing I'm currently working with the coarse mesh found on the NASA 3d model site, but I wonder if anyone here would be aware of a GPL compatible textured version of ISS?

 

[Donamy]

Looks like you're in need of a space station.

 

[Thorsten]

Quite so - as I said:

As you can see, for flight testing I'm currently working with the coarse mesh found on the NASA 3d model site, but I wonder if anyone here would be aware of a GPL compatible textured version of ISS?

 

[Thorsten]

It's not a visually very appealing feature yet (and a bit difficult to recognize since the stars don't appear very bright - you'll have to click to see the fullsize image I gues) but it's a working demo for a COAS procedure.

If you look carefully, you can see the constellation Cassiopeia in the center, and the aiming point of the HUD is centered at Shedir (alpha Cas) - and executing the 'attitude reference' function correctly outputs that we're aiming at Shedir to the console. Whereas aiming at Mirphak (alpha Per) identifies that star.

Dot product of current pointing vector with stored pointing vector then gives the quality of the COAS attitude reference.

This is way cool, since reading how the COAS system works, I've always wanted to have that feature for the Shuttle

 

[Thorsten]

Impressions from a test flight.

(More pictures here. What can I say - I love spaceflight...)

 

[indy91]

I should give your Space Shuttle a try. The SSU guys have to hurry up with development, before Flight Gear suddenly has a more realistic Space Shuttle than Orbiter! :lol:

 

[Thorsten]

Take with a grain of salt because I've never tried the SSU, my knowledge of it come from skimming over the OPS manual (V 3.0).

I had the impression that the philosophy of development is rather different. SSU seems to aim to re-create the Shuttle missions with great accuracy, FG aims to re-create the Shuttle as a spacecraft with great accuracy.

For instance, I couldn't find much about systems management in the SSU manual. Which is usually boring of course - the electrical system runs with minimal intervention if all goes well and you can just display some plausible voltage numbers everywhere without taking away from the experience of flying a historical mission.

If you're interested in the spacecraft as such, it's different. To get voltages and power consumption changed whenever an electrical system is switched on and to model how power consumption is shared across fuel cells dependent on how the bus tie switches are set is, frankly, a bitch, and it gets you back to pretty much the same numbers you had before if all goes well. But it does allow you to fail a fuel cell, a circuit or similar and to see how the Shuttle responds. What do the various voltages show in this case, how do they reflect problems, what do you need to do to fix these problems - that's where the FG development focus is.

Another example is thermal management - there's close to 20 primary unique temperatures simulated by solving radiative balance and heat conduction equations. There's another 20 temperatures derived from those, so almost every temperature reading you can conjure up in the systems management software has actual meaning and will change when you operate heaters, change attitude with respect to the sun, run equipment or modify the freon flow. You can do things like run an APU for 30 minutes and observe the residual heat leak into the aft fuselage to be picked up as a minute temperature increase of the neighbouring APU thermal sensor, even if that APU isn't running.

On the other hand, you can not lug modules into orbit and gradually assemble ISS that way - that's not what FG is for. While you can fully configure orbital DAP gains and deadbands in SPEC 20, I doubt the current defaults are particular realistic for any particular mission as they're a bit wasteful. While you can launch on autopilot, the guidance algorithm isn't particularly good (I just did it in two afternoons as an exercise whether I could) - the focus is really on piloting the Shuttle, which always has been possible in reality, but was never intended to be the default for real missions.

So there's a question of what kind of realism you're looking for, and I think it's not simply a question of 'more' realism.

 

[Urwumpe]

For instance, I couldn't find much about systems management in the SSU manual.

We have a manual? :blink:

Actually, the design philosophy is not so much different, but what makes our job a bit harder is that we also want to support different space shuttle configurations. Including configurations that never flew. Including GSE for these configurations that was never used (Like SLC-6)

And then wrap this around the long-term goal of also displaying the re-usability of the space shuttle in SSU by allowing flying multiple missions with multiple orbiters in a single scenario/campaign, which again means that some direct solutions for a problem to just simulate the spacecraft are not working out.

We have not really chosen the easiest way to make a Space Shuttle, but we had to be a bit more distinct, because nobody of us wanted to make a second Shuttle Fleet add-on. If we would be just doing what another add-on can already do, what would be the gain for the community?

Also development for SSU is a bit slow-paced after 8 years... I have spent maybe 20 hours into coding SSU this year and 40 into researching. Call me lazy, you would see me agree.

 

[Thorsten]

I was under the impression that is your manual... correct me if it's not.

 

[Urwumpe]

I was under the impression that is your manual... correct me if it's not.

There is no SSU manual. <-- Irony intended.

You are really among the few people who noticed it. :lol:

 

[Thorsten]

Sorry, I ain't good in parsing irony in the web. Works too different in different countries unfortunately.

Do I detect some past experiences with users trying to operate a complex machine without looking into the instruction manual?

 

[Donamy]

Ding ding ding !!!! We have a winner.

 

[Thorsten]

Plenty of detail work on RCS hardware and control logic.

The newest addition to the avionics is the RCS page (SPEC 23 - mostly working)

RCS thrusters now can exhibit both fail-off (thruster refuses to ignite despite being commanded to do so) and fail-on (thruster remains on despite getting a command to shut down).

A thruster that fails on needs to be de-activated by cutting the propellant flow, and to avoid the problem from re-occurring, it needs to be de-selected in the management software, otherwise it'll just keep going next time.


The RCS wraparound roll control is also coded now - here's the Shuttle after a two engine failure rolling under RCS - feels a bit weird to fly, but works fine.

Same works for single engine OMS burns.

There's now also support for something that probably comes naturally to orbinauts - the ability to use a mission file. Currently the mission file allows to

* set configuration and payload
* i-load ascent guidance targets, TAL sites, automatic ET sep and propellant dump as well as an OMS-1 burn
* to specify the rates, deadbands, pulse durations etc. for the orbital DAPs
* to specify probabilistic component failures for MET points

We're hoping to publish another milestone for the next FG release about a month from now.

 

[Thorsten]

Adding the avionice support for abort procedures - here's the brand new RTLS TRAJ 2 DPS page:

Incidentially, this is now screen number thirty of the original avionics that's supported - the list also includes lovely useless items like RM ORBIT (SPEC 25) which is basically a fancy way of checking whether your joystick is connected to the sim and gives proper commands.

For anyone interested, the full list of currently supported pages is on the FG Wiki.

The Shuttle can now fly the powered part of a 2-engine TAL to an i-loaded site on autopilot once the TAL is called, and there's full support for OMS propellant dumps (both with RCS interconnect and without) via SPEC 51.

Dumping OMS fuel through the OMS engines and 24 aft thrusters is a lot of fireworks:

The RTLS is still a bit too dynamic to be handled by an AP, dependent on just when an engine cuts out, there's a relatively wide dispersal of possible trajectories - though it's definitely the most interesting abort to fly (you don't often fall into the atmosphere with a vertical supersonic velocity...)