Challenge Fully loaded Shuttle-A from Earth to Ganymede

mbartley

Member
Joined
Mar 26, 2008
Messages
66
Reaction score
0
Points
6
Run the Shuttle-A -> "Shuttle-A Launch" scenario.
Using the scenario editor, change the date to July 11, 2011 - a good Jupiter launch window.
Get to Ganymede orbit, using the magic of scenario editor to refuel after reaching low earth orbit.

I managed to get to a 100 km equatorial orbit around Ganymede on December 7, 2013, with only 789 m/s of delta-V left, according to IEAT MFD: nowhere near enough to land safely.

I planned the flight to Jupiter with IMFD, minimizing the combined departure and arrival delta-V requirement. I launched into Earth orbit at the appropriate time and refueled after reaching orbit. Near the end of the trans-Jupiter burn, I brought up Trans-X into Jupiter encounter stage and cut off the burn early when the estimated encounter altitude reached 1G (1 million km), approximately the semi-major axis of Ganymede's orbit.
About half-way there (in time), I made an out-of-plane maneuver while watching IMFD Map mode, aiming to minimize equatorial inclination at Jupiter arrival and hit the same 1G periapsis. No further course corrections.
Near perijove, I used IMFD in target intercept mode to hit Ganymede, in 2-plane mode, with the burn starting at perijove and intercept time chosen to minimize combined delta-V. I then executed this plan, using IMFD Map mode to watch the Ganymede encounter altitude and course correct as needed.

I've tried more sophisticated 3-burn Jupiter encounters with moon gravity assists, but I have to do so many major course corrections and deep space maneuvers I run out of fuel trying to drop into Ganymede orbit, if not sooner.

I'm curious what others here can do, and how. :thumbup:
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
I haven't attempted this yet, but I've run a few numbers to estimate how much I think that the exercise should cost. Here are the numbers and reasoning:

1. I assume that one starts in a fully-fuelled Shuttle-A in a 300 x 300 km orbit around Earth in plane with Jupiter on the nominated departure date of July 11, 2011.

2. According to BurnTime Calculator, a fully-fuelled Shuttle-A carries 14,000 m/s of delta-V.

3. Using IMFD, I estimate that to eject from Earth to Jupiter along a Hohmann trajectory on the specified date requires an ejection burn of 6,419 m/s. I assume that the target radius at Jupiter encounter is 75,000 km - i.e., a few thousand km above the Jovian cloud deck (a la the "Callisto Challenge").

4. Prior to entry into Jupiter's SOI, I assume that one rotates the approach trajectory so that the Jupiter periapsis lies on the line of nodes of the Shuttle-A's trajectory around Jupter, and Ganymede's orbit around Jupiter. I assume that it may take anything up to 100 m/s to achieve this alignment.

5. I assume that the Shuttle-A executes a 405 m/s retrograde burn at Jupiter periapsis to target a new apojove of around 17.5 million km.

6. At this apojove, I assume that the Shuttle-A executes a 665 m/s prograde burn to lift the perijove up to Ganymede's orbital radius. To this, I guesstimate another 150 m/s to align planes with Ganymede and to synchronise the encounter with Ganymede. (This guesstimate is based on experience with the "Callisto Challenge". The real value could be a little higher or lower).

7. At Ganymede encounter, the hyperbolic excess velocity should be around 4,057 m/s. To insert into a 20 x 20 km circular orbit around Ganymede one needs to execute a hefty 2,960 m/s retrograde burn at Ganymede periapsis.

8. To all of this, I add around 300 m/s for ancillary mid-course corrections.

The total delta-V tally is then:

TJI burn: 6419 m/s
Node alignment: 100 m/s
Oberth burn: 405 m/s
Apojove burn: 665 m/s + 150 m/s
GOI burn: 2960 m/s
MCCs: 300 m/s

Total delta-V: 11,000 m/s

So, in principle, one should arrive in a circular orbit around Ganymede with something close to 3,000 m/s of fuel to spare. I would be interested to see how your experience tallies with these 'back-of-the-envelope' calculations.

A couple of other comments:

a. The really sizeable burn, see is the initial TJI burn. One approach might be to try a sling-shot around Mars. This could save a 2 to 3 thousand m/s of fuel. (One could also try a VEGA-style Jupiter approach - although that sequence is much harder to set up in Orbiter. However if you could do, you would save around 3,500 m/s of delta-V).

b. The other big burn is the GOI burn. Here, a series of gravity de-assists would make sense. But, as you have probably noticed, Orbiter's current mission planning tools really aren't geared up to execute these manoeuvres with much fidelity (or efficiency).


Over the weekend, I may attempt this sequence 'for real' to see if the calculations match reality.
 
Last edited:

mbartley

Member
Joined
Mar 26, 2008
Messages
66
Reaction score
0
Points
6
4. Prior to entry into Jupiter's SOI, I assume that one rotates the approach trajectory so that the Jupiter periapsis lies on the line of nodes of the Shuttle-A's trajectory around Jupiter, and Ganymede's orbit around Jupiter. I assume that it may take anything up to 100 m/s to achieve this alignment.
That's the part I couldn't get. I've been able to do this well when arriving in other years, but not this one (2013). My projected arrival in this scenario had me about 90 degrees off. I don't know how I could get periapsis on a node without aiming for a nearly polar orbit at Jupiter. Is that what you did? What tool did you use to visualize it?

In scenarios where I have been able to do this, I've been able to then do moon encounter gravity de-assists, and sometimes even moon encounter plane changes. But again, only with burning up a lot of fuel on course corrections.

OK, so I've run my own flight plan and arrived in low orbit around Ganymede with about 3,000 m/s left over.

Very nice. You probably could even land after that.
I'll try again.
PS, in the scenario where I was low on fuel in Ganymede orbit, I found that after jettisoning the payloads and leaving them in Ganymede orbit for later rescue, the Shuttle-A lightened up so much I was not only able to land on Ganymede, but I was actually able to actually instead return to Earth!
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
That's the part I couldn't get. I've been able to do this well when arriving in other years, but not this one (2013). My projected arrival in this scenario had me about 90 degrees off. I don't know how I could get periapsis on a node without aiming for a nearly polar orbit at Jupiter. Is that what you did? What tool did you use to visualize it?

As you have probably worked out, this 'node alignment' is a fairly subtle - but important - part of the whole process. Anticipating a few questions about this, I did a 'quick save' of the flight shortly before the Oberth burn at Jupiter periapsis. So, just so that we are on the same page - and in case others read this who aren't familiar with this concept, after having completed the node alignment, the goal is to have TransX display look something like this:



The green line is, of course, the Shuttle-A's hyperbolic trajectory around Jupiter; and the white line is the line of nodes (i.e., the intersection of the Shuttle-A's orbital plane with Ganymede's orbital plane). Importantly, the line of nodes needs to bisect the hyperbolic trajectory (green) so that periapsis lies on that line of nodes. And the reason for doing this is to ensure that after the Oberth burn at Jupiter periapsis, TransX shows something like this:



This means that when you do your apoapsis burn (or near apoapsis) it too lies on the line of nodes which means that you can then efficiently incorporate a 'plane change' component into your prograde burn to lift orbital periapsis up to Ganymede orbital radius. That means that when you encounter Ganymede at periapsis, you are (more or less) in plane with Ganymede. And that means that your Ganymede encounter velocity is as low as possible.

Rotating the line of nodes
I'm guessing that you know all of this already - but others may read this and wonder what the underlying logic is. Probably what you really want to know 'how do you go about doing the plane alignment in the first place'. In which case, here are some thoughts:

Imagine a straight line connecting the Shuttle-A to the centre of Jupiter. Now consider the Shuttle-A's velocity vector in relation to that line: the you are a long way out from Jupiter - say, 50 million km - your velocity vector and that line point in almost the same direction. There is, however, a small angular difference. To align the line of nodes with periapsis, one has to rotate the ship's velocity vector around the line point to the centre of Jupiter. The question is: how does one do that:

To rotate the ship's velocity vector in this fashion, one needs to:
a. rotate the ship into either the 'normal+' or 'normal-' position (wrt to Jupiter - not the Sun!)
b. lock the ship in that position (either using the autopilots if within Jupiter's SOI; or using manual control otherwise)
c. engage the main engines on a very low thrust setting (so as to not overwhelm the autopilot)
d. sit back and wait for the ship's orbital plane (and line of nodes) to very slowly rotate.

This should rotate the velocity vector and disturb the periapsis radius as little as possible as it rotates. In principle, if you rotate for long enough you will eventually come back to where you started from. And in doing so, the line of nodes will pass through the periapsis point twice. (Why twice? The line of nodes is just that: a line. Rotate it by 180 degrees and its the same line.)

One achieves the same rotation (albeit in reverse) by using 'normal-' rather than 'normal+'. And generally speaking, one of these directions requires less rotation than the other. To work out which is the better direction in which to rotate, it makes sense to use TransX in manoeuvre mode; apply some +ve and -ve plane change and see what impact that this has on the orientation of the line of nodes. (N.B., if you use TransX in this fashion, just applying 'plane change' will not preserve the periapsis radius. To do that you will also need to apply some 'outward' as well. Never, though, use 'prograde' since use of that doesn't correspond to a rotation of the ship's velocity vector).

When I ran your scenario, I performed this manoeuvre 100 million km out from Jupiter. The delta-V cost at that distance was around 20 m/s or so - a relatively inexpensive thing to do at that distance. This manoeuvre rotated the ship's velocity vector by around 25 degrees as evidenced by this snapshot of Orbit MFD:



Whenever I've performed this manoeuvre following a Hohmann transfer from Earth to Jupiter, rotations have generally been around this much - i.e., 25 degrees. Some circumstances may require more or less than this, I suppose, but a rotation of the Shuttle-A's orbital plane so that it is near polar seems a little unlikely.

When to start and stop the rotation
Assuming you can work out in which direction you should rotate your velocity vector - i.e., using 'normal+' or 'normal-' - there is the ancillary questions 'when should you start and stop the rotation. Basically, it makes sense to do the node alignment when you are still a long way out from Jupiter. The Callisto Challenge, for example, starts with a Delta Glider close to the edge of Jupiter's SOI at around 22 million km (and one month before perijove). There, the cost of the node alignment is around 89 m/s. If one performed the nodes alignment when one was 50 million km out, then it would cost roughly as much - and so on. So, generally speaking, the earlier the better. I would say that performing the manoeuvre when one is 100 million km out from Jupiter, would be sensible.

And when to stop? TransX is the only tool that I know of that will show the line of nodes. Generally, I simple 'eye-ball' the rotation and when the line of nodes seems to bisect the ship's hyperbolic trajectory, I stop. One could use rulers and protractors if one so wishes - but I find that eye-balling it works pretty well.

The cost of course corrections
The main difficulty in executing the '3-burn' technique is that the initial Oberth burn throws the craft so far away from Jupiter that perturbations from the Sun become non-negligible. As you have noted on the return leg back to Ganymede encounter, one has to make a series of corrections in order to mitigate the effect of Sun induced perturbations. The further one is thrown away from Jupiter, the more corrections one has to make. But on the other hand, the further away you go, the more efficient the '3-burn' technique should be.

For Jupiter, the sweet-spot appears to target an initial apoapsis radius of between 15 million km and 20 million km. I usually opt for the half-way point - i.e., 17.5 million km but there are no hard and fast rules.

After the Oberth burn and on the outward leg to apoapsis, I use IMFD's Course program to estimate the optimal time to do the 'apoapsis' burn. The Course program has a 'dV' estimate in the bottom left corner. As one moves away from Jupiter (assuming that one has set up the encounter date correctly in the Course prgram), the 'dV' estimate will steadily fall. As one approaches apoapsis, the 'dV' estimate will begin to level off and, finally, it will begin to rise again. The optimal time to do the apoapsis burn when the dV estimate begins to rise again. This may be either before or after apoapsis - but if the node alignment has gone well, it should be reasonably close to apoapsis.

Once one has carried out the apoapsis burn, one is on the way back to Ganymede encounter and, hopefully, more or less in plane with Ganymede after that burn. Again, I use IMFD's Course program to monitor the effect of solar perturbations. If the dV estimate rises above 15 m/s, I carry out a correction burn and repeat as often as necessary to keep things 'on track'. I've found that for a target apoapsis of 17.5 million km, I need to do about three corrective burns - so a total fuel requirement of around 50 m/s. If I go out to 35 million km, corrective burns can be as much as 300 m/s.

Anyway, I hope these comments help.

---------- Post added 11-18-15 at 02:09 AM ---------- Previous post was 11-17-15 at 08:27 AM ----------

Just out of curiosity, I repeated the scenario but this time put an Earth Gravity Assist (EGA) manoeuvre at the front end. This time around, the total dV remaining after Ganymede Orbit Insertion was 5,274 m/s:



The EGA manoeuvre saved (net) about 1,500 m/s. I also managed to avoid Callisto this time which save, I guess another 300 or 400 m/s; and I was generally more careful in executing manoeuvres which save another a few hundred m/s.

The EGA manoeuvre is known as a "2+ dV-EGA" manoeuvre. The '2+' refers to it taking slightly longer than 2 years were the Earth Gravity Assist. And the 'dV' refers to the fact that a smallish (retrograde) burn needs to be executed at apoapsis of the spacecraft's initial orbit away from Earth in order to rendezvous with Earth. The design and implementation of these gravity assists is new ground for me and this was the first time that I've actually applied the maths in Orbiter. Somewhat gratifyingly, the maths works.

Anyway, the basic outlines of the EGA scheme is as follows:

a. Launch the Shuttle-A into a a 300 x 300 km circular orbit in plane with the ecliptic 777 days before the target Hohmann transfer date for going to Jupiter from Earth (in your case, 11 July 2011 or thereabouts).

b. Execute a 4,400 m/s burn to achieve an initial aphelion of 2.25 AU (i.e., beyond the orbit of Mars.

c. At apoapsis execute a retrograde burn of around 560 m/s to lower orbital periapsis to around 0.90 AU (and to set up a rendezvous with Earth).

d. At Earth rendezvous, slingshot around Earth in a prograde orientation at an altitude of around 300 km and, in the process, getting a velocity boost of 3.9 km/s.

e. If one gets the timing (and orientation) right, this sets the spacecraft on a near-Hohmann trajectory to Jupiter.

Once the EGA sequence is over, the 'mission' then proceeds as before. Roughly speaking, the fuel costs are:

1. 4,400 m/s for the initial escape burn
2. 560 m/s for the apoapsis burn
3. 100 m/s for node alignment and fine tuning Jupiter approach
4. 405 m/s for the perijove 'Oberth' burn
5. 665 + 150 m/s for the apojove burn to sign up Ganymede rendezvous
6. 2960 m/s for Ganymede Orbit Insertion (GOI)
7. 300 m/s for ancillary mid-course corrections.

Bearing in mind that it takes about 3,400 m/s for the Shuttle-A just to climb its way out of the Earth's gravitational well, the incremental cost of 1,560 m/s to get all the way to Jupiter seems pretty reasonable.

The other big budget item is the 2960 m/s for the final GOI. At some point, I may have a go at putting a gravity de-assist sequence at the back-end of this mission. I suspect that if I were to do so, I could save somewhere around 1,500 m/s (at the cost, though, of extending out the mission timeline by another year or so).
 
Last edited:

mbartley

Member
Joined
Mar 26, 2008
Messages
66
Reaction score
0
Points
6
As you have probably worked out, this 'node alignment' is a fairly subtle - but important - part of the whole process. Anticipating a few questions about this, I did a 'quick save' of the flight shortly before the Oberth burn at Jupiter periapsis. So, just so that we are on the same page - and in case others read this who aren't familiar with this concept, after having completed the node alignment, the goal is to have TransX display look something like this:
My approach (two attempts now) didn't look anything like that. I was never able to get a decent node alignment. Perhaps I'm trying to do it too early? You mention waiting until much closer (100 million km) to Jupiter than me.

My second attempt ended up about the same as before, reaching circular Ganymede orbit with little fuel left, but this time only after two gravity assist flybys first. Final orbit insertion burn was 2013 m/s.

Just out of curiosity, I repeated the scenario but this time put an Earth Gravity Assist (EGA) manoeuvre at the front end. This time around, the total dV remaining after Ganymede Orbit Insertion was 5,274 m/s:
...
The EGA manoeuvre is known as a "2+ dV-EGA" manoeuvre. The '2+' refers to it taking slightly longer than 2 years before the Earth Gravity Assist. And the 'dV' refers to the fact that a smallish (retrograde) burn needs to be executed at apoapsis of the spacecraft's initial orbit away from Earth in order to rendezvous with Earth.

That's really cool. I've tried following flights from the NASA Trajectory Browser, which often shows flights like that, and I've never been able to get it to work. Do you do the first part (before the Earth flyby) all in the ecliptic plane?
I did manage to re-create the more complicated Cassini mission once, but other attempts to do inner planet gravity assists haven't worked out for me.
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
My approach (two attempts now) didn't look anything like that. I was never able to get a decent node alignment. Perhaps I'm trying to do it too early? You mention waiting until much closer (100 million km) to Jupiter than me.

In truth, I haven't tried using this technique further out than 100 million km. One is relying on TransX, and although it is a powerful tool in many ways, I don't trust its accuracy for very long range planning.

Just to stress, though, the node alignment is really all about executing a plane alignment so as to (eventually) get into plane with the target moon (e.g., Ganymede) prior to the final insertion burn. Its utility stems from the fact that it is usually a cheaper way of achieving plane alignment rather than performing a deep space 'plane change' manoeuvre prior to arrival at Jupiter. It is cheaper because the plane change is a) done at a time when the ship's speed relative to Jupiter is very low (~ 1km/s or less); and b) it is coupled with a largely prograde periapsis- raising burn.

However, if you have executed a plane change manoeuvre prior to Jupiter arrival then aligning nodes isn't going to be helpful. In fact, its going to be nigh-on impossible to do.


My second attempt ended up about the same as before, reaching circular Ganymede orbit with little fuel left, but this time only after two gravity assist flybys first. Final orbit insertion burn was 2013 m/s.

Do you have a break-down of the cost of the various burns that you make? It may help to work out where the fuel is going. The bare-bones three-burn approach should still have you arrive in Ganymede orbit with around 3,000 m/s of fuel to spare.

Setting up efficient gravity de-assist sequences using TransX/IMFD is a hard thing to do. For the most part, I end up using more fuel for MCCs than I save. The only way that I have been able to do better is to work up a full n-body integrator and work out the sequence of burns needed to execute the gravity de-assists. Very efficient, very accurate - but exceedingly time consuming and not something for the mathematically faint of heart. 'dgatsoulis' has, it seems, used IMFD to good effect in setting up gravity de-assists, but his fidelity with IMFD is superior to mine.


That's really cool. I've tried following flights from the NASA Trajectory Browser, which often shows flights like that, and I've never been able to get it to work. Do you do the first part (before the Earth flyby) all in the ecliptic plane?

Yes, the Earth flyby sequence is all in Earth's orbital plane, the ecliptic. The calculations needed to do so are just based on a simple patched-conics approximation. I've managed to put these calculations on a spreadsheet and I am now in the process of writing up some notes and procedures so that others can understand what is going and then implement these techniques for themselves using that spreadsheet and TransX/IMFD. Over the next few weeks I will (hopefully) post something in the Maths & Physics section on this.

(P.S. Thanks for introducing me to the Nasa Trajectory Browser, by the way. Until now, I wasn't aware that this resource existed.)
 
Last edited:

mbartley

Member
Joined
Mar 26, 2008
Messages
66
Reaction score
0
Points
6
Do you have a break-down of the cost of the various burns that you make? It may help to work out where the fuel is going. The bare-bones three-burn approach should still have you arrive in Ganymede orbit with around 3,000 m/s of fuel to spare.
I'll have to try the original scenario again and note that.
I tried a different launch opportunity, arriving at Jupiter in Nov. 2019. This time, I was able to do a proper node alignment. However, it wasn't perfect, plus the original Jupiter orbit insertion left me with a much lower apopapsis than planned. If I'd done both better... Anyways, here were the major remaining maneuvers to reach Ganymede, months later. I did course corrections with RCS and didn't try to measure that.

plane alignment: ~125 m/s
Ganymede targetting burn #1 (raising Jupiter periapsis): 2916 m/s
(flyby)
Ganymede targetting burn #2: 810 m/s
(flyby)
Ganymede targetting burn #3: 27 m/s
Ganymede orbit insertion: 982 m/s

I could have entered orbit at the second encounter instead of making another flyby; it wasn't worth it. I had 1660 m/s left after reaching circular orbit. Better than before, but it should be better.
 

dgatsoulis

ele2png user
Donator
Joined
Dec 2, 2009
Messages
1,927
Reaction score
340
Points
98
Location
Sparta
Unfortunately, I haven't so far been able to contribute anything to this thread, due to RL workload.
Hopefully, I will have time to give the whole mission a try this next weekend and show my results here.

Tonight, being one of those sleepless nights before a big presentation I have for tomorrow, I thought I'd share some of the work I've done on similar missions in the past.

On the subject of reducing the Trans-Jupiter injection dV:

The EGA trajectory is the safe bet, for when there are are no other viable slingshot trajectories (which btw is pretty rare).
The savings in dV are between 1-2 km/s - compared to a direct Trans-Jupiter injection burn - and the time penalty is in the +2 years region.
Setting it up is quite fun, but you do need the help of a spreadsheet.
There was a question by wingnut in the MFD questions and help section a few months back,in which the setup was covered in detail (post #4 of this thread), including the maths, a google spreadsheet and a detailed setup of the flight.

The user boogabooga went into the trouble of copying the spreadsheet in Excel, where one can use the solver feature to avoid some of the time-consuming back and forth between the variables needed to be checked, in order to get an optimised plan. You can find the link in post #8 of the same thread.

Following other paths to Jupiter:

This paper by Anastassios E. Petropoulos, James M. Longuski and Eugene P. Bonfiglio covers conventional and non-conventional paths to Jupiter via gravity assists from Venus Earth and Mars for the years 1999 - 2031.

I've converted the data shown in pages 5 and 6 into a spreadsheet, covering the trajectories from 2011 to 2031. You can use excel's sort and filter feature to find whatever type of trajectory interests you, whether you want to minimize dV, Time Of Flight or some combination of both.
I've attached the spreadsheet on this post. The headline row is pretty much self explanatory, but here is how to read it in case there's some confusion:

Path = The series of gravity assists before reaching Jupiter. VE is a Venus→Earth series, VVV is a triple Venus series, VMVE is Venus,→Mars→Venus→Earth, and so on.
Launch Date = Launch date in day/month/year format.
Launch MJD = converted to MJD.
Launch Vinf (km/s) = The hyperbolic excess velocity relative to Earth of the Trans-(first planet of the path) burn. Keep in mind that this is unoptimised/rounded to the closest quarter of a km/s.
Inj DV (km/s) (200x200km) = The cost of the Injection burn for the Vinf above, from a 200x200 km parking orbit.
Flyby DV (km/s) = Some gravity assists need to be powered; the cost is shown here and also the number of the series encounter. For example, 0.255 (2) means that a burn of 255 m/s will be needed at the periapsis of the second planet encounter of the series. An empty cell in this column means that all encounters are unpowered.
Arrival Vinf (km/s) = The hyperbolic excess velocity relative to Jupiter upon arrival.
Capt.DV (km/s) (1200 km) = The Vinf above, converted into a capture burn at an altitude of 1200 km (Just above Jupiter's cloud-tops). Remember that the apoapsis of this burn is at infinity.
Total DV (km/s) = The Inj DV + the flybies + the capture burn.
TOF (y) = The duration of the flight in years.
Flyby times in days after launch = The number of days passed since launch to the flyby. For example: a VMVE path with 433, 1024, 1350, 1400 in this column, means that the first encounter is on day 433 after launch, the second is on day 1024 after launch and so on.
In some cases you will notice the letter 'r' between the flyby times. This means that the spacecraft's trajectory and the next target's orbit will be in resonance. Practically, this means that you'll have to go around the Sun once, before you reach your next target.
# Enc MJD = (This covers the next five columns) The flyby times converted to MJDs.

I tried to make this spreadsheet as Orbiter-friendly as I could, any additions/suggestions are welcome.

In a next post I'll setup an example flight from the spreadsheet.
 

Attachments

  • Jupiter trajectories.zip
    19.8 KB · Views: 6
Last edited:

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
Ganymede targeting burn #1 (raising Jupiter periapsis): 2916 m/s

That's a hefty burn - and probably where much of the fuel is going. If the Oberth burn (to achieve Jupiter capture) is done at a radius of 75,000km around Jupiter (a few thousand km above the cloud deck), then the retrograde burn at Jovian periapsis to achieve capture and to set a new apojove to around, say, 17.5 million km should be ~400 m/s; and the subsequent periapsis raising manoeuvre should only require 650 - 800 m/s. So, to have 2916 m/s for the periapsis raising (and plane alignment) manoeuvre only would seem to be about 2,000 m/s higher than it should be. That, together with the fact that your Oberth burn was probably substantially higher than it needed to be, probably accounts for most of delta-V discrepancy.

One can do back of the envelope calculations to work out the size of the Oberth burn to set the new apojove. Or one can use IMFDs "Delta Velocity" and "Map" programs to do these calculations for you. If you want to do the back of the envelope calculations then you need to calculate:

[math] \Delta V_{Oberth} = \sqrt{\frac{r_{a}}{r_{p}}\,\frac{2\,\mu}{r_{a}+r_{p}}} - v_{\pi} [/math]
where [MATH]\mu = 126686534.0\,km^3\,s^{-2}[/MATH] is the standard gravitational parameter for Jupiter; [MATH]r_a = 17,500,000\,km[/MATH] is the target apoapsis after the Oberth burn; [MATH]r_p = ~75,000\,km[/MATH] is the perijove of the inbound trajectory to Jupiter; and [MATH]v_\pi = ~58.4\,km/s[/MATH] is the velocity of the craft at perijove (available from IMFD "Map" program). This calculation should give a number of around -400 m/s.

The periapsis-raising burn needs to be done 'near' apoapsis, but because of TransX inaccuracies, it is rarely the optimal time. I would suggest that anything up to a few months prior to apoapsis is a good time to open IMFD's "Course" program and switch to "two-plane" mode. Then find the Ganymede encounter date that minimises your delta-V. Always check that this really is the minimum by winding the encounter date forward/backwards by one Ganymede orbit to see if you can improve on delta-V. Keep on winding forwards or backwards until you cannot improve. Having done this, then 'time warp' slowly ahead while making sure that arrival angle at Ganymede stays close to zero. You should see the delta-V estimate steadily fall for a time, and then it will begin to increase again. The point where the delta-V begins to rise again is the optimal time to do the burn. For a 17.5 million km apoapsis, the delta-V cost (including the plane change to match Ganymede's orbital plane) should be around 650 - 800 m/s. Much higher than this and I would suggest that something has gone wrong.

Ganymede orbit insertion: 982 m/s
That's actually a very low GOI burn. Given that orbital velocity around Ganymede is ~ 1930 m/s, the minimum burn required to achieve that is ~800 m/s. So, well done! It certainly is a big improvement on the 2960 m/s needed for a standard orbit insert burn (for a 17.5 million km apoapsis).

---------- Post added at 02:47 AM ---------- Previous post was at 02:15 AM ----------

There was a question by wingnut in the MFD questions and help section a few months back,in which the setup was covered in detail (post #4 of this thread), including the maths, a Google spreadsheet and a detailed setup of the flight.

Thanks, 'dgatsoulis' for pointing that out. I hadn't realised that this topic had ben covered earlier.

One thing to add, though, in addition to matching [MATH]v_\infty[/MATH] at Earth encounter, in principle one also needs to align the approach angle and departure angles. For the EGA scheme to work (and for circular orbits), the Earth approach angle need to be around 13.8 degrees; and the departure angle somewhere around 3.5 degrees. Usually, there is enough 'slack' in the flyby parameters to accommodate some inaccuracies here - but if one is trying to coordinate multiple gravity assists, then matching all three variables at each encounter becomes more important.


Hopefully, I will have time to give the whole mission a try this next weekend and show my results here.

I will be interested in seeing what you can do. I suspect that if one tried hard enough one could get in to Low Ganymede Orbit with between 7,500 m/s and 8,000 m/s to spare. Good luck!
 
Last edited:

mbartley

Member
Joined
Mar 26, 2008
Messages
66
Reaction score
0
Points
6
That's a hefty burn - and probably where much of the fuel is going. If the Oberth burn (to achieve Jupiter capture) is done at a radius of 75,000km around Jupiter (a few thousand km above the cloud deck)
I made another attempt, got to an altitude of about 4 thousand km and got an apoapsis of 5 million km, and nearly nailed the node alignment. Indeed the fuel requirements were less.

This however illustrates two serious sources of inaccuracy I've noticed in this project. Aiming for such a low altitude above Jupiter is difficult. Even IMFD Map's results are wild until close up (within Ganymede's orbit). I limited my apoapsis at Jupiter to 5 million km. Even that far, much less 15 million km you talk about, I find aiming at Ganymede inaccurate.

After the periapsis burn, Orbit MFD's prediction of apoapsis is way off until I get out to around Io's orbit. Is that non-sperical gravity?

The periapsis-raising burn needs to be done 'near' apoapsis, but because of TransX inaccuracies, it is rarely the optimal time. I would suggest that anything up to a few months prior to apoapsis is a good time to open IMFD's "Course" program and switch to "two-plane" mode. Then find the Ganymede encounter date that minimises your delta-V. Always check that this really is the minimum by winding the encounter date forward/backwards by one Ganymede orbit to see if you can improve on delta-V.
That's more or less what I do. In particular I aim the Ganymede flyby for minimum encounter speed as shown in IMFD target intercept, or slightly sooner. Then I course correct to make a prograde flyby. The actual intercept time will be sooner than predicted by 2-body prediction. (TransX or IMFD target intercept)

After one or two flybys, my orbit is close enough to Jupiter that I use Sync Orbit MFD to look for an upcoming close encounter. Yes, this can be a long wait... I'll make maneuvers to get it closer and/or reduce encounter speed.

My last attempt, after 3 flybys as described above, got me into Ganymede orbit at the 4th encounter, leaving 3600 m/s of fuel left. The final orbit insertion burn was 1600 m/s. Not too good - sometimes I don't get a low encounter speed, but I'd have to maneuver significantly to reduce it, and it often isn't worth it.
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
This however illustrates two serious sources of inaccuracy I've noticed in this project. Aiming for such a low altitude above Jupiter is difficult. Even IMFD Map's results are wild until close up (within Ganymede's orbit).

Yes, I agree: IMFD Map's results are wild. I know that 'dgatsoulis' seems to work magic with IMFD Map, but I struggle with it just as you do. Although an improvement over TransX for many tasks, I rather think that this sequence of manoeuvres pushes IMFD beyond the limits of what it was designed to - which, of course, leaves the humble Orbiter navigator somewhat bereft of serviceable tools. To be fair to IMFD Map, it is an n-body integrator that is being asked to provide answers in 'real time' - even at time warp. And the fact of the matter is that it is difficult for computers to do this both quickly and accurately - and IMFD errs on the side of speed rather than accuracy. Generally, like everyone else that uses Orbiter, I work with these deficiencies as best I can and have developed ad hoc heuristics that limit the amount of delta-v to compensate for its inaccuracies.

I have developed a number of n-body integration tools that work 'offline' that are (it has to be said) considerably more accurate that IMFD Map. The first of these tools runs a small lua script that dumps the positions and velocities of the spacecraft, the Sun, Jupiter, Saturn and the four Galilean moons to a text file. I then have a separate little program that runs out outside of Orbiter that co-integrates the path of all of these bodies using a fourth order symplectic integrator to periapsis. At this point, the program performs a simple interpolation and returns the periapsis radius/altitude (together with any other information I may require (e.g., node and plane alignment, etc.) This co-integration takes just a few seconds and, from, say, 25 million km out, will predicts the outturn periapsis altitude to with an accuracy of around 10 km. If I am too high or too low then, at 25 million km, a small amount of RCS corrects the periapsis altitude.

This co-integration technique works well (and quickly) up to a point - usually pretty accurate for 30 days or so, but over time discrepancies rise between the paths of the planets and moons as calculated by the co-integration from the 'true' paths used by Orbiter. Although still better than IMFD and TransX, to compensate for this I have a gone a step further and built a full n-body integrator that uses the same ephemeris solution the Orbiter uses for Jupiter (VSOP87/Galsat). With that, I can hit the periapsis altitude from 1 AU out with an accuracy of < 1km. This works the someway as the co-integration method, but here all that is needed is the current speed and velocity of the spacecraft. This is then cranked through the integrator and (eventually) a highly accurate number pops out. This integration takes time - typically 10 seconds or so there is a substantial trade-off between accuracy and speed.

I have thought about writing the co-integration approach up a a lua script that can then be run by others as a sort of "long range periapsis calculator". It isn't terribly hard to write, and I should probably do that at some point.


I limited my apoapsis at Jupiter to 5 million km. Even that far, much less 15 million km you talk about, I find aiming at Ganymede inaccurate.

The three-burn technique becomes much more efficient the higher you throw the spacecraft away from Jupiter. 5 million km is probably still to low. Yes, aiming at Ganymede using IMFD/TransX is inaccurate. After the apoapsis burn, I use the IMFD Course program - frankly, it is considerably more stable than IMFD Map. Course corrections are required because of solar perturbations, but if I do small corrections to keep IMFD Course errors in check early enough, the total delta-V for course corrections is around 30-50 m/s. Good, but not great. Only when I'm with 1 or 2 days out from Ganymede do I bother to switch over to IMFD Map.

(Of course, applies the co-integration trick to this rendezvous problem as well. Even from, say, 30 million km out, MCCs can be as low as 1 or 2 m/s to set up an approach to Ganymede with arrival at a target altitude of 20 km +/- 0.1 km. The full integrator solution, can also be used, and I can set up an apoapsis burn that will take me all the way back to Ganymede without any MCCs at all - even from 40 million km out. Again, there is a case for writing up the co-integration tool as a lua script and making this more widely available.)

With an apoapsis of 5 million km, you are likely to need a fair amount of inward or outward in your apoapsis burn to get the rendezvous with Ganymede to work. If you aim for a higher apoapsis, setting up the Ganymede rendezvous becomes much easier, and much less costly.

After the periapsis burn, Orbit MFD's prediction of apoapsis is way off until I get out to around Io's orbit. Is that non-sperical gravity?

In a word: yes. Jupiter's J2 field is particularly strong out to Io's orbital radius. Its effect falls off very quickly as you move away from Jupiter so that by the time you are out to Callisto's orbital radius, its effects are pretty negligible. My suggestion would be to simply switch off no-spherical gravitation sources for the time being.


After one or two flybys, my orbit is close enough to Jupiter that I use Sync Orbit MFD to look for an upcoming close encounter. Yes, this can be a long wait... I'll make maneuvers to get it closer and/or reduce encounter speed.

Setting up efficient flybys is hard. This isn't a defect of Orbiter's gravity model, only a limitation of tools available within Orbiter to do it. Unfortunately, neither TransX nor IMFD are set up to provide the right kind information to do this. And the information that they do give tends to be not entirely reliable. The experience of setting up a gravity de-assist sequence in Orbiter can be pretty frustrating in my view.

Again, to get around these limitations, I've developed my own tools to do the job. The work well (almost too well, actually) but they are slow, hard to use and very time-consuming. I am still thinking about ways that the calculations to do the gravity de-assists can be set up and executed more efficiently, but so far to no avail.
 
Last edited:

dgatsoulis

ele2png user
Donator
Joined
Dec 2, 2009
Messages
1,927
Reaction score
340
Points
98
Location
Sparta
I'm curious what others here can do, and how. :thumbup:

I am finally sitting down to try this. I will be flying 3 versions of this flight and I'll be keeping a detailed log including pics of the progress of each mission.

1. A direct Earth > Ganymede flight with 2 main burns. One to leave Earth and the second to enter a low orbit around Ganymede. (plus corrections).

2. This version will make use of the Oberth effect, so there will be 4 main burns. TJI, capture burn at low Jovian altitude, Ganymede rendezvous setup at the apoapsis of the capture burn and finally the GOI burn. The TJI itself will be broken down into a series of two or three periapsis 'kicks', in order to minimize gravitational losses. The first burn will need to take place about 3 days before the indicated July 11th 2011 date posted by the OP.

3. The final version will be this: At the front end, I'll have a series of gravity assists to reach Jupiter. Once I'm there, I'll utilize the Oberth effect again and at the back end of the mission I'll add a series of gravity de-assists, to enter a low orbit around Ganymede. The launch date will be as close as I can get to July 11th 2011, but it may have to be a few months before or after that.

Pre-flight setup: Non-spherical gravity switched on. IMFD configured like this:

pic1_zpso7ufnckp.jpg


The reason for this setup is this: First, IMFD's map works best if you have non-spherical gravity switched ON. Yes, there is an option for IMFD to auto-detect the setting, but as far as the map's predictions go, you get the best results if you have it switched on. (Not to mention the benefit of the added realism.) The rest of the settings are selected for maximum accuracy, except the last one in the map's configuration page (error tolerance).
There, I have found that using a value of 4.000 is a good compromise between the accuracy of the map and the speed at which connected IMFD's 'talk' to each other.

You can setup IMFD like this from within Orbiter, or you can copy the lines below and paste them in your OrbiterRoot\Config\IMFD5.cfg file. This way, you won't have to set it up again each time you start a scenario.

Code:
// Configuration file for BaseSyncMFD, I-MFD, AeroBrakeMFD

Color_01 0x0000DD00  	// Current Ship orbit, Source Orbit [Bright green]
Color_02 0x00008800  	// Additional Map lines [Dark green]
Color_03 0x0000BB00  	// Base Text color [green]
Color_04 0x0000EEAA  	// Hilighted text 
Color_05 0x0000CCFF  	// Target orbit, Some Warnings [Orange]
Color_06 0x00EEEEEE  	// Selected Item [White]
Color_07 0x00FF5555  	// Planned trajectory [Blue]
Color_08 0x00666666  	// Planets [Dark Grey]
Color_09 0x000000DD  	// Warning lights [Red]
Color_10 0x00EEEEEE  	// [White]
Color_11 0x00999999     // Headlines, Some planets [Grey]
Color_12 0x0000BB00	// Adjustable Items
  

// Multibody predictor configurations
Rectification 0.005	// Rectification constant for trajectory engine
NonSpherical 2          // Use Non spherical gravity on low orbit prediction in Map Program, 0=Disabled, 1=Auto, 2=Always ON
LegSize 1			// Legsize factor used in Multibody predictor
LegsPerFrame 64		// Number of legs calculated each time step
Celbody 1			// Use Orbiter's Celbody Interface to improve accuracy of the map  (1=On, 0=Off)
Adaptive 0			// Use Adaptive step-size control (1=On, 0=Off)
AdapTol 4			// Error tolerance (Lower value = higher accuracy)
Integrator 0		// Default Integrator 0=RK5(6), 1=RK6(7), 2=RK7(8)	


// General Configurations
RefAltitude 120e3		// Reference altitude for atmospheric entry interface
ReEntryAngle 5.5		// Default ReEntry in degrees 
DateFormat 0		// Default Date Format 0=MJD, 1=GET
UseRegres 1			// Use Nodel Regression Estimation (1=On, 0=Off)
IgnState 1			// Use numerical ignition state propagation
FastUpdate 1		// Use Fast Update of MFD Screens	

// Key Setup
BaseSyncKey 0x30        // StartUp key used by BaseSyncMFD
IMFDKey 0x17            // StartUp key used by IMFD
RotationKey1 0x26       // Rotation Key "L"
RotationKey2 0x2C		// Rotation Key "Z"

    
// Auto-burn options
AB_Rate 10.0		// AutoBurn MaxRate (degrees/s)
AB_RCS_Th 2.0		// RCS Level Treshold m/s
AB_Thr_Th 20.0		// Throttle Down Level Treshold m/s

I will be changing some of these settings to suit my needs as the missions progress, but as far as the initial setup goes, this is how I start my scenarios.

Off to fly the first version of the mission.

Since the challenge scenario permits a 'magical' fuel re-supply at LEO, I'll start at a 300x300 km orbit around Earth with the Shuttle-A fully fueled. The inclination and LAN will be selected to fit the plane of the TJI burn, but I will have an approximate 1/10th of a degree misalignment of the orbital plane to maintain some realism. Usually my launches with the DeltaGlider are within 0.01°, but I can't even remember the last time I rode the aerodynamically 'challenged' Shuttle-A into LEO. This is how I'll start all 3 versions of the mission.

First task is to set the date, get the ship in LEO and check my delta-v budget.
Including the RCS, I start out with 14630 m/s.

Firing up IMFD and setting up a Jupiter intercept course. Since I will be going directly to Ganymede, I am selecting the course with the minimum arrival velocity at 5655 m/s

Preflight calculations:

I'm starting from the end. Arrival V∞ = 5655. This means a periapsis velocity at Ganymede's distance of 16394 m/s. Ganymede is orbiting Jupiter at a velocity of 10881 m/s; allowing for a ~10° off-plane intercept, I get an arrival V∞ relative to Ganymede equal to 5984 m/s, This gives a periapsis velocity @ 20 km above Ganymede equal to 6578 m/s which means an orbit insertion burn of 4647 m/s.

TJI burn (impulsive) = 6440 m/s, Burntime = 571.2 seconds. This burn is huge, covering more than 10% of a full orbit. Before continuing, I want to address this by figuring out the gravitational losses.
I know that the grav. losses are calculated by
[math] \int_{t_1}^{t_2 } g \; sin \gamma \; dt [/math] where g is the gravitational acceleration at the altitude of the burn, t2-t1 is the duration of the burn and γ is the flight path angle at the beginning/end of the burn. This is known as the finite burn problem.

pic2_zps6q62rfwi.jpg


Unfortunately I don't know how to solve integrals, so I'll just plug it in to wolframalpha and get the result: 842 m/s.

Hmm... from experience with the DG, I know that a burn this big has significant losses, but I don't think it's going to be that high. Besides, IMFDs AB feature doesn't use the method shown in the pic above, TransX does though (start burning to the "inside" of the prograde direction and end the burn to the "outside" of the prograde direction.)

No other option than to use a quicksave at this point and let the burn happen with IMFD's AutoBurn feature in the Orbit-Eject program, while keeping track of the ΔV. By the end of the burn, I am left with 7496 m/s.

Wow, the impulsive burn was 6440 m/s but the actual burn cost 14630 - 7496 = 7134 m/s. That's 694 m/s lost on IMFD's AutoBurn trying to correct the finite burn problem.
Fortunately, I know a couple of ways to minimize this loss. The first one is instead of leaving Earth in a single burn, using a series of smaller burns, each time raising the apoapsis of the trajectory until escaping after an x amount of revolutions. I will use this method in version #2 of this flight.

The other way to do it, is to use IMFD's Delta-Velocity and Map programs, instead of letting the autopilot of the Orbit-Eject program do the burn. All I have to do, is to try and arrive at Jupiter at the same date as the one shown in the Target Intercept program (this should result in an arrival velocity close to what the Target Intercept program shows), while adjusting my burn variables (x,y,z and time) keeping the ΔV as close as I can to the impulsive burn. This way, I should be able to keep the losses under 100 m/s.

Back to the quicksave and the calculations:

GOI burn ≈ 4650 m/s
TJI = 6450 + ~100 ≈ 6550 m/s
1% room for corrections ≈ 110 m/s
Total ΔV = 11310 m/s , let's round it to 11.3 km/s

I should be able to make it directly to Ganymede low orbit with ~3300 m/s left in the tanks.

Starting the Delta-Velocity and map programs. Since these are connected, I need to make a note of the Target Intercept program's arrival date, which is 56660.
Then I select an unshared IMFD and enter the burn shown in the orbit eject program. Once that's done, I share the other IMFD with the one showing the Delta-Velocity program, open the map, target Jupiter and press "plan" to see the trajectory prediction.

pic3_zpsnganlxkr.jpg


Right from the start, I run into a problem. The map's prediction doesn't extend all the way to Jupiter.
I can fix that by changing a few settings in the map's configuration page.
Period Limit: No
Hyper Limit: No
Adaptive: Yes
The journey will take ~910 days which is ~80M seconds. I'll let the prediction extend out to 100M seconds by setting the Time Limit to 100M (typing 100M or 100e6 or 100000000 is the same thing)

Now the prediction extends all the way to Jupiter.

pic4_zpsopltw58z.jpg


It is time to start fiddling with the burn variables to get the encounter when/where I want it. My aim is for an arrival close to 56660 at a PeD of ~1 G away from Jupiter (Ganymede's distance) and as low an equatorial inclination as I can get. (Ganymede is just 0.15° inclined relative to Jupiter's equator).
After ~5 mins of adjusting the burn variables:

pic5_zpsjmo8ojlv.jpg


I am spending less than my prediction and arriving 20 days early. But the PeV seems ok and the minimum equatorial inclination I can get is slightly more than 7°. I'll go ahead and burn this plan.
Here is the trajectory after the burn.

pic6_zpswiebpaqd.jpg


TJI cost: 6514 m/s
T to Jupiter periapsis: 76.51M seconds

Time-warping to the MCC at ~ 40M seconds away from Jupiter.
I switch the Map to reference Jupiter and targeting the equator. I center the periapsis at Jupiter (CNT : p-Jupiter) and I wait until Ganymede is near the periapsis of the predicted path. I need to setup my MCC with these characteristics:
Arrival @ Ganymede's distance from Jupiter, with the PeT being a multiple of Ganymede's orbital period around Jupiter. (that's why I waited for Ganymede to be near the periapsis). I also need to get the line of nodes exactly at the periapsis.
On the left is the pre-burn path and on the right the path after the MCC

pic7_zpsdh6xdko6.jpg


Notice how Ganymede 'right now' is almost exactly at the prediction's periapsis, the line of nodes is also there (but it did raise my Eq Incl to 11.74°) and the PeT is 64 times Ganymede's orbital period.
MCC cost: 37 m/s. Burning and time-warping to 20M seconds away from perijove.

The drill for the second MCC is the same as before; wait for Ganymede, get the periapsis and node exactly at Ganymede and the PeT a multiple of Ganymede's orbital period. Cost: 12 m/s

pic8_zpsagtpre7t.jpg


Time-warping 'til the PeT is in the single M digits away from perijove, to repeat the process once more.

pic9_zpszefqocpt.jpg


Turns out, I don't have to perform the 3rd MCC. My path is exactly where I want it, with the PeT being 16 times Ganymede's orbital period.
Time-warping 'til I'm inside Jupiter's strong SOI. Once there, I'll check my map to see how I am doing.

Ok, I am deep nside Jupiter's grav. well (G = 0.61) but I am not sure which prediction to trust. With the Map's "Adaptive" set to "On" I am doing really well, almost exactly on the path I want, but setting it to "Off" shows I will be falling deeper than Ganymede's orbit. I'll fire up TransX, target Ganymede and see what kind of prediction it shows.

pic10_zpszrvrmhvs.jpg


Ok, so with the map's "Adaptive: On" I am getting almost the same prediction as TransX. At this distance from Jupiter, this is somewhat trustworthy. I'll time-warp 'till I am ~1 Ganymede orbit away and keep a close eye to the map.
For my next (and final) MCC I'll keep the "Adaptive" to "On". I'll also lower the Time Limit to 5M seconds. I'll setup an Offset Target Intercept plan (target Ganymede) and watch the Map's prediction with Ganymede also targeted. Anything after that will be minor linear RCS corrections.

Turns out I made the right call. The Ganymede intercept burn costs only 9 m/s.

pic11_zpshn14uimd.jpg


Finally, the last leg of the mission. I'll make minor linear RCS adjustments to keep an orbit insertion altitude of ~20km above Ganymede and perform the GOI burn once I arrive.
Half a day away from Ganymede periapsis.

pic12_zpsbtabdklc.jpg


The GOI burn is a substancial one, at 4773 m/s. I'll set it up as a maneuver, to minimize grav losses again.

pic13_zpsvqnh6ncb.jpg


Welcome to Low Ganymede Orbit. ΔV left: 3254 m/s

pic14_zpsseb9ufzj.jpg


In a next post, I'll try the 2nd version of the journey with the Oberth effect at the back end, and a series of periapsis kicks at the front end.
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
'dgatsoulis' , thanks very much for making the effort to draft your post. Detailed and comprehensive as always.

Whenever I read your contributions on this forum, I learn something new. Although I knew that 'gravitational losses' existed on some of these long burns, I hadn't realised that the gravitational losses would be as large as you have shown them to be. I had presumed that they would be of the order of 50 m/s or. Clearly not.

I look forward to reading the rest of the series.
 
Last edited:

mbartley

Member
Joined
Mar 26, 2008
Messages
66
Reaction score
0
Points
6
Wow, you're making me look bad.:thumbup: I just managed to reach orbit with ~2200 m/s left, but only after two flybys.

TJI burn (impulsive) = 6440 m/s, Burntime = 571.2 seconds. This burn is huge, covering more than 10% of a full orbit. Before continuing, I want to address this by figuring out the gravitational losses.
...
Unfortunately I don't know how to solve integrals, so I'll just plug it in to wolframalpha and get the result: 842 m/s.

In IMFD Orbit Eject, I typically change it from Realtime to Off-Axis. It's a pain though because it often doesn't work. I've found I have to set Off-Axis, quit Orbiter, then immediately restart the (Current state) scenario. Then Off-Axis will be working. Adjust the start-of-burn time to minimize the delta-V.

I found that the gravity loss penalty this way was about 100 m/s.

I need to setup my MCC with these characteristics:
Arrival @ Ganymede's distance from Jupiter, with the PeT being a multiple of Ganymede's orbital period around Jupiter.

That's the part I haven't managed yet. I'll keep trying. I'm also not sure yet when to use Adaptive=On vs. Adaptive=Off in IMFD Map.

Directly intercepting Ganymede has the advantage of minimizing flight time and radiation exposure (keeping distant from Jupiter).

Welcome to Low Ganymede Orbit. ΔV left: 3254 m/s

It also doesn't seem to have hurt delta-V requirements. Perhaps flying straight into Ganymede's gravity well is a good Oberth effect in and of itself.
 

dgatsoulis

ele2png user
Donator
Joined
Dec 2, 2009
Messages
1,927
Reaction score
340
Points
98
Location
Sparta
'dgatsoulis' , thanks very much for making the effort to draft your post. Detailed and comprehensive as always.

Whenever I read your contributions on this forum, I learn something new. Although I knew that 'gravitational losses' existed on some of these long burns, I hadn't realised that the gravitational losses would be as large as you have shown them to be. I had presumed that they would be of the order of 50 m/s or. Clearly not.

I look forward to reading the rest of the series.

Thank you for the kind words. I feel a bit uncomfortable with the calculation of the 'grav.losses' because I get the answer from wolframalpha without having any way to check if it's right, or even if my inputs were correct.

The test with IMFD and BurnTimeCalcMFD showed that the result was near the expected value, but as 'mbartley' already said, IMFD has a built in way to deal with these long burns.

In IMFD Orbit Eject, I typically change it from Realtime to Off-Axis. It's a pain though because it often doesn't work. I've found I have to set Off-Axis, quit Orbiter, then immediately restart the (Current state) scenario. Then Off-Axis will be working. Adjust the start-of-burn time to minimize the delta-V.

I found that the gravity loss penalty this way was about 100 m/s.

I've also run into the same problem of IMFD's 'Off-Axis' burn method being unreliable, so I use the Delta-velocity and Map programs with similar results.

That's the part I haven't managed yet. I'll keep trying. I'm also not sure yet when to use Adaptive=On vs. Adaptive=Off in IMFD Map.

From experience with flights to Jupiter, I've found that it's best to have the 'Adaptive' setting 'On'. The 'trick' was is that I didn't target the destination (in this case Ganymede) until the last 'moment' (~ 1 Ganymedian orbit away).
Up until that moment, I had Jupiter as the reference in the map, targeted the equator (Target: 'l' [the lower case letter L]) and timed my arrival in such a way that Ganymede would be there. (By making sure at each MCC, that my perijove PeT was a multiple of Ganymede's orbital period around Jupiter and getting the line of nodes exactly at perijove).

When I had doubts I also checked TransX. When the ship is deep inside the main body's gravity well, TransX's prediction is somewhat trustworthy.

Anyway, this is how I had a pretty good prediction from IMFD's Map, which resulted in keeping the total of my MCCs in the <100 m/s region.

Directly intercepting Ganymede has the advantage of minimizing flight time and radiation exposure (keeping distant from Jupiter).

Those are exactly the advantages of the direct flight. Using the Oberth effect will definitely result in delta-v savings, but they come with a cost in time.
The radiation exposure can be minimized by selecting a near polar arrival trajectory at Jupiter.
I'll be simulating this in the 2nd version of the flight. (see version#2 preflight calculations below).

--------------------------------------------------------------------------
Version #2

dgatsoulis said:
This version will make use of the Oberth effect, so there will be 4 main burns. TJI, capture burn at low Jovian altitude, Ganymede rendezvous setup at the apoapsis of the capture burn and finally the GOI burn.
The TJI itself will be broken down into a series of two or three periapsis 'kicks', in order to minimize gravitational losses. The first burn will need to take place about 3 days before the indicated July 11th 2011 date posted by the OP.

In an effort to avoid Jupiter's radiation belts, I'll arrive in an almost polar trajectory (eq. Incl: > 80°). This will cost ~150 m/s more than an almost equatorial arrival, during the Ganymede intercept burn.

p0_zps9sp4egb0.jpg


I am starting the scenario once again at a 300x300 km orbit, on July 11th 2011, and setting up a journey to Jupiter with IMFD's Target Intercept program.
In the last flight, I selected a plan with a departure Vinf of 9015 m/s and an arrival Vinf of 5655 m/s.
Since I'll be using the Oberh effect on arrival, I am not looking for the minimum arrival Vinf this time, so I'll try to lower my departure velocity a little bit.

p1_zpsxgrko1mh.jpg


Preflight calculations:

Starting from the end again.
Arrival Vinf = 5656 m/s → PeriJove Vel (1300 km alt) = 59918 m/s → Capture dV (for an ApA of ~29e6 km) = 341 m/s > Plane alignment & Ganymede Intercept burn (combined) = 550 m/s
Ganymede arrival Vinf = 4231 m/s → PeV = 5036 m/s → GOI burn @20 km alt = 3105 m/s

The ApoJove altitude of the capture burn has been selected so that it adds ~1 year to the total flight time of the mission.

Earth departure Vinf = 8966 m/s > TJI burn = 6408 m/s

Budget: 14630 m/s
TJI: 6408 m/s + ~50 m/s in grav. loss
Jupiter Capt = 341 m/s
Ganymede Intercept = 550 m/s
GOI = 3105 m/s
1% room for error ~ 105 m/s
Total ΔV = 10559 m/s (round it to 10.6 km/s)

I should be able to make it to Ganymede with ~4 km/s of ΔV still left in the tanks.

----------------------------------------------------------------------------------------------------------------------------------------------------

TJI burn periapsis 'kicks'

This time, I'll use a series of 4 periapsis 'kicks', in order to minimize the gravitational losses of the injection burn. The first 3 will be to raise my apoapsis and the last one to escape Earth. Obviously, I can't simply divide the total burn by 4 and use 6408/4 = 1602 m/s for each 'kick', because by the end of the second one, I'll already be escaping Earth.
So, I need to make sure that the sum of the first 3 burns is lower than the escape velocity for this altitude (3202 m/s). I'll go for a total of 3030 m/s in the first 3 burns (1010 m/s each), leaving me with 3378 m/s for the last one.

Calculating the total time for the first 3 burns:

Burn #1: PeV = 7730+1010 = 8740 m/s, PeA = 300 km, ApA = 5447 km, T = 8846 seconds
Burn #2: PeV = 8740+1010 = 9750 m/s, PeA = 300 km, ApA = 19575 km, T = 20727 seconds
Burn #3: PeV = 9750+1010 = 10760 m/s, PeA = 300 km, ApA = 201000 km, T = 348429 seconds
Total T = 378002 seconds = 4.375 days.

I should start my first burn 4 days and 9 hours before the time of the TJI burn.

----------------------------------------------------------------------------------------------------------------------------------------------------

Accounting for nonspherical gravity:

(the effects of nonspherical gravity on this eject plan should be quite small, but I'll include the calculation here for those interested)

Nonspherical gravity causes two main perturbations to my spacecraft's orbit. https://en.wikipedia.org/wiki/Nodal_precession which causes the LAN to "drift" in a direction opposite to the spacecraft's orbit and https://en.wikipedia.org/wiki/Apsidal_precession which causes a similar "drift" in the argument of periapsis. The rate of these "drifts" can be calculated by:

[math]\frac{\partial \Omega}{\partial t}\;=\;-\frac{3n}{2}\left(\frac{R}{a}\right)^2\frac{cosi}{(1-e^2)^2}J_2[/math]
[math]\frac{\partial \omega}{\partial t}\;=\;\frac{3n}{4}\left(\frac{R}{a}\right)^2\frac{5cos^2i-1}{(1-e^2)^2}J_2[/math]
[math]n=\frac{2\pi}{P} [/math]where,
P = orbital period
R = Earth's Mean Eq Radius (6371.01 km in Orbiter)
α = Semi-major axis
i = inclination
e = eccentricity
J2 = the body's second dynamic form factor (1.0826269 x 10^-3 for Earth in Orbiter)

Source: OrbiterRoot\Doc\Technotes\gravity.pdf

First, I need to see what my Incl., LAN and AgP need to be at the time of the TJI burn (July 11th 2011, 13:42:06 UT).

p2_zpsmxtdmxkz.jpg


LAN = 317.28°, AgP = 262.02°

(The TrL will be my AgP after the first "kick".)

Now I have everything that I need to calculate the LAN and AgP drifts:

Burn #1: Incl = 13.81°, α = 9244.51 km, e = 0.2784, T = 8846 secs LAN = -0.317° AgP = -0.046°

Burn #2: Incl = 13.81°, α = 16308.51 km, e = 0.5909, T = 20727 secs LAN = -0.205° AgP = -0.030°

Burn #3: Incl = 13.81°, α = 107021.01km, e = 0.9377, T = 348429 secs LAN = -0.138° AgP = -0.020°

Total LAN drift = -0.66° → R.Inc to parking orbit: 0.16° , Total AgP drift = -0.096°, T of parking orbit = 5422 secs, T to 1st burn correction = 0.096°/360° * 5422 = 1.45 seconds

(both effects are negligible, so I'll just account for the time to the TJI burn in my start scenario)
--------------------------------------------------------------------------

My start scenario is as follows:

Date: July 7th 2011, 04:37:06 UT (5 minutes before the 1st burn)
SMa: 6671.01 km
e = 0.0
Eq.Incl: 13.81°
LAN = 317.28°

I'll continue with the actual flight sometime later today.
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
I feel a bit uncomfortable with the calculation of the 'grav.losses' because I get the answer from wolfram alpha without having any way to check if it's right, or even if my inputs were correct

Most people, even those well-trained in the arcane art of integration, will use WolframAlpha or its equivalents to calculate the integral. Very few people these days, will go to the effort of calculating their own integrals from 'first principles'. The real 'value-add' in integration is in making sure that the thing you are integrating makes sense. The actual integration itself is a mechanical task that can be happily left to a computational aid.

The problem I still struggle with computing in Orbiter is:

a) the effect of solar perturbations on the spacecraft's trajectory after the initial JOI ("Oberth") burn. Because the spacecraft moves well out towards the edge of the Sphere of Influence, solar contributions become non-negligible. Now, I can use a full n-body integrator to calculate these effects, but it a bit likening a sledge-hammer to crack a nut (it works, but its overkill). What I need is more straightforward analytical approximation to the solar contributions so that I can more precisely calculate the resulting orbit after the JOI burn.

b) the "three-body" effects that occur in the vicinity of the Galilean moons. Because, the Galilean moons - particularly Io and Europa - orbit Jupiter so rapidly, using a simple patched-conics approximation for calculating the trajectories of a spacecraft in the vicinity of a Galilean moon - particularly the departure trajectory of a spacecraft after a close encounter with one of the moons. During the encounter, the moon moves through a substantial arc in its orbit, and forces attributable to the Jupiter's gravitational field distort the normal 'hyperbolic trajectory' assumption. Again, I can calculate these effects using an n-body integrator, but what I really need is a more simple analytical calculation of the perturbative effect of Jupiter on the spacecraft so that I can calculate appropriate approach altitudes more effectively.
 
Last edited:
Top