Patched Conics Trajectory from Initial Orbit State

[TheHarvesteR]

Hi,

I've got a problem here, that I'd like to discuss before trying to implement any sort of solution.

Basically I've got a planetarium simulation, in which I'd like to plot a patched conic trajectory ahead of a spacecraft .

The planetarium only simulates two-body gravity, and switches gravity sources for spacecraft based on the SOI they are in. This was a decision made to make it possible to use deterministic propagation methods at all times, for both the spacecraft and any celestial body. This also means a patched conic trajectory isn't an approximation in this system, but the actual trajectory the ship will fly.

So, currently, all the orbit propagation is working properly, and spacecraft are able to move from one SOI to another, and have their orbits recalculated for the new reference frame, and that happens as expected.


What I want to add next is a patched conic 'renderer' system, that instead of drawing the spacecraft orbit as a simple conic section, would find if the orbit intersects any SOI (or leaves the current one), and draw a patched conic trajectory for the ship.



So this brings me to my original question. In order to render a patched conic trajectory, I need to somehow determine if and where along the orbit the ship would change SOIs. For the SOI escaping case, I believe this would be relatively straightforward, as it would require finding only the time at which the orbit radius equals the SOI radius.

For a SOI change like a lunar flyby, though, this would require calculating in advance the exact point in which the orbit enters the moon's SOI, to recalculate and go on from there, but keeping in mind that the moon itself is also orbiting, so by the time we reach the SOI distance, the moon will be further along its orbit.

So I'm hoping someone can enlighten me with some theory here... first, is it possible to calculate the point of SOI encounter like that? If not, what other options are there to plot a patched conic trajectory, having only the initial orbital parameters (and state vectors) as input?


Thanks in advance!

Cheers

 

[SHISHKABOB]

perhaps can you have the program calculate where the moon's SOI will be based on its orbital velocity and the velocity of the spaceship?

 

[TheHarvesteR]

perhaps can you have the program calculate where the moon's SOI will be based on its orbital velocity and the velocity of the spaceship?

Well, yes, because the simulation is restricted to two-body systems, we can get the position of just about anything as a function of time, so that bit is taken care of.

The problem here is that I can't think of a way to properly find the true point of intersection...

I suppose one way of doing it would be to simply test, for each point in the orbit that we sample (to draw the initial ellipse), if that point wouldn't be inside another SOI by the time we get there. then, if so, take the state vectors at that point, and recompute a new orbit from there.

The problem with that method is that it's not accurate, because the samples are spaced pretty far apart, so you could easily miss a planet encounter on an interplanetary trip, and it could be pretty expensive to calculate as well, depending on how many samples we are running.


I was hoping to find some analytical method to find the SOI intersection.


Thinking about it, I do think it will be necessary to run two stages of detection at least... First, we test the orbit to see if the orbital ellipse intersects the 'torus' described by the other body's SOI as it orbits. That doesn't really find the point of intersection, but it does rule out bodies which you couldn't possibly meet in your current path.

Then, if a potential intersection is found, see if the body will be at any point that's close enough to have a chance of encounter. If so, it should be relatively fast to compute, possibly by integration, if no other option is found, where exactly SOIs would change.

The same method could be used to detect whether your trajectory would take you outside your current body SOI. Even a closed orbit has the potential to lead you out of the SOI, so that has to be detected by checking if the orbit Ap is greater than the SOI radius, if so, we start looking for the orbit point at which your radius = SOI.

I think the exit case at least can be reduced to a modified form of the orbit equation, where radius is known, but true anomaly isn't. Some algebra later, we would have the true anomaly at which you'll be leaving SOI.

For the flyby case though, I'm still at a loss.


Cheers

 

[D H]

Have you tried working in the Earth-Moon rotating frame? If you are approximating the Moon's orbit as a circular orbit, this becomes the circular restricted three body problem, with the added simplification that the orbit of the third body is a conic section. The Earth and Moon are stationary in the circular restricted three body problem. Finding the time at which the trajectory enters or leaves the Moon's sphere of influence can be done by regula falsi fairly easily.

The regula falsi approach will also work in the case of the elliptic restricted three body problem. A bit trickier, but still workable.

 

[TheHarvesteR]

A regula falsi approach is what I had in mind really. Although I had been planning on doing it on the current main body frame, and treating entering a "child" SOI as a separate case than leaving your current one for the SOI of the "parent" body in the system.

It should be possible I think, after finding if the orbit intersects the torus described by the body and its SOI, to run some sort of root-finding algorithm to converge down on the true point of transition... I thought that there could be a simpler, more direct method though, given that all positions can be calculated as a function of time...

Well, at least this is a potential solution already. :)EDIT:

Well I have some progress news here. I decided to make some tests, and set up a simple system to just do some math between two orbits.

