Maneuver node off by 200 m/s?

[Brainlord Mesomorph]

I’ve been having trouble with my interplanetary transfers that I’d been blaming on my own sloppy piloting. But this time it wasn’t me. Honest!

Flight to Jool. Got my transfer window from AlexMoon, Found the departure angle, put my ship in an elliptical orbit (9000km x 100km) w/ Pe at the departure point. Plotted a perfect departure burn; intercept just at Ap, which was just at Acending Node (actually was plotted as collision w/ Jool)

Ship has a low TWR, so it’s a 15 minute burn. Can’t  start 8 minutes before the node, that too early, so I go 4 minutes early, and the burn is going to run 4 minutes late. Locked to node, the burn is nominal. At T+8:15,  with 40m/s to go,  I switch to map view and my AP is already way past Jool!

I abort the burn, and plot a correction; It’s going to take a retrograde burn of 150 m/s just to get me back to my original course.  What the kerb happened?

It wasn’t me!

 Was the plotted node off by almost 200m/s?

Is that possible?

Did the nav system not properly calculate Oberth effect?

What gives?

Edited February 2, 2018 by Brainlord Mesomorph

[Atkara]

I've seen this happening and the only explanation I could come up with, is that when you start the burn, you're burning between prograde and radial in. This means you're lowering and moving your periapsis as you go, effectively throwing off any previous calculation.

This also happens to relatively fast burns, but the effect becomes much more 'dramatic' during long ones.

Or I could just be wrong.

[Jarin]

25 minutes ago, Atkara said:

I've seen this happening and the only explanation I could come up with, is that when you start the burn, you're burning between prograde and radial in. This means you're lowering and moving your periapsis as you go, effectively throwing off any previous calculation.

This also happens to relatively fast burns, but the effect becomes much more 'dramatic' during long ones.

Or I could just be wrong.

This is my thought. 4 minutes early notably lowered your PE at Kerbin, which increased the Oberth effect on your maneuver. Remember, a maneuver node is only 100% accurate if you have infinite TWR, and can deliver the dV instantaneously.

I think mods can help here. I'm not sure if better burn time has calculations like this, but I bet someone does.

[Tyko]

initial DV calculations are based on applying all the necessary thrust at a single moment. In reality, you can't do that so there's going to some error introduced because you're executing part of the burn early and part of it late. The more time your burn takes, the more pronounced that error is.

One solution is to use a series of shorter 4-6 minute kicker burns. Burn on the first orbit for 4-6 minutes. On the next orbit you burn for another 4-6 minutes and you keep repeating until you've completed the maneuver. This can make it more complicated, but will help you stick to your DV budget.

Another solution I'm trying with my current save is to follow what many real rockets do...they use the third launch stage to make the transfer burn. After the burn is complete it's staged and your smaller payload goes coasting off. This stage typically has bigger engines than your payload would, and it's already consumed some fuel getting into orbit. It'll likely have over a 1.0 TWR so you can reduce burn length substantially.  This is how the Apollo missions worked.

Edited February 2, 2018 by Tyko

[Brainlord Mesomorph]

Well, yes, yes, and yes but no.

My burn was early but mostly centered on the node.

It did reduce Pe, but only by like 8 km (103 to 96 km) and only temporarily, for the second half of the burn PE was rising.

I did do Pe kicks, thats why it was only a 15 minute burn.

