Differential drive encoder interpretation

Question

I'm trying to use the differential_drive package to convert my encoder counts to odometry messages, but the docs are a little ambiguous.

My encoders are non-quadrature, so I can either provide an absolute pulse count, which will only increment, or take into account the active motor speed and provide a relative count, which may increment or decrement depending on motor direction. However, the package's docs just say:

The hardware is expected to count pulses from the wheel encoders, and provide the total number of pulses since the start of tracking.

Does this mean it expects an absolute pulse count or a relative pulse count? The phrasing makes me think the former, but since the package calculates odometry, I don't see how it could do that without knowing the direction that the pulses imply.

---

Originally posted by Cerin on ROS Answers with karma: 940 on 2016-09-20

Post score: 0

Answer 1

I've used the differential_drive package as you suggest. It wants absolute counts reported by the robot controller, not relative. I assume you're planning to run your motors only forward. I've successfully used non-quadrature encoding while running the motors both directions, but it requires coasting to a stop, waiting, updating some state variable, then reversing direction. The total encoder count can be incremented or decremented, depending on the direction state variable.

However, I've never tried to do bidirectional movement without quadrature encoding while using ROS. If you use the ROS navigation stack, you necessarily relinquish some low-level control of the motors to gain the benefit of the global and local planners. Both the planners assume the motors can move either direction.

---

Originally posted by Mark Rose with karma: 1563 on 2016-09-21

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by Cerin on 2016-09-21:
Why do you say I'll only run my motors forwards? I plan on going both forwards and backwards. I think I've miscommunicated. By "absolute count" I mean the count never decrements. It literally counts encoder pulses, which can never decrement since there's no such thing as a "negative" encoder pulse.

Comment by Cerin on 2016-09-21:
My question is about what kind of count the differential_drive package expects. If I reverse my motors, does differential_drive expect the encoder count to decrement?

Comment by Mark Rose on 2016-09-21:
Yes. As I said, differential_drive expects an absolute encoder count, incrementing when driving forward, decrementing when driving backward. I assumed you would only drive forward because of the problems inherent in a single-tick encoder. You can drive both directions, but it's tricky.

Comment by Mark Rose on 2016-09-21:
You will probably have to write your own local planner if you want to use the navigation stack, because the default local planners assume that the odometry will work properly even when reversing motor direction. A single-tick setup might might lose counts because of inertia in the system.