Project Trajectory Optimization Tool Development

[Arrowstar]

Trajectory Optimization Tool v2.0
By Arrowstar

The Trajectory Optimization Tool is a MATLAB-based utility used for finding the optimal trajectory between any number of bodies in the solar system. Given an initial planet, the subsequent bodies to visit, and a range of dates for launch and arrival, this tool will provide the user with the optimal flight plan for accomplishing the mission's goals. It is a perfect complement to TransX or similar Orbiter MFDs in that it can provide launch and arrival dates, deltaV estimates, and other necessary figures needed to execute an interplanetary mission.

The internals of the software use a Gooding solver in order to solve Lambert's problem. A patched conics approximation is used when computing flyby maneuvers. Ephemerides provided are from JPL's Navigation and Ancillary Information Facility.

This software was created and tested on MATLAB 2010b and requires the MATLAB Compiler Runtime, version 7.14 (included) to execute.

Version History

Version 0.5 – Initial Public Release. Requires MATLAB 2009b to run.

Version 0.7 – Major Revision. Executes as a Windows standalone application. Addition of a GUI for program control. Requires MATLAB Compiler Runtime v7.14 to run. Numerous additional bug fixes in user interface, output code, and trajectory code. NOTE: The size of the download has increased significantly from version 0.5 to version 0.7. This is due to the large (~180 MiB) MATLAB Compiler Runtime that had to be included with the package.

Version 0.8 – Major Revision. Date ranges may now overlap, and dates may be entered as MJD. Text in output is now selectable. Dates on plots are now in MJD. Date step may now be entered as a positive floating point number. Maximum C3 Energy and Delta V added/updated. Central body now saved in Flight Plan file. Updated documentation. New demo flight plan. Other numerous minor bug fixes and alterations.

Version 1.0 – First “Release” Version. Added pause/resume button. Various buttons now go inactive during while calculations are in progress so they cannot be accidently pressed while the program is running. New B-Plane angle steps added. New B-Plane search modes added. A major bug with the B-plane delta-V calculations was fixed. Other minor bug fixes and tweaks. This documentation updated.

Version 1.1 – Major Revision. The Lambert solver has been changed from p-iteration to a Gooding solver, which is more robust and should also be faster. Multiple revolution transfers are also possible using this solver now. The B-Plane fly-by search code has been heavily optimized for a five-fold increase in speed during this segment of calculations. The ability to output a plot of arrival velocities at the final body on the flight plan has been implemented. An estimated time remaining clock has been added. The legend on plots has been moved to below the abscissa on all plots. Other minor bug fixes and tweaks.

Version 1.1.1 – Bug-fix release. The zooming/panning issue with axis tick mark numbers on graphs should be eliminated. The B-Plane plot legend has been moved and updated to show additional information. Other minor tweaks.

Version 1.1.2 – Updated the size of the GUI box so that it can fit on monitors with resolutions less than 900 pixels.

Version 2.0 – Major Revision. Completely rewrote application from scratch. Now includes ability to globally optimize arbitrary trajectory using genetic algorithms. Completely new user interface. Ability to generate individual pork chop plots independent of optimization run. Trajectories are now plotted as a visual aid. Documentation completely rewritten. Numerous other rewrites, updates, and corrections.

Get the Trajectory Optimization Tool

Downloads are available from Orbit Hanger Mods: [ame="http://www.orbithangar.com/searchid.php?ID=5418"]Trajectory Optimization Tool[/ame]
​

 

[n72.75]

That's impressive, I hope you'll post the *.m file at some point.


Also, out of curiosity: what are you using as a data source for planetary positions.

Another question: where are you studying astrodynamics?
I'm studying aerospace engineering at Clarkson University.

 

[Wishbone]

Arrowstar, one thing that present interplanetary add-ons (TransX and IMFD) miss is the automatic search for the dV minima in the Launch-Arrival plane. While Piper's planner does that, it is outside Orbiter. I will do minimization in a separate thread, but only for single-conic missions (like LEO rendezvous/intercept), and I'm not a physicist/astrodynamics specialist. It would be great if you could come up with a patched conic optimizer...

 

