Optimal MGA and MGA-1DSM trajectories - PyKEP/PyGMO

[f1re]

I understand that you are doing a global optimization, and thus should naturally arrive at a solution with a ~0 m/s burn on the second leg, but in my tests it was having trouble finding it.

Ok, then I get what you mean, and I see no problem with making it possible, I'll need to touch the PaGMO code as well for this, as this affects the decision vector, and the dimension of the problem as well.

But it makes sense perfectly. I think the approach will be to merge the MGA and MGA-1DSM problems in a more generalized problem. If you want no DSM at all (actually this is equivalent to making DSM time equal 0, where you have a powered flyby), you have MGA. If you allow DSM during any leg, you have MGA-1DSM, and what you ask for, are problems in-between (2^num_legs different problems, all with different dimensionality).

This is actually good, because providing such information speeds up optimization a great deal.

 

[f1re]

GravityAssistMFD-0.2

Hello everyone, disappeared a bit, had to earn money and things

Thanks to Boogabooga's advices regarding UI, and DSMs, here is version 0.2 of GravityAsistMFD, which makes optimization a bit friendlier for people with weaker machine.

Changes
1. The Departure and Arrival planets are extracted to combo boxes.
2. It is possible to insert special DSM items in the list, which can be put in-between planets. If you add at least 1 such item, DSM is only legal in that leg where you specify it.
If you don't add any, then for MGA there will be no DSMs, for MGA-1DSM, then DSM is legal during all legs.
3. It is possible now to re-order items of the list, to decrease pain if you want to change order.

Notes:
- I was lazy, and there are a few unfiltered illegal case, which please do avoid:
a) Don't insert two DSM items next to each other
b) Always make sure that departure and arrival planets are selected.
c) Don't put text in numeric fields.

When I have time, I'll make it foolproof, but for now it is assumed you put in reasonable input.

Performance note:
- MGA problem is still the fastest.
- complete MGA-1DSM is still the slowest.
- Depending on how many (>=1) DSM items you add, the problem dimension increase by 3 for each.

Thank you, please keep consuming, and getting back with any type of feedback you can think of.
https://github.com/tuzcsaba/orbiter-kep/blob/master/Install-Package/GravityAssistMFD-0.2.zip

 

[Enjo]

I tested it on a proper (non-emulated) windows and it works good. No idea how to use it for now, though
I will slowly start thinking about integrating it with TransX.

 

[boogabooga]

My next question is if you are considering the possibility of multiple revolutions.

Also, what is the valid range of dates?

Edit:
It would be good to have periodic feedback of some sort during the optimization so the user can tell if it is still in progress or has gotten stuck.

 

[Keithth G]

I will slowly start thinking about integrating it with TransX.

A couple of things to throw into the mix as Enjo thinks about TransX integration.

1. Although TransX and PyKEP/PyGMO both use 2-body Keplerian physics, TransX uses a true 'patched conics' model whereas PyKEP/PyGMO uses a simplified 'linked conics' model. For the most part, the difference doesn't matter much - or at least the differences can be dealt with using minimal dV, but there is a fundamental difference in the way that trajectories are modelled.

2. Implementation of a the MGM or MGM-1DSM trajectories coming out of PyKEP/PyGMO really require a (multi-period) Lambert Solver to implement well. Arrival at a planet on a specific date is important in the optimised trajectory plan. Of course, one can fudge things with TransX, but life would be much simpler if TransX incorporated one directly.

3. Neither TransX nor PyKEP/PyGMO include n-body physics. Planetary perturbations, particularly those associated with slow planetary encounters where 3-body interactions become significant, introduce significant distortions in the trajectory. To ameliorate the accumulation of n-body errors, it may make sense to 're-optimise' the remaining part of the trajectory plan at various stages through trajectory implementation.

4. In the case of the Earth, PyKEP/PyGMO models the EMB - the Earth-Moon Barycentre - but not the position of the Earth. I'm not sure what TransX targets, but I suspect that it is the other way around.

 

[boogabooga]

2. Implementation of a the MGM or MGM-1DSM trajectories coming out of PyKEP/PyGMO really require a (multi-period) Lambert Solver

3. Neither TransX nor PyKEP/PyGMO include n-body physics. Planetary perturbations, particularly those associated with slow planetary encounters where 3-body interactions become significant, introduce significant distortions in the trajectory.

All things being equal, seems to me that IMFD rather than TransX would be a more suitable platform, since it does both of these things.

 

[Keithth G]

All things being equal, seems to me that IMFD rather than TransX would be a more suitable platform, since it does both of these things.

Yes and no.

IMFD's Map Program does indeed take into account n-body interactions, but my experience of it is that it is not always reliable. Better, methinks, to build a bespoke n-body integrator.

IMFD's Course Program does have a Lambert Solver - but it is not a multi-period solver.

 

[f1re]

1. Although TransX and PyKEP/PyGMO both use 2-body Keplerian physics, TransX uses a true 'patched conics' model whereas PyKEP/PyGMO uses a simplified 'linked conics' model. For the most part, the difference doesn't matter much - or at least the differences can be dealt with using minimal dV, but there is a fundamental difference in the way that trajectories are modelled.

This made me thinking about if the accuracy can be improved. I don't think that moving the optimization towards n-body would be feasible, but improvements in the approximation model might be possible.

Keithth G., can you elaborate on 'patched conics' vs. 'linked conics' model? First of all, I am not sure about the definition of 'linked conics'.
On the other hand, the idea behind Patched conics is that at the edge of each SOI, you forget the other bodies. The only thing to keep in mind, is to ensure the boundary constraints regarding velocity.

