Author Topic: Tool: Generate C3 porkchop plots for interplanetary travel  (Read 40491 times)

Offline Twark_Main

  • Senior Member
  • *****
  • Posts: 4043
  • Technically we ALL live in space
  • Liked: 2154
  • Likes Given: 1304
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #60 on: 06/01/2024 07:04 pm »
[snip]

(My own interest is in trajectories with departure burns, arrival burns, and mid-course plane-change burns. Porkchop style tools don't seem to support that.)

Donny from The Big Lebowski: What do you need that for, dude?

Is there a scenario where it uses less fuel to do a plane change separately instead of combining it with the departure & arrival burns? Of course we all know about the bi-elliptic transfer, but is there a less extreme case you're thinking of?

Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2699
  • Seattle
  • Liked: 2090
  • Likes Given: 3406
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #61 on: 06/01/2024 10:51 pm »
[...] I want a... mission planning tool [...]
Still there are some open source alternatives. GMAT for example is available under the Apache License. https://opensource.gsfc.nasa.gov/projects/GMAT/

from README.txt

Quote
NSI standard C++ using an Object Oriented
methodology,

Oh dear, mallocs in the middle of computation loops.  Might as well just use a scripting language if one didn't care about performance.

2 decades of C++.  Still hate it.   One of the languages where O(nlogn) can be easily turned into O(N^2) mallocs if you are not insanely careful.   which most aren't.

Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2699
  • Seattle
  • Liked: 2090
  • Likes Given: 3406
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #62 on: 06/01/2024 11:01 pm »
And Porkchops are terrible at hyperbolic trajectories.  I've never seen one do one correctly.

Which ones?

all the ones in this thread.  The JPL will intentionally not let you input high enough deltaVs to go hyperbolic.  Which is probably a way of covering up a bug.


Quote
It's odd that this bug would exist, since the underlying Lambert solver algorithms I've seen are perfectly capable of handling hyperbolic trajectories.

I think you said they have accuracy problems.  There's also a bunch of corner cases I can see in the code for it.  Which means probably not tested very well, esp. since stuff like the JPL Pork Chop plotter won't let you test it in the first place.


Quote
They also don't spit out the vector for the deltaV.  I can't even tell if they've optimized tangential and radial components.

Do you want the vector for the delta-v (ie the heliocentric spacecraft velocity vector minus the heliocentric Earth velocity vector), or do you just want the heliocentric spacecraft velocity vector?

It would be pretty trivial to make the Easy Porkchop algorithm spit out either one. Obviously it has to find them to solve the problem.

Yes.  I want the standard patched conics solutions.


Quote
Yes, but making the graph is the problem.  At this point I'm far enough along I'll just make my own graphs.

I look forward to years and years of correcting people after they got fooled by recycled copies of your "idealized" (ie wrong) graphs.  ;D

It'll be fun.  I've been having to point out problems with hyperbolic orbits on Porkchop plotters... soooo....

Quote
I'm currently working on making Easy Porkchop less hilariously wrong for high delta-v trajectories. When I have something that won't be absurdly wrong, I might work on graphs.

Definitely looking forward to that.

Quote
Multi-variate optimization might be a bit of a hassle but it's doable, it's what neural net learning does all day long.

Very funny!

Seriously that is what neural net learning is fundamentally. 

https://www.ibm.com/topics/gradient-descent

Which makes me think I should also tried to train a neural net to make trajectories and pork chop plots.

Offline Twark_Main

  • Senior Member
  • *****
  • Posts: 4043
  • Technically we ALL live in space
  • Liked: 2154
  • Likes Given: 1304
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #63 on: 06/01/2024 11:37 pm »
[...] I want a... mission planning tool [...]
Still there are some open source alternatives. GMAT for example is available under the Apache License. https://opensource.gsfc.nasa.gov/projects/GMAT/

from README.txt

Quote
NSI standard C++ using an Object Oriented
methodology,

Oh dear, mallocs in the middle of computation loops.  Might as well just use a scripting language if one didn't care about performance.

2 decades of C++.  Still hate it.   One of the languages where O(nlogn) can be easily turned into O(N^2) mallocs if you are not insanely careful.   which most aren't.

GMAT is...  how to put this...  not middle-of-the-bell-curve code.   :D

I would actually try it and benchmark it, instead of trying to guesstimate performance based solely on the language.


« Last Edit: 06/01/2024 11:47 pm by Twark_Main »

Offline Twark_Main

  • Senior Member
  • *****
  • Posts: 4043
  • Technically we ALL live in space
  • Liked: 2154
  • Likes Given: 1304
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #64 on: 06/02/2024 02:32 am »
And Porkchops are terrible at hyperbolic trajectories.  I've never seen one do one correctly.

Which ones?

all the ones in this thread.  The JPL will intentionally not let you input high enough deltaVs to go hyperbolic.  Which is probably a way of covering up a bug.

"Probably"  ::)

