OHM Trajectory Optimization Tool v1.1.2

[OrbitHangar]

Author: arrowstar

This version is outdated.  Get the up-to-date version here: http://www.orbithangar.com/searchid.php?ID=5418

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 at each body, 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 manuevers.  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 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.  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.  Documentation updated.

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.


DOWNLOAD

 

[Arrowstar]

From the development thread:

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.

 

[jedimaster1214]

I believe we already have something like this: [ame="http://www.orbithangar.com/searchid.php?ID=4439"]Trajectory Planner[/ame]

 

[jgrillo2002]

I believe he knows that.

 

[Arrowstar]

I do indeed. Piper's Trajectory Planner is a great tool and one I used to help validate my own code. However, the software I've released (and am continuing to release as I improve it) is designed to do a bit more than Trajectory Planner. I'll leave the details for the documentation, but basically, what I've written can handle optimizing multi-body tours of the solar system (or, in fact, any system of moons around a planet, if you load the necessary data). It's designed to be a complement to TransX or IMFD in that you can use it to automate the search process for a trajectory, and then use those MFDs to actually fly the mission.

Also, having a choice of software is never a bad thing.

 

[BrianJ]

Super cool! :thumbup:
Can't wait til the weekend to try the "non-Matlab" version.
Thank you :hail:

 

[XZentus]

Perfect tool! Thanks!

One question: are there any difference between last version(212.26 MB: Date Added: 14/01/11) and first one released here(45.5 MB)? I have Matlab and rather slow i-net, so have I a reason to download last version?

 

[Arrowstar]

You'll most likely want this version, yes. The main difference is that I built this version with the MATLAB Compiler so it can run as a Windows application. This is the reason that the file is so large: I had to include a ~180 MiB MATLAB runtime so that people could run it. There are also numerous enhancements (such as the inclusion of a GUI) and bug fixes (some rather important) in this version. I know the download cost for this version is kinda steep, but if you can manage it, I would include re-download it.

 

[Wishbone]

As Arrowstar explained in another thread, it's a standalone Windows version (with Matlab runtime, and MICE, that is). For me, it's worth the time to wait till I get to broadband (Monday perhaps), since I've got only SPICE and CSPICE but no MICE...

 

[Arrowstar]

MICE is included in the package, no need to get it on your own this time.

 

[rappolee]

I am lost, are there two threads on this topic?

I am lost, are there two threads on this topic?
and they are not merged?

 

[orb]

I am lost, are there two threads on this topic?
and they are not merged?

This is a release thread, which is automatically created and updated by Orbit Hangar Mods when add-on is uploaded, and deleted when add-on is removed from Orbit Hangar Mods. Other thread is a development thread created by add-on developer.

Those threads can't be merged, because the development took place earlier, and after merging them the OrbitHangar wouldn't be any more the thread owner. The link between comments here and the add-on would be broken, and probably a new thread for this add-on would be created by OrbitHangar to fix missing comments thread for this release.

The other Trajectory Planner is another add-on, so it has its own threads (OHM release / development) too.

 

[Turbinator]

I would love to know how to use this tool. It just goes that one step above in making Orbiter as real as it gets, so I would really love to know how to use a tool like this.

Any tutorials would be greatly appreciated.

 

[Arrowstar]

Turbinator: It's quite straightforward, really. I included a nice manual with the application, along with demo flight plans. All you do is fill in body names and dates, and then push "Optimize." Very easy.

 

[Moonray]

Excellent tool !

May I suggest some improvements ? I would be cool if you can auto-fill date range after the first step, with typical Delta-T for a Hohmann transfer. Otherwise, it is quite difficult to enter plausible time windows, especially for unusual transfer.

Thanks again for this wonderful tool !

 

[Arrowstar]

Excellent tool !

May I suggest some improvements ? I would be cool if you can auto-fill date range after the first step, with typical Delta-T for a Hohmann transfer. Otherwise, it is quite difficult to enter plausible time windows, especially for unusual transfer.

Thanks again for this wonderful tool !

That's an interesting idea, Moonray, thank you for suggesting it. I guess the problem I see with the suggestion is two-fold. First, in practice we rarely setup Hohmann transfers because they take so long to complete. There usually isn't that kinda of time with a human crew. Second, an Hohmann transfer is only possible when the planets are positions correctly. The first planet's position when the spacecraft departs has to be 180 degrees from the second planet's position when the spacecraft arrives. This doesn't occur that often, so auto-filling dates for a trajectory you (probably) can't use doesn't seem too helpful.

As I noted in the documentation, it's probably helpful for you to start with large date ranges and a large date step, and then focus in on the "low points" in the contour plots with smaller date steps. For example, here's a two year analysis I did for an Earth-Mars transfer. The launch axis runs from 06/2005 to 12/2007 and the arrival axis runs from 12/2005 to 09/2008:

As you can see, I've found both the 2005 launch window and the 2007 launch window. Say I wanted to get to Mars by leaving in 2007. I now have a decent range of dates I could use to do a focused study. I should point out that the plots you're seeing above look rough because I skipped every 10 days. But the whole analysis only took a few minutes and the information I recovered from it is enormous.

My advice: start large, then focus in on what you want. Thank you for bringing this suggestion to my attention, though! This is what I want: ideas that I haven't thought of. Every concept is much appreciated! :tiphat:

 

[Moonray]

My advice: start large, then focus in on what you want. Thank you for bringing this suggestion to my attention, though! This is what I want: ideas that I haven't thought of. Every concept is much appreciated! :tiphat:

Thanks for your precise and interesting answer. I was not fully aware, indeed, I could start with such large windows, with large date step.

My next suggestion : for an more easy iterating process and focusing, can you allow to enter MJD for start and end date, because they are exprimed as such in the result graph.

 

[Arrowstar]

My next suggestion : for an more easy iterating process and focusing, can you allow to enter MJD for start and end date, because they are exprimed as such in the result graph.

I'll look into doing that, yes. You're right, it would be easier. I'm also going to make the dates on the porkchop plots MJD, because I realize that what I have now is silly if I'm trying to use it with Orbiter.

Thanks for the suggestion.

EDIT: And done. The behavior now is that if you enter a date as MJD, it will convert itself to the appropriate yyyy/mm/dd format automatically. The logic that looks for this basically checks to see if you entered a floating point/integer number. If you did, it gets treated as MJD. If you didn't, it tries to deal with it as a yyyy/mm/dd date and performs all the usual formatting checks on it as usual. Should be sufficient. Plots are also given in MJD now, as well. Thanks for the suggestion! I'll have this version up probably early next week, depending on what kind of response I get to my query over in the development thread.

---------- Post added 01-16-11 at 06:06 PM ---------- Previous post was 01-15-11 at 07:02 PM ----------

Tool has been updated to version 0.8 with numerous fixes and additions. See development thread for details. The updated file should be hitting OHM shortly.

 

[Arrowstar]

Updated to version 1.0. See the first post of development thread for details and download information.

 

[Wishbone]

Did a first-approximation run for my flight to Neptune with a Jupiter sling on 0.8. Awesome! (I'll try other slingshot combinations later to get within the limits of the craft) Ideas and comments:

1. There are conditions (suspect when B-plane is set to Partial, and this possibly was fixed with 1.0 - can't wait till Monday when I get to download it on broadband) when the execution simply ceases (the process doesn't use CPU).
2. Estimation and display of time remaining can be helpful since all iterations are more or less equal as far as complexity is concerned (assuming constant CPU load).
3. Same for ability to save flight plans with a non-default name (a minor nitpick, I know, and not directly relevant to the way your professor is going to assess the tool).