Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby Hooray » Sun May 29, 2016 8:09 am

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.


the main thread could set flags/variables to communicate the duration of a frame, i.e. time spent creating it - i.e. using the equivalent of several systime() calls, and appending those to a vector with timestamps and calculations to be executed.

IIRC, systime() is using SGTimeStamp internally, which shouldn't be using the event manager.

There also is some kind /frame property and various /time properties that could be gathered and put into such data structure, which would then be accessible from the other/worker thread.

Regarding the precision of systime(), that may indeed be an issue - Richard recently mentioned that there are some OS specifics, e.g. on Windows.

Anyway, if Nasal is not a good tool for the job, I can help you come up with C++ code to do what is needed - either in the form of additional property-rule features or via a dedicated C++ SGSubsystem.

PS: The "ready concept" (wiki) is indeed very overloaded - I think Michat introduced this one, at least he contributed many/most icons.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sun May 29, 2016 8:25 am

Nasal ought to be fine - it can simulate co-orbiting objects with the required precision, so it should get predictions done. Even in a C++ context, you'd have numerical issues. You have them even in reality..

As John Denker pointed out, the correct solution would be to run a second instance of JSBSim in fast-forward mode - which is where we should eventually be heading. But this is a finite accuracy game also in reality - you'll never be able to know the exact weight of the orbiter prior to a burn, so you'll never exactly control Delta v, state vector extrapolation requires periodical corrections,...

The difficulties are in finding a good algorithm - how that is implemented is not the primary concern (although it matters as well of course).
Thorsten
 
Posts: 10965
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sun May 29, 2016 10:19 am

Using the approach outlined above via the Nasal console, where I am merely copying properties into a Nasal data structure, the worker thread can do timing via /sim/time/elapsed-sec, e.g.: Elapsed sec: 608.1666666664384


Code: Select all
# this is a hash where we will store a list of key/value pairs, where the key is the name of the property
var propertyMap = {};

# this is a vector of properties that are to be synced, i.e. put into the map above
var syncedProperties = ['/sim/time/elapsed-sec', ];

# this will be invoked by a timer per frame to update the properties in the propertyMap
var copyProps = func() {
foreach(var p; syncedProperties) {
propertyMap[p] = getprop(p);
 }
}

# this sets up the timer to update properies per frame
maketimer(0.00, copyProps).start();


# this is the function that will be executed by the worker thread
var workerThread = func() {
#print("Hello from the worker thread");
for (var i =0; i<=20; i+=1)  {
print("Elapsed sec: ",propertyMap['/sim/time/elapsed-sec']);
}
};

# start worker thread:
var t = maketimer(1, func thread.newthread( workerThread ));
t.singleShot=1;
t.start();


Thorsten wrote in Sun May 29, 2016 8:25 am:As John Denker pointed out, the correct solution would be to run a second instance of JSBSim in fast-forward mode - which is where we should eventually be heading. But this is a finite accuracy game also in reality - you'll never be able to know the exact weight of the orbiter prior to a burn, so you'll never exactly control Delta v, state vector extrapolation requires periodical corrections,...


I wasn't aware of any recent disscussion relating to this, but I did actually do something like this a few years ago, i.e. a 2nd JSBSim (FGFDMExec) instance, used as a "stage" in a pipeline of controllers, that was back when we were talking about simulating vnav, which basically also requires a look-ahead capability: http://wiki.flightgear.org/Implementing ... FlightGear

https://sourceforge.net/p/jsbsim/featur ... age=1#8ce6
Jon S. Berndt wrote:I've seen the use of simple simulation within a simulation, where performance data is being calculated. It was not within JSBSim, however. This is an interesting prospect. Nobody has ever done this, up to now. My initial reaction was pessimistic. However, the flight control components within JSBSim are fairly capable, and you are permitted to define arbitrary functions. So, my guess at this time is, yes, you should be able to set up JSBSim to calculate some performance data. It may be a lot of work, but it should be possible.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby bugman » Tue May 31, 2016 3:46 pm

Thorsten, thanks for the feedback on the wiki template. I've managed to get most of it into my test aircraft infobox template. For the spacetrip ready option, I have simply dropped that as it is meaningless. For other space related options, we can add those later when a need arises.

Cheers,
Edward

Edit: Note the collapsible author list on the FGAddon Space Shuttle example.
bugman
Moderator
 
Posts: 1698
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Space Shuttle

Postby Thorsten » Tue May 31, 2016 5:21 pm

Yeah - nice work on the author list!
Thorsten
 
Posts: 10965
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby bcoconni » Sat Jun 04, 2016 10:27 am

Hi Thorsten,

I'm reading this post from time to time with much interest to see the progress of the Space Shuttle and I see that you are struggling to predict the shuttle position using a Nasal script. The thing is that JSBSim is actually cheating regarding its trajectory computation : every time step, it calls a function FGPropagate::NudgeBodyLocation to compensate the drift of the CG with respect to the structural frame. This function is a no-op as long as the mass geometry of the body remains the same. But as soon as you burn fuel, the mass geometry changes and this function moves the CG so that the structural frame position remains unaffected by the mass geometry modification.

