KSP Orbit Mechanic 1.2a: Optimize Your Orbits

[semininja]

I\'m glad to hear you\'re enjoying the calculator. I\'m working hard on the next version, and I hope it will add to the current features in a meaningful way. I\'ll drop an ETA as soon as I can.

As for your questions:

1) I\'ll look into ways of streamlining the data. I can appreciate the desire to make the most important information easily accessible. As for the user-customized data, that may be more difficult to code than it would seem (at least with my Java programming skills). I\'ll play around with some design tweaks and see what I can come up with.

Awesome. Hopefully you can come up with something, but if not, no worries.

2) I think I know what you\'re getting at here, but I\'m not sure how to implement this in a meaningful way. If I understand correctly, you would like to know how small perturbations in the intercept angle or impulse will affect your proximity to the edge of the sphere of influence? Perhaps a context would help me understand how you would like to use the data.

Basically, rather than a specific velocity and angle for the intercept, give a range within which you will intercept the body\'s sphere of influence, so we know how much \'fudge room\' we have.

3) I\'m already working on an improved intercept algorithm that provides the user with more meaningful information. Specifically, you will be able to enter the game time of the last sysygy (i.e. opposition, conjunction, inferior conjunction, or superior conjunction) and the game will use the synodic period and the transfer geometry to compute the game time of the next intercept opportunity (i.e. the time the user should initiate the transfer, or burn). I\'ve done some simple tests with this method and IMO it\'s far superior to methods that require the user to estimate the relative angular separation. If this doesn\'t seem helpful, please feel free to give me additional feedback.

What I meant was this:

If you\'re stuck in a transfer orbit, i.e. out of fuel or don\'t want to make any corrections, you\'d put in the angle formed by the apoapsis of your transfer orbit, the body you\'re orbiting, and the body you\'re transferring to, and the calculator spits out a time until you intercept the body\'s sphere of influence. Basically, if you miss capture the first time, how long\'s it going to take to catch up?

Incidentally, is it \'sysygy\' or \'syzygy\'?

[WX_Echo]

Thanks for the clarifications. I understand your intent behind point number two much better now. Let me work through the equations and see what I can come up with.

IRT to the third item, I should be able to work out the math for this as well. At first I thought the synodic period is what you were after, which represents the time between syzygy events (or intercept opportunities), but the scenario you\'re describing is slightly different (i.e. out of fuel on the transfer orbit or missed on the first attempt and desire to know the time until the phasing works out again). I\'ll post an update later this week when I\'ll have a chance to really sift through everything again.

Both of these features would make nice additions to their respective sections. Great suggestions!

Incidentally, is it \'sysygy\' or \'syzygy\'?

It\'s syzygy; I mis-typed it my previous post. Please let me know if you spot this error in the calculator.

[WX_Echo]

Just finished a great new reference graphic for some of the new data coming in v1.2.

During beta testing, my friend wanted to know where the optimal circularization location was in his elliptic orbit. After some time, and a few derivations, I have a nice little plot demonstrating the results:

Behold the power of apoapse.

Here\'s the updated UI (still in beta) for the elliptical orbits form: (notice the new circumference data for circular orbits) 8)

[Commander Zoom]

Amazing tool (if still rather intimidating - math was never my strong suit). I look forward to putting it in action, once I figure out how.

I can\'t help but think of it in the context of the software and hardware used to put the actual astronauts on the Moon, forty-plus years ago.

[WX_Echo]

Gents,

Just a quick update on progress for v1.2. I wasn\'t able to devote as much time to coding this weekend as I had planned; as a result, I wasn\'t able to finish all of the features I would like to include in the next release. Therefore, I have decided to delay publication until all the planned upgrades are completed. I don\'t want to provide a hard estimate, but I\'ll do my best to complete it within the next two weeks.

I really appreciate all the feedback provided thus far, and I hope to have some results to show for it very soon.

Thanks for your patience.

[semininja]

It\'s been a little while; could you give us an update on where the next version stands?

[WX_Echo]

It\'s been a little while; could you give us an update on where the next version stands?

I should thank SemiNinja for poking me out of my self-imposed coding exile. It has indeed been a while since my last update, due in large part to a rather hectic period at work. Sadly, as is the case with community addons like this calculator, updates can be sporadic and unpredictable. They often suffer when the programmers (in this case...just me) are diverted by other work-related projects. KSP orbit Mechanic has been a glorious labor of love for me, and I fully intend to continue to provide support for it whenever I can.

