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

[PLAD]

3 hours ago, Zuppermati said:

Avira tells me it has a filerexsnxclass [pup] virus 

 I downloaded it from Dropbox and scanned it with my virus checker and didn't see anything, then compared the download to the original I uploaded and didn't see any changes, then recompiled it from the original source code and still don't see any differences between that and what I pulled off of Dropbox. (When you say 'it' I assume you mean the .exe.) So I'm down to a few possibilities:

-There is a virus and it hides from my checks.

-I'm using an old language and a virus checker might misinterpret unusual code as a virus. I don't use Avira so I can't check this.

Does anybody else see this? I wrote FF to not write anything to disk at any time so it should be easy to spot any misbehavior.

[Zuppermati]

The strange thing is, the 0.82 version is 100% fine. Even stranger, the antivirus notifies me of the virus only when i open the program. When i do a specific scan on the .exe, it tells me it's 100% clean.

By the way i confused avast with avira 

[TrooperCooper]

 

Ahoy @PLAD !

Just a big THANKS for this great tool. I have just started using it the other day and completed an Earth-Venus-Mars-Earth roundtrip based on its data last night. With this program you have really opened up the possibilities within RSS enormously. My hats off to you.

 

[PLAD]

22 hours ago, TrooperCooper said:

 

Ahoy @PLAD !

Just a big THANKS for this great tool. I have just started using it the other day and completed an Earth-Venus-Mars-Earth roundtrip based on its data last night. With this program you have really opened up the possibilities within RSS enormously. My hats off to you.

 

Thank You! Impressive UNSA mission reports, by the way! Your E-V-M-E mission was dramatic, and I learned something from seeing how you were able to correct for the suboptimal starting boost from earth orbit.

[berkekrkn]

Hi @PLAD

 

how can I manage "earliest search date, search period, V at SOI" these kind of things ? 

Should I always get these infos from earlier missions ?

[PLAD]

The search period and especially V at SOI are things I learned the hard way, by trying an initial search with a very wide search period and a very high VSOI and looking around until I find something. The primer I have in the first post of this thread can save you some time with its examples of successful searches. You can search more quickly by paying attention to synodic periods, for instance the synodic period between Kerbin and Eve is 680 Kerbin days (or 170 Earth days) so if you manage to find a path you like from Kerbin to Eve on K-day 100, then there should be another one around day 780. This is also a good search period- one synodic period. It is more complicated when more than 2 planets are involved but there are still 'quasi-synodic' periods between multiple planets where a good path repeats. For example 4 Kerbin/Eve synodic periods almost exactly equals 3 Kerbin/Duna synodic periods, so a good Kerbin-Eve-Duna path will often be repeated about 2720 K-days later. As for VSOI, if you are starting a completely new search I use 6000m/s for VSOI, this should be way more than anything needs. I'll usually get so many hits that the max_flybys_found is exceeded, but then I just sort the hits by start dV and look at the VSOI of the lowest ones and then reduce VSOI to something a little above that.

Even trickier is figuring out when the 3rd, 4th, and 5th encounter search dates should start, since you have no idea whether there will be a low, fast possible route or a high, slow route, or both. So I set the earliest search dates to be only 10 days after the previous encounter's earliest search date, and the search periods for the later encounters to be ridiculously high, say 8000 days, and hope a 'hit' doesn't disappear in the gaps between search times. And of course proceed one encounter at a time, for instance if you want to find a Kerbin-Eve-Duna-Kerbin-Duna flight first find a Kerbin-Eve window, then narrow the search to that window and add Duna, then once you find that add Kerbin, and so on.

Sorry if this answer is overkill, from your question it sounds like you've run into this stuff already. I don't have an easy answer. I sometimes think I should make a library of flyby windows. If you download the Lambert spreadsheet I did put some notes in there.

 

EDIT: Sigh, I see I mixed up RSS and stock above, however most of it is the same. The spreadsheet LambertRSS has a page "synodic" that gives recommended V at SOI max values for each planet, in summary, starting from Earth and going to :

Mercury: 8000m/s

Venus: 3500m/s. If you're going to go Earth-Venus-Mars then 5500m/s is needed.

Mars: 3500m/s

Jupiter: 9500m/s

Saturn: 11000m/s.

 I would never fly directly to anything past Saturn, a Jupiter flyby is always better IMHO. (Though the Jupiter-Uranus synodic period is 5047 days so it could be years until the next good window.)

