why do maneuver nodes wander around?

[maxdreamland]

I recently started to leave the Kerbin system and started to exlore different planets, like Duna for example. while doing so i discovered a behaviour that i never came across while navigating within the Kerbin environment (Kerbin, Mun, Minmus).

i would be curious to learn if i'm doing something wrong or if this is a quirk/bug of the game. for the sake of simplicity take the following scenario.

slap together the simplest of all spacecraft. a command module, a fuel tank and a liquid engine. then use HyperEdit to place the craft in a 52km Duna orbit. create a maneuver node to lift your apoapsis to, let's say, 85km.

when you start to execute that maneuver node keep an eye on the node in the navball. when you're close to completing the node, throttle down so you can observe the effect more clearly. every time i'm close to completing the node, that means when i aproach less than 1 m/s delta V left on the node, the node starts wandering on the navball. usually 90 degrees up. And no matter how long you follow the node, you will never be able to "complete" it, because you will never get down to 0 m/s delta V left.

i started noticing this behaviour when i tried to use mechJeb to rendezvous or dock with other craft while orbiting Duna. It's impossible, because mechJeb can't complete a single maneuver because of this effect.

at first i thought my install was messed up. but since then i tried fresh 0.90 steam installs without any mods (except HyperEdit) on two different machines and the behaviour is the same.

i tried the same scenario around Kerbin (little different altitudes of course) and it works fine there. i assume thats why i never noticed it before in my game.

is this something the community is familiar with? do i have to live with it? can i do something about it?

any input would be appreciated. thanks in advance!

regards

Max

EDIT: after some discussion it became obvious that a video of the effect would be helpful for everybody to know what we're talking about, so i provided this one:

https://www.youtube.com/watch?v=QaU51V4QzBY

Edited February 17, 2015 by maxdreamland
providing additional information

[Henshaw]

Thats because nodes assume an instantaneous change of velocity, but since that isn't the case it needs to adjust and move since your burn takes time in order to get the exact orbit one planned with the node.

[brdavis]

The marker on the NavBall shows the orientation to burn in to reduce the current difference between your velocity vector and the selected velocity vector… but there's no such thing as "zero". So when you get close, although the error (residual) is really small, it's still there, and the game adjusts the nav marker to show the current orientation to try to burn in. It happens all the time (try a simple Kerbin-Mun insertion, and you'll see the same thing… or at least I do). Note there is a "you're good enough" indicator - the dV tag on the maneuver (shown to the right of the NavBall) turns green when the game things you are "close enough", but it will still keep moving around the nav marker.

Think about it this way: if you are trying to walk to a mark on the floor 10 meters away that's north of you, I can tell you "go north". But when you are within 10 cm of it, unless I was *perfect* on telling you the heading, and you were *perfect* at executing it, you might be a little to the east or west of the mark… so I would have to tell you to go "north but a little bit east as well". As you try to do that, and get within 1 cm of the mark, I realize you've overshot slightly, and tell you "oh, yeah, now the mark's just behind you, head sort of southwest." And when you do that and end up 2 mm to the side, and ask "am I there yet", I say "no but almost, now go due east just a little bit." This would be the point where you slap my silly and realize that the error isn't important, and wander off to get a corn beef sandwich instead.

Edited February 16, 2015 by brdavis

[maxdreamland]

@henshaw: no, i don't think thats it. i'm familiar with the effect you describe, but it's usually only a factor with very long burns and the node deviation/wandering is small.

in the scenario i described above we talk about a 19m/s delta V burn that is may 1-2 seconds long at full thrust. that is quasi instantaneous. and the node wanders around like crazy (90+ degree deviations) and you can try to chase it forever.

when i'm at home i can try to make a video of it...this is something different than you describe, i'm pretty sure.

[magnemoe]

I think wandering nodes is an issue with rotating the ship also moves the command module around center of mass and this speed will affect very small burns. You also have floating point errors however the rotation issue is lager on long ships. Try to do an 5x timewarp as it freeze rotation and see where the marker ends up.

[maxdreamland]

@brdavis: yes, i think i understand the concept. but if you get close to node completion for a simple maneuver like raising your apoapsis where you basically just burn prograde, the "residual error" what you call it, shouldn't suddenly make the maneuver node jump 90 degrees upwards. thats a direction you would never burn to, no matter how large the residual error becomes to complete the burn. wouldn't you agree?

i think it will really help if i try to post a video of the effect, later when i'm at home.

[eddiew]

I've had this problem when using Kerbal Construction Time simulations around non-Kerbin planets; other than that, the node-movement should only be small.

[brdavis]

...you basically just burn prograde…

When you say "burn prograde"… how closely did you put your orientation relative to the NavBall marker? To better than a degree? Good, but not good enough… especially at the end of the maneuver. To better than 0.1 degrees? Good… but if you push it "to the end", not good enough.

"It's always something"… be that finite burn time (which should result in a predictable drift), or error in sighting the marker (are you pointed right at it to 0.000001 degrees?), or numerical error… there's always a residual.

When you say "tends to move upward"… relative to the ship marker on the NavBall? Or relative to the artificial horizon? On *all* burns, or prograde ones?

[maxdreamland]

When you say "burn prograde"… how closely did you put your orientation relative to the NavBall marker? To better than a degree? Good, but not good enough… especially at the end of the maneuver. To better than 0.1 degrees? Good… but if you push it "to the end", not good enough.

i actually used the SAS "point at node" feature.

"It's always something"… be that finite burn time (which should result in a predictable drift), or error in sighting the marker (are you pointed right at it to 0.000001 degrees?), or numerical error… there's always a residual.

i agree with you that the node is "supposed" to move "a little" towards the end of the burn because of this effect. and i'm used to this while playing in the kerbin system. and it never effected the gameplay adversly. more to the point, it never rendered mechJeb useless.

so the behaviour around Duna is definitely something different or far more pronounced. I'll make you a video later on, i think that will clear tings up...i understand it's hard for you guys to comment on it without experiencing it. i probably should have done the video from the start. sorry for that.

When you say "tends to move upward"… relative to the ship marker on the NavBall? Or relative to the artificial horizon? On *all* burns, or prograde ones?

it tends to wander to the "north pole" (of the blue hemisphere) of the navball.

[EdFred]

I've always had this "issue", it's nothing new.

[maxdreamland]

I've always had this "issue", it's nothing new.

i'm glad i'm not the only one...i started to question my sanity :-)

