Board index FlightGear Development Spaceflight

Space Shuttle - Development

Discussion about development and usage of spacecraft

Re: Space Shuttle - Development

Postby GinGin » Thu Jan 17, 2019 11:59 am

@EatDirt: Ah sorry for the out of subject answer, you are a true test pilot with all those bounces :)
I see for the checks, why not. That's a lot of small steps to add. You would find it handier than to have the Annotated checklist on paper ?

@Thorsten: I am starting to play with rendez vous. So far, I managed to find a suitable Launch window from KSC, with an ISS LAN around 254 ° and anomaly more than 40 ° to have in front of us.
If I understand well, ISS should appear when we are in a sphere of 5 km radius around the Target?

Also, I noticed that we don't have anymore the blue line for ISS Orbit on the trajectory map, don't remember if it is like that since your last work on that map?

Time to fire the new LEO tool now :)
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby Thorsten » Thu Jan 17, 2019 1:34 pm

ISS appears when you get within 5 km, but for a reason I have yet to determine it does not appear with the correct relative velocity :evil: So either you burn plenty of propellant or you can't dock at the moment.

Though I might find the cause before your phasing is over...

Also, I noticed that we don't have anymore the blue line for ISS Orbit on the trajectory map, don't remember if it is like that since your last work on that map?


I've not re-implemented that - it seemed too confusing if you want to rendezvous as they almost overlap, and it seems pointless if you do not rendezvous.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby eatdirt » Thu Jan 17, 2019 1:53 pm

You would find it handier than to have the Annotated checklist on paper?


Not really, on a piece of paper it would be nice too. Do you mean that such a checklist exist already? Sorry, if that's the case, I missed it. Currently I am underlining in red the actions in printed version of your tutorials, that's fine, but I have quite a pile of documents each time I am getting on board the Shuttle, lol :)
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby GinGin » Thu Jan 17, 2019 3:33 pm

Though I might find the cause before your phasing is over...


Ahah maybe.
The difference is of which order of magnitude ?
If I save and resume on Orbit, normally both state vector ( Shuttle and ISS) should resume where I let them ?

as they almost overlap


Indeed, it makes sense.
It was just to be sure we are launching on the same orbit, but indeed, if LAN and Inc targeted at launch match ISS one, overlaping should be there.


@EatDirt: Mmm did you have a look there ?

http://wiki.flightgear.org/Flying_the_Shuttle_-_Space_Shuttle_Checklists
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby Thorsten » Thu Jan 17, 2019 4:18 pm

The difference is of which order of magnitude ?


Yesterday evening I got something like 6-8 m/s. It can be nulled (I tried that) but it has to be done visually - because the velocity difference means 3d model and rendezvous zero point won't be aligned.

If I save and resume on Orbit, normally both state vector ( Shuttle and ISS) should resume where I let them ?


Unless I included the orbital target in the save/resume script long ago and don't remember - no.

As I said - it has plenty of errors and quirks still, at this point just getting to know the Lambert solver is the goal.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby wlbragg » Thu Jan 17, 2019 7:07 pm

did you have a look there ?

No, outstanding GinGin! Thank you for that.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7587
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 - Development

Postby eatdirt » Fri Jan 18, 2019 12:50 am

did you have a look there ?


Et voilà! so NICE!! Thanks for the link.

And finally, you can enjoy the double pass aerobraking there:

https://forum.flightgear.org/viewtopic.php?f=19&t=35234&p=341617#p341617
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby GinGin » Fri Jan 18, 2019 8:19 pm

@EatDirt and Wayne: Glad you like it.
EatDirt, it was mentionned on the first lines of tutorial :mrgreen:


@Thorsten: I started some tests. Mainly Working on Launch window with Mission File Parameters, First test with LEO tools, etc to get used to it and to the new Lambert Functionality.
Rendez Vous Canvas is really useful. Very Pertinent informations with Delta position and Catch up rate.

It looks really promising. I will have almost a week of free time next week to test all that in deep. That a hell of work you made there.

On a side note, I am really optimistic on Rendez vous timeline in FG despite the lack of high time compression ( I managed x 8 / x 16 max with disabling a lot of 3D stuff).
With the good launch window, we can launch and rendez vous as short as half an orbit later like Gemini did, or extend it to 3 to 6 hours like Soyuz/Progress mainly does now.
That is completely viable for a gaming session of a couple of hours.



Unless I included the orbital target in the save/resume script long ago and don't remember - no.


Indeed, it is not saved. It reloads mission file parameters for ISS when we resume
I really have no idea how tough is it to add the ISS state vector in save, I was just thinking it could have been a good idea to add it while we are testing rendez vous to save and resume quickly by having the same relative position between shuttle and ISS to test faster :)



Have a nice week end guys
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby Thorsten » Sat Jan 19, 2019 7:31 pm

On a side note, I am really optimistic on Rendez vous timeline in FG despite the lack of high time compression ( I managed x 8 / x 16 max with disabling a lot of 3D stuff).


