Determining speed relative to surface (ground speed)

[malcontent]

I have been working on a simulation and have got a spaceship in orbit around a planet. Now I want to present some information useful for navigation, in particular for landing on the surface. So the speed the surface moving under you is important, but for the life of me I can not figure it out or find the right information on the web (or the math forum)

I have two hunches. The first is that I need to find the tangential plane to the surface of the planet and project the velocity vector onto this plane, which will match the vector you find in this plane for the velocity of the rotation of the body. This is not a simple orthogonal projection though, so there I get stuck.

My second hunch is that there's a chance converting the vector represention to Kepler elements might be better, scaling the distance between two moments in time to the circle the ship orbits, but perhaps this is only easier in the idealised circular, non inclined orbit. (Isn't everything?)

Some details:

This simulation is running on a 1mhz Commodore 64, so it's highly likely the code to calc the speed, will take as long as updating the physics, I might have to forego considering the rotation speed, but basically the point is I am looking for a method that is both computationally cheap, and memory friendly. Approximations are okay, because of the resoloution of the dimensions, you'll be landing at unrealistic speeds anyway. I have slow and accurate trig routines, and fast and approximate ones, so with lots of fast trig the errors compound.

Any pointers are appreciated. Nice to be on this forum, and hope to have anyone interested flying an 8-bit spaceship soon.

 

[Thorsten]

