Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby Thorsten » Tue Apr 26, 2016 6:31 pm

I actually don't think I'll write an entry autopilot any time soon. I simply don't have the time for the required test flights.

It's not technically hard - the Aerojet DAP can hold attitude precisely and crisply responds to rolls - so it's just a question of feeding it the desired roll angle as a guidance input. Using an additional PID layer, it can probably even adjust bank angle to hold an hdot target.

The issue are all the parameters of the thing, making it crisp but not overcorrecting, compensate for the lags in the system and prevent integrator windup and oscillations, setting good hdot targets based on how far we are from the nominal trajectory, make decisions how quickly we need to compensate for what amount of deviation when - all the stuff which is fairly easy to do 'by eye'.

Someone just has to create a set of such high-level decision parameters, then fly an entry, adjust and iterate the scheme,... and I simply don't have the time (nor the inclination to spend it for something that I don't really find interesting in the first place).

I'll be happy to help if someone else wants to try - it sure is a fun project, and you're guaranteed to learn a lot about the entry process itself and nested PID controllers in general. It just takes patience and persistence.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby amalahama » Tue Apr 26, 2016 11:15 pm

Well, the control code is reasonably well structured (I actually went quickly through it) but the problem itself is not that easy; the amount of energy loss during one roll reversal should be estimated, so the amount of roll is adjusted on demand. I don't know if actually the shuttle did the estimation in real time though, or the roll reversal was pre-programmed in advance.

If you don't expect to get into it for the time being, I will have a look in the future when I get a bit more of free time, I can barely fly the shuttle now :?

By the way, I've seen that JSBSim can be executed standalone. Is it possible to test automatic trajectories in this mode and run the simulations faster than real time?

Regards!
amalahama
 
Posts: 149
Joined: Mon Mar 28, 2016 10:54 am

Re: Space Shuttle

Postby Thorsten » Wed Apr 27, 2016 9:18 am

By the way, I've seen that JSBSim can be executed standalone. Is it possible to test automatic trajectories in this mode and run the simulations faster than real time?


While the Shuttle FDM is 'clean' in the sense that it could go through JSBSim standalone, the systems modeling is not (it occasionally uses properties outside the JSBSim subtree) and the high-level GNC systems frequently use Nasal.

So it's not clear whether this helps so much, historically I don't think it has been used much for most FG JSBSim aircraft. You'd have to do a substantial effort in JSBSim scripting (and I'm certainly not an expert there).

the amount of energy loss during one roll reversal should be estimated, so the amount of roll is adjusted on demand.


Sorry, you lost me.

