Challenge Europa Challenge

[dgatsoulis]

As a continuation from this challenge, I wanted to see whether an orbit around Europa can be achieved, using the exact same setup.

If you haven't visited that thread, this was the initial setup:

a Delta Glider is in-bound towards Callisto with an approach speed of approximately 3.0 km/s relative to that moon. The goal of the challenge is to achieve a 20 x 20 circular orbit around Callisto. At an approach speed of 3.0 km/s, achieving the required orbit requires 2.2 km/s of delta-v. However, the Delta Glider only has fuel for 2.0 km/s of delta-v The challenge, then, is to execute a series of manoeuvres that gets around this conundrum.

Now I am shifting the goalpost much further inside Jupiter's gravity well:

a Delta Glider is in-bound towards Callisto with an approach speed of approximately 3.0 km/s relative to that moon. The goal of the challenge is to achieve a 20 x 20 km circular orbit around Callisto Europa.

I also added a time limit, to make things more interesting. You have one year from the scenario start to meet the goal.

Unzip the attached file in your Orbiter directory and run the Europa Challenge scenario. Lua script included.

This time the script allows for a pick up from a save, so you don't have to finish the challenge in one session. It will take quite a bit of Jovian moon pinball to get this one right.

Good luck!

 

[Keithth G]

Thanks for putting this together, dgatsoulis.

I can envisage a mechanism by which this can be done - but the time constraint you have imposed may prove to be irksome.

I am busy at the moment working on other things but I will get around to looking at this more closely in the near future.

 

[dgatsoulis]

Thank you for starting this whole idea.
I learned a couple of things on the way, one of them being how to use IMFD's map in a way that tells me whether the ellipse of my trajectory has resonance with my target's orbit - no spreadsheet required. The "Time limit" in the map's configuration page is very useful.

I can envisage a mechanism by which this can be done - but the time constraint you have imposed may prove to be irksome.

It is quite doable with lots of time and delta-v to spare:

This is a mockup of all the orbits put together. It took four encounters with Callisto, two with Ganymede and then a medium sized maneuver (~200 m/s) to setup an encounter with Europa.

I got lucky in the Callisto to Ganymede transition; Ganymede happened to be in the right place to make it in the first pass. But even if it wasn't, the period of the trajectory was quite low by that time. It would only add a dozen days or so to get it in the next one.

I am busy at the moment working on other things but I will get around to looking at this more closely in the near future.

Looking forward to seeing your attempt on this one.

 

[Keithth G]

dgatsoulis, this really is very good - and very clever. Well done.

I'm pretty sure that your techniques are better than mine for solving this problem, but I think that our approaches share a number of common features:

1. one needs to use a quality numerical integrator to assess the numerous n-body perturbations encountered along the way. It isn't really sufficient, or at least very difficult, to rely upon patched conic techniques

2. one needs a mechanism for identifying (and implementing) resonances with the target moon(s). As you have indicated, the numerical integrator is a good tool with which to find them.

3. it is possible to implement manoeuvres in a serial - rather than parallel - fashion. There is no need to solve the whole of trajectory problem is one go: each step of the trajectory plan can be developed in isolation from the next.

I have in mind that there is a need to capture some of these ideas in a way that permits others to understand the basic principles behind these gravity de-assist sequences - and to show others how to use existing MFDs to perform them.

(There is a tendency to think that Orbiter is in some sense 'a toy'. Although it is used by many for recreational purposes, and one would never want to use it to send a real spacecraft anywhere, its core integration engine and ephemeris is surprisingly accurate and robust. There is no reason to believe that with it one cannot develop and implement some really quite complex, and really quite realistic, trajectory plans.)

 

[downloaderfan]

Gave this a shot & was able to come up with a solution to complete this challenge. (It's not nearly as good as dgatsoulis's, though)

Both IMFD & TransX(the tools which I use) were very unreliable as already mentioned in this thread.

Took the same 4 slings from callisto & 2 from ganymede without any additional maneuvers.

I'll just post the screenshots of the last 3 stages

Took about 268 days to complete the trip, with an encounter Pe velocity of 3218 m/s at europa, knowing that the orbital speed of a 20 km orbit around europa is about 1389 m/s, I'll have to do a burn of 1829 m/s delta velocity to get into an orbit around europa.

I made this plan after the second sling from callisto & you can see I only have 1620.8 m/s dv left, the remaining went into corrections so far. However, since my plan only requires slings & no additional maneuvers, in theory, it should be possible to complete the challenge using this plan. Just not practically using IMFD or TransX :huh::shrug::uhh:

 