And even if it did underestimate Oberth effect at first, it would have autocorrected that during the burn (it doesn't matter why velocity is changing, just that it is).

But even if all those things were true it still wouldn't explain overshooting my target by 200 m/s. It was only an 1100 m/s burn,  forget 100% accurate, that's off by almost 20%!

Here's one thing that might explain it: its a giant kilometer long colony cruiser with over 1000 parts that's choking the game to death. I counted and I was getting 1 second of game time for every 5 seconds of realtime. So the ."15 minute" burn ended up being over an hour of processing. Perhaps with all that overhead it wasn't updating the remaining dV properly.

Now that I look; all of my interplanetary ships are overshooting there targets to one extent or another.

So from now on all my interplanetary burns are happening in map view!

Edited February 2, 2018 by Brainlord Mesomorph

[SpacedCowboy]

A kilometer long? Over a 1000 parts? Geesh!

Have you noticed any smoke rising up from your PC?

[Guest]

48 minutes ago, Brainlord Mesomorph said:

So from now on all my interplanetary burns are happening in map view!

Yeah.

This bit me too quite a long time ago, and I had almost forgotten there was any other way to do them.

[Cpt Kerbalkrunch]

48 minutes ago, Brainlord Mesomorph said:

Here's one thing that might explain it: its a giant kilometer long colony cruiser with over 1000 parts that's choking the game to death. I counted and I was getting 1 second of game time for every 5 seconds of realtime. So the ."15 minute" burn ended up being over an hour of processing. Perhaps with all that overhead it wasn't updating the remaining dV properly.

Now that I look; all of my interplanetary ships are overshooting there targets to one extent or another.

So from now on all my interplanetary burns are happening in map view!

I've got plenty of ships with over 1,000 parts, and my current record is over 1,900 for an Eve lander, but a kilometer long is freakin' nuts. Any bigger and that thing would be out of its own physics range. 

[Brainlord Mesomorph]

1 hour ago, Cpt Kerbalkrunch said:

I've got plenty of ships with over 1,000 parts, and my current record is over 1,900 for an Eve lander, but a kilometer long is freakin' nuts. Any bigger and that thing would be out of its own physics range. 

\

The Olympus Interplanetary Coloniation Cruiser: Seen departing the Hephestus Spacedocks, Over a kilometer long, half a kilometer tall, and 3/4 of a kilometer wide, 950 tonnes. She carries 6 assorted nuclear landers, has two labs, large scale ISRU facilities and room for 44 Kerbal colonists plus crew. AND  can carry 120 tonnes of additional payload anywhere in the solar system.

Edited February 2, 2018 by Brainlord Mesomorph

[helaeon]

I think likely there are some major physics inaccuracies going on here. What is your physics tick time set at? You might be an edge case where you have an incredibly large/long vessel, with long burn times... does it wobble as you burn? Also are your engines burning directly ahead or are you angling your engines to get them to match your center of mass (including relying on gimbals to do it). You'll have delta-V correctional losses from that which could be adding up. 200m/s is a lot but you might have a bunch of little things and errors in the simulation adding up to a significant total sum.

[Cpt Kerbalkrunch]

1 hour ago, Brainlord Mesomorph said:

\

The Olympus Interplanetary Coloniation Cruiser: Seen departing the Hephestus Spacedocks, Over a kilometer long, half a kilometer tall, and 3/4 of a kilometer wide, 950 tonnes. She carries 6 assorted nuclear landers, has two labs, large scale ISRU facilities and room for 44 Kerbal colonists plus crew. AND  can carry 120 tonnes of additional payload anywhere in the solar system.

[GoSlash27]

17 hours ago, Brainlord Mesomorph said:

It was only an 1100 m/s burn, 

BM,
 I verified that figure on my spreadsheet, and my numbers concur. I got 1,110.9 m/sec DV for that burn. 1,931.3 for the Hohmann transfer minus 820.4 for being at the Pe of a 9 Mm x 100 km orbit. Whatever the problem, it wasn't the nav computer.

Best,
-Slashy

[Brainlord Mesomorph]

16 hours ago, helaeon said:

I think likely there are some major physics inaccuracies going on here. What is your physics tick time set at? You might be an edge case where you have an incredibly large/long vessel, with long burn times... does it wobble as you burn? Also are your engines burning directly ahead or are you angling your engines to get them to match your center of mass (including relying on gimbals to do it). You'll have delta-V correctional losses from that which could be adding up. 200m/s is a lot but you might have a bunch of little things and errors in the simulation adding up to a significant total sum.

 

Yes, all of those things could cause a loss of dV. But 1, my ship doesn't have those problems, CoM and CoT where perfectly centered, and 2, I din't have a LOSS of dV, if anything I had  gain of dV and more importantly one that didn't appear in the nav system.

I wish I had grabbed a screenshot of it but I was too busy panicking; My Ap was way above (150m/s) my desired Ap but the Navball was telling me to keep burning prograde. it made no sense. I guess I was burning the extra fuel, but the navball wasn't telling me to cut the burn.

Like I said the game was choking to death, 1 second of gametime for 5 seconds of processor time, and down to like 2 fps. My best guess is that when you overload the system like I was, there is some sort of cumulative error in the nav system. It may not happen in map View at all. We should do tests.

 

54 minutes ago, GoSlash27 said:

BM,
 I verified that figure on my spreadsheet, and my numbers concur. I got 1,110.9 m/sec DV for that burn. 1,931.3 for the Hohmann transfer minus 820.4 for being at the Pe of a 9 Mm x 100 km orbit. Whatever the problem, it wasn't the nav computer.

Best,
-Slashy

Hi slash, Good to hear from you,

You're checking my math? You don't think I know how to get to Jool?

B

[GoSlash27]

17 minutes ago, Brainlord Mesomorph said:

You're checking my math?

BM,
 Nah. It's not your math, it's the nav computer's math. I'm just verifying that it told you what it was supposed to so you can eliminate it as the culprit.
 

Best,
-Slashy

Edited February 3, 2018 by GoSlash27

[Brainlord Mesomorph]

8 minutes ago, GoSlash27 said:

BM,
 It's not your math, it's the nav computer's math. I'm just verifying that it told you what it was supposed to.
 

Best,
-Slashy

Just giving you a hard time. No comment on the giant spaceship?  (in year 3 of my career game no less)

 

I've got an upcoming  (smaller) colony flight to Duna. 

I'll deliberately save the game and do the burn twice. Once in map view, and once while I watch the ship in orbit. 

Let see what happens.

B 

[GoSlash27]

19 minutes ago, Brainlord Mesomorph said:

No comment on the giant spaceship?

Nah, not particularly.

Best,
-Slashy

[Brainlord Mesomorph]

 

[GoSlash27]

33 minutes ago, Brainlord Mesomorph said:

 

Sorry
 Not really anything to say about it that you don't already know. It's a really big ship and it may be breaking your game *shrug*.

Best,
-Slashy

[Laie]

@Brainlord Mesomorph: simply put, this is (part of) the price you pay for a low TWR and the resulting long-duration burns.

Watch where the maneuver node marker is on the navball during the burn. Most of the time it's not lined up with the prograde marker. If you started four minutes early, it was probably 20° off (inwards to Kerbin) ; later during the maneuver, I guess that it might have been pointing outwards by a similar-if-not-larger amount.

A smaller, but still significant, amount is lost because you're not doing a short impulse that's basically at right angles to gravity, but keep pushing while Kerbin's gravity is already tugging at your coattails, trying to hold you back. In other words, old-fashioned gravity losses.

[GoSlash27]

Laie,
 The problem is that the burn actually *overshot* the intercept by a large margin. Cosine errors only account for an undershoot.

Best,
-Slashy

[Rune]

I think what is happening is, the maneuver node gets moved around your orbit as you change it. Have you checked that you burned only the time and dV you were supposed to? I mean, I do low TWR ejections all the time, and I always need more dV than the node says I will. But I time my burns, and when I finish them the maneuver node still thinks I have more to do. It' just that the maneuver took place over a significant part of my orbit, and the place the node was put in is no longer anywhere close.

 

 

Rune. I seriously doubt it's a physics bug.

[Laie]

3 minutes ago, GoSlash27 said:

The problem is that the burn actually *overshot* the intercept by a large margin.

That's just an artefact of the maneuver-node smartness.

Nodes try to correct for all kinds of errors. Point left for a little while and you will notice how the marker shifts right; it tries to point in the direction you need to go (now! instantly!) to put you on the desired speed&vector.

I do *not* know how it really works and what it takes into account; I do know that it works well until it no longer does; taken beyond it's limits it starts to make matters worse. Going halfway around Kerbin on a single maneuver node is bound to lead to strange results.

[Brainlord Mesomorph]

47 minutes ago, Laie said:

That's just an artefact of the maneuver-node smartness.

Nodes try to correct for all kinds of errors. Point left for a little while and you will notice how the marker shifts right; it tries to point in the direction you need to go (now! instantly!) to put you on the desired speed&vector.

I do *not* know how it really works and what it takes into account; I do know that it works well until it no longer does; taken beyond it's limits it starts to make matters worse. Going halfway around Kerbin on a single maneuver node is bound to lead to strange results.

Hi L,

I was already well past my  desired Ap and the NavBall was telling me to keep going in the wrong direction. That's not "smartness." 

It might be miscalculation due to massively overloading the system, or it might be a result of underestimating Oberth effect.

It all boils down to a couple of "Nature-Of-The-(KSP)-Universe" questions like: "What IS a maneuver node, anyway?" '

Is it (a) an amount of thrust in a direction at a time? or is it (b) a desired orbit at a time? (and the thrust and direction are calculated).  "How DOES the game update the navball during the burn?" Is it (a) a question of the amount of thrust exerted so far (and its direction) ? or is it (b) a question of your current location and speed vs where you want be? In both cases "b" would be more accurate, (indeed totally self correcting) but "a" would be less work on the computer (and easily fooled by underestimating Oberth effect). 

It might be method "b" while you plot the burn, but "a" as soon you take you finger off the mouse. Heck, it could be "a" in orbital view, but "b" in map view. 

Experiments are needed.

Edited February 3, 2018 by Brainlord Mesomorph

[GoSlash27]

27 minutes ago, Brainlord Mesomorph said:

Experiments are needed.

Agreed

Best,
-Slashy

[Laie]

1 minute ago, Brainlord Mesomorph said:

"How DOES the game update the navball during the burn?"

That is indeed a good question.

2 minutes ago, Brainlord Mesomorph said:

or is it (b) a question of your current location and speed vs where you want be?

I *think* this comes very close to the mark.

I believe it compares the track you are on with the track you want to be on (the dotted line in map view) and somehow computes a vector that takes you from one to the other. Said "tracks" can also be expressed as a vector+timestamp+orbital_mechanics, so I guess it comes down to comparing vectors.

But, as I said, that's only guesswork. I've done some experiments where I started the burn sooner or later, or tried to not strictly follow the mark on the navball ("if I don't point as far in during the first half of the burn, maybe I don't need to point as far out later on") but none of these have lead anywhere: Merely comparing dV is a bit one-dimensional, and beyond that I don't know how to quantify if one outcome is better or worse than another.

On a practical side, I did get good results with splitting burns, that is, lining up two or three maneuvers end-to-end with only short breaks between. Planning this is a PITA (and it breaks down if burn times overlap, so you really want to be conservative), but the upside is that you get the encounter you've been aiming for, at very nearly the dV expense as it said on the nodes.