SpaceFDM: Difference between revisions
m (Switch to the {{forum url}} and {{forum link}} templates for all forum links.) |
|||
Line 8: | Line 8: | ||
I'm not convinced that JSBSim is up to that out of the box. | I'm not convinced that JSBSim is up to that out of the box. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=153918}} | ||
| title = <nowiki>Re: Earthview - an orbital terrain rendering engine [v0.1]</nowiki> | | title = <nowiki>Re: Earthview - an orbital terrain rendering engine [v0.1]</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 21: | Line 21: | ||
That's in contrast to a Flightsim where you have forces acting now - it doesn't matter for aerodynamical flight if a gust hit you 10 minutes ago, the plane doesn't remember and the code doesn't need to keep track of tiny forces. It matters in space. | That's in contrast to a Flightsim where you have forces acting now - it doesn't matter for aerodynamical flight if a gust hit you 10 minutes ago, the plane doesn't remember and the code doesn't need to keep track of tiny forces. It matters in space. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=124319}} | ||
| title = <nowiki>Re: New Flight Gear Terrain Engine</nowiki> | | title = <nowiki>Re: New Flight Gear Terrain Engine</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 35: | Line 35: | ||
Also, regarding orbital flight, I recently did a comparison between JSBSim and STK (Satellite Toolkit) for a highly elliptical orbit over a 24 hour period. The results were very close. See the JSBSim Facebook page for the details. ( [http://www.facebook.com/jsbsim http://www.facebook.com/jsbsim] ). | Also, regarding orbital flight, I recently did a comparison between JSBSim and STK (Satellite Toolkit) for a highly elliptical orbit over a 24 hour period. The results were very close. See the JSBSim Facebook page for the details. ( [http://www.facebook.com/jsbsim http://www.facebook.com/jsbsim] ). | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=124326}} | ||
| title = <nowiki>Re: New Flight Gear Terrain Engine</nowiki> | | title = <nowiki>Re: New Flight Gear Terrain Engine</nowiki> | ||
| author = <nowiki>jonsberndt</nowiki> | | author = <nowiki>jonsberndt</nowiki> | ||
Line 47: | Line 47: | ||
|1= we need the instruments to do precise orbital maneuvering around earth ''before'' even thinking to leave earth orbit, because if we can't compute a launch trajectory to ISS, we can't compute the ejection trajectory to moon or any correction burns either. Having a deep space FDM right now is useless for us, because we can't even test it in a reasonable way. | |1= we need the instruments to do precise orbital maneuvering around earth ''before'' even thinking to leave earth orbit, because if we can't compute a launch trajectory to ISS, we can't compute the ejection trajectory to moon or any correction burns either. Having a deep space FDM right now is useless for us, because we can't even test it in a reasonable way. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=153981}} | ||
| title = <nowiki>Re: Earthview - an orbital terrain rendering engine [v0.1]</nowiki> | | title = <nowiki>Re: Earthview - an orbital terrain rendering engine [v0.1]</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 63: | Line 63: | ||
That's in contrast to a Flightsim where you have forces acting now - it doesn't matter for aerodynamical flight if a gust hit you 10 minutes ago, the plane doesn't remember and the code doesn't need to keep track of tiny forces. It matters in space. Are you truly telling me that JSBSim is able to handle these issues correctly? | That's in contrast to a Flightsim where you have forces acting now - it doesn't matter for aerodynamical flight if a gust hit you 10 minutes ago, the plane doesn't remember and the code doesn't need to keep track of tiny forces. It matters in space. Are you truly telling me that JSBSim is able to handle these issues correctly? | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=124319}} | ||
| title = <nowiki>Re: New Flight Gear Terrain Engine</nowiki> | | title = <nowiki>Re: New Flight Gear Terrain Engine</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 78: | Line 78: | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=124257}} | ||
| title = <nowiki>Re: New Flight Gear Terrain Engine</nowiki> | | title = <nowiki>Re: New Flight Gear Terrain Engine</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 93: | Line 93: | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=153981}} | ||
| title = <nowiki>Re: Earthview - an orbital terrain rendering engine [v0.1]</nowiki> | | title = <nowiki>Re: Earthview - an orbital terrain rendering engine [v0.1]</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 105: | Line 105: | ||
|1= An FDM simulating [https://en.wikipedia.org/wiki/Orbit_modeling real orbital mechanics], which properly handles the [https://en.wikipedia.org/wiki/Three-body_problem three-body problem], is required for any moon adventures. Then the FlightGear time acceleration framework would be useful (the [a]/[A] buttons), and the maximum acceleration of x32 extended to higher values. But the orbital mechanics is currently missing. It needs to be implemented in JSBSim. Or in a new orbital/space FDM which can be hot switched to on the FG side. In any case, there is a lot of work ahead. | |1= An FDM simulating [https://en.wikipedia.org/wiki/Orbit_modeling real orbital mechanics], which properly handles the [https://en.wikipedia.org/wiki/Three-body_problem three-body problem], is required for any moon adventures. Then the FlightGear time acceleration framework would be useful (the [a]/[A] buttons), and the maximum acceleration of x32 extended to higher values. But the orbital mechanics is currently missing. It needs to be implemented in JSBSim. Or in a new orbital/space FDM which can be hot switched to on the FG side. In any case, there is a lot of work ahead. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269139}} | ||
| title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | | title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | ||
| author = <nowiki>bugman</nowiki> | | author = <nowiki>bugman</nowiki> | ||
Line 118: | Line 118: | ||
|1= We need no more and no less than what I wrote - a numerically stable solver for orbital dynamics. The accuracy of analytical orbits seems quite enough though. | |1= We need no more and no less than what I wrote - a numerically stable solver for orbital dynamics. The accuracy of analytical orbits seems quite enough though. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=250124}} | ||
| title = <nowiki>Re: Space Shuttle</nowiki> | | title = <nowiki>Re: Space Shuttle</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 131: | Line 131: | ||
The algorithm needs to be stable against perturbations and self-correcting. Whether it's done in Nasal, xml or C++ is rather irrelevant. | The algorithm needs to be stable against perturbations and self-correcting. Whether it's done in Nasal, xml or C++ is rather irrelevant. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=249415}} | ||
| title = <nowiki>Re: Space Shuttle</nowiki> | | title = <nowiki>Re: Space Shuttle</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 146: | Line 146: | ||
Doing a 3d model of the ISS should be easy by comparison. | Doing a 3d model of the ISS should be easy by comparison. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=249387}} | ||
| title = <nowiki>Re: Space Shuttle</nowiki> | | title = <nowiki>Re: Space Shuttle</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 159: | Line 159: | ||
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. | 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. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=251774}} | ||
| title = <nowiki>Re: Payload satellite deployment</nowiki> | | title = <nowiki>Re: Payload satellite deployment</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 172: | Line 172: | ||
|1= could there be a 'portal' to go to the Moon or Mars, since not many have a couple of days to spare flying a spaceship to the moon? | |1= could there be a 'portal' to go to the Moon or Mars, since not many have a couple of days to spare flying a spaceship to the moon? | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269046}} | ||
| title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | | title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | ||
| author = <nowiki>legoboyvdlp</nowiki> | | author = <nowiki>legoboyvdlp</nowiki> | ||
Line 183: | Line 183: | ||
{{FGCquote | {{FGCquote | ||
|1= ou can always accelerate simulator time and/or reposition your vehicle at run-time. | |1= ou can always accelerate simulator time and/or reposition your vehicle at run-time. | ||
Also see the "planets" discussion here, including the links to related devel list postings: | Also see the "planets" discussion here, including the links to related devel list postings: {{forum link|t=26785}} | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269048}} | ||
| title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | | title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
Line 198: | Line 198: | ||
And good luck re-positioning a spaceship - you need to get the whole state vector right, not just the position. A percent of velocity might be the difference between orbit and not orbit already. There are libration points in orbital mechanics where the balance is even more fine and a tiny nudge either way will send you either off to the outer planets or back to Earth. | And good luck re-positioning a spaceship - you need to get the whole state vector right, not just the position. A percent of velocity might be the difference between orbit and not orbit already. There are libration points in orbital mechanics where the balance is even more fine and a tiny nudge either way will send you either off to the outer planets or back to Earth. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269130}} | ||
| title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | | title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 210: | Line 210: | ||
|1= that's just the catch with orbital mechanics. The multi-body orbital codes I've been writing really are sensitive to the timestep - if you increase it by a factor ten, you're getting more than a factor ten worse. So even if you have a code and can run it with 32x time acceleration, it's not a given that you can run it with 10.000x time acceleration. | |1= that's just the catch with orbital mechanics. The multi-body orbital codes I've been writing really are sensitive to the timestep - if you increase it by a factor ten, you're getting more than a factor ten worse. So even if you have a code and can run it with 32x time acceleration, it's not a given that you can run it with 10.000x time acceleration. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269146}} | ||
| title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | | title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 225: | Line 225: | ||
(Timing a fixed duration script for an aircraft in an optimied JSBSim/standalone instance should give a hint of how far time could be accelerated with that aircraft.) | (Timing a fixed duration script for an aircraft in an optimied JSBSim/standalone instance should give a hint of how far time could be accelerated with that aircraft.) | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269189}} | ||
| title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | | title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | ||
| author = <nowiki>AndersG</nowiki> | | author = <nowiki>AndersG</nowiki> | ||
Line 237: | Line 237: | ||
|1= Maybe if internal perturbations are disabled when time is not normal, the full trajectory in space could be calculated once and the spacecraft made to follow that pre-determined trajectory. If the trajectory requiresero updates, then accelerated time should not be a major issue. This might be quite contrary to the current design of JSBSim though. Hence why I often mention a SpaceFDM instead. Though maybe JSBSim simply requires a 'mode change' that includes 'sleep states' where the trajectory is only recalculated if there is a perturbation. Anyway, such things should be discussed on the [https://sourceforge.net/p/jsbsim/mailman/jsbsim-devel/ JSBSim development mailing list]. | |1= Maybe if internal perturbations are disabled when time is not normal, the full trajectory in space could be calculated once and the spacecraft made to follow that pre-determined trajectory. If the trajectory requiresero updates, then accelerated time should not be a major issue. This might be quite contrary to the current design of JSBSim though. Hence why I often mention a SpaceFDM instead. Though maybe JSBSim simply requires a 'mode change' that includes 'sleep states' where the trajectory is only recalculated if there is a perturbation. Anyway, such things should be discussed on the [https://sourceforge.net/p/jsbsim/mailman/jsbsim-devel/ JSBSim development mailing list]. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269197}} | ||
| title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | | title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | ||
| author = <nowiki>bugman</nowiki> | | author = <nowiki>bugman</nowiki> | ||
Line 248: | Line 248: | ||
|1= I can compute half an hour worth of trajectory with reasonable accuracy (I think no more 100 m off for a whole orbit) within approximately a second. So that's a compression factor of ~2000 which I can achieve by just doing lots of timesteps following each other (I think that's a 0.05 s interval). For anything more, you would have to jiggle with the timestep. | |1= I can compute half an hour worth of trajectory with reasonable accuracy (I think no more 100 m off for a whole orbit) within approximately a second. So that's a compression factor of ~2000 which I can achieve by just doing lots of timesteps following each other (I think that's a 0.05 s interval). For anything more, you would have to jiggle with the timestep. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269206}} | ||
| title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | | title = <nowiki>Re: Implementing moonlight (or not)</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> |
Latest revision as of 11:27, 8 June 2019
This article is a stub. You can help the wiki by expanding it. |
Note In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives).
While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible. |
Space flight |
---|
in FlightGear |
Space Shuttle |
Vostok-1 |
Background
going to moon is *not* primarily a rendering question - it is a question of the numerical stability of the FDM. At distances of a million kilometers, even small rounding errors tend to become very large over time. Most people are likely not to sit 3 days in front of their computer but do the trip in fast-forward time. Yet the spacecraft is in vacuum, there is *no* damping force for any tumbling or other motion, so you have to ensure that the spacecraft motion is accurately computed across a really large distance in fast-forward time without you emerging in wildly spinning motion. At the same time, you have to solve a multi-body gravitational problem to some accuracy. Mars is worse by about two orders of magnitude.
I'm not convinced that JSBSim is up to that out of the box. — Thorsten (Mar 24th, 2012). Re: Earthview - an orbital terrain rendering engine [v0.1].
(powered by Instant-Cquotes) |
I have been referring only to operating only in the vicinity of a single planetary body, such as Earth, Moon, Mars, etc.
Regarding entry, a better high altitude atmosphere model would help a lot. Right now we use the standard atmosphere, and as I recall we have sort of extended that at high altitude. Our current default atmosphere model is not relevant to any kind of real research. We do have another atmosphere model that might be a lot better, but I have not yet tried it in this application. It's the MSIS atmosphere model, and it is in our atmosphere/ subdirectory. Also, regarding orbital flight, I recently did a comparison between JSBSim and STK (Satellite Toolkit) for a highly elliptical orbit over a 24 hour period. The results were very close. See the JSBSim Facebook page for the details. ( http://www.facebook.com/jsbsim ). |
we need the instruments to do precise orbital maneuvering around earth before even thinking to leave earth orbit, because if we can't compute a launch trajectory to ISS, we can't compute the ejection trajectory to moon or any correction burns either. Having a deep space FDM right now is useless for us, because we can't even test it in a reasonable way. — Thorsten (Mar 25th, 2012). Re: Earthview - an orbital terrain rendering engine [v0.1].
(powered by Instant-Cquotes) |
Motivation
the issues are not the equations of motion - they're easy to write down and code. The problem is to solve them numerically in a long-term stable way so that fast-forward in time works, and Nasal (being tied to graphical frames) is particularly troublesome for this task.
But as a next step, I would suggest that the AI system is expanded to allow to place AI objects in a stable orbit with orbital parameters to be determined in the AI scenario xml. Then we need the instruments to display such information and the tools to in-simulation calculate launch windows, orbital intercept points, the time window for tilting the orbital plane, and these things. — Thorsten (Mar 25th, 2012). Re: Earthview - an orbital terrain rendering engine [v0.1].
(powered by Instant-Cquotes) |
An FDM simulating real orbital mechanics, which properly handles the three-body problem, is required for any moon adventures. Then the FlightGear time acceleration framework would be useful (the [a]/[A] buttons), and the maximum acceleration of x32 extended to higher values. But the orbital mechanics is currently missing. It needs to be implemented in JSBSim. Or in a new orbital/space FDM which can be hot switched to on the FG side. In any case, there is a lot of work ahead. |
FDM
We need no more and no less than what I wrote - a numerically stable solver for orbital dynamics. The accuracy of analytical orbits seems quite enough though. |
AI
That about is the math you have to encode, and then you have to get it numerically stable.
(You have two objects moving with 8 km/s alongside such that their relative motion is close toero, but our coordinate system is not the inertial system in which they're moving but co-rotates with Earth since our infrastructure is for a flightsim where we don't need non-rotating inertial reference frames. The rotation is (dependent on latitude) a bit faster than speed of sound, so you need to get all the numbers to some precision and without numerical jitter if you aim at cm/s docking velocities). Doing a 3d model of the ISS should be easy by comparison. |
Requirements
could there be a 'portal' to go to the Moon or Mars, since not many have a couple of days to spare flying a spaceship to the moon? |
ou can always accelerate simulator time and/or reposition your vehicle at run-time.
Also see the "planets" discussion here, including the links to related devel list postings: [1] |
Maybe if internal perturbations are disabled when time is not normal, the full trajectory in space could be calculated once and the spacecraft made to follow that pre-determined trajectory. If the trajectory requiresero updates, then accelerated time should not be a major issue. This might be quite contrary to the current design of JSBSim though. Hence why I often mention a SpaceFDM instead. Though maybe JSBSim simply requires a 'mode change' that includes 'sleep states' where the trajectory is only recalculated if there is a perturbation. Anyway, such things should be discussed on the JSBSim development mailing list. |