Turn consistency issues with Pybricks 4.x

[joshsloat]

Our FLL team had great success using Pybricks with our robot last season, finishing second in the robot game in the state of Michigan. We went from measuring route inconsistencies in inches to millimeters with a driving base that evolved with our Pybricks adoption. We concluded in late December '25 with Pybricks 3.6.1 and picked back up recently with 4.1. With this same driving base build and the same code base, but using the latest Pybricks, our robot is not driving with nearly the same reliability or precision. And I'm noticing it particularly with turning.

We honestly haven't identified everything that's contributing to the consistency issues, but I'm attaching a video to demonstrate one of the turning issues we did pinpoint. On a simple run where the robot drives straight forward and then does a 20 degree right turn and then drives forward again, the robot seems to do a small turn right as part of the last drive straight. And I'm certain this turn is happening with the start of the second drive straight because we've separated each drive command block with wait blocks to help isolate.

Pybricks.Turn.mp4

In this short example, if I put waits before and after the turn and brake instead of hold after the turn, I get something that works more like the consistency we saw with 3.6.

Bad Behavior

Hack That Makes It Better

But I don't love that as a solution since it's going to add wasted time and possibly contribute to the kind of accumulated errors that hold used to prevent.

Possible Driving Base Design Implications
For our rear wheels, we use spinning discs as opposed to castors. In our testing last season, we found that these made for better straight line consistency and any drag introduced in turns was easily compensated for. At least half of the robots we saw at Worlds used this design pattern, so I'm confident it's historically been a sound approach, but I can't help but wonder if this approach is fighting with some potentially new aspect of the the internal Pybricks PID implementation (our driving base is configured to use gyro) or something along those lines.

I'm really hoping someone can provide some insights into what changed between 3.6.1 and 4.1 that could be contributing to this behavior, and consequently, what we might consider doing differently to adjust. Thanks for any insights!

[zoligyenge]

I have the same issue with a wobble after a turn. But nothing new with pybricks 4.x

As far as I can tell it is due to the play in the motor gearing. In your example, when you turn right, your left wheel turns forwards, but your rigth wheel turns backwards. This means that for drivign straight, just as you start driving, your left wheel is engaged to drive forwards but the right wheel is not. Hence, in the very first moment of driving straight, the robot will veer right, which is then very quickyl corrected, but the effect is noticable.

May what happened is that with time your motors got older and the play of the gearing got more pronounced.

BTW: I am also curios as how to prevent this. Maybe turn one of the motors (not drivebase) by 1° before driving off just to engage the gearing?

[Sirus-7]

The two rear wheels are subject to significant friction when turning.
You should replace them with steering ball joints, which will significantly improve driving performance.
(Steering Ball Joint - 92911 + Wheel Ball - 52629)

[joshsloat]

Thanks, @Sirus-7. We did a lot of testing in Pybricks 3.x with both the dual rear discs and castors and the rear discs achieve better overall run consistency. The theory is that you spend more time driving straight than turning and the dual rear discs help keep the robot better aligned in straight line driving. And we ran all of last season this way without the issues we're seeing now.

[Sirus-7]

Are you using the gyro sensor?
I've sometimes noticed some strange behavior when using it with DriveBase.
When the robot came to stop, it would move again briefly.
(TechnicHub)

[Debenben]

@joshsloat in case you are using the gyro you will only get good results if you calibrate it, see imu.settings() in documentation. Those settings are lost during firmware update so you need to restore them manually or calibrate again.

[joshsloat]

Thanks @Debenben. We are using the gyro, but never did any manual calibration in the past. I thought I had read somewhere (can't find now) that this used to be a manual process, but that re-calibration was more automatic now. What kind of tuning have you done with settings? Any tips, effective approaches, etc would be much appreciated!

[Debenben]

To calibrate your hub you can run the program import _imu_calibrate on the hub and follow the steps. That calibrates angular_velocity_bias, angular_velocity_scale, acceleration_correction to compensate for mechanical stress introduces when soldering it to the pcb. You need to repeat this or backup and restore the values whenever you install a new firmware.

The other calibration is done by the hub itself whenever it thinks it is stationary. With the gyro you can only measure angular acceleration. A constant offset in acceleration means your angular velocity changes linear in time and your angle changes quadratic. The more often your hub thinks it is stationary, like during the pause in your example, the more often can set this drift back to zero. You can test with print(hub.imu.stationary()) if your hub thinks it is stationary. In case it is not stationary when it should be you need to adjust angular_velocity_threshold and acceleration_threshold.

[laurensvalk]

Thanks @joshsloat for reporting. To help pinpoint the issue, could you kindly retry this with your current robot on different firmware versions?

You can easily do that with the current day Pybricks editor using these instructions.

You can try it with these firmware files:

• Current version: v4.1.0 where you are seeing this issue.
• pybricks-primehub-v4.0.1.zip
• pybricks-primehub-v3.6.1.zip reportedly your good version, worth confirming.

If you can see a difference, I can give more intermediate versions to further close in on which change made the difference.

[joshsloat]

Thanks, @laurensvalk. Will test these out and get back with you!