
Tutorials & Challenges Feel free to publish your tutorials, challenges, & flight scenarios in this forum. 

Thread Tools 
Callisto Challenge
by Keithth G 05082015, 10:15 AM
OK, here's a little challenge that people may find interesting:
Using the following QuickSave scenario, take the Delta Glider that has just entered the Jovian SOI enroute from Earth (and which is low on fuel) and enter into a 20 x 20 km parking orbit around Callisto. This sounds simple  but it probably isn't. Code:
BEGIN_DESC Orbiter saved state at T = 365 END_DESC BEGIN_ENVIRONMENT System Sol Date MJD 54570.3107363040 END_ENVIRONMENT BEGIN_FOCUS Ship GL02 END_FOCUS BEGIN_CAMERA TARGET GL02 MODE Cockpit FOV 39.79 END_CAMERA BEGIN_HUD TYPE Orbit REF Sun END_HUD BEGIN_SHIPS GL02:DeltaGlider STATUS Orbiting Jupiter RPOS 17098535388.37 1494939144.23 13618786714.34 RVEL 5534.188 480.332 4162.163 AROT 178.39 52.55 178.40 AFCMODE 7 PRPLEVEL 0:0.074730 1:0.049963 NAVFREQ 2 466 0 0 XPDR 0 NOSECONE 1 0.0000 SKIN BLUE AAP 0:0 0:0 0:0 END END_SHIPS BEGIN_ExtMFD END BEGIN_VistaBoost END Last edited by Keithth G; 03062017 at 12:22 AM. 
Views 12499
Comments 17

Thanked by: 
05102015, 06:40 AM  #2 
Orbinaut

I wrote a small lua script for this challenge. Unzip the attached file in your Orbiter directory and run the "Callisto Challenge" scenario.
The script checks if you have completed the goal of the challenge (enter a 20x20 km orbit around Callisto) and returns you a score in DeltaV used and Time (in days, since the start of the scenario). For me, the hard part was not so much the inclination relative to Callisto, but the position of the line of nodes. In my first attempt I almost managed to make it, but I was missing another ~30 m/s of dv. I didn't like it very much. Spent too much time in the fringes of Jupiter's SOI and needed too many corrections. So, I tried a deltav and timesaving variation of the same method and voila: 
05102015, 08:25 AM  #3 
Orbinaut

Well done, 'dgatsoulis'. But, then, I had little doubt that you could do it.
Thank you for posting your results. At least this demonstrates that the challenge is achievable. And that you for writing the lua script. This is what I would have written (and posted) had I the competence to do so. As I am sure you recognise, the point of the challenge is to demonstrate that the Oberth Effect is a very efficient way of shedding inbound hyperbolic excess velocity. In the challenge, an initial hyperbolic excess velocity of around 6.05 km/s is reduced to essentially zero via a retrograde burn of around 0.3  04 km/s (depending on the apogee of the resulting orbit). Yes, the consequence of this is to throw the craft into a highly elliptical orbit around the parent planet  something that has both advantages and disadvantages. The first advantage is that it allows the craft to be slowed to very low speeds so that plane alignment with the moon (in this case Callisto) can be undertaken at low cost  thus ensuring a minimum final encounter velocity with Callisto. The second advantage is that it allows time to synchronise with Callisto's arrival at second perigee passage  again with low deltav cost  without having to worry too much about this at the start of the scenario when the craft arrives at the Jupiter system. As you note, the principal disadvantage of the method is that elliptical orbit may take the craft to the edge (or even beyond) the edge of the Jupiter SOI where the craft is subject to significant perturbations. These perturbations then lead to numerous corrections when using the standard planning tools of IMFD and TransX which struggle to cope with this somewhat extreme manoeuvre. This doesn't reflect a failure of the basic concept, per se, but rather that a clean implementation of the technique requires better trajectory targeting tools  both to align the nodes on Jupiter approach and to calculate a 'oneshot' burn at (or near ) apoapsis that avoids a series of messy (and expensive) correction manoeuvres on the return from apoapsis back to second periapsis. Last edited by Keithth G; 03062017 at 12:22 AM. 
Thanked by: 
05102015, 09:55 AM  #4 
Orbinaut

