Space Shuttle - Development

[Thorsten]

The entry/TAEM thing plus minor FDM enhancements will come in January, and I think then we can have a good testing phase before a milestone and stable release (?)

Let's aim for a release early next spring - I don't think I'll manage january with testing and manual writing, so please bear with me as I'm going to be slow still... But let's agree that we make a release first

[amalahama]

Wow GinGin the entry pages look awesome! I'm really looking forward to test them out. Now that all pages have been adapted to the new font style, I think it should become the default one

[GinGin]

Let's aim for a release early next spring

Sure, plenty of time then to test the changes and for me to update the wiki accordingly

I'm really looking forward to test them out [...] I think it should become the default one

Thanks.
It is already the default one in the dev branch.


An example of the new Entry logic.
Third line starting from left is the nominal one.
Our current Drag is 19.9 ft/s² and we are almost on the nominal path thanks to good entry interface parameters.
Hence we can use the dashed drag line (20 ) as a cue ( we have almost that) and the nominal path vertical speed at the bottom that we should have ( between -180 and -100). Guidance calculated -130, spot on.




Also, the far right line is the zero bank equilibrium one.
That means no bank to have maximum upward lift and come back from a low energy/Long range situation.

Formula for the drag at equilibrium depends mainly on L/D ratio and Speed:




And it is particularly useful now.
Back to the previous situation, the far right line for our speed matches well the forecasted zero bank equilibrium ( 10 ft/s²)

[GinGin]

I pushed in the dev branch the work I made on new fault messages.



It extends the fault messages available to the Hydraulic/APU/ Environment/Heaters/ Fuel Cells subsytems.
I will update in depth the wiki, but for now I made a sum up of the available faults that you can find there : http://wiki.flightgear.org/Flying_the_Shuttle_-_Space_Shuttle_Checklists under CWS Fault Messages

Order is alphabetical.

For example, a fuel cell fault will look like that on the CRT:



In the book, it will be written like that:
Yellow for PASS and blue for BFS fault layout



The structure of the fault message is explained in the DPS pictionnary for the Fault page




And at the end of every subsytem SCOM chapters, there is an explanation of what is lying behind the fault associated with the above messages.


I pushed also the SM system sum up displays rework with the parameter indicators ( up and down arrown, Low and High parameter values)
You will have to activate an option in Space Shuttle Simulation and Rendering Options.

SM realism on enhanced.



Implemented indicators for the SM are available there: http://wiki.flightgear.org/Flying_the_Shuttle_-_Space_Shuttle_Checklists under DPS Dictionnary SM indicators.


As I pushed the last svg file I was working on for the SM part, it will contain also some work on the entry display that will be pretty mixed up for a few days until I push entry nasal associated files. ( Entry still playable though, just a graphic display thing)




Please give me any feedback on errors in the bugfixes topic, thanks

https://forum.flightgear.org/viewtopic.php?f=87&t=35077

[GinGin]

I pushed the rest of the SM rework.



All the new display layouts are available there: http://wiki.flightgear.org/Space_Shuttle_Avionics#ORBIT_PFD

I also updated the wiki with up to date screens and new categories for educationnal links and videos: http://wiki.flightgear.org/Space_Shuttle

[GinGin]

Some news of the entry/TAEM and fdm update.

FDM

-Addition of datas for High Mach ( above 4) and High altitude ( above 300 kft) concerning the Basic Drag and Lift Coefficient (Cl / Cd)
Better accuracy for first part of entry.
Lift/Drag Ratio almost on par with real one ( 1.1 ish up to mach 10).
Below mach 4, the previous parametrization of Cl/Cd implemented by Thorsten from this article https://www.researchgate.net/publication/259900872_Dynamic_Trajectory_Control_of_Gliders kicks in and works better than interpolated datas.
Very Low energy entry ( Entry Interface up to 6000 Nm ) will be possible now, and entertaining with exotic procedures from Non Normal documentations.




-Addition of a deeper table for BodyFlap Pitch moment ( Mach, BF deflection, Alpha dependant).
That allows a better trimming of the pitch jets during first part of entry and elevons then (interesting to save RCS fuel)


-Addition of slightly improved Lift and Drag coefficient for the gear

-Addition of deeper coefficients for SpeedBrakes Lift and Drag, mach dependant now.
Shuttle is now maintaining far better 300 kts ( speed targeted for final part of approach) on a 19 ° path.