* 'Vertical distance' to the nominal trajectory in (range/velocity) space is the input for a hdot target (the nominal trajectory represents about a 70 m/s sinkrate, so if you're above it, you approach it by setting the target to, say, 100 m/s or 150 m/s) and reduce this target as you get closer.

* After hdot capture, hdot can be managed by a PID controller with bank angle - response of hdot to change in bank angle is reasonably fast.

* A bank angle target can be fed to the Aerojet DAP via roll channel input and held via another PID

I don't see where I need to estimate energy - implicitly that happens by comparing actual trajectory with nominal trajectory, but that's trivial to do.

The actual roll reversal then needs to suspend hdot hold controllers till the attitude has reached a roll of the opposite sign. The maneuver is commanded every time Delta Azimuth exceeds limits.

* after the reversal. and hdot re-capture has to be done with careful prevention of integrator windup

* (and if one is really ambitious, a +-3 deg pitch angle modulation can be used for fast hdot control)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby wlbragg » Wed Apr 27, 2016 8:31 pm

Two things,

ISS Docking Scenario
I finally was able to run this by changing line 2167 stages.nas from 2.0 to 5.0. That was just a stab in the dark but worked. So you might want to consider changing this if it isn't causing another issue I am unaware of. 5.0 might be able to be shaved down if you think it needs to be as low as possible, I can test and see where it breaks if you consider changing it for us cpu challenged folks.

Persistent Data
I have not been able to get "automatically use earthview" in Space Shuttle/Simulation Options to persist between sessions, do you know if it is programed to be persistent? If not, may I? I haven't looked in set to see if this is already being done so I don't know if this maybe is just my problem or not.

If there is a list of items you want persistent that currently aren't, let me know or we can discuss it.

I just noticed "automatically use earthview" doesn't activate being already inserted to altitudes, like the ISS simulation, can we make it also cover those scenarios.

Something else, why after a certain amount of time am I getting some kind of landing site weather conditions audio broadcasts?
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle

Postby Thorsten » Thu Apr 28, 2016 5:51 am

So you might want to consider changing this if it isn't causing another issue I am unaware of.


Feel free - there's not going to be an issue, I had it on 10 during development and only set it to 2 late.

I have not been able to get "automatically use earthview" in Space Shuttle/Simulation Options to persist between sessions, do you know if it is programed to be persistent?


It is since two weeks or so, and works now here. But FG saves the persistent properties separately for each *-set.xml, so if it was selected in the launch scenerio, it is not in the on-orbit scenario.

Also, the on-orbit scenarios don't check upon startup whether this is selected - we need to add this if it's wanted (it probably is...)

If there is a list of items you want persistent that currently aren't, let me know or we can discuss it.


This would mostly be simulation option choices - actual vehicle state vector data I want to tag specifically when a command to save the state arrives, not on shutdown.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby Thorsten » Fri Apr 29, 2016 6:18 am

Some promotion for FG and the Space Shuttle project on Flightsim.com.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby Johan G » Mon May 02, 2016 7:17 pm

Nice article. :)
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Space Shuttle

Postby bugman » Mon May 02, 2016 8:19 pm

It is a great article! For future reference, it has been backed up on the Internet Archive.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Space Shuttle

Postby Hooray » Mon May 09, 2016 6:02 pm

https://sourceforge.net/p/flightgear/ma ... /35074660/
Thorsten wrote:the Shuttle has the most complex avionics of any FG
plane, showing 9 screens often with dozens of properties to be read. In
comparison, the avionics of Vostok-1 is modest.


Referring to your comments on the devel list, since we've had the same, heated, debate on the forum:

As you know, "avionics" is not just about the front-end stuff (what we are commonly referring to as MFDs), and the degree of back-end modeling you ( the whole shuttle team) have done is certainly unprecedented, but since you specifically mentioned the number of "screens": I have no doubt that the shuttle has the most number of active Canvas screens, but its visual part of the avionics (the representation on-screen) is rather "simple" compared to other MFDs; i.e. you mentioned number of properties to be updated - those are usually "just" OSG text nodes (there's a 1:1 mapping to existing OSG code), whereas most airliners will typically need to retrieve dozens of properties to animate certain elements using a combination of timers and listeners, which will usually map to more complex, non-OSG native, elements - e.g. Shiva/OpenVG paths.

Personally, I would still consider the extra500/Avidyne Entegra R900 avionics to be most complex in terms of workload caused (property I/O) and data management required, which isn't intended to downplay the shuttle effort (hey, it's a much older "aircraft") - but I don't think that "avionics complexity" is a function of number of screens displayed or properties fetched, even when we restrict it to just MFDs, i.e. visuals.

