KSP Orbit Mechanic 1.2a: Optimize Your Orbits

[WX_Echo]

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

Make it an option in a config menu.

Indeed. The solution is simple and elegant, but I\'ll need to figure out how to do that and implement it properly. As with many things in Java, it\'s probably not too hard at all.

Thanks for the suggestion!

As an aside, I fully intend to collaborate with you on the 3D modelling capability you described. I have zero experience in 3D Java coding, so I\'m afraid you will end up doing all the heavy lifting. However, I would love to include it in a future version of KOM (KSP Orbit Mechanic) and provide you with developer credit.

I\'ll PM you once I\'m settled enough here to begin work on the next version.

[Warringer]

You do that.

And after you did that, I will try to see if I can come up with a decent implementation and API.

I think I start from scratch with a new display engine.

[Elladril]

Awesome calculator.. thanks so much! Hope to see you keep developing this and other addons

[WX_Echo]

Awesome calculator.. thanks so much! Hope to see you keep developing this and other addons

Thanks - I\'m glad you like it.

For all those waiting on an update, I\'m still getting settled into my new place. It will take me a while before I can devote any real time to the next update. Thanks again for your patience!

[Maraz]

Awesome calculator!

How do I get the game time of last sygyzy?

Thanks

Maraz

[WX_Echo]

Awesome calculator!

How do I get the game time of last sygyzy?

Thanks

Maraz

You estimate it based on the map view. In other words, what you\'re trying to do is advance time until your spacecraft and the target object have achieved opposition or conjunction (i.e. syzygy). Simply note the game time that this occurs in HH:MM:SS and input this data into the calculator. This method was chosen due to its simplicity; it\'s a lot easier to estimate when (i.e. the game time) a syzygy occurs than taking out a protractor and measuring angles on your monitor.

Please note that the syzygy data in the Hohmann and Bi-elliptic sections of v1.2a are different. The Hohmann section works as intended, allowing the user to indicate the time and type of syzygy to determine the appropriate burn time for intercept. The bi-elliptic section uses my old method of syzygy determination, which simply adds the synodic period of the two objects to the time indicated by the user. The latter scheme is too simple and will be augmented with the method currently utilized by the Hohmann transfer tab when I finish the next version.

Hope this helps!

[hubbazoot]

Excellent tool.

One request: I\'d like to see a way to see what my orbit looks like without knowing whether I\'m at the Ap or Pe, by entering in a declination and my current velocity.

[Nadrek]

This appears to be an amazing application for orbital mechanics, and could likely be useful with Orbiter as well as Kerbal!

I have a suggestion, a request, and a frivolous request:

Suggestion: As far as the thousands separator goes, yes, it\'s useful, but perhaps an option for scientific notation at whatever level of precision is requested would be useful as well, if a bit more complex?

Request: Molniya orbits.

Frivolous request: Computer support for both minimum time and maximum energy re-entry impacts at a defined point on Kerbal\'s surface, suitable for ortillery (orbital artillery) practice.

[Blackbird]

First: what a great tool to play with. It just helps me a lot since you can get sooo much information without a lot of typeing. Thank you a lot for that awsome tool.

But there is one thing that I think would be a nice little extra in your program. I like the part that you can see the Intercept Angle and even the time in your Hohmann Transfers part. But I think the angle is only usefull if your Target is something that you can actually see on your screen so you are able to read the angle from your HUD. But if you want to intercept e.g. an other ship its quite hard to figure out the angle since messurements on the map are quite....wrong, i guess. I figured out a nice little formula that can estimate, based on your intercept Angle, the distance between you and your target to start your intercept burn. Since you are able to see objects in space at about 100km distance at your HUD this is a nice alternative to intercept another spaceship or station.

Let me show you:

A = sqrt[ (Rb + Rk)² + (Rc + Rk)² - ( 2(Rb + Rk)(Rc + Rk)cosß) ]

A is the distance between you and your target to start the burn.

Rb is the targets orbital radius

Rc is your orbital radius

Rk is the radius of Kerbin

ß is the interception angle

so if you are on an orbit at about 680km and you want to intercept another ship at 700km you need a distance of 50,7km between you and your target to start the brun. I have tried this out a few times now and you can get to about 1km distance between you and your target if done right.

This was the closed one I achieved (3. try)

http://www.abload.de/img/screenshot106edev.png

I hope you did understand what I was talking about (my english, u know ;P ) and I hope this wasn\'t mentioned before since I haven\'t read the whole threat.

Have a nice day and keep it up!

[TelluriumCrystal]

Hi, I\'m looking to use this calculator to find an optimal method of performing a plane change. Unfortunately my understandings of orbital physics don\'t extend beyond Hohmann Transfers, which I routinely use to reach the Mun.

My goal is to achieve a polar orbit around the Mun from an orbit that is more or less in line with the equator (a 90-ish degree plane change).

I would just like to know what I need to enter and then how to make sense of the data that is output. Specifically what is the 'Midcourse Impulse Altitude'? Otherwise I think I understand what most of the information means, I just want some clarification before I risk sending some Kerbals to their deaths...

Thanks for any help!

[WX_Echo]