The main drawback of the 3 burns solution is time. Basically, you exchange time for deltav. If you notice the first pic, I made it to Callisto in 1.33 years after the scenario start. My Apojove after the first burn needed to be at about 19 times Callisto's orbital altitude around Jupiter (which is outside the "strong" Jovian SOI), if I wanted to have enough deltav for the rest of the burns. It took a lot of time and 4 corrections to get it right.
In the second attempt I tried the aerocapture variation of the 3 burns solution. I dived into Jupiter's atmosphere just enough so that I would shed the hyperbolic excess velocity without having to actually perform a burn. The advantage was that I could now use the saved deltav to select a much lower apojove for the second burn, resulting in a lot of time saved (completed in only 168.3 days since scenario start). 
Thanked by: 
05112015, 09:36 AM  #5 
Orbinaut

An elegant solution!
 Post added 051115 at 09:36 AM  Previous post was 051015 at 11:22 AM  And, for what it is worth, here is my effort (without aerobraking): A considerably longer journey than dgatsoulis'  but just to show that aerobraking isn't necessary. Last edited by Keithth G; 03062017 at 12:22 AM. 
Thanked by: 
06032015, 07:11 AM  #6 
Orbinaut

Above is a screenshot of another successful completion of this "Callisto Challenge". Although, as some of you may have discovered, it is not always a rivetingly interesting exercise, it does show case an additional (and generally low deltav) method of orbit insertion around a moon of a planetary body. Moreover, it is an exercise in technique, knowhow and control. This particular successful completion is not noteworthy because of the low deltav score but, rather, because of the rather long time (601 simulation days) that it took to achieve orbit insertion. This is nearly four times as long as it took 'dgatsoulis' to complete the same challenge (see preceding posts). Why did it take so long? Well, for the simple reason that, as a navigation test, after first perijove (a mere 30.5 simulation days into the exercise) I decided to set the Delta Glider into a very elliptical orbit with an apojove of 50 million kilometres and an extended foray into the gravitational 'badlands' between the Sun and Jupiter where the two bodies compete for gravitational dominance and where the assumption of 2body motion begins to break down badly. So, how far is 50 million kilometres? The Earth orbits the Sun at a mean distance of around 150 million kilometres. So, 50 million kilometres is 1/3 of the distance of between the Earth and the Sun. It is as if, on approach to Earth, one decided that it would be a good idea to drop down to Venus, snuffle around there for a year or so, before returning to Earth for orbit insertion around the Moon. It's a long way and it takes a long time to complete the loop  particularly given that at apojove, the Delta Glider is moving little faster than a family car driving along a freeway. At these distances from Jupiter, every little bump and wrinkle in the gravitational field has a significant impact  an impact that it not noticed when travelling through this region of space at normal interplanetary speeds. And none of this would be at all interesting if it were not for the fact that to navigate successfully (without racking up a huge midcourse deltav tally to make corrections for all of the nbody perturbations encountered along the way) one needs a good navigational aid. For this purpose, neither TransX nor IMFD are of much help. To overcome this limitation, I resorted to building my own navigational instrument  essentially an nbody symplectic integrator with a targeting mechanism built in. With it, I can say: given that I am 'here' now and I given that want to get 'there' on a particular date, how do I need to change my velocity now  bearing in mind that I have a complex gravitational field to navigate through between 'here' and 'there'. (This is more or less what TransX and IMFD are designed to do, its just that neither is of much help way out in the gravitational 'badlands'.) Rather gratifyingly, at 50 million kilometres out (i.e., at Jovian apoapsis), I can now target Callisto one year in the future and reasonably expect to arrive within a few hundred kilometres of Callisto on the appointed arrival date. One burn at apojove; sit back for one simulated year; and then arrival at Callisto. (Well, strictly speaking I allow myself one mid course correction of 5 m/s at 30 million kilometers out from Jupiter. And there is the inevitable tinkering to ensure that one arrives at Callisto exactly 20 km above the surface. But this is very small in comparison with the hundreds of m/s of delatv required to complete course corrections using IMFD and TransX.) So, the above screenshot marks the successful completion of a long mission using this navigational tool. At the moment, the navigational tool is a prototype tool and has been for personal use. The work flow is simple: it uses a lua script to take snapshot of the position and velocities of relevant gravitating bodies; it integrates forward their motion for as long as required; it uses a general purpose function minimisation software to plan the trajectory; and then once the optimal deltav requirements have been identified using the minimisation software, the Delta Velocity program in IMFD is then used to set up a 'burn' which is then executed in the usual way within Orbiter. I can imagine that such a tool may be of interest to others and so I shall probably embark upon a slow process of converting the prototype into something that other can use. Last edited by Keithth G; 03062017 at 12:22 AM. 
Thanked by: 
06062015, 05:45 AM  #7 
Orbinaut

