Space Shuttle

[Hooray]

So it requires a numerical prediction of the trajectory. This needs to be done at high temporal resolution to avoid numerical drift and hence be split across multiple frames (I'm forwarding some 5 seconds per frame). Then the calculation takes time... perhaps some 4 seconds. What I figured out today is that computing distance to target without taking the calculation time into account causes an offset of some 40 km in the result - because stuff in orbit moves fast.

Now the code latches onto the wrong solution - it gets the closest distance when the Shuttle on the rising trajectory passes right underneath ISS, rather when it reaches apoapsis and ISS comes from behind 15 minutes later. So the whole aim has to be refined.

Not sure where your computations are running (JSBSim, Nasal, C++, GLSL/effects (GPGPU)) - but if you are using Nasal to do any of this, you may want to consider using a worker thread to run/update your calculations - Nasal threads generally work fairly well, you just need to avoid using any of the FlightGear specific extensions functions or accessing/mutating anything that is updated/used in the main loop.

A worker thread can be invoked using thread.newthread( function): http://wiki.flightgear.org/Howto:Start_ ... s_in_Nasal

Code: Select all

thread.newthread( func() {
for (var i=0;i<10000;i++) {
 var j = i*i+i*i / i/2
} # for-loop
}); # newthread call


Note that you can access other Nasal variables just fine - but you would want to use a reader/writer separation to prevent race conditions (i.e. no properties) - and you may want to use one of the serialization mechanisms (mutexes and semaphores are both supported by the thread module).

This means that any getprop()-like calls would need to take place in the main thread, where you'd then put all retrieved state into native Nasal data sttructures variables, that can be safely accessed from a Nasal worker thread.

Obviously, you can pretty much ignore everything I said if you are doing computations in C++, GLSL or JSBSim space - equally, before you consider porting any non-Nasal stuff over to Nasal, it would probably make sense to use the Nasal Console to see if that makes sense or not.

In general, it is likely that a property-rule, fgcommand or JSBSim building block should be faster than any Nasal code - but Nasal code using thread.newthread() is not executed within the main loop thread (however, it does share the same GC context for the time being, so that main-thread GC pressure will also impact the worker thread to some degree).

Feel free to get in touch if you'd like to investigate using background threads in a producer/consumer fashion. Alternatively, it would also be possible to add XML/property building blocks to make these things possible using fgdata-level hooks.

[wlbragg]

Okay, I wonder if anyone will ever actually use the orbital targeting screen at all, because it's really about as non-intuitive as it gets...

Sure, just as soon as you write the instructions for it!

[Hooray]

Ideally you would visualize it in 3d space, with the orbits as lines projected around Earth and the ability to turn and zoom.

Just for the record, I stumbled across a freely-available JavaScript-based implementation of a solar system simulator: http://mgvez.github.io/jsorrery/



Note that this is basically using the same technology stack that Torsten's mongoose/Phi work is based on (DHTML, JavaScript, Canvas) - in other words, it would be possible to hook this up to FlightGear by serving this via mongoose/Phi and add objects (think satellites, spacecraft) to it using Torsten's websocket interface/remote properties: http://lab.la-grange.ca/building-jsorre ... lar-system

For some background info, see:
http://lab.la-grange.ca/building-jsorre ... lar-system
http://arachnoid.com/orbital_dynamics/

Update: I just cloned https://github.com/mgvez/jsorrery into $FG_ROOT/Phi and ended up with an "jsorrery" folder there, and I can confirm that Phi can properly serve the full thing, i.e. it can be accessed at: http://localhost:8080/jsorrery/ and is working perfectly well. Note that the whole thing took less than 60 seconds to get working. Hooking this up to some internal objects/properties should be straightforward, too.

[Thorsten]

Update: I just cloned https://github.com/mgvez/jsorrery into $FG_ROOT/Phi and ended up with an "jsorrery" folder there, and I can confirm that Phi can properly serve the full thing, i.e. it can be accessed at: http://localhost:8080/jsorrery/ and is working perfectly well. Note that the whole thing took less than 60 seconds to get working. Hooking this up to some internal objects/properties should be straightforward, too.

Nice...

You can try to instance an orbiting target on a circular orbit

Code: Select all

var oTgt = orbital_target.orbitalTarget.new(alt_above_ground_m, orbital_inclination_deg, ascending_node_longitude_deg, true_anomaly_deg);


then run it

Code: Select all

oTgt.start();


and retrieve the position in JSBSim inertial coordinates

Code: Select all

oTgt.get_inertial_pos();


and try to plot that in the application to see whether the scope and resolution is good enough.

[Hooray]

try to plot that in the application to see whether the scope and resolution is good enough.

Apparently, jsorrery has been used to plot apollo trajectories: http://lab.la-grange.ca/showing-an-apol ... n-jsorrery


Apart from that, I am more than willing to actually try adding a FlightGear object, but I need a more detailed/self-contained snippet of Nasal code, so that I don't need to reverse engineer all your code, because I still need to look at the JavaScript and Phi side of things to fetch/update the corresponding properties

[Thorsten]

Apart from that, I am more than willing to actually try adding a FlightGear object, but I need a more detailed/self-contained snippet of Nasal code, so that I don't need to reverse engineer all your code, because I still need to look at the JavaScript and Phi side of things to fetch/update the corresponding properties

orbital_target is a general-purpose object to simulate the coordinates of something in Earth orbit. There's nothing you need to reverse engineer - you set the orbital elements, you start it, and it spits out current inertial position (or lat/lon/alt if you prefer - but that's an Earth co-rotating system and probably awkward for visualization...) whenever you ask for it. You 'just' need to hook it up to whatever backend you want.

