Project Trajectory Optimization Tool Development

[Arrowstar]

Sure, I don't see why I couldn't. That said, I'd rather the author of the software provide me with the format that the data needs to be written in, rather than reverse engineer it myself. Again, the time issue.

---------- Post added at 09:43 PM ---------- Previous post was at 08:59 PM ----------

You know what occurs to me: Piper wrote his Porkchop plotter (available on OHM) with the ability to write the TransX portion of SCN files. Anyone know if he's still around? I could probably ask him how he went about it...

 

[agentgonzo]

Piper wrote his Porkchop plotter (available on OHM) with the ability to write the TransX portion of SCN files. Anyone know if he's still around? I could probably ask him how he went about it...

Piper:
Last Activity: 22-08-11 15:33

Send him a PM.

 

[Wishbone]

I'll be using the transfer orbit keps from TOT 2.0 to program NTR core stage burns, the information available from the TOT run report is enough at the moment.

 

[Zachstar]

I had contacted Mindblast over PM. Before anything can happen tho he is on a 2 week holiday.

Heh of another issue is the lack of ability to plan DSMs. That has to be done in manuver mode manually in TransX unless I am mistaken.

If we could just combine TOT with the ability to plan of Orbiter Navigator with the burn planning ability of TransX with the Off plane ability of IMFD we would be epic win on Orbiter Navigation.

 

[Arrowstar]

I'm afraid I'm not familiar with Mindblast... what did you contact him about?

As far as deep space maneuvers are concerned: I'm not actually sure why you'd need them. The idea behind TOT is to minimize the amount of dV needed to go somewhere. Burn dV is already applied when it's most advantageous, at the periapse of a gravity assist maneuver's planet-centric hyperbolic orbit.

Also keep in mind that TOT does not directly simulate spacecraft motion. Instead, it solves Lambert's problem under the standard two-body assumption. It doesn't make as much sense to talk about something like engine burns halfway through a Lambert arc, since you're already heading where you presumably want to go anyway...

 

[Zachstar]

Multiple Interplanetary missions used DSMs in order to reduce either time or allow greater windows of opportunity. Then again simulating when those are best are likely outside the scope of your program and likely hidden in some NASA PDF somewhere.

Mindblast is the author of Orbiter Navigator. I PMed him about the possibility of using it as a means of making use of the output data from TOT. However he indicated that he is going on holiday so any use of that might have to wait unless you want to figure out how Orbiter Navigator saves its burns.

 

[Arrowstar]

Okay-dokie! Well, let me know what he says when he comes back and I'll see what I can do for you.

 

[Zachstar]

Okay-dokie! Well, let me know what he says when he comes back and I'll see what I can do for you.

I think he will post here when he gets back. In the meantime tho I do hope you can get some info on how Piper does TransX integration with his Porkchop plotter.

I have actually grown to like the burn program of TransX. Strange considering how I used to curse it while loving on IMFD. :lol:

 

[Arrowstar]

I think he will post here when he gets back. In the meantime tho I do hope you can get some info on how Piper does TransX integration with his Porkchop plotter.

Me too! If I hear anything I'll let you know...

 

[Arrowstar]

Hi everyone,

