WX_Echo

Sadly, no ETA at this time. I apologize to those who were hoping to have the calculator available with the release of 0.17. I will try to provide an update when I have something to share.

KOM 1.2a doesn't run inside the game environment, so it's compatible with all versions of KSP. I haven't added Minmus data to the calculator yet, so in that sense it's not entirely 0.16 capable. Otherwise, you should be good to go. As an aside, I will add Minmus data into the next update, which will be available after 0.17 is released. If I'm going to open up the code again, I want to wait for all of the new celestial bodies.

Good suggestion. Let me see what I can do.

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.

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!

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!

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!

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!

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.

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.

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).

Although it appears you\'ve found an operational solution to your problem, the theoretical tools to solve the standard intercept condition are available in my Java calculator. This example assumes a simple intercept scenario in which the target object (could be a celestial body or a spacecraft) is orbiting in a circular orbit at a larger orbital altitude than your spacecraft (which is assumed to also be in a circular orbit). For the image I assumed your spacecraft is in a parking orbit of 150 km around Kerbin and the target craft is at 500 km. If the two objects are in opposition at time zero (you could use the actual game time of your situation as well), then you should burn at time 01:13:21 (HH:MM:SS); this will provide you with the intercept angle needed to intercept the target. All of the actual Delta-V data (first and second burn values) are provided as well. Hope this helps! FYI - It is my intent to include support for orbit phasing in my next update.

This is also my understanding. It would be nice to have proper units indicated for all parameters in the game.

This is correct. I would add that the Keostationary orbit requires a circular orbit, zero orbit inclination, and the aforementioned orbital altitude and speed. Keosynchronous is less restrictive in the sense that only the orbit period must match the rotation period. This means a Keosynchronous orbit could be an ellipse with any inclination (including zero). The good news is that we\'re all on the same page!

That\'s a wonderful video! Great music selection as well.

Perhaps I just misread your intent. I interpreted the thread to be describing a the method of obtaining a Keostationary orbit over a desired point. Yet, use use the term Keosynchoronous several times. The context with which you used the latter term lead me to believe you should have been using the former in your description. It\'s clear from your post you have the theory behind both down; apologies if my post indicated otherwise. I have no desire to start a silly semantics debate. Thanks again for the tips!

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). 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.

You can lead a horse to water, but you can\'t make him drink. From KSP Orbit Mechanic v1.2a:

Thanks SN! He\'s right; all of this data, and quite a bit more, is available in KSP Orbit Mechanic. Check out the 'Celestial Bodies' reference table for more information. FYI: you can even normalize your selected data to any celestial object in the game, and even a few in our solar system. Also, as mentioned above, G is simply a constant of proportionality that allows us to match theoretical equations to empirical results. The value is constant everywhere in the universe, at least with our current knowledge of physics, and is usually not as meaningful as the gravitational parameter for a celestial body. This data is also provided in my calculator. Hope this helps! Happy orbiting!

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. 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. 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. 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!

My calculator will solve all of this in closed form for you! You put a lot of unnecessary effort into this analysis. I highly encourage everyone attempting to perform orbit cranking (orbit inclination changes) to check the 'Plane Changes' section in KSP Orbit Mechanic. Please check out the optimal plane change reference graphics for a detailed comparison. Hope this helps!

Be careful with the keosynchronous term. I believe you mean to say keostationary. Any orbit that has the same rotational period as Kerbin is technically keosynchronous; the location-specific nature of your advice indicates the latter. Hope this helps!

I think most folks were more worried about the delta-v required to accomplish Kerbin-Mun transfers. Hohmann transfer techniques are actually very easy to calculate and perform (which my calculator will perform for you), and require no special navigation aids. The nav-ball we have is quite useful and will get us to far-flung places in the kerbal-verse. What we could use, however, is more orbital parameters in the map that allow us to estimate a spacecraft\'s position in greater detail (e.g. true anomaly, relative angular separation, etc.). All this aside, nice work with the free return!

I\'m glad to hear you like the calculator. When designing this feature, I would just eyeball the syzygy conditions you\'ve specified. In the absence of more precise in-game orbital tools, it\'s the best we can manage. The trick when using the calculator is to know what type of syzygy you\'re dealing with. Most users will be performing a low-to-high Hohmann transfer where the Mun is at opposition. My recommendation is to zoom out just far enough to be able to estimate when your spacecraft will move between Kerbin and the Mun such that all three are along a single line extending radially from Kerbin out to the Mun (and beyond). Different syzygy geometries will require a bit more understanding from the user, but are still very easy to estimate. FYI: this feature originally required the user to estimate angles like 83 deg. I received some great feedback from one of my beta testers that indicated syzygy events (e.g. conjunction or opposition) were much easier to estimate (precisely) without additional in-game tools. Happy orbiting!

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.