Ok, another successful completion of this Callisto Challenge. It happens to be my most efficient attempt to date  and one that makes use of some new trajectory planning tools that I've put together  but that's not the point. What I want to do here is use this mission to make a point  about what it takes to enter into orbit around a planetary moon when on a low deltaV budget. A bit of a recap Before going on to make the point, its worthwhile briefly reiterating a few key themes that underpin this challenge. In essence, the Callisto Challenge is intended to be a way of practicing the "three burn" approach of orbit insertion. Here, we use Callisto as the moon, and Jupiter as the planet, but the concept of the "threeburn" approach has wide applicability for entry into orbit around the Moon, or even Phobos and Deimos. And, again, the whole point of the "threeburn" approach is to save deltaV (at the expense, though, of a considerable increase in the amount of time needed to achieve orbit insertion around the target moon.) The following picture captures the essence of what the "threeburn" solution: In the above diagram, Jupiter is located at the origin of the coordinate system (i.e., at the point (0,0). The red line indicates the orbit of Callisto. The blue line, which starts from the lower left of the diagram, represents the Delta Glider approaching the Jovian system with a hyperbolic excess velocity of around 6 km/s. Because the Delta Glider starts out moving fast, and because it continues to accelerate as it dives into Jupiter's gravitational well, any direct encounter with one of the four Galilean moons  Io, Europa, Ganymede and Callisto  is necessarily a high speed one. A direct orbit insertion around any of these moons takes a large retrograde burn. Because it is moving the slowest, Callisto is the easiest of the four moons to approach. Io, on the other hand, is a long way inside Jupiter's gravitational well and it is the hardest to approach. Reducing deltaV So, to reduce the final encounter velocity with the target moon, Callisto in this case, we resort a series of manoeuvres designed to slow the Delta Glider down, and give us sufficient to line ourselves up so that we can have a low velocity rendezvous with Callisto. There are three basic steps:
Hence, as the name implies, the "threeburn" method has three main burns. The above diagram represents the approach in two dimensions. In practice, orbital insertion is a threedimensional problem and the full procedure requires two more important steps: A. One of the principal tasks that the three burn method requires is an alignment the 'line of nodes' of the DeltaGlider and Callisto so that we arrive at Jupiter periapsis at a point that lies on the line of nodes. (The line of nodes is just the line of intersection between two orbital planes.) This alignment ensures that after we have completed our retrograde burn at periapsis, our new orbital apoapsis will also lie on the line of nodes  and so too will our new periapsis once we have completed a largely prograde burn at apoapsis. And all this to create a situation in which: a) we have a rendezvous with Callisto; and b) that the encounter velocity with Callisto is as slow as possible. To align the line of nodes with our periapsis, and when we are still at some distance from Jupiter, we have to rotate our orbital plane so that the line of nodes coincide with orbital periapsis. Upon starting this challenge, this task has the highest priority. B. Now, aligning the line of nodes in this way means that we rotate the DeltaGlider's orbit out of Jupiter's orbital and equatorial planes. In fact, we end up with an orbit that is highly inclined with respect to Callisto's. In the Callisto Challenge, and after we have completed this manoeuvre, Orbit MFD shows that the Delta Glider is 24 degrees out of plane with respect to Callisto. At some point, we have to rotate our orbit plane once again, so as to preserve the alignment of the line of nodes, but also to reduce the inclination of the Delta Glider's orbit relative to Callisto. This a burn we undertake at apoapsis and, as 'dgatsoulis' has suggested elsewhere, it is efficient to combine this plane alignment task with the prograde burn needed to raise orbital periapsis to Callisto's orbital radius. A comparison with theory OK, so that's a bit of background on what this challenge is all about. Now, the first image of this post shown above is that of a successful completion of the challenge. All good. But what I thought I would look at is a comparison of a breakdown of mission deltaV costs against what theory suggests it should be. The following table gives the breakdown of actual deltaV costs for this mission and compares them with the 2body theoretical values. This table breaks up deltav expenditure into a number of basic tasks that need to be carried out in order to successfully complete this mission. First, we have the alignment of nodes. Now, I have developed a little widget that can tell me exactly by how many degrees I need to rotate the DeltaGlider's orbital plane in order to have the Jupiter periapsis lie on the line of nodes with Callisto. From this, I can work out exactly how much deltav it takes to achieve this burn. And to cut a long story short, I can tell you that I need exactly 88.53 m/s to rotate the achieve the correct node alignment. Now, in practice this manoeuvre costs a little more because I find it expedient to engage the 'Normal ' autopilot to execute this burn  and using the autopilot 'costs' an additional 0.2 m/s. Such is life. Second, I set my target apoapsis altitude is 30 million km. The 2body theory says that this should be 388.7 m/s. However, I can use my trajectory planning tools to show that because largely of perturbations from the Sun, I actually only need a retrograde burn of 385.0 m/s. Third, at apoapsis, my trajectory planning tools estimate that a largely prograde burn of 572 m/s is needed to: a) raise the Delta Glider's periapsis, b) synchronise rendezvous with Callisto, and c) get into plane alignment with Callisto. Twobody theory suggests that this should cost 585.9 m/s. The actual deltaV requirement here is less than theory because, again, perturbations from the Sun influence our return trajectory. Fourth, the actual flight required one midcourse correction of 1.9 m/s. Frankly, I find this a little large and have yet to track down why it isn't smaller  say 0.2  0.3 m/s or so. Theory, of course, has no use for midcourse corrections. Fifth, on 'Callisto final approach' we need to fine tune our arrival altitude and orientation. For these tasks, I 'spent' 5.7 m/s. Of this, around 4.5 m/s was spent on a plane adjustment so that my arrival inclination at Callisto was near equatorial. (In principle, this expenditure wasn't strictly necessary and amounted to little more than orbital housekeeping.) This left around 1.2 m/s to ensure that Callisto periapsis altitude was 20 km. Again, I find 1.2 m/s a little disconcerting and this reflects some inaccuracies in my trajectory planning tools. Still, not bad  but there is room for improvement. Sixth, orbit insertion around Callisto. In practice, it took roughly 30 m/s more fuel than theory would suggest to enter orbit around Callisto. Why? Well, I can think of two likely reasons: the theory assumes that Callisto orbits around Jupiter in a circular orbit  it doesn't, so its orbital speed varies; and my approach angle to Callisto may have been off by a fraction of a degree. Seventh, orbital fine tuning. This reflects a blunder on my part. Due mainly to laziness and an over reliance on autopilots, I was forced to spend 4 m/s correcting some imperfections in the autopilot's best attempt to insert the Delta Glider into a 20 x 20 km orbit. Overall, this table shows that there really isn't much 'fat' left in the deltaV budget for this mission. I may be able to eek out an extra 20 m/s or so by correcting a few things, but one quickly finds that one is hitting up against the buffers of physical reality. The gorilla in our midst Does this mean that one can't do better than, say, 3,200 m/s in getting into orbit around Callisto. Yes, I would say that's about right for this challenge if one is focusing purely on the "threeburn" approach. It is an improvement in deltaV terms over other, more basic orbital insertion methods  but it is still not optimal. Having gone through the the breakdown of deltaV costs, (and now we come to the point of the tale) it is clear that the 400 lb gorilla in the room is the cost of Callisto orbit insertion. At 2,200 m/s this is by far and away the largest deltaV budget item. The large deltav is a direct function of our approach speed to Callisto. In this challenge the Delta Glider's approach speed is around 3,000 m/s. But what if we can reduce this to only 1,000 m/s (or even less). If we could do that, we could save upwards of 1,300 m/s on mission deltaV requirements. So the question is: can we do anything to further reduce our Callisto approach speed? The answer is, of course, yes  so long as we are prepared to accept a further time delay of one or more ballistic breaking encounters with Callisto before, finally, inserting into orbit around Callisto. (A ballistic braking encounters is simply a 'flyby' of the moon in which some of kinetic energy is transferred from the craft to the Moon. Repeated encounters progressively slow the craft.) And all of this raises the question: in Orbiter, how can one design and execute a series of repeated ballistic braking encounters with a moon (or even a planet) to reduce orbital speed prior to orbit insertion. And it is to this question that my thoughts now turn  and the subject, no doubt, of future threads. Last edited by Keithth G; 03062017 at 12:22 AM. 
Thanked by: 
06062015, 04:42 PM  #8 
Orbinaut