It is pretty self-contained, and you can find in in the Nasal folder of your FG installation.

[Hooray]

In case you missed it, I am not at all familiar with the terminology used for computing orbital mechanics, i.e. I literally have to use google to come up with appropriate numbers for each argument.

Thus, should something like this work:

Code: Select all

var oTgt = orbital_target.orbitalTarget.new(400000, 51.65, 162.3891, 90);
oTgt.start();

var update = func() {
var pos = oTgt.get_inertial_pos();
debug.dump(pos);
}

maketimer(1.5, update).start();


If in doubt, just provide a stub that should work, or tell me how to get a handle to the ISS you are simulating.

[Thorsten]

In case you missed it, I am not at all familiar with the terminology used for computing orbital mechanics, i.e. I literally have to use google to come up with appropriate numbers for each argument.

The point of using orbital elements is that all except the true anomaly (or mean anomaly if you prefer that) are constant (under idealized conditions - not so for non-spherical gravity...) - so they characterize the orbit, and then you can look up ISS and just read off the orbital elements to initialize it - and updating the position is numerically very cheap because all you need to do is to increment the anomaly (as the others don't change).

Your code should do the trick, yes.

[bugman]

Hi,

I was wondering if I could get some feedback from the shuttle team about the aircraft infobox used on the Space Shuttle wiki article. I am currently playing around with a sandboxed aircraft infobox template on steroids. I have added an example to the test template for the Space Shuttle. Any shuttle or spacecraft related suggestions would be appreciated. Is there anything space related that could enhance the aircraft infobox?

Cheers,
Edward

[Thorsten]

Hi Edward,

good work in general - expanding the info box is a good idea. and I like the concept of the repository icon on top to see where a plane is found.

I personally find the icons for 'Spacetrip ready' and for 'visit devel repository' together with the labels 'Ready' and 'Development' not really intuitive.

I was also wondering whether it'd be possible to make an author summary (say, a list that expands when you click on it) rather than what is in for the DHC6 for long author lists. The top level could then just read 'PAF team' or 'Shuttle development team' and be detailed on request.

In analogy to 'Rembrandt ready' in principle you could also make an 'uses ALS interior effects' icon if you like.

As for especially space related things, I don't think we have enough spacecraft to really try to make a meaningful distinction. You could potentially ask for the quality of orbital guidance for instance (this is something completely absent from plane ratings and also poorly supported by FG) - but with two real orbiting craft, how much sense does this really make? You could also make a distinction whether the stage separations are fully animated or whether discarded stages just disappear (another thing that's not usually rated for aircraft). You could ask for payload support (where applicable) or spacewalk capability.

Perhaps more thinking aloud at this point...

[Thorsten]

Not sure where your computations are running (JSBSim, Nasal, C++, GLSL/effects (GPGPU)) - but if you are using Nasal to do any of this, you may want to consider using a worker thread to run/update your calculations

I'm not sure whether this would do for the particular problem, because the time duration of the calculation needs to be established to good precision.

One issue I had been finding out the hard way is that Nasal timers aren't exact enough for the purpose if you just specify a duration - you have to run them per frame to get it right. So I'm not sure how well a thread running outside the main loop could be made aware of the passage of time inside the main loop, or with what precision that could be established after the fact.

I'm (unfortunately) discovering a lot of unexpected numerical issues here (orbital speed just magnifies things - it's not usual that if you're one second wrong you're off by 8 km).

[Hooray]

right, that is basically because of two things: 1) there is no such as thing as "Nasal timers" - it's a separate subsystem ("events"), which is part of SGEventMgr - whenever SGEventMgr::update(double dt) is called, there is the equivalent of a foreach loop that traverses a vector of with intervals and callbacks to check if any of those are to be executed given the current dt value, 2) Nasal in general is not deterministic due to its GC scheme, i.e. it is the code itself that may trigger the GC and thus delay execution of other code.

Thus, I think you would definitely need to experiment with threads to see if there's any benefit here at all - e.g. by providing a calculation and letting that run via thread.newthread() - as long as it's just math.* stuff and no extension functions there should be no problems - however, GC in the main thread will definitely also affect GC in other threads.
Thus, while the update rate of the 2nd thread can be "more framerate independent" than stuff running in the main loop, GC will still make it appear interconnected at times.

However, last I checked, Nasal code running in a worker thread can provide update rates of ~300-500 hz (depending on your hardware obviously, as well as your frame spacing)

Subject: Actual programming language for autopilot implementation?

