A question about orbits

[Milorgmannen]

Hi,

I'm toying around with making a Low Earth Orbit RTS, purely just to see if it could work.

But I'm wondering if my orbits are realistic. Currently any orbit that is not circular but like an ellipse will "move" its highest point around the earth each orbit.

Like this.

Playing KSP makes me thing that something is wrong here.

Is it?

[KSK]

Is the planet rotating? It looks like you're displaying things from the 'wrong' frame of reference, so that rather than displaying a fixed orbit with a rotating planet, you're displaying a fixed planet with a rotating orbit. Both are valid but the first one might be more intuitive to use!

[Milorgmannen]

The planet is not rotating.I wasn't thinking of that

[Frida Space]

Is the planet rotating? It looks like you're displaying things from the 'wrong' frame of reference, so that rather than displaying a fixed orbit with a rotating planet, you're displaying a fixed planet with a rotating orbit. Both are valid but the first one might be more intuitive to use!

Having read space-news for many years now, I have to say that the second one, althought less intuitive (for me, that is), is often the most used, especially by NASA & Co.

[Greenfire32]

Yeah, like KSK said, you have to take planet rotation into effect. If you were to observe the orbit from the surface of the planet, it would appear as if the orbit was moving around the planet.

Sort of like how we say the sun is "rising" or "setting," but it's actually Earth's rotation causing that effect.

[merendel]

The apoapsis (highpoint) of the orbit will stay in roughly the same alignment relitive to a fixed referance point from orbit to orbit. If its over the "Dawn" line one orbit it will still be over the dawn line when it gets back to apoapsis the next time. The earth will be rotating under that orbit so the apoapsis may be over Russia the first time, Europe the second and the USA on the third orbit but it will still be at dawn in the short term. Over the year it will appear to shift as the earth moves around the sun, the orbit itself wont have changed just the frame of referance. from a top down view of the solar system if the apoapsis is south of earth it will stay south of earth even 6 months later when its now over sunset instead of dawn.

This is of course ignoring N body physics where the gravity of other moons/planets can alter the orbits but thats probably beyond the scope of what your looking at. Asumeing your not viewing the solar system as a whole in the scope of your game and your looking for a simi realistic eliptical orbit I'd recomend useing the day/night terminator as your referance point. If your only looking at a few days timeframe dont bother moveing it around from orbit to orbit as the shift will be negligible. if going for realism and many months of time are passing it will shift relative to the terminator about 2 hours per month so its going to be quite a few orbits before the effect is noticeable to the naked eye

[TythosEternal]

Currently any orbit that is not circular but like an ellipse will "move" its highest point around the earth each orbit.

Periapsis and apoapsis will always be, by definition, the lowest and highest points in the orbit, respectively. You are trying to show the same orbit rotated about the central body, but orbits one and three appear to have both a) different periapsis and apoapsis altitudes and still share the same point of intersection with orbit two, which is not possible unless the shape of the orbit has also changed.

