MontBlanc2012
Active member
- Joined
- Aug 13, 2017
- Messages
- 138
- Reaction score
- 26
- Points
- 28
For a while now, I've been thinking about the kinds of tools that one needs to navigate efficiently and effectivel in the vicinity of the Lagrange points of, say, the Earth-Moon system. To be sure, Orbiter has a number of lesser-known (but quite sophisticated) tools in the Orbiter MFD stable - notably Lagrange MFD v1.5 for Orbiter 2016 - which permit some basic navigation relative to the Lagrange points of the Earth-Moon system and the Sun-Earth system. But none of these tools allow one to design optimal transfers in 'cis-lunar space'.
Surely we can do better than this.
A comparison with two-body motion
As most users already know, Orbiter has been very successful in enabling tools that allow for the design of efficient interplanetary transfers using the now very familiar 'patched conics' approximation . In particular, IMFD's Course Program can be used to design efficient Hohmann-like transfers between planets. It is able to do this because it makes use of a Lambert Solver to construct a Keplerian arc between a trajectory start-point and a trajectory end-point with a specified time-of-flight. A Lambert Solver solves the two-point boundary value problem "Given a starting point A, an end point B and a transfer time dt, what initial velocity is required at the point A to make this transfer". For the Kepler problem efficient solutions to this boundary value problem can be computed. And ny judicious adjustment of the departure date and arrival date, one can construct an optimal, two-impulse transfer manoeuvre that minimises the amount of dV required to make the transfer.
But what about motion in the vicinity of a Lagrange Point? In the vicinity of the Lagrange points of the Earth-Moon system say, IMFD's Keplerian Lambert Solver built into its Course Program no longer works (because the gravitational field in the vicinity here is no longer Keplerian). And, yet, we do not have an equivalent Lambert Solver for cis-lunar space that we can use to carry out the same sort of trajectory optimisation that we would for the patched-conics model. For example, let's suppose that we are at some arbitrary position reasonably close to the L1 Lagrange point and travelling reasonably slowly relative to it. Let's also suppose that we wish to make a transfer to the Lagrange point that takes a specific time, dt. What velocity should our satellite have now in order to effect this transfer to L1? And what velocity will we have relative to the Lagrange point when we arrive? When is the optimal time to leave; and what is the optimal duration of our transfer? In the absence of a Lambert Solver for the restricted three-body problem, we struggle to answer basic questions of this kind.
A different kind of Lamber Solver
Evidently, the only way of answering questions of this kind is to have a Lambert-like Solver that has been designed to work in the vicinity of Lagrange points. Needless to say, I wouldn't be posting this note if a tool of this kind didn't exist.
Let's make things a little more concrete by considering a simple (but arbitrary) example. And because we are thinking about navigation in the vicinity of Lagrange points, we are going to set this example up in the rotating reference frame of the three-body problem such that the location of the Lagrange points in that reference frame is fixed. In this rotating reference frame, imagine that we have a satellite located 4,000 km from L1 towards the Moon (the 'x' coordinate in our rotating reference frame); 4,000 km vertically above the orbital plane of the Moon in its orbit around the Earth (the 'z' coordinate in our rotating reference frame); and 4,000 km 'ahead' of the Lagrange point (the 'y' coordinate in our rotating reference frame). In other words, the satellite starts off at some arbitrary point about 7,000 km from L1. Let's also suppose, for sake of example only, that we wish our transfer to L1 to take a rather leasurely 71.3 days. Of course, there is no particular reason for having a transfer of this kind, but we choose these number somewhat arbitrarily simply to work through an example in this note. In the context of this scenario, we can ask a number of questions:
* what is our transfer trajectory?
* what velocity do we need to have now to send us on this trajectory? and
* what velocity will we have when we finally arrive at L1?
* if we vary our time-of-flight, how do these things change?
These questions parallel those that we would ask of a standard Lambert Solver. And we use answers to those questions to drive the search for optimality. So, if we can answer these questions for the three-body problem, we should be able to carry out the same sort of optimsisation tasks that we would normally apply to a standard Keplerian (two-body) Lambert Solver. And since I do have a solver of this kind I can, of course, use it to answer these questions.
What is our transfer trajectory?
First of all, what is the transfer trajectory that we need to effect the transfer from our (arbitrary) starting position to L1 such that the time-of-flight is 71 days. Well, if we apply our new Lambert Solver to this problem, we find (without proof) that the three-dimensional transfer trajectory looks like this:
Clearly, the trajectory has a complicated structure. But, then again, this is a transfer orbit that takes 71.3 days (~ 2.5 lunar orbits of the Earth), so one might have expected that the transfer wouldn't be straightforward. So what's going on here in this trajectory. Roughly speaking, from the start point, the trajectory follows the stable manifold of Lissajous orbit around L1. Once 'on' the Lissajous orbit, the satellite circumnavigates the L1 Lagrange point six times before finally exiting the Lissajous orbit on the unstable manifold of that Lisaajous orbit that happens to pass through the Lagrange point arriving at L1 on the correct date. Of course, there is nothing particularly significant about the starting point or the duration of the transfer. They have merely been used here to demonstrate the capability of the Lambert Solver. As for the Lambert Solver itself, I'll focus on the mathematical details elsewhere but its foundations rest on sold maths and physics and, in effect, reduced the problem to an exercise in linear algebra. Although the end result is a trajectory solution that makes use of the stable, unstable and centre manifolds in the vicinity of the Lagrange point, the Lambert Solver does not solve the problem in terms of those structure.
What velocity do we need to have now to send us on this trajectory?
Naturally, we can find the velocity vector (in rotating coordinates) that we need to start ourselves on this trajectory. For our sample solution the x-y-z components of the velocity vector (in the rotating coordinate system) are as follows:
* x-direction - -34.65 m/s
* y-direction - +3.03 m/s
* z-direction - +3.19 m/s
Just as with a standard Keplerian Lambert Solver, we are able to calculate the initial velocity vector with ease. However, whereas Keplerian trajectories are meta-stable so that once on a Keplerian arc, and absent perturbations, one stays on the same Keplerian arc, for the Lambert Solver for Lagrange points, we have a situation where we will need to undertake periodic corrections in order to remain on the prescribed transfer trajectory. However, this kind of 'station keeping' doesn't present any particular problem since we can periodically re-run our solver during the flight to calculate the minor correction needed to remain 'on track' for the entire 71.3 days.
What velocity will we have when we finally arrive at L1?
It is just as straightforward to calculate the velocity components upon arrival at the L1 Lagrange point. For our example, for our test problem, we find that the speed of the vessel upon arrival is:
* x-direction - +8.75 m/s
* y-direction - +19.02 m/s
* z-direction - +18.31 m/s
Upon arrival at L1, and assuming one wishes to 'park' at L1, this is the velocity vector that would need to be nulled out. If we take the length of the velocity vector, we find that the dV required to park at L1 is 27.8 m/s.
If we vary our time-of-flight, how does this change?
We can also ask the question: is this solution optimal? Well, let's suppose that we only care about minimising the dV requirements at L1, given our starting point, what is the time-of-flight that minimises this dV? At this point, we can use the same kind of techniques that we would use when using IMFD's Course Program to optimise the transfer trajectory. And without going into the details, but simply using the time-of-flight as a control parameter, we find that if we target a time-of-flight of 69.5 days rather than 71.3 days, we can reduce the dV requirements to 'park' at L1 from 27.8 m/s down to just 15.7 m/s. For those interested, the optimal trajectory is shown below:
Of course, this optimality search was not intended to be exhaustive - but the point remains valid: once one has a three-body Lambert Solver, one has one of the basic instrument for finding optimal transfers in the vicinity of Lagrange points.
Where to from here?
By virtue of the trajectory planning tools that have been created thus far for Orbiter, Orbiter has largely been a vehicle for designing, optimising and executing patched conic trajectories. As such, it has been remarkably successful. But even though Orbiter includes a faithful rendition of Newtonian gravity for the Solar System, very few tools have been created that allow one to design, optimise and execute trajectories in the vicinity of Lagrange points. The Lambert Solver briefly showcased in those note goes some way to addressing that issue.
As for the Lambert Solver, itself. At the moment it exists, and it works - but there is a substantial amount of work to be done to make this into a tool that is useful by other in the Orbiter community. Nonetheless, this is the long-term goal of this endeavour and this note is but the first small step towards achieving that end.
Surely we can do better than this.
A comparison with two-body motion
As most users already know, Orbiter has been very successful in enabling tools that allow for the design of efficient interplanetary transfers using the now very familiar 'patched conics' approximation . In particular, IMFD's Course Program can be used to design efficient Hohmann-like transfers between planets. It is able to do this because it makes use of a Lambert Solver to construct a Keplerian arc between a trajectory start-point and a trajectory end-point with a specified time-of-flight. A Lambert Solver solves the two-point boundary value problem "Given a starting point A, an end point B and a transfer time dt, what initial velocity is required at the point A to make this transfer". For the Kepler problem efficient solutions to this boundary value problem can be computed. And ny judicious adjustment of the departure date and arrival date, one can construct an optimal, two-impulse transfer manoeuvre that minimises the amount of dV required to make the transfer.
But what about motion in the vicinity of a Lagrange Point? In the vicinity of the Lagrange points of the Earth-Moon system say, IMFD's Keplerian Lambert Solver built into its Course Program no longer works (because the gravitational field in the vicinity here is no longer Keplerian). And, yet, we do not have an equivalent Lambert Solver for cis-lunar space that we can use to carry out the same sort of trajectory optimisation that we would for the patched-conics model. For example, let's suppose that we are at some arbitrary position reasonably close to the L1 Lagrange point and travelling reasonably slowly relative to it. Let's also suppose that we wish to make a transfer to the Lagrange point that takes a specific time, dt. What velocity should our satellite have now in order to effect this transfer to L1? And what velocity will we have relative to the Lagrange point when we arrive? When is the optimal time to leave; and what is the optimal duration of our transfer? In the absence of a Lambert Solver for the restricted three-body problem, we struggle to answer basic questions of this kind.
A different kind of Lamber Solver
Evidently, the only way of answering questions of this kind is to have a Lambert-like Solver that has been designed to work in the vicinity of Lagrange points. Needless to say, I wouldn't be posting this note if a tool of this kind didn't exist.
Let's make things a little more concrete by considering a simple (but arbitrary) example. And because we are thinking about navigation in the vicinity of Lagrange points, we are going to set this example up in the rotating reference frame of the three-body problem such that the location of the Lagrange points in that reference frame is fixed. In this rotating reference frame, imagine that we have a satellite located 4,000 km from L1 towards the Moon (the 'x' coordinate in our rotating reference frame); 4,000 km vertically above the orbital plane of the Moon in its orbit around the Earth (the 'z' coordinate in our rotating reference frame); and 4,000 km 'ahead' of the Lagrange point (the 'y' coordinate in our rotating reference frame). In other words, the satellite starts off at some arbitrary point about 7,000 km from L1. Let's also suppose, for sake of example only, that we wish our transfer to L1 to take a rather leasurely 71.3 days. Of course, there is no particular reason for having a transfer of this kind, but we choose these number somewhat arbitrarily simply to work through an example in this note. In the context of this scenario, we can ask a number of questions:
* what is our transfer trajectory?
* what velocity do we need to have now to send us on this trajectory? and
* what velocity will we have when we finally arrive at L1?
* if we vary our time-of-flight, how do these things change?
These questions parallel those that we would ask of a standard Lambert Solver. And we use answers to those questions to drive the search for optimality. So, if we can answer these questions for the three-body problem, we should be able to carry out the same sort of optimsisation tasks that we would normally apply to a standard Keplerian (two-body) Lambert Solver. And since I do have a solver of this kind I can, of course, use it to answer these questions.
What is our transfer trajectory?
First of all, what is the transfer trajectory that we need to effect the transfer from our (arbitrary) starting position to L1 such that the time-of-flight is 71 days. Well, if we apply our new Lambert Solver to this problem, we find (without proof) that the three-dimensional transfer trajectory looks like this:
Clearly, the trajectory has a complicated structure. But, then again, this is a transfer orbit that takes 71.3 days (~ 2.5 lunar orbits of the Earth), so one might have expected that the transfer wouldn't be straightforward. So what's going on here in this trajectory. Roughly speaking, from the start point, the trajectory follows the stable manifold of Lissajous orbit around L1. Once 'on' the Lissajous orbit, the satellite circumnavigates the L1 Lagrange point six times before finally exiting the Lissajous orbit on the unstable manifold of that Lisaajous orbit that happens to pass through the Lagrange point arriving at L1 on the correct date. Of course, there is nothing particularly significant about the starting point or the duration of the transfer. They have merely been used here to demonstrate the capability of the Lambert Solver. As for the Lambert Solver itself, I'll focus on the mathematical details elsewhere but its foundations rest on sold maths and physics and, in effect, reduced the problem to an exercise in linear algebra. Although the end result is a trajectory solution that makes use of the stable, unstable and centre manifolds in the vicinity of the Lagrange point, the Lambert Solver does not solve the problem in terms of those structure.
What velocity do we need to have now to send us on this trajectory?
Naturally, we can find the velocity vector (in rotating coordinates) that we need to start ourselves on this trajectory. For our sample solution the x-y-z components of the velocity vector (in the rotating coordinate system) are as follows:
* x-direction - -34.65 m/s
* y-direction - +3.03 m/s
* z-direction - +3.19 m/s
Just as with a standard Keplerian Lambert Solver, we are able to calculate the initial velocity vector with ease. However, whereas Keplerian trajectories are meta-stable so that once on a Keplerian arc, and absent perturbations, one stays on the same Keplerian arc, for the Lambert Solver for Lagrange points, we have a situation where we will need to undertake periodic corrections in order to remain on the prescribed transfer trajectory. However, this kind of 'station keeping' doesn't present any particular problem since we can periodically re-run our solver during the flight to calculate the minor correction needed to remain 'on track' for the entire 71.3 days.
What velocity will we have when we finally arrive at L1?
It is just as straightforward to calculate the velocity components upon arrival at the L1 Lagrange point. For our example, for our test problem, we find that the speed of the vessel upon arrival is:
* x-direction - +8.75 m/s
* y-direction - +19.02 m/s
* z-direction - +18.31 m/s
Upon arrival at L1, and assuming one wishes to 'park' at L1, this is the velocity vector that would need to be nulled out. If we take the length of the velocity vector, we find that the dV required to park at L1 is 27.8 m/s.
If we vary our time-of-flight, how does this change?
We can also ask the question: is this solution optimal? Well, let's suppose that we only care about minimising the dV requirements at L1, given our starting point, what is the time-of-flight that minimises this dV? At this point, we can use the same kind of techniques that we would use when using IMFD's Course Program to optimise the transfer trajectory. And without going into the details, but simply using the time-of-flight as a control parameter, we find that if we target a time-of-flight of 69.5 days rather than 71.3 days, we can reduce the dV requirements to 'park' at L1 from 27.8 m/s down to just 15.7 m/s. For those interested, the optimal trajectory is shown below:
Of course, this optimality search was not intended to be exhaustive - but the point remains valid: once one has a three-body Lambert Solver, one has one of the basic instrument for finding optimal transfers in the vicinity of Lagrange points.
Where to from here?
By virtue of the trajectory planning tools that have been created thus far for Orbiter, Orbiter has largely been a vehicle for designing, optimising and executing patched conic trajectories. As such, it has been remarkably successful. But even though Orbiter includes a faithful rendition of Newtonian gravity for the Solar System, very few tools have been created that allow one to design, optimise and execute trajectories in the vicinity of Lagrange points. The Lambert Solver briefly showcased in those note goes some way to addressing that issue.
As for the Lambert Solver, itself. At the moment it exists, and it works - but there is a substantial amount of work to be done to make this into a tool that is useful by other in the Orbiter community. Nonetheless, this is the long-term goal of this endeavour and this note is but the first small step towards achieving that end.