transfer calculator [1.12] Astrogator v1.0.1

[HebaruSan]

Astrogator    

A space-navigational aide for Kerbal Space Program.

See all the transfers that you could choose from your current location at a glance, including the time till the burn and delta V, and turn them into maneuvers with one click.

Automatic maneuver node creation

When you're piloting a vessel, maneuver node icons will appear next to the delta V numbers. Click to create maneuver nodes for that transfer:

These typically give immediate encounters for transfers to the Mun from low Kerbin orbit, and sometimes Minmus, Duna, and Jool, but some adjustment is usually needed for other destinations.

Time warping

Click a warp icon to warp to 5 minutes before the corresponding transfer. If it's already within 5 minutes, you'll be auto-warped to the exact time of the transfer.

More transfers, fewer clicks

• Shows transfers for all main reachable spheres of influence, including from parent spheres of influence, not just bodies with the same parent
• Supports transfers to vessel's target, regardless of what it is
• Handles "nested" ejection burns, such as when you need to burn at the right time to escape Laythe at the right time to escape Jool at the right time to reach Kerbin
• Supports burns to bodies within the current sphere of influence, such as the moons of Kerbin from low Kerbin orbit
• Uses the active vessel's location and orbital parameters to fill in as many of the input parameters as it can
• Shows you the results in zero clicks
• Integrates with the game to streamline use of the data
• Moves the map view focus automatically
• Sets the vessel's target
• Automatically opens maneuver nodes for editing

 

Download: https://github.com/HebaruSan/Astrogator/releases

Where to report bugs: https://github.com/HebaruSan/Astrogator/issues

Source and documentation: https://github.com/HebaruSan/Astrogator

License: GPL v3, some icons and parts of code are MIT

Acknowledgements: Borrowed icons from Kerbal Alarm Clock, some code from Kerbal Alarm Clock, Transfer Window Planner, and MechJeb2

Language	Translators
Spanish	Iván (hashashin), @Deltathiago98, @fitiales
Chinese	@QAQdong
Russian	Niev, @Sooll3
French	@valens
Italian	Leonardo Ascione

 

 

 

Edited June 24 by HebaruSan

[drtedastro]

interesting.  will take a look.

cheers.

[jlcarneiro]

Looks promising!

Thanks!

Haven't tried the plugin yet, but checked the documentation: it's great! Thanks again!

Edited February 5, 2017 by jlcarneiro

[jlcarneiro]

I've quickly tried the plugin. It's great!

But I have a question/suggestion: when the ship gets to space (and enters orbit), the plugins automatically tries to create a node. Although I liked the documentation, I confess I couldn't find how to disable this auto generation...

[White Owl]

How does this mod handle customized systems? Particularly a system with lots of additional bodies and all orbits inclined, similar to Real Solar System?

[HebaruSan]

2 hours ago, jlcarneiro said:

I've quickly tried the plugin. It's great!

Glad you like it!

2 hours ago, jlcarneiro said:

But I have a question/suggestion: when the ship gets to space (and enters orbit), the plugins automatically tries to create a node. Although I liked the documentation, I confess I couldn't find how to disable this auto generation...

So it's creating a maneuver node for you automatically, and the node sticks around? It's not supposed to do that, so I think we can count this as the first bug report; thanks! Does it happen as you cross 70 km (entering space) or as your periapsis gets above 70 km (orbiting), or something else? I flew out to Duna with it just now and didn't notice anything out of the ordinary, so I'll need more info to figure out what's going on.

(It is intentional that it creates a node and deletes it right away sometimes, so if that's what you're seeing, try to ignore it for now. If you want to disable that, you'd have to turn off calculation of plane change burns. It's just easier to let KSP do some of the math for us at this point, but long term I hope to eliminate this.)

37 minutes ago, White Owl said:

How does this mod handle customized systems? Particularly a system with lots of additional bodies and all orbits inclined, similar to Real Solar System?

Extra custom bodies shouldn't be a problem since it inspects whatever solar system you have loaded for all calculations, but I'm not sure how much of a problem the inclined orbits would be, if any. If your ship's inclination is 30° or greater, it'll refuse to calculate, but there isn't anything like that for the bodies themselves. In theory it should just give you huge plane change burns. I'll try it on my copy of RSS...

