How does one execute and calculate Delta V for non optimal planetary transfers

[meyst]

The ideal option would be to wait for a window to make a transfer. I would like to learn how to execute an interplanetary transfer outside a hohmann transfer window.(What would that look like in the map viewer?) How does one calculate the Delta V to do such a burn(s)? Once I have some ideas on how to do it, I can run some transfers myself to get an idea as to how long it would take, unless you already know how to figure that out as well.

I want to learn how to do this using scrap paper and a calculator. Not mods or a do it for you tool. I also think if I learn to do this, I could use it for any body in KSP and I think that would be cool.

This challenge thread inspired me to ask. Being able to send supplies outside the optimum window could be used to greatly add to such a mission's resilience.

For example, if I was to do a transfer from Kerbin to Duna on day 10 (too early, Duna too far ahead of Kerbin. This is the first opportunity to launch anything to Duna in that challenge).

I know I can make an intercept by dropping my solar transfer orbit slightly towards Eve's orbit to 'catch up'. I can then burning prograde at the lowered Periapsis to raise my orbit to a Duna intercept. I do not know how to calculate how much Delta V it will take to execute these two burns. I also suspect with the first window only a few days away it would actually take longer to do so in that example, however if the next transfer window was over 100 days away...

I think it is should also be possible to use MOAR Thrust aproach, to burn towards Duna and force an intercept at

. Combining that with a Duna aerocapture would look very cool I bet (and require a very sturdy ship with massive Delta V capability, but how much?). Edited May 29, 2013 by meyst

[Specialist290]

It's doable, but I'm not 100% on the math itself, since it's not a question that regularly comes up.

The ideal Hohmann interplanetary transfer essentially calculates an orbit with its apoapsis and periapsis at your start and desired end points, completing a 180-degree path in that orbit. For a faster but less-efficient orbit, you're going to have a higher apoapsis (taking the case of Duna) than your planetary intercept, which means that your "executive express" transit is going to take less than 180 degrees of your orbit.

If you know where Duna is now, you can calculate where it's going to be at the end of your desired transit time through the application of Kepler's second law. You can then use Kerbin's current location, Duna's projected location, and your transit time to find the dimensions of your desired transfer orbit. From there, you'd calculate your ejection burn as you would for a Hohmann transfer.

Now, putting this in terms of workable equations is where things start to break down for me myself, since math never was my best subject. You'll have to wait for someone else to do that.

Edited May 28, 2013 by Specialist290

[tavert]

To calculate this precisely is called the Lambert problem. It's a bit much to do on paper, but you can find implementations of Lambert solvers in whatever your favorite programming language may be. The problem statement is basically: what is the Kepler orbit around a central body that starts at location x1 at time t1 and ends at location x2 at time t2. Since the planets have fixed orbits, for a transfer between a given pair of planets, x1 is a function of t1 and x2 is a function of t2. So for given starting and ending planets, plug in a departure time and a transfer duration and you'll get the trajectory you need to follow.

[meyst]

So to clarify, I would pick a time I want to arrive at (using best guess or supply limits), use this Lambert's problem equation here.

To get a Kepler orbit that will be my transfer orbit.

That I can use to calculate the required Delta V, to get into the above Kepler orbit.

If I find out I can not build in enough Delta V, I would do it over again using a new t2 transit time period.

It seems I asked a challenging question, Kepler Orbit's, Lambert's problem and semi-major axises are all new to me.

My understanding is that a Kepler Orbit would be an equation that describes the orbit I would want my ship to be on. I am unsure how I would turn that information into a heading and burn time/Delta V. Unless I am mistaken one could require multiple burns to get onto the desired Kepler orbit, especially if the target is on an inclined orbit.

So, how does one do that (I mean fly it / convert it to course headings and burn times, at location x1 at time t1)?

Assuming that one was to use the Lambert's problem and picked the exact timings for a Hohmann transfer would the Kepler orbit plot be a Hohmann transfer or would it come up with something different? I strongly think it would be the same. If that is the case, is it fair to assume that the Delta V needed would be greatest when one is exactly in the between two Hohmann transfer windows? ie If Windows for transfer are on days 0 and 500, would going on day 250 require the most Delta V (at a minimum) to make the transit, not so important to know but something that I thought about.

Edited May 29, 2013 by meyst

[tavert]

