2
$\begingroup$

enter image description hereFirst - my question: After the orbit insertion, in the coast stage, and assuming perigee is out of the atmosphere, and neglecting any external forces and influences - is the orbit now "fixed"? As in, should apogee, perigee, eccentricity and inclination now be fixed values?

A bit of a background:

I am working on a spaceflight simulator FSX SpacePort, and currently, I am implementing cockpit instrumentation. I have a display that shows the location of my spacecraft, as it ascends on a trajectory towards the orbit. The display is dynamic - it shows the orbit's changing shape as the spacecraft progresses towards its intended orbit.

I have implemented an algorithm and pseudo code I found here (using C++), and in this basic form, all works and looks good.

When I reach apogee and try to circularize, and as eccentricity nears 0, I cut out my first stage engines. Because the engines have a bit of a ramp-down time, it is always a bit of a guess when to cut the engines off so that the eccentricity would be as close to 0. I do this manually, and I might put in some algorithm in the future to do this for me.

The problem I have is, after the engines are off and the launch stack is coasting, the parameters of my orbital ellipse keep changing - by a small amount at first, but then, progressively faster, the perigee descends back into atmosphere and I eventually crash into the ground.

I thought that, without any external forces, the orbit is "stable" - the orbital parameters (apoapsis, periapsis, eccentricity...) would be fixed and not changing. Before I check my physics code (which has so far been reliable), I thought I checked first if I fully understood the astrodynamics.

thanks!

edit: I added the screen caps of the orbital display. The time stamps are at the bottom, the 3 images show the span of about 10 seconds. You can see how, a, b, e, apogee and perigee (values are in km, above ground) are changing... inclination is rock steady. Symbols: - diamond is the spacecraft position - full dot is apogee - hollow dot is perigee - also, "apo" and "per" numerical readouts are flipped, it's a bug...

edit 2: OK - My physics guy looked at my code, and almost immediately saw what I was doing wrong - and it kind of surprised me: I was assuming that my gravitational constant was indeed a constant, at 9.81 m/s^2. At orbital altitudes, it is actually a variable that depends on altitude. I inserted 2 lines of code that properly calculated the g vs. altitude relationship, and sure enough, the values are rock steady, exactly where they should be! So - the problem was in me assuming a "constant" gravitational constant!

Improve this question
$\endgroup$
5
  • 1
    $\begingroup$ Are you integrating the forces acting on the orbital vehicle and calculating the resulting accelerations? $\endgroup$
    – Organic Marble
    Mar 13, 2019 at 17:48
  • $\begingroup$ I am using an "off the shelf" physics library, so I am not fully familiar with the inner workings of it. But I can (and did) check the values I am passing to it, and the only force passed is the gravitational force. The physics engine calculates the state vector based on that, and the object's velocity vector. The engine is quite robust and I haven't had any major issues with it so far. I DO have the personal attention of the author of the engine, but before I raise this with him, I thought I checked here first. Thank you! $\endgroup$
    – Mitch99
    Mar 13, 2019 at 18:03
  • 1
    $\begingroup$ I had some really weird problems using keplarian elements as the eccentricity approached 0. By using very small numbers like 0.000000001 I was able to still plot them using my basic equations. If you're using orbital equations, the case for eccentricity = 0 is a unique one that requires unique versions of each formula (well, kind of). It could be floating point calculation errors that seem small, but add up. $\endgroup$
    – Magic Octopus Urn
    Mar 13, 2019 at 18:05
  • $\begingroup$ Yes, that might be valid for the display - and indeed, at eccentricity approaching zero, it gets all "flippy" and I had to insert a special case to "flip" my display by 180 to show correct orientation. But after it gets "flippy" ;) (or before, if I cut engines), the numbers are changing without any external forces... $\endgroup$
    – Mitch99
    Mar 13, 2019 at 18:17
  • $\begingroup$ Not only "yes" - these all also work for suborbital trajectories - with the obvious disclaimer of crashing into the surface. But you can project a rendez-vous between a spacecraft in LEO and a spacecraft launching with the orbit passing through the launchpad and apogee somewhere near Earth core, all using plain old orbital mechanics as always, with the only disclaimer of only certain range of values of true anomaly being allowed. Essentially, the border between ballistics and orbital mechanics is very blurred. $\endgroup$
    – SF.
    Mar 14, 2019 at 10:36

2 Answers 2

Reset to default
5
$\begingroup$

If the spacecraft is out of the atmosphere, and the modeling is two-body (e.g. Earth and spacecraft and no other massive bodies are present in the model), and solar wind and other effects are not modeled, then yes, apogee, perigee, eccentricity and inclination should remain fixed.

If that's not what you're observing, then either the simulation thinks some additional force is still acting, or there's a problem with the simulation engine.

The orbital parameters changing "by a small amount at first, but then, progressively faster" is suggestive of atmospheric orbital decay, so my first questions would be:

  • What altitude is your orbit?
  • How do you know that FSX SpacePort considers that to be "out of the atmosphere"?
  • What happens if you insert into a much higher circular orbit, say, twice the altitude?
Improve this answer
$\endgroup$
14
  • 2
    $\begingroup$ or it suggests a system that is having incremental numerical accuracy issues because the model is at the edge of the precision of the floating point system used. $\endgroup$
    – Paul S
    Mar 13, 2019 at 17:59
  • 3
    $\begingroup$ If the physics engine is for a flight simulator maybe it doesn't include (and I hate to bring this up because of history on this site) centrifugal force which (from a engineering perspective) holds the vehicle in orbit. Is your vehicle following a parabolic trajectory (basically falling) down once the engines cut off? Given a 5-10 minute time frame, it kind of sounds like that. $\endgroup$
    – Organic Marble
    Mar 13, 2019 at 19:30
  • 2
    $\begingroup$ @Organic Marble,, I have the ability to override the Flight Simulator physics engine, with my own, or in my case, third-party physics library. So, the code is there, except there is a drift error. A few hours ago I heard back from the author of the physics engine, and indeed, it seems to be a problem that exhibits in my special case: "you are applying a non linear force to the body but a simple semi implicit integrator is not enough to reproduce a large scale integration."... he is working on the solution for my case. $\endgroup$
    – Mitch99
    Mar 13, 2019 at 21:15
  • 1
    $\begingroup$ If you calculate a delta position of a fraction of a millimeter at a time, over a 50,000 kilometer orbit you have 50*e3*1e3*1e4 = 50e10 opportunities for rounding error. $\endgroup$
    – Paul S
    Mar 13, 2019 at 23:38
  • 1
    $\begingroup$ @Paul S, thanks! I did find what was happening - it is in my edit #2 in the original question! $\endgroup$
    – Mitch99
    Mar 14, 2019 at 8:07
1
$\begingroup$

Ok, a little while ago I heard back from the author of the Physics Engine, and this seems to be a special case for the engine, that requires a bit of enhancement. It is at the edge of my understanding, but basically,

"you are applying a non linear force to the body but a simple semi-implicit integrator is not enough to reproduce a large scale integration. There you need to implement a mini integration step to advance the model in time, then use that value as a correction force. The engine does that for angular acceleration, but not for gravitational acceleration, for gravity if G is constant, the Semi implicit integrator is accurate enough."

From what I understand, the direction of my gravitation vector is constantly changing (Earth is not flat!) and the integrator has trouble keeping up.

I will mark answer #1 as the correct answer, since it answers what I asked.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.