[HebaruSan]

1 hour ago, White Owl said:

How does this mod handle customized systems? Particularly a system with lots of additional bodies and all orbits inclined, similar to Real Solar System?

Turns out it's not too bad. Overview from tracking station, superimposed on SQUAD's homeland:

Here's what those transfers look like from LEO without any manual adjustments:

Spoiler

Mercury shows close approach markers somewhat nearby:

Venus likewise:

Mars doesn't look great, but I didn't experiment to see just how far off it is if you add more thrust:

Jupiter gets an encounter directly from the auto-generated nodes:

As does Saturn:

I'm not sure what happened at Uranus. There might be an unintentional gravity assist messing this up:

Neptune looks decent:

Finally, Pluto puts us on an escape trajectory:

So depending where you're going, it can still be useful. I think it's saved by the fact that the Earth has a similar inclination, so the interplanetary plane changes aren't too severe.

[Cheesecake]

6 hours ago, HebaruSan said:

Glad you like it!

So it's creating a maneuver node for you automatically, and the node sticks around? It's not supposed to do that, so I think we can count this as the first bug report; thanks! Does it happen as you cross 70 km (entering space) or as your periapsis gets above 70 km (orbiting), or something else? I flew out to Duna with it just now and didn't notice anything out of the ordinary, so I'll need more info to figure out what's going on.

 

I have the same issue. The node is createt directly after launch.

[HebaruSan]

18 hours ago, jlcarneiro said:

But I have a question/suggestion: when the ship gets to space (and enters orbit), the plugins automatically tries to create a node. Although I liked the documentation, I confess I couldn't find how to disable this auto generation...

 

9 hours ago, Cheesecake said:

I have the same issue. The node is createt directly after launch.

Thanks for the reports. I have created a new release that ought to help with this; it's admittedly a bit of guesswork when I can't see the problem happening myself. Either way, debugging output is now on, so your KSP.log file should be more useful if problems crop up. Please give it a try at your convenience.

https://github.com/HebaruSan/Astrogator/releases/tag/v0.1.1

[hab136]

Neat!

How does the accuracy of the calculated trajectory compare to Transfer Planner/Kerbal Alarm Clock/MechJeb/KSP Trajectory Optimization Tool?

Can it sort by encounter time instead of planet position?

[Wallygator]

Excellent work!

nice name as well.  

[Hesp]

Excellent tool, thanks!

Is there any software limitation in computing nodes while in retrograde orbit? Looks like you have to be within 30° from a prograde orbit for it to work.

Yesterday I launched some vessels from Mun station (retrograde orbit) to Duna, and I'd like to check the tool's efficiency with these transfers vs. manual node placement.

As for the reported bug, I saw a node spawn also during a manual deorbit burn (definitely not a big issue, but maybe is useful for tracking down the problem). This evening I'll try with the new release.

 

[HebaruSan]

5 hours ago, hab136 said:

Neat!

4 hours ago, Wallygator said:

Excellent work!

nice name as well.  

3 hours ago, Hesp said:

Excellent tool, thanks!

Thanks for your kind words!

5 hours ago, hab136 said:

How does the accuracy of the calculated trajectory compare to Transfer Planner/Kerbal Alarm Clock/MechJeb/KSP Trajectory Optimization Tool?

The accuracy should be the same as TWP/KAC (in "formula" mode, not the precalculated "model" mode); I used them as a comparison/reference during development to make sure it was working properly, and in some cases I used their actual code (see the Acknowledgements line). I have not done direct comparisons to transfers calculated by MechJeb and TOT, but I'd be curious to know what you find if you try it.

5 hours ago, hab136 said:

Can it sort by encounter time instead of planet position?

Not yet, but that's going onto the planned features list right now!

3 hours ago, Hesp said:

Is there any software limitation in computing nodes while in retrograde orbit? Looks like you have to be within 30° from a prograde orbit for it to work.

The tricky thing is that in, say, a polar orbit, you only get good ejection trajectories in two directions (along the intersection of the plane of the orbit and the equatorial plane). That would limit which transfers we can use, whereas an equatorial orbit has the full 360° of ejection angles available.

<30° retrograde should be do-able with some refactoring, though; I'll put that on the list. Thanks for the suggestion!