8x I can run regularly, 16x might be in reach on more than high end systems.

I really have no idea how tough is it to add the ISS state vector in save,


Messy mainly. The inertial coordinate system which is used is different in JSBSim after a resume. From that it follows that dependent on what coordinates some object uses, we have to cheat accordingly.

I've now managed to make the orbital target at distance resumable - but the avionics will still not target it correctly because of the different elapsed time definition (the reference zero time unfortunately also changes...) But we'll get there.

Whether it'll be possible to save/resume an explicit 3d model in the proximity I do not know. That seems a much harder problem, because one is constantly combating transients and numerical artifacts.

Generally it's slowly coming into shape now - I've tested successfully today targeting an offset on the vbar. When a mid-coast correction burn is done at around 30 km distance, the accuracy is something like 500 m after switching over from analytic to numerical orbit - that's quite possible to null manually, and I've nicely parked the Shuttle on a 4000 m distant vbar position - from where I could have started an approach to proximity operations.

By and large I'd advise to come in slow and on a near Hohmann trajectory...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby GinGin » Sun Jan 20, 2019 2:12 pm

8x I can run regularly, 16x might be in reach on more than high end systems.


What do you suggest to shed to improve Time Compression performance? 3D graphics like shader, stuff like that?
If I remember well, FDM is running at a constant 120 Hz and it is independant from in game fps, so even if it is laggy during compression, Clock and fdm should stay accurate?


Messy mainly. The inertial coordinate system which is used is different in JSBSim after a resume. From that it follows that dependent on what coordinates some object uses, we have to cheat accordingly.


Wow, indeed. Looks pretty complicated with all those frame changes :/
Thanks for doing the ISS save.


I've tested successfully today targeting an offset on the vbar. When a mid-coast correction burn is done at around 30 km distance, the accuracy is something like 500 m after switching over from analytic to numerical orbit



Very nice, well done.
I guess Spec 34 works like PEG 4 in game, it has a fixed number of iterations compared to doing that through the LEO tools?


By and large I'd advise to come in slow and on a near Hohmann trajectory


Alright, I will stick to that :)

Like in Nasa graphics, Perigee within 6 Nm from ISS one, and Apogee same than ISS
First On board targeted burn 50 km ish before rendez vous ( alpha of 0.5 degrees), and final insertion burn one orbit before rendez vous ( 15 km ish from ISS).


What senario/ parameters do you use for on orbit test ?
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby Hooray » Sun Jan 20, 2019 2:53 pm

GinGin wrote in Sun Jan 20, 2019 2:12 pm:
8x I can run regularly, 16x might be in reach on more than high end systems.

What do you suggest to shed to improve Time Compression performance? 3D graphics like shader, stuff like that?
If I remember well, FDM is running at a constant 120 Hz and it is independant from in game fps, so even if it is laggy during compression, Clock and fdm should stay accurate?


Personally, I find it pretty amazing that this works at all - the majority of aircraft are not really designed with this in mind,so that this simply doesn't work at all, or is highly fragile - after all, the correct "time" must be used for different systems.

Just so that you know, you can tell the impact of 3D/rendering by using so called "draw masks" which can be used to separately toggle certain rendering stuff on/off at runtime:

http://wiki.flightgear.org/Draw_masks
Image

In and of itself, this isn't too useful, but it can at least give you a rough idea about the overhead involved in systems simulation and in actually creating/updating and rendering the scene. I am sure Thorsten can provide additional background information - for example, there are also the OSG on-screen stats: http://wiki.flightgear.org/OSG_on_screen_stats

As well as the so called "performance monitor" (which should really only be used via Phi, because using it in-sim will yield false positives, because it is using PUI):

http://wiki.flightgear.org/Howto:Use_the_system_monitor
http://wiki.flightgear.org/Howto:Using_ ... ithout_PUI

I am not sure if this is very useful though, it's primarily intended to help with troubleshooting - so, it's more likely to be useful when debugging/profiling fgfs.

What might be possible though, is temporarily disabling certain things (think 3D rendering) to "fast-forward" the sim more reliably.

But again, Thorsten and Richard would be in a much better position to judge if that makes any sense or not.
Like I said, most aircraft (and especially their FDM/control systems) don't respond too well to tinkering with "simulation time".

Conceptually, another useful benchmark/metric might be running the JSBSim FDM/systems in standalone mode, to come up with a rough figure that can be compared to jsbsim/fdm performance inside fgfs.
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 - Development

Postby Thorsten » Sun Jan 20, 2019 3:41 pm

What do you suggest to shed to improve Time Compression performance? 3D graphics like shader, stuff like that?


At least for me, the problem is the FDM itself, so without changing the code you can't improve anything. The requirement of keeping the FDM at constant accuracy means that more and more FDM needs to be squeezed into a frame, and for me the frame is simply full with FDM when time compression is 8x, beyond that FDM calculations start to overlap and delays are introduced.