It's a pretty tricky problem, yes. To find the delta V needed to get onto a Lambert solution transfer orbit, you find the orbital velocity of the transfer orbit at t1 and translate that into the "hyperbolic excess velocity" relative to your departure planet. You start with the planet's orbital velocity around the sun, then the vector difference between that orbital velocity and the velocity of the Lambert transfer orbit at t1 gives you the speed and direction needed for your escape from the sphere of influence of your departure planet. You can translate that escape velocity into a maneuver delta-V from an initial parking orbit using the vis-viva equation. Set your parking orbit altitude as the periapsis of the escape trajectory, then the maneuver delta-V for your escape burn is the difference between orbital speed at that altitude and periapsis speed of the hyperbolic escape trajectory.

You should always be able to get into any Lambert transfer orbit with one (instantaneous) burn, but that burn may need to be quite crazy if your transfer orbit is inclined in a way that doesn't line up nicely with your initial parking orbit. Inclination is more of a pain than eccentricity.

If the initial and destination planets both have circular coplanar orbits, then the Hohmann transfer is one specific solution to Lambert's problem, but only when you plug in the correct phase-angle times for t1 and t2.

I'm not sure how the numbers work out. Halfway between Hohmann windows will definitely require more delta V than a perfectly-timed Hohmann transfer, but it might be that 40% or 60% or something else entirely is the worst point.

Edited May 29, 2013 by tavert

[tavert]

Also note that the Lambert problem solves for a "single-burn" transfer. There are several other ways of getting from x1 at t1 to x2 at t2 that involve intermediate maneuvers, like the somewhat bielliptic-ish idea you mentioned in your OP that I seem to have missed. That might be an easier place to start actually, if you work with Hohmann-like assumptions of circular coplanar orbits. You could set an initial phase angle and solve for the intermediate target altitude to do your second burn at peri/apoapsis so you arrive at your destination orbit at the correct time.

[Colonel_Panic]

Hmm, correct m if I'm wrong, but any way you slice this problem, aren't you basically going to still reach your destination planet at the same time as if you'd used a hohmann transfer directly? It seems to me the price you pay for an early departure, all delta-v aside, is a longer transit time with more adjustments en-route.

[tavert]

Nah, not necessarily. You can arrive at your destination at essentially any time you want, if you're willing to pay possibly outrageous delta-V costs to do so. Or potentially you can do a several-times-around very slow transfer, which in some cases may end up with a smaller initial cost.

[sturmstiger]

One thing to google for is "porkchop plot", which is a plot of energy contours on departure and arrival dates. In another word, it put solutions of Lambert's problems given various inputs on a graph, to allow you choose departure dates which meet your energy and transit time requirements. This is what they use in NASA to plan for interplanetary missions.