You could use Nasal's worker threads to run some of your code outside the main loop, i.e. decoupled from the frame rate - you would then merely need to synchronize your computations with the main loop at frame rate, that should give you several 100 hertz for your computations.

[...]

When using Nasal, you'll need to make sure not to call any FG extension functions in your worker threads, but number crunching will be just fine - if you need to call extension functions (i.e. to access the property tree), you'll want to design your code such that these things are handled in the Nasal main thread, i.e. as part of the FG main loop.

[bugman]

good work in general - expanding the info box is a good idea. and I like the concept of the repository icon on top to see where a plane is found.

Cheers! For the logo concept, that was the original idea - to show the origins of the craft and to show off the 3rd party hangars. If this takes off, I'll need to contact a few people behind the venerable 3rd party hangars about creating 270 px banner graphics.

I personally find the icons for 'Spacetrip ready' and for 'visit devel repository' together with the labels 'Ready' and 'Development' not really intuitive.

Hmmm, I'll have to think about this one. These elements are rooted in history. For the spacetrip ready concept within the infobox, I found that on the Vostok-1 page and expanded it. I quickly created the spacetrip ready icon as a temporary placeholder:



I wanted this to look nothing like a bomb used for 'bombable', i.e. avoiding a cartoon rocket. The icon I used for the development repository is also a temporary placeholder. I found the icon on the wiki and used it to be quick:



This seemed to be quite reasonable, for lack of a better icon. For the text 'Ready' and 'Development', would you have suggestions? 'Ready' is the original text. I did think of 'features', but that is not specific enough. I find this 'ready' concept quite strange, and don't know how to describe it. For 'development', I could maybe use 'Development repository', but that ends up being split on two lines. Short forms are pretty ugly though ('devel repo').

I was also wondering whether it'd be possible to make an author summary (say, a list that expands when you click on it) rather than what is in for the DHC6 for long author lists. The top level could then just read 'PAF team' or 'Shuttle development team' and be detailed on request.

This is a good idea. I will have to look into what technology we have in Mediawiki to implement such a concept.

In analogy to 'Rembrandt ready' in principle you could also make an 'uses ALS interior effects' icon if you like.

That would good for balance. I would put this as "ready = als". As for an icon, hmmm, that's a tough one for a 30x30 pixel grey-scale square! Suggestions are most welcome

As for especially space related things, I don't think we have enough spacecraft to really try to make a meaningful distinction. You could potentially ask for the quality of orbital guidance for instance (this is something completely absent from plane ratings and also poorly supported by FG) - but with two real orbiting craft, how much sense does this really make? You could also make a distinction whether the stage separations are fully animated or whether discarded stages just disappear (another thing that's not usually rated for aircraft). You could ask for payload support (where applicable) or spacewalk capability.

Perhaps more thinking aloud at this point...

I'll keep things open. I've tried to standardise a few things on the wiki (spacetrip ready, space meta-categories, etc.), but this will have to develop with FlightGear and its future spacecraft.

Regards,
Edward

[Thorsten]

For the text 'Ready' and 'Development', would you have suggestions? 'Ready' is the original text. I did think of 'features', but that is not specific enough. I find this 'ready' concept quite strange, and don't know how to describe it. For 'development', I could maybe use 'Development repository', but that ends up being split on two lines.

I'm not sure what the 'Ready' concept really means - we're using it with the icons in a number of different ways:

* explicitly supports some optional feature of the core (checklists, Rembrandt, air refueling, aerotow...) or 3rd party developments (bombable)

* is a particular type of craft (spacecraft are always spacetrip ready, gliders are always thermal ready,...)

* uses a particular bit of FG technology (canvas ready,...)

In a way, I see the point of the first category, I'm less sure about the second (while it is possible to write a spacecraft that isn't actually capable of reaching space, I fail to see how a glider could be designed that does not respond to a thermal - a 747 will do this just as well (so will the Shuttle, though turning radius and sinkrate are too high to gain any altitude). I don't really see where the third comes in - we might as well declare JSBSim planes JSBSim ready or anything that has textures 'rendering ready'.

So maybe the whole concept of the 'ready' categories needs to be re-designed. In that case, we may actually want to change this into 'support for' or 'supports' making the first most prominent.

The repository problem could be solved at the expense of making 'release' and 'development' subcategories of 'repository' or 'download' - I believe that text might fit. I'm not sure this needs icons at all.

[Thorsten]

However, last I checked, Nasal code running in a worker thread can provide update rates of ~300-500 hz (depending on your hardware obviously, as well as your frame spacing)

For once, orbital targeting is a problem that's not performance critical at all because it doesn't provide real time guidance. I'm not sure about all the details, but the Shuttle manual contains occasionally passages 'if guidance remains unconverged after more than 67 seconds, do XXX' - so in reality the computations seem to have taken multiple tens of seconds - if anything we're doing them too fast in FG to be real.

Imagine doing a computation now for a maneuver you will execute 30 minutes in the future which will bring you to the desired position some two hours in the future - that's the kind of timescales this is operating in. It doesn't really matter if the calculation takes a second or a minute.