ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Integer overflow in differential_drive wheel encoders?

asked 2016-01-14 09:35:12 -0600

lalten gravatar image

updated 2016-01-14 09:35:35 -0600


I'm reading a sensored brushless motor's tri-phase hall encoders in an effort to get odometry on my robot.

I get six increments for one motor turn. The motor runs at something like 17000rpm at max speed. If I track the encoders with an std_msgs/Int16 message, as expected from the differential_drive package, I will get an integer overflow after only about 300 ms...

I'll be using rosserial_arduino on an Arduino Micro with interrupt driven software.

Is there an alternative package I could use? Maybe something that tracks the relative change of the encoder counter instead of its absolute value?


edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2016-01-15 03:40:34 -0600

Akif gravatar image

In the package wiki it says;

wheel_low_wrap (int, default: 0.3 * (encoder_max - encoder_min) + encoder_min

wheel_high_wrap (int, default: 0.7 * (encoder_max - encoder_min) + encoder_min

If a reading is greater than wheel_high_wrap and the next reading is less than wheel_low_wrap, then the reading has wrapped around in the positive direction, and the odometry will be calculated appropriately. The same concept applies for the negative direction.

Therefore it seems like it can handle wrap around.

edit flag offensive delete link more

answered 2016-01-14 15:57:24 -0600

ahendrix gravatar image

Most encoders are incremental, and the software that reads them expects them to wrap around. I'm not deeply familiar with the differential_drive package, but it should handle the wraparound correctly.

That said, having that wraparound happen every 300mS is a little extreme; if the ROS system is running very slowly, there's some potential for it missing the wraparound event. If you track your encoders with a larger type ( int32_t ) on the arduino and then divide that by something like 10 or 20 before converting to an Int16 and publishing, you increase the time between overflows in your Int16 to a more reasonable value of 3 to 6 seconds.

edit flag offensive delete link more


I looked at differential_drive's source and it does seem to handle the wraps. However, there's another problem: It's an Ackermann-style vehicle, so I have only one motor encoder. I plan on combining it with IMU orientation (or steering-servo set-value). So I will need to write my own node anyways.

lalten gravatar image lalten  ( 2016-01-14 16:24:48 -0600 )edit

Question Tools

1 follower


Asked: 2016-01-14 09:35:12 -0600

Seen: 1,272 times

Last updated: Jan 15 '16