Very cool to see that the navigational aid you've been working on allows for such precision in the trajectory prediction.
Quote:
Stage1→"Target body"→FW Stage2→"Escape"→FW Stage3→"Target body" (Orbits to Icept > 0.0) Quote:
A tangential arrival at Callisto with V∞ ~ 3 km/s which requires ~2.2 km/s for orbit insertion. You have half of that in your tanks. Off to set it up in Orbiter. 
06062015, 05:49 PM  #9 
Orbinaut

And here it is. I decided to start with a budget of 2000 m/s (60 kg RCS included), so it's only slightly less than what's needed for a direct orbit insertion.
Let's see what can be done from this starting point. Unzip the attached file in your Orbiter directory and run the "Callisto ChallengeII" scenario. Script included. 
06082015, 12:44 AM  #10 
Orbinaut

Hi, 'dgatsoulis'
Thanks for the posts and challenge. I have to focus on other things for a couple of days. But I will return to this topic soon. Last edited by Keithth G; 03062017 at 12:21 AM. 
06092015, 03:06 AM  #11 
Orbinaut

Hi, 'dgatsoulis'
I've a bit more time today, so a somewhat more considered response. Quote:
Quote:
Now, I don't want this note to turn into a tutorial on how to set up and execute these manoeuvres in IMFD  that I will reserve for a later date. But it is worthwhile outlining the basic scheme that (I think) allows for a simplified set of braking encounters to be orchestrated. This isn't an optimal (low deltav) trajectory design, but it does allow one to serialise the encounters so that you just have to focus on the next encounter before having to think about the next. To begin, though, it might be worthwhile summarising a few facts about these encounters  and the conditions that make one encounter a 'braking' encounter whereas other encounters (e.g., Grand Tour style slingshots) are ones that 'accelerate' a spacecraft. The answer has to do with approach and exit angles of the craft relative to the velocity vector of the body that you are encountering. If the angle of the craft's velocity vector on approach makes with the velocity vector of the moon/planet is less the angle it makes on departure, then the encounter will serve as a brake. If not, then, it will be an accelerating slingshot. One gets the maximum braking effect when the encounter angle on approach is zero. So, what happens when executes a braking encounter? Well, the Jovian periapsis of the craft's orbit after the encounter is pushed down a little bit; the apoapsis is also pushed down a lot; the eccentricity of the orbit falls; orbital period falls; and the orientation of the orbit rotates (typically by around 15  20 degrees for the first few encounters.) And how much speed is lost after each braking encounter? This depends on your approach speed. If your approach speed is very high, then the braking manoeuvre is not very efficient. As the approach speed falls, the efficiency increases rapidly. As a simplified example, consider an optimal 'braking' approach to Callisto with an orbital speed of a nominal 3,000 m/s. Encounter 1: Approach speed 3,000 m/s Encounter braking 271 m/s Perijove reduction 40,000 km Post encounter apojove 14.7 million km Post encounter ecc. 0.78 Encounter 2: Approach speed 2,729 m/s Encounter braking 335 m/s Perijove reduction 47,000 km Post encounter apojove 9.4 million km Post encounter ecc. 0.67 Encounter 3: Approach speed 2,349 m/s Encounter braking 453 m/s Perijove reduction 63,000 km Post encounter apojove 5.9 million km Post encounter ecc. 0.53 Encounter 4: Approach speed 1,941 m/s Encounter braking 625 m/s Perijove reduction 96,000 km Post encounter apojove 3.9 million km Post encounter ecc. 0.37 Encounter 5: Approach speed 1,316 m/s Encounter braking 948 m/s Perijove reduction 150,000 km Post encounter apojove 2.4 million km Post encounter ecc. 0.17 Encounter 6 (and rendezvous): Approach speed 368 m/s In this scheme, after each encounter one has to expend deltav on order to lift periapsis back up to the Callisto's orbital radius. The cost of raising the orbital periapsis after each encounter can become quite significant. For the first few encounters, though, the cost is around 30 to 50 m/s How does one coordinate a series of encounters? Not only does one have to lift Jovian periapsis, but one also needs to coordinate one's arrival at the new periapsis with that of the target body (i.e., Callisto). The easiest way of doing this is to adjust the approach altitude to Callisto. This serves as a throttle and controls both apoapsis and the orbital period of the post encounter orbit. In principle at least, it is quite an easy thing to set up the timing correctly by adjusting the approach altitude. But solar perturbations throw "Target Intercept"'s calculations way off leading to large deltav course correction costs. Anyway, that's a brief summary of where my thinking has taken me so far. All of this is quite implementable within Orbiter using IMFD  and I've done it  but the overall result isn't great because of large course correction costs. A better trajectory planning tool is needed. I will write up some more detailed notes on this in the Maths and Physics section  but not today. Last edited by Keithth G; 03062017 at 12:21 AM. 
Thanked by: 
07082015, 03:35 PM  #12 
Orbinaut