Edited July 13, 2016 by PLAD

[DBowman]

@PLAD thanks for the great tool, I've used it in stock a few times and now having a go in RSS. Previously I'd 'near enough is good enoughed' and mashed the xfers till they more or less did what I wanted.

I'm trying to get everything nice a neat this time for an EVME; I think I've got an initial equatorial node setup at perfect UT seconds with the first Venus Pe within 15 mins of the FBF prediction - but the Pe at 1.5M km. Here is the first two encounter from FBF:

Start Planet: Earth

Orbit Departure Time:

   2292546240 seconds UT

   26535.1 days UT

   25 Aug 2023 = day 237 0.1D is 144 mins 2hr24m

   Y73   D255   H2.3

Start Orbit Inclination: -62.8 degrees

Start Boost from that incl.: 3742 m/s

Start Equatorial Z velocity: -10258 m/s

Start Equat. Prograde velocity: -2521 m/s

Start Boost from Equat. Orbit: 10563 m/s

V Infinity Leaving Start Planet: 3538 m/s

 

1st Encounter Planet: Venus

Time from Start to 1st Encounter: 164 days 13.6 hours

Vinf in: 7493 m/s

Brake to Orbit?: 5401 m/s

1st Encounter Periapsis:

   26699.67 days UT

   05 Feb 2024

   Y74   D54   H16

   8054 km altitude

Vinf out: 7493 m/s

 

and a screen shot:

to 'position' the node I placed it in time and then tweaked argument of periapsis - which moves the probe around but leaves the node UT unchanged. I tweaked the AoP and could get either the above at the right time or an encounter 32 hours late. Is this variance within what you expect?

 

If it is - then from your experience whats the best way to work with it? the late encounter is equivalent to burning a little later within the 'current' orbit which would be easy to hit. The encounter at the right time is probably under/over / before/after the AN/DN so I'd have to wait for the planets to move a little (or go early) but then some or all of where in the orbit to burn, normal, prograde would have to be adjusted.

 

If the variance is more than you expect then do you have any ideas re how I can trouble shoot it?

 

oh and I forgot to check 'notify me' so could you please quote or reference me.

 

Edited November 7, 2016 by DBowman
pressed save not add image

[PLAD]

I'm sorry Dave, but I can't do that.... There, I got that out of my system.

@DBowman- I've found that the Venus flyby timing in an EVME path should be within about +/-24 hours to keep mid-course corrections near zero, so 32 hours late is risky in the sense that you might need something on the order of 50m/s of corrections to get the final Earth encounter. This looks like a high-z velocity flight too, and that makes the timing requirements even more tight. I'm going to have to set this one up myself to explore the situation, but that might take a day to get back to you so I'll tell you what my first try will be: First tweak the start equatorial prograde and z velocities a bit, I notice you have the values entered exactly, and in RSS z can be +/- a percent or so when the z values get high. Tweak z (or 'Normal') first. That should get you closer to Venus at the right flyby time. Next, live with leaving Earth at the right time on a path that takes you past Venus at the right time but fairly far off from the right flyby altitude. Try to make your initial orbit cross as close to Venus' orbital plane at flyby time as possible, be willing to be +/-18 hours off in order to do that. Then set up a maneuver about 90 to 180 degrees before your Venus encounter that corrects the flyby altitude, at this point you'll find that it won't change the flyby time as much. If you had a lot of z-error (flyby too far above or below Venus) the maneuver should be closer to 90 degrees before the flyby. Now you should be flying by Venus at close to the right time and close to the right altitude. But then, at a point 90 degrees before the Venus encounter you can set up the Mars encounter fairly precisely, and that will be more important than the details of your Venus flyby. Flyby altitude soaks up other errors, there is no need to worry about up to +/-20% error in flyby altitude.

     Changing the AoP of the departure orbit instead of the departure time is an approach I haven't used, I get the reason for it, because changing the departure node time by even 1 second can cause a change of tens of thousands of Km in the Venus encounter and changing the AoP allows greater sensitivity. But I change the departure node radial velocity by a few m/s to get the same effect as changing the node time, the change in the total dV is trivial and it is easier to adjust by pressing the radial + and - buttons than by typing in the AoP value.

[DBowman]

1 hour ago, PLAD said:

in RSS z can be +/- a percent or so when the z values get high.

