[WIN] Flyby Finder for Real Solar System Mod V0.85 [RSS12.0 for KSP1.2.2]

[PLAD]

This stand-alone program searches for flyby opportunities in KSP when using the Real Solar System mod by Nathan Kell only. It also does pork-chop plots. It only finds ballistic trajectories, that is, ones where you do one major boost when leaving your start planet and then coast past all other planets you encounter (allowing for small course corrections). Real world examples of this are Pioneer 11, Voyager 1&2, and the New Horizons Pluto probe. I also use it for planning opposition-class missions to Mars. It does not handle deep space maneuvers or multiple flybys of one planet, like the Mercury Messenger probe or Galileo or Cassini.

I've tested it with up to RSS version 12.0 used on KSP 1.2.2. It works with all RSS versions back to at least 8.2 as well, but note that Earth's SMA changed in version 12.0 so you have to select the right version from the radio buttons when you start FF. Default is set for V12+ so if you are only using older versions of RSS then I would stick with FFRSS V0.83 so you don't have to select the radio button every time.

This is a fork of my Flyby Finder for stock KSP. As such the basic operation is the same as FF, and if you've used that then you need only see this quick guide for FFRSS, the new 0.80+ features are shown at the end:

Javascript is disabled. View full album

If you have never used FF then here is its guide, which you should read for FFRSS as well:

Javascript is disabled. View full album

Here are the known bugs and suggestions on things to avoid:

1) The program does not accurately do double flybys, that is consecutive encounters with the same body. It doesn't warn you of the error if you do enter a planet twice in a row, and the output will be wrong.

2) There is limited input checking- make sure to only enter decimal numbers in the input fields! The program just refuses to do the search if bad entries are made.

3) If the initial departure orbit shows an inclination of exactly 90 or -90 degrees then the departure equatorial prograde and departure vZ values will be wrong. Okder's addon (mentioned below) gets around this! High-inclination transfer orbits are very tricky to fly in any case, I try to avoid them if I can.

4) Paths that fly by gas giants more than 3 times get clumpy. (See FFRSS guide for example.)My problem is that setting precision parameters good for Mercury makes them bad for the big outer planets.

5) When doing searches with more than 3 bodies the program sometimes stops updating the screen (though it is still working and will finish the search eventually). The problem is that I don't have it update the screen when it is deep in nested loops since it could be a big hit to run time.

6) The new "Search steps per period" (SSPP) feature is handy, but remember that increasing it by a factor of 2 increases the run time by 4x. It is also best to keep (Search Period/SSPP) higher than 12 hours or so or it slows down even more.

Here are the links. I'd call 0.85 a beta version. 0.85 has only one change from V0.83- a pair of radio buttons have been added to select between Earth's SMA from RSS Version 12.0+ (default) or Earth's SMA from all older versions. Version 0.84 has been dumped because I did not enter all the changed parameters for Earth's orbit correctly in it, 0.85 corrects those and is now the one to use with RSS V12.0+

I use the MIT license.

FFRSS 0.85 Executable and instructions for Real Solar System mod only:

https://www.dropbox.com/s/7o5buwpkp9fgj39/Flyby Finder RSS085exe.zip?dl=0

FFRSS 0.85 Source code for Real Solar System mod only:

https://www.dropbox.com/s/4p8kgc4lcn8pgk3/Flyby085RSSsource.zip?dl=0

and just in case, here is the previous version. I would stick with this one until you install RSS version 12:

FFRSS 0.83 Executable and instructions for Real Solar System mod only:

https://www.dropbox.com/s/32pkvymdftvd8al/Flyby%20Finder%20RSS083exe.zip?dl=0

FFRSS 0.83 Source code:

https://www.dropbox.com/s/mkk8wyvf8c6t3p9/Flyby083RSSsource.zip?dl=0

