Odometry Glitches
Contents
Background and Set Up
These odometry glitches were discovered during motor control PID tuning. See
Example Graph
These measurements are under no load. The robot is resting on a test bench with the wheel off the table.
Observations
- Notice the odometry glitches that report a 0 m/sec wheel speed. This issue appears to be an odometry node bug. See below.
- Notice the wheel speed short term oscillation. This issue may be an encoder node issue bug because of a lack of time precision. See below.
Zero Wheel Speed Glitches
Tests Starting at 0 degree heading
These test start with the robot initially facing 0 degrees. The example graph above was the result publish com_vel messages with a linear x speed of 0.2 m/sec and an angular z speed of 0 radians/sec. They were generated by this command.
python motors_go_full.py 0.2 0.0
A second example below repeats with an angular velocity of 0.4 radians/sec. Notice that the 0 speed glitches reported by odom have disappeared. Is that because of the initial direction or angular component? Two additional tests will follow.
python motors_go_full.py 0.2 0.4
Tests starting at 40 degree heading
In the following example plots the robot is first rotated about 40 degrees and then brought to a stop to stabilize. com_vel messages are publish like the ones above. In the next example the robot goes straight after completing the rotation.
motors_turn_go.py 0.2 0.0
In the following example the robot does a turn after the rotation completes
motors_turn_go.py 0.2 0.2
Conclusion
The results indicate that odometry has more 0 speed glitches when it is going straight. I really don't know what to say.
Short Term Oscillations
One candidate for the short term oscillations that ride on top of the wheel speed line is the lack of encoder time precision. This has not been verified. What follows are some data points.
Odometry Publication Rate
Odometry is published 22 times a second. See the frequency definition in line 407 of odometry.cpp.
Wheel Speed Publication
The motor controller publishes wheel speed and power values whenever it receives a odometry publication. The Example Graph above
- Displays 22 points every second.
- Displays 7 dips every second. (Roughly 1/3 have speed values significantly lower than average.
Encoder Publications
There are roughly 125 encoder messages published each second by each encoder like the two below. The rate of 125 corresponds to one roughly every 8 milliseconds. See the time field. Measurement show that
- 102 or about 80% have a time value of 8 ms
- 23 or about 20% have a time value of 7 ms
- 80% have a count_change value of 32.
- 20% have a count_change value of 33.
- Inspection indicates that 7 ms times are near messages with a count_change of 52. This needs to be verified.
---
header:
seq: 2171
stamp:
secs: 0
nsecs: 0
frame_id:
index: 0
count: -64455
count_change: -33
time: 7
---
header:
seq: 2172
stamp:
secs: 0
nsecs: 0
frame_id:
index: 0
count: -64488
count_change: -33
time: 8
---
Example rostopic commands used:
rostopic echo /phidgets/encoder/351547 rostopic echo /phidgets/encoder/351547/time rostopic echo /phidgets/encoder/351547/count_change rostopic echo /odom
Observations based on above
- There are roughly 23 encoder 7 ms time reading per second. Odometry is published roughly 22 times a second. I don't know if this is meaningful.
- The speed dips are roughly 7 times a second. This doesn't appear to correlate with anything above.
- I am not pleased that the encoder time readings returned by the phidget encoder driver are imprecise. The impact is a 10 to 15% error in time interval reading from the encoder. This precision is determined by the core Phidgets drivers written by Phidgets or by their hardware.
Conclusions
I can't deduce anything meaningful about the cause of the speed oscillations.
Overall Conclusion
I don't see a simple resolution to these glitches. Digging into the core Pidgets driver and debugging the Encoder and Odometry ROS code does not look time effective. I'm going to live with it for now.
