Robotics

These are my notes (in progress) on adapting a HEXBUG Spider robot into a mobile platform for my computer vision project.

The Measurement Computing 1024LS powers up into a state where the IO lines are inputs. These inputs are pulled up to +5 V. This causes the HEXBUG robot to immediately start moving. The 1024LS has a three 0 Ohm surface mount resistors that switch between the inputs being pulled up to +5 V or down to 0 V. Here are the two for banks A and B:

The PCB under each resistor has three pads. By default, the resistors are spanning the “H” side. By switching this to the “L” side, the outputs will pull the outputs down to 0 V on start up. Now the robot waits patiently for me to get my control software up and running.

To make my HEXBUG Spider computer controlled, I could have duplicated the IR transmitter but there is the issue of battery lifetime and the issue of the circuit on the HEXBUG timing out and requiring a manual flip of the bot’s power switch.

I opted to replace the IR receiver in the HEXBUG and wire that directly to a series of TTL outputs from my computer. In essence, I removed the robot’s brain (can you say: “Robot Zombie”?). Opening up the robot showed that it is controlled via two small motors. One motor controls the robot’s head rotation and, consequently, the direction the robot walks. The second motor controls the leg motion. A small circuit board runs the whole thing:

On one side of the board is a two channel driver chip that takes an enable and direction signal for each channel.

The enable applies a potential to the motor and the direction specifies the polarity of the potential. The other side of the board has the IR receiver:

I removed the IR receiver and wired lines straight to the exposed pads as well as +5 V and Gnd wires to where the battery was hooked up:

The fine wires were taken from a flexible USB cable I had lying around. I then closed up the HEXBUG and hooked it up the Measurement Computing 1024LS digital IO controller including the 5 V supply and ground.

Worked great, though the robot does have an umbilical now that drags when the robot moves. Given that I also attached a USB camera to the head, the umbilical is the least of the cables being dragged by this robot.

To be able to computer control my robot, I purchased a Measurement Computing 1024LS 24 channel TTL IO board that runs off of USB. There are third party drivers for Linux. The instructions on installing the drivers are good, but I did have to play around to get them to install on my Ubuntu 11.04 machine.

Plugging the 1024LS into the USB and running lsusb gives me a series of entries including:

The 09db is the vendor ID and 0076 is the product id. We will need this later.

Started by installing the libusb-dev package:

Then downloaded libhid-0.2.16.tar.gz from libhid.alioth.debian.org and
extracted it. Configured and made the package:

The tests provided with the package did not seem to be able to find the 1024LS (results are buried in a lot of stderr trace output). However, that is likely due to incorrect permissions at the time with the usb port (see below).

Downloaded the 3-rd party driver package MCCLIBHID.1.48.tgz from ftp://lx10.tx.ncsu.edu/pub/Linux/drivers/USB/
Unpackage MCCLIBHID:

The test routine failed with errors like:

The issue is that we need to allow access to the USB connection. Took the single line from ftp://lx10.tx.ncsu.edu/pub/Linux/drivers/USB/60-mcc.rules
which matched the vendor/product id of the 1024LS (which we found with ‘lsusb’) and created a file mcc.rules via echo:

The MMCLIBHID README says to use:

or

The latter worked on my system

Needed to unplug and replug the device before the test worked:

and was able to blink the device LED (command ‘b’).

Then in the libhid-*/test folder:

returns a ton of TRACE info to the stderr, but in the middle is some stdout text:

For some reason test_libhid still fails.