As for v1.2, the last three weeks have just been slow on the coding front. I have many of the planned improvements completed. The only section I have left to finish is orbit phasing. Unfortunately, I will have to postpone my plans for patched conic analysis until a later iteration. The benefit to this section will be rather limited until the game adds support for other planets. I had hoped to add Nova\'s proposed celestial bodies into my reference charts, but I have not had the time do this yet.

The good news is that v 1.2 is almost done (say ~80%) and my goal is to release it this weekend.

Thanks again for your interest and support! ;D

[Panichio]

Haven\'t downloaded the latest version yet. I was wondering if you fixed the calculations for Mun and Kerbol orbits... They were way off with the first release.

[WX_Echo]

Version 1.1 has been out for a while, and you\'re welcome to download it to test for issues. I\'m not aware of any problems with Mun or Kerbol data; however, I would welcome examples if you have them.

Can you provide me with any specifics? Screenshots would be best.

[WX_Echo]

Gents,

Although I wasn\'t able to complete all of the features I had hoped for the next version, I did manage to make enough progress to release something to you guys tonight. I don\'t feel comfortable calling it v1.2, as there are enough items missing to leave it short of my plans for the official v1.2 release. However, I will be travelling over the next several weeks and unable to work on the project until mid February. As a result, I would prefer to release a stable version of what is ready now, and add in the remaining items next month.

New in this version (v1.2a):

- Updated the main menu to properly sort reference diagrams and graphs.

- New graph indicating the cost to circularize an elliptical orbit as a function of your position in that orbit. This graph conclusively indicates that the minimum-fuel location for such a maneuver is at the apoapse of the elliptic orbit.

- Clear buttons now reset combination boxes to their default values.

- Changed the default position of the GUI when loading the program. The calculator will now detect your screen resolution and adjust its starting position based on your monitor properties.

- Improved the interface and data offered in the 'Circular Orbits' form.

- Improved the interface and data offered in the 'Elliptical Orbits' form. Added a 'Dynamic Orbital Data' section which provides relevant parameters based on your current altitude (e.g. current speed, delta-v to circularize, flight path angle, true anomaly, etc.). I\'m a big fan of the elliptic orbit circumference data now available.

- Augmented the 'Hohmann Transfers' section to include all of the data now provided by the 'Elliptical Orbits' form. Modified the 'Next Syzygy' section to allow the user to specify the game time (in HH:MM:SS) of the last syzygy. With this data, KSP Orbit Mechanic will now provide the game time of the next opportunity for intercept. Please note: to use this function, simply note the game time that your spacecraft and the target object (e.g. the Mun) are aligned in a straight line configuration. Select the kind of syzygy observed (i.e. opposition, conjunction, inferior conjunction, superior conjunction) and the calculator will tell you when to execute your maneuver. This feature, if used properly, is tremendously useful for orbit transfers. 8)

Planned updates remaining:

- Orbit phasing

- Next syzygy calculations as described above for Bi-elliptic transfers.