Hi, I\'m looking to use this calculator to find an optimal method of performing a plane change. Unfortunately my understandings of orbital physics don\'t extend beyond Hohmann Transfers, which I routinely use to reach the Mun.

My goal is to achieve a polar orbit around the Mun from an orbit that is more or less in line with the equator (a 90-ish degree plane change).

I would just like to know what I need to enter and then how to make sense of the data that is output. Specifically what is the 'Midcourse Impulse Altitude'? Otherwise I think I understand what most of the information means, I just want some clarification before I risk sending some Kerbals to their deaths...

Thanks for any help!

This is a great question!

I never did manage to publish any user-friendly guides on how to interpret some of this complex data, so I can imagine these features can seem rather opaque to the majority of users.

The best way to picture optimal plane change maneuvers is to understand your options: (a) a single-impulse maneuver or ( a three-impulse maneuver. In the single-impulse case, you stay at your initial/final orbit altitude and simply 'crank' your orbit to the desired inclination angle with a single delta-v. In certain cases, specifically when your desired inclination angle is greater than 38.94 deg (see graph below), it makes sense to perform your 'crank' maneuver at an altitude that is greater than your target orbit. This is due to the fact the that the amount of propellant required to execute an orbital plane change (i.e. the delta-v) is linearly dependent on the orbital speed at which the maneuver occurs. Conservation of angular momentum (or equivalently Kepler\'s 2nd) requires that our speed decrease as our altitude increase (i.e. constant areal velocity). Thus, the three-impulse maneuver takes advantage of the fact that the delta-v required to 'crank' our orbit to a desired inclination will be lower if we move the location of the plane change out away from the target orbit altitude (where we will be travelling at a lower speed).

To answer your specific question, the mid-course impulse altitude is simply the altitude at which this theoretical three-impulse maneuver takes place. The total maneuver would work like this: (1) utilize a co-planar transfer (delta-v) to get yourself on a transfer ellipse out to the mid-course impulse altitude; (2) once at this location, perform the orbit 'cranking' maneuver; (3) execute another co-planar transfer (since you are now at the desired inclination angle) back to the target altitude.

It turns out that for inclination angles between 38.94 (deg) and 60 (deg), the three-impulse maneuver is the minimum-fuel option; additionally, there is an optimal mid-course impulse altitude for each inclination angle in this region (it\'s actually a radius ratio, but the mid-course impulse altitude is known once the initial/final orbit altitude is specified). For desired inclination angles less than 38.94 (deg), you\'re better off performing the single-impulse maneuver at the original altitude (i.e. option (a) above). For angles greater than 60 (deg), we are limited to the bi-parabolic optimum solution. Otherwise stated, this scenario means that your efficiency will reach an asymptotic limit as you increase the mid-course impulse altitude (the theoretical limit occurs at R -> inf).

KSP Orbit Mechanic will determine the optimal maneuver based on your desired inclination angle and will specify the ideal mid-course impulse altitude for the orbit data provided. All you have to do is execute your burns with the right burn angle, as defined in the Single-Impulse Plane Change reference graphic, and hope for the best!

Please consider the following charts when visualizing these concepts:

Hope this helps!

[WX_Echo]

Just a quick update on where things are...

Thanks to all those who have provided feedback over the last couple of weeks. I\'m glad the tool is still relevant for those wishing to apply some of the more advanced optimal transfer schemes. Although it should be obvious, the recent proliferation of plugins and mods (e.g. telemetry, in-game autopilot, etc.) has rendered programs and applications that run outside of the game somewhat less useful. It\'s a pain to run the game windowed (or alt-tab constantly) to get your orbital data from a java tool that is completely decoupled from KSP.

Consequently, I\'ve decided to suspend further development of KSP Orbit Mechanic in its current form. I may release a final version that incorporates the latest celestial body, but I don\'t think it makes sense to keep working on an external Java application when the future of mods and plugins resides within the game environment. Complicating matters, the devs have indicated a desire to support maneuver scheduling, or some other form of maneuver autopilot (similar to MechJeb), in a future version. This may render some of my efforts superfluous.

As a result, I will cautiously explore the concept of porting some of the features provided in KSP Orbit Mechanic into an in-game plugin/mod that will (possibly) combine real-time telemetry and optimal (i.e. minimum fuel or time) orbital maneuvers with an in-game autopilot. I don\'t know if all of this is possible, or if I can develop the c# skills needed to get the job done (I\'ve worked with C, C++, Java, and MATLAB), but I\'m willing to give it a shot.

I will continue to provide forum support for KSP Orbit Mechanic in this thread, and I welcome your continued feedback. Believe it or not, I do have a list of user-requested features that I feel have a place in future iterations of the program. If my in-game plugin/mod concept takes shape, I will certainly try to incorporate them into the project.

Thanks for all your kind words and support!

[Ravenhold IV]

You guys are flippin\' geniuses. I\'ve seen many gyros in my time but that stuff on your calculator is unfathomably difficult for me to understand. Degrees are easy and as a result, I can understand the next intercept opportunity and intercept angle but that is it. Make a KSP Orbiter for Dummies book please. And how do I get off the launch pad at 2184.2376M/s?

[honza97]

Thanks god ! That\'s what I needed. It saved my time, when I was trying to hit Mun.

[noneyabidnis]

I\'m starting to gain a better understanding of the transfer orbit mechanisms, but have one question. The 'Bi-elliptic transfer' is supposed to be more efficient than all others for a Kerbin / Mun transfer, but wouldn\'t a properly timed Hohmann transfer be more efficient, in terms of landing on the Mun?

With the Bi-elliptic transfer, it seems like the first step is to generate a very long elliptical orbit that shoots out waaay past the moon.

Or is it that the Bi-elliptic transfer is more efficient if you actually want to build a circular orbit at 11,400 KM?

[semininja]

For ratios of inner to outer orbit that are high enough, a bi-elliptical orbit will actually save fuel. the 100km-to-11400km transfer is high enough, so long as your first transfer is a /lot/ farther; the higher your primary transfer orbit, the more efficient (I believe).

[sektis]

hello I\'m new and I want to know how to install your software if you have not a good tutorial to help me thank you in advance

(I\'m French so I did grieve clerical errors)

[semininja]

All you have to do is run the .jar file; there\'s no installation required.

[closette]

Bug report (sorry if this was already mentioned):

For an 'inner' bi-elliptic transfer from low to high (or an outer transfer high to low), the first of the 'delta-V's is negative, which is fine since you are slowing down, but for the total delta-V budget, you should add the absolute values of all the individual delta-v impulses because each impulse uses fuel regardless of direction.

To demonstrate, select 'Bi-elliptic', 'Kerbin', 'Low to High' and

Lower Orbit Altitude: 300 km

Higher Orbit Altitude: 2000 km

Midcourse Impulse Altitude: 100km

and you\'ll see that the 3 impulses are -128, 437, and 406 m/s, but the TOTAL is given as 715 m/s, which is misleading. It should be about 971 m/s.

OK not a very practical example but this bug also shows up when I try to plan high-to-low transfers around the Mun and it spoils an otherwise useful tool.

The V/V_c values also suffer from this bug. It might also affect the output under 'Bi-elliptic transfer analysis' as well.

By the way, this is a great utility and I hope you can maintain it, and perhaps add Minmus at some point. I like that it works 'standalone' so that I don\'t have to fire up KSP and rely on a bunch of add-ons.

[avidday]

Anyone else getting corrupt zip files when downloading?

[WX_Echo]

Bug report (sorry if this was already mentioned):

For an 'inner' bi-elliptic transfer from low to high (or an outer transfer high to low), the first of the 'delta-V's is negative, which is fine since you are slowing down, but for the total delta-V budget, you should add the absolute values of all the individual delta-v impulses because each impulse uses fuel regardless of direction.

To demonstrate, select 'Bi-elliptic', 'Kerbin', 'Low to High' and

Lower Orbit Altitude: 300 km

Higher Orbit Altitude: 2000 km

Midcourse Impulse Altitude: 100km

and you\'ll see that the 3 impulses are -128, 437, and 406 m/s, but the TOTAL is given as 715 m/s, which is misleading. It should be about 971 m/s.

OK not a very practical example but this bug also shows up when I try to plan high-to-low transfers around the Mun and it spoils an otherwise useful tool.

The V/V_c values also suffer from this bug. It might also affect the output under 'Bi-elliptic transfer analysis' as well.

By the way, this is a great utility and I hope you can maintain it, and perhaps add Minmus at some point. I like that it works 'standalone' so that I don\'t have to fire up KSP and rely on a bunch of add-ons.

Thanks for the bug report, Closette. It's good to hear the program is still useful.

I don't want to get anyone's hopes up, but I may be able to update the program to 1.3 soon. I can't give any reasonable time estimates, but it shouldn't take too long to add Minmus and address the issue you identified above.

I also want to apologize for the delay in my response. After the KSP forums migrated to the current solution, the auto-notification feature was disabled by default. I had relied on those notifications to let me know when someone responded to this thread. I should be able to respond faster going forward.

In other news, I'm watching this thread very closely.

Thread: Kerbal Space Program Trajectory Optimization Tool

While low energy transfers are very exciting, and are indeed quite useful for a variety of missions, they also come at a cost: long transfer times. This issue is mitigated by our ability to warp in KSP, but many may still prefer the traditional minimum-fuel solutions provided by the Hohmann and Bi-elliptic schemes. In any event, it's a tool worth watching.

Also, I removed the corrupted download links. Please use the paths indicated in my original post.

Edited August 20, 2012 by WX_Echo

[Arrowstar]

That's my thread and application. Feel free to post comments and suggestions if you have any.

[bigpapabearxx]

In the Hohmann Transfer turn the Syzygy time into the format of DD:HH:MM:SS. If you dont then you cant transfer from a kerbol orbit to a kerbin.

[WX_Echo]

In the Hohmann Transfer turn the Syzygy time into the format of DD:HH:MM:SS. If you dont then you cant transfer from a kerbol orbit to a kerbin.

Good suggestion. Let me see what I can do.

[kevthebrave3]

is this compatible with v0.16 of KSP