An orbit is fixed inertially unless a non-"restricted two body" force (like a reaction thruster during a maneuver, the gravitational pull of a third body, or the non-spherical components of the central body's gravitational field) changes that orbit. An orbit is not fixed with respect to the surface of the planet, because the surface is not inertial (it is spinning). An orbit is not fixed with respect to the sun, because the central body (I am assuming we are talking about a planet here) is also moving about the sun. Of course, the sun-centered frame of reference isn't inertial either, but it's sufficiently close for accurate orbital calculations.

If its over the "Dawn" line one orbit it will still be over the dawn line when it gets back to apoapsis the next time.

This is decidedly NOT the case. As the earth moves about the sun, the sun's position w.r.t. the earth changes noticeably over the course of even one orbit. There is a special type of orbit ("sun-synchronous") that uses higher-order gravitational perturbations (specifically, the oblateness of the earth) to recess (rotate backwards) its nodal line (orbital plane) to make sure the mean solar time at nodal crossings remains constant, but this is a special case.

LEO orbits can be tricky to model in a ground-fixed frame (I assume, given that you are writing an RTS, that you want to manipulate your orbits w.r.t. the ground) without doing full-up orbit propagation, but it's not impossible by any means. One of the simpler approaches might be to assume all the spacecraft in your environment have been placed in circular orbits, which simplifies the equations of motion considerably into something a decent programmer like to yourself would have no problem implementing for your game to compute in real-time.

[Bill Phil]

Clearly it has to do with frame of reference issues.

[K^2]

Hi,

I'm toying around with making a Low Earth Orbit RTS, purely just to see if it could work.

But I'm wondering if my orbits are realistic. Currently any orbit that is not circular but like an ellipse will "move" its highest point around the earth each orbit.

Playing KSP makes me thing that something is wrong here.

Is it?

This is definitely wrong. Argument of periapsis (location of lowest point) can drift for a number of reasons. Most likely, you have some numerical errors. If you can post the portion of the code that you use to evaluate orbit, we can look for an actual error.

[N_las]

I had the same issue once. You are probably using the Euler methode to calculate your trajectory. http://en.wikipedia.org/wiki/Euler_method

You can fix this by using a more complicated methode of calculation.

You are probalby calculating the force and subsequent acceleration at the "current" moment.

Then you are adding the acceleration (times the time-step-size) to your "current" velocity to get the "new" velocity.

Then your are adding the "new" velocity (times the time-step-size) to your "current" position to get the "new" position.

If that is true then I can explain how to fix it.

[TythosEternal]

I had the same issue once. You are probably using the Euler methode to calculate your trajectory

The Euler method is unstable for inverse-square propagation, but the error mode results in non-conservation of energy. Euler will show you an orbit that is slowly shrinking (or growing) over time, but the shape remains the same. What he's describing here is a frame issue.

Milorgmannen, are you also managing things on the ground, or is the RTS purely on space? Are you flying in a localized area, or does your RRS span the entire volume about the planet? Can you post your orbital code and tell us what you are trying to make it do? The more we know, the more we can help.

Edited January 15, 2015 by TythosEternal
adding question

[K^2]

Euler does both. Energy will increase, and argument of periapsis will precess. One can be more noticeable than the other.

[Milorgmannen]

I had the same issue once. You are probably using the Euler methode to calculate your trajectory. http://en.wikipedia.org/wiki/Euler_method

You can fix this by using a more complicated methode of calculation.

You are probalby calculating the force and subsequent acceleration at the "current" moment.

Then you are adding the acceleration (times the time-step-size) to your "current" velocity to get the "new" velocity.

Then your are adding the "new" velocity (times the time-step-size) to your "current" position to get the "new" position.

If that is true then I can explain how to fix it.

That would be precise what I'm doing I didn't know anything about orbits other than KSP before I started, all I have is Wikipedia

The drawing was not quite accurate but my point was that it seemed like the orbits were shifting.

I'm only modelling space combat in LEO. Currently I have no idea of how to make it work, but it is fun just trying to find out what that would work, and what that doesn't, I have studied all kinds of warfare on earth, I figured it was time to look to the sky.

First problem other that weird orbits is that space even around earth is huge, I have to make the tools needed to find and destroy enemy ships.

I decided to simplify things by going 2D, and I might go for a micro earth later if I continue to have problems finding the enemy ships

The interesting part is here. It might just be a rounding error?

//Each orbiting object

int bb = 0;

while (bb < orbitingObjects.Count)

{

//Apply gravity

orbitingObjects[bb].radius = Math.Sqrt(Math.Pow(orbitingObjects[bb].position.X, 2) + Math.Pow(orbitingObjects[bb].position.Y, 2));

double gravityVelocity = earth.gravity * (earth.mass / Math.Pow(earth.radius, 2)); //earth.mass = 5.975e24; earth.radius = 6.37814e6;

orbitingObjects[bb].angle = Math.Atan2(orbitingObjects[bb].position.X, orbitingObjects[bb].position.Y);

orbitingObjects[bb].velocity += new Vector2((float)(Math.Sin(orbitingObjects[bb].angle) * gravityVelocity), (float)(Math.Cos(orbitingObjects[bb].angle) * gravityVelocity));

//Move item

orbitingObjects[bb].position -= orbitingObjects[bb].velocity;

bb++;

}

[N_las]

You are first calculating the distance between your ship and the middle of the earth (the middle of the earth is at (0 ; 0) in your simulation?)

Then you calculate a "gravity velocity"? ( G*M_Earth / r^2)

This is actually an acceleration you are calculation here, not a velocity.

You are correctly fighting the angles ( atan2(x,y) instead of atan(x/y) )

Then you are saying the new velocity is the the old velocity plus your calculated "gravity velocity"

Then you move the object by said velocity (why -= instead of +=)?

First: You should define a step size: How much time (in your simulation) is going by during each calculatin cycle (in seconds or something).

StepTime = 10

Then you can calculate the CURRENT radius (exactly as you do now). This represents the radius you have at the beginning of each calculation cycle.

r_current = blabla

then you calculate the CURRENT accelration due to gravity (exactly as you calculate your "gravityVelocity":

a_current = - G*M_Earth/(r_current^2)

The minus is very important! You do want an attracting planet.

Then you caculate your CURRENT angle:

angle_current = blabla

Assume you know v_current.

Then you calculate the PROJECTED velocity that you would have AFTER the cycle (if the distance and angle wouldn't change)

Something like this, exept you have to somehow take the current angle into account... I haven't done that here)

v_projected = v_current + ( a_current * StepTime )

But v_projected is the projected velocity you have AFTER the step time. (while v_current is the velocity you have BEFORE the step time).

For your calculation you want the mean value between both (the estimated mean velocity DURING the step)

v_effective = (v_projected + v_current)/2

You now know v_effective. With that you can calculate the projected position:

position_projected = position_current + (v_effective * StepTime)

It seem like the calculation is finished here, but that is not true:

The projected position you just calculated is just the first estimation. You now have to use this estimation to calculate a more exact result:

1.) use the projected postion to calculate a projected radius (the radius you would have at the end of the cycle) r_projected

2.) use the projected radius to calculate the projected gravity acceleration (the acceleration you would have at the end of the cycle) a_projected

3.) do the same angle stuff as before to calculate the projected angle (the angle you would have at the end of the cylce) angle_projected