Earlier in this thread (see above), dgatsoulis posted a challenge (Callisto Challenge II) in which a Delta Glider is inbound towards Callisto with an approach speed of approximately 3.0 km/s relative to that moon. The goal is to achieve a 20 x 20 circular orbit around Callisto. At that approach speed, achieving that orbit requires 2.2 km/s of deltav. However, the Delta Glider only has 2.0 km/s. The challenge, then, is to execute a series of manoeuvres that get around this conundrum.
Here (below) is the screenshot of successful completion of that challenge in which 1.9 km/s of was used to achieve the prescribed circular orbit. Only standard Orbiter MFDs were used: IMFD, BurnTimeCalculator, Orbit and Align Plane. OK, so how was this done? Basically, by setting up a series of 'gravity deassist' encounters with Callisto. With each encounter, energy is transferred from the Delta Glider to Callisto and, eventually, the Delta Glider slows to the point where it can achieve the required circular orbit. Although roughly 200 m/s is shaved off the DeltaGlider's approach speed, a good chunk of these energy savings is 'spent' on a series of mid course corrections. Most of these corrections  roughly 150 m/s for each lap around Callisto  are to correct for the inaccuracies of the standard planning tools which don't account well for perturbations induced by the Sun. With better planning tools, it would be possible to save around another 400  500 m/s  i.e., achieve a circular orbit with, say, just 1400  1500 m/s of deltav. Moreover, I terminated the gravity deassist sequence at the first one that permitted the Delta Glider to complete the challenge by going around one (or even two) more laps, would have realised significant further savings because the energy transfer process becomes very much more efficient at lower approach speeds. I may have another go at this challenge at a later date just to see how low one could drive the deltav use and still achieve the 20 x 20 circular orbit. However, that will have to wait for another day. Last edited by Keithth G; 03062017 at 12:21 AM. 
Thanked by: 
07232015, 04:45 PM  #13 
Orbinaut