I've found that it's very much possible to find the points of intersection between two orbits analytically, so I plan on using that as a first-stage triage scheme, to rule out orbits which you wouldn't have any chance at all of intersecting.

If any orbits pass this verification, then I can run another set of calculations to determine just how far off both bodies would be, and calculate a dT for encounter. If the dT is close enough, we can then move on to the converging algorithm, using the analytical intersection point as an initial guess.

If the ship is inside the target SOI, move it back proportionally to how much it's below the SOI radius. If the ship is outside, move it forward. Hopefully after a few iterations, it should result in a reasonably accurate point of transition, from which we can grab state vectors and recalculate a new conic patch.

Cheers

 

[Rokkerboyy]

Harvester, I respect you and what you have done for Kerbal so very much and if you are still having problems, I would like you to allow me to look at the source code for the Patched-Conics trajectory projection system I can attempt to assist you in finding a solution using what you have so far.

 

[TheHarvesteR]

Harvester, I respect you and what you have done for Kerbal so very much and if you are still having problems, I would like you to allow me to look at the source code for the Patched-Conics trajectory projection system I can attempt to assist you in finding a solution using what you have so far.

Thanks, but at the moment, there is very little to work with here... I have the single-orbit code already working, so we can abstract that bit away and work with what we already know to be osculating orbits... But as far as actually calculating patched conics and all that, all I have right now is a test project with a quick hack thrown into do some math.

At this point, I'm mostly looking for conceptual help really. I need to be sure I'm on the right track with this idea. :)

Cheers

 

[KenCarlson]

Hi,

I wrote a paper in 1970 I think will help. It provides a set of equations that will define the patch point at the SOI given a set of five input trajectory elements. The needed inputs are the inclination of both parts of the trajectory, i.e., the conic sections around the more massive and less massive body, the radius of pericentron and semi-major axis at the less massive body and the angular momentum of the trajectory relative to the more massive body. (Note that the angular momentum can be simply calculated from the apsidial distances. In the case of Earth-Moon trajectories, the angular momentum can be closely approximated using only the radius of perigee.) The latitude and longitude of the patch point and the state vector of both parts of the trajectory at the patch point are calculated. The solutions are approximate, but the derived patch point is within a small fraction of a degree of the true point.

This solves your problem somewhat backward, as it assumes you know the position of the less massive body at the time of entry into or out of its SOI and then calculates the initial conditions from there.

I would include a link to the paper, but the rule on this forum is that one must have had ten posts before a link can be included. None-the-less, if you go to the NASA Technical Reports Server and search on patched conic, the paper will be in the returned list with the title "An analytical solution to patched conic trajectories satisfying initial and final boundary conditions" by K. M. Carlson

I hope this helps and good luck,

Ken Carlson



The paper is available on the NASA Technical Reports Server. I be happy to give you the link but the rule on this forum is that I cannot post a link until I've had 10 posts. But if you go to that server and search on patched conic, the paper will come up with the title: "An analytical solution to patched conic trajectories satisfying initial and final boundary conditions" by K. M. Carlson

 

[TheHarvesteR]

Thanks Ken.

I actually have this working here already. I followed a paper by Hoots from 1984 (to some extent), and wrote a few algorithms of my own to find the solutions.

Basically what it does is first rule out orbits that won't intersect, first by simple criteria, like periapsis and apoapsis intersection, then by comparing the orbital ellipses (as per Hoots' paper). If the orbits pass those initial conditions, it runs a root-finding algorithm to converge on the point of SOI transition, and calculates the new conic patch by taking your state vectors at that point, transforming them to the coordinate system of the new body, and using those vectors to compute the parameters of the new patch.

Hoots proposed using a Newton-Raphson solver to find the solution, but that was too unreliable if the initial guess wasn't good enough. So I wrote a simpler and more robust algorithm that is probably less efficient, but much more dependable. In my case here, it's more important to be reliable than to be efficient.

All that is running on a loop, so each patch is used to find and calculate the next one, until a final patch is reached (one with no transitions), or the max limit is exceeded.

In the end, we get a list of future patches, each with its own timestamps for patch start and end, and also the true anomalies at SOI entry and exit. We use those to draw the trajectory as a 3D spline, using several options for the reference frame.

Here's a screenshot of it in action, each patch is a different colour orbit:

Apart from a few bugs here and there with the implementation, which I hope to solve soon, it's working quite well. It's actually more accurate than the actual flight simulation, and I'm thinking about using it as more than just an analysis feature in the game... Well, eventually. :)

Cheers

 

[KenCarlson]

Glad to hear you've solved the problem but sorry I didn't get to you in time. My solution doesn't require iteration and allows both beginning and ending conditions to be specified. I would have loved to see it implemented.

Ken