[Arrowstar]

That's impressive, I hope you'll post the *.m file at some point.


Also, out of curiosity: what are you using as a data source for planetary positions.

Another question: where are you studying astrodynamics?
I'm studying aerospace engineering at Clarkson University.

It's actually a series of .m files with a variety of functions. My plan is to throw it up on OHM when I get it to the point where I like it. My current plans, like I said, are to improve the execution speed and add in some fly-by calculations, after I determine what metric is most useful for determining optimal fly-bys. I may leave it in .m form or I may see if I can't get the MATLAB compiler to work and build a GUI. We'll see.

My source for data is JPL's NAIF organization. Particularly, I'm using their DE421 ephemeris data along with their MATLAB implementation of the MICE toolbox. You can download these files freely, I've used them for a variety of academic and personal projects. Check it out: http://naif.jpl.nasa.gov/naif/

I'm studying astrodynamics at Purdue University.

---------- Post added 12-18-10 at 01:47 AM ---------- Previous post was 12-17-10 at 05:40 PM ----------

Arrowstar, one thing that present interplanetary add-ons (TransX and IMFD) miss is the automatic search for the dV minima in the Launch-Arrival plane. While Piper's planner does that, it is outside Orbiter. I will do minimization in a separate thread, but only for single-conic missions (like LEO rendezvous/intercept), and I'm not a physicist/astrodynamics specialist. It would be great if you could come up with a patched conic optimizer...

Interesting idea. I guess my question to you would be: by what metric do I optimize? DeltaV is the usual answer, but since you typically eject directly from launch into the first stage of the transfer, that's really rather hard to know (depends on launch site, etc - this is why we use the C3 energy as the optimization metric for normal transfers, I think). I really don't want to deal with calculating launch deltaV, that's outside my current experience. If I just look at deltaV for the fly-by maneuvers, we might have something, but ideally you don't need to burn anything at all when flying around the solar system. I could look at equivalent deltaV from gravity assists, but who really cares how much extra boost you get from the planet so long as you're not the one paying the price? I suppose we can knock out all swing-bys that have a pass altitude of less than 0, but that only defines a cutoff, not an optimum.

One idea I had was to look at relative arrival speed, the thought being that the slower arrival speeds will make the insertion burn/aerocapture/etc easier. I'll probably code up an external function to handle this tonight, actually, since it seems like a good idea. If anyone can provide any other suggestions for optimization metrics (or, if anyone actually works in the business, let me know what we really do!), that'd be great.

---------- Post added at 06:01 AM ---------- Previous post was at 01:47 AM ----------

Tonight I modified the scripting to allow for full missions to be computed. The code is capable of taking a range of initial launch dates and ranges of arrival dates to various bodies, and computing pork-chops for each of the transfers. Just for kicks, I took the transfer I showed in the pork-chop plot above added a Mars -> Venus transfer. Here's the transfer plot:

Notice how the departure dates on this plot match the arrival dates on the Earth->Mars plot I did above. We can see here that you would ideally leave Mars to get to Venus around 3850, but that's not particularly optimal to arrive at Mars, so this transfer solution is probably not very good.

The next thing is to compute the fly-by targeting information for each plot. I'd like to present the user with all the B-plane targeting information so they could use it with guidance software or some such thing. But, so far so good.

Oh, right, last thing: with the exception of Earth and Mars, I have to use the body barycenters because the bodies themselves aren't in the JPL NAIF files. But I think it's close enough, yes?

 

[Notebook]

Probably a simple question, hopefully a simple answer! What is the vertical scale to the right of the graph, 18 to 30?

N.

 

[n72.75]

Oh, right, last thing: with the exception of Earth and Mars, I have to use the body barycenters because the bodies themselves aren't in the JPL NAIF files. But I think it's close enough, yes?

Yeah that should be plenty close

 

[Arrowstar]

Probably a simple question, hopefully a simple answer! What is the vertical scale to the right of the graph, 18 to 30?

N.