In any case, I'm not being a smartass, just trying to get an idea if there's room for improvement without too much cost in regards of performance.

I have the feeling that using same ephimerides as Orbiter would make the most impact on accuracy at this point.

Do you see any particular research direction to improve on plan accuracy?

 

[Keithth G]

Keithth G., can you elaborate on 'patched conics' vs. 'linked conics' model? First of all, I am not sure about the definition of 'linked conics'.
On the other hand, the idea behind Patched conics is that at the edge of each SOI, you forget the other bodies. The only thing to keep in mind, is to ensure the boundary constraints regarding velocity.

Let's suppose that you want to make a transfer from Earth to Mars. The patched-conic approximation has a hyperbolic departure from Earth (with the central mass of the 2-body approximation being Earth); an elliptical transfer from Earth to Mars (with the central mass of the 2-body approximation being the Sun; and another hyperbolic arrival at Mars (with the central mass of that 2-body approximation being Mars. These three conics needs to be spliced together at some point. In the patched-conics model, these are done on the surface of a sphere - the 'sphere of influence' of the Earth / Mars. While in Earth's SOI, Earth is assumed to be the dominant gravitating body and outside of it, the Sun. Similarly, upon arrival at Mars: upon crossing Mars' SOI, one transfers from a regime in which the Sun is presumed to be the dominant gravitating body to one in which Mars is the dominant body.

In the linked-conics model, the same basic tripartite logic applies, except that the radius of Earth's and Mars' SOI is shrunk to zero radius. This is achieved essentially by a rescaling of masses and distances. Even through the SOI is shrunk to zero, there is still a hyperbolic escape from Earth, an elliptical transfer from Earth to Mars, and a hyperbolic arrival at Mars. The fact that the radius of the SOI is shrunk to zero gives rise to an alternative, but long-winded, name for the linked-conics model: "the zero radius SOI patched conics approximation".

It is possible to model a true patched conics model in PyKEP / PyGMO - but at the cost of introducing a large number of additional degrees of freedom in the optimisation. The result will be a solution that will be more consistent with the TransX formulation, but the increase in accuracy may be spurious.

Indeed, without resorting to a full 3 or 4-body gravity model, it is hard to develop trajectory plans that are much more accurate than the simple linked-conics model. But the maths of 2-body calculations is simple (and fast) - whereas the maths of n-body calculations is most decidedly not fast.

---------- Post added at 07:45 PM ---------- Previous post was at 07:38 PM ----------

I have the feeling that using same ephimerides as Orbiter would make the most impact on accuracy at this point.

Do you see any particular research direction to improve on plan accuracy?

Orbiter uses VSOP87 for its planetary ephemeris, whereas PyKEP uses (in its default setting anyway) JPL's Low Precision Ephemeris. So far, I haven't found material differences between the two - but then, when using TransX, a solution that is within, say 10,000 km of the true value is good enough.

It is possible to crank the handle and develop some highly accurate trajectory plans within Orbiter - but at the cost of spending many man-hours doing so. Although the result is extremely accurate, it also leads to an Orbiter experience that is extremely boring. The trajectory plan is so accurate that, quite literally, there is nothing left to do except monitor dials and gauges and, periodically, execute a minuscule corrective manoeuvre. Better, methinks to stick with the linked-conics or patched-conics approximation - even though this be at the cost of losing some accuracy.

 

[Keithth G]

Do you see any particular research direction to improve on plan accuracy?

I was giving a little more thought to this question the other day. Although my views are hardly definitive, I think that the area to focus on is using PyKEP/PyGMO as a tool for making a series of mid-course corrections by way of re-optimising the trajectory plan based on the spacecraft's actual state vector at any given point in time.

As I understand it, the MFD that you (f1re) have been working on produces an optimised trajectory plan for a trajectory involving multiple gravity assists and deep-space manoeuvres. At the start of a 'mission' this is fine. In particular, it identifies the launch date and time, the orbit into which one must launch and the planetary escape manoeuvre than needs to be executed. However, because of imperfections in the 2-body linked-conics model, because one never executes the launch and planetary escape manoeuvres perfectly, some material errors begin to creep into the outturn trajectory as opposed to the initial planned trajectory. As time goes by, these errors begin accumulate and slowly undermine the validity of the initial trajectory plan.

To overcome this accumulation of errors, it makes sense to use PyKEP/PyGMO to revise the trajectory plan. In concept, this means:

1. interrogating Orbiter to find the current position and velocity of the spacecraft;

2. incorporating that information in the PyGMO optimisation routine and then re-optimise a truncated form of the trajectory plan that takes into account the fact that part of the mission is already complete and the current state vectors of the spacecraft.

During execution of a complex mission, this re-optimisation process may need to be undertake a number of times.

Although this scheme obviously doesn't overcome the limitations in accuracy of 2-body physics, but it will help users undertake deep space manoeuvres and achieve planetary rendezvous at the correct time to undertake gravity assists.

 

[Strathcona]

It complained about msvcp140.dll being missing from my computer, and I knew what that was.

But, it might be a good idea to document the dependency.

I think I missed a dependency. I tried to activate the module and I got that message about msvcp140.dll being missing... even though I have the dll in system32. Did I miss a dependency?

 

[boogabooga]

You need the Visual C++ Redistributable for Visual Studio 2015.

 

[Enjo]

You need the Visual C++ Redistributable for Visual Studio 2015.

And the 32-bit version, not 64.