ah thanks this and your advice were exactly what I was looking for. I thrashed around on the 32 hours late encounter a little yesterday and got Venus (44 hours late) & Mars about the right time and very sensitive, about 10 prograde and 12 radial - I'll give it a shot with the earlier one.

re the AoP I'd found that fixing the node time could mean it being half an orbit / 45 mins off where it was 'supposed to be' depending on where the probe was - so to 'exterminate all sources of error' I used AoP for the initial node placement and then (as you say it' more awkward) and then radial tweaks.

[PLAD]

@DBowman

I tried this path out and I see the issue- the required start equatorial Z and start equatorial prograde values are wildly sensitive to the flyby time with this particular flight. For instance if I leave Earth at day 26535.1 and pass Venus on day 26699.4 it requires a start z of -10329m/s and a prograde of -2663, but if the arrival time is changed to day 26699.6  then the z has to be -10277 and the prograde -2560m/s. So 4.8 hours changes the z by 52m/s and the prograde by 103m/s. In other words it takes a big change in start v to make a small change in arrival time. Flyby Finder has a lot of operations to find a flyby and trigonometric rounding errors build up in a sensitive path like this, and I can't think of a way to make it more accurate without a big hit in run time. So I live with sometimes having to adjust the prograde and z values from the values output by FF.

 On the other hand, as you found, it is easy to get a good Mars encounter from a range of Venus flyby times. It is also straightforward to coast from there back to Earth, the problem is that your Earth arrival time can vary a lot- in the above example the 4.8 hour Venus flyby timing error can lead to a 5.5 day change in the Earth arrival time. So if you want a precise Earth return time for some reason you might be forced to make a number of large-ish MCC's to pull it off- keep trying to make each encounter happen as close to the listed time as possible.

Sounds like you flew it well despite the roughness in FF. I think I see why you chose that path, it has a nice balance between low Earth arrival velocity and a short total flight time.

[DBowman]

11 minutes ago, PLAD said:

I think I see why you chose that path, it has a nice balance between low Earth arrival velocity and a short total flight time.

exactly, I wanted to minimize arrival velocity for a short flight time in my deltaV budget. I've not flown it yet - just played around with the reference departure node.

Interesting. The sensitivity of the underlying path means a three extra orbit periods between departure can change departure dealtV by 75. That is a straight consequence of reality, there would be other 'regions' that were much less sensitive. It doesn't seem straightforward to give users indications of 'the sensitivity'. I mean each craft has a deltaV / life support trade off given a certain 'lift to departure orbit' mass budget - so everyone cares about something different.

I had thought to 'focus the calcs' in on that 'lower band' of flybys you must have seen, the only tool I could see to do that was limiting the Venus or Mars search times to indirectly exclude the longer flybys - is there a better way to do that? Would it be easy to be able to show the detail for a trajectory from clicking on a dot in the chart? it would make it easier to 'browse' the trajectories.

Actually it might be really handy to be able to export the table to csv - so you could filter out things - like in my case if I discarded flights shorter than 490 days I'd have only 'the low departure deltaV' ones to browse and select between. Or even just allow copy on the rows you can select.

1 hour ago, PLAD said:

trigonometric rounding errors build up in a sensitive path like this, and I can't think of a way to make it more accurate without a big hit in run time.

'live with it' - really it's hard to live without what you have done so far! I guess the trick would be to dynamically do more computation / higher representation accuracy only where sensitivity was high - but that's easy to say...

For my mission I think I have a few 100 m/s contingency so I'll plan on mid course and encounter approach corrections. Thanks again for your help.

[PLAD]

Just a note, I've added a new version of FFRSS, it is now V 0.84. The only change from V0.83 is that I added a couple of radio buttons to allow you to select between using the value for Earth's SMA used in all versions of RSS before V12.0, and the (more accurate) value used starting in V12.0. The default on starting the program is the V12.0+ value, so there is no need to upgrade to FFRSS 0.84 until you start using V12.0. The change is pretty small, you wouldn't really notice different results  until you're in the 1960's

-PLAD

[brooklyn666]

Can this work on Mac at all?

[leudaimon]

6 hours ago, brooklyn666 said:

Can this work on Mac at all?

Can't say about Mac, but I run this on Wine in Linux with no issues

[brooklyn666]

14 minutes ago, leudaimon said:

Can't say about Mac, but I run this on Wine in Linux with no issues

How would I go about setting it up with Wine?

[leudaimon]

If you have Wine installed, just run the .exe file with Wine.

[brooklyn666]

17 hours ago, leudaimon said:

If you have Wine installed, just run the .exe file with Wine.

 

I downloaded Wine (or at least I think I did. this is the link I used) but I don't know how to use it. I would appreciate an eli5 step-by-step

[leudaimon]

I have never used Mac, and I don't think the instructions for linux would apply.

I googled it, and think you may follow this tutorial to install it, and then just open the .exe with wine.

[PLAD]

Argh, I've been running  series of flyby missions in RSS 12.0 and have discovered a bug in v0.84 of FFRSS. It is only a problem when in V12.0 mode, I didn't enter all the new parameters correctly and FF will give increasingly bad results as the years go by (though the first few years the error is trivial). I think I've nailed down the error and am testing a fix now but it will take another day or two to be sure. I shall remove version 0.84 for now because I don't want anyone counting on it. Sorry about this.

-PLAD

[PLAD]

OK, It's fixed now. I've put up FFRSS version 0.85 in the OP. Changes from version 0.84 are that the Earth's starting position, change in anomaly per day, and SMA have been adjusted to sufficient accuracy. Anomaly and start postion were off by about one part in 1000 in 0.84, so Earth would be about a third of a degree further out of position every year. I also tweaked some of the planet diameters and atmosphere heights that changed a bit in RSS v12. I saw that Pluto has an atmosphere now, but it is so thin that I let FF ignore it, I figure Pluto isn't going to change your course a bit if are going fast enough for that atmosphere to affect you.

  

 

[PLAD]

As some have noted, it can be time-consuming to set up a flyby when you only know the flyby altitude. However, okder has updated his Mechjeb addon to add a graphical departure asymptote indicator. This makes it much easier to set up a flyby path past the intermediate planets. (It also has some other uses, more details below.) Here is a little primer on how to use it.

https://imgur.com/a/MzWwR

This little album shows more detail on using it to plan a future departure from a planet you are arriving at.

https://imgur.com/a/vSGZB

 I experimented with putting more info in FF's text output, like the inclination of the transfer orbit from one planet to another, but this graphical indicator is much easier to use. It works with stock,  RSS and other planet packs. Note you will need Mechjeb in order to use this.

The biggest trick is deciding whether to use the short path or long path when setting up a flyby. Long path means you will go more than 180 degrees around the sun during the transfer, short path means less than 180. For a given flight one of them will require you to go retrograde around the sun, that is the wrong way. Looking at the number in the '"boost from circular" field will tell you which that is because the retrograde path will have a much higher value than the prograde one.

[ebigunso]

Hi. I have a little feature request that could make the experience smoother.

Filter results by launch site latitude. Add a box to have the user input the launch site's latitude, and FF could filter out results that require starting orbit inclinations lower than what is achievable from that latitude.

[TheBok]

PLAD dude you should know that this mod is amazing, and you should feel good.

I am wondering if you know of any practical solution to determining parking orbit LAN, or something, other than using the test vehicle in equatorial, setting maneuvre node, and launching by eye into that orbit? I don't use MechJeb so the addon isn't really an option for me. I actually somehow am finding the eyeballing launch into the maneuvre node method not too difficult, but it is a little time consuming and messy and just wondering if you've found any other practical solutions.

Thanks again for your epic work on this mod.

[Arrowstar]

On 2/27/2019 at 10:23 PM, TheBok said:

PLAD dude you should know that this mod is amazing, and you should feel good.

I am wondering if you know of any practical solution to determining parking orbit LAN, or something, other than using the test vehicle in equatorial, setting maneuvre node, and launching by eye into that orbit? I don't use MechJeb so the addon isn't really an option for me. I actually somehow am finding the eyeballing launch into the maneuvre node method not too difficult, but it is a little time consuming and messy and just wondering if you've found any other practical solutions.

Thanks again for your epic work on this mod.

I don't think @PLAD has been around for almost a year, sadly.

[SSME reigns supreme]

I have a question: Flyby RSS gives some information about the maneuver in LEO required to achieve a calculated series of flybys. However, only the start inclination is given, e.g. 33°. But the thing is that there is an infinite amount of orbits with an inclination of 33°. So how do I know from your program which of those orbits is required when launching?