Here is an Excel spreadsheet, LambertH.xls, that I use to set up and test FFRSS. It does test double flybys, and it shows you the data and calculations that are used in FFRSS. It is pretty hard core math-wise though, you probably shouldn't mess with it unless you know what you are doing. This is an update that fixes the 'out of order' third double flyby field. It also shows an Earth-Venus-Earth-Earth-Jupiter path with a very low starting dV. Beat that, Galileo mission planners!

https://www.dropbox.com/s/58yepcybuoz2ll2/LambertRSSvH.xls?dl=0

Here is a little spreadsheet, "MoonfinderB", I made that gives the next 2 launch times from any high-latitude (higher than 28.4 degrees) launch site to Earth's Moon using a due East launch azimuth (the easiest and most efficient launch azimuth). I fly to the Moon a lot and was getting tired of guessing. Instructions are in page two of this thread, here. and a direct link to the Imgur album here. Check the yellow cell in the spreadsheet to make sure it is set for your version of RSS as Earth's sidereal rotation period has changed. Doh! I need to upgrade it for V12.0 since Earth's SMA and year have changed, that only affects the info on where the Moon's terminator will be though, the best time to launch calculation should still be correct.

https://www.dropbox.com/s/rqcb48m43rmh7g6/MoonfinderB.xls?dl=0

Okder has made a Mechjeb addon that eliminates the need to use a test probe for deciding when best to launch into the transfer orbit. It even creates an updated departure burn node after you are in orbit! Now being off by a couple of degrees in inclination or LAN can be instantly accounted for. Check it out!

I also find slingshotter by Overengineer1 to be very useful in setting up flybys, it enables you to see if your future path will cross a future target planet's path in the right location. It is only available for KSP 1.05 though.

Edited February 1, 2017 by PLAD

[NathanKell]

Holy smokes that's awesome!

[Hattivat]

Awesome! \o/

[selfmade]

Awesome tool

Did a Earth-Jupiter-Saturn-Mercury today and it worked great! 10/10 would use again.

[Carlo]

Awesome tool in theory, in practice i wasn't able to have any kind of response T_T i tried multiple times with multiple celestial bodies... nothing at all, just blank pages T_T.

[BevoLJ]

Awesome tool in theory, in practice i wasn't able to have any kind of response T_T i tried multiple times with multiple celestial bodies... nothing at all, just blank pages T_T.

Did you increase the search periods? If nothing is found in the period you give it there will be no results. By default those are only increased by 1 or 2 hundred if I remember right. Since you are trying to plan an orbit mission out to Pluto the search periods for your assist encounters (like Jupiter) will need to be bumped up a great deal. Edited March 6, 2015 by BevoLJ

[Carlo]

Did you increase the search periods? If nothing is found in the period you give it there will be no results.

I tried with exagerated numbers also, but nothing, it seems to find only flybys for venus as the 1st encounter, if i choose any other celestial body, or a 3rd encounter, it shows no results

[PLAD]

Below is a primer showing how I searched for optimal flights to Pluto. To Carlo and anyone else getting lots of blank screens, it's not easy to find that first window, most of the time there is no path between the selected planets at the selected times. The most important thing though is to set the "V at SOI" "max" number high enough. If you leave it at the default 3500 it will only find windows from Earth to Venus and Earth to Mars, and even then only if you set the "Earliest Search Dates" and "Search Periods" just right. In the following primer I have a set of good numbers to start with, for instance, If you are going from Earth to Jupiter you must set V at SOI max to at least 9500, (10000 would be even safer), the "Earliest Search Date" for Jupiter must be at least 600 days later than the one for Earth, and the "Search Period" for Jupiter should be at least 500 days, (or even 1000 days to be safer). For flybys you often need an even higher V at SOI, for instance Earth-Venus only needs 3500m/s but Earth-Venus-Mars needs at least 5500. I still forget to raise this number high enough sometimes. (If you raise it too high you'll often hit the 'flybys found' limit of 4500 and a big part of the output will be blank)

