Fix the normal and anti-normal nodes in the maneuver planner

[Guest]

I want to explain one silly thing that happens when you are planning a maneuver.

When you are accelerating pointing at the normal/antinormal node via navball, the node is continuously changing. But if you plan a maneuver trying to change the orbit angle the normal/anti-normal reference still the actual one.

This creates a problem when you try to change the angle of the orbit, causing an elliptical planned one. Then you have to fix it with the pro-grade/retro-grade nodes in the maneuver planner.

This is only a little suggestion to fix a problem about our orbital maneuvering. Please Squad, fix it.

[Red Iron Crown]

You're describing two different types of burns.

The first one has a constantly changing target, because the direction that is normal/antinormal changes as the inclination changes. Such a burn only affects inclination but is less efficient than the second one.

The second one stays pointed in the the direction of the node, and that direction is determined relative to the original orbit. It is correct and proper that setting up an inclination change without affecting Ap or Pe requires both a normal/antinormal component and a retrograde component, because a burn that is completely normal/antinormal to the original orbit will end up raising the orbit.

These two different maneuvers achieve the same end result (an inclination change), but the second one does so for less propellant cost.

IMO this isn't broken, and the suggested fix would make it broken.

[pellinor]

I think this is not about actual engine burns but about the behavior of the maneuver node gizmo: should the handles refer to the orbit before or after the burn?

The current behaviour is "before", so pulling the handles does not change their orientation. Pulling the prograde handle means "add a small prograde burn before the current node". Simple and stable, but not always ideal. For example, pulling the normal handle messes up AP/PE and needs lots of fiddling to get a pure inclination change. This is a common use case so the UI should allow an efficient way to do it.

"After" seems more logical to me. Let's say I plot a complex maneuver node and look at the resulting orbit. The direction is fine but I need to go faster. In this case the vector I want to add is the "prograde" of the new orbit. Instead the gizmo gives me the prograde direction of the old orbit, which tends to mess things up if those directions are not the same. With the "after" behavior, the above inclination change would also be plotted by just pulling the normal handle. I'd strongly prefer this behavior.

First I wanted to propose a switch for this, but actually I can not think of any situation where I'd prefer to make corrections based on the "before" coordinate system. Of course the final node is an object in the "before" coordinate system. What I propose is that a UI for the input of incremental changes is more intuitive if it operates in the "after" coordinate system.

EDIT: another try to formulate this in a simple way:

1) it is EASY to say what a small prograde burn AFTER a complex node will do

2) it is HARD to say what a small prograde burn BEFORE a complex node will do

In KSP we plan our maneuvers by adding up small incremental changes. Why are we doing it the hard way?

Edited October 3, 2015 by pellinor

[Guest]

I've seen another thread about this. Can you move this into that post?

http://forum.kerbalspaceprogram.com/threads/134805-New-Maneuver-Node-Editing-Tool

Edited October 3, 2015 by Guest

[Red Iron Crown]

I don't see the other thread, could you link it?

[Guest]

I don't know how.

[Red Iron Crown]

I see your link. That suggestion is different enough that these two should probably remain separate threads.

[pellinor]

I already mentioned our idea in the other thread and it seems not welcome there. Which is okay because we propose a change in the stock gizmo and the other thread is about an extra tool that needs to be consistent with stock.

When I find the time I'll try to code a prototype of the "target orbit" coordinate system into preciseNode. Then we will see how it handles.

[cfds]

The problem is that for an inclination change with an impulsive manoeuvre, the direction is neither in the original nor in the target orbit parallel to the normal/anti-normal axis. There is in both cases a contribution along the prograde/retrograde axis.

[pellinor]

The problem is that for an inclination change with an impulsive manoeuvre, the direction is neither in the original nor in the target orbit parallel to the normal/anti-normal axis. There is in both cases a contribution along the prograde/retrograde axis.

You're right, this is just the sort of contribution I'd like the node tool to handle for me. When assembling the node from small incremental steps (like the stock gizmo does) or integrating over a continuous burn following the normal marker (like an engine burn) the contribution in pro/retrograde builds up naturally. When taking large steps (like pressing +100m/s in preciseNode) things get imprecise. And I already have ideas how to correct for this.

[BudgetHedgehog]

The best explanation I've seen of this is from Technokratik: "Maneuver node controls rotate with the post-maneuver trajectory/orbit, but the maneuver's reference frame is that of the pre-maneuver trajectory/orbit"

For example, when dragging the orbit-normal handle of a maneuver node placed at the periapsis of an elliptical orbit, the handles of the maneuver node rotate with the post-maneuver orbit's plane (about the radial/anti-radial axis of the node). However, the apoapsis of the post-maneuver orbit increases (as the orbit-normal delta-V increases) because the maneuver's reference frame is that of the pre-maneuver orbit - this seems counter-intuitive. Compare this to burning in the orbit-normal direction at periapsis, and following the orbit-normal as it moves on the navball during the burn (just as the orbit-normal maneuver handle rotates as the delta-V along that axis is adjusted): since this burn is constantly in a direction perpendicular to the prograde vector, the craft's orbital velocity (in terms of magnitude) is unaffected, and thus so is its apoapsis.

Either a) the maneuver node's handles should not rotate when the radial/anti-radial and normal/anti-normal delta-Vs are changed, or changes to the radial/anti-radial and normal/anti-normal delta-Vs should be with respect to the post-maneuver reference frame; ideally, the user could choose between these two behaviours in the game's settings. The second behaviour would make large plane changes easier because it would simply be a matter of dragging the orbit-normal handle of the maneuver.

[...]

My complaint is that the maneuver node's handle's axes are aligned to the post-maneuver orbit, but adjust the maneuver in the pre-maneuver reference frame that is, they don't adjust the maneuver in the direction they point. If you setup the second example I gave (http://i.imgur.com/mxnXYTu.png), this issue becomes evident: dragging the normal/anti-normal handles of the maneuver node seen in the screenshot affects the north/south component of the maneuver's delta-V, even though those handles are oriented east-west. This seems counter-intuitive, no?

[pellinor]

The best explanation I've seen of this is from Technokratik: "Maneuver node controls rotate with the post-maneuver trajectory/orbit, but the maneuver's reference frame is that of the pre-maneuver trajectory/orbit"

Thanks, I couldn't explain it better! Good to see that the issue already has some attention.

[pellinor]

Update: I did the prototype and put up a feature request in the precise node thread.

[OmniscientQ]

I'd be happy with a maneuver node that doesn't change its orientation as you plan maneuvers. I wouldn't be at all happy with one that changed the orientation of the node handles, and changed their behaviors as you go. The maneuver nodes as they function now gave me a much better understanding of the orbital mechanics involved precisely because I could watch as the new orbit failed to change in the way I expected it to. Orbital mechanics are (to most people) completely non-intuitive, and the current nodes allowed me to understand WHY I was wrong. And understanding why I was wrong made it trivial to use the nodes as-is.