still, would be interesting to find the root cause for this...

[LameLefty]

It's a combination of floating point imprecision (the amount of which is always variable) and imprecision of thrust control of your vessel. If your craft is insanely over-powered, it can very, very hard to get your dV residual down close to zero because you're just not able to be that precise when you throttle down. If you have a moderately-powerful T/W ratio, it should be quite easy to fly your burn manually to <0.2 (and often all the way to zero).

Conversely, if your vehicle is under-powered, it can take so long to reach your target dV for the trajectory you want, that you simply can't complete the burn before you move so far along your orbit that you're actually burning radially or even retrograde, which is entirely counter-productive.

[maxdreamland]

OK, i managed to throw together a video that showcases the effect i'm talking about:

https://www.youtube.com/watch?v=QaU51V4QzBY

you can clearly see that the behaviour around Duna is vastly different than around Kerbin and i don't believe it is merely a "rounding error" thing.

let me know what you think when you watched it. i annotated the video, but it basically shows the build of the simple spacecraft and then the same maneuver twice. once around Duna and once around Kerbin. in Kerbin orbit mechJeb has no problem to execute this simple maneuver. in Duna orbit mechJeb will be caught in an "infinite loop" and burns all your fuel, and then some :-)

i believe what most of you guys tried to describe/explain to me with the "residual error" and "floating point imprecisions" can be seen in the video at the very end of the Kerbin variant of the maneuver. there is a tiny amount of jitter visible for the maneuver node display on the navball. but it in no way interferes with mechJebs ability to complete the node. The behaviour around Duna ist vastly different and "breaks" mechJeb.

just to be clear, this is not a mechJeb introduced problem. the same thing happens without mechJeb and manual controls.

oh by the way, i decided to use mechJeb for the video because that makes it easy for everbody to reproduce this effect without any "manual control effects" introduced on top.

[lordlundar]

I'll admit I've been having, well similar issues. When using the Albecurrie warp drive mod in trying to escape Duna's orbit the orientation goes haywire causing an abort. It took a lot of frustrating manipulations of the thrust to get it to a point where I could escape the Duna SoI. It only happened with Duna though, Kerbin, Jool and Eve had no problems. Not sure what's causing it.

[Brotoro]