- Several community-requested features (I haven\'t forgotten about you guys)

- YouTube 'how to' videos.

- Collaborative features with Warringer (developer of KSP Calculator).

Thanks again for your patience. My work schedule has been unusually busy recently, and I haven\'t been able to devote as much time to playing KSP and coding for this project. I\'ll do my best to keep the future updates timely and relevant.

Download KSP Orbit Mechanic 1.2a

[ThaineFurrows]

Awesome, love it...

[Krenn]

I\'m using this to calculate munar intercepts, and it works fine... except i keep reaching the munar sphere of influence while I\'m in front of the moon. How do i calculate when to burn in order to aproach the Mun from slightly behind, giving me a gravity boost?

[WX_Echo]

Although I didn\'t explicitly break this out in my planned features section, I intend to add support for this kind of consideration in the full version of 1.2.

In the interim, I would recommend a very slight delay in your burn time (i.e. wait a small amount of time after the recommended burn time). This will have your spacecraft enter the Mun\'s SOI from the 'backdoor.' The exact amount will vary, so you\'ll have to use some old fashioned intuition until I can code support for this feature.

Have you found the next syzygy section useful? If users understand its function properly, it has the ability to tell you exactly when to execute your burn.

Thanks for the feedback!

[Krenn]

Have you found the next syzygy section useful? If users understand its function properly, it has the ability to tell you exactly when to execute your burn.

yes, i\'ve been using it consistently.

[WX_Echo]

Glad to hear it.

It actually took quite some time to code, as the initial configuration used to specify the type of syzygy changes the equation needed to compute the burn time. I have a whole white board full of derivations for just this feature. Doing the same for Bi-elliptic transfers will also be a tough project.

The ability to enter the Mun\'s SOI from the 'backdoor' is essentially equivalent to some feedback I received from another user. The goal is to provide a burn range that will satisfy intercept condition such that you have the entire SOI to work with.

Please let me know if you have any more questions.

[LambdaCactus]

Just a few questions about using this for the Hohmann transfers:

Do you need to factor in any time for your ship to accelerate?

At the end of the burn when the engines are cut, the ship immediately starts losing speed since it\'s in a steeply climbing orbit. How do you know you\'re at the right speed if the speed is being drained away during the whole burn? Is there a way to fine-tune it?

What about the angle? If the ship is gyroscopically pointed at the horizon (aligned with the flat orbit) at the start of the burn at the intercept time, does it matter how long the acceleration goes in that constant direction, or should the ship be continuously adjusted to the horizon during the whole burn?

Do the high-to-low transfers work for prograde only? Which side of the orbit do you calculate from?

[WX_Echo]

Do you need to factor in any time for your ship to accelerate?

No. The equations used to calculate this data assume that the thrust applied by the spacecraft\'s engines are applied instantaneously (i.e. an impulse). As with real spacecraft, as long as the duration of the burn is relatively short (e.g. on the order of a couple of minutes or less), this assumption is valid. Note: for high-thrust chemical engines, this almost always holds for short 'impulsive' burns; low-thrust engines that use electric propulsion (e.g. ion) that must be fired over a long period are not ideal candidates for this assumption.

At the end of the burn when the engines are cut, the ship immediately starts losing speed since it\'s in a steeply climbing orbit. How do you know you\'re at the right speed if the speed is being drained away during the whole burn? Is there a way to fine-tune it?

Don\'t worry about the dropping speed at the end of your burn. The equations assume that the impulsive energy transfer (i.e. the burn) occurs at the periapse or apoapse of the transfer ellipse. As with the previous question, everything is fine so long as the duration of your burn was relatively short (i.e. on the order of a few minutes or less). The goal is to achieve the indicated injection speed as quickly as possible (to satisfy the impulsive transfer approximation); once you have, you\'re fine to let the spacecraft drift along the transfer ellipse until you arrive at the target.

The Hohmann transfer data takes into account the 'dropping speed' that you describe, because this is exactly what is predicted by the governing equations Kepler and Newton provided us. In it\'s most elegant form, this falling speed (when gaining altitude) is a result of the conservation of angular momentum for your spacecraft\'s orbit; a line connecting the central body and your spacecraft will always sweep out equal areas in equal time. This means your orbital speed must decrease as your radius/altitude increases. The calculator takes all of this into account.

What about the angle? If the ship is gyroscopically pointed at the horizon (aligned with the flat orbit) at the start of the burn at the intercept time, does it matter how long the acceleration goes in that constant direction, or should the ship be continuously adjusted to the horizon during the whole burn?

Unless you desire to change the plane of your orbit, you should attempt to execute your burns so that your spacecraft remains in the same plane. Here again we benefit from the impulsive orbit assumption; as long as the duration of the burn is short, you don\'t really have to worry about this. When your spacecraft is at periapse (for a low-to-high transfer) or apoapse (for a high-to-low transfer), your instantaneous velocity vector will appear to have zero inclination (i.e. 'flat') on the nav-ball; you should burn prograde (for low-to-high) or retrograde (for high-to-low) at max thrust to achieve the transfer ellipse injection speed indicated by the calculator as quickly as possible. This will maximize the accuracy of the governing equations and improve your transfer maneuver.

Do the high-to-low transfers work for prograde only? Which side of the orbit do you calculate from?

I think this question was answered above, but I\'ll add a few more items. When transferring from high to low, you actually need to reduce your orbital speed to place yourself on a transfer ellipse that takes you closer to the dominate central body. In this case, you would burn retrograde at both the periapse and apoapse of the transfer ellipse. The final burn removes energy from your orbit so that you achieve the desired inner target circular orbit.

Hope this answers your questions!

[LambdaCactus]

Thanks, that helps!

I understood that the equations rely on an instantaneous impulse, so that\'s why I was wondering whether the couple minutes to accelerate needed any tuning. For a moderately massive ship, it takes about 90 seconds to get up to speed. A larger ship or a ship with low thrust could take more than a few minutes. I guess I was wondering how you know when you\'ve hit the target speed. Close enough; as quick as possible seems to be the answer: I shouldn\'t try and chase the last 50 m/s as I watch the speed bleed away when I cut the engines.

When transferring from high to low, you actually need to reduce your orbital speed to place yourself on a transfer ellipse that takes you closer to the dominate central body. In this case, you would burn retrograde at both the periapse and apoapse of the transfer ellipse. The final burn removes energy from your orbit so that you achieve the desired inner target circular orbit.

What I was asking was whether this works for either direction orbiting the moon. A free-return trajectory with lunar orbit insertion will put you in retrograde orbit, so you have to burn on the far side to transfer back. A prograde lunar orbit would have you burn on the near side. Since transfer path gets curved in opposite directions by the moon\'s gravity in each of these situations, how much does it matter?

[WX_Echo]

I guess I was wondering how you know when you\'ve hit the target speed. Close enough; as quick as possible seems to be the answer: I shouldn\'t try and chase the last 50 m/s as I watch the speed bleed away when I cut the engines.

Although I\'m sure you\'re already doing this, please note that the Hohmann transfer (and my calculator) assumes you start from a circular orbit.

The calculator will provide the initial circular orbit speed for your parking orbit (which should closely match your nav-ball data before the burn is executed), the final desired speed (i.e. the transfer orbit injection speed) when the burn is complete (which you can easily match by burning until your nav-ball speed matches the desired speed), and the delta-v of the maneuver. Your nav-ball has no delta-v indicator so you\'re simply matching the final speed the calculator provides for the specified transfer.

With respect, I\'m confused why you might leave 50 m/s unaccounted for; you should have no problem matching the exact transfer injection speed provided by the calculator. The theory behind the Hohmann transfer, as you might be aware, assumes that the impulse happens instantaneously so that the initial circular orbit velocity and final transfer ellipse injection velocity occur at apoapse or periapse. The fact that the burn take place over a finite amount of time will have a trivial impact on the transfer so long as the burn time is relatively small (as previously discussed).

What I was asking was whether this works for either direction orbiting the moon. A free-return trajectory with lunar orbit insertion will put you in retrograde orbit, so you have to burn on the far side to transfer back. A prograde lunar orbit would have you burn on the near side. Since transfer path gets curved in opposite directions by the moon\'s gravity in each of these situations, how much does it matter?

Only the intercept features of my calculator (i.e. the next syzygy time) are sensitive to the direction of the orbit. The equations I used required assumptions about the intercept geometry that were greatly simplified by assuming prograde orbits. A true free-return trajectory requires no burns to return to the initial celestial body, so I\'m also confused with the retrograde/prograde burns you\'re describing.

Just in-case I\'m not reading your question correctly, the orbit orientation around the Mun will not significantly impact the standard transfer equations from the Mun back to Kerbin. The patched conic method would be affected, as would intercept/rendezvous considerations. A simple transfer ellipse (a hyperbola from a Mun-orbit perspective) to get you outside of the Mun\'s SOI should be fine, though. Since the Mun and its SOI lie entirely within Kerbin\'s SOI, I\'m careful here not to say that the spacecraft re-enters Kerbin\'s SOI. This is precisely why the patched-conic method breaks down for Kerbin-Mun transfers (and Earth-Moon transfers too).

Tricky technical questions like this can be difficult to answer via text. I hope I\'ve gotten closer to your questions and provided relevant answers. If not, I\'ll be happy to keep trying!

Thanks again for the feedback! Hope the calculator is proving helpful.

[LambdaCactus]

With respect, I\'m confused why you might leave 50 m/s unaccounted for; you should have no problem matching the exact transfer injection speed provided by the calculator.

It can be hard to hit the shutoff at just the right time when the m/s numbers are flying by. If you burn 100% throttle and try to cut it using the X key at the right moment, it\'s hard to hit the right number, and then it immediately starts bleeding off. If you slow your burn as you approach the target speed, or make small adjustments after the burn, it seems like you\'re 'chasing' a target number, or trying to maintain a speed that should have already bled off, in effect ending up faster than you should be.

The theory behind the Hohmann transfer, as you might be aware, assumes that the impulse happens instantaneously so that the initial circular orbit velocity and final transfer ellipse injection velocity occur at apoapse or periapse. The fact that the burn take place over a finite amount of time will have a trivial impact on the transfer so long as the burn time is relatively small (as previously discussed).

Maybe I\'m overthinking it. It\'s just that after the theoretical 'instantaneous impulse', the speed naturally starts to drop as it gets exchanged for altitude. I haven\'t yet measured how much speed might be lost in the first 90 seconds of a steep transfer orbit, but if that\'s how long my ship takes to accelerate to the transfer orbit and I\'m trying to match a calculated speed I should\'ve theoretically had 90 seconds ago, then shouldn\'t my target speed be slower by that much?

90 seconds is 5% of the low orbit period; it\'s 18-ish degrees. I guess I\'m wondering what does that margin play out to? Is the difference just the extra distance travelled in my low orbit, or is the error magnified at the far end at all?

Only the intercept features of my calculator (i.e. the next syzygy time) are sensitive to the direction of the orbit. The equations I used required assumptions about the intercept geometry that were greatly simplified by assuming prograde orbits. A true free-return trajectory requires no burns to return to the initial celestial body, so I\'m also confused with the retrograde/prograde burns you\'re describing.

I meant a FRT approach to the moon, where you arrive in front of the moon, then insert into orbit coming around the far side (retrograde). The question was about the differences in the return transfer from different orbit directions.

Just in-case I\'m not reading your question correctly, the orbit orientation around the Mun will not significantly impact the standard transfer equations from the Mun back to Kerbin. The patched conic method would be affected, as would intercept/rendezvous considerations. A simple transfer ellipse (a hyperbola from a Mun-orbit perspective) to get you outside of the Mun\'s SOI should be fine, though.

What I meant was if you do your return transfer burn from the far side, the moon\'s gravity curves the path inward (towards home). If you\'re orbiting the other way (prograde) and your return transfer burn happens on the moon\'s near side, then the moon\'s gravity curves the path outward (away from home).

In practice, the paths off the Mun are pretty straight once you get hyperbolic speed and the game is quite forgiving, so it\'s inconsequential here, really. But would transferring off a more massive outer planet make this significant?

I\'m just curious how the calculations work, and what they might/might not account for. I never studied the maths, but lately I\'ve been picking it up a bit of recreational learning so it\'s fun to have toys like this to see it in action!

[semininja]

The difference you\'re describing can, in fact, make a considerable difference on the other end of the orbit. In my experience, you can miss your target orbit by a fair amount for the exact reasons you\'re describing.

[flap]

Hello ! That tools looks very useful (but might require some time to master...).

A suggestion though : would it be possible to have thousands separators for an easier reading of large figures ?

[WX_Echo]

Hey gents,

I just wanted to check-in after a rather long delay in responding to this thread. I just finished moving across the country (from the East to the West Coast of the U.S.), and I finally have my gaming computer back online. I will attempt to reengage some of the user-requested features in my next update and clean up some loose ends from the last version (i.e. 1.2a).

I\'m grateful for the feedback everyone has provided and your patience with my development delays. My family and work responsibilities must come first, and as you can image, the move consumed almost all of my time during February.

I\'ll provide another update when I have something meaningful to share. No promises or timetables; just a reminder that I\'ll do my best.

Please feel free to provide any comments or ask questions about specific features (either implemented or planned).

[WX_Echo]

Hello ! That tools looks very useful (but might require some time to master...).

A suggestion though : would it be possible to have thousands separators for an easier reading of large figures ?

Perhaps, although this is not common is most engineering applications and I don\'t personally prefer this format. I would be curious if other folks would like this added. However, I\'m willing to be persuaded.

[Warringer]

Perhaps, although this is not common is most engineering applications and I don\'t personally prefer this format. I would be curious if other folks would like this added. However, I\'m willing to be persuaded.

There\'s a nice simple way of dealing with that.

Make it an option in a config menu.