After taking a break to concentrate on my academics (I'm finishing up a Master of Science in astronautics come spring), I've started to take a look at TOT again. There are a few improvements/additions I'm in the process of adding.

First, users of TOT may remember that the Flight Plan GUI forced the user to select a transfer type (long way or short way) and number of revolutions for each leg of the journey. I'm in the process of ripping this out and getting the genetic algorithm to treat these quantities as design variables to be optimized, as well. Its not terribly hard, but it requires some changes to the GA code and the UI that the GA sits under.

Another update is an additional genetic algorithm that I've written myself. This will not replace the MATLAB-implemented GA code, it's just an alternative one can use. No promises that its better or more effective or anything, I'm just trying to present options to "canned" code with an eye towards evaluating my algorithms as a replacement.

Finally, I added a small utility that converts Gregorian calendar dates to MJD and back. I've always wanted something like that in an easy-to-use interface, so I wrote a small tool within the TOT to do just that.

I'll post screenshots of the updates in the coming days/weeks, as I find time. I'll probably get around to a 2.1 update in mid-December.

As usual, comments/questions/concerns welcome.

 

[rappolee]

location of pioneer 11 PAM upper stage

can your trajectory tool handle FORTRAN ? :facepalm:
The reason I ask is I am trying to gather some historical data on the locations of the solid upper stages for the voyager and pioneer projects.

http://nssdcftp.gsfc.nasa.gov/spacecraft_data/pioneer/pioneer10/traj/mission/voldesc1.sfdu

and

http://nssdcftp.gsfc.nasa.gov/spacecraft_data/pioneer/pioneer11/traj/mission/

I think the pioneer 11 stage is not in a solar system escape orbit but in a solar polar orbit. The pioneer 10 solid motor is headed to the stars


voyager
http://nssdcftp.gsfc.nasa.gov/spacecraft_data/voyager/voyager1/traj/ssc/vy1trj_ssc_fmt.txt

http://nssdcftp.gsfc.nasa.gov/spacecraft_data/voyager/voyager2/traj/ssc/vy2trj_ssc_fmt.txt

 

[Arrowstar]

can your trajectory tool handle FORTRAN ? :facepalm:

No, sorry.

 

[Arrowstar]

Hi everyone,

Here's a brief glimpse of what I've been up to. I completed some work early today and I thought I'd share. This is a screenshot of the upcoming Departure Analysis Tool, which will be accessible from the TOT's menu.

On the left, the user provides the helio-centric orbital elements for the helio-centric transfer orbit they're on when they depart the initial planet/body. In the center pane, the user inputs information about the orbit they are currently in about the "departure body". Lastly, the user provides the departure date in MJD.

All the information about helio-centric orbital elements and departure date is computed by the TOT directly. The "pre-departure orbit information" is something the user should know in advance. For example, if the user typically injects into a 51 degree 400 km x 400 km orbit, that information could be entered here. Basically, read off what Orbit MFD in Orbiter gives you.

When "Compute Departure Burn" is pushed, the Tool goes through an optimization routine to attempt to find the optimal true anomaly (relative to the initial orbit) at which the departure burn should be performed. It also computes the deltaV burn vector and will eventually output that into that blank text box in the lower left, along with other information.

Anyway, there's still lots to do yet, but I like the progress I made today. (I spent yesterday working through the math and today programming.) As usual, I'm open to suggestions, comments, and concerns.

 

[Cras]

This looks fantastic.

 

[Arrowstar]

Here's another screenshot with more stuff added.

The DAT now gives burn vectors in both the J2000 frames and the local VNC frame. VNC is a coordinate system in which the first component is the velocity unit vector, the second is the orbit angular moment unit vector, and the third is such that the system is right-handed. It's great for figuring out burns because the system's reference is something you know quite well (in Orbiter, anyway): your velocity vector.

Other data displayed is the total burn Delta-V, the elements of the departure body-relative hyperbolic orbit, and the "constraint error," which is a number that describes how close the optimizer was able to match the desired outbound hyperbolic velocity vector with the computed vector. This number should always be quite small (1E-10 or smaller).

The only thing I have to do is write the code to populate the Departure Body drop-down menu, I think. If anyone has any suggestions that would improve the usability of the DAT, either from a data output perspective or from a visuals perspective, I'd be willing to hear it.

 

[Cras]

The only suggestion I can have is for the data to be displayed in such way that is easily transcribed into either IMFD or TransX.

That way the "flight plan" can be loaded in and the choosen program can be used for any correction burns required enroute to ensure the craft is still on the proper course.

 

[Arrowstar]

I can try and do that, but I'm not really too familiar with how either of those programs accepts information. (It's easily been over a year since I've done anything interplanetary with Orbiter, school has gotten in the way.) Can you be more specific about the kind of information I should provide and how it should be provided?

 

[Mandella]

This looks to be a great version of the Trajectory Optimization Tool, but is it also going to be limited to working out plots within the near future and recent past?

I think the tables the old version worked off of only covered less than one hundred years into the future, to my recollection...

 

[Arrowstar]

The TOT works off fairly high fidelity ephemerides provided publicly by NASA JPL. The date limitations on those are the date limitations on TOT, and there's not much I can do about that. There are ways to build your own ephemeris files and if you need dates beyond what I've made available, you are more than welcome to investigate those techniques. For starters, I would check out JPL's Navigation and Ancillary Information Facility website:

http://naif.jpl.nasa.gov/naif/

 

[Cras]

Looking at IMFD, it actually does not seem any information is required. The only inputs are the type of transfer (which plane to use), time of ejection, and time of intercept, which of course is already offered by TOT. As far as TransX, I cannot say yet, I need to refresh my memory on the matter.