[1.2.2] Maneuver Node Splitter v1.7.0

[nathan1]

Maneuver Node Splitter v1.7.0

Maneuver Node Splitter provides a GUI interface to split a single interplanetary transfer ejection burn maneuver node into multiple maneuver nodes.

Version 1.3.0 comparison of the Unity skin and KSP skin above. Also shows the new 1.3.0 "repeat" option.

Version 1.2.0 picture of the four modes for splitting nodes below.

 

Why does it exist?

If your vessel has a low TWR then it may not be possible to perform your ejection burn in a single orbit. By splitting your ejection maneuver into multiple burns you can raise your apoapsis a bit with each orbit until your final burn gives you an escape trajectory.

 

How do I use it?

1. Get into orbit.
2. Create a maneuver node.
3. (Optional) Use Precise Node to move your maneuver node forward to the transfer window.
4. Set up the maneuver node to give you your ejection and encounter with your destination.
5. Open the Maneuver Node Splitter GUI by clicking the icon on the toolbar.
6. Use the left and right buttons to select how you want to split the maneuver node.
7. Enter the appropriate values into the text boxes. For example: delta-V values for the amount of delta-V you want to burn in each maneuver.
8. Click "Apply."

Your original maneuver node will be replaced by multiple maneuver nodes. Each of the first maneuver nodes will be created based on the values you entered, and the final maneuver node will have the remaining delta-V. Your final ejection burn maneuver node will be around the same time as the original maneuver node (depending on what values you entered).

Example:
After creating an ejection burn requiring 2500m/s I open the GUI and enter 250 and 300 then click "Apply." The mod will split my original maneuver node into three maneuvers: the first will be 250m/s, the second will be 300m/s, and the third will be 1950m/s (the remainder).

Note:

Once your maneuver nodes are created it's up to you to actually perform the burns. This is the hard part. If you do not perform the burns precisely enough then the subsequent burns will be impacted. Luckily, as long as you're close it's usually easy to do minor adjustments to the later maneuver nodes using Precise Node to restore your rendezvous. Usually what you will need to adjust will be the *timing* of the subsequent maneuver nodes (since burning a slightly different amount from what the maneuver node specified will give you a different orbital period) rather than the delta-V.

 

Additional Tips and Notes:

• It works with both mid-course plane-changes and direct ejection burns.
• The additional maneuver nodes will be created prior to the timing of your original maneuver (if your maneuver node is far enough in the future) so that your ejection time is left as unchanged as possible.
• The GUI will modify your upcoming maneuver, so don't add extra maneuvers before your ejection burn.
• The GUI will preserve any maneuver nodes that come after your ejection burn as long as they're far enough later than the original maneuver.
• After clicking "Apply" there will be an "Undo" button that will restore your prior maneuvers, so it's easy to just throw some numbers in and see how they work out. If it's not to your liking you can easily undo it.
• The "+" button will add more text boxes (for splitting the original maneuver into more burns) and the text boxes will have "x" buttons next to them for removing them (when you have more than one text box).
• Stock KSP has a bug where projected orbits sometimes do not show when multiple maneuver nodes from separate orbits are placed directly on top of each other. This is not a bug with the Maneuver Node Splitter.
• It's usually best not to raise your apoapsis above around 7000km prior to your ejection burn because of the possibility of an encounter with the Mun.
• While the tool can convert your ejection burn into a dozen or more tiny burns, it's usually easier to perform the ejection in fewer burns rather than more (due to the impact on later burns of not performing the earlier burns perfectly).
• Your current orbit very slowly drifts when your vessel is not on rails (timewarp) due to floating point math. This can impact your ejection maneuver while you are trying to set it up, so it's best to set it up at timewarp, if possible.

 

Pics:

 

Download

GitHub

 

Source

GitHub

 

Version History

v1.7.0 (2017-03-18)
-Compiled for KSP 1.2.2
-Fix for splitting maneuvers that include a normal component.

v1.6.0 (2016-10-13)
-Update for KSP 1.2
-Includes a version file for KSP-AVC (thanks Henry Bauer!)

v1.5.0 (2016-03-30)
-Updated for the KSP 1.1 pre-release. Only use this version with KSP 1.1, not KSP 1.0.5.