[Keithth G]

Well done 'downloaderfan'. Not an easy challenge to complete. And the unreliability of IMFD/TransX certainly doesn't help. (Frankly, 'dgatsoulis' seems to work magic with IMFD. No idea how he does it.)

I have been musing about building a somewhat more reliable lua script-based tool with which to better implement the resonant orbits. If I can get it to work, it should make executing these manoeuvres more straightforward.

 

[downloaderfan]

Well done 'downloaderfan'. Not an easy challenge to complete.

Thanks

And the unreliability of IMFD/TransX certainly doesn't help. (Frankly, 'dgatsoulis' seems to work magic with IMFD. No idea how he does it.)

Truly commendable indeed :thumbup:

I personally find 2 problems with IMFD,

1) It's map program cannot be used to watch our position multiple slings in the future.
2) It's sometimes very accurate, barely fluctuating as our journey progresses, but then, after a few slings, it can get very inaccurate & fluctuate even more than TransX.

The video below is a part of my ultimate great grand tour, specifically while I was returning to earth from mars. Up until that point, which was EVMeVVVMa, IMFD was very accurate, but then after mars it started fluctuating violently, while transX was relatively stable. I've also shown the accuracy settings which I use(I think it provides best accuracy) at the beginning of the video.

https://vid.me/GuiH

This just leaves me confused in the end, as to which program to trust in certain scenarios.

I have been musing about building a somewhat more reliable lua script-based tool with which to better implement the resonant orbits. If I can get it to work, it should make executing these manoeuvres more straightforward.

That would be really awesome and make things much easier & tolerable.

 

[Keithth G]

The video below is a part of my ultimate great grand tour journey, specifically while I was returning to earth from mars. Up until that point, which was EVMeVVVMa, IMFD was very accurate, but then after mars it started fluctuating violently, while transX was relatively stable. I've also shown the accuracy settings which I use(I think it provides best accuracy) at the beginning of the video.

I use much the same IMFD settings as you - and I encounter much the same problem.

Part of the problem is, I think, that IMFD simply can't do the numerical integration of the trajectory fast enough to keep up with the demands of a real-time simulator - particularly when time acceleration is set to high values - e.g., 100,000 X.

---------- Post added at 03:45 AM ---------- Previous post was at 12:40 AM ----------

As a quick addendum, a short video to demonstrate the potential of accurate n-body integrators for trajectory planning in Orbiter 2010:

https://youtu.be/qxtsVRwq7U0

An offline integrator is used to calculate a ~15 day trajectory for a spacecraft to intercept Callisto in a retrograde orbit, 'in plane' with Callisto's orbit around Jupiter, and with a periapsis altitude of 20.00 km. The starting values for the trajectory are inserted manually into Orbiter using the Scenario Editor. Orbiter is then run with no MCCs. Orbiter calculates that the spacecraft arrives (more or less exactly) in plane, and with a periapsis altitude of 19.88 km - just 120 m shy of the target.

 

[boogabooga]

Seems then that there is a need for either a better n-body planning map in Orbiter, or perhaps a utility that navigates via comparison to a predetermined ephemeris. :hmm:

Could you please post the scenario.

 

[Keithth G]

Could you please post the scenario.

I'm not sure to whom this request is addressed, but if the scenario of my video is as follows:

MJD 57930.0000

Position and velocity wrt the Sun (Orbiter 2010 coordinates)
X: -744124548692.448 m
Y: +18184724000.0739 m
Z: -327593490343.857 m

VX: +630.591197919803 m/s
VY: -117.220793095668 m/s
VZ: -10961.6756100409 m/s

Not all of these digits are significant, of course, but the easiest thing is to do a cut and paste of these values rather than to make the decision about where to round.

A few notes:
1. To set up using the Scenario Editor, always 'Pause' Orbiter before amending the date and state vectors. 'Unpause' only after all of the updates have been entered.

2. Turn off non-spherical gravity sources. Although I could model non-spherical gravity sources, I don't usually bother to model them in my 'offline' numerical integrator. This is sheer laziness on my part.

3. Set the 'Error Limit' for all planets and the Sun in the .cfg files to 10^-9. I use the full VSOP87 series in my 'offline' numerical integrations and, as far as I am aware, this forces Orbiter to do the same.

 

[boogabooga]

I meant post a .scn file like this:

BEGIN_DESC
Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 57930.0000000000
  Help Default\Checklists\Checklist1,Checklist1
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-01
END_FOCUS

