For some very early incremental prototyping on the HAMMR project, I’ve pulled out an old Roomba motor that has a rotary encoder built in.

The purpose here was to begin some of the groundwork for the Arduino sketch that would read the encoder input and probably do some PID control. I used a L293D H-bridge chip and an Arduino UNO to get things going. The code can be found here.

I spent quite a lot of time trying to determine the pin out for the encoders. The ones I have are an IR emitter pair that are triggered when the IR light is broken. Most of the motors I found online where of the hall-effect sensor type and their pin outs did not match mine.

After some multimeter testing with trial and error, here’s what I came up with:

schematic for the roomba encoder. (the resistor on the right is 10k)

The inside of my roomba motor is pretty much exactly like the one on Robotgrrl’s write-up on the same topic. Its a belt (rubber band) driven gearbox. I didn’t need to go into the internal hub gearbox, I left it alone since all I’m interested in is the encoder. What’s nice about the encoder is that even if the belt slips, your feedback will still have your back.

inside the roomba motor.

After a bunch of testing to determine how many pulses per revolution there are, I determined that this geartrain coupled with the Arduino makes a very imprecise system. The ppr is not immediately obvious since the encoder wheel does not spin 1:1 with either the big wheel or the motor. Without a known gear ratio, it was required to gather some empirical data on the system. This was really hard since the Arduino can’t read very fast (even with interrupts) due to its own internal overhead (the Arduino environment itself).

The most accurate results I came up with was about 860ppr. As long as I commanded a small speed – about 11RPM – I was able to consistently get one exact rotation each time.

I ran into an odd problem when attempting to stall the motor during the feedback loop. If I were to forcibly stall the motor, the encoder ticks would pause for a moment, then spike a few times until the end of the routine. A electrical whining sound corresponded with this spiking. It seems by stalling the motors, I created an unsteady surge in the circuit which may have caused some funny readings to the encoder. I’m sure there are some isolation techniques I could follow to fix that problem.