OHM Trajectory Optimization Tool v1.1.2

Wishbone:

Sounds good! Did you actually carry out the Jupiter-Neptune plan in Orbiter, or did you just trial it in the Tool only?

Regarding your points:
1) Can I get the flight plan that caused you this problem? I can check the debugging output and see what's going on. Might very well be an issue I need to take care of.
2) I could certainly give it a go, yeah. Shouldn't be too hard.
3) I thought about this, and it should be doable. I just have to learn how to implement dialog boxes in MATLAB first, but shouldn't be too hard. I'll see what I can do.

Thanks!

EDIT: Rereading your post, Wishbone, I should point something out. I'm actually writing this for my own edification, so none of my professors will be seeing it or have any part in it. I'm definitely doing this just for fun, no grades involved! :)
 
Last edited:
I'm sorry for my ignorance but can you please specify in common words what the C3 energy, Type I and Type II transfers stands for?
 
Hi PeterRoss,

Here's some information that might help you. The definitions of a Type I and Type II transfer, from the JPL Basics of Space Flight:

If the interplanetary trajectory carries the spacecraft less than 180 degrees around the sun, it's called a Type-I Trajectory. If the trajectory carries it 180 degrees or more around the sun, it's called a Type-II.

C3 energy is a way of quantifying how much "kick" the launch vehicle needs to provide the spacecraft to hyperbolically leave whatever planet being launched from. Mathematically, it's the "hyperbolic excess velocity" times itself (in other words, squared).

Does that help? I would suggest reading through some of the info on that JPL Basics of Space Flight link I gave up there, plenty of good information to be had. Let me know if I can answer other questions. :)
 
Thank you, Arrowstar, it's all clear for me about transfer types now:)
As for C3 energy I'd like to ask just one more stupid question: does it corresponds somehow with dV? I guess it does, but how exactly? I don't think C3 energy is just the squared sum of orbital velocity and dV. Sorry, I'm not good with math and physics at all. I just want to find what numbers output by your program I can use directly with TransX.

As for now I've used your program to check the trajectory used by me for my Earth-Saturn flight and calculated by TransX only, and it was a perfect match. Though the graph wasn't looking like porkchop of any kind, just two points.
I've wanted also to find all Mars launch windows for next ten years, but then I've found calculations would have taken 80 hours (with default settings) so I think I'll try it later :lol:

Thanks for the link, I'm planning to read all the 'Basics of Space Flight' from the moment I've found it in the 'Additional reading' section of your program readme.
 
I'm glad you've found I'm returning accurate results with my application. That's the kind of feedback I'm looking for! :)

There is going to be a correlation between how much delta-V the launch vehicle/spacecraft needs to provide and how what the C3 energy is for a given transfer. The higher the C3 energy, (typically) the higher the deltaV you're going to need to get to where you're going.

The reason I don't give it as delta-V immediately is because that would depending on where exactly you are on or in orbit around the starting body. C3 energy is more general, because it only looks at the energy you need to escape from that body.

If you want to look at the Mars transfers for the next 10 years, I'd recommend using a large date step. Try 10, 20, 30 days or so. See what that gives you. (This is what it gave me: )

10yearmarstransfers.png
 
Last edited:
With the date step of 10 days I've got the graph in 8 minutes.
And I think I'll figure out the dependence between C3 and dV for each particular flight empirically.

This tool will be quite useful for me. Thank you for it :tiphat:

---------- Post added at 04:59 PM ---------- Previous post was at 04:38 PM ----------

I believe I've found a bug. When you use the Zoom In function on the graph screen it does zoom in, but the axial numbers remains the same relative to the lower left corner of the window.
 
I believe I've found a bug. When you use the Zoom In function on the graph screen it does zoom in, but the axial numbers remains the same relative to the lower left corner of the window.

Confirmed. Thanks for the report. I think I know what's causing it, let me see if I can't do something about it. :tiphat:

