Project Trajectory Optimization Tool Development

[Arrowstar]

So a couple updates:

This week is Midterms, Round 1, hence the lack of updates. But I have some plans I'd like to get feedback from the community on.

1) The 750 px version should be around at some point. I just need to think about how I want to rearrange it. Or perhaps I'll just shrink things a bit, we'll see. The inability to resize the window is intentional, however: it doesn't look good when you change it.

2) The optimization routine really didn't work well. It was far too sensitive to initial conditions to give good results, even when I used the heavily optimized functions built into MATLAB. So this part is basically out, for now, though I'd be happy to share the code with anyone who wants it.

3) I'm looking at building a Maneuver Planner add-on for the Trajectory addon. The idea would be to use initial orbit information around some body and maneuver information (such as deltaV vector/magnitude, location of burn, etc) to allow people to use the Trajectory Optimizer side of things to get a good idea of what the trajectory should be, and then allow them to see what will happen when they actually implement that trajectory. I'll have to numerically integrate the equations of motion, but I think it could be interesting. The basic premise would be similar to NASA Goddard's GMAT or STK/Astrogator, though obviously not as feature-rich (grad student, remember? ).

Comments, questions? Would that last bit be useful?

 

[Wishbone]

Returning to interplanetary flight planning (without planning, I only managed to get to Neptune in a stock DG with humongous inefficiency, have never been to Neptune before other than on guided tours, they say hotel prices are hyperbolic)... Thinking about speeding up computations by setting date grid granularity _separately_ for each stage. Would that be possible?

Re: #3. If you come to this step, would be nice to compute sensitivities to 1 m/s changes in dV components, and to 1 second's difference in burn start time in terms of final miss vector (assume this will be the ideal way of aiming for the optimal spot during swing-by).

 

[Arrowstar]

Returning to interplanetary flight planning (without planning, I only managed to get to Neptune in a stock DG with humongous inefficiency, have never been to Neptune before other than on guided tours, they say hotel prices are hyperbolic)... Thinking about speeding up computations by setting date grid granularity _separately_ for each stage. Would that be possible?

Re: #3. If you come to this step, would be nice to compute sensitivities to 1 m/s changes in dV components, and to 1 second's difference in burn start time in terms of final miss vector (assume this will be the ideal way of aiming for the optimal spot during swing-by).

Regarding the first question: I could probably do something like that. Let me save that for v1.1.3 (meaning the version after the 'too big for some monitors fix' version, aka 1.1.2). Thanks for the tip! :tiphat:

Can you explain what you meant in your second paragraph? I didn't quite follow.... Thanks!

And finally, I will leave everyone with a teaser of what I've been working on lately:

 

[Wishbone]

The idea is to give users some notion on how costly a deviation from the plan may be in terms of miss distance or anything else, which requires computing derivatives of the objective function w.r.t. maneuver params.

 

[Arrowstar]

The idea is to give users some notion on how costly a deviation from the plan may be in terms of miss distance or anything else, which requires computing derivatives of the objective function w.r.t. maneuver params.

I suppose I could look into that, though even at this point I'm still not entirely sure I'd accomplish precisely what you're asking for. Given the number of parameters possible, I'm not sure how efficient it would be to start looking at computing derivatives for each of them. You don't by any chance have a paper that discusses this, do you?

 

[Wishbone]

Will rummage through the 'bytes and send you the code or the linky or the PDF...

 

[Arrowstar]

Sounds good, thanks!

 

[Wishbone]

Work and misc. things clouded my mind. The code is in the [ame="http://www.orbithangar.com/searchid.php?ID=4889"]Precession MFD[/ame] source folder, in PrecessionMFD.cpp - it is the subroutine ComputeRMinWithDerivatives_VelFrame. What it does is calculating the derivatives of the final miss distance in the Intercept mode w.r.t. instantaneous velocity changes.

I use it for seat-of-the-pants timing of RCS maneuvers to minimize the miss and, hopefully, to be on the right side of the target. Basically, I do corrections along the axes in my own velocity frame when the corresponding derivative is the biggest. This is suboptimal, of course, and for large maneuvers it is necessary to use IMFD.

 