Isn't the JPL "plotter" just an interface to spit out pre-computed solutions?

It wouldn't be surprising if the solutions JPL pre-computed are only in the modest delta-v range. Generally most real-world missions are trying to minimize delta-v, without this emphasis on extremely short travel time.

It's odd that this bug would exist, since the underlying Lambert solver algorithms I've seen are perfectly capable of handling hyperbolic trajectories.

I think you said they have accuracy problems.

The algorithm works fine though. As I said, it just needs more refinement iterations.


  There's also a bunch of corner cases I can see in the code for it.  Which means probably not tested very well, esp. since stuff like the JPL Pork Chop plotter won't let you test it in the first place.

"Probably"  ::)

I guess I was right to have my doubts. No evidence of a show-stopper with hyperbolic orbits and Porkchop Plotters (innuendo isn't evidence).

They also don't spit out the vector for the deltaV.  I can't even tell if they've optimized tangential and radial components.

Do you want the vector for the delta-v (ie the heliocentric spacecraft velocity vector minus the heliocentric Earth velocity vector), or do you just want the heliocentric spacecraft velocity vector?

It would be pretty trivial to make the Easy Porkchop algorithm spit out either one. Obviously it has to find them to solve the problem.

Yes.  I want the standard patched conics solutions.

Again Easy Porkchop is just a Lambert solver, so it doesn't do patched conics. It does one single conic, calculating the heliocentric orbit from A to B (but ignoring the gravity of A and B).

You can, naturally enough, take the output V-infinity and do the math to get a rough estimate of the Oberth effect. That's what I do. But it's not "real" patched conics.

In Easy Porkchop the final solution is v2x, v2y, and v2z from line 1063 in LambertSDG.js. You can directly inspect these, or stuff these into the return array and store them for later. While you're there, on line 1074 is R_2, which is the targeting error in kilometers. This might be useful for getting a handle on the magnitude of the error for various solutions, eg hyperbolic trajectories.

The in-plane motion of the departure planet is given by v0_pi_x, v0_pi_y, and v0_pi_z, so the angle between those two vectors is your departure angle.

[skip a bit, Brother...]

Multi-variate optimization might be a bit of a hassle but it's doable, it's what neural net learning does all day long.

Very funny!

Seriously that is what neural net learning is fundamentally.

I'm aware.  ;)
« Last Edit: 06/02/2024 04:02 am by Twark_Main »

Offline sdsds

  • Senior Member
  • *****
  • Posts: 7547
  • “With peace and hope for all mankind.”
  • Seattle
  • Liked: 2349
  • Likes Given: 2175
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #65 on: 06/02/2024 03:52 am »
Is there a scenario where it uses less fuel to do a plane change separately instead of combining it with the departure & arrival burns? Of course we all know about the bi-elliptic transfer, but is there a less extreme case you're thinking of?

Selecting two posts from a very old thread.

Heh. I can understand tense SLS threads, but not tense orbital mechanics threads! :D

Quote
You're familiar with the Lambert space triangle?

Yes. You mentioned "Orbital Mechanics" by Prussing and Conway a few pages ago. I am one of Professor Conway's graduate students. I've been reading this message board for years but I never found anything that I felt I could contribute to. I'm happy to see an orbital mechanics thread!

You are right that it is (usually) better to have a mid course maneuver. I say usually because sometimes it turns out from an operational perspective that it's cheaper in dollars to spend the extra fuel than it is to bring in the staff for an additional burn.

The way I would do this numerically:

First, choose the launch date. That gives you the position and velocity of the Earth on the date of launch. Second, choose a total flight time T_{flight}. That gives you the position and velocity of Mars.

Second, choose a magnitude and direction (two angles) of the launch v_{infty}. You do it this way because you can bound the magnitude without having to impose an explicit constraint. That's an additional three variables. Add this vector to Earth's velocity to get the initial velocity of the spacecraft.

Third, choose a "burn index" eta. This is scaling factor that varies in [0,1]. For practical purposes let's let it vary in [0.1,0.9]. Propagate the spacecraft forward in time from the date of launch to time t=eta*T_{flight}. For this you could use the "Universal Kepler Solver" on page 36 of Prussing and Conway. It's not great as it doesn't handle orbits with eccentricity 1, so if you're interested there is a better one in Battin's "Mathematics and Methods of Astrodynamics." You have now arrived at the point where the mid course burn will occur.

Fourth, solve Lambert's problem to go from the burn point to the location of Mars in time (1-eta)*T_{flight}. Then calculate your braking burn (rendezvous, orbit insertion, aerobraking, whatever) just as you did before.

This becomes a six variable problem. You control the launch window by putting bounds on the decision variables, most importantly T_{launch} and T_{flight}. I would use differential evolution or particle swarm to solve this. You could try using Excel's solver too. I think it could handle this problem because it should be unimodal (only one local minimum). I have not verified that though.

The solver will find that the burn index should appear at the node point, assuming you've allowed a long enough T_{flight}. But if you insist on a very short transfer, it will place the burn earlier, and if you insist on a long transfer, it might go out to a high aphelion and do the burn there, or figure out for itself that it needs to do a multi-rev orbit. Very flexible.

All that said, I like what you are doing. You're an artist by trade, right? One of the difficult things about the way engineers do orbital mechanics is that it's very difficult to explain to the general public. But your work, from what I see from your website, is a lot easier to present as a teaching tool. Every year we have an engineering open house and I think about having a booth, but I can't figure out how to explain what I do to kids and so I never do it.

I will confess that I haven't checked your math yet. Can you add true anomaly to your chart? Or better yet x,y,z coordinates of the spacecraft and the planets so that we can check the endpoints.

Also, do you have access to AIAA journals? If not I could go hunting for you and see if anyone has tried to do this before.
— 𝐬𝐝𝐒𝐝𝐬 —

Offline Twark_Main

  • Senior Member
  • *****
  • Posts: 4043
  • Technically we ALL live in space
  • Liked: 2154
  • Likes Given: 1304
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #66 on: 06/02/2024 04:20 am »
Is there a scenario where it uses less fuel to do a plane change separately instead of combining it with the departure & arrival burns? Of course we all know about the bi-elliptic transfer, but is there a less extreme case you're thinking of?

Selecting two posts from a very old thread.

Heh. I can understand tense SLS threads, but not tense orbital mechanics threads! :D

Quote
You're familiar with the Lambert space triangle?

Yes. You mentioned "Orbital Mechanics" by Prussing and Conway a few pages ago. I am one of Professor Conway's graduate students. I've been reading this message board for years but I never found anything that I felt I could contribute to. I'm happy to see an orbital mechanics thread!

You are right that it is (usually) better to have a mid course maneuver. I say usually because sometimes it turns out from an operational perspective that it's cheaper in dollars to spend the extra fuel than it is to bring in the staff for an additional burn.

The way I would do this numerically:

First, choose the launch date. That gives you the position and velocity of the Earth on the date of launch. Second, choose a total flight time T_{flight}. That gives you the position and velocity of Mars.

Second, choose a magnitude and direction (two angles) of the launch v_{infty}. You do it this way because you can bound the magnitude without having to impose an explicit constraint. That's an additional three variables. Add this vector to Earth's velocity to get the initial velocity of the spacecraft.

Third, choose a "burn index" eta. This is scaling factor that varies in [0,1]. For practical purposes let's let it vary in [0.1,0.9]. Propagate the spacecraft forward in time from the date of launch to time t=eta*T_{flight}. For this you could use the "Universal Kepler Solver" on page 36 of Prussing and Conway. It's not great as it doesn't handle orbits with eccentricity 1, so if you're interested there is a better one in Battin's "Mathematics and Methods of Astrodynamics." You have now arrived at the point where the mid course burn will occur.

Fourth, solve Lambert's problem to go from the burn point to the location of Mars in time (1-eta)*T_{flight}. Then calculate your braking burn (rendezvous, orbit insertion, aerobraking, whatever) just as you did before.

This becomes a six variable problem. You control the launch window by putting bounds on the decision variables, most importantly T_{launch} and T_{flight}. I would use differential evolution or particle swarm to solve this. You could try using Excel's solver too. I think it could handle this problem because it should be unimodal (only one local minimum). I have not verified that though.

The solver will find that the burn index should appear at the node point, assuming you've allowed a long enough T_{flight}. But if you insist on a very short transfer, it will place the burn earlier, and if you insist on a long transfer, it might go out to a high aphelion and do the burn there, or figure out for itself that it needs to do a multi-rev orbit. Very flexible.

All that said, I like what you are doing. You're an artist by trade, right? One of the difficult things about the way engineers do orbital mechanics is that it's very difficult to explain to the general public. But your work, from what I see from your website, is a lot easier to present as a teaching tool. Every year we have an engineering open house and I think about having a booth, but I can't figure out how to explain what I do to kids and so I never do it.

I will confess that I haven't checked your math yet. Can you add true anomaly to your chart? Or better yet x,y,z coordinates of the spacecraft and the planets so that we can check the endpoints.

Also, do you have access to AIAA journals? If not I could go hunting for you and see if anyone has tried to do this before.

Sure. The solving method is simple, even simplistic.

A better method would assign the six optimization variables as (departure date, maneuver date, arrival date, maneuver location X/Y/Z) and then just solve two Lambert problems. This decomposition avoids artificially constraining the first leg of the journey coplanar with the ecliptic (or... something? they don't say really, they just use two variables instead of the expected three), which strikes me as a strange limitation to quietly and subtly impose without any justification.  Probably just an error.


However I'm still baffled at how intentionally putting a big plane change maneuver mid-course could possibly save fuel (again, excluding bi-elliptic transfers which he mentions) instead of simply performing 100% of your plane change during the departure burn, where it benefits significantly from Oberth and benefits from the Pythagorean theorem when adding orthogonal heliocentric burn vectors (i.e.  sqrt(x2 + y2 + z2)  <  sqrt(x2 + y2) + z ,  where z is the out-of-plane component ).

Mathematically speaking, it doesn't look like "success is one of the possible outcomes" here.

What am I missing? Can we find (or contrive, I'm not picky!) even a single example where three burns beats two, without having it be a bi-elliptic transfer with all its limitations?
« Last Edit: 06/02/2024 05:20 am by Twark_Main »

Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2699
  • Seattle
  • Liked: 2090
  • Likes Given: 3406
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #67 on: 06/02/2024 05:09 am »

I guess I was right to have my doubts. No evidence of a show-stopper with hyperbolic orbits and Porkchop Plotters (innuendo isn't evidence).


30 years of software engineering experience where I (for example) found memory allocation bugs in a company purchase due diligence trip inside 1/2 hour in a new (to me) code base while jet lagged on the other side of the planet.

It's all patterns based on experience.  You see patterns of code and you know what the highest probability bugs are.  Not guaranteed, but worth placing bets on.

Here's some patterns in the existing code.

1. there's no unit tests, and it's javascript which requires unit tests to be a usable language (some call that a benefit*).
2. There are a couple of "if this is hyperbolic do X" spots in the code that likely haven't been tested
3. There are few people interested in hyperbolic orbits (as you point out in the part of your reply I didn't quote).
4. Really long functions.  I'm too lazy to run a McCabe complexity tool on it, but it'll be a pretty high score.
5. The hyperbolic orbits don't appear to be graphing correctly.  Which means they weren't tested or someone would have fixed that.

That's a red flag pattern to a software engineer.  It's where I'd go looking for bugs.

Now, maybe it just works.  But it's a lower probability than 1.0.

In software engineering, like science, you assume the code (hypothesis) is wrong and go try to break things.  That's not innuendo, it's software engineering.  If a developer claims their code is correct without proof that they tried to break it they'd get laughed at and their boss would look at them with a gimlet eye, much as a scientist would amongst his peers about a hypothesis he proposed.  It's the same epistemological problem.


* The benefit of Javascript is your code is likely wrong, there's not much of a compiler rule set so you wont' find it till runtime, so you'd better unit tests.  So more likely to have unit tests.  Which is a net benefit.

Offline Twark_Main

  • Senior Member
  • *****
  • Posts: 4043
  • Technically we ALL live in space
  • Liked: 2154
  • Likes Given: 1304
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #68 on: 06/02/2024 05:39 am »
[snip]

Yes, we know. "Code smell."

2. There are a couple of "if this is hyperbolic do X" spots in the code that likely haven't been tested

"Likely" ::)

Sprinkling in unsupported, question-begging probability words to prop up your argument has a bad "rhetoric smell"  FYI.

5. The hyperbolic orbits don't appear to be graphing correctly.  Which means they weren't tested or someone would have fixed that.


Now we're getting somewhere!!

What are the reproduction steps? Can we get a screenshot of the incorrect graph or graphs?
« Last Edit: 06/02/2024 05:52 am by Twark_Main »

Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2699
  • Seattle
  • Liked: 2090
  • Likes Given: 3406
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #69 on: 06/02/2024 06:04 am »
[snip]

Yes, we know. "Code smell."

2. There are a couple of "if this is hyperbolic do X" spots in the code that likely haven't been tested

"Likely" ::)

Sprinkling in unsupported, question-begging probability words to prop up your argument has a bad "rhetoric smell"  FYI.

5. The hyperbolic orbits don't appear to be graphing correctly.  Which means they weren't tested or someone would have fixed that.


Now we're getting somewhere!!

What are the reproduction steps? Can we get a screenshot of the incorrect graph or graphs?

It's reactions like these that argue for implementing McCabe complexity metrics in a development process so that a computer will tell someone their code is likely full of bugs instead of an experienced human "smelling" it.

My dog is amused by the smelling analogy, BTW.   He says smelling works just fine for finding food.  One of which is bugs, coincidentally.

Is this your code?

Offline Twark_Main

  • Senior Member
  • *****
  • Posts: 4043
  • Technically we ALL live in space
  • Liked: 2154
  • Likes Given: 1304
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #70 on: 06/02/2024 05:54 pm »
[snip]

Yes, we know. "Code smell."

2. There are a couple of "if this is hyperbolic do X" spots in the code that likely haven't been tested

"Likely" ::)

Sprinkling in unsupported, question-begging probability words to prop up your argument has a bad "rhetoric smell"  FYI.

5. The hyperbolic orbits don't appear to be graphing correctly.  Which means they weren't tested or someone would have fixed that.


Now we're getting somewhere!!

What are the reproduction steps? Can we get a screenshot of the incorrect graph or graphs?

It's reactions like these that argue for implementing McCabe complexity metrics in a development process so that a computer will tell someone their code is likely full of bugs instead of an experienced human "smelling" it.

My dog is amused by the smelling analogy, BTW.   He says smelling works just fine for finding food.  One of which is bugs, coincidentally.

I don't understand your objection here. Running a metric also counts as "smelling."

The entire (stated) point of complexity metrics is just to estimate how the code smells. That's all. There's nothing wrong with that, however it's not a method where the direct goal is to actually find bugs (and reminder: we got down this rabbit hole when you claimed there was a specific bug and I asked for evidence).

Is this your code?

Now that's funny!


Anyway, how about those reproduction steps? Since you said there's observable evidence of a hyperbolic bug that's the real meat and potatoes now, all the rest is just in good fun.  ;)
« Last Edit: 06/02/2024 06:48 pm by Twark_Main »

Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2699
  • Seattle
  • Liked: 2090
  • Likes Given: 3406
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #71 on: 06/03/2024 01:13 am »
Here's a snapshot of a 30-100 day for departure Vinf.

1. Why are there mid 2025, 2027, and late 2029 departures that aren't part of the normal window of Mars 2024, 2026, and 2028 conjunctions?

2.  Why are the high deltaV windows so narrow for the correct conjunctions in 2024, 2026, and 2028?

3.  I note it refused to give me an actual 30 day trip result.

Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2699
  • Seattle
  • Liked: 2090
  • Likes Given: 3406
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #72 on: 06/03/2024 01:15 am »
If I drop down to 5 days apparently I can get to Mars instantaneously.

Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2699
  • Seattle
  • Liked: 2090
  • Likes Given: 3406
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #73 on: 06/03/2024 07:33 pm »
The reason I think it has something to do with hyperbolic orbits is that all the wonky stuff is above Vinf of 12.3km/sec, which is where the crossover to hyperbolic orbit happens at Earth distance from the Sun.

From:  https://wavwebs.com/PorkChopPlot/


Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2699
  • Seattle
  • Liked: 2090
  • Likes Given: 3406
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #74 on: 06/04/2024 02:27 am »

Idealized is good enough.  It is irrelevant whether it's +/- a couple of days or a 0.5 km/sec.

Looking at the (large) differences between various Earth-Mars conjunctions, I doubt it would be adequate. Also, 0.5 km/s is a lot!


If you are in a traditional low-capability environment such as SLS or cheapest-starship rendezvous where there's barely enough deltaV (~4km/sec)  to get to Mars and one has a tool that has an error of  +/- ~1km/sec then you would be correct.  (the radial velocity of the earth varies by +/- 0.5km/sec depending on the season1 for example.  As does Mars, and so does the Z axis)

But those aren't any of the use cases I'm concerned with.  I'm trying to work out things with an earth Vinf in excess of 12km/sec.  At that point it's almost irrelevant about non-circular aspects of Earth/Mars orbits, it's literally rounding error.  If I take the arcsin of 0.1 (10%) of my deltaV budget to compensate for up to 1.2km/sec differences in radial velocity between Earth and Mars I get an angle of 5.7 degrees.  That translates to 0.5% less velocity in the cosine direction. 

to quote Wallace from Wallace and Gromit in A Grand Day Out

Quote
adjusting thrust angle

is sufficient to deal with minor bobbles in orbits when estimating hyperbolic rendezvous times for most solar system objects.

It also happens that all the porkchop stuff I've tried happens to not work well for hyperbolic orbits.


1 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4742028

Offline mikelepage

  • Full Member
  • ****
  • Posts: 1281
  • ExodusSpaceSystems.com
  • Perth, Australia
  • Liked: 897
  • Likes Given: 1425
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #75 on: 06/05/2024 09:52 am »
At the risk of bringing more attention than I'm ready for, this is what I've been working on for the last year... (it's an early beta, feedback welcome). A proper launch will happen at some point down the track when I've fixed a bunch of things.

https://exodusspacesystems.com/exodus-pathfinder-project/

While not strictly on topic, I've always found porkchop plots to be something of an abstraction, so the goal here was to game-ify the user interface, and have a better way to browse the JPL small body database. The sector grid, as well as the trajectory and lookup modes are my original implementations.

Here's a snapshot of a 30-100 day for departure Vinf.

1. Why are there mid 2025, 2027, and late 2029 departures that aren't part of the normal window of Mars 2024, 2026, and 2028 conjunctions?

2.  Why are the high deltaV windows so narrow for the correct conjunctions in 2024, 2026, and 2028?

3.  I note it refused to give me an actual 30 day trip result.

Hopefully the difference in interface sheds some light on your questions? You'll notice I've also excluded hyperbolic transfers (even having e > 0.98 was inducing some plotting weirdness, so I've kept everything within the regular elliptical transfers).

Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2699
  • Seattle
  • Liked: 2090
  • Likes Given: 3406
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #76 on: 06/05/2024 07:29 pm »
Quote from: mikelepage link=topic=33642.msg2597207#msg2597207
You'll notice I've also excluded hyperbolic transfers (even having e > 0.98 was inducing some plotting weirdness, so I've kept everything within the regular elliptical transfers).

Thanks for doing this work!

Alas, hyperbolic transfers are still the poor step child of mission capability planning.

Starship is the first spacecraft truly capable of hyperbolic transfer, so it's probably why it's been the poor stepchild.

Do you know why there's plotting weirdness with hyperbolic transfers?   I note that's what I got with the weird off-cycle pork chop transfers - only at hyperbolic speeds.

Alas it is too early to post what I've got.  I just got secant and golden ratio searches working yesterday, to do multi-variable searches I have to now implement gradient descent or one of its cousins.
« Last Edit: 06/05/2024 07:29 pm by InterestedEngineer »

Offline mikelepage

  • Full Member
  • ****
  • Posts: 1281
  • ExodusSpaceSystems.com
  • Perth, Australia
  • Liked: 897
  • Likes Given: 1425
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #77 on: 06/06/2024 07:51 am »
Do you know why there's plotting weirdness with hyperbolic transfers?   I note that's what I got with the weird off-cycle pork chop transfers - only at hyperbolic speeds.

I must admit I really don't. It's been quite a while since I touched that section of code, and I struggled with it even then.

My (bisection) implementation was largely based off of this pdf:
https://control.asu.edu/Classes/MAE462/462Lecture10.pdf
which doesn't cover the hyperbolic approach, but I thought the following comment was revealing:
Quote
These algorithms are very touchy and ill-tempered, especially for multi-revolution orbits and at the transition between elliptic and hyperbolic orbits
and that's why I decided not to even attempt it. My interest was more in making an interface that was easier to use and more fun.

Offline Twark_Main

  • Senior Member
  • *****
  • Posts: 4043
  • Technically we ALL live in space
  • Liked: 2154
  • Likes Given: 1304
Re: Tool: Generate C3 porkchop plots for interplanetary travel
« Reply #78 on: 09/08/2024 08:52 pm »
Posted some information on broken plane transfers in a different thread, but it's relevant in this thread too.

From the video, I notice your paths are going "up and over" the Sun's poles. From this I gather you don't do broken plane transfers, only ballistic transfers.

Check out these resources:

https://hopsblog-hop.blogspot.com/2013/01/deboning-porkchop-plot.html

https://physics.stackexchange.com/questions/123029/why-is-there-a-gap-in-porkchop-plots

http://www.braeunig.us/space/ (section "Non-coplanar Trajectories")

There's an implementation of the latter...  for KSP.  :D Selecting "Optimal" will perform both ballistic and broken plane calculations and return the cheapest option.

https://alexmoon.github.io/ksp/

https://github.com/alexmoon/ksp

Even that algorithm isn't quite optimal. It's actually better to do a hybrid strategy, with part of your plane change at departure and part of it during the mid-course burn. See:

https://orbital-mechanics.space/orbital-maneuvers/plane-change-example.html

https://space.stackexchange.com/questions/12997/saving-delta-v-by-splitting-plane-changing-manoeuvre

It's not perfectly optimal, but it's close. To find the exact optimal solution would require a 4-D binary hill climb for the mid-course burn X/Y/Z/time variables. At first I worried this would be too simplistic an approach, but further research reveals that's exactly how NASA solved the problem.  :D

https://ntrs.nasa.gov/api/citations/19940010378/downloads/19940010378.pdf (see "Optimizer" on page 16 / PDF page 28)

Sorry for the number of links, but hopefully you find something useful in it.
« Last Edit: 09/09/2024 01:00 am by Twark_Main »

Tags:
 

Advertisement NovaTech
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1