Wishbone: You got your "Est. Time Remaining" counter tonight. :)

EDIT: Regarding zoom error: D'oh. Well that was silly. :blush: Fix will be in next release.
 
Last edited:
Is this compatible with Windows 7 because I installed the MCR and try to open the trajectory exe and its complaining that the MCR directory is not found
 
Have you rebooted the OS after installing the runtime?
 
Is this compatible with Windows 7 because I installed the MCR and try to open the trajectory exe and its complaining that the MCR directory is not found

I'm running Windows 7 with no problems, so I have to imagine so, yes. :) Wishbone's suggestion is a good one, please try rebooting. Thanks! Let me know if you still have issues afterward.
 
that work but now when I analyze the results all I see is dots instead of the porkchop plot on the graph screen when calculations are finished
 
Was leafing through FlyTandem's masterpieces, including EVEEJN. (Two slings around the Earth, one after another). The attempt to replicate the plan failed, TOpTool doesn't allow two successive slings around the same body. Which is sort of a shortcoming, given lots and lots of resonance-based missions.

Also attaching the file that with B-Plane set to Partial seems to lose the CPU.
 

Attachments

  • E.ZIP
    E.ZIP
    442 bytes · Views: 4
jgrillo2002: You'll need to set the Max C3 and Max Delta-V options higher, as was pointed out. You can try infinity (Inf) to start and see what that gives you.

Wishbone: The flight plan you gave me is incredibly long. Even skipping every 30 days, we're still looking at a computation time of ~13 hours. If I had to take a guess, either you ran out of memory or something wonky and memory-related happened to the underlying Java code that MATLAB is built on. I've seen both happen on very long computations, though admittedly only once and I would think it'd be pretty infrequent in general.

Is there a way to specify how many revolutions around the Sun you go before reaching your destination in Lambert's Equation? That must be the only way you can do something like EVEEJN, going around the Sun at least once and then coming back. Let me see what information I can find...
 
I ran the plan with a 50 or 75 day grid.
 
I ran the plan with a 50 or 75 day grid.

Let me give it a go on the latest build with both intervals and see what I end up with.

---------- Post added 01-24-11 at 10:46 AM ---------- Previous post was 01-23-11 at 02:14 PM ----------

Update: I didn't encounter the process issue you did, Wishbone. I ran your flight plan on the (yet to be released) v1.1 code... would you care to try out the new executable and see if it still occurs? Let me know and I'll PM you a link with a ZIP file.
 
A somewhat belated response: afraid am a bit too busy for the next ten days or so. As soon as there's a suitable time slot, will do Orbiter-related stuff, TOpTool included...
 
Nice tool. I am exploring using this tool as part of my Spacecraft Design class this semester. The design project is an asteroid mission, and I have one question related to that specifically, and one more general.

1) I downloaded a custom SPICE file (.bsp) for one of the candidate asteroids (2001_US16). I got this file by logging into JPL Horizons and getting it to generate the bsp file for the date range of interest. When I load it into the Traj Op. tool, it does not display a name. It shows that two SPK files were loaded. It shows a new entry after MARS, but it just has --> and then blank space. Any idea why a name or number doesn't appear?

2) It looks like the tool doesn't calculate arrival conditions. Is this true? Sometimes the lowest departure C3 is not the best trajectory if it means you come rocketing into your destination with too much energy to slow down for orbit capture.

Thanks,
-Steve
 
Wishbone: Not a problem. :)

sraque: 1) I'm familiar with JPL Horizons but not with whatever function allows you to build custom BSP files. Can you describe to me, in detail, how to go about doing it so I can test it later?

2) It actually does calculate body-centric arrival velocity (versus heliocentric arrival velocity and all that), but it doesn't display it. You are perfectly correct, however, in saying that arrival conditions can dictate your flight plan. Would it be worth seeing a contour map of arrival velocities on the departure/arrival plane for the final body in the flight plan?
 
Back
Top