To test that the program is working correctly on your computer pick one of the graphs in the pictures below and copy all of the "V at SOI", "Earliest Search Date", "Search Period", and "Start at", "1st Encounter", "2nd Encounter" (etc) numbers to your program and see if you get the same result I show. If you don't, is it possible to get a screen grab of it?

Javascript is disabled. View full album

[sisyphean]

well i would like the tool if i could work out how to use it, beyond porkshop selections ive only been able to find earth venus mercury. trying to find earth venus jupiter is proving impossible, i have tried expanding all the search criteria and i just end up with blank pages, i have no idea how to troubleshoot or find out what it is im doing wrong to stop me getting any results, spent 40 minutes trying and searched all the way to 2020ish and nada.

any chance you can give a suggested method of finding this flyby? ive opened up my search periods all the way to 10000 days and i still cant find anything

[PLAD]

well i would like the tool if i could work out how to use it, beyond porkshop selections ive only been able to find earth venus mercury. trying to find earth venus jupiter is proving impossible, i have tried expanding all the search criteria and i just end up with blank pages, i have no idea how to troubleshoot or find out what it is im doing wrong to stop me getting any results, spent 40 minutes trying and searched all the way to 2020ish and nada.

any chance you can give a suggested method of finding this flyby? ive opened up my search periods all the way to 10000 days and i still cant find anything

Sorry for the delay in answering. I've got to figure out how to be auto-notified when something is posted here.

Earth-Venus-Jupiter is a very difficult trajectory. To get from Venus to Jupiter requires a V infinity at Venus of about 11500m/s, which is about 17000m/s at 200km above Venus. At this speed Venus can only bend your path a few degrees, in essence you are making a high-speed shot from Earth to Jupiter that passes close by Venus on the way. Because of orbital inclinations there are only some very small points in their orbits that all three planets have to be at where this will work. Here's a sample of this rare alignment:

Planet Earliest Search Date Search Period

Earth 2250 150

Venus 2315 200

Jupiter 2800 2000

V at SOI max: 16000 m/s (!)

The V at SOI is so high because you are shooting at a high angle inward from Earth's direction of orbital motion to pass by Venus in the right spot. Notice the two arrival times, in one you hit Jupiter flying outward from the Sun, in the other you go way out pass Jupiter and then catch it coming back in towards the Sun.

In real life this path would never be used but paths that fly by either Earth twice or Venus twice could be used. I've looked for Earth-Venus-Earth-Jupiter paths, but those are almost as rare as E-V-J. It's the same problem, flying from Earth to Jupiter requires a V inf at Earth of around 8800m/s, and Earth can't change your flight path much at that speed, so the alignments have to be very precise and thus rare. E-V-E-E-J is more possible since the two passes of Earth double it's ability to turn your path, but FF can't do double flybys. The Galileo and Cassini missions had to use double flybys and significant deep space maneuvers to get out to Jupiter and Saturn.

Finding these types of paths would require using double flybys, deep space maneuvers, and multiple orbits between encounters to really find all possibilities, but I get the shakes just thinking about what that code would look like.

[drtedastro]

Very interesting and good work.

I looked at your stock ksp version and it seems to be quite old. Will it be getting any new life in your plans?

Also, any chance of being able to add the extra planets and moons that come from the kopernicus type mods?

Great work again.

Cheers.

[PLAD]

Thanks! I am a week or so away from releasing a new version of FF for RSS, it will have more graphing options and catches up with the slight changes that RSS made to gas giant diameters and atmosphere heights. None of the orbits or masses have changed so the current version is still accurate.

