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

1024LS Power-on State

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.

HEXBUG Spider Zombification

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.

Measurement Computing 1024LS

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:

Bus 001 Device 007: ID 09db:0076 Measurement Computing Corp. PMD-1024

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

Started by installing the libusb-dev package:

sudo apt-get install libusb-dev

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

sudo make install

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
Unpackage MCCLIBHID:

sudo make install
sudo ldconfig

The test routine failed with errors like:

hid_force_open failed with return code 12
hid_force_open failed with return code 7

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

echo ‘SUBSYSTEM==”usb”, ATTR{idVendor}==”09db”, ATTR{idProduct}==”0076″, MODE=”0666″‘ > mcc.rules

The MMCLIBHID README says to use:

/sbin/udevcontrol –reload_rules


/sbin/udevadm control –reload-rules

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:

device identification of HIDInterface 001/010[0]:
dev_handle: 0x009a3ea0
device: 0x0099f870
location: 001/010
manufacturer: MCC
product: USB-1024LS
serial number: 017328D9

For some reason test_libhid still fails.