SpaceFDM
| 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) |
|
|
|
Leaving LEO (i.e. Apollo, pictures from Mars,...): Here, you have a multibody gravitational problem - on a trajectory to Mars, there is the gravity of Earth on leaving with a correction by the Moon, of Sun during most of the trajectory, and of Mars on capture. In this complicated gravitational field which varies over time, you need to have your trajectory stable over a time period of 3 months (!) or so while users go fast-forward with simulation time. At the same time, you can do the math how far 0.1 degree deviation in your trajectory simulation by numerical errors would displace you 250.000.000 km later on arrival. That's a problem that's simply not there in a Flightsim. Even tiny forces accumulate to substantial effects over long times with no dissipative effects around - magnetic fields, light pressure, solar wind.
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. |
|
|
|
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) |
|
|
|
I think we're talking two different issues here:
1)Short, low orbit flights: Here I believe that the issues are reasonably well under control. I believe that if you have the right table of coefficients, you will get reasonable answers. The issue is that the atmosphere is, as in a Flightsim, the dominant dissipative force and any deviation from constant gravity is small, gravity is dominated by Earth and you require stability of orbits on relatively small timescales, because an orbit in the upper atmosphere is probably physically unstable before it becomes numerically unstable. I remain skeptical about the re-entry physics though, especially if it handles deviations from the default profile correctly. But I'll let myself be convinced by results - so once I have more time, I'll have a look how the Vostok behaves on re-entry. 2) Leaving LEO (i.e. Apollo, pictures from Mars,...): Here, you have a multibody gravitational problem - on a trajectory to Mars, there is the gravity of Earth on leaving with a correction by the Moon, of Sun during most of the trajectory, and of Mars on capture. In this complicated gravitational field which varies over time, you need to have your trajectory stable over a time period of 3 months (!) or so while users go fast-forward with simulation time. At the same time, you can do the math how far 0.1 degree deviation in your trajectory simulation by numerical errors would displace you 250.000.000 km later on arrival. That's a problem that's simply not there in a Flightsim. Even tiny forces accumulate to substantial effects over long times with no dissipative effects around - magnetic fields, light pressure, solar wind. 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? |
|
Motivation
|
|
Numerically, orbital simulations need to be long-term stable because there's no dissipative force to dampen perturbations away. Orbits continue over days - your calculation of the orbit should not accumulate mistakes over such times. Not so for atmpspheric flights, where any perturbation is quickly damped away by drag on the timescale of seconds to minutes. |
|
|
|
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. |
|
|
|
The precision of the variables is not the issue, the issue is reaching the necessary precision and long-term stability in the computation. Even floating point precision is good enough to resolve the world on a ~10 m scale (we know that from applying shaders in world coords).
The algorithm needs to be stable against perturbations and self-correcting. Whether it's done in Nasal, xml or C++ is rather irrelevant. |
|
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. |
|
|
|
Currently objects are persistent till they get deleted because of a distance cut. There's no need to delete them though. After analying 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. |
|
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]  |
|
|
|
Only if your underlying trajectory simulation code is numerically stable enough to do that. Which JSBSim was never tested for if I remember Jon correctly.
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. |
|
|
|
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. |
|
|
|
The easy way out of that problem is to still run JSBSim with the normal time step length, just more of them per real second - though that will only allow you to accelerate simulation time up to the capacity of your CPU core. For none too complex FDM configurations that should still easily be above 10x.
However, IIRC that is not how FG does acceleration today. (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.) |
|
|
|
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. |
|
|
|
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. |
|