IMFD IMFD and VEEGA-type flight plans

[Strathcona]

Hello,

I've been using Orbiter for the last 10 years but I've only recently learned to use IMFD. Best decision ever.

My question is fairly specific. I'm flying a low-dV flight plan to Jupiter involving multiple flybys of inner solar system planets. In between my first flyby (Venus, MJD = 61365) and my second flyby (Earth, MJD = 61837), I orbit the sun about one and a quarter times before the Earth flyby. However when I try to enter these flyby dates into IMFD's course program to figure out my slingshot trajectory around Venus, IMFD assumes I want to complete less than one orbit around the sun before the Earth flyby, resulting in a very incorrect slingshot trajectory.

It's possible to tell TransX how many orbits you'd like to complete before target interception. How can I tell IMFD the same information in the course program?

Thank you! :tiphat:

 

[Keithth G]

It's possible to tell TransX how many orbits you'd like to complete before target interception. How can I tell IMFD the same information in the course program?

With respect to IMFD's Course Program: basically, you can't. IMFD's Course Program implements a single revolution Lambert Solver (which solves the boundary value problem: "I'm at point A and I want to be at point B at time dT in the future. What change in velocity should I apply now to get to B?"). It always assumes that the trajectory is less than one revolution. There is no option, as far as I am aware, to make it 'see' beyond one revolution.

With respect to TransX: TransX does not have a Lambert Solver. But it does project Keplerian trajectories for multiple revolutions. To engage multiple revolutions, in the "Setup" view, you need to change variables until you see "Orbits to Icept". Changing this number will allow you to go beyond 1 revolution to however many revolutions you wish. Of course, if you want to get to a specific space-time point, then the lack of a Lambert Solver in TransX will be a bit of a problem and you will have to tinker with manoeuvre variables until you have a planetary encounter with the MJD of your choice.

On the whole, my feeling is that the utility of both IMFD and TransX could be improved if they incorporated a multi-period Lambert Solver.

 

[Strathcona]

Hi Keithth,

I understand. Multi-period Lambert solver eh? I should read up on the math involved. I fiddled with the manoeuvre variables as you suggested, and was able to use TransX to come up with a flyby trajectory that placed me in the approximate orbit around the sun I needed, but it required a deep space manoeuvre to correct the error that resulted. It also made Orbiter crash to desktop shortly after I left Venus SOI (although turning off TransX and IMFD, then saving the scenario, then re-opening it prevented the crash). It looks like I'll have to repeat this for the second Earth flyby as well.

I've read your fascinating posts about the math involved in trajectory planning. Thank you for your help, I appreciate it!

 

[Keithth G]

wrt the multi-revolution Lambert Solver: there are a few papers floating around the internet on multi-period Lambert Solvers. And it is possible to build your own. But probably the easiest thing to do is to download someone else's algorithm rather than re-invent the wheel.

Personally, I find the one in PyKEP to be rather good (the chaps at ESA's Advanced Concepts Team have done a good job here.) To use it one would really need to use a lua script in Orbiter to download the spacecraft's (current) state vector (i.e., position and velocity with respect to the Sun) for your spacecraft. Then, one load's this data into PyKEP and use its Lambert Solver to solve the multi-revolution boundary problem. This will give a velocity with respect to the Sun that you need and, after subtracting your current velocity, will give you the delta-V that you need to apply now in order to arrive at your destination at the nominated arrival time. One then enters this into TransX, for example, as a 'manoeuvre' and off you go. (Of course, n-body forces will perturb the ensuing trajectory, so this process may need to be repeated a number of times.

All of this is a very 'manual' process and could easily be automated in an MFD. However, writing this MFD is probably better left to someone other than me. In any event, I actually prefer the manual process since I have complete control over the algorithm and the application of the results. But that's just a question of taste.

wrt CTD: It doubt it is TransX's fault per se - this tinkering with manoeuvre variables doesn't cause a crash for me. Orbiter was probably just having a 'bad crash day'.

 

[Strathcona]

I don't really have the computer know-how to install PyKEP/PyGMO, but having read your posts in the math/science board, it appears to be a powerful trajectory planning tool. Lately I have been experimenting with GMAT, which has a lovely GUI for knuckleheads like myself and a C++ like coding environment for more sophisticated setups, and I think it would be simple to export manoeuvre data from GMAT (using the Vector-Normal-Binormal coordinate system) into TransX (prograde, plane change, and outward respectively?), but I have yet to try it.

I agree with you, I like having to run calculations and implement the results manually using my own judgement. If one was so inclined, an n-body MFD could generate the trajectory and combine it with an autoburn function. Then you'd just sit back in your chair and watch Orbiter fly you to your destination with zero input. That seems boring.

Maybe I'll teach myself to write an MFD of some sort... :thumbup:

 

[Enjo]

I don't really have the computer know-how to install PyKEP/PyGMO, but having read your posts in the math/science board, it appears to be a powerful trajectory planning tool. Lately I have been experimenting with GMAT, which has a lovely GUI for knuckleheads like myself and a C++ like coding environment for more sophisticated setups, and I think it would be simple to export manoeuvre data from GMAT (using the Vector-Normal-Binormal coordinate system) into TransX (prograde, plane change, and outward respectively?), but I have yet to try it.

Probably yes, but there's a tool in development, which integrates PyKEP/PyGMO with Orbiter:
http://www.orbiter-forum.com/showthread.php?t=37120

 

[jedidia]

Probably yes, but there's a tool in development, which integrates PyKEP/PyGMO with Orbiter:

Finally! How did I miss that completely?

 

[Enjo]

Finally! How did I miss that completely?

Because usually great work has poor marketing and vice-versa