In red the new L/D ratio with speedbrakes extended ( smaller than with previous coefficients used,SB are 20 % ish more efficient)





TAEM

I finished the rework of the Vertical Traj 1 ( from 80 kfeet up to 30 kfeet)

Horizontally: Range to runway
Vertically: Altitude
Both are linear scales, no quadratic range scale there.



It took me time to find solid datas to feed well the right scale, indicating our Energy state basically.
Energy / Weight = altitude + TAS² /2g

Picture below to illustrate.

In White, triangle indicating our Actual Energy, almost matching the nominal energy for the TAEM chosen.
Sturn is the upper energy boundary // above, we would need more track miles hence some S-turn
MEP is the lower energy boundary // below, we would need less track miles hence some shedding with a minimal entry point ( a few miles shorter)
In blue, the EAS we should have if on the path and on energy

That scale is dynamical, parameters depend of distance to go mainly.


The Nose High/Low scale and triangle are useful in case of bad datas from Probes.
It is a kind of airspeed unreliable thing, where we have to fly the basics ( pitch settings pre determined to stay within a good flight envelop).

In the present situation and in case of loss of Air datas, we would have to maintain a pitch angle between -6° (red) and -19°(purple).





A quick glance if your are interested of some of the datas implemented.
There are good explanations in Thorsten manual and SCOM about TAEM Energy logic, and I will update manual/wiki with those few additions.

[eatdirt]

Some news of the entry/TAEM and fdm update.

Hi there,
I gave a try today to the TAEM scenario at KTTS with the devel version and current stable flightgear 2020.3.6

Code: Select all

fgfs --fg-aircraft=/home/chris/.Aircraft --aircraft=SpaceShuttle-TAEM --airport=KTTS

I really never recover the figures I can see on your pictures

I gave 5-6 tries and followed the AP guidance carefully (wind 7 knots max). For instance, I am arriving over the runway at around 320-340 knots, and the speedbrakes are actually retracting... I don't know what is going on, but, on my computer, the new guidance is clearly far worse than Thorsten's. I did not even manage wheels stop before the end of the runway even once, and that is KTTS

At some point, we should maybe freeze the devel and try to debug all these things that differ before making a release?

Cheers,
Chris.

[GinGin]

@EatDirt: Last updates on the dev branch are up to the SM dps rework ( check the update history on SF), I didn’t put anything new on SF about the fdm and entry/ TAEM yet.
Update above was just about what I was Currently working on.

So no new guidance logic involved in your problem , and I tried a TAEM approach with the current dev, it works ok for me like in the video I made.
You might be already High on Energy when starting the scenario.
You should specify a longitude that put you 60 Nm away from the landing site and try with sate vector in perfect mode.


I will freeze my dev stuff after the entry rework yes, but I already pushed a lot of things and I am waiting some returns on them for debugging .

[eatdirt]

Yep, it is weird, that's the standard TAEM scenario that used to work fine for me too. Things have changed though, for instance the ITEM 41 is set by default to 0, so may be there have been some changes on initial conditions that could trigger this behaviour. The speed brake retracting is also new, but it is certainly better to wait that you have pushed all your improvements before checking all this, sure !

[GinGin]

I answered in the bug fixes topic.

[Thorsten]

Let me put out a few thoughts about things that could/should be done before a release:

1) Throttle - I realize the current AP-controlled throttle is bad, because it basically uses setprop() to set /controls/throttle - which is however overwritten every time you change a physical hardware throttle setting. This prevents us from a proper manual takeover procedure as 'move throttle lever to within 5% of current setting, press takeover button'. It also prevents us from using the throttle lever to control speedbrakes.

(In my defense, I had zero experience in aircraft modeling when having to deal with this very early in the Shuttle development, and it works fine for keyboard-controlled throttle which I have - and also in my favour, I believe I've already abstracted many throttle commands issued by the AP as shuttle_main_engine[i].throttle_to() ).

So what we should be doing instead is to do what we do for other channels - separate throttle-cmd-norm from throttle-pos-norm and introduce a separate throttle-ap-norm which represents the AP-issued throttle command (normally mapped to throttle-pos-norm) from the lever position (only mapped after the takeover procedure has been executed, and mapped to SB during entry).

As far as the shuttle_main_engine[i].throttle_to is concerned that's reasonably easy, and Systems/throttle.xml is the logical point to model the JSBSim side of it, but there's (unfortunately) still places in the launch procedure where this has to be done, and then a takeover procedure as well as throttle-controlled SB can be implemented (like in most other gliders in FG)

2) Velcroed content - is there more material we should digitalize and display in-cockpit? Can anyone with experience in 3d modeling perhaps add a few creases so that it looks more papery (or would we prefer a normal map?)

