Make sure you watch "where is Rosetta" animation. Amazing.
http://sci.esa.int/where_is_rosetta/
Tip: Use your mouse to change the view.
http://sci.esa.int/where_is_rosetta/
Tip: Use your mouse to change the view.
>"The process of orbit determination is fairly taken for granted today. During the effort to launch America's first artificial Earth satellites, the JPL craft Explorers 1 and 2, a room-sized IBM computer was employed to figure a new satellite's trajectory using Doppler data acquired from Cape Canaveral and a few other tracking sites. The late Caltech physics professor Richard Feynman was asked to come to the Lab and assist with difficulties encountered in processing the data. He accomplished all of the calculations by hand, revealing the fact that Explorer 2 had failed to achieve orbit and had come down in the Atlantic ocean. The IBM mainframe was eventually coaxed to reach the same result, hours after Professor Feynman had departed for the weekend."
For more complicated paths such as the Rosetta mission, my understanding is that since the 3 body problem remains unsolved for general initial conditions, a numerical solution has to be derived. This numerical solution, at least until recently, seems to have required some fine tuning and intelligent guessing of initial mission parameters [2]:
> “It took only two days of computing time on an ordinary desktop computer and no other user input to reproduce the Cassini mission configuration — a trajectory that originally took extremely talented designers many months to develop.”
Since this mission launched before the development of the software in the above reference, it's likely that a team of experienced engineers spent some time fine tuning it from an initial guess.
[1] http://www2.jpl.nasa.gov/basics/bsf13-1.php
[2] http://www.nasa.gov/content/goddard/nasa-technologist-makes-...
http://en.wikipedia.org/wiki/N-body_problem
http://en.wikipedia.org/wiki/Interplanetary_Transport_Networ...
Ideally they would have an orbit that would have a really low intercept velocity, so the deceleration burns would require the least amount of fuel possible. Once they get close, they burn to get into a stable orbit around the comet. I found one article covering the math behind the deceleration orbit:
http://blog.wolframalpha.com/2014/08/04/rosetta-first-missio...
There's only a finite number of possible, reasonable-duration sequences of Earth and Mars flybys to try, so you just get a computer and try them all. Once you pick a sequence (e.g. EEMEC), you scan across a range of launch dates, maybe incrementing by half a day…
Okay, so now we've picked out a flyby sequence and a launch date. Next up is to pick the date of the first flyby. You can scan across those in half-day increments too.
Once you pick the launch date and the first flyby date, you treat the leg as a two-body problem. You know the initial position vector, the final position vector, and the leg duration: it's a "Lambert Problem." Typically, there's only a finite number of solutions, so you just try them all (or all the reasonable ones, anyway).
(Aside: In this mission, the first transfer was a one-year Earth-Earth transfer. It was a "resonant transfer": there's actually an infinite number of ways to do those, but the set of ways is topologically equivalent to the surface of a sphere, so you just try a finite number of points on that sphere. I digress.)
In preliminary mission design, you just treat the gravity-assist flybys as instantaneous kicks to the spacecraft (instantaneous Delta-V maneuvers).
Next up, we pick the date of the second flyby. Again you can scan across all those in half-day steps or whatever. Once you pick that date, you now have another Lambert problem for the second leg. It's handled the same way as with the first leg, only there's an added complication:
Once we've got the first and second leg transfer orbits selected, we can ask the required flyby altitude at the first flyby. If it's below the surface of the planet, then that particular second leg is a no-go, and we can stop considering it.
And so on. Eventually we end up at the destination. The trajectory model is just a bunch of conic sections (solutions to the two-body problem) patched together at the gravity assists (which have no extent in time or space). It's a "patched conic trajectory."
What if the spacecraft does a Delta-V maneuver at some point? Yes, that's common, but it's also just a few more free parameters, so just throw them into the bag and try a bunch…
Most of the time is spent just trying all the possible combinations. Each individual trajectory takes almost no time to calculate.
Once you have a bunch of candidate trajectories, you can just compare them using whatever metrics matter, e.g. final mass at the target body, total mission duration, does it pass any interesting objects? And so on.
Often there are constraints to satisfy as well. For example, operations people don't like it when maneuvers happen on the other side of the Sun from where the Earth currently is, because they can't communicate with the spacecraft at that time: the Sun is in the way.
Once a preliminary trajectory design (or set of designs) has been chosen, one can simulate a more detailed model (e.g. one that adds the gravity of Jupiter), but the overall trajectory architecture doesn't change.
Also, there was a crowd-sourcing space game with a nifty javascript interface for trajectory design where they looked at how people came up with good trajectories. http://sophia.estec.esa.int/thespacegame/game/
It's a fascinating field!
window.persegueRosetta=1;