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.