After an initial attempt that barely made it dVwise and was in the +350 days wrt time, I managed to find a method that worked, using IMFD's map program, Target Intercept (with offset) and a quick spreadsheet to calculate the resonance of the ship's and Callisto's orbits after each pass. The result was quite good.
Major improvement in both time and deltav. Like Keithth G, I could have saved even more if I was willing to take another couple of spins around Jupiter, but it is also possible to use the gravity deassists to get even further in Jupiter's gravity well. I don't see why a 20x20 km orbit around Europa can't be achieved using the exact same setup. Sure the corrections will be costlier further in, but I think it can be done. I'll set up a lua script when I get the chance. 
09122015, 05:47 AM  #14 
Orbinaut

Well, after a considerable amount of careful thought and analysis, here is my (proposed) trajectory solution for dgatsoulis' "Callisto Challenge II':
For those not familiar with this challenge, the goal is to carry out manoeuvres so as to get a DeltaGlider into a 20km x 20km parking orbit around Callisto within a fuel budge of 2,000 m/s. The challenge starts out with a DeltaGlider 0.8 days out from Callisto but with an initial circularisation cost of 2,200 m/s. A number of gravity deassists and other manoeuvres need to be carried out to shed energy before Callisto orbit entry and circularisation can be attempted. My trajectory solution takes 811 (simulated) days to complete (a long time!) but results in a total deltaV of 1156 m/s of which 872 m/s is needed for the final orbit entry and circularisation burn. This is represents a fuel saving of around 1,050 m/s. Can this trajectory be set up and completed in Orbiter? Yes, absolutely! Having painstakingly constructed the mission plan, 'flying it' in Orbiter is next on my 'to do' list. VILMs The trajectory is base upon a sequence of manoeuvres known as VILMs ("VInfinity Leveraged Manoeuvres") and are an accepted part of the mission planner's toolkit for solving the "Endgame" problem  i.e., working out low deltaV approaches to the moon's of planetary systems such as Jupiter after having made the Hohmannstyle transfer from Earth. The 'VInfinity' part of the title refers to the hyperbolic excess velocity of approach to a moon (in this case, Callisto); and the 'leveraged' bit refers to the fact that a small amount of deltaV required as part of the manoeuvre  usually at or near apoapsis  that has a much larger (leveraged) impact in the reduction of the approach speed to the target body, Callisto. A schematic of a VILM is given below: (This was copied from a 2010 paper "The Endgame Problem Part A: VInfinity Leveraging and the Leveraging Graph" by Campognola & Russell. Together with its twin, "Part B", these papers provide interesting reading for anyone interested in the technical details of this subject.) The key part of the VILM is easy to understand: an incoming trajectory is set up so that it arrives at the target body tangentially  i.e., from directly 'behind' Callisto as it traces out its orbit around Jupiter. The encounter with Callisto, then 'bends' the spacecrafts trajectory and sends it out again on a wide elliptical trajectory. This periapsis of this new trajectory is lower after the encounter than it was prior to the encounter. So, at (or near) apojove, a small amount of prograde deltaV is used to 'lift' the orbital periapsis up to where it was before the encounter. If one gets the timing of these manoeuvres correct, when the craft next reaches periapsis it will again encounter the target body, Callisto, but this time with a much lower approach speed. Overall, the ethos of the manoeuvre is "spend a little to get a lot". The trajectory plan So, my trajectory plan has been designed as a sequence of seven VILMs. Each one requires spending a little at apoapsis to lift orbital perapisis to reset the machine, and the result is a steadily decreasing sequence of approach speeds: On the first approach, at the start of the scenario, the hyperbolic excess velocity (approach speed) is 2,980 m/s. By the end of the VILM sequence, this has fallen to 921 m/s  i.e., a cumulative reduction of 2,059 m/s. Each VILM, then, has reduced the approach speed by around 300 m/s. This reduction doesn't quite translate into the same reduction in Callisto periapsis velocity. This starts out at 3,911 m/s (for a 20km approach attitude) at the first encounter in the challenge, but has reduced to 2,603 m/s (20km altitude) by the final encounter  i.e., an average reduction of around 200 m/s for each VILM in the sequence. Bearing in mind that Callisto's escape velocity is 2,434 m/s, this final periapsis velocity is just 169 m/s faster that Callisto's escape velocity  so, it would be difficult to reduce fuel costs much further. We can also calculate the reduction in magnitude of the circularisation burn needed at each encounter. This falls from 2,190 m/s down to 872 m/s by the end of the VILM sequence. The minimum it could ever be (using 2body physics, anyway) is 713 m/s which reflects the circularisation cost of a body that is just outside of Callisto capture. In total, then, the VILM sequence has reduced the circularisation cost by 1,318 m/s. VILM midcourse corrections Overall, the trajectory plan requires that 285 m/s of deltaV be spent on course corrections. Of this, 258 m/s are a series of burns executed close to apoapsis of each of the VILM manoeuvres. The remaining 27 m/s is the cumulative cost of a set of corrections incurred two days out from each Callisto encounter needed to set up the next VILM sequence. (Strictly, speaking, this 27 m/s isn't necessary  it just reflects a trajectory that has not been fully optimised  but what the heck, I can live with the additional 27 m/s.) Resonances The VILM sequence works by exploiting resonances between the orbital period of the spacecraft and that of Callisto. What does this mean? Well, to get a sequence of encounters, Callisto has to orbit Jupiter an integer number of times while the spacecraft just does one much bigger loop around Jupiter. If Callisto orbits, say, 10.5 times in the time that the spacecraft takes to get back to periapsis, there will be no encounter. (Although, if it orbits twice, Callisto will have completed 21 orbits (350 days or so) and so this might result in a rendezvous. For the first VILM in the sequence, Callisto does 21 orbits while the spacecraft completes just one lap around Jupiter. By the sixth loop, this has fallen to a 2:1 ratio  Callisto completes two laps around Jupiter while the spacecraft completes just one. For the final loop, it isn't possible to go for a 1:1 resonance ratio  a ratio that would seem to be the next logical step. Instead, I have opted for a 3:2 ratio  i.e., Callisto completes there orbits while spacecraft completes two. Other options were available  e.g., 4:3; 5:3; 5:4 and so on  but 3:2 was the most obvious, and the easiest, one to calculate. Numerical Integration The calculation of this trajectory was carried out 'offline' using a bespoke numerical integrator built specifically to 'solve' this challenge. The integrator uses Orbiter's reference frame, its core ephemeris program (VSOP87 and GalSat), and relevant model parameters  e.g., gravitational constants and body masses. The key component, the integrator, has been detailed elsewhere in this forum in the "Maths & Physics" section. Anyone interested should refer to that. Code for the VSOP87 routines can be obtained online using an automatic code generator (http://www.neoprogrammics.com/vsop87...enerator_tool/). The GalSat routines I will post on this forum at a later date. Having 'testflown' a few of the VILM procedures of the trajectory plan in Orbiter I can vouch for the accuracy of the plan: Orbiter faithful reproduces (to within a few km) the predicted positions. So, although I have a mission plan set up and ready to go, I will need to make a number of tweaks to plan 'on the fly'. Overall, I'm pretty confident that the trajectory plan will reflect the 'real' trajectory when run through Orbiter. Time to fly Having designed this trajectory, time to put my money where my mouth is: I now just have to go and fly it. Last edited by Keithth G; 03062017 at 12:21 AM. 
Thanked by: 
01062016, 08:41 AM  #15 
Bug Crusher

Wasn't there a youtube video for this?
I had some time tonight and I wanted to watch, but I can't find it. 

Thread Tools  


Quick Links  Need Help? 