General Question Standard autopilots, slight inaccuracies?

[Beavis]

Could someone who is knowledgeable about the internal workings of Orbiter give me some insight into how the autopilots work? I'm using the patched 2010 edition.

I had noticed, as I'm sure most have, that when in LEO and doing a burn with the normal or antinormal autopilots, on the Orbit HUD the normal and antinormal vectors move as the delta-vee is applied, and the nose of the craft lags behind those vectors. I had also noticed that the nose does not appear to drift away from the prograde or retrograde markers when using those autopilots and doing burns. I hadn't worried about it, in fact I just assumed that the normal/antinormal autopilots had a small bug in them …

Lately I did some RK4 simulations of prograde burns in low planetary orbits, to simulate ejections from orbits a little more accurately. And my numbers are always a shade off from what happens in Orbiter. I've verified that I'm doing RK4 correctly and the error is larger than what could be attributed to the fact that RK4 is good-but-not-quite-perfect. Now the errors aren't large enough to complain about, a fraction of a percentage point, but they are there and are consistent. And that got me to take a closer look – literally, zooming into 10 degree FOV (something I had no reason to do before) -- and then I noticed something I had missed earlier.

When the (anti)normal autopilot is on and the ship is in a stable orbit (no burn), the nose of the craft is right on the +/- “90 degree latitude” marker on the Orbit HUD. But with the prograde and retrograde autopilots, the nose is pointed about 1/3 of a degree to the right of the appropriate HUD marker (outward from the central body for prograde; inward for retrograde). However, unlike the (anti)normal autopilots, which drift away from the normal vectors during a burn, the prograde and retrograde autopilots do not drift away from this position during burns (except in extreme cases; e.g., burning retrograde until orbital velocity = 0).

I'm guessing that the autopilots cannot quite precisely track changing vectors, and that Orbiter handles this in two different ways. For the (anti)normal autopilots, the autopilots just track the vectors the best they can and the chips are left to fall where they may (altering the periapse/apoapse of the orbit). For the prograde and retrograde autopilots, a small fudge factor is used to compensate, skewing the autopilot slightly in the direction in which a burn would bend the trajectory. But that's just a guess; obviously I don't know firsthand. Is that what's happening? Or if it's not, what's the reason for the autopilots acting this way? And again, I'm not complaining, it's a wonderful program and I've had a lot of fun with it.

 

[francisdrake]

That is an interesting observation you made! I checked it on my Orbiter 2010 installation and it shows the same result. Prograde is pointing outwards by ~0.3° (marker lines are every 2°). Retrograde is pointing inwards by the same amount.

I was suspecting this might be a result of using either the Surface or Orbit MFD, but the value seems to be the same for both.
Then I was suspecting this may have to do something with the planetary rotating reference frame. So I went into a retrograde orbit, looking if the signs would be revised. But the effect is the same for a retrograde orbit.
At the moment I am out of ideas, what might cause this slight deviation ...

 

[n0mad23]

It's the same for heading when using Multistage2's guidance files. Ninety degrees is always off by your 0.3 deg. But Mulitstage2 is so buggy on 2010 (guidance files fail in running probably 60% of the time for me) I hadn't noticed the parallels with the built in autopilots.

Good observation.

 

[Beavis]

Thanks to both of you for confirming that I'm not crazy. :lol:

Just for kicks, I added a yaw variable to my RK4s, so that instead of simulating an exactly prograde burn I can set the nose of the craft to stay pointed at a fixed angle to the left or right of the prograde vector. Like both of you, I read the discrepancy on the HUD as being around 0.3 degrees, maybe a little more. But when I tried out different small values I got the best results by holding the nose 0.23 degrees to the right of the prograde vector. The SMA ends up a little off when I do the same maneuver in Orbiter (I'm still trying to figure out why), but if I manually adjust that to where it should be with a few thruster taps just after the main burn is completed, the other elements (Ecc, LPe) fall into line exactly where they're predicted to be.

So, I dunno <shrug> ... I guess unless someone tells me differently I'll assume that prograde really means 1/4 degree off prograde.

 

[kocmolyf]

I suspect that the prograde/retrograde autopilots are operating in inertial space with a PID controller. Since the derivative gain is applied to angular velocity in inertial space rather than local horizontal space, it can prevent the controller from actually reaching its target (because tracking the velocity vector requires a constant inertial angular velocity). The bias will be in the "lagging" direction, which is consistent with the prograde-out, retrograde-in observation. Try using the autopilots in a large heliocentric orbit - they should have virtually no bias there.

Because the orbital momentum vector (normal/anti-normal) is fixed in inertial space (with a spherical gravity model), you don't have this problem in those directions.

Unfortunately, without knowing the inner workings of the Orbiter autopilot PID controller, it will be hard to predict the bias exactly. You'll probably have to use a fudge factor in your simulator. Note that the "fudge" should be proportional to the rate at which the velocity vector is changing, i.e. the local gravitation.