I never managed to convince Jon that this creates an artificial force on the body which bias the trajctory computation. Indeed the function does not make much difference for aircrafts but I am suspecting that it corrupts the computation for orbiting bodies for which, as you said, a tiny error can result in a misplacement of 100km. I would therefore be interested to know if disabling the call to that function is making any difference for your problem.

The function can be disabled by commenting out the line 212 in src/FDM/JSBSim/models/FGMassBalance.cpp
Code: Select all
206:  // Track frame-by-frame delta CG, and move the EOM-tracked location
207:  // by this amount.
208:  if (vLastXYZcg.Magnitude() == 0.0) vLastXYZcg = vXYZcg;
209:  vDeltaXYZcg = vXYZcg - vLastXYZcg;
210:  vDeltaXYZcgBody = StructuralToBody(vLastXYZcg) - StructuralToBody(vXYZcg);
211:  vLastXYZcg = vXYZcg;
212:  FDMExec->GetPropagate()->NudgeBodyLocation(vDeltaXYZcgBody);


Bertrand.
bcoconni
 
Posts: 41
Joined: Sat Nov 13, 2010 2:27 pm
Location: France
IRC name: Bertrand0
Version: Git
OS: Linux

Re: Space Shuttle

Postby Thorsten » Sat Jun 04, 2016 10:37 am

Okay... I'll take a look once I go back to this problem.

It's the OMS burns which matter here, and I suspect the fuel fraction spent on a 20 second burn is not staggering, but it might be an issue to consider. Thanks for letting me know!
Thorsten
 
Posts: 10965
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Tue Jun 07, 2016 5:31 pm

After some rather frustrating debug sessions, I've now managed to get a reasonably accurate trajectory prediction code (including OMS burn on the way) which can be fit to a certain target.

In a test, I've managed to get (almost) as close (30 km) as predicted to ISS aiming 1 1/2 hours in advance from an eccentric orbit with the automatically computed burn. So we may get support for targeting ISS automagically after all...

And the PEG-4 targets - which are basically the same technology, except the aim point isn't moving...
Thorsten
 
Posts: 10965
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Mon Jun 13, 2016 4:56 pm

After staring at some pics, I think I got the basic structure of that orientation ball in the PFD covered. It's basically the central portion of the nice ball here, plus some additional labels and ladders.

Image

Funnily, this is sort of a real-time 3d rendering code written in Nasal - it generated a 3d vertex mesh, then projects it into the view plane, does normal dot view vector to determine whether line segments are visible, will get a clipping function... Anyway, I think it's feasible to do it that way - especially since we want to draw labels undistorted.
Thorsten
 
Posts: 10965
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Tue Jun 14, 2016 2:10 pm

Yayy!!! I can't wait to definitively get rid of the ugly HUD :D

Regards
amalahama
 
Posts: 109
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle

Postby Thorsten » Thu Jun 16, 2016 9:27 am

Learned a lot about canvas in the last days... the conceptional issues are all well under control, the rest is just tedious (and possibly needs to be performance-optimized in the end, this has tons of elements...).

Image

Pretty much everything you can see on this display is procedurally drawn - I have now routines which generate ladders (minor and major ticks on request), compass roses, arrows,... So doing something like the alpha tape is just calling a few commands and setting fonts and colors for the various elements in-between - no drawing by hand, no SVG input required, very neat.
Thorsten
 
Posts: 10965
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby wlbragg » Thu Jun 16, 2016 4:16 pm

Wow, that is incredible. Can't wait to see it in action. Now I won't get "Lost In Space" anymore! :D
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4880
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: Space Shuttle

Postby Hooray » Thu Jun 16, 2016 4:23 pm

That's prettty impressive, I would not have known how to do this, and I think Richard also mentioned that he struggled with the PFD, so kudos to you - and you may really want to consider adding your routines to $FG_ROOT/Nasal/canvas, so that they can be more easily reused.

besides, feel free to get in touch if there are any remaining "conceptual" questions - I think, you have just created one of the most difficult displays in the history of the Canvas system ;-)
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Thu Jun 16, 2016 6:05 pm

Now I won't get "Lost In Space" anymore!


Now that ADI switch you animated is finally good for something :mrgreen:
Thorsten
 
Posts: 10965
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Thu Jun 16, 2016 6:12 pm

and you may really want to consider adding your routines to $FG_ROOT/Nasal/canvas, so that they can be more easily reused.


You probably want them 'nice' though - not my function calls taking long lists of parameters. I guess you'd rather pass hash or property arguments?

Well, if you can give me an idea in what form they'd be most useful, I'm happy to add them to a lib.
Thorsten
 
Posts: 10965
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 4 guests

cron