Project Trajectory Optimization Tool Development

[Arrowstar]

Alright, sounds good.

 

[krom0025]

Great tool Arrowstar. I find it very useful. I was wondering if you have tried using any of the ephemerides files from the NASA website? I downloaded the file "jup230l" to get the moons of Jupiter added. It seems the orbits plotted with your program fly all over the place and don't seem to stay near Jupiter. Is this a problem with the coordinate system or the reference points used for the data? Thanks again for a great tool.

 

[Arrowstar]

I suspect the problem you're having is that, for the moment, the central body for all TOT transfer arcs is the Sun. There's no way to set it to use Jupiter or something else. 90% of the code to make that happen is there, and so its mostly a matter of implementation.

To confirm, can you describe the Flight Plan you gave the program?

 

[astrosammy]

Are multiple slingshots around the same planet possible? I tried to recreate MESSENGER's trajectory, which has multiple Mercury flybys, but only get "Error: Flight plan waypoints x and y are set to the same body. ".

 

[krom0025]

I suspect the problem you're having is that, for the moment, the central body for all TOT transfer arcs is the Sun. There's no way to set it to use Jupiter or something else. 90% of the code to make that happen is there, and so its mostly a matter of implementation.

To confirm, can you describe the Flight Plan you gave the program?

I was doing a flight plan from Earth-Jupiter-Europa hoping to finding an arrival time at Juptier that would allow me to approach Europa without having to perform and orbit insert around Jupiter first. I think you must be right about why I am seeing the problem because the ephemerides data for Europa was with respect to Jupiter and not the sun. Perhaps something to be implemented in a later version?

By the way, did I read previously that you were getting your masters from Purdue? Great school for aerospace. I got my PhD there in chemical engineering back in 2008.

 

[Arrowstar]

Are multiple slingshots around the same planet possible? I tried to recreate MESSENGER's trajectory, which has multiple Mercury flybys, but only get "Error: Flight plan waypoints x and y are set to the same body. ".

Yeah, in the Flight Plan window you need to set the "number of revolutions" between Earth and Earth to +/-1 (that is, try either +1 or -1, could be either solution). Sometimes the Lambert solver gets a bit finiky here, but it should be possible. If you get it to work, please do let me know. I've never tried to recreate Messenger's flight.

Eliminating the need to enter this stuff manually is a big part of v2.1. I'm in the middle of two new features right now, having just finished the Departure Analysis Tool:

1) eliminating the need for the user to manually enter the transfer type (already coded up and working) and number of revolutions (not started), and
2) a new Flight Constraints window, which will allow the user to set the following constraints on the flight:
--Set the departing/arriving/swing-by date & time for a particular body in the Flight Plan
--Set a maximum/minimum transit time between two bodies in the flight plan (which also allow you to set the maximum/minimum transit time for the whole flight plan if you select the first and last body in the flight plan)
--Possibly other time-related constraints (suggestions welcome!)
3) Check box to consider (or disable) multi-revolution solutions

What I intend to happen for for Messenger-like trajectory in v2.1 is something like this: When optimizing such a trajectory, TOT realizes that you're looking to do an Earth-Earth flyby and understands that the "number of revolutions" between these two points in the flight plan must not be zero. It internally sets a constraint that says abs(numRevs)>=1 and moves on.

Btw, this "number of revolutions" thing is required by the Lambert solver, which is why I discuss it here at all.

---------- Post added at 12:57 PM ---------- Previous post was at 12:46 PM ----------

I was doing a flight plan from Earth-Jupiter-Europa hoping to finding an arrival time at Juptier that would allow me to approach Europa without having to perform and orbit insert around Jupiter first. I think you must be right about why I am seeing the problem because the ephemerides data for Europa was with respect to Jupiter and not the sun. Perhaps something to be implemented in a later version?.

TOT currently uses a patched conics approach to determining flybys and all that. This means that the central body for the flight plan pretty much needs to remain fixed and that its hard to move "down" the celestial body hierarchy from Planet to Moon-Of-Planet. Here's why. Let's say you do your Earth to Jupiter approach. Now, where does the TOT think you are? Well, in the sun-centered coordinate system, it has you at exactly the location of Jupiter! Now try and translate this over to a Europa fly-by. Where are you? Well, you're still centered on Jupiter's location of course, because this is all the information the TOT has. This is obviously completely unrealistic (starting out inside Jupiter) and the Lambert solver will choke at having to deal with a position vector of <0,0,0> on top of it all.

There may be a nice way of doing something like this, and it's something I would LOVE to implement, I just haven't given the problem enough thought really. Suggestions, of course, are welcome.

 

[astrosammy]

Just going from Earth to Earth works, but when I add Venus to the flight plan:
"Error: Function values at interval endpoints must be finite and real."

Also happens with Earth->Venus->Venus.

 

[Arrowstar]

Sounds like you've run into a bug I fixed a while back for v2.1. What happens is that the TOT tried to pass the same date for two subsequent waypoints into the DeltaV function. This gives a time of flight between those waypoints of 0, which mean causes the Lambert solver to choke and return NaN for all its outputs. This NaN finds its way into a root-finding algorithm used in the flyby code, and its this root-finding code (MATLABs fzero() if anyone's interested) that's throwing the error you're seeing.

I fixed it by telling the trajectory function to output Infinity for the cost of any function where two subsequent dates are the same. This eliminated the problem.

