Jump to content

[not a bug] Tricky maneuver nodes?


Recommended Posts

I've tried to understand what seems to be a bug in 1.11.0

Suppose you want to leave Kerbin. You plot your maneuver mode, you warp just before starting burning, you burn -> behaves like expected.

Now let's use a craft with a low TWR. We need to achieve our transfer with slowly raising your apoapsis and gain benefit of the Oberth effect for the final burn.
You plot your maneuver node. Several orbits before the maneuver node time, you start incremental burns -> the maneuver marker in the navball moves and can bounces up & down along on the pro/retrograde plane. The remaining amount of deltav to be burned varies a lot (I had 850 -> almost 5000).

Have you noticed this phenomenon?

Edited by OnlyLightMatters
Not a bug
Link to comment
Share on other sites

Hey, did you add steering parts (the tiny thrusters that have 4 tiny rockets going it opposite directions)

if not try this. I’m not sure if it’s what you need, but I have made the mistake of forgetting these before. 
if it does help post that it worked, so other players can see it. 

Link to comment
Share on other sites

I could be wrong, but I don't think it was a bug...

A maneuver node is essentially a "plan" to achieve a certain trajectory. As such, once the node is established, what the Navball maneuver prograde marker indicates is how to continue to achieve that path - both in direction and required dV, not necessarily what was contemplated when placing the node (i.e. x amount of thrust in prograde direction, and so on).

Thus, with a low-TWR vessel, in order to accomplish what was planned with the maneuver node, let's say a burn that takes 10 minutes at low thrust (optimally accomplished by starting 5 minutes before the node and completed 5 minutes after the node), as the vessel proceeds past the 5-minutes-before mark, the requirement for thrust will exceed the thrust available and the node reflects that by increasing and a continuously changing requirement as you continue to close in on the node, as displayed.

Additionally (edit add) if your TWR does not allow a single orbit burn (it requires too much time) it will act rather bizarrely regardless of how you attempt it - the solution is plan a, say, 10 minute burn over multiple orbits until the cumulative effect results in your desired trajectory / path.

[Edit 2:

A full circular orbit at 100,000m takes about 32 min 38 sec.; a 35 min burn would literally require burning over an entire orbit and then some.

Maneuver nodes are simplifications of a maneuver's burn requirement - AS PLANNED they are "instantaneous" burns, meaning we know that to be precise, you would need to "instantaneously" burn all the dV at the point of the node. Realistically (even in KSP!) we have to distribute the burn over time due to TWR constraints (the half-before the node, half-after referenced above), with the burn time constraints becoming virtually impossible as the burn time requirement exceeds half of an orbit.

Hope that all makes sense... ]

Edited by Wobbly Av8r
Additional information
Link to comment
Share on other sites

7 hours ago, OnlyLightMatters said:

Several orbits before the maneuver node time, you start incremental burns  [ . . .]

Have you noticed this phenomenon?

Yes.   The remaining burn, for nodes a few orbits in future, has behaved in this strange way since at least version 1.2.1, so unfortunately it might not but just a bug, but something they never designed in the first place.

I think the remaining-burn display does roughly this: 
Figure (a) the craft's velocity at the maneuver-node time, given its current orbit after maybe a partial burn, then
subtract (b) the velocity along the planned route at the maneuver-node time.

But if you split a long burn into a few orbits, then when you start the partial burn you lengthen the time it takes for one orbit, so at the original time of the maneuver, our current orbit might be maybe one-and-a-half orbits in future, and then the velocity (a) is taken from a point in the orbit when we are going the wrong way.

What we would like to see, is the difference between our velocity when we return to the maneuver node's angular position around the orbited body, at whatever time that may be, and the desired velocity after the maneuver.   (The UTC time of the maneuver node would then need to change.)  I would guess that is possible to program, but difficult to get the details right like exactly how to define that angular position.

To help with this situation, people have made maneuver-node-splitting mods, that we might still find on this forum.

Link to comment
Share on other sites

8 hours ago, OnlyLightMatters said:

I've tried to understand what seems to be a bug in 1.11.0

Suppose you want to leave Kerbin. You plot your maneuver mode, you warp just before starting burning, you burn -> behaves like expected.