Part of the reason why the extra500 is/was (haven't checked in a while) such a resource hog is indeed the way its massive display is organized and the way it is updated - while some things could certainly be optimized, the typical shuttle display will have more or less a 1:1 mapping from a sprintf/getprop() call to a setText() equivalent which maps to OSGText nodes, in the case of most modern MFDs, i.e. those on the extra500, but also the PFD/ND on an airlienr, that is no longer the case - which I think you can see when looking at some of the Canvas.Path-heavier "pages", or the trajectory map.

(not trying to debate, just sharing my perspective ... :lol: )
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby Thorsten » Tue May 10, 2016 6:52 am

but I don't think that "avionics complexity" is a function of number of screens displayed or properties fetched


The workload is certainly a function of the number of screens (unless you can assume have duplicate screens, in which case you can cut it by re-using a canvas or using a data provider).

Creating the property structure by simply copying it turned out to be the largest drag in setting up a canvas display.

whereas most airliners will typically need to retrieve dozens of properties to animate certain elements using a combination of timers and listeners,


If you need to do that, you're probably doing something wrong, because to completely animate an element in 2d, you need 2 translation values, one rotation value and 1 scale value maximum. If you fetch more than four properties for the animation of a single display element, you're using the wrong output of whatever system you try to display. Given how expensive property getting is, re-structuring the input for your displays will likely speed you up quite a bit.

In contrast, if you have a page that displays 90 data values in text, you actually have to fetch all 90 of them. With 9 displays open, that's 810 properties to be fetched and then to be written so that canvas can display them. If you try that per frame, you'll see quickly why it doesn't work.

The actual amount of data displayed on modern avionics is small, because designers realized since the Shuttle days that displays crammed with values are hard to parse - a display needs a condensed message with limited information merged in an easily-parsable way.

Of course there needs to be an information merging and representation stage which the Shuttle doesn't have - but if you put this into the display code itself... see above. Fetching dozens of properties when all you need is four pre-computed ones is a bad idea.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby Thorsten » Thu May 12, 2016 3:48 pm

Personally, I would still consider the extra500/Avidyne Entegra R900 avionics to be most complex in terms of workload caused (property I/O) and data management required,


Afterthought - it sort of depends on what you consider part of the avionics still.

For instance, the Shuttle code does not get a free ride from FG but needs to perform pretty much all GNC tasks itself. While aircraft APs are typically busy managing instantaneous state (fly ILS glidepath and adjust throttle to match airspeed targets), the Shuttle needs to do guidance for ballistic trajectories.

For instance, closed loop TAL guidance needs to predict where the Shuttle would hit the ground if thrust would cut right now (i.e. fast-forward the next 10-15 minutes) to determine the MECO target. That's a significantly more complex challenge than manage instantaneous state. You never need to compute 10 minutes ahead to stay on a glidepath - knowing the deviation now is essentially enough to determine your actions.

The avionics needs to manage pointing vectors and associated orientation angles in five different coordinate systems (body, FG world, LVLH, JSBSim inertial, fixed inertial) to feed the attitude displays - an airplane can just retrieve pitch, heading and roll from FG.

OMS burn logic can fast-forward the orbital trajectory around half the world, then simulate the effect of a burn specified in LVLH coordinates (which are different here and there) and predict how the burn will change the orbit.

So the associated display code may be simple and just involve a handful of numbers - but to get these numbers isn't cheap at all.

I guess I stand by my statement - powered ballistic guidance is quite a different beast from what airplanes do.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby Hooray » Thu May 12, 2016 4:02 pm

So the associated display code may be simple and just involve a handful of numbers - but to get these numbers isn't cheap at all.

I guess I stand by my statement - powered ballistic guidance is quite a different beast from what airplanes do.

absolutely, I don't disagree with that, but I specifically responded to your emphasis on the visual representation of the avionics (i.e. the MFDs themselves), which is why I quoted your statement, where you pointed to the number of screens to support your case :D

It goes without saying that doing something 9 times instead of just once it is likely heavier in comparison, but that was never the point, I was specifically referring to the nature of the avionics/displays, i.e. mainly text properties vs. animated Canvas Paths, especially given that text properties are directly mapped to Osg::Text, whereas the Canvas path stuff is "2nd class" to OSG in that is an external library (Shiva), that OSG not really aware of, so it simply cannot make certain assumptions/optimizations, unless it is provided with annotated classes telling it to do so.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby Thorsten » Thu May 12, 2016 6:20 pm

It goes without saying that doing something 9 times instead of just once it is likely heavier in comparison, but that was never the point,


It was _my_ original point on the mailing list because I was after the actual performance footprint running all systems Vostok vs. Shuttle - that includes systems computations, guidance, feeding and rendering nine displays and all the mesh and effects.

Personally, I would still consider the extra500/Avidyne Entegra R900 avionics to be most complex in terms of workload caused (property I/O) and data management required


Okay, I've given you my numbers - in an extreme case, I need to read (and canvas later write) some 800 properties for one screen processing cycle. Part of those trigger unit conversions, mappings to strings,... A small subset goes into translating, rotating and scaling line elements. My experience is that property reading and writing is usually the most expensive part - with AW I have not managed even with complex cloud setup calls squeezed into a single frame to make even a dent in the framerate or latency (not for lack of trying), but property access does it as soon as you reach ~1000 per frame.

What's the number for the extra500? And what's the necessary number (as I said above, fetching dozens of properties to animate an element where you really need four doesn't smell like good design).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby Hooray » Thu May 12, 2016 6:44 pm

Thorsten wrote in Thu May 12, 2016 6:20 pm:What's the number for the extra500? And what's the necessary number (as I said above, fetching dozens of properties to animate an element where you really need four doesn't smell like good design).


Like I said, I haven't looked at the extra500 code in a long time, last I checked it would not even start up for me - so I am definitely not in a good position to give you any numbers, or even just tell you if those observations are simply obsolete meanwhile.

If I were to look at this right now, I would overload the getprop() and *setlistener() APIs at the extra500 level, so that all calls end up using my wrappers, and then use those to instrument/sample the number of calls made, i.e. using a counter that is reset per frame/second and log that to the console.

Who knows, things may have improved massively meanwhile ... but D-LEON/D-EKEW are definitely in a much better position to come up with the numbers here and compare the visual complexity of the Avidyne Entegra R9 with the spaceshuttle MFDs.

Apart from that, it is possible to dump the property-tree representation of the Canvas to a file and use the sheer size of the tree, and number of child nodes as a figure - but overloading getprop/_setlistener should be much more reliable to determine the actual property throughput

Another potential metric might be property tree tracing against /canvas, if that still works: http://wiki.flightgear.org/Command_line ... ng_Options
Code: Select all
--trace-read=property        Trace the reads for a property; multiple instances can be used
--trace-write=property       Trace the writes for a property; multiple instances can be used


That should give us a pretty good ballpark figure for any Canvas-based aircraft, including the shuttle/extra500 - i.e. just by comparing the number of reads/writes taking place per time period
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby Thorsten » Thu May 12, 2016 7:08 pm

Okay, to summarize: I drop a comment about 'most complex avionics' in a context where total workload counts. You call me out on that using a definition of 'visual complexity' in which neither total workload (i.e. scale the number of screens out) nor avionics functionality (aka the guidance running underneath it all) counts.

I'll grant you that visually rendering a single screen modern avionics is more complex than rendering a single Shuttle DPS text page and that the rendering code needs to work more.

In terms of property access per frame, we've already passed the point where we can manage everything at once - displays are updated in a staggered fashion, only one or two each frame. I have generally taken care to minimize property reading - values are stored in Nasal variables where this is feasible.

In terms of total canvas nodes - the canvas of a display always holds all (currently 30) pages and just has 29 of them set to invisible. So it is pretty large (but pages switch and render reasonably fast, so this seems to trade memory against performace).

So both property throughput per time and canvas node size are pretty much driven by the chosen strategy to model it, not by the complexity of the avionics as such. Avionics doesn't get more complex if you drop the optimization - if we'd not stagger display updates, throughput would go up by a factor 5 but complexity would remain what it is.

But again, if your measure of complexity is the amount of things that need to be done to animate/show one single layer without considering the backend or the need to do this multiple times or the theoretical equivalent property throughput, then any modern glass cockpit is more complex than the Shuttle.

I'll bet you by any other measure the Shuttle is.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 3 guests