3) Interaction with payloads - at some point we pondered making an ISS interior view accessible when we're docked - should we do that? Wayne had ideas about assembly - what are the obstacles, should we be doing anything? Do we have an ability to grab Hubble now - I forgot (definitely never tried)?

4) I believe the real alphanumerics displayed by the RMS position are not metric - currently however we display metric units (I originally did that for debugging purposes because the problem was tough enough without computing all offsets in my head, I just wanted to compare the FG coordinates - I can't believe no one actually spotted this so far...)

5) Probably the state save feature could be extended to store a few more things - important failure modes perhaps? (Don't say 'everything' because that's likely thousands of values - technically doable but tedious - but let's proceed with 'some').

6) More... scenarios? Failure modes? Tutorial extensions?

I expect to be able to do /some/ work in the near future, so I hope to be able to tackle a subset of this - anyone up for the low hanging stuff?

[eatdirt]

Hi Chief
for this one, I know:

Do we have an ability to grab Hubble now - I forgot (definitely never tried)?

We do not. What we can do is release it, and grab it afterwards. But, I think, we miss the part for which we grab it after a rdv.

Thanks for the head-up!

[GinGin]

I might help with the throttle thing once I will have finished current work about FDM/Entry .
I should start to push the work next week.

The save thing is interesting, I will think to what might miss when resuming a save .

For the ISS, I think Wayne was working at some point on a HD version of it (?)

Should we stick for a Stable release around beginning of Spring ?

[wlbragg]

For the ISS, I think Wayne was working at some point on a HD version of it (?)

Yeah, I have a start on it and quite frankly forget where I left off. I know there was some pretty extensive work to get it to where I wanted, but doable and still on my long term goals.

The Hubble missions were ones I really was most interested in and probably the most likely to get done in a reasonable time frame. Assembly, repair, we have some of those mechanics in place and a model organized to be able to accomplish this with a bit of work.

I never looked closely at the ISS rendezvous code, should be extensible to use for Hubble rendezvous and repair?

It seems there should be a fairly easy way to use the existing rendezvous code combined with the existing deploy code to make for a really interesting Hubble mission.

I've got tons of ideas for this, just needed some motivation.

Can anyone with experience in 3d modeling perhaps add a few creases so that it looks more papery (or would we prefer a normal map?)

Are you talking about the papers or the Velcro? I assume the papers, if so, yeah a couple random normal maps might be enough. I can look into that easy enough.

[Thorsten]

Should we stick for a Stable release around beginning of Spring ?

That'd be the plan - and the changes I mentioned are (mostly) easy and would benefit from a testing period, so I'd like to get them on.

The exception is ISS/Hubble/... extension, where I really did not know whether Wayne had anything ready already which could go on - if not, I suggest we defer that part toafter the release.

I never looked closely at the ISS rendezvous code, should be extensible to use for Hubble rendezvous and repair?

Basically since both are objects with which you interact in more complex ways, I didn't 'just' make them instances of the general 'orbiting object which you can grab' class, so ISS has extra code for docking and I don't know what Hubble has - it should be easy to add a hardpoint to grab it though, it seems odd that we can release it and grab it afterwards but not grab the pre-initialized version, they should be using the same code.

I'm not sure what you have in mind in terms of repair - as far as it happens only with the Hubble 3d model, I guess all functions can go inside the Hubble class, otherwise we have the ability to maintain multiple orbiting objects which we can grab individually, so assembly should be possible. We currently switch the valid reference using Eileen - I have the feeling there must be a software option to do this properly, but I can't recall offhand where that would be - another point to consider.

@GinGin - let me lay the groundwork for the throttle, I have a design in mind that I'd like to implement, and once that's done you can do the manual takeover procedure as well as the speedbrakes - you have the advantage that you can test whether this really works, it's pointless to properly test without a joystick