BEGIN_CAMERA
  TARGET GL-01
  MODE Extern
  POS 3.70 -19.87 -25.78
  TRACKMODE TargetRelative
  FOV 50.02
END_CAMERA

BEGIN_SHIPS
GL-01:DeltaGlider
  STATUS Orbiting Jupiter
  RPOS 930078480.04 136836189.27 3920801108.86
  RVEL -4528.452 -48.836 369.797
  AROT 136.48 9.77 -156.54
  AFCMODE 7
  PRPLEVEL 0:0.269009 1:0.942856
  NAVFREQ 94 524 84 114
  XPDR 0
  RADIATOR 1 1.0000
  TRIM -0.028262
  AAP 0:0 0:0 0:0
END
END_SHIPS

BEGIN_ExtMFD
END

I leave non-spherical gravity on and don't mess with the config files. I get a final PeA of 42.18 km, which is perfectly reasonable IMHO.

Actually, I don't think that IMFD map is doing too bad. I don't see as wild oscillations as you do on the video. The mission starts about 2 weeks before arrival, and my predicted PeA is always within 400 km of the final value. Not bad considering the scale of the Jupiter system.

I am glad that you know how to make your own numerical integrator. Perhaps this shows that there is potential to use GMAT, STK, etc. for advanced mission planning that can be useful in Orbiter. However, it seems to me that over-reliance on an offline integrator defeats the purpose of Orbiter, which is real-time simulation. There is certainly better software out there for (semi) professional level trajectory design and optimization, and I have already listed two.

Thank you for providing a benchmark scenario, though. This will be useful for testing the effects of various IMFD map parameters. For example, I can try again with a higher order Rutta-Kunge scheme and see how this affects IMFD's accuracy. :hmm:

 

[Keithth G]

I am glad that you know how to make your own numerical integrator. Perhaps this shows that there is potential to use GMAT, STK, etc. for advanced mission planning that can be useful in Orbiter. However, it seems to me that over-reliance on an offline integrator defeats the purpose of Orbiter, which is real-time simulation. There is certainly better software out there for (semi) professional level trajectory design and optimisation, and I have already listed two.

I guess we all get something different out of Orbiter. My basic goal is to understand the theoretical underpinnings of various real-world missions (and then develop the tools with which to design and implement them in Orbiter). For this, Orbiter provides a rather unique 'first person' perspective.

The interrogators that I use are tailored to match Orbiter's somewhat idiosyncratic coordinate system and ephemeris structure. Other tools such as GMAT and STK use slightly different coordinate and ephemeris systems and, rather than convert, I simply build interrogators that are suited to Orbiter. I find this more satisfying, but I'm sure have other tastes in such things.

 

[downloaderfan]

I use much the same IMFD settings as you - and I encounter much the same problem.

Part of the problem is, I think, that IMFD simply can't do the numerical integration of the trajectory fast enough to keep up with the demands of a real-time simulator - particularly when time acceleration is set to high values - e.g., 100,000 X.

That may be true, but then again, it does work as expected sometimes,even at 100,000x as I've mentioned in my previous post.

Take a look at the video below, which is the same(ultimate grand tour) journey but this time I'm going from venus to mars. See the values of TransX & IMFD at the beginning & end of the video...TransX was just way off this time.

https://vid.me/Rel7

An offline integrator is used to calculate a ~15 day trajectory for a spacecraft to intercept Callisto in a retrograde orbit, 'in plane' with Callisto's orbit around Jupiter, and with a periapsis altitude of 20.00 km. The starting values for the trajectory are inserted manually into Orbiter using the Scenario Editor. Orbiter is then run with no MCCs. Orbiter calculates that the spacecraft arrives (more or less exactly) in plane, and with a periapsis altitude of 19.88 km - just 120 m shy of the target.

It is quite incredible & amazing that your numerical integrator can work with that amount of precision, that too in the Jovian system. Excellent work in there!!! :thumbup::tiphat:

Although I do wonder, whether it can predict our position multiple slings later??? Would that be too much to ask?? Please let me know....

TransX works fine for planning slingshots anywhere except the Jovian system. A few days ago, I posted this screenshot of my plan

Here the periapsis of my orbit has almost the same altitude as that of europa where it meets europa which is needed for a lower encounter velocity. I planned this after my second sling from callisto.

But after performing it, my rendezvous with europa was way off & I had to lower my orbit periapsis to approach europa, resulting in a much higher encounter velocity.

This happened mainly due to the amount of corrections I needed to do to get that far.

 

[Keithth G]

That may be true, but then again, it does work as expected sometimes,even at 100,000x as I've mentioned in my previous post.

