Repository navigation
Carry partial encoder ticks between wheel odometry samples - #10
Merged
Merged
Conversation
Each sample rounded its own wheel travel to whole ticks and dropped the remainder. The distance error then depended on speed: -8% at 0.2 m/s and +15% at 0.04 m/s. Below half a tick per sample the odometry read zero. The model now keeps the total travel of each wheel and quantizes that total, as an encoder count does. The error stays below one tick. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
buildWheelOdometryMeasurementrounded each sample's wheel travel to whole ticks withquantizeTraveland dropped the remainder. A real encoder counts the total rotation, so partial ticks add up. Here they were lost or gained on every sample.The distance error then depended on speed. Measured over 30 s at 50 Hz with the default 0.15 m wheel and 1024 ticks per revolution:
Below half a tick per sample, about 0.046 m/s at 50 Hz, the odometry read zero.
Fix
The measurement state keeps each wheel's total travel (
leftTravelM,rightTravelM). Each sample rounds the total to whole ticks. The travel it reports is the change in that tick count.leftTicksandrightTicksnow hold the encoder count directly.The position error stays below one tick (0.92 mm with the defaults) at any speed.
Tests
tests/localization-sensors.test.js: 30 s straight runs at 0.01, 0.2, 1 and 3 m/s with pose noise off. Each final distance is within one tick of truth. Without the fix, 0.01 m/s reports 0 m against 0.3 m.npm teston a clean checkout: all pass exceptPython decodes retained RGB, depth, and CameraInfo SFLog messages, which also fails onmain.Related
#9 fixes the integration interval in the same function. The two PRs merge cleanly in either order; I checked the combined result with
npm test.The measured wheel odometry values change for every run.
deterministic-state-sensorsstays at version1. Bump it if recorded runs must reproduce exactly across this change.🤖 Generated with Claude Code