Thanks for doing the ISS save.


I think I have it now, but it still might require some testing...

What senario/ parameters do you use for on orbit test ?


Code: Select all
 --lat=0.0 --lon=5.07 --heading=44.66


works fine for me with the orbital target defined in mission,xml - it gives some not really efficient transfer solutions 'sight now' or more efficient ones if you wait a bit' (I've actually amused myself by asking the solver for a 15 minute transfer time... it did come up with an answer, but the Shuttle doesn't have enough propellant for that kind of thing...)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby Hooray » Sun Jan 20, 2019 3:58 pm

Thorsten wrote in Sun Jan 20, 2019 3:41 pm:
What do you suggest to shed to improve Time Compression performance? 3D graphics like shader, stuff like that?

At least for me, the problem is the FDM itself, so without changing the code you can't improve anything. The requirement of keeping the FDM at constant accuracy means that more and more FDM needs to be squeezed into a frame, and for me the frame is simply full with FDM when time compression is 8x, beyond that FDM calculations start to overlap and delays are introduced.


FWIW, back in the early 2000s, it was relatively common to hook up external FDMs to FlightGear, and at some point both, JSBSim and fgfs were modified to make it possible to run jsbsim "out of process" (fgfs), so that the fdm would get its own process, and merely synchronize FDM related data with fgfs at the desired rate, whereas the FDM itself could indeed run at higher rates. The full background can be looked up in the archives, some of the key folks involved back then were David Megginson, Erik and obviously Jon himself.

In other words, it should still be possible to run the FDM out of the main loop and merely synchronize "state vectors" with fgfs - if/how this works (at all) for the shuttle or other spacecraft could obviously be an entirely different topic.

But we do have a number of topics here that cover how to run jsbsim externally, i.e. as a different process.
Obviously, that would require some matching CLI arguments to hook up the I/O (sockets), but I believe the details are documented somewhere in $FG_ROOT/Docs

There is also a hard-coded protocol to feed back "controls" to another process.
Anyway, I assume most of this hasn't really gotten much attention over the years, so it may be best to discuss this with people more familiar with jsbsim/fgfs interfacing - but running jsbsim out of process was indeed a fairly common topic back in the early days of the project, which is also how and why "tied properties" were introduced at the time, as well as the "FDMShell" abstraction.
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 - Development

Postby Thorsten » Sun Jan 20, 2019 5:00 pm

You can't run the Shuttle in an external FDM because it requires integration between the various systems (JSBSim, Nasal,...).

If you're just interested in the state vector, you can fast-forward it using a tool like LEO targeting and simply export it at later time via a mechanism like the save/resume, that will work to good accuracy.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby Hooray » Sun Jan 20, 2019 6:18 pm

Thorsten wrote in Sun Jan 20, 2019 5:00 pm:You can't run the Shuttle in an external FDM because it requires integration between the various systems (JSBSim, Nasal,...).


I guess there's a misconception here - JSBSim merely runs the FDM out of process, but that's totally transparent to FlightGear,the external FDM mechanism I mentioned previously takes care of synchronizing the relevant properties in a transparent fashion using the aforementioned "FDMShell" mechanism - with your Linux background, you can imagine the whole thing to work analogous to "mounting", i.e. /fdm is mounted inside flightgear, but actually lives out of process.

Again, you are in a much better position to judge if this is a red herring or not - but conceptually, that is how this was originally supposed to work: there is the equivalent of a remotely managed property tree that is mounted inside flightgear, but created/populated and updated using a different process, which is also how "tied properties" came to be, and why they're used everywhere in jsbsim.

This isn't to suggest that this should actually "just work as is", but that the limitations you mentioned would be more relevant in the context of getting scripting/Nasal off the main loop, which is next to impossible unless the code in question is structured in a corresponding fashion (e.g. using a simple form of message passing akin to Emesary).

Conceptually, an external FDM (i.e. jsbsim) running out-of-process can still affect properties in fgfs and vice versa, via the so called "FDMShell" mechanism.

I don't know if this is anywhere documented other than in the archives, but it has been used by a number of people/efforts to hook up proprietary flight dynamics engines to FlightGear, that also had a nees to access fgfs properties and update fdm state in an encapsulated fashion

I do agree however that it is unlikely to work "out of the box", given that this is obviously a legacy fashion that most people are not longer familiar with, but also because the shuttle project has been sailing in uncharted waters since its very inception ...

Anyway, in the context of the infamous HLA discussion, the FDMShell mechanism is still regularly being brought up as one example of a well-encapsulated subsystem that could be easily moved onto another core/process (or even machine), because the FDMShell "subsystem" formalizes and encapsulates I/O dataflow dependencies.

I believe that some of the "old-timers" like Curt, Erik or Jon (sorry ...) might be able to provide additional background information here, unless the JSBSim manual documents the whole interfacing mechanism already.
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

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 2 guests