v1.4.0 (2016-03-20)
-Added error messages when the input values cause early ejection from the original SOI or an encounter with another SOI.

v1.3.0
-Added a "repeat" option to make specifying how to split the nodes easier.

v1.2.0
-Maneuver splitting can now be specified by deltaV, orbital period, burn time, or apoapsis (splitting by burn time requires that you install KER). Thanks @Val for the suggestions!

v1.1.0
-Added support for using either the KSP skin or the Unity skin (the new default), configured via settings.cfg.

v1.0.0
-Initial release.

 

License

Maneuver Node Splitter is licensed under the MIT license.

Edited March 19, 2017 by nathan1

[theJesuit]

Wow - this is awesome, and several forum users have asked for it.  Can't wait to try it myself for my return from Duna.

Pleased to see you've considered and avoided a possible clash with PreciseNode or hopefully PreciseManeuver!

Peace.

[nathan1]

Yeah, I was kind of bored and perusing the forums when I saw someone ask about it and thought "hey, I've done that manually in game with Precise Node... I bet I could make a mod to automate the process!"

I've never heard of Precise Maneuver before now; I'll have to look into that one.

[Gribbleshnibit8]

Yay a mod that supports both toolbars and exists only in the correct scene on the app launcher!

Also, this looks awesome. I'm in the design/testing phase of a nuke powered interplanetary ship that has lousy TWR and the super long 25 min burns suck when you get so far away from optimal burn times and you can just feel the dv being wasted. Totally a part of my mod installs now.

[Racescort666]

Awesome! I can't wait to try it out.

[Jansn67]

Wow, amazing!

Exactly what i need for my xenon-driveen-2-hours-burning-probes.

BIG THANK YOU for that mod.

(Later i will include it (if possible) into my ckan-1-click-reinstall-package.)

[SmarterThanMe]

This should be part of MechJeb. Nice!

[frencrs]

On 2/16/2016 at 9:57 PM, nathan1 said:

I've never heard of Precise Maneuver before now; I'll have to look into that one.

It's exactly like Precise Node, except the author is doing more recent updates. I'm almost certain it'll work exactly the same without changing anything in either mod.

[Val]

This is really, really useful. Thank you, @nathan1.

Some additional cool ways to split burns, other than m/s, that might be useful, if possible.

• Number of burns. (Could be tricky, because you'd have to make sure the second to last burn doesn't exit SoI)
• Max burn time. (Might be difficult to calculate, though)
• Max angle or % of orbit.
  How big of an arc of the total orbit that the burn may take place. Each burn would become shorter than the previous, because orbital speed is increased.
  (No idea how one would do that)

Well, just my thoughts. Maybe it's not doable.

[nathan1]

10 hours ago, Val said:

This is really, really useful. Thank you, @nathan1.

Some additional cool ways to split burns, other than m/s, that might be useful, if possible.

• Number of burns. (Could be tricky, because you'd have to make sure the second to last burn doesn't exit SoI)
• Max burn time. (Might be difficult to calculate, though)
• Max angle or % of orbit.
  How big of an arc of the total orbit that the burn may take place. Each burn would become shorter than the previous, because orbital speed is increased.
  (No idea how one would do that)

Well, just my thoughts. Maybe it's not doable.

Hm, I had some ideas for improvements, but I hadn't thought about providing other ways of specifying the split...

I like the ideas. I'll have to look into what I can do there.

[nathan1]

Version 1.1.0 has been released.

This version adds support for using either the KSP skin or the Unity skin (the new default).

To change the skin you can modify the settings.cfg file in the NodeSplitter directory, or you can add a Module Manager patch in the root of your GameData directory so that your settings aren't affected by updating the mod again later:

@MANEUVER_NODE_SPLITTER
{
    @SETTINGS
    {
        @skin = ksp
    }
}

 

[Ignath]

Congrats on the Modding Mondays mention.  Awesome looking mod!

[nathan1]

26 minutes ago, Ignath said:

Congrats on the Modding Mondays mention.  Awesome looking mod!

Awesome, thanks!

