
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.