[Hesp]

Regarding the high inclination orbits, I totally agree with you. They can be ignored when looking for transfer windows.

 

The manouver node still pops up as soon as I hit spacebar for launch, even with the new release.

It appears also when:

- your Pe gets inside atmosphere

- you actually reentry in the atmosphere

I tried to take a series of snapshots while performing the reentry burn, hope it helps:

http://imgur.com/a/Wrfsv

 

 

[HebaruSan]

On 2/6/2017 at 3:06 AM, hab136 said:

Can it sort by encounter time instead of planet position?

On 2/6/2017 at 4:53 AM, Hesp said:

Is there any software limitation in computing nodes while in retrograde orbit?

I'm pleased to announce the v0.2.0 release; in one image:

• Click the headers to sort transfers
• Support for retrograde orbits
• Option for United States customary units (off by default )
• Still more attempts to avoid unintentional generation of maneuver nodes

Last but not least, we're now indexed on CKAN. 

https://github.com/HebaruSan/Astrogator/releases/tag/v0.2.0

[Hesp]

First feedback for the new version: dV for retrograde orbits are calculated correctly: I got 422 m/s for a Mun-Duna burn that matches my previous launches in the current transfer window. 

There seems to be an issue with node placement though: the final trajectory is nowhere close to a Duna encounter. Screenshots attached:

http://imgur.com/a/yFdcC

Actually it places the manouver 2y, 47d in the future while the correct timing (due to Mun position around Kerbin) is in about 2 days.

Thinking a bit more, 2y47d is the next Duna transfer window. This could leave room for improvement.

 

What about an option like "calculate dV for a transfer within X days" instead that giving only the best dV attainable?

[HebaruSan]

30 minutes ago, Hesp said:

First feedback for the new version: dV for retrograde orbits are calculated correctly: I got 422 m/s for a Mun-Duna burn that matches my previous launches in the current transfer window. 

Cool! Thanks for testing it out. I have to admit it's fun to see it in other people's screenshots.

30 minutes ago, Hesp said:

There seems to be an issue with node placement though: the final trajectory is nowhere close to a Duna encounter. [...] Thinking a bit more, 2y47d is the next Duna transfer window. This could leave room for improvement.

So is the problem that it's creating a node that isn't close to a potential encounter, or that it's skipping what appears to be the soonest transfer?

If the latter, then yeah, it's not overly sophisticated about imminent/current transfers; regardless of the actual sensitivity of the orbits, it'll pick one instant in time as the time to burn for that window based on the phase angles and ejection angles and so forth, and once you pass that instant it goes to the next window, even if you only missed it by a few minutes or seconds and could actually still transfer now without problems. So in your case, it probably thinks that your current transfer time was a few hours or days ago (might be interesting to confirm that by save-editing yourself back in time). I'll look for ways to make it more forgiving, but I confess I don't have a clear idea of how to do that at the moment.

30 minutes ago, Hesp said:

What about an option like "calculate dV for a transfer within X days" instead that giving only the best dV attainable?

I'd prefer to get it to a state where it "just works" and does something sensible without making the user worry about the details of the calculations. (Also, this may be a technical TMI, but currently there's no hard and fast distinction in the code between, say, a transfer to Duna from Kerbin and a transfer to Mun from LKO, and "X days" of flexibility wouldn't translate well to Mun transfers.)

[Hesp]

You're welcome! I'm using it in career, so as soon as i have a rocket on the launchpad I'll check also the node spawning bug

The game date is Y1D235, so 4 days past the "sweet spot" to Duna from Munar orbit. The main issue was that the generated node was completely off. Looking at the screens it was ejecting me 90° from prograde.

Just tried to set up a Mun-Minmus transfer from retrograde: the main ejection seems right-ish - no encounter but after few small corrections I got it. 

 

 

[HebaruSan]

12 minutes ago, Hesp said:

The main issue was that the generated node was completely off. Looking at the screens it was ejecting me 90° from prograde.

I think that may be because the burn was 2y 47d into the future, and Kerbin's prograde direction will have rotated about 40° by then. From the zoomed out solar orbit it looks correct for that future timeframe, since your projected solar Pe was right at Kerbin's orbit, and a non-aligned ejection burn generally doesn't do that.

 