[Arrowstar]

Got it, thanks.

 

[Arrowstar]

The TOT has been updated to v1.1.2, which is a fix for the tall height of the GUI. Other features mentioned in here will be looked into as time allows.

 

[ivan_w]

Arrowstar,

(not a criticism - just to make sure I have everything right - or possibly where I got it wrong)

I've been playing a bit with your Trajectory Optimization Tool and found myself a little confused by it..

Let me explain :

I'm trying to reproduce the cassini mission.. I didn't run into major problems running it manually (well - with the help of IMFD - and usually manage to hit saturn within 2 days of the historical date) - but when I try to set a flight plan that closely mimics what actually occurred, the planner seems to start giving me either bogus results (like 100 km/s + of dV on swings) or completely failing (the dreadfull 'ding' when something doesn't go right - with no explanation given).

You may have moved to another project (I see you are anyway) - in which case I guess I'll just wait for you new tool to mess around with trajectory optimization and planning - but just wanted to let you know of the problems I am running into.

If you are done with this particular project - that's fine... However, if you are still maintaining this project (and assuming it's not me trying to do things backwards) I'll be glad to provide any extra information.

Thanks !

--Ivan

 

[Arrowstar]

Hi Ivan!

Could you PM a copy of a flight plan that doesn't seem to work? Just the text would be fine, I can enter it in manually. Keep in mind that the TOT is using a two-body approximation and the Saturnian system tends to be full of dynamical non-linearities, so this may be part of the reason why the program fails to give 100% historically accurate results. Once I see what you're trying to do, I can tell you more.

Thanks for your interest!

 

[Zachstar]

I would like to see more development of this project as well.

 

[Arrowstar]

As always, suggestions for improvements of any sort are welcome. Their implementation, of course, is hinged on how much spare time my graduate work leaves me.

 

[ivan_w]

Arrowstar,

Just a thought...

I think I have an idea why your tool can't find a solution to the Cassini mission : The problem might be the Deep Space Maneuver that occurred midway between the 2 Venus flybys.

Basically the 2nd flyby doesn't occur at the same spot as the 1st encounter - so in essence, it is a 2:1 resonance less a little bit - and this can only be achieved (with the best fuel efficiency) by reducing the Periapsis at Apoapsis. On Cassini, this occured on December 3rd 1998.

The sequence of events for the cassini mission were as follows (cf wikipedia) :