I get this same issue, even in Kerbin orbit. But it seems to have gotten more pronounced in recent versions of KSP. If you slide ahead of the wandering node (in the direction it's moving) and give a burst of thrust, you can stop it from doing that. But it's a bother.

[maxdreamland]

i investigated this effect a little bit more. i tried to vary different variables to see if they have any effect.

first i varied the mass of the craft itself. i tried crafts with 0.2t, 4.6t and 590t. they each suffered from the effect exactly the same. so craft mass doesn't seem to be a factor.

next i varied TWR. i tried TWR's of 0.26, 4.80 and 56.00. again no effect, they all suffered the same.

then i started to check out different planets and moons. from the ones i checked Moho, Eve, Eeloo, Ike, Jool and even the Mun all suffered from this effect. i was especially surprised to see that i could recreate the effect at the Mun, because i played quite a lot in the Kerbin system before and it never caught my eye before.

i did find a couple of places where the effect was not present, or to be more precise it was less pronounced. less to a factor that mechjeb was able to complete it's maneuver nodes. those places were Gilly, Bop, Pol and Minmus ... all relative small (light) moons. so gravity seems to be a factor here.

i don't know what to do next. to be honest this impairs my fun with the game significantly because i like to use mechJeb, especially for things like rendesvous and docking.

and given that the effect seems to be present in so many places/cases/scenarios i'm surprised this hasn't been a bigger issue before in the community. i mean even if you don't like to use mechJeb and do everything manually, this is still quite annoying. or am i just especially sensitive? :-)

does somebody know how we could get the attention of Squad for this? is there an official way to report bugs?

regards

Max

- - - Updated - - -

nevermind, i think i found it myself:

http://bugs.kerbalspaceprogram.com/

i think i might report this and see what comes of it

[eddiew]

I've had this problem when using Kerbal Construction Time simulations around non-Kerbin planets; other than that, the node-movement should only be small.

Going to follow up my own comment since I think it's relevant; KCT uses HyperEdit to do it's simulation runs, and displays the same node wandering problems.

However when you actually go to Duna properly, without cheats or sims, it'll be completely fine You can use HyperEdit to test deorbit, landing, and ascent back to orbit, but there seems to be an underlying issue in the mod(s) that doesn't quite get the frame of reference right and manoeuvre nodes won't work. When in doubt, check it in sandbox mode, build a launcher, and time-accelerate your way there.

Doesn't fix the problem, but should be some reassurance that when you do the trip for real, it'll work as planned. Unless your entire mission plan is wrong, as mine was...

Edited February 17, 2015 by eddiew

[maxdreamland]

thats very interesting! thank you for your feedback!

i'll try this right away. but i have a feeling you might be right, because it would make sense why i never came across this effect before, when i played in the Kerbin system. because i never used Hyperedit there.

And like you said, i started using Hyperedit t when i worked on my Duna Lander Module, to be able to quickly test landing/ascent/docking scenarios.

before i read your comment i already created a bug report for this:

http://bugs.kerbalspaceprogram.com/issues/4090

i'll just leave this here for now. if it is in fact a side effect of HyperEdit i'll close that ticket after i was able to verify it.

thanks again!

regards

Max

[TheMoonRover]

I have HyperEdit and have never observed the effect shown in the video, however I do not have MechJeb installed. I'm also running windows 32 bit. However I haven't specifically tried to replicate this. Possibly a conflict between HyperEdit and MechJeb?

[maxdreamland]

i have now flown a simple mission to Duna (with unlimited fuel cheat enabled) where i uninstalled the HyperEdit addon and @eddiew was right, the problem is gone.

i've updated the reported bug and marked it fo rejection. maybe i can get in touch with the author of HyperEdit and make him aware of this effect.

thanks again to @eddiew for giving the key hint!

regards

Max

EDIT: i've now posted the problem in the HyperEdit Addon-Thread, maybe it will get some traction there:

http://forum.kerbalspaceprogram.com/threads/37756-0-90-HyperEdit-NEW-VERSION-Teleporter-Orbit-Planet-Editor-More?p=1739780&viewfull=1#post1739780

Edited February 17, 2015 by maxdreamland
provided additional information

[Ezriilc]

i have now flown a simple mission to Duna (with unlimited fuel cheat enabled) where i uninstalled the HyperEdit addon and @eddiew was right, the problem is gone.

i've updated the reported bug and marked it fo rejection. maybe i can get in touch with the author of HyperEdit and make him aware of this effect.

thanks again to @eddiew for giving the key hint!

regards

Max

EDIT: i've now posted the problem in the HyperEdit Addon-Thread, maybe it will get some traction there:

http://forum.kerbalspaceprogram.com/threads/37756-0-90-HyperEdit-NEW-VERSION-Teleporter-Orbit-Planet-Editor-More?p=1739780&viewfull=1#post1739780

Just to let everyone here know, testing has confirmed that this issue is NOT being caused by HyperEdit. It's actually not possible for HyperEdit to have any effect on maneuver nodes whatsoever, since it never touches that code nor anything that even deals with it.

I haven't read the entire thread here, but I did notice some others mentioning possible causes and explaining how nodes work - to some degree, what you describe is the intended behavior of maneuver nodes. I can only recommend that you do some more extensive testing to determine why it's happening, and why no one else can reproduce the issue - like removing ALL mods.

Good luck!

[Starwaster]

Sorry, no. HyperEdit does not cause wandering nodes. I rarely ever have HyperEdit installed. Haven't had it installed at all for several KSP updates now.

You may think they're gone but they'll come back. It's a stock issue and everyone experiences it at one time or another.

Same with MJ

[SpaceHips]

Likely you're seeing floating point errors and phantom forces wobbling your craft.

It's hard to get any sort of true precision down to <1m levels over any real distance due to this.

Floating point errors are also the reason getting an eeloo encounter is so wonky.

[Andem]

Honestly, the maneuver node was wobbling the entire time. When you get within 2-3 m/s of delta v left the wobble becomes much more exaggerated, and even caused one of my small ships to spin out trying to line up. the best you can do is make the burn use more delta v. it wastes more fuel, but you can actually do your maneuvers.

[RocketBlam]

I always thought it was because your ship rotates around its center of mass, which is somewhere near the middle. But your cockpit, where the node measurements are being done, is out on one end, so while rotating, the node marker location is changing because the distance between the cockpit to the node is changing, slightly. Note that it stops moving when you stop rotating.

I bet if you designed a ship where the cockpit was very near the COM, the problem would mostly go away. Something to test maybe.

Edited December 28, 2015 by RocketBlam