4.) calculate the mean of the current acceleration and the projected acceleration to get the effektive acceleration (you also have to calculate the effective angle in the same manner)

5.) do the same stuff as before to calculate a "better" projection of the velocity (and take somehow the angle into account)

v_betterProjection = v_current + ( a_effective * StepTime )

6.)

Use it to calculate a better estimation of the effective velocity (the mean velocity between the current velocity and the betterProjection velocity9

v_betterEffective = (v_current + v_betterProjection) /2

7.)

With v_betterEffective, you can now calculate a much better estimation of your projected position:

position_betterProjection = position_current + (v_betterEffective * StepTime)

This "position_betterProjection" is now a much better value as your previously calculated new position.

You have to end the cycle.

Don't forget that your "position_betterProjection" becomes your "positon_current" for the next cycle.

And your "v_betterProjection" becomes your "v_current" for the next cycle.

The methode I described here is the Heun-Methode (you originally used the Euler-Methode).

While it doubles the computational effort, it is worth it: You can find tons of example all over the internet how it gives much better results:

https://controls.engin.umich.edu/wiki/images/1/13/Slopedepiction.JPG

Edited January 18, 2015 by N_las

[Waterlimon]

Instead of using a better integration (your problem is basically using a bad integrator, check ones like leapfrog algorithm or RK4 or whatever) technique (which is an approximation, like eulers method assumes velocity is constant over a frame, when its not, and better methods assume the velocity changes linearly or is given by a polynomial or other such approximations), you could do what KSP does for orbits and describe them explicitly.

What this means is that you actually calculate the orbital parameters (eccentricity, inclination, whatnot, i dont know, google for relevant material) and save that as the orbit.

This means you can calculate the exact position of the orbiting body based on time, with no drifting whatsoever (since you saved the exact orbit instead of it just forming as a result of inaccurate physics approximations)

Of course you need to update this saved orbit data when nongravity forces act on the craft, which means it wont really work if theres a constant force like a thruster thats constantly on acting on the craft.

Use explicit orbits if the orbits remain unchanged for long periods of time, thus avoiding numerical accuracy errors.

[K^2]

You can, actually, recompute all of the physics to act on orbital parameters directly. This is something that KSP doesn't do. KSP does it exactly like you say. It takes velocity and position and computes the 6 orbital elements. Semi-major axis, eccentricity, inclination, argument of periapsis, longitude of the ascending node, and mean anomaly at epoch. If you apply a force, it recomputes velocity, then recomputes the orbital elements. That's why sometimes you see the orbits shake a little for your current craft. While warping, or if physics isn't being simulated, you usually go "on rails". That is, you'll just follow along a fixed orbit.

The other way to do this is to work with constants of motion directly. There are also six, and they are closely related to orbital elements above. Energy, angular momentum, z-component of angular momentum, time of periapsis passage, argument of periapsis, and longitude of the ascending node. The best part is that they are constants of unperturbed Hamiltonian, they have rather simple laws of motion. In fact, they are just Hamilton's Equations on perturbation potential. For example, the equation for the rate of change of energy is dE/dt = -∂U/∂T. Here, U is effective potential of the applied force. In other words, what you really know is that ∂U/∂x = -F_x, and so on. If you apply the chain rule a whole bunch of time, you'll find that dE/dt is equal to dot product of velocity and force, which is exactly what you expect. Some of the other results are a bit less trivial, and they are almost nightmarish to derive. On the other hand, once you have these equations derived, you can apply forces directly to orbital elements, and then you don't have to worry about your energy running away, like it does with Euler method (or even higher order methods, to lesser extent) or oscillating, like it does in KSP.