My part in Max's master plan, as discussed below, will be to help him implement his ultrasonic distance ranging sensors. Max wrote about these in his blog, A Sensor for All Seasons. Since that time, we've been bouncing ideas back and forth with regard to connecting the sensors to his Arduino.

To refresh your memory, Max wants to load up on ultrasonic rangefinders as one technique to maintain good situational analysis. The sensors Max picked -- the SRF04 type (sometimes shown without the F as SR04) -- are "cheap-and cheerful" and can be obtained for only a few dollars (the price on Amazon goes up and down like a yo-yo, but you can usually obtain these sensors for less than $3 apiece).

Of course, you get what you pay for. The reason SRF04s are so cheap is that they don't have an onboard MCU; instead, they rely on the host MCU for all of their control and processing. The host MCU has to trigger an ultrasonic "ping," then time the delay between the ping and the return echo, and then use this delay to calculate the distance between the sensor and the object it's detected. The host MCU has to do this for each ultrasonic sensor, as well as managing all other aspects of the robot.

This works reasonably well for a small number of sensors, and most robots would typically only have one or two such sensors mounted on the front. The thing is that Max's three-wheeled robot platform can scoot around in any direction, which means it has no "front." This explains why he wants to have multiple sensors mounted around the periphery of his platform. The problem here is that when you start to add more and more sensors, the host MCU can very quickly use up all of its processing power servicing the sensors. When that happens, there's nothing left over for any other "robotic things." Thus, my mission was to offload the ranging burden without incurring too much cost.

For my own robot project, I've been experimenting with a related model of ultrasonic sensor, the SRF08. The '08 has an onboard PIC MCU to deal with the timing and the conversion of time into distance. It communicates over I2C in a "fire-and-forget" mode. An I2C command from the host MCU will instruct the sensor to initiate the ping, after which the host MCU can go about its business without the need to watch and wait for the echo return. Another I2C command sometime later will retrieve the distance measurement from the sensor. Here is a front view of one of my original '08 modules:

The two "cans" are the ultrasonic transmitter and receiver. The small part, between the two, near the top, is a CdS light-controlled resistor. The on-board MCU and a bunch of other bits and pieces are found on the backside of the module as illustrated below:

The downside is that the '08 is considerably more expensive than the '04. When Max and I looked recently, the best price we could find was around $55 for each '08 module. Since Max is talking about having nine ultrasonic sensors on his robot, this could quickly become a very expensive hobby.

Fortunately (certainly for Max), my own robot project will be able to help here. I plan to use an FPGA to talk to a large number of sensors simultaneously. In order to make this possible, I need each of my sensors to have a small on-board MCU and to communicate over I2C. Key to this concept is the availability of an inexpensive sensor-to-I2C board. Since I couldnít find anything commercially available that satisfied my requirements, I whipped up my own board. Conveniently, this little board will be perfect for Max to use with his '04s. In fact, the image below shows an '04 (on the left) plugged into one of my boards:

There's nothing at all complex about my board -- its main feature is a small PIC12F1840 MCU and some connectors. For the purposes of these discussions, imagine my board in the above image to be rotated 90 degrees clockwise such that the 4/5 double row of holes (with the '04 plugged into the row for 4 holes) are at the top. The '04 uses a four-pin connector, while the slightly more sophisticated SRF05 uses a five-pin connector, hence the 4/5 double row of holes at the top of my board.

If we keep on visualizing my board in the image above as being rotated 90 degrees clockwise, then the six pins on the right are for programming. Meanwhile, the connector on the left can be I2C or SPI. The three-pin connector in the middle of the board (just under the 4/5 double row of holes) is designed to accept an analog IR ranging sensor (but not at the same time as an '04 or '05, of course).

Finally, the five-pin connector at the bottom of the board is the I2C interface to the host MCU. The clever thing is that this is presented with exactly the same pin-out as an SRF08 (the LED, just right of the MCU, is connected to the trigger line). The idea is that, in its default configuration, my board -- which costs only around $3 fully populated -- can be used to make a $3 '04 or '05 sensor behave just like a $55 '08 module.

When I proudly presented the above image to Max, his immediate response was "That looks very nice, but where are the mounting holes?" Welcome to Revision 1.1:

First, this new version has mounting holes (never design a board for Max without mounting holes). Also, it has two more LEDs (as a general rule of thumb, you canít have too many LEDs on a board intended for Max). In addition to the trigger indicator, we now have an LED on the echo line and a power-on indicator LED on the back side of the board. (The echo LED has a jumper inline so it can be disabled when using the analog input.)

By the time I'm finished with this and Max is happily roboting away, maybe I'll have the FPGA on my own robot ready to accept a dozen of these little boards.

Max, I would love to understand how you are going to implement depth perception with the two Pixy Machines! That should be a cool programming project, I am wondering what vision libraries were you planning on using? The attraction to the Kinect is the built in horsepower/processing for the depth reporting. Sounds like a fun project for sure.

@Robotics Developer: ...the areas of software, vision, mechanical and systems for robot designs keep me occupied learning and exploring new areas, a wonderful thing for an engineer at heart!

I agree -- one of the reasons for having hobby projects is that it's a great way to learn "stuff" -- for example, working on my my Inamorata Prognostication Engine is affording me the opertunity to learn all sorts of things, like how to calculate the dates of Full Moons and Blue Moons :-)

Max, consider (if you have the bandwidth and processing power) adding a Kinect to the robot. It has nice sensor features (depth being one of the really nice ones) as well as vision. Adding that to the platfrom could provide you with years of experimentation and exploration (pun intended).

You are most welcome! Any help that I can provide please contact me! Robotics encompasses a diverse mix of disciplines and as such it provides an endless opportunity to learn and grow. As a EE by degree the areas of software, vision, mechanical and systems for robot designs keep me occupied learning and exploring new areas, a wonderful thing for an engineer at heart!