Launch : 1997-10-15
Venus 1 : 1998-04-26
DSM : 1998-12-03
Venus 2 : 1999-06-26 (Note : That's 424 days - ~25 days short of 2 Venus orbits)
Earth : 1999-08-18
Jupiter : 2000-12-30
Saturn : 2004-07-01

So I think unless your tool can incorporate Deep Space Maneuvers, it might not be able to find the best solution for a trajectory involving multiple flybys of a single body - if a subsequent encounter is suppose to occur somewhere else than the previous flyby.

Just guessing here though !

--Ivan

 

[Arrowstar]

Thanks for the help, Ivan. I'll take a look at this when I get the chance, though it may be a few days. Is this the sequence that gives you the 'dings of doom'?

I doubt I'll be able to do deep space maneuvers, since the idea behind this tool is a two-body solution to Lambert's problem and maneuvers don't really come into that. Doesn't mean it couldn't be done, but I'll have to think about it.

For the record: I do plan on continuing to develop this tool so long as the interest exists for me to do so. However, at the moment, I'm a little swamped with work here at school. Whenever I get the chance, though, I'll be using this thread as a repository of ideas that have been requested.

 

[sraque]

Arrowstar,

First, thanks again for the assistance and updates last semester. The asteroid projects turned out very well, and without your tool, the mission planning wouldn't have gotten very far at all. One of the teams did about 30 runs varying the order they visited the different asteroids to find minimum total dV they needed for the mission. Final mission profiles were simulated in STK. Most of the time the arrival departure dates matched very well, within what I consider understandable variation between the 2-body and hi-fidelity sim. A couple times they were far off, but I didn't get the time to sit down with them and rigorously determine what was the root cause. Also, departure C3 from Earth matched very well.

I am already looking ahead to next spring semester when I teach design again, and I'm planning projects. Consistently, students tell me that the interplanetary missions are the most interesting ones, so porkchop plots are probably going to be needed. With that in mind, I had a question and then some suggested tool enhancements that I believe would help the mission design process.

First, the question. Is the arrival velocity (as plotted) calculated by taking the vector difference of the arrival body and the spacecraft in the sun-center inertial frame (i.e. V-infinity in the arrival body frame) or is it the velocity magnitude of the spacecraft when it reaches the location of the arrival body in the sun-centered inertial frame?

The user not knowing what the transfer orbit looks like made the transition from porkchop plot to hi-fidelity sim tough. For example, launching from Earth, you really need to know the inclination of the transfer orbit so that you can launch at the right time to get the maximum benefit from the Earth's rotation. Arrival inclination also has an affect on possible orbits around the target body, but is even more important if you are performing a rendezvous instead of an orbit of the target body (with a small asteroid or another spacecraft). So, some way to get the orbital elements of selected transfer orbits would be useful.

With the departure plots and arrival plots as-is, you can do visual analysis to find optimums, but combined plots or some way to output the raw data would be useful.

I believe this gets back to one of your earlier posts from this year: "what do I optimize". I think from a 2-body perspective it is the total dV that gets optimized. However, there are two missing pieces to that puzzle (in the current tool) both of which are essentially the two enhancements above. 1) How much dV needs to come from the launch vehicle vs. what I get from Earth rotation? 2) How much dV do I need on the arrival end?

-Steve

 

[Arrowstar]

Hi Steve,

I've had a chance to consider your questions. Let me hit them in the order you asked them.

1) Arrival velocity is computed as the magnitude of the difference in the velocity vectors between the spacecraft and the arrival body.

2) I already have the elements for each arrival/departure pair computed, I do believe, though they don't get exposed to the user. Would it be handy if I provided a way to click on the porkchop plot and have the elements of the transfer closest to the point clicked get output to the text output box?

3) Thanks for the suggestion there, that really does help.

Let me know if I can provide anything else! If you get back to me on 2, I can look into it...

 

[sraque]

Arrowstar, thanks for the answers and support. On #2, that would be a user-friendly way to do it. I hadn't specifically asked for that level of user interaction since I thought it might be a big pain in the UI. I'm guessing here, but it seems to me that most of the time, outputs for the minimum points on the plot would do well (especially if they are plots of combined departure/arrival), which would simplify the UI development, or be an incremental step towards what you ultimately want.

-Steve

 

[Arrowstar]

Steve: Nah, it really shouldn't be that bad. Those are the programming challenges I find interesting! Can you explain further what you mean by "output for the minimum points on the plots"? You mean provide orbital elements for both the type 1 and 2 minimums?

In other news, I had some inspiration on Thursday and decided I really know where the big flaw in the TOT is. The current goal for TOT as I've written it is to provide an optimum (or near optimum) trajectory based on user parameters. However, what is actually does is just put out porkchop plots for each stage of the flight. There's nothing inherently wrong with this: at one point, that was the only goal of the application. (Indeed, all the MATLAB files still reside in a folder called "Porkchop Plot Generator.") However, it's really not doing what it was advertized to do.

To that end, I pretty much need to rewrite the whole thing in order to provide a simple method of optimizing trajectory. What I couldn't do with version 1 of TOT is provide a deltaV function to the MATLAB function minimizer. Knowing in advance that this is what I want to do, I should be able to produce the requisite function easily. TOT v1 just wasn't written to do that sort of thing.

I won't be starting from scratch. I have the function library I built for version still, and almost all of that code is relevant here. It's mostly just a shift in paradigm, not the math.

I'll try to post updates here as I make progress.

---------- Post added 07-31-11 at 12:52 PM ---------- Previous post was 07-30-11 at 02:31 PM ----------