[Hesp]

3 minutes ago, HebaruSan said:

I think that may be because the burn was 2y 47d into the future, and Kerbin's prograde direction will have rotated about 40° by then. From the zoomed out solar orbit it looks correct for that future timeframe, since your projected solar Pe was right at Kerbin's orbit, and a non-aligned ejection burn generally doesn't do that.

 

Probably yes, I didn't consider the 47 extra days.

Changing subject, the manouver node didn't appear during reentry but I noticed an Astrogator spam in the alt+F12 console:

http://imgur.com/a/WvLKc

 

 

 

[HebaruSan]

Just now, Hesp said:

Changing subject, the manouver node didn't appear during reentry but I noticed an Astrogator spam in the alt+F12 console:

http://imgur.com/a/WvLKc

Oh, that's just some harmless debugging output (it's reporting that your semimajor axis has changed enough to require transfer recalculation, which I certainly hope it would during re-entry ). I'll turn all of the debugging messages off in a future release once I'm confident that they're no longer needed.

[Hesp]

1 minute ago, HebaruSan said:

Oh, that's just some harmless debugging output (it's reporting that your semimajor axis has changed enough to require transfer recalculation, which I certainly hope it would during re-entry ). I'll turn all of the debugging messages off in a future release once I'm confident that they're no longer needed.

Oh haha sorry for that!

[HebaruSan]

Just now, Hesp said:

Oh haha sorry for that!

No problem; in fact, up to now I had been closing KSP and opening the log file to see that output, so you showed me a more convenient way to view it. Thanks!

[Jebs_SY]

@HebaruSan

The .version file in the 0.2-release-zip on github says Astrogator-0.1.1.0. So maybe that was forgotten to update?
The version in the .version-file is analyzed by CKAN to determine if this is an newer version, AFAIK.
And, according to the AVC specification, the .version file MUST include a "KSP_VERSION". "KSP_VERSION_MIN" and "KSP_VERSION_MAX" are optional. This could confuse CKAN.

Edited February 9, 2017 by Jebs_SY

[HebaruSan]

1 minute ago, Jebs_SY said:

The .version file in the 0.2-release-zip on github says Astrogator-0.1.1.0. So maybe that was forgotten to update?

Yes, I just noticed that and pushed a new copy of the version file, but I don't want to change the zip file in-place because CKAN keeps checksums of the downloads, which would break installation until the crawler runs. My apologies, I'm still getting accustomed to all the steps needed to create a full release. Luckily the CKAN fields still have the right version somehow:

        "Astrogator": {
            "module_version": {
                "v0.2.0": {
                    "version": "v0.2.0",

1 minute ago, Jebs_SY said:

And, according to the AVC specification, the .version file MUST include a "KSP_VERSION". "KSP_VERSION_MIN" and "KSP_VERSION_MAX" are optional. This could confuse CKAN.

I'm not 100% sure of that... http://ksp.cybutek.net/kspavc/Documents/README.htm

• KSP_VERSION - Optional, Required for MIN/MAX
  Version of KSP that the add-on was made to support.

That phrasing isn't very clear, but I took it to mean you either need KSP_VERSION by itself, or KSP_VERSION_MIN and KSP_VERSION_MAX. I'm not sure what the advantage of providing all three would be; if anything, it could cause confusion by giving conflicting impressions of the scope of compatibility. Looking at the registry.json file, that does seem to be how existing mods use these fields, and my data seems to be in line with others':

        "ABCORS": {
                    "ksp_version": null,
                    "ksp_version_max": "1.2.99",
                    "ksp_version_min": "1.2.0",

        "AT-Utils": {
                    "ksp_version": "1.2.2",
                    "ksp_version_max": null,
                    "ksp_version_min": null,

        "Astrogator": {
                    "ksp_version": null,
                    "ksp_version_max": "1.2.99",
                    "ksp_version_min": "1.2.2",

As a point of comparison, KER (originally written by the author of the KSP-AVC spec, if I'm not mistaken) seems to use my interpretation in its version file, so I think I'll leave it as-is for the time being:

https://github.com/CYBUTEK/KerbalEngineer/blob/master/Output/KerbalEngineer/KerbalEngineer.version