Wheel Encoders

In order to estimate position and orientation using dead reckoning, you have to measure the rotation of your wheels (or the motor shaft or gear driving the wheels).   This means using some sort of shaft or wheel encoder.  The RP5 has a gear that rotates 4x for every wheel rotation, and a hole in it which they indicate can be used to count gear rotations using some sort of optical (infrared) encoder.

One can get much more precision by using more holes/slots or more markings, as discussed in this thread on homemade encoders.  Also, having two offset sets of marks allows one to do quadrature encoding and determine the direction of travel as well. For my first robot, I’m just using a rough encoder, with 4 counts per wheel revolution.

In looking in the chassis, there’s not a lot of room. As a result, I decided I’d use a small transmissive sensor, rather than a reflective sensor.  Both have an IR emitter and an IR photo detector.  For reflective units, they both face the same direction, and the detector measure IR reflected back to the sensor.  For a transmissive or interrupt sensor, the two units are separated by a gap, and the detector picks up IR passing through the gap. So far, so good.

I ended up using Vishay transmissive optical sensors (model TCST1202) I purchased from DigiKey.  I found a ciruch  and wiring them up based on the circuit posted by Aniss1001 in the “Homemade wheel encoder”  thread on the Arduino forum.

encoder circuit diagram

Encoder circuit diagram - for a different encoder, but it worked fine

I built the circuit on a prototyping breadboard for testing and got a surprise.  The circuit worked fine, but the gear is transparent to IR!  It turns out that nylon and most plastics used for inexpensive gears are pretty transparent to IR.  I first tried creating an opaque section with a black marker, but while that worked on paper, it didn’t adhere well enough to the gear.  I ended up using a piece of black tape.  Once that worked, I cut some small circuit boards down to size and built the encoders, practicing my soldering skills.

I just used hot glue to mount the encoders.  The encoder boards stick up above the chassis base, so I’m using standoffs to raise the plastic plate with the Romeo controller and other devices.  Here’s a picture of one of the encoders before mounting,, and then mounted on the chassis:

Homemade wheel encoder

Homemade wheel encoder

Mounted encoder

UPDATE: If you don’t want to build your own, I just discovered these pre-built transmissive encoder boards.

A note on C, C++, and Arduino programming

I see a lot of questions on the Web about how Arduino code relates to C and/or C++.  In a nutshell,  Arduino code IS basically C/C++ code.  Arduino uses a set of standard libraries to hide some of the functionality behind the curtain, making things easier for the newcomer to get started in the hobby.  For example, rather than setting specific bits on a “Port” to identify a pin as an output, coding something like DDRC.1 = 1;   after looking up which “port register” and which bit in the register controls the pin you want, you simply can code something like:  pinMode(8, OUTPUT);

This can also save time and effort for more experienced developers as well.  Arduino is not just for newbies.  There are tradeoffs, however.  For example, using the Arduino library to set pin modes takes longer, in terms of CPU processing time, than setting them more directly.  BUT, because Arduino basically IS C, you can often (but not always) just drop in the direct code you need, and still use the Arduino libraries for the rest.  And if you someday want to go straight to AVR C programming, skipping the Arduino IDE’s and libraries entirely, there are ways of doing that to with your Arduino board.

You may have noticed that I said Arduino is basically C/C++.  Well, which is it?  Aren’t they two different, if related languages?  Yes, they are.   C++ is mostly a superset of C, adding object oriented programming concepts.  C++ started as “C with classes”   but C is no longer completely a proper subset of C++, as the two languages evolved a bit differently over time.  These days, languages usually have both the core language itself and a set of standard libraries.  These libraries have already coded frequently used routines in an efficient manner,  so you don’t have to keep reinventing the wheel.  As I understand it, Arduinos support C++ core language features and the common C libraries, such as math.h, but NOT the standard C++ libraries.  So while you can use objects and other core C++ language features, you can’t draw from the C++ library.  At least this is my understanding.  Please let me know if I’ve gotten something wrong.

Initial musings on robotic vehicles

I finally started working on my first robotic vehicle about 2 months ago.  It’s built around the RP5 tracked chassis and the Romeo controller board, both from DFRobot.  I chose the RP5 because it’s low-cost, the tracks make it a bit more capable for traveling over small objects, and it was fully assembled.  I chose the Romeo because it’s an Arduino-compatible board with support for driving the motors built in (no need for a motor controller board) and lots of convenient 3-pin headers (pwr, gnd, and signal) tied to the Arduino pins, making it really easy to connect sensors and other items.

My goal for the first robot is for it to run indoors, using dead reckoning to navigate (as best it can) to a series of pre-specified waypoints, while avoiding obstacles along the way.  I wanted to build capability in stages.  Here’s what I’ve found out so far:

  1. It is trivial to use available kit parts, like the RP5 and the Romeo, to quickly get up a vehicle that moves around, whether in a straight line, by moving and turning for preset time periods, or moving at random.
  2. It is surprisingly easy to add a sensor and instigate obstacle avoidance.
  3. It is 1-2 orders of magnitude harder to add position sensing and navigation.

Having said that, I’m well along the way to getting navigation working, it’s been fun, and given me the opportunity to learn or relearn a lot of basic C along the way (my previous C experience being limited to 1 course about 25 years ago).  I find it’s much easier to learn a technical subject if you’ve got a hands-on project you’re working on, and that even a simple robot touches on a lot of the basics of the C language.