I will attack FF for stock next, the giant improvement needed is to be able to use both time systems (6/426 and 24/365). I'll also add the option for the OPM system (Sarnus, Urlum, etc.). I have no plans to add any moons because of the way I wrote FF- it uses linked conics for speed rather than patched conics, so it becomes too inaccurate if the SOI's are large relative to the distance between the bodies (like in Jool's moon system). I think TOT can handle that stuff.

[drtedastro]

Sounds great. I look forward to being able to work with it.

I am getting setup to start a new RSS run so I will be able to test / work with both versions.

Cheers.

[Wobulator]

This is an awesome mod!

Is this linux compatible? I'd imagine that the majority of RSS/RO players use linux

[PLAD]

This is an awesome mod!

Is this linux compatible? I'd imagine that the majority of RSS/RO players use linux

You may be right, it must be nice to not have to worry about memory when a lot of mods are loaded. I've never used Linux, so I don't know what it would take to run this in Linux. Windows 10 might be the thing that finally pushes me to find out, but I have no plans for it at this time.

[PLAD]

OK, I've just posted links to the new version in the OP. The visible changes are all to the graph display, you can now set the colors that used to only show the start boost dV to show Total dV, Braking dV, Start vZ, and 1st flyby altitude as well. The most powerful addition is a new parameter "Search steps per period" (I abbreviate this as SSPP). See the primer below (which I will tack on to the end of the main primer as well).

Javascript is disabled. View full album

Watch out, if you double the SSPP you increase the run time by 4x, it is best to keep SSPP at 100 until you've found a good area to make a fancier graph of. Also remember the 'flybys found' limit of 4500, ideally you set SSPP so that you will be just below this limit.

I found good uses for all the new features when searching for flights, except for graphing by 1st flyby altitude, I put that in there just to see what it looks like. If someone can think of a use for it when setting up a flight I'd like to hear it. That's why there is no graphing by second or third flyby, I didn't want to clutter up the display (or the code) with experiments.

My next plan is a new release for FF for stock KSP. Besides the new graphing features it needs to handle the two time systems and I wish to put in a way to easily add mod systems, starting with the OPM. I figure 4 weeks for this.

I also plan to make a primer on setting up the departure boost, Alex Mun's pork chop plotter and my FF use two different ways to help set it up and neither one is perfect (IMHO). It's a complex problem but I've got some ideas...

After that I will attack double flybys again and maybe a way to search for Juno-style missions to Jupiter. Time scale for these things is several months though.

Edited August 24, 2015 by PLAD

[drtedastro]

Looking good.

Great work.

Cheers.

[Wobulator]

Awesome!

I'll look into running this on linux. Linux has Free Pascal, which claims to emulate most of Delphi Pascal. Unfortunately, I've never programmed in Pascal before, so no promises if I can actually do this.

[BevoLJ]

What does it mean if I am getting a negative Equat. Prograde velocity?

[PLAD]

What does it mean if I am getting a negative Equat. Prograde velocity?

It means the departure orbit is highly inclined. Remember that the Start Equat. Prograde velocity and Start equat Z velocity are to be applied to a test ship that is already in a zero-degree inclination circular orbit around the start planet. If you are in such an orbit around Earth at, say, 200km altitude then the ship is already going 7787m/s in a prograde direction (and 0 m/s in the Z direction). If the departure orbit was inclined 90 degrees then you would have to kill all of that 7787m/s and add vZ for the departure. So the program would say you have to add -7787m/s in the equatorial prograde direction (and something over 11200m/s in Z.) Of course in practice you would see the departure path for the test ship and use it to launch your real ship from the ground into a polar orbit at the right time.

And I must note that the program still doesn't handle the numbers right when the indicated start orbit inclination is exactly +90 or -90 degrees. It gives correct departure and flyby dates and so on but the prograde and vZ numbers are not right.

[BevoLJ]

Awesome. Thanks PLAD. =)

[Lilienthal]

This is really awesome. Thank you.

I have one question/request: I assume that in most cases a launch from an orbit that is coplanar to the ecliptic is usually better than starting from an equatorial orbit. Therefore I launch my interplanatery probes into such an orbit before going leaving Earth.

Would it be possible to calculate vz and v_prograde relative to that? Or is my whole approach flawed?