I also just released version 1.2.0:
-Maneuver splitting can now be specified by deltaV, orbital period, burn time, or apoapsis (splitting by burn time requires that you have installed KER).

[Deimos Rast]

So I was about to make a big post about how I don't have the arrows at the top of the Node Splitter window, when I noticed I didn't have the latest version, and realize that was a feature specific to the latest version.

I was even going to include pretty pictures too.

Downloaded the latest version to play with later.

Also, thanks for turning me on to PreciseNode - didn't know about that mod before.

Cheers.

 

[surge]

Great mod. Seems to work mostly as advertised too, which is a big plus.

Suggestions on UI:

-Most use cases for this will be to split a large dV change into smaller ones, as you've said. It is logical then, that the UI should have a mode when you simply type in the max dV you can support in one burst (Vy), and it splits the node (Vt) into Vt/Vy nodes, each of Vy (and possibly a remainder) Obviously this should work with other units as well, particularly time. I tested this on an solar powered ion probe which had a perigee mostly on the dark side of a moon, and i had only a few minutes of sunlight to burn each pass.

-When you press + to add another split, it should copy the text from the split above it - saves alot of typing when you have to split 500m/s into 15m/s burns!

 

Also a not-really-a-bug-because-its-undefined but if i split a node and execute a couple of them, and then press undo, it reverts to semi-garbage. If there is a way to detect if a node has been executed, you might want to disable the undo button.

[nathan1]

12 hours ago, Deimos Rast said:

So I was about to make a big post about how I don't have the arrows at the top of the Node Splitter window, when I noticed I didn't have the latest version, and realize that was a feature specific to the latest version.

I was even going to include pretty pictures too.

Downloaded the latest version to play with later.

Also, thanks for turning me on to PreciseNode - didn't know about that mod before.

Cheers.

 

I'm glad to have been able to introduce it to you. Precise Node is one of my top download priorities when a new KSP version comes out.

4 hours ago, surge said:

Great mod. Seems to work mostly as advertised too, which is a big plus.

Suggestions on UI:

-Most use cases for this will be to split a large dV change into smaller ones, as you've said. It is logical then, that the UI should have a mode when you simply type in the max dV you can support in one burst (Vy), and it splits the node (Vt) into Vt/Vy nodes, each of Vy (and possibly a remainder) Obviously this should work with other units as well, particularly time. I tested this on an solar powered ion probe which had a perigee mostly on the dark side of a moon, and i had only a few minutes of sunlight to burn each pass.

-When you press + to add another split, it should copy the text from the split above it - saves alot of typing when you have to split 500m/s into 15m/s burns!

 

Also a not-really-a-bug-because-its-undefined but if i split a node and execute a couple of them, and then press undo, it reverts to semi-garbage. If there is a way to detect if a node has been executed, you might want to disable the undo button.

Thanks for the suggestions; I think I can implement something like that.

 

As for the undo, I thought I already checked if the nodes were in the past, but I guess not. I could at least make the undo button remember what the state was immediately prior to clicking it, so you can undo your undo.

[surge]

At that point, youre just being unnecessarily kerbal. If one of the nodes is in the past, DISABLE the undo button. Punkt! You must make it idiot proof, after all. These are kerbals were dealing with!

