How do I turn wheel encoder ticks into x, y and heading for a differential-drive robot?

Convert ticks to distance first. One wheel revolution is π × 65 mm = 204.2 mm, so each count is 204.2 / 1440 = 0.1418 mm. For each update take the change in counts since the last update, not the totals: dL = Δticks_left × 0.1418 mm, and the same for dR.

Then the distance moved by the robot centre is d = (dR + dL) / 2 and the change in heading is dθ = (dR - dL) / b, in radians, where b is the track width (150 mm here). Counter-clockwise is positive with this sign convention.

The pose update that works well in practice uses the heading at the middle of the step: x += d × cos(θ + dθ/2), y += d × sin(θ + dθ/2), then θ += dθ. Worked example: left wheel 1000 counts, right wheel 1100 counts. dL = 141.8 mm, dR = 156.0 mm, so d = 148.9 mm and dθ = 14.2 / 150 = 0.0945 rad, about 5.4°.

Run the update often enough that dθ per step stays small, for example every 10 to 20 ms, and keep θ in radians inside the code.

Accuracy is limited by systematic errors much more than by encoder resolution. The two that matter are unequal wheel diameters, which make the robot curve when the counts say it went straight, and an uncertain effective track width, which scales every turn. The contact patch of a soft tyre is not a point, so the effective b is rarely the value you measure with a ruler.

Heading error is what hurts: a 1° heading error carried over 5 m of travel puts you 5 m × sin(1°) = 87 mm off to one side, and it keeps growing.

Calibrate with two simple tests. Drive a straight line of a few metres and compare the measured distance with the odometry distance to correct the mm-per-count figure, and note any sideways drift to trim the left/right ratio. Then spin in place for ten full turns and compare the odometry heading with 3600°; adjust b until they agree.

Driving a square in both directions and measuring the return error separates the two effects more rigorously, because a diameter mismatch and a track width error behave differently when the direction of travel is reversed.

Adding to the point about heading: encoder odometry cannot see wheel slip, bumps or a carpet edge, so the error is unbounded over time. The usual next step is to take heading from a gyro (integrated yaw rate) and distance from the encoders, since a gyro is not fooled by slip. For anything longer than a few metres you need an absolute reference as well, such as markers, a lidar scan match or beacons, with a filter to blend them.

In firmware, read both counters at the same instant and use signed differences so that counter wrap-around does not produce a jump.