Plotting orbit ground track relative to a given point

[Hlynkacg]

So After a long hiatus I'm back and I'm messing around in orbiter. I know this question has been asked before but lord help me if I can find it.

Basically I'm trying to figure out if my orbital track will take me over a specific point on the surface (such as a base or specified Lat/Lng), or rather what my closest point of approach will be, and at what point in my orbit it will occur.

I've got a rough estimation in place that works by projecting the target's position in global coordinates onto my orbit's normal vector, but I'm not sure how well that works as a "general solution" and I'm hoping that someone can point me towards something a bit more refined.

 

[indy91]

You first will want to transform the target position vector to the same coordinate system as your vessel. That is usually the ecliptic relative coordinate system to the body (GetRelativePos in the API).

Your approach with the normal vector of the orbit was a good one, because next you have to project the target position into the orbital plane of your vessel. I'll be using the Apollo guidance equations nomenclature:

[MATH]\underline{u}_{LS} = unit[\underline{r}_{LS}-(\underline{u}_{N}\cdot \underline{r}_{LS})\underline{u}_{N}][/MATH]
where u_N is

[MATH]u_{N} = unit(\underline{r} \times \underline{v})[/MATH]
r and v are your state vector and r_LS is the target position vector. The angle between the current position of the vessel and the projected target is:

[MATH]\theta = \arccos(unit(\underline{r}) \cdot \underline{u}_{LS})[/MATH]
You have to be careful with the sign of the angle though.

Now you need a method to calculate the time of flight from the angle. And because bodies usually rotate you have to calculate a new target vector with the calculated time and iterate a few times.

Helpful so far?

 

[Hlynkacg]

I already have everything translated into a shared coordinate frame, which is how I was able to project the position of my ground target onto my orbit's normal vector.

crossrange = dotp (target_pos, unit (vNormal))

in conjuntion with my velocity tells me how far to the left or right of my prograde vector i need to aim but I'm still having trouble with the rest. I use

target_pos + unit (vNormal) * crossrange

to project the target's position onto my orbital plane but from there things get squirelly. I had assumed that I could use the angle between the adjusted target point and my position relative to the planet a la

acos (dotp (unit (adjusted_pos), unit (planet_rPos)))

But results are inconsistent, and the problem of relating the closest point of approach to the rest of the orbit remains.

 

[C3PO]

You could use spherical trigonometry like navigator do (or did).

 

[Hlynkacg]

You could use spherical trigonometry like navigator do (or did).

I would like to keep this all in one coordinate frame if possible.

 

[C3PO]

I would like to keep this all in one coordinate frame if possible.

Spherical geometry is practically 2D so I guess it's out then. I just like it because the math is quite easy.
If navigators can figure it out it can't be that hard.

 

[Urwumpe]

Also... your preferred map projection is very likely defined by spherical geometry anyway.

 

[C3PO]

Also... your preferred map projection is very likely defined by spherical geometry anyway.

That's probably why the math is easy. You don't need to convert between frames.

 

[indy91]

I guess your two first equations are very similar to my equation no. 1. There u_LS is the projected target vector.

The results of the acos term in both of our 3rd equations are inconsistent, because it can't tell you, when the target vector is more than 180° away. So you have to use an additional equation to calculate the sign of the result. If

[MATH]\underline{u}_N \cdot (unit( \underline{r}) \times \underline{u}_{LS})[/MATH]
is positive then the target vector is between 0° and 180° away from the vessel position. If it is negative theta gets a negative sign and then lies between -180° and 0° (= between 180° and 360°)

 

[Hlynkacg]

Spherical geometry is practically 2D so I guess it's out then. I just like it because the math is quite easy.
If navigators can figure it out it can't be that hard.

Having to do multiple coordinate transformations per step kind of invalidates the whole "math being easy" part.

 

[Urwumpe]

Having to do multiple coordinate transformations per step kind of invalidates the whole "math being easy" part.

Sorry, but there is just one tiny problem with easy. You can only make things as easy as possible - but not more.

Question is: Can you define your orbit only in geographical frame?

If you are in a static frame around an rotating frame - you can't really avoid it.

 

[C3PO]

I'm not sure what you need conversions for. I guess it depends what you are planning to do. The simplest method only requires your position, target position and LAN, and AFAIK you can get that from Orbiter. If you want to include planet rotation there are several options depending on how accurate you want to be. If you want to predict several orbits I suspect it will become very "messy" and not very accurate.

 

[Hlynkacg]

The results of the acos term in both of our 3rd equations are inconsistent, because it can't tell you, when the target vector is more than 180° away. So you have to use an additional equation to calculate the sign of the result.

Actually that was not it, the old "offset origin" velocity conversion issue just bit me in the ass again. I got the code working now.