(I'm going to assume that since you have orbital elements, you have a planet-centered coordinate system available but are using inertial rather than co-rotating coordinates - if not you might need additional transformations).

So, if the planet center is at (0,0,0) and you define the z-axis to point towards the north pole and the x-axis towards some inertial reference direction, you can construct a local horizon coordinate system as follows:

* the normalized position vector of the spacecraft is the radial (or 'up' direction). That's because the position vector points from the center of the planet upward to the craft, so if you normalize it, you get a unit vector in the right direction.

* now take the dot product of the spacecraft velocity with the normalized up vector. The result is the upward velocity component magnitude of the spacecraft. Multiply that with the up unity vector to get the upward vector velocity.

* vector-subtract that from the total spacecraft velocity - that's the horizontal velocity component - let's call that v_H

* normalize that - you get a horizontal direction vector, we call it 'forward'

(* do a cross product of 'forward' and 'up' and you get the 'normal' direction unit vector)

Now, if you've done it all correctly, v_H is a 3-vector containing the forward velocity over a non-rotating planet surface. So if you have the velocity vector of the rotating planet, you can simply subtract them and you're done.

Thus, we need the velocity vector of the surface.

* a point at the equator and the chosen inertial reference will be at (R,0,0) initially with R being the planet radius

* over time t, it will displace in longitude by lambda = omega * t where omega is the rotation speed in deg/s, so the point will be at (R* cos(lambda), R* sin(lambda), 0)

* the speed is the time differential of that, so (-omega * R* sin(omega * t), R *omega * cos(omega * t) , 0)

* a point at a higher latitude phi will initially be at (R * cos(phi), 0, R * sin(phi)), so you can see that the velocity vector gets an additional cos(phi) which makes it vanish at the poles at phi=90 deg

So now you can evaluate that and subtract.

(There may be signs off in the definitions used in the derivation - the aim is to give you the general idea, not to provide a ready-made expression. There's also other ways to organize the computation.)

 

[RisingFury]

IIRC there are two functions that do that for you:

GetHorizonAirspeedVector() , which gives you the airspeed relative to the horizon, but I think this one includes wind. IIRC, there's another that excludes wind. You'll have to look it up in the API Reference.

 

[Thorsten]

He's doing it on a Commodore 64 - I frankly think it's unlikely that he can access the Orbiter API

 

[Hielor]

If approximate is okay, and CPU cycles are critical, have you considered using a stepwise method of estimation?

E.g., at each timestep find out what the point on the surface directly under the vehicle is, and then compare the distances between them each timestep. Divide by the timestep duration and you've got the estimate.

Not sure if you'd have the precision for that on the single-timestep scale, though; depending on timestep duration the distance might be too miniscule.

In fact, since this value doesn't change very often, it may be sufficient to just do the calculation once a second, and update then.

 

[Thorsten]

That's a clever and very resource friendly one!

 

[malcontent]

The estimate sounds great. It seem also I could get a velocity vector between 2 points to compare to the planet's rotation?

Timestep is one and never varies, so I would not need the division unless converting units.

Thorsten: I'm still interested in what you wrote. It gets me the vertical velocity which is important for landing as well. But I'm confused it seems to just compare two vectors together without scaling them for distance.

The calculation of the rotation makes more sense, but it's weird to me that something that is known - the speed of rotation - should be calculated, however when I think of just constructing a vector and rotating it, the radius must be taken into account as well, so maybe you do all that in one step?

Thanks for your replies.

 

[Col_Klonk]

If approximate is okay, and CPU cycles are critical, have you considered using a stepwise method of estimation?

Find the 6502 CPU datasheet...Crystal/RC statistical stability.. Yeah.. love that one.
:tiphat:
Not to mention the C64 circuit diagram... really cool.
Not impossible... have fun

 

[malcontent]

Ok so normalizing a vector is not computationally cheap, three divides by the square root, but I have discovered that instead you can multiply by the inverse square root. There is the Quake 3 method of quickly finding inverse square roots which I have already adapted for c64, and my multiply is much faster than my divide, so I think this is the fastest way to find the point under you on the sphere. The only other way I can think of (using atan to get angles then multiply sines/cosines of the angle to the radius) is to slow even with my speedy trig approximations. Unless something from the black arts of trig I know nothing about, like haversine, etc, might help me, I have only just started reading about spherical trig with the idea that it might help, but vector representation (especially when you start with it) often seems to be cheaper computationally, at least in my admittedly very specific circumstance.

 

[Hielor]

If you convert to polar coordinates, scaling to the surface of the planet becomes trivially easy

 

[malcontent]

Sure it's trivial with a calculator, but sin/cos/arctan are calculated with a Taylor series which require a succession of multiplications and divisions. One call to a trig function on a 1Mhz computer takes up more than an entire video frame. I have faster, approximate trig functions that use polynomials, but the errors compound when too many are used in conjunction.

 

[Thorsten]

I'm still interested in what you wrote. It gets me the vertical velocity which is important for landing as well. But I'm confused it seems to just compare two vectors together without scaling them for distance.

You got me confused.

The original question was about a velocity ('speed relative to the ground'). Mathematically that is a vector (and the length of the vector is what your gauge would show).

Veocity vectors are not scaled for distance - their difference is the same no matter the distance between the objects (well, short of curved spaces...)

Also if you take ('position in this frame' - 'position of last frame')/'frame duration' you get a difference between two three vectors, which is a three vector.

The calculation of the rotation makes more sense, but it's weird to me that something that is known - the speed of rotation - should be calculated

First, you know it as angle/time. For points on a sphere, that's very different in distance/time dependent on whether you are on the equator or at the pole.

Second you know it in spherical coordinates, but your velocity vector typically is in inertial Cartesian ones - so you need to transform.

You're not calculating the rotation speed itself - you're applying the required transformations to make use of it.

(As Hielor indicated, you can of course turn the problem around and represent your craft's position in spherical coordinates - then factoring in the rotation is trivial, but projections for rendering and relative distances become more complicated).

 

[Face]

Sure it's trivial with a calculator, but sin/cos/arctan are calculated with a Taylor series which require a succession of multiplications and divisions. One call to a trig function on a 1Mhz computer takes up more than an entire video frame. I have faster, approximate trig functions that use polynomials, but the errors compound when too many are used in conjunction.

Lookup tables. Most 8bitter code I've tinkered with used lookup tables with interpolation to do quick trig functions. Nice article in this regards: https://jfdube.wordpress.com/2011/12/06/trigonometric-look-up-tables-revisited/

 

[malcontent]

You got me confused.

The original question was about a velocity ('speed relative to the ground'). Mathematically that is a vector (and the length of the vector is what your gauge would show).

Veocity vectors are not scaled for distance - their difference is the same no matter the distance between the objects (well, short of curved spaces...)

Okay, I get what you are saying, and perhaps my wording of the question was poor (damn you relativity!) But it is about the distance covered over the surface over time. A ship traveling at 10kps 1000 km away is travelling faster over the surface than one travelling at 10 kps 2000 km away right? Assuming the same direction of course.

Lookup tables. Most 8bitter code I've tinkered with used lookup tables with interpolation to do quick trig functions. Nice article in this regards: https://jfdube.wordpress.com/2011/12/06/trigonometric-look-up-tables-revisited/

Yes. LUTs are the way to go on 8-bit machines when you are using integer math but I am using floating point. Each number is five bytes long, so a table with just 500 elements is 2.5k large. You can have small tables and do something like CORDIC, but when you are compromising accuracy by using smaller and smaller tables, but still using so many divides, the trade off begins to favor faking sine with parabolas, which only take a few multiplies and no extra memory for tables.

 

[Hielor]

Okay, I get what you are saying, and perhaps my wording of the question was poor (damn you relativity!) But it is about the distance covered over the surface over time. A ship traveling at 10kps 1000 km away is travelling faster over the surface than one travelling at 10 kps 2000 km away right? Assuming the same direction of course.

In any given timestep, the angle traversed by the ship is going to be fairly tiny, which means the cosine will be fairly close to 1.

As a result, I suspect but am too lazy to prove that the distance over the surface in a given timestep is approximately proportional to the tangential distance travelled (relative to the center of the planetary body) in the same ratio that the radius of the planetary body is proportional to the orbit radius of the object; at least close enough for display to the end user. That is, if the body has radius 1000km and the orbit is 1000km above the surface (orbit radius 2000km), I suspect that the speed over the surface will be approximately half of the (tangential) orbital velocity.

Obviously doesn't account for planetary rotation, but it could be a start. Also of course only applies for sufficiently small timesteps.

 

[Face]

You can have small tables and do something like CORDIC, but when you are compromising accuracy by using smaller and smaller tables, but still using so many divides, the trade off begins to favor faking sine with parabolas, which only take a few multiplies and no extra memory for tables.

Some of the comments in the linked article discussed that, too.

 

[Thorsten]

But it is about the distance covered over the surface over time. A ship traveling at 10kps 1000 km away is travelling faster over the surface than one travelling at 10 kps 2000 km away right? Assuming the same direction of course.

Ah - we're entering the realm of definitions.

Originally the question was for 'speed relative to the surface'. That's always constant no matter the distance, because the surface merely defines the zero point of velocity.

Now the distance covered over the surface is a different speed - it's sort of translating 'If I would move on the surface with the same angular velocity the spacecraft in orbit has, what speed would I need to remain 'underneath' the spacecraft?'

Note that for e.g. friction forces with residual atmosphere, it's actually the first definition which gives you what you need (velocity difference to a co-rotating atmosphere). I can't think of an easy application of the second one where the difference matters - when you need ground speed, you're going to be close to the ground - you can compute a 'ground speed' according to the second definition for e.g. the moon, but I don't think it means too much.

 

[Hielor]

Ah - we're entering the realm of definitions.

Originally the question was for 'speed relative to the surface'. That's always constant no matter the distance, because the surface merely defines the zero point of velocity.

Now the distance covered over the surface is a different speed - it's sort of translating 'If I would move on the surface with the same angular velocity the spacecraft in orbit has, what speed would I need to remain 'underneath' the spacecraft?'

Note that for e.g. friction forces with residual atmosphere, it's actually the first definition which gives you what you need (velocity difference to a co-rotating atmosphere). I can't think of an easy application of the second one where the difference matters - when you need ground speed, you're going to be close to the ground - you can compute a 'ground speed' according to the second definition for e.g. the moon, but I don't think it means too much.

Actually, the OP was asking for "the speed the surface is moving under you" and specifically calls out "ground speed" in the title of the thread...

 

[Thorsten]

Actually the thread title is 'speed relative to the surface'.

Whether the Moon has a 'groundspeed' I do not know, I've never seen the term in use for anything moving in orbit, I know it only from airplanes where it's mainly used to factor out the air movement.

So I guess we can chalk it all up to my ignorance what ground speed for orbiting bodies means.

 

[Hielor]

Actually the thread title is 'speed relative to the surface'.

Whether the Moon has a 'groundspeed' I do not know, I've never seen the term in use for anything moving in orbit, I know it only from airplanes where it's mainly used to factor out the air movement.

So I guess we can chalk it all up to my ignorance what ground speed for orbiting bodies means.

Odd, I see the thread title as "Determining speed relative to surface (ground speed) "