Yes, I agree. On the whole, I like IMFD. It's just that sometimes I find its forecasts are a bit erratic. And this leads to excessive MCCs.

Although I do wonder, whether it can predict our position multiple slings later??? Would that be too much to ask?? Please let me know....

The short answer to this question is, of course, no. A 1 km error in one flyby may translate into 10,000 km error by the time you get to the next. It's a bit like playing a game of cosmic billiards. Although one can predict the angle with which one hits the first ball with great accuracy, by the time the ball has ricocheted to the next, one's ability to predict angles and position is considerably worse. And by the third or fourth ricochet predictions are way off.

To make any integrator work for multiple slings one has to have an underlying 'reference trajectory' to aim for so that after a flyby, one can execute a very small MCC to return the outturn trajectory back to the reference trajectory. This process can be carried on, with high precision, indefinitely - but small (very small) MCCs are needed periodically.

The longest sequence for which I've used this technique is for a reference orbit flyby sequence as follows:



This sequence involves about 14 precision burns, with about the same number of MCCs. Total MCCs for the whole trajectory amount to 2 m/s.


P.S. It may be just incompetence on my part, but the screenshots that you have posted seem to have very low resolution. It makes it rather had to read. But this could just be me.

 

[downloaderfan]

This sequence involves about 14 precision burns, with about the same number of MCCs. Total MCCs for the whole trajectory amount to 2 m/s

I acknowledge i may have not been very clear in my previous post(sorry for that), but I was not demanding the amount of precision you've assumed. I just wanted to know if your trajectory planning tool would be way too off to rely on after multiple slingshots. A few MCCs here and there is fine, even a total of 100 m/s dv of burn in MCCs is pretty reasonable for this challenge. 2 m/s is pretty low :tiphat:

P.S. It may be just incompetence on my part, but the screenshots that you have posted seem to have very low resolution. It makes it rather had to read. But this could just be me.

I'm surprised. The resolution of these images is just below 1280x720. I can clearly read the text in it in my 14 inch 1366x768 laptop, your screen resolution may be higher but that still shouldn't make it difficult to read. Could you be talking about the video?? In that case, that website does apply a compression which results in a noticeable deterioration of video quality, but still the text should be readable for anyone with normal eyesight.

Anyway, I went ahead & retook the same 2 screenshots with the most I could do to increase the resolution

 

[Keithth G]

I acknowledge i may have not been very clear in my previous post(sorry for that), but I was not demanding the amount of precision you've assumed. I just wanted to know if your trajectory planning tool would be way too off to rely on after multiple slingshots.

To put together a trajectory plan for multiple slingshots, one basically integrates forwards and backwards in time from one's first estimate of the encounter positions and times. Then one uses a mathematical technique called 'differential correction' to splice all of those integrated trajectories into a seamless, zero delta-V whole. Using this technique, one can splice together 5, 10, or 100 slingshots together if one wants - it's essentially the same mathematical problem, just requiring a little more processing time. However, one must at least have a basic idea of where/when the slingshots are going to be for the differential correction method to work. But when it works, it works exceedingly well and can lead to highly accurate results - even in Orbiter.


As for the images, if you click on the following image link, this is a screenshot of what I see on my computer. Try as I might, I can't 'expand' the images to yield any greater resolution.

 

[downloaderfan]

To put together a trajectory plan for multiple slingshots, one basically integrates forwards and backwards in time from a first guess of each of the slingshot encounter positions and times. Then one uses a mathematical technique called 'differential correction' to splice all of those integrated trajectories into a seamless, zero delta-V whole. This is basically a Newton-Raphson root finding problem. Using this technique, one can splice together 5, 10, or 100 slingshots together if one so desires - it's essentially the same mathematical problem, just requiring a little more processing time. However, one must at least have a basic idea of where/when the slingshots are going to be for the differential correction method to work. But when it works, it works exceedingly well and can lead to highly accurate results - even in Orbiter.


As for the images, if you click on the following image link, this is a screenshot of what I see on my computer. Try as I might, I can't 'expand' the images to yield any greater resolution.

Weird, I'm getting a "Click this bar to view full image" not only on my laptop but also my phone & tablet.

http://s1350.photobucket.com/user/downloaderfan/media/Image 12_zpsxb4jjznk.png.html?o=0

These are the previous two images:

http://s1350.photobucket.com/user/downloaderfan/media/Image 10_zpsp115jdxk.png.html?o=1

http://s1350.photobucket.com/user/downloaderfan/media/Image_3_zpsgg9iwsfd.png.html?o=2