The vertical scale is C3 energy, in km^2/s^2. It's the departure hyperbolic excess speed squared, and is twice the hyperbolic departure orbit's specific energy.

n72: Good to hear. :thumbup:

---------- Post added at 08:06 PM ---------- Previous post was at 02:25 PM ----------

So, more progress!

I've put together a function that computes the DeltaV required to go from one planet to another planet based on the results of the function that optimizes the transfer arc between two points. It takes the hyperbolic velocity vector and iterates on all possible semi-minor axis vectors on the B plane from Theta=0 to Theta=2*pi and between a min and max value for the hyperbolic periapse (don't want to crash!). The result looks something like this:

This, by the way, is the Mars flyby to get to Venus, the porkchop plots of which are above. It gives results for the B vector in terms of the T and R unit vectors. What this is telling us, if I did the math right, is that a pass targeting an aim point with "B dot T" of about -0.75E4 and a "B dot R" of about 0 will minimize the amount of fuel you need to burn at periapse to get onto the heliocentric departure velocity vector another part of the code calculated as being the optimal departure vector.

Since this is a patched conics approximation, I'm assuming all these deltaVs at the swingby are happening instantaneously. In other words, to go from the arrival velocity vector to the departure velocity vector, we use:

V1_Vector + deltaV_Due_To_Flyby + deltaV_Engine = V2_Vector

What I've done is rearranged that to solve for the deltaV_Engine part. The results of doing so are what you're seeing in the picture up there. The "deltaV_Due_To_Flyby" vector is the equivalent deltaV you'd pick up from the planet if you flew by it unpowered.

Comments? Questions?

 

[Arrowstar]

Arrowstar, one thing that present interplanetary add-ons (TransX and IMFD) miss is the automatic search for the dV minima in the Launch-Arrival plane. While Piper's planner does that, it is outside Orbiter. I will do minimization in a separate thread, but only for single-conic missions (like LEO rendezvous/intercept), and I'm not a physicist/astrodynamics specialist. It would be great if you could come up with a patched conic optimizer...

Alrighty. I think I have accomplished what you have asked. You said you were looking for a patched conic optimizer, presumably for multi-body tours of the solar system. Here's what my code does now.

On the first transfer, it generates a norm porkchop plot with the C3 energy on the launch/arrival plane. It also computes the minimum C3 energy on the launch/arrival plane and tells you what day you'd have to launch to pull it off. This part of the code has been verified for the most part, if I can take some images from NASA JPL and Piper's "Trajectory Planner" program to be verification of the underlying math. So far, so good.

On the second transfer orbit (and all subsequent arcs, for that matter), the code takes the arrival velocity vector computed from the optimal first transfer trajectory. On every trajectory calculated between the second and third body (and so on), the code uses the optimal arrival velocity vector and the computed necessary departure velocity vector for that iteration to determine the minimum deltaV you'd need to add with your engine to swing by the planet in the correct direction. It does this for every trajectory it computes between the second and third body. At the end of the trajectory iterations, it finds the trajectory that offers the lowest powered deltaV as the optimal solution.

This process of "compute trajectory, check flyby deltaV" is performed for every transfer arc except the first one. Sadly, it quadruples the amount of time to code takes to execute, but all in all it's not *terrible*. You might need to go get a cup of coffee and chat with some folks for a few minutes, but it'll finish soon enough. Of course, the larger the departure/arrival plane, the longer the code takes to execute...

Here's an example output from the code. It shows the Saturn B-plane of the optimal Saturn-Uranus trajectory that the Voyager 2 probe approximately used.

The big blue circle on the right is the region of lowest powered deltaV. While the plot doesn't show the minimum value, the output from the code places it at lower than 0.03 km/s, which is effectively 0 given the somewhat grainy resolution I used to calculate points on the B-plane. As far as I can tell, if you aim for the middle of that circle (literally, if your hyperbolic aim point is in the middle of that circle), you'll hit the minimum deltaV swing by.

The code also computes the heliocentric orbital elements of each transfer orbit, so you can check to see if you're on the right path or not. Since I'm using a patched conics approach, they probably won't be perfect, but close enough for planning I hope.