If you want to get fancy, maybe the button could turn into "delete all the nodes my mod has created" There was mention about it supposing to leave future nodes alone after all (I've not tested this, when it gave me what i didnt like and the undo button produced garbage,  i just used mechjeb to "delete all nodes").

Edited February 23, 2016 by surge
forgot to mention something

[Laie]

I was totally excited at the name of this mod, expecting something that will let me do this (because a low TWR won't magically improve when the actual transfer comes up):

I've written a kOS script to plot these nodes. They are equal burn time (~80sec in this case), with slightly increasing dV due to spent propellant increasing TWR. 5-second gaps between burns. Calculating the nodes and putting them on the map wasn't much of a problem; however, the most important means of refining such a scheme is taking all nodes and moving each of them a few seconds forward or back. I never figured out how to do that, eventually resorting to discarding all nodes and plotting a new set with a slightly different start time. Te-di-ous.

I don't know how maneuver nodes work, but they obviously are auto-correcting to some degree (node changes vector in response to steering errors and the likes). Giving Mechjeb such a string of nodes and telling it to just execute them all gave me pretty precise burns, with post-transfer corrections of <10m/s.

[nathan1]

5 hours ago, surge said:

At that point, youre just being unnecessarily kerbal. If one of the nodes is in the past, DISABLE the undo button. Punkt! You must make it idiot proof, after all. These are kerbals were dealing with!

If you want to get fancy, maybe the button could turn into "delete all the nodes my mod has created" There was mention about it supposing to leave future nodes alone after all (I've not tested this, when it gave me what i didnt like and the undo button produced garbage,  i just used mechjeb to "delete all nodes").

Since the new maneuver nodes get shifted to be earlier than the original maneuver node you can end up with a new maneuver node only minutes or seconds in the future. If you're not paying close enough attention to how much earlier the new nodes are you could easily fly past the new nodes without burning at all. There's no reason for me to prevent the user from undoing the maneuver node changes and re-applying.

2 hours ago, Laie said:

I was totally excited at the name of this mod, expecting something that will let me do this (because a low TWR won't magically improve when the actual transfer comes up):

I've written a kOS script to plot these nodes. They are equal burn time (~80sec in this case), with slightly increasing dV due to spent propellant increasing TWR. 5-second gaps between burns. Calculating the nodes and putting them on the map wasn't much of a problem; however, the most important means of refining such a scheme is taking all nodes and moving each of them a few seconds forward or back. I never figured out how to do that, eventually resorting to discarding all nodes and plotting a new set with a slightly different start time. Te-di-ous.

I don't know how maneuver nodes work, but they obviously are auto-correcting to some degree (node changes vector in response to steering errors and the likes). Giving Mechjeb such a string of nodes and telling it to just execute them all gave me pretty precise burns, with post-transfer corrections of <10m/s.

Can you provide the kOS script that does that?

[Laie]

1 hour ago, nathan1 said:

Can you provide the kOS script that does that?

Here it is, cruft and all. It takes no input: you edit, run, edit until you're content. As I said, not the most user-friendly implementation. I last used it more than a year ago, it may no longer work in current kOS.

You provide it with maneuver data (pro/rad/nor) and a time (seconds relative to next periapsis). It computes the total duration of that maneuver, then splits it into n chunks of similar duration.

set num_nodes to 5.
set time_between to 3. //time between nodes, in seconds

set pro to 1149.
set rad to 0.
set nor to 0.
set abstime to time:seconds + eta:periapsis + obt:period +5.

set update to 2. //2= delete previous nodes; anything else no effect

lock alldv to v(pro,rad,nor):mag. //total dV of maneuver


//get current TWR and effictive ISP (allows for a mix of engines)
set thrust to 0.
set wisp to 0.  //weighted ISP.
list engines in el.
for e in el {
    if e:ignition = 1 and e:flameout = 0
    {set thrust to thrust + (e:maxthrust * e:thrustlimit * 0.01).
     set wisp to wisp + (e:isp * e:maxthrust * e:thrustlimit * 0.01).
}}
set isp to wisp/thrust.
set twr to (thrust*1000)/mass.
set kgf to thrust / (isp * 9.81).  //kg fuel per second
print "Thrust: " +  thrust + " ISP: " + isp + " TWR: " + round(twr)/1000 + "fuel: " + round(kgf,3) +"kg/sec".

//get change in mass, duration of burn
//e= 2.718281828
set allnewmass to mass*2.718281828^(-alldv/(isp*9.81)).
set alldiffmass to mass - allnewmass.
set allduration to (mass-allnewmass)/kgf.

//"all" means the variable is related to the compound maneuver;
// later there's "newmass" etc. for the small maneuvers.


set x to 0.
set foo to 0.

wait 0.1. 
print "wait foo".
if update > 0 {
 if update = 1 {
  set j to 1.
  until j > num_nodes {
  print "remove node " + j.
  remove nextnode.
  set j to j + 1.
  wait 0.1.
 }}
 if update = 2 {
 // kOS will segfault if you try to edit/delete a non-existing node
 // ...and has no means of checking if a node exists.
 // this deletes all nodes until it sees one that's more than 50d in the future
 // placing that node is the user's job.

  until nextnode:eta > (50*6*3600) {
   remove nextnode.
   wait 0.01.
}}
wait 0.1.
set update to 0.
set duration to allduration / num_nodes.
set mass0 to mass.
set i to 0.5-(num_nodes/2).  //the mind, it boggles.

wait 0.01.

until i > (num_nodes/2) {
 set mass1 to mass0 - (alldiffmass / num_nodes).
 set dv to isp*9.81*ln(mass0/mass1).
 set factor to dv/alldv.
 set this_time to abstime + ((duration + time_between) * i).
 set myNode to NODE(this_time,rad*factor,nor*factor,pro*factor).
 add myNode.

 print "Node" + i + " at " + round(this_time) + " with " + round(dv,1) + " m/s".
 set mass0 to mass1.
 set i to i + 1.
 wait 0.01.
 }
}
print "total dV: " + round(alldv,1) + " total burn time: " + round(allduration).

One thing that looks a lot more convoluted than it is, average ISP is really just the arithmetic average:
(thrust1*isp1 + thrust2*isp2 + ...) / (thrust1 + thrust2 + ...)

 

[smjjames]

Has anybody tried this with MJ? I often use low TWR ships with LOTS of deltaV when doing Jool system missions, so, this would be useful.

edit: Does this work with other maneuvers besides transfers?

edit2: Going to go and give it a try here with the current craft....

edit3: It doesn't seem to work very well with the Joolian moons since it throws the transfer burn way off, then again, I'm in a polar orbit and even MJ has trouble with the Joolian moons.

edit4: I tried it with an inclination change and while it works well, I'm not seeing any deltaV savings and in fact, using MJ to do just one node is actually more efficient than using node splitter. At least for that particular function.

Edited February 24, 2016 by smjjames

[nathan1]

9 hours ago, smjjames said:

Has anybody tried this with MJ? I often use low TWR ships with LOTS of deltaV when doing Jool system missions, so, this would be useful.

edit: Does this work with other maneuvers besides transfers?

edit2: Going to go and give it a try here with the current craft....

edit3: It doesn't seem to work very well with the Joolian moons since it throws the transfer burn way off, then again, I'm in a polar orbit and even MJ has trouble with the Joolian moons.

edit4: I tried it with an inclination change and while it works well, I'm not seeing any deltaV savings and in fact, using MJ to do just one node is actually more efficient than using node splitter. At least for that particular function.

The mod is designed to split a maneuver node so that you can perform part of the burn on each of multiple orbits. You can use it for any maneuver node--you don't have to use it for transfers--but I'm not sure what kinds of maneuvers other than transfers you'd actually want to split in this way.

Did you set up your original node very far in the future? If you split your maneuver into multiple nodes then you have to make a full orbit between each burn. If your original maneuver node isn't far enough in the future then the mod can't put the prior burns far enough ahead of time for your final ejection burn to be around the same time, so that will have a big impact on your transfer. For example, if your orbital period is 30 minutes and after splitting your first burn gives you a 1 hour period, your second burn gives you a 6 hour period, and your third burn is the ejection burn then the mod has to place the first burn and the ejection 7 hours apart. If your original node is 30 minutes in the future then the split nodes will be moved multiple hours, but if your original node was 8 hours in the future then when the mod splits the nodes it can put the first one about 1 hour in the future and have your final ejection be around the same time as it was originally.

If your maneuver node is far enough in the future you can also play with the values to get the timing of the final ejection as close to your original maneuver node as possible (the first maneuver the mod creates has to be an integer multiple of your orbital period away from your original maneuver node in order for it to be in the correct location. From there the remaining maneuver nodes are constrained by the orbital periods resulting from each of the burns). Re-using my example from above: the mod can put a new node 14 orbits (7 hours) ahead of your original node, then the next node on the next orbit (6 hours ahead of your original node), and the final ejection will be right around the time of your original node. But if your second burn gives you an orbital period of 6 hours and 15 minutes then the mod can't place the first node anywhere that leaves your ejection anything less than 15 minutes away from your original maneuver node.

[Laie]

@smjjames: The problem starts with how the game stores nodes: they are not tied to a position, but to a fixed time. The position of the node is wherever your (projected) position happens to be at that time.

If the first node is supposed to send you on an orbit that takes 50 minutes, the second node will be set to happen 50 min after the first (because that's when you're back at periapsis). If your execution of the first node is less than perfect, the second node will not be at periapsis. In my experience, even MJ can't execute them to the necessary precision: by the third of fourth maneuver your remaining nodes will be noticeably off.

Thankfully, the solution is simple: just reach in and move the node to periapsis where it's supposed to be.

By the time you come around to do the final burn, you cannot expect it to still take you to your target. But it will be pretty close, so don't discard the maneuver but instead use it as a starting point that only needs minor adjustment.

So, what this boils down to: this mod saves you the hassle of putting nodes down and setting their pro/rad/norm values. No more, no less. You will still need to pay attention to what really happens on when you execute them.

[surge]

Quote

You can use it for any maneuver node--you don't have to use it for transfers--but I'm not sure what kinds of maneuvers other than transfers you'd actually want to split in this way.

In real life, most high orbit launches (russian ones at least) use a very low thrust (lower than yours obviously - the Briz-M generates about 20kN, but the numbers don't translate into KSP well) final stage to do somewhere between 3-8 burns each orbit to get the satellite both into the orbital altitude they want and to circularise it.  I think the french/europeans (Ariane) and americans (Delta) do this too. Real space flight is unbelievably slow and boring!

As mentioned, I tested this before on a set of circularisation burns for Jool's moon Laythe with a 2kN ion engine, that could only get enough electric power each time around for about 15ms-1 dV, and it seemed to work pretty well, so there are 2 other uses for this. Probably only the 1st is realism related, real space agencies seem to use aerobraking to help circularise an outer world orbit with an atmosphere, but with the funny atmosphere density on bodies other than Kerbin in KSP, we have to do it the hard way (at least in 1.0.4 - I've heard they tried to fix that in 1.0.5).

 

Transfers are actually a really bad use for this, because of what you've discovered... it takes longer and longer to come around to the next orbit each time, and there's no easy way to tell the maneuvre system that you want to have a final ejection at *this* time, and on *this* orbit. It's not a fault of this mod, it's a fault of the basic system. It's much simpler to build an overpowered rocket and just do it all in one go. On the other hand, if you're doing a several million km transfer, the timing doesn't matter much, what matters most is the final velocity, so it's not entirely useless - as Lale said, you should just need a little correction burn after you've exited the original SOI.

 

Lastly, inclination changes are more efficient if you do them in one go... by ALOT, so don't use that as a yardstick. Sometimes you have to do them over multiple burns because of TWR/crashing into the planet, but just live with it, or build a bigger rocket. If you're not doing it already, do them as far away from the body as you can when your speed is the slowest (like just after you achieve initial orbit). You'll be surprised how little it costs. Then do the circularisation burn(s).

[smjjames]

1 hour ago, surge said:

Lastly, inclination changes are more efficient if you do them in one go... by ALOT, so don't use that as a yardstick. Sometimes you have to do them over multiple burns because of TWR/crashing into the planet, but just live with it, or build a bigger rocket. If you're not doing it already, do them as far away from the body as you can when your speed is the slowest (like just after you achieve initial orbit). You'll be surprised how little it costs. Then do the circularisation burn(s).

Point taken. I did do the analysis and noticed that doing it in one go was more efficient and I was seeing if it would work for inclination change.

As for the transfer stuff, the main problem is that I was trying to do it from a polar orbit.

Transfers are actually a really bad use for this, because of what you've discovered... it takes longer and longer to come around to the next orbit each time, and there's no easy way to tell the maneuvre system that you want to have a final ejection at *this* time, and on *this* orbit. It's not a fault of this mod, it's a fault of the basic system. It's much simpler to build an overpowered rocket and just do it all in one go. On the other hand, if you're doing a several million km transfer, the timing doesn't matter much, what matters most is the final velocity, so it's not entirely useless - as Lale said, you should just need a little correction burn after you've exited the original SOI.

Yeah, that's why I use a stage with a TWR of < 1.0 to do the transfer burn out of Kerbin orbit.

Edited March 13, 2016 by smjjames