Question is: Can you define your orbit only in geographical frame?

No, which is why i converted everything into a shared ecliptic frame in the first place.

 

[indy91]

Actually that was not it, the old "offset origin" velocity conversion issue just bit me in the ass again. I got the code working now.

Hmm, I don't quite understand that issue, but whatever :lol:

Do you have a solution yet for taking the rotation of the body into account? I can write a little bit about that, if you want.

 

[Hlynkacg]

Hmm, I don't quite understand that issue, but whatever :lol:

It has to do with how orbiter handles velocity vs position vectors. Unlike a position, the origin of a velocity vector is not necessarily the origin of the frame, which can screw with conversions from one frame to another.

Do you have a solution yet for taking the rotation of the body into account? I can write a little bit about that, if you want.

I have an approximation...

cos (target Lat) * (2 * PI * planet radius / planet length of day)

gets me the rough "eastward" velocity of my landing site which I can then multiply by the sine of my orbit's inclination to get a "crossrange" component.

I'm still working on the "determining time of flight" side of the problem though. Simple angle comparisons work for a circular orbit, but I'd like a general solution.

 

[indy91]

Ok, the time from "now" to the closest approach. Let's get into the wicked geometry.

We have the theta from before, which is the difference in true anomaly. To calculate the time we also need the eccentric anomaly and the mean anomaly.

The mean anomaly can be written as

[MATH]M_e=2\pi \frac{t}{T}[/MATH]
where t is the time from periapsis and T the orbital period. We can rearrange this equation to solve for t and to get a time difference between two mean anomalies we can write:

[MATH]\Delta t=t_1-t_0=\frac{T}{2 \pi} \cdot (M_{e,1}-M_{e,0})[/MATH]
We can calculate the two mean anomalies with Kepler's equation:

[MATH]M_e=E-e \sin(E)[/MATH]
where E is the eccentric anomaly and e the eccentricity.

The eccentric anomaly can be calculated from the true anomaly:

[MATH]\tan \frac{E}{2} = \sqrt{\frac{1-e}{1+e}} \tan \frac{\theta}{2}[/MATH]
There are several ways to calculate the current true anomaly, I like this one:

[MATH]\theta = \left\{\begin{array}{ll} \arccos(\frac{\mathbf{e}}{e} \cdot \frac{\mathbf{r}}{r}), & (v_r >=0) \\ 360 ^{\circ} - \arccos(\frac{\mathbf{e}}{e} \cdot \frac{\mathbf{r}}{r}), & (v_r<0)\end{array}\right.[/MATH]
Where the bold e is the the eccentricity vector and e the eccentricity, the bold r the position vector and r the radius. v_r is the radial velocity. And yes, that's a dot product in the arccos term.

We calculate the two mean anomalies with the just calculated theta as theta_0, and theta_1 is just

[MATH]\theta_1=\theta_0+\Delta \theta[/MATH]
The delta theta is the angle, we talked about earlier in the thread. I hope I explained this in an intelligible way. :embarrassed:

 

[Hlynkacg]

Ok, I already calculated my vessel's current mean anomaly as part of another function. so that is one component already taken care of. The mean anomaly of my CPA (closest point of approach) would simply be MnA + theta where MnA = my current mean anomaly.

That said i'm still unclear on how to get the time difference between "current MnA" and the "target MnA".

Updated with screen shot...

I used Brighton's Lat/Long as my target and tried to hit printscreen right at CPA, Note the debug string in bottom left of screen (angles in degrees), looks like the targeting was pretty close.

 

[indy91]

If you already have the two mean anomalies, then the time diference is

[MATH]\Delta t=\frac{T}{2\pi} (M_{e,1}-M_{e,0})[/MATH]
as above or written differently

[MATH]\Delta t = \sqrt{\frac{\mu}{a^3}}(M_{e,1}-M_{e,0}) [/MATH]

 

[Hlynkacg]

Is it really that simple?

For some reason I was not expecting the angular velocity (delta MnA) to be constant.

 

[indy91]

Yes, you can do that with the mean anomalies. However, the mean anomaly is not the actual angle since periapsis. The mean anomaly is an angular parameter of the orbit that is always monotonically increasing. Imagine your elliptical orbit would be transformed into a circular orbit with the same orbital period. The derivative of the mean anomaly would be the mean motion, which is the time-average angular velocity of the orbit.

There are three angular parameters: mean anomaly, eccentric anomaly and true anomaly. The angle between vessel and target, we have calculated earlier, has to be added to the true anomaly of the orbit, because that is the actual angle between the direction of periapsis and the current position of the vessel. And that's why I posted the rather lengthy equations earlier to calculate the mean anomalies from the true anomalies.