Some example output from the code looks like this:

##########################
Computing possible transfers between Saturn and Uranus.
There will be 22 total iteration cycles.
Starting Type 1 transfer calculations.
Completed tenth iteration (82.7012 total seconds elapsed)....
Starting Type 2 transfer calculations.
Completed tenth iteration (173.2148 total seconds elapsed)....
C3 Energy Calculations Complete.
Finding C3 energy minimums
Generating pork-chop plot....
-> The Fly-By Powered DeltaV of the optimal Type I transfer is 0.0155 km/s. The launch window is centered around 30-Aug-1981.  The transfer time is 1610 days.
-> The Fly-By Powered DeltaV of the optimal Type II transfer is 24.6275 km/s. The launch window is centered around 20-Aug-1981.  The transfer time is 1624 days.
##########################

I'm open for comments, suggestions, and questions as always. This has been a fun little project.

 

[Arrowstar]

So I finally got around to cleaning up the code and making the utility publicly presentable. Keep an eye on OHM, it should be hitting shelves there as soon as it's approved. Happy optimizing.

So where do I sign up for my Addon Developer tag? :lol:

(Just kidding )

 

[Arrowstar]

Here's another little teaser. I spent the past few days working on a simple GUI for the backend code. I'm happy to report that, thanks to the wonders of the MATLAB compiler, I've now got the code running as a standalone Windows application. This means that everyone, not just those with MATLAB, will be able to run this Tool.

Enjoy!

Moderator: Could I get this thread moved to the Add-on Development sub-forum with the title changed to "Trajectory Optimization Tool Development"? Seeing as how my little question exploded into its own add-on and all that... :lol: Thank you.

 

[jgrillo2002]

Pardon me for asking but is this more accurate than piper's calculations or are they just the same as his?

 

[Arrowstar]

Pardon me for asking but is this more accurate than piper's calculations or are they just the same as his?

That's a very good question. My answer, unfortunately, can only be purely speculative as I really don't know the internals of Piper's software. There are two parts to this answer:

First, the calculations behind the C3 energy (porkchop) plots appear to produce near identical results. I did some validation using Piper's tool and data I had from JPL regarding the Mars 2005 transfer window and my work appeared to converge with the other two nicely. Without additional information, I'm going to go out on a limb and say that Piper's tool and mine are identical in this sense.

Second, however, is the matter of additional features. Piper's tool will give you porkchop plots for any two bodies in the solar system. I've attempted to take this a step further by allowing the user to enter in an arbitrarily complex flight plan over any number of bodies. The tool will then attempt to optimize that flight plan as to minimize not only the C3 energy, but also the needed deltaV when swinging around planets for a gravity assist. The idea is that the planet should do all the work for you, and my tool attempts to figure out if that's possible, and if so, how to go about it by providing targeting information needed to properly swing by the planet.

Does that answer your question?

 

[Ripley]

...I've now got the code running as a standalone Windows application. This means that everyone, not just those with MATLAB, will be able to run this Tool.

On Orbit Hangar page ([ame="http://www.orbithangar.com/searchid.php?ID=5034"]Trajectory Optimization Tool[/ame]) it says
...To use this software, you must have MATLAB...
So, is MATLAB required or not??

 

[Arrowstar]

On Orbit Hangar page (Trajectory Optimization Tool) it says
...To use this software, you must have MATLAB...
So, is MATLAB required or not??

Ah good, it finally make it up. In version 0.5, MATLAB is required, yes. The Windows standalone version is 95% complete, I'm just working out some packaging details. The application requires the MATLAB Compiler Runtime (in the same way that other applications require the .NET Framework), and that's a bit large. I've still determining the best way to package it.

The stand-alone version will be uploaded by the end of this weekend.

 

[Arrowstar]

Good news, folks! I'm ahead of schedule on my coursework, so I took some time and got the latest version packaged and uploaded. See the first post in this thread for details. Feedback on the tool in this thread would be greatly appreciated.

Happy optimizing!