Right now I'm experimenting with a genetic algorithm to perform the trajectory optimization. The functions to calculate C3 energy needed from the launch vehicle and deltaV needed for powered flybys are written, and the function to calculate arrival deltaV to stop at the body is next.

My test case right now is the Voyager 2 Jupiter flyby, and the results are fairly promising as far as I can tell. I've had to mess with the sub-algorithms used within the MATLAB GA function, but I've got it to where I'm regularly hitting effectively 0 deltaV solutions 8 out of 10 times. GA is a stochastic algorithm and it's going to return slightly different solutions each time. This is fine, so long as the solutions are fairly close enough to each other. I'm planning on exposing some of the more basic algorithm options to the user so they can manipulate as they desire, but of course I'm trying to provide a decent set of defaults.

Next up on the list is to redo the GUI from scratch, taking into account what I've learned from version 1 and my GUI projects I'm completed since starting this previously. After that, I need to write the relevant callback functions to make the Tool come alive, write the code to generate porkchop plots, and write the code to create a map of the trajectory so people can visualize what's going on.

Here's some example output from my test script. I ran 10 trials, they are so labeled. The three long numbers a few lines down into each trial are the Earth departure date, Jupiter flyby date, and Saturn arrival date, respectively, in Julian Date. Elapsed time is the processing time in seconds (not CPU-seconds) required to generate the result.

1:  ---------------------
Optimization terminated: maximum number of generations exceeded.
DeltaV is 1.9408e-005
          2443515.95885315          2443853.03166839          2453941.58018276

Elapsed time is 25.913932 seconds.
2:  ---------------------
Optimization terminated: maximum number of generations exceeded.
DeltaV is 4.4105e-005
          2443515.95082796          2443853.02607047          2453941.77927664

Elapsed time is 25.508045 seconds.
3:  ---------------------
Optimization terminated: maximum number of generations exceeded.
DeltaV is 1.494e-005
          2443515.95796018          2443853.03141523          2453941.60673764

Elapsed time is 24.758804 seconds.
4:  ---------------------
Optimization terminated: average change in the fitness value less than options.TolFun.
DeltaV is 0.19745
          2443675.49995765          2444144.84000759           2452315.2736878

Elapsed time is 20.546130 seconds.
5:  ---------------------
Optimization terminated: maximum number of generations exceeded.
DeltaV is 7.6528e-006
          2443336.06434977          2443823.37390295          2451683.51491418

Elapsed time is 26.324571 seconds.
6:  ---------------------
Optimization terminated: maximum number of generations exceeded.
DeltaV is 1.2393e-005
          2443336.06449116          2443823.37411664          2451683.51823564

Elapsed time is 25.502319 seconds.
7:  ---------------------
Optimization terminated: maximum number of generations exceeded.
DeltaV is 0.19745
          2443675.49998729          2444144.82760091          2452315.36593189

Elapsed time is 26.056920 seconds.
8:  ---------------------
Optimization terminated: maximum number of generations exceeded.
DeltaV is 4.8143e-007
            2443336.064506          2443823.37417522          2451683.51541067

Elapsed time is 25.586863 seconds.
9:  ---------------------
Optimization terminated: maximum number of generations exceeded.
DeltaV is 0.00023231
          2443516.00502642          2443853.06638158          2453940.46983232

Elapsed time is 25.826775 seconds.
10:  ---------------------
Optimization terminated: maximum number of generations exceeded.
DeltaV is 1.5697e-006
          2443336.06447782          2443823.37413454          2451683.51555075

Elapsed time is 25.320806 seconds.

Comments, questions?

---------- Post added at 11:57 PM ---------- Previous post was at 12:52 PM ----------

And just a quick update before I go to bed. The cost function that combines the C3 energy, the total flyby deltaV, and the arrival deltaV has been written and tested. This next version of TOT will allow people to set requirements for when an encounter with a body must happen (that is, set the Julian Date, if you desire) as well as weight those three quantities I listed above with relative importance factors so you can optimize towards what you need.

Really, all I have to do is write the GUI now. The actual optimization code is up and running in a few test sets.