ta,

Gustav

[PLAD]

This is really awesome. Thank you.

I have one question/request: I assume that in most cases a launch from an orbit that is coplanar to the ecliptic is usually better than starting from an equatorial orbit. Therefore I launch my interplanetary probes into such an orbit before going leaving Earth.

Would it be possible to calculate vz and v_prograde relative to that? Or is my whole approach flawed?

ta,

Gustav

That is an interesting question. It is true that the planets all orbit in planes within about 7 degrees of the ecliptic, but transfer orbits to the planets are usually more inclined than that. So having your parking orbit around Earth be precisely in the plane of the ecliptic might not be a particular advantage. What makes it so bad is adding the Earth's velocity to your Earth departure velocity. Imagine that you need an interplanetary transfer orbit inclined 7 degrees to the ecliptic. So you leave in an orbit inclined 7 degrees to the ecliptic relative to Earth. Your v leaving Earth's SOI is, let's say 4000m/s. Once you leave Earth's SOI and your reference is now the Sun, the 4km/s is now added to Earth's orbital 29km/s, and your 7 degrees relative to Earth becomes 0.85 degrees relative to the Sun. So in this example, with a Vsoi of 4km/s, leaving more or less prograde from Earth, your Earth start orbit inclination has to be about 8 times more inclined to the ecliptic (relative to Earth) than the interplanetary transfer orbit's required inclination (relative to the Sun). In summary, I think you can often save a lot by launching into an orbit that is not necessarily in the plane of the ecliptic.

Your other question is an intriguing. If I use the ecliptic plane as the plane to put the test probe in then it is trickier to put it there, since you will have to specify the inclination and the longitude of the ascending node precisely. When I use an equatorial test orbit no LAN is necessary. If you're hyperediting it up there I suppose it's no big difference. Then I would give Vprograde and vZ relative to that orbit and you could see what plane to launch into, same either way. But I wouldn't know what the inclination of the departure orbit is relative to Earth's equator, since vZ and Vprograde would be relative to a specific point in an already-inclined orbit and wouldn't add together simply. I'd have to figure out the ejection time exactly, beforehand, to give the inclination of the orbit to launch into. (Right now I just set vZ and vprograde into a maneuver editor and adjust the ejection time back and forth until I see the orbit prediction hit the target planet.) There would be one big advantage to using the ecliptic plane though- it's a lot closer to Canaveral's latitude than the equator, and it would be much less common for the test orbit to be less inclined than Canaveral. (When that happens my current way breaks down since you can't launch from Canaveral into a, say, 10-degree orbit.)

I have to think about it for a while. My way of defining the departure orbit is not nearly as good in RSS as it is in stock KSP (unless you launch from Kourou:)), and it's not perfect anyway. I don't want to promise anything.

[Lilienthal]

Thanks for your thoughts. I didn't think enough about it, but yes, if you want to leave SOI with 6 deg rel. to ecliptic your initial orbit has to be *far* more inclined relative to the ecliptic than 6 deg. That of course limits the use of always launching into the ecliptic massively. (Which I do, BTW by launching into the orbit of a test craft that I edited in that orbit.)

However, I do think that on average a start orbit in the ecliptic plane should be beneficial and the method you describe of setting v_z and v_pro and then adjusting the time should work, IMHO, just the same. Also, of course you are right, from Canaveral that would be much beneficial.

So overall, I think a calculation of v_z and v_pro relative to the "ecliptic orbit" would be awesome. I'd be so happy if you could do it. Would you? Please?

Gustav

[PLAD]

I'm not ready to make a substantial addition to the output yet. I'm planning to fix the false positives problem first, then update the Lambert spreadsheet, and then take another shot at double flybys before I will take a hard look at improving the output. In my mind neither using an equatorial or ecliptic orbit is optimal, but as yet I haven't thought of a best way. (Especially for high-latitude sites like Baikonur.) Sorry for now.