It seems somebody on the Orbiter forum wrote a porkchop plot generator (http://www.orbiter-forum.com/showthread.php?t=6889), which could probably be used to solve the problem if you input Kerbin & Duna's orbit parameters. I imagine it would be quite hard to do with paper & calculator, but should be possible since the mathematicians & physicists worked out these orbital mechanic problems long before computer.

Oh, it's awesome to see the challenge made people think about problems like that! It was hoping that people who do the challenge would consider things real space agencies would consider for manned missions to Mars.

[meyst]

Now I want porkchop's, they look very tasty to have for mission planning. Unless I am mistaken it's a lambert's problem calculated for different times and put on a graphic/map that shows the energy of the transfer orbit.

I also still have not given up my conviction of wanting to learn, understand and be able to do it myself, instead of just using a game aid. To make a porkchop plot, requires solving the Lambert's problem for Kerbin/Duna for a 1000 day period, about one million times (assuming daily plots)... I am in agreement that an upgrade to my planned calculator and scrap paper method is in order.

The good news is I have a computer and I have done programing before. The bad news is I have not done anything programing for well over 10 years... and that was BASIC... So it is a safe bet I will be learning a new computer language.

Something called Matlab seems to be a popular choice from what I can gathered from a few searches. I am however not willing to drop $100 to make a game aid. So I had a look at this list on Wikipedia and the only one that was listed as "used for astrophysics, solar physics" was Perl Data Language. It's also at the exact range of my Delta $ budget I have heard of Perl, not ever looked at any code for it though.

So unless somebody has a better idea for a computer language and why it deserves my consideration, for my far too involved planning, I will be adding 'Learn Perl" to the mission preparation itinerary.

[tavert]

Perl's a bit antiquated, it's good for writing fancy batch scripts that make some simple modification to a whole bunch of text files, that kind of thing. I haven't tried PDL but it doesn't seem like something I'd want to use Perl for.

I'd say Python would be a better choice. Simple, general-purpose, popular, lots of libraries for numerical computing and application-specific things like, say, http://sourceforge.net/projects/keptoolbox/ - I'm sure there are people on here who actually know PyKEP.

I use Matlab daily, in some communities it's the go-to standard for technical computing, but it's also on the expensive side if you don't have your employer or school paying for it. There is an open-source Matlab-style language called Octave, but Python is more general-purpose and useful to learn in my opinion.

[sturmstiger]

I totally agree with tavert on both points:

1. Python would be a better choice than perl. It's a cleaner & much more "sensible" language, and should be easier to learn.

2. If you'd like to do more numerical work (instead of general purpose programming) but don't want to buy Matlab, Octave is be a free & pretty good alternative.

[PakledHostage]

I think sturmstiger's suggestion to use Octave is a good one. I flew a similar mission to what is described in the OP back before manoeuvre nodes were added, and I used MathCAD (similar principle to Octave or Matlab) to plan my burns.

I planned my flight to Duna (a Duna flyby with free return to Kerbin) such that the spacecraft would arrive at Duna as close as possible to an ascending/descending node. That minimised the out-of-plane manoeuvring required, and turned it into a 2D problem.

Here's a video showing how the orbits looked in the map view (it was flicking back and forth between Duna and Kerbin encounters because I'd intentionally set it up to graze Duna's SOI to avoid a significant gravitational assist from Duna screwing up my return trajectory):

Edit: Here's the link to the original forum thread: Proof of concept Duna cycler trajectory.

- The second screen shot was taken while still inside Kerbin's SOI. It was just over 32 1/2 days from then until Duna intercept.

- The fourth screen shot shows my spacecraft at Duna Pe of 47500 km (just inside Duna's SOI) going 3043 m/s relative to Duna.

- The fifth screen shot shows my spacecraft returning to Kerbin after 212 days.

Edited May 30, 2013 by PakledHostage

[meyst]

This morning I put some Perl and Python onto my computer. I also wrote and ran small Hello world style programs to confirm they are working. Both seem workable to me, but I did fine it easier to find resources to get going with Python.

I have also come across something I did not expect at all. NASA has an open source software toolkit, for Java. With everything I would need and more. My understanding of Java is it can be a pain to program in but is designed to take full advantage of modules/tool kits. Something about using a program for KSP that builds on work NASA has done just seems so

That does look like an epic way to go to Duna. A cycler trajectory is something I didn't even know was possible. For the Duna sustained mission challenge, assuming I can handle the telemetry, it has the potential to be a useful addition.

Edited May 30, 2013 by meyst

[Specialist290]

Definitely keep us in the loop on how progress goes. If it ends up working well, I might end up with a new resource for the Drawing Board!

[tavert]

There was a guy working on a KSP porkchop plotter written in Java a while back, but it doesn't look like he kept up development of it: http://forum.kerbalspaceprogram.com/archive/index.php/t-16695.html

[alexmun]

I've put together a web app that generates porkchop plots for ksp: http://alexmoon.github.io/ksp

[meyst]

Alexmun, that is exactly it! With the cross reference to telemetry needed to execute and everything!

It even runs fast, any way I would be able to get my hands on the code so I can take the time to understand it and not feel like a cheat?

[alexmun]

Sure, just click on the GitHub ribbon in the upper right corner. It all runs in JavaScript in your browser so you can also look at it that way. Most of the math I got from: http://www.braeunig.us/space

[Specialist290]

Very nice! I think I'll be grabbing that for the Drawing Board.

[Mr Shifty]

I've put together a web app that generates porkchop plots for ksp: http://alexmoon.github.io/ksp

That. Is. Awesome. It would be cool to be able to toggle the contour plot to show ejection/insertion/total delta-V's. And totally easy to update when new celestial bodies arrive. This tool needs a sticky somewhere.

And let me just say that your code is very clean and elegant and easy to read. You are my new hero.

[Colonel_Panic]

I've put together a web app that generates porkchop plots for ksp: http://alexmoon.github.io/ksp

Awesome, totally concur this needs a sticky. Does it take into account orbital inclination as well? because that would just be a godsend for planning trips to moho and eelo.

[Mr Shifty]

Does it take into account orbital inclination as well?

It should; it solves for an orbital path that lies in the plane defined by your initial position vector in 3-space and the final position vector at intercept.

[alexmun]

Awesome, totally concur this needs a sticky. Does it take into account orbital inclination as well? because that would just be a godsend for planning trips to moho and eelo.

Yes, my whole motivation for making this was to calculate transfers to Moho. As Mr Shifty said, it calculates transfer orbits that hit specific points in space at specific times so it works for any eccentricity and inclination of orbits.