You'll just have to wait until v2.1 for now, I suppose. Sorry about that. :blush:

 

[Arrowstar]

Quick update:

The last thing I need to do before the 2.1 release can get pushed out is the flight constraints stuff I was talking about previously. Everything else (number of revolutions as a design variable, the departure analysis tool, and some bug fixing) has been completed so far as I can tell.

Since the flight constraints stuff isn't too challenging, I suspect I'll be able to finish it by tomorrow. Should be straight-forward.

If anyone wants to beta test for a day or so, let me know and I'll point you to the file location on my Dropbox tomorrow. It would be quite appreciated.

EDIT: So it turns out that the GUI is more involved than I previously anticipated. Hopefully I'll finish this up tomorrow (Saturday).

 

[usmc3891]

It might be a stupid question but how do I go about using the data from TOTin Transx?

 

[Arrowstar]

Well, the information you get out of the TOT includes optimal departure and arrival dates. While I'm not terribly familiar with TransX, I suspect you could use these dates within TransX. You may also be able to verify the orbital elements you have once you're on your transfer orbits against the orbital elements contained within the report you can generate with TOT.

Hope that helps!

 

[Arrowstar]

Hi everyone,

Today I finished up the last piece of technical work left on the next release of TOT. This included writing the code for the flight constraints system and hooking it up to the genetic algorithm. Anyway, long story short, we now have this:

This allows the user to set the maximum duration a flight should run (good for sending humans around the solar system!), the minimum duration (mostly for symmetry), and the min/max duration between any two waypoints (the big table in the center).

Additionally, I used this area to enable/disable "multi-revolution" mode in the Lambert solver. Disabling it tends to significantly increase solution performance and stability, but at the expense of not finding some interesting trajectories. In any event, it's mostly a "use a own risk" feature.

Tomorrow I'll clean up the documentation and send up a version to OHM. Woo!

 

[Arrowstar]

Version 2.1 of the TOT is uploading to OHM now. Get it [ame="http://www.orbithangar.com/searchid.php?ID=5418"]here[/ame]!

 

[Zatnikitelman]

Not sure if this is my end or not, but even after installing the MCR, when I try to run the tool, I get the same message that it can't find version 7.14 of the MCR.

 

[Arrowstar]

Hmm, odd. Go ahead and try uninstalling and reinstalling the MCR. I checked the package I uploaded and it includes version 7.14, so I'm not sure what the problem could be. Let me know if you're still having trouble after the reinstall.

 

[Zatnikitelman]

Yep, that did it. Strange though how it didn't work from the first install. Thanks!

 

[Arrowstar]

Hi everyone!

This past week I've made some modifications to the TOT that fix a few bugs (including the Departure Analysis Tool) and add some nice features. Here's the changelog as it currently stands:

Version 2.1.1 - Minor revision. Changed the working reference frame from J2000 (Earth mean equator) to J2000 (ecliptic plane). Added constraint options on C3 energy, fly-by deltaV, and arrival speed. Changed the “pre-departure” orbit reference frame in the Departure Analysis Tool (DAT) from J200 to the local, non-inertial (landmass-fixed) IAU reference frame for the departure body. Corrected how the DAT computed hyperbolic semi-major axes. Added additional hard constraints to DAT optimization. Revised documentation. Procured new TOT logo.

I'm hoping to get this out tomorrow. Enjoy!

---------- Post added at 01:31 PM ---------- Previous post was at 12:54 AM ----------

Version 2.1.1 is now uploading at Orbit Hanger Mods! Get it here!

Standard Version: [ame="http://www.orbithangar.com/searchid.php?ID=5418"]Trajectory Optimization Tool v2.1[/ame]
No MATLAB Compiler Runtime version: [ame="http://www.orbithangar.com/searchid.php?ID=5419"]Trajectory Optimization Tool v2.1 - No MATLAB Compiler Runtime[/ame]

(Give it a few minutes from the time stamp of this post for both uploads to complete, please!)

As usual, comments, questions, and bug reports are welcome in this thread...

 

[Cairan]

Wow, what a fantastic piece of software... I think I'll finally be able to do the Earth->Venus->Earth->Jupiter->Saturn's Titan mission I love to do using less fuel...

I just love using Titan's atmosphere for killing two birds with one stone and get aerocaptured by it (and also the Saturn system). Previously I used Hohmann transfers and got captured when Titan was in conjonction between the Sun and Saturn, but lately I've been using Jupiter to slingshot to Saturn for a quicker trip, but the increased relative velocity means that I now have to intercept Titan when it is at opposition of the Sun relative to Saturn, so that Titan's heliocentric velocity is greater and reduces the difference between the ship and the moon's atmosphere.

Thanks a lot for the hardwork, I'll try this out soon!

 

[NovaSilisko]

This will be useful for sending the Neil Armstrong to Titan...when I actually get it built.

 

[Arrowstar]

Wow, what a fantastic piece of software... I think I'll finally be able to do the Earth->Venus->Earth->Jupiter->Saturn's Titan mission I love to do using less fuel...

[...]

Thanks a lot for the hardwork, I'll try this out soon!

Thanks! Keep in mind that targeting moons is not yet supported and the TOT is designed for solar system trajectories only. I would set it up so you target Saturn last, and then in your approach you can tweak how you intercept Saturn so that you hit Titan instead. You'll have to do that with IMFD or TransX, however, as TOT doesn't support that at the moment.

Nova: Thanks!