Board index FlightGear Media

Payload satellite deployment

Screenshots, videos, sound recording etc. taken in/with FlightGear.

Payload satellite deployment

Postby Thorsten » Thu Jul 23, 2015 2:39 pm

I'm actually fairly proud of having figured that one out so quickly...

Payload specialist's view into the bay, using the RMS arm to grab a satellite - Shuttle is in inertial attitude hold mode.

Image

The arm needs to be maneuvered rather carefully into the right position - takes some time to learn (though, once the stick mode is implemented, it's going to be easier). After attaching the effector to the payload, we can do this:

Lifting the satellite out of the cargo bay...

Image

... and onwards...

Image

... slowly stretching the RMS arm...

Image

... till it won't go any further...

Image

(note how the Shuttle seems to rotate relative to Earth as we cross Africa because it holds inertial attitude, not horizon attitude)

Image

Then we can release the payload - it just drifts there, doing nothing.

Image

The arm gets folded back again, and then we can ignite the RCS thrusters in -Z translation mode...

Image

.. pushing us away from the satellite.

Image

(satellite is a mockup of course - I'm not a 3d modeler, but a real payload would unfold panels after being deployed - but it gives a good visual idea of how it all works :-) ).
Thorsten
 
Posts: 10089
Joined: Mon Nov 02, 2009 8:33 am

Re: Payload satellite deployment

Postby Bjoern » Thu Jul 23, 2015 3:17 pm

Wow!

This just begs the question:
Is persistence doable in FG's present condition or would it require fundamental enhancements to the sim core?
Do a barrel roll!
User avatar
Bjoern
 
Posts: 384
Joined: Fri Jan 06, 2012 10:00 pm
Location: Nearest: THF
Version: Next
OS: ArchLinux, Win 7

Re: Payload satellite deployment

Postby Thorsten » Thu Jul 23, 2015 5:44 pm

Of what kind? Like a scenery object - always there? Like an AI object - there on request? Shared over MP? Across different sessions?

Currently objects are persistent till they get deleted because of a distance cut. There's no need to delete them though. After analyzing what the orbital motion solver does and compensating for the observed drift, I now have error rates measured in meters per minute independent of framerate - objects could be simulated for multiple orbits numerically and would still be found. Technically they could be handed over to an analytical orbit solver as well - then they'd be stable forever. As long as FG runs, that is.

We just can't save a FG session state, so anything will be gone after a reset. We have no infrastructure to do that - so that would need to be created.
Thorsten
 
Posts: 10089
Joined: Mon Nov 02, 2009 8:33 am

Re: Payload satellite deployment

Postby Bjoern » Fri Jul 24, 2015 10:57 am

Thorsten wrote in Thu Jul 23, 2015 5:44 pm:We just can't save a FG session state, so anything will be gone after a reset. We have no infrastructure to do that - so that would need to be created.


That's what I meant.
Do a barrel roll!
User avatar
Bjoern
 
Posts: 384
Joined: Fri Jan 06, 2012 10:00 pm
Location: Nearest: THF
Version: Next
OS: ArchLinux, Win 7

Re: Payload satellite deployment

Postby gsagostinho » Fri Jul 24, 2015 11:43 am

Absolutely stunning, Thorsten! What a great work you are doing with the Space Shuttle project!
User avatar
gsagostinho
 
Posts: 1799
Joined: Thu Jan 15, 2015 6:27 pm
Location: London, UK

Re: Payload satellite deployment

Postby Thorsten » Fri Jul 24, 2015 11:48 am

I think persistence of that kind would require a conceptual discussion about how the FG world is supposed to work, because right now we're geared towards real-time MP sync.

Meaning the AI traffic is supposed to mimic real traffic as it would happen at the time of day (I think), there's pushes to use real-time ship traffic and even real flight tracker data, and airplanes appear over MP based on what they do right now. Most MP users also use real weather.

If airplanes would be persistent, they'd soon clutter parking positions all over the world in MP. And if satellites were persistent and MP-capable, everything you lug into orbit would stay there forever for everyone.

What about launch tests then? - I've flown far more Shuttles into orbit then back - it's a bit scary to imagine them remaining up there. If I leave a FG session with the Shuttle somewhere and resume that session (assuming I could) - what could I expect to find? Myself in the same time instance I left (breaking sync with real time), or the Shuttle having orbited happily in the mean time, keeping sync with real time and having been visible over MP, and me finding the Shuttle in a different place, in the position of an astronaut who took a nap.

What about decaying orbits? Stationkeeping?

I don't think we even have a conceptual answer how all this might work together eventually at this point.
Thorsten
 
Posts: 10089
Joined: Mon Nov 02, 2009 8:33 am

Re: Payload satellite deployment

Postby clrCoda » Fri Jul 24, 2015 8:46 pm

OOH! Persistant Walkers.

Let's see, just 6billion more to go... :)

--Ray
Ray St. Marie
clrCoda
 
Posts: 1228
Joined: Wed Apr 07, 2010 11:04 am

Re: Payload satellite deployment

Postby legoboyvdlp » Fri Jul 24, 2015 10:11 pm

What would be rather interesting would be to be able to define sub,odules as "persistence-avail" that is, persistence could be toggled. IE, if the ISS is a submodel, an option toggle ISS persistent could be added to the sim options part of the space shuttle. Then the sattellite could be as well.
Also, a parameter like "persistence-time" could mean that it would be there for x seconds.
User avatar
legoboyvdlp
 
Posts: 6020
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Payload satellite deployment

Postby Thorsten » Sat Jul 25, 2015 5:42 am

Also, a parameter like "persistence-time" could mean that it would be there for x seconds.


The distance cut seems more useful - it's there as long as it is in the vicinity and you can see it.

But we're talking about things which continue to 'be there' after a restart of the sim - and I'm asking seriously for an idea of how this should consistently tie with the rest of the FG world including MP. It's easy to use an AI model for ISS - if you save the orbital parameters, it'll be (optionally) there where you left it last time if you load the AI scenario. But it won't go over MP. Conversely, objects over MP will need to be in-sync with real time, i.e. will not be at the same place where you left them, they'll have to be simulated all the time.
Thorsten
 
Posts: 10089
Joined: Mon Nov 02, 2009 8:33 am

Re: Payload satellite deployment

Postby Hooray » Sat Jul 25, 2015 1:42 pm

Concerning "persistence" in general, and in FG in particular, there is no notion in place to cover all aspects of "persistence" - but there are various attempts at implementing "partial persistence", as per the "FlightGear Sessions" article on the wiki and variou XML/scripted workarounds (think ac_state.nas). Equally, there's the flight recorder (replay tapes) as well as the "userarchive" attribute. So, the underlying APIs are certainly available, it would mainly require someone to formalize a few requirements and to flesh out the corresponding high level APIs to implement those. I am willing to support such an effort (leaving aside MP for now, for reasons discussed in the DIS/HLA debates we've had - as per the corresponding wiki articles). But I would suggest to start a new thread and/or have a dedicated wiki article for that purpose.

Conceptually, this is touching on a number of seemingly unrelated efforts, such as synchronized weather/AI state across multiple FG instances (not just multiplayer, but also multi-instance setups like those at FSWeekend/LinuxTag).

Speaking in general, RTI/HLA is the appropriate/correct technology stack for these kinds of problems (synchronizing shared state in a distributed environment). But I guess it would make sense to come up with a list of requirements that people (=contributors, people willing to do something) can agree on. Personally, I am not the slightest bit interested in supporting the legacy MP environment - however, AndersG's mp_broadcast.nas script (see wildifre.nas) could certainly be exploited to a certain degree to make something like this work.

But like I said, this is also touching on various other aspects of the simulation, including even dual/shared control.
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: 11263
Joined: Tue Mar 25, 2008 8:40 am

Re: Payload satellite deployment

Postby Bjoern » Sun Jul 26, 2015 9:18 pm

Can Nasal or XML in FG read/write from/to file? And are enough simulation properties exposed to create a basic, robust, (SP-only) load/save system for a specific aircraft?
Do a barrel roll!
User avatar
Bjoern
 
Posts: 384
Joined: Fri Jan 06, 2012 10:00 pm
Location: Nearest: THF
Version: Next
OS: ArchLinux, Win 7

Re: Payload satellite deployment

Postby Hooray » Mon Jul 27, 2015 12:49 pm

yes, but that's not the point - something like this could work analogous to ac_state.nas and friends - however, there are deeper issues invololved here - for details, see the "reset & reinit" and "FlightGear Sessions" articles on the wiki.
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: 11263
Joined: Tue Mar 25, 2008 8:40 am

Re: Payload satellite deployment

Postby Bjoern » Mon Jul 27, 2015 5:38 pm

http://wiki.flightgear.org/Reset_%26_re-init

From what I understood, saving and loading is essentially impossible in FG's current state. Purging the current session from memory and reinitializing it is seen as the best solution. An early initialization of Nasal, coupled with simulation options parsed from a script, would basically make loading an aircraft in a certain state possible. This is still under development.
Did I get the key points correctly?
Do a barrel roll!
User avatar
Bjoern
 
Posts: 384
Joined: Fri Jan 06, 2012 10:00 pm
Location: Nearest: THF
Version: Next
OS: ArchLinux, Win 7

Re: Payload satellite deployment

Postby Hooray » Mon Jul 27, 2015 7:37 pm

Yeah, that's basically correct - the main issue here is not so much Nasal/XML level stuff, but the underlying C++ code (SGSubsystem and friends) that's basically been written/developed and maintained without such design requirements in mind - even though the original API designer (David Megginson) did prepare things accordingly, by providing the corresponding APIs and stubs for core developers to fill in subsystem-specific routines for run-time re-initialization and for decoupling the whole design (as per the bind/unbind APIs, referring to the property tree) .
However, subsequently a number of major contributions were made without them providing the stubs for run-time re-initialization that would be required for saving/loading flights but also for changing aircraft at run-time. The main culprit in the early days of the SGSubsystem effort was the "presets" work, which exposed a bunch of attributes to the property tree and the command line, at the cost of crippling "save/load" functionality - for details, see: http://wiki.flightgear.org/Fixing_Presets

As can be seen, the main core developers back then were contemplating to revert the whole "presets" stuff and come up with a better formalized framework instead that would honour the corresponding run-time requirements for providing aircraft state saving/loading and switching functionality.

Ultimately, this kept getting re-identified as a major issue in the following years, and even the majority of core developers agreed that it would be good to get this fixed - but in the meantime, more and more new C++ code (subsystems) were added without them providing the corresponding functionality - so in the meantime, this is no longer just about a single feature or subsystem like "presets", but a whole shebang of features that are increasingly incompatible with key functionality - however, that doesn't just involve saving/loading or switching aircraft, this also touches on unrelated debates, like those of having "persistent" state or replicating/sharing and synchronizing specific simulator state across multiple fgfs instances (even unrelated to multiplayer).

The underlying challenge really is more about project coordination and active management, while taking into account that contributors may come and leave, despite certain issues still remaining valid over the course of many years. Things like Canvas were debated for the better part of a decade before they got implemented - and even though Canvas was obviously prototyped and developed by an enormously experienced C++ developer, even the Canvas system suffers from limitations related to reset/re-init or multi-instance state replication (multiplayer or multi-instance setups).

An early initialization of Nasal, coupled with simulation options parsed from a script, would basically make loading an aircraft in a certain state possible. This is still under development.

Well sort of: http://wiki.flightgear.org/Initializing_Nasal_early

This was actually discussed on the devel list among core developers, and it inspired some work that I prototyped a while ago - however, ultimately the core developers askign for it (e.g. Zakalawe) were no longer around when the patch came up, and others (like TorstenD) were generally opposed to the idea, despite massive backlogs of discussions in the archives detailing why this was a good thing for the simulator's design.

In general, this is proving the point that FG has grown up to a point were it may no longer suffice for individual developers to hash out some roadmaps and ideas, but instead team up to conceive long-term roadmaps in the form of the updated project roadmap that Stuart has been working on: viewtopic.php?f=42&t=26486&p=246450&

Unfortunately, there is an increasing share of FlightGear contributors familiar with building from source code and familiar with C++ and the corresponding SG/FG and OSG APIs, who no longer feel that the project addresses contributions adequately, so that they're feeling kinda deflated - especially those who have already spent considerable time working on features and patches, that were ultimately rejected or not even reviewed in a timely fashion.

The "reset/re-init" article you linked to still is a good entry point though, because it provides a good baseline for people wanting to understand the underlying challenges, without any of those being specific to a single contributor or core developer. You will find a number of more or less related articles documenting efforts that are related to these. So over time, these will probably be fixed - but unfortunately, this means more often than not 5+ years down the line and even more frustrated/potential contributors ...

http://wiki.flightgear.org/FlightGear_Headless
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: 11263
Joined: Tue Mar 25, 2008 8:40 am

Re: Payload satellite deployment

Postby Bjoern » Tue Jul 28, 2015 1:53 pm

So the entire issue is a mix between nearsighted code design and diverging interests?

Well, at that point, I'd probably consider a project fork to get things rolling again.
Do a barrel roll!
User avatar
Bjoern
 
Posts: 384
Joined: Fri Jan 06, 2012 10:00 pm
Location: Nearest: THF
Version: Next
OS: ArchLinux, Win 7

Next

Return to Media

Who is online

Users browsing this forum: No registered users and 2 guests