# Closest Approach Point Between Two Conics

#### Arrowstar

##### Probenaut
Hi all!

I've got a fun orbits question I've been toying with for a few days now, and I've hit something of a wall. I was hoping I might get some insight from you fine folks that might push me in the general direction of the solution.

The question is this: given two arbitrary orbits defined by static conic sections (that is, pure two body motion), find the closest approach point or points between the conics.

Assume orbit 1 is defined by: <a1, e1, i1, O1, w1>
Assume orbit 2 is defined by: <a2, e2, i2, O2, w2>

These elements are arbitrary. For the purposes of our discussion here, let's assume that we're dealing with elliptical orbits, though it should be straight-forward to expand any solutions to all conic sections: 0.0 <= e1,e2 < 1.0

The anomaly is not pertinent to this discussion as I am looking for the close approach point of the orbits (or, the geometry of the orbits) and not the close approach point of two bodies on those orbits.

My thought on the solution to date has been this: I believe that the closest approach point between two conics should be at their relative ascending/descending nodes. Therefore, to get inertial unit vectors to those points, I can do the following:

Define the orbital angular momentum unit vector of orbit 1: h1
Define the orbital angular momentum unit vector of orbit 2: h2

The ascending/descending nodes are then located along the unit vectors: n = h1 ^ h2/norm(h1 ^ h2) and n` = -(h1 ^ h2/norm(h1 ^ h2)

From there it's trivial to determine the true anomaly at each orbit. Something like this, for example:

theta1 = asin(n_z/sin(i1))
true1 = theta1 - w1

Where n_z is the "z" component of the unit vector "n".

So now the issue: this doesn't seem to work. I can define orbits which I know approach each other closely at some point, but the closest approach point doesn't seem to be as I've defined it. Is the issue in my assumption (closest approach at nodes)? Is there something wrong in my mathematics?

Input appreciated! Thanks everyone.

Last edited:

#### BrianJ

Hi,
Is the issue in my assumption (closest approach at nodes)?
I think this is only true if the orbits definitely intersect.

Imagine a classic Lunar Transfer Orbit in the same plane as the Moon's orbit, but now tip it up a little bit at apogee so it passes just over the Moon's N.pole - the nodes will be at 90deg to the Perigee-Apogee line but closest point(s) to the Moon's orbit will be at(or close to) Apogee.

Cheers,
Brian

#### martins

##### Orbiter Founder
Orbiter Founder
I also don't think that the assumption (minimum distance is between two nodal points) is correct.

I don't know if the problem has an analytic solution, but if in doubt, you can always apply a numerical minimisation approach. The solution should be so smooth that any gradient-based method should converge quickly (although I suppose there is a potential danger of local minima).

#### Enjo

##### Mostly harmless
Tutorial Publisher
Donator
Until you find an analytic solution:

First part - the model
There is an example in KOST library for simulating a 3D point in orbit. Use it to do your own simulation of a point in orbit 1 (position portion of the state vector). Iterate the orbit time (0, T) until the distance between the point and the 2nd orbit's plane is minimal. So the source of the distance line is the point of course, and the end would be created by finding 3D intersection between the point and a line, always perpendicular to the 2nd plane (3D geometry - you'll find it on the Net).

Second part - effective numerical minimization
I strongly recommend my binary (fast & precise) solver that I used for TransX' Auto-Min. You can read about it in my only blog post. You just need to wrap the above model as EnjoLib::BinSearchOptiSubject and pass it to the EnjoLib::BinSearchOpti, also giving it minimal argument (0) and maximal (T). Also you can experiment with different epsilons (precision) (0.1 : 0.0001) and you'll see that even with very small eps, the calculation is still very fast. Any MFD can handle it. Struggling to find analytic solution would be only needed if you needed to calculate like 100000 such orbits in one frame*. Anyway, you can always try the binary search and make the decision later.

Have fun!

*Proven empirically

Last edited:

#### Arrowstar

##### Probenaut
I also don't think that the assumption (minimum distance is between two nodal points) is correct.

I don't know if the problem has an analytic solution, but if in doubt, you can always apply a numerical minimisation approach. The solution should be so smooth that any gradient-based method should converge quickly (although I suppose there is a potential danger of local minima).

Duly noted, thank you! Could you suggest a form of the function to be minimized that would also lend itself to quick minimization? My instinct is to write the problem as a function of the two anomalies (each representing a point on each orbit) and find the pair of anomalies that minimizes the distance between the points. Is there a more efficient way to perform the search?

Once I've got the function, of course, actually minimizing it is very straight-forward. I'm keen to write to a function that lends itself to quick minimization, though.

Enjo: Thanks for the tips, I'll take a look.

#### Enjo

##### Mostly harmless
Tutorial Publisher
Donator
If, for practical reasons, your goal is to find a closest approach between a vessel and a planet, like in TransX, then I believe simulating two points simultaneously is the wrong way to go, because then, even if you used my binary solvers, you'd end up with complexity of log^2, because you have to run a binary search for each binary search's iteration of the other point (hence ^2). Sure, you could use a multidimensional approach, like Nelder-Mead method (see Microsoft Solver Foundation), but I still think that it would be a waste (could be much worse than log^2), and finding the closest point to the 2nd orbit's plane would guarantee you (I assume) finding the closest distance of orbits in all 3 dimensions, while keeping the optimization problem one-dimensional, where you can apply a binary solver with a complexity of mere log. But that's not finding a closest approach to the planet on the 2nd orbit yet, only to the plane of the 2nd orbit...

So the plan would be:
1) Do what I've described in the first post - this is what TransX does by giving to the user some closest approach. Here you calculate the distance to a plane only. To get the closest approach value you have to do the following:
a) iterate the first orbit in (0, T) to find t_opt, like I described
b) use t_opt to advance the planet on the 2nd orbit by that time (using KOST)
c) Closest approach = dist( obj1(t_opt).pos, obj2(t_opt).pos )

2) Exactly what I've done in Auto-Min: find such parameters of the orbit 1 that minimize the calculated Closest approach, by using another set of binary solvers, one for each orbit's parameter. That's fast enough for making 100 such evaluations per second for TransX, which performs the Closest approach calculation probably in a slower manner than I've described in 1)
Here is where you could fall into local minima, so choosing sane bounds for the search algorithm is crucial.

[EDIT]
If you actually need to find the closest approach of orbits, not to a planet on the 2nd orbit, then indeed, you need to make two numerical simulations, but one after another, so minimize the distance to the 2nd plane and simulate in KOST to position for t_opt, like I said, but for the second orbit don't use the t_opt, but just minimize the distance function from 1)c) for arguments (0, T2) of the second orbit - dist( obj1(t_opt).pos, obj2((0, T2)).pos ). It's not log^2, but only 2 * log, since you do one optimization and then another after finishing the first one.

Is anything clear?

Last edited:

Replies
6
Views
3K
Replies
0
Views
1K
Replies
0
Views
1K
Replies
0
Views
896