---------- Post added at 06:19 PM ---------- Previous post was at 01:42 PM ----------

While I'm thinking about it, could I get some folks who use TransX or IMFD to try a couple flights around the solar system, using the data my tool provides? I'd like to see just how good the data from my software is at helping setup interplanetary flights. If anyone wants to provide feedback in this regard, that'd be great.

 

[rappolee]

my first post here!
Arrowstar, what you are doing is wonderful!
thank you.I will see if its possible to teach my self how to use this program, I have a project in mind.The pioneer and voyager space craft has Star solid motor kick stages, years ago I was talking to Dr Stone( Aug 1994) the Pioneer PI about the trajectory of these motors, and it seems that in the case of pioneer 11 that third stage is not in a solar system escape trajectory, in addition one of the voyager third stages got really close and perhaps inside the Jupiter B plane impact ellipse.these letters from Dr stone are now lost( my copy) and I have lost the early pioneer AIAA astrodynamics papers, however please see the profile image
would anyone care to help me find pioneer and voyager Pre TCM-1 orbital elements and propagate them out to the stars??
the above I have posted on Wiki some years ago but I need to verify the facts
some years ago I tried to convince the new horizons team to place some sort of plaque on the third stage, but they declined to do so
thanks

after extracting the file, my computer says the mcr compiler is not recognized.................or not present.
so the read me says download again..............

so I have, MCR downloads and I get the, finish, after that trajectory program does not recognize the MCR metlab
the pc states, can not recognize MCR 7.14 or something

 

[Arrowstar]

rappolee: Thank you for the kind words. What you would like to do sounds interesting. I would recommend creating a new thread on the Forum for that discussion, as to keep my development thread on-topic. Thanks!

A quick poll to the community on two items:

First, would it be more intuitive if I changed the launch/arrival dates on the porkchop plots to be in MJD, versus my current JD-245000 scheme? Orbiter uses MJD, and I'm wondering if that wouldn't help when actually flying things.

Second, would it be helpful when getting around the solar system to see the Keplerian orbital elements for each transfer, relative to the Central Body? Or is this information not really used when you're flying about the solar system?

Thanks!

 

[rappolee]

that's a good idea, let me create a thread for that,

will I be able to input old orbital ephemeris into your trajectory tool?
(and how)
also notice you can change Sun to a planet for satellite orbital tours, I have a PDF document that everyone should read,

CASSINI END-OF-LIFE ESCAPE TRAJECTORIES TO THE
OUTER PLANETS :thumbup:

but its to large to up load here:facepalm:

lots of thought went to flying Cassini out of the Saturn system at end of mission! This might make a good thread too................
let me work on a thread for this topic to,
Done!

 

[Arrowstar]

will I be able to input old orbital ephemeris into your trajectory tool?
(and how)

That was a huge question for me when I starting developing this tool. Should I allow users to enter their own orbital elements? In the end, I didn't include this capability for two reasons.

First, there are physics problems associated with this sort of thing. If you were to give the program a set of orbital elements, relative to the Sun, and at some point during the analysis the Earth's positive and spacecraft's position became very close, that would ruin the results of the analysis because the Earth would influence the spacecraft in a way that the patched-conic approximation does not account for.

Second, there is the problem of knowing where on the orbit the spacecraft is. If you don't provide true S/C's true anomaly, then I have no idea where the spacecraft is. If you do, that means that you're always looking at the same point in space, even if the planets are moving. This really doesn't make sense, since what you as the user actually want is to make the spacecraft propagate along its orbit and then determine when the best time to leave that orbit is. Either way, we have a problem.

For now, I won't have this capability. If there's a good way to implement it and I figure that out in the future, then I will do so. For now, though, it is what it is.

Thanks for the suggestion! :tiphat:

 

[rappolee]

not a problem!
I have made a post in regards to a future...................flight
the thread idea is in the above post,
your read me PDF suggests replacing the sun with your planet of choice and using your tool to propagate satellite tours
right?
the post is over on the, "challenge" thread, steal the cassini probe from its end of mission dive into Saturn's atmosphere and send it somewhere...............