You can now see how different the two paths are, one was taken after 2 callisto slings & the other was taken after 4 callisto slings.

I'm not that much of a technical guy when it comes to orbital physics since orbiter is just a hobby & my current study course has little to do with orbital physics(otherwise I would look up more on stuff like this), but what I understand from your statement is that...it is possible to get pretty accurate plans & execute them with a few MCCs using your trajectory tool, unlike TransX & IMFD. That's all I needed to know



Or is it something else??? :lol:

 

[Keithth G]

but what I understand from your statement is that...it is possible to get pretty accurate plans & execute them with a few MCCs using your trajectory tool, unlike TransX & IMFD. That's all I needed to know

Yes. That pretty much sums up the situation.

---------- Post added 01-11-16 at 04:48 AM ---------- Previous post was 01-10-16 at 11:15 PM ----------

Actually, I don't think that IMFD map is doing too bad. I don't see as wild oscillations as you do on the video. The mission starts about 2 weeks before arrival, and my predicted PeA is always within 400 km of the final value. Not bad considering the scale of the Jupiter system.

The attached video may better highlight the problems that I have with IMFD (and TransX).

https://youtu.be/TbnLExlsOj0

This is basically the same scenario as before, but the Delta Glider starts its journey to Callisto rendezvous much further out, at around 26 million km from Jupiter (and outside of Jupiter's strong SOI). The total journey time to Callisto is around 180 days. On my computer, IMFD's predictions dance around enormously, by around 1 million km, and are unusable - until, that is, the Delta Glider is just a few weeks out from Callisto by which time it is too late to perform low-cost delta-V manoeuvres.

In this scenario, Orbiter's trajectory projection is that the periapsis altitude is 11 km - just 9 km shy of the target 20 km assumed in the offline n-body trajectory planning. And, of course, the Delta Glider arrives at Callisto more or less exactly 'in plane' with Callisto's orbit around Jupiter.

I will attach the .scn file for this scenario shortly.

---------- Post added at 04:51 AM ---------- Previous post was at 04:48 AM ----------

Contents of the .scn file for this scenario:

BEGIN_DESC
Orbiter saved state at T = 15372026
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 57357.6345357819
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-01
END_FOCUS

BEGIN_CAMERA
  TARGET GL-01
  MODE Cockpit
  FOV 55.00
END_CAMERA

BEGIN_SHIPS
GL-01:DeltaGlider
  STATUS Orbiting Sun
  RPOS -788764317470.56 15830101920.60 274705590644.91
  RVEL -4667.931 117.073 -12537.351
  AROT 2.27 -34.26 -1.21
  AFCMODE 7
  PRPLEVEL 0:0.039070 1:0.099962
  NAVFREQ 402 94 0 0
  XPDR 0
  SKIN RUSTY
  AAP 0:0 0:0 0:0
END
END_SHIPS

BEGIN_ExtMFD
END

BEGIN_VistaBoost
END

 

[boogabooga]

It is good that you have an offline n-body integrator. But let me put it this way:

WHY does your integrator perform better than IMFD's map program?
What advice would you give to someone who would develop a new online n-body integrator MFD for use in Orbiter?

 

[Keithth G]

It is good that you have an offline n-body integrator. But let me put it this way:

WHY does your integrator perform better than IMFD's map program?
What advice would you give to someone who would develop a new online n-body integrator MFD for use in Orbiter?

Let's focus on the 'why' question. Building an n-body integrator that is both fast and accurate is a tough computational challenge. On the whole, I doubt that with using standard PC/laptop architectures one can achieve both. I don't know much about the algorithm that IMFD's Map program uses to update its trajectory projections, but I suspect that its author placed an emphasis on speed so that it can provide a very rapid 'refresh rate'.

My integrator is based strictly on a concept of computational accuracy - even if achieving that means sacrificing computational speed. It uses the same ephemeris programs (for Jupiter - VSOP87 and Galsat); and it uses a fourth order explicit symplectic integrator with a time-step that is sufficiently small to ensure high accuracy in the results. At the moment, though, the integrator runs 'offline' in Mathematica - a reliable, bullet-proof program notorious for its computational sluggishness - making external calls to bespoke C routines to calculate the positions of planets and moons using VSOP87 and Galsat routines (the same ephemeris routines as used in Orbiter). In Mathematica, the current 'refresh rate' for straightforward trajectory projection calculations is currently around 5 - 10 seconds depending upon the time interval of the projection and the number of close encounters with gravitating bodies.

I'll think further about the issue of 'advice'.