Now let's use a craft with a low TWR. We need to achieve our transfer with slowly raising your apoapsis and gain benefit of the Oberth effect for the final burn.
You plot your maneuver node. Several orbits before the maneuver node time, you start incremental burns -> the maneuver marker in the navball moves and can bounces up & down along on the pro/retrograde plane. The remaining amount of deltav to be burned varies a lot (I had 850 -> almost 5000).

Have you noticed this phenomenon?
That's very annoying regarding xenon powered crafts :/

This is a video to illustrate the issue.

 

there's nothing strange there, it's absolutely normal.

When you set up the manuever node, say, 10 orbits for now, in 5 hours because you have a 30 minutes orbit.

then you start burning well before the time, and your orbit changes. it change time. so now in 5 hours you won't be on your manuever node again, you will be in a different part of the orbit. but the game still think you will want a manuever node in 5 hours, because manuever nodes are set in time, not in position. So, of course to perform the same manuever in the completely wrong part of the orbit, you would need a much higher amount of deltaV. But then, keep burning prograde, you will achieve a 33 minutes 20 seconds orbit, and 9 of those orbits will get you at your manuever node in exactly 5 hours, again! so the burn time will go down again.

And then your orbital time will again go up, and your manuever node will be screwed, until you will increment orbital time enough to get 5 hours in 8 orbits. and so on.

Just make the manuever node anew after every incremental apoapsis raising.

Link to comment
Share on other sites

Yeah I think you are right (all of you).
Some quotes.

Just make the maneuver node anew after every incremental apoapsis raising.

-> The idea was to plan the node to make incremental raising so that each of them could take in account a strong normal deviation which happens sometimes for interplanetary transfers with inclined celestial bodies (Eeloo, moho).

To help with this situation, people have made maneuver-node-splitting mods, that we might still find on this forum.

Will do some research :)

Additionally (edit add) if your TWR does not allow a single orbit burn (it requires too much time) it will act rather bizarrely regardless of how you attempt it - the solution is plan a, say, 10 minute burn over multiple orbits until the cumulative effect results in your desired trajectory / path.

This is why it is the whole point of raising slowly your apoapsis and quickly you will have hours or days to complete a maneuver.

Edited by OnlyLightMatters
Link to comment
Share on other sites

Periapsis kicks aka breaking up a looong burn into a series of shorter ones, all on the periapsis to maximise efficiency (hence the name), is a pretty standard procedure when you have limited TWR and unlimited (or close enough) engine ignitions- because in real life most rockets can only be lit once rather than flipped on and off like a switch as for KSP. There’s even a mod to do just that- Maneuver Node Splitter, which can split the node by burn duration, orbital period or maximum apoapsis.

Just be glad that you’re not using real ion thrusters, which have thrust measured in milliNewtons not kiloNewtons and which take months to do their burns...

Link to comment
Share on other sites

On 1/15/2021 at 5:02 PM, OnlyLightMatters said:

Have you noticed this phenomenon?

What engine, what reaction wheels?

Is COM coaxial with thrust?

I nottice this phenomen every time I build crap that is not corectly engineered because I would have some fancy construction instead of symetric one.

On 1/15/2021 at 5:57 PM, Wobbly Av8r said:

Maneuver nodes are simplifications of a maneuver's burn requirement - AS PLANNED they are "instantaneous" burns, meaning we know that to be precise, you would need to "instantaneously" burn all the dV at the point of the node. Realistically (even in KSP!) we have to distribute the burn

In real manouvers are counted this way. Then from this point they are computed for specific engines and controls depend of remain fuel and mass distribution.

On 1/16/2021 at 3:37 AM, FloppyRocket said:

I think the key issue is that maneuver nodes assume you're going to make an impulse burn of the required delta-v, and it doesn't expect the maneuver to be spread out over time.

Whole orbital mechanics use this. It is why there are corection burns.

On 1/16/2021 at 10:12 AM, jimmymcgoochie said:

Just be glad that you’re not using real ion thrusters, which have thrust measured in milliNewtons not kiloNewtons and which take months to do their burns...

With this hair drayer thrust there is no issue of counteracting them with thrusters. Reaction wheel is enough.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...