Heading drift after multiple DriveBase.turn() calls despite Stop.HOLD

[zoligyenge]

Hi,

I’m seeing heading drift after several consecutive drive_base.turn() calls, even though I’m using Stop.HOLD.

Turns are chained and are all multiples of 90° (e.g. ±90°, 180°, 270°)

Example pattern:

drive_base.turn(90)
drive_base.turn(-90)
drive_base.turn(180)
drive_base.turn(270)

Observation:

After a few turns, the final heading is slightly off. For example, I repeatadly (that is on multiple runs of the robot) end up at 88° instead of 90° relative to the starting orientation. The IMU reports 88°, and physical measurement confirms the robot is indeed about 2° off. So the IMU reading appears correct.

My understanding is that the built-in turn() method with Stop.HOLD is supposed to account for accumulation of tolerance errors between turns. In that case, I would expect these small errors not to accumulate over multiple ±90° / 180° / 270° turns.

Why is this 2° deviation not corrected by:

Stop.HOLD after the turn finishes?

Or at least by the next drive_base.straight() call?

Is this related to turn completion criteria, internal pose tracking, or how HOLD works internally?

As a side note: a more detailed explanation of how the different DriveBase stop types (especially Stop.HOLD) behave internally would be very welcome. I fully appreciate that Pybricks is developed in your free time — the work you’re doing is fantastic — but some deeper documentation of the control logic would really help advanced users understand edge cases like this. (Or maybe it is on purpose so people experiment more?)

Thanks

[laurensvalk]

I’m seeing heading drift after several consecutive drive_base.turn() calls
After a few turns, the final heading is slightly off.

If it is by the same amount every time, these statements can't be both true 🙂

With hold, the robot will update its target when you make incremental turns, so +90 etc. So it will go from 180 to 270 even if it happened to end up at 182 in the last move. With coast or brake, there isn't a way to know what you intended, so it will just aim for +90, e.g. 272 in this example.

So when using hold, you can do this pretty much endlessly and never drift:

drivebase_turn2.mp4

In this demo, note that it doesn't make full circles (360 not being exactly 360 is a separate matter altogether).

[zoligyenge]

I’m seeing heading drift after several consecutive drive_base.turn() calls
After a few turns, the final heading is slightly off.

If it is by the same amount every time, these statements can't be both true 🙂

With hold, the robot will update its target when you make incremental turns, so +90 etc. So it will go from 180 to 270 even if it happened to end up at 182 in the last move. With coast or brake, there isn't a way to know what you intended, so it will just aim for +90, e.g. 272 in this example.

So when using hold, you can do this pretty much endlessly and never drift:

drivebase_turn2.mp4
In this demo, note that it doesn't make full circles (360 not being exactly 360 is a separate matter altogether).

Sorry I wasn't precise: What I meant is that the (accumulated, or drifted) error is the same on every run of the robot but not after avery turn.

[laurensvalk]

Right, but does the number go up for more turns?

What if you did +90 and -90 in a loop 10x, for example?

[zoligyenge]

Right, but does the number go up for more turns?

What if you did +90 and -90 in a loop 10x, for example?

You are right, it does appear to rather fluctuate rather than accumulate in this test. However, in our actual competition program, we got smilar errors around the same place multiple times. That is why we thought about accumulation.

BTW: When I do a full 360° turn and print out heading and driven angle, they arre not exaclty 360°. I tried changimng the axle track. Is there any other way to improve accuracy? For example by lowering the motor tolerances?