It can be viewed here: https://github.com/rbtying/Companion-Cube

Download here:

Robot Controller
Source code is released into the public domain, but if you use it, I’d appreciate it if you cite me somewhere (Robert Ying).

You’ll also need to have the appropriate rxtx native library in the same folder as the jar file when running it—you can download that here

Corresponding Arduino Code:

void setup() {
  Serial.begin(115200);
}

// method that sets motor speeds from -255 to 255
// corresponding to full reverse and full forward
void setLeftMotor(int speed);
void setRightMotor(int speed);

byte nextByte() {
  unsigned long start = millis();
  while (millis() - start < 100) {
    if (Serial.available()) {
      return Serial.read();
    }
  }
  return 0x00;
]

void loop() {
  while (Serial.available()) {
    switch(Serial.read()) {
      case 0xC1: setLeftMotor(2 * nextByte()); break;
      case 0xC2: setLeftMotor(-2 * nextByte()); break;
      case 0xC5: setRightMotor(2 * nextByte()); break;
      case 0xC6: setRightMotor(-2 * nextByte()); break;
      default: setLeftMotor(0); setRightMotor(0); break;
    }
  }
}

The Companion Cube—with new wheels!

I finished up the wheel replacement today with a pair of Vex Omniwheels, which have little rollers on them to allow movement perpendicular to the way they’re mounted, thus resolving the previous shearing force problems.

An Omniwheel

Unfortunately, since my motor shafts are 6mm single-flat and the Vex wheels are designed for 0.125″ square, I had to drill the wheels out a bit to make it work. Lacking a drill press, I made do with a slightly smaller drill bit, a hand drill, and a rotary tool, adding in a few screws to adjust the fit and to lock the wheel against the single flat. Although there were some mistakes, I think it turned out rather well:

Closeup of the left side of the robot

Closeup of the right side of the robot

The larger wheels get over bumps more easily, and they make it faster, both to turn and to drive—the omniwheels are especially helpful while turning, as they allow me to treat the system as a two-wheel system at the back instead of a four-wheel system like it actually is.

Got some new rear drive wheels, but I'm still waiting on the omniwheels for the front.

I’ve also got a (really short) video from before I started the wheel switch:

A short (and incomplete) list of changes:

1. Switch from old laptop motherboard to an Artigo pico-itx computer
2. Move the Kinect down—empirical data shows that it does not need to be placed very high to get useful readings
3. Elevate the base (by using bigger wheels): I’ve had troubles getting over bumps due to low ground clearance
4. Change microcontrollers from an ATMega328P to a ATMega2560
5. Add an LCD for quick feedback on important things like battery voltage and motor speed

Source code is available for download—there’s a Git repository at tpmo.im/robot.git.

git clone git://tpmo.im/robot.git

Alternatively, browse the repository over the internet here

Pictures:

Replaced the computer and moved the kinect. It's a lot smaller now!

Added a LCD for status feedback

Closeup on the LCD

And a short video:

After some thinking, I decided to solve the problem via udev mounting (somewhat hackish). In Linux, udev controls the mounting of various hardware peripherals to mountpoints in the file system. This tutorial is written for Ubuntu 10.10, but could easily be translated to any distribution of Linux (and probably Mac OS X, as well).

Step 1: Plug in your FTDI device (this will be an FTDI breakout of some sort, or perhaps an Arduino Duemilanove or older)

Step 2: Find its current mountpoint: Ubuntu mounts FTDI devices to /dev/ttyUSB*, where * is a number.
In the terminal, type this:

ls /dev/ttyUSB*

Output:

$ ls /dev/ttyUSB*
/dev/ttyUSB0
/dev/ttyUSB1

I’m going to assume that we’re working with /dev/ttyUSB0 for the rest of this post.

Step 3: Find the udev properties that are unique to each FTDI device.
In the terminal, type this:

$ udevadm info -a -p $(udevadm info -q path -n ttyUSB0) | egrep -i "ATTRS{serial}|ATTRS{idVendor}|ATTRS{idProduct}" -m 3

I recognize that the regex used in the egrep isn’t the most concise, but it works (anyone want to suggest something better?).
The output will look something like this:

$ udevadm info -a -p $(udevadm info -q path -n ttyUSB0) | egrep -i "ATTRS{serial}|ATTRS{idVendor}|ATTRS{idProduct}" -m 3
ATTRS{idVendor}=="0403"
ATTRS{idProduct}=="6001"
ATTRS{serial}=="A700eEPB"


Record all the values in the quotes – you’ll need them in the next steps.

Step 4: Create the udev file.
In the terminal, create a file named 10-ftdi.rules in /etc/udev/rules.d with 644 permissions.
$ sudo touch /etc/udev/rules.d/10-ftdi.rules && sudo chmod 644 /etc/udev/rules.d/10-ftdi.rules
Open the file with your favorite text editor:

$ sudo vim /etc/udev/rules.d/10-ftdi.rules

and copy this line in:

BUS=="usb", SYSFS{idProduct}=="IDPRODUCT", SYSFS{idVendor}=="IDVENDOR", SYSFS{serial}=="SERIAL", NAME="DEVICENAME"

Substitute your values from Step 3 for IDPRODUCT, IDVENDOR, and SERIAL. DEVICENAME will be your new mountpoint.
Save and close the file.

Step 5: Remove your FTDI cable and plug it back in (this will remount it using your new rule). It should now be mounted in /dev/DEVICENAME, where DEVICENAME is what you put in the NAME field in the udev rule.

Step 6: Repeat this process for your other FTDI devices. Consecutive udev rules can be placed on the next line in the same file – no need to create another one.

This quick and easy trick lets you assign memorable mountpoints to otherwise identical devices – a godsend when you’ve got a few too many to work with.

We stayed at the Sheraton Hotel in the Inner Harbor, just a block away from the Baltimore Convention Center where the actual competition was held. Since we had to fly in, we didn’t have much in the ways of transportation – most of the time, we just walked to where we needed to go. Unfortunately, we never did get a chance to try Baltimore’s famous crab, so maybe next time.

In terms of the competition itself, we managed to make it into the quarter-finals, eventually losing to the first-seed alliance (this was mostly because our alliance had two useless robots (teams unnamed) and us), leaving us to score almost all of the points in the round. Although our position was uneviable, we felt we acquitted ourselves well.

As something of a surprise, we did get the Engineering Inspiration Award, the second most prestigious award given at a regional competition. With it, we qualify for the World Championships in St. Louis – an accomplishment that we didn’t really expect from our travel tournament.