Tuesday, October 21, 2008

A new video

As you can see in the following video, the eeePC now operates the robot. However, there are some issues. Since it's not nearly as powerful as the Macbook Pro, I had to reduce the resolution of the input image. This makes the line-finding less precise. Also, it's not yet tuned properly, so you can see it tends to overcorrect and constantly be "bouncing" off the sides of the course. You can see as it rounds the curve that the guidance picks up the left line of the course as the right line by accident, causing it to run between the two sides of the U-shaped course. Needs some work.

video

eeePC up and running

Lately I've been a bit busy, but there's been some progress. The eeePC now has full functionality and can operate the vehicle in place of the Macbook Pro. Here are some pics:

First, the eeePC with the screen shut on its new aluminium tray on the Stampede. Note the webcam between the two front springs. It's a USB2 Logitech Quickcam Deluxe for Notebooks. It's got a glass lens and no autofocus. (Autofocus can play havoc with vision software, as autofocus will change the image's focus without warning.)

This shot shows the eeePC with the screen open. This setup means that I can walk behind the robot and see what it's seeing: this is very useful for debugging the guidance. The grey USB cable goes to the microcontroller. The black USB cable goes to the camera.

The chassis remains largely unchanged. The computer tray attaches to the four body posts that used to hold the lexan truck body on. It can be removed by taking out the four retaining clips. A piece of scrap lexan from a keyboard's packaging makes a small tray to hold the Arduino microcontroller (blue, on right side of vehicle) and the wire breakout board (green, left side of vehicle).

Tuesday, August 19, 2008

Ubuntu Install via external optical drive

If you have better luck than I, you may be able to install Ubuntu 8.04 from a USB stick. If you read my previous post, you'll know that I can't get that to work.

So here's what to do: beg, buy or borrow a USB2 DVD drive. (I went with "buy"). The helpful guy at the Future Shop sold me a LG 20X Super Multi External DVD Rewriter (GE20), which just happened to be the cheapest USB2-optical device available in my area of the city. He warned me that some computers' BIOS' support booting from USB2 drives and some don't. Given that the eeePC comes with a recovery DVD and support CD, I assumed that it was able to boot from an external optical drive. This turned out to be correct.

So, I booted from the Xubuntu 8.04 Live CD, and lo and behold, the eeePC boots! (It refuses to do so with almost all of the USB drives I tried to create.) Up comes the load screen, and then the Live session begins. I chose to install Xubuntu. I won't go into the details here, because the install failed. I think, in retrospect, this is because I chose to change the partition setup, but I did not click the little "format" checkboxes in the installer. Whatever the reason, the installer fails due to an unspecified I/O error at 53% into the install process (This happened twice in two attempts, at the identical point.)

So I tried booting from the Ubuntu 8.04 CD. The only difference here is that Ubuntu uses the Gnome desktop, and Xubuntu uses the XFCE lightweight desktop.

The Ubuntu live session booted, and I started the install. When asked how I wanted to partition the drive, I chose "manual". In its stock (Xandros) configuration, the drive has 4 partitions on the fast 4Gb motherboard-mounted hard disk and two on the slower 16Gb removable hard disk. The first thing is to select "new partition table" for each drive. For the 4Gb drive, I created one partition, in the ext2 format. The "mount point" is "/", to indicate that the root of the filesystem goes in that drive, with all the system files. Be sure to check the "format" checkbox to ensure that the drive is wiped before installing, as I think omitting that killed the Xubuntu installer. For the 16Gb drive, I made one partition, in ext3 format, mount point "/home", to indicate that the user's files will go on this drive. Again check the "format" checkbox. When you accept the configuration, it will warn you that you have not allocated any swap space. This can affect performance when you use a lot of RAM, but using the SSD drives for swap space can reduce their lifetime, as they have a finite number of writes before they die. I hope the system can function well without swap. We shall see. It also warns that this will wipe any files on the drives. I don't have anything of importance on my machine, but if you do, then don't hit that button until you copy your files somewhere safe.

The rest of the installation went fine. I was worried that Gnome would be too resource-intensive for the eeePC but it runs well, even with some of the graphical effects turned on. I will detail the setup later once I have it working, but suffice to say that within an hour of installing Ubuntu, I had working Wifi, Ethernet, custom keys on the keyboard, installed build-essential, got the camera working, and installed subversion and GTK.

Now that Ubuntu is installed and configured, it's like night and day. I will never go back to the default Xandros OS.

USB-Install hell

So, the consensus among my Linux-savvy friends regarding getting GTK, gcc, glut and opencv working on the eeePC was a resounding "GET RID OF XANDROS!". The rest of the robotics club uses Ubuntu or the lightweight derivative Xubuntu. People have reported various levels of success on eeeUser regarding Ubuntu installs, so I decided to give it a shot.

It was at this point I discovered that I have some sort of curse regarding bootable USB drives. I tried creating bootable Xubuntu, Ubuntu, Kubuntu (all 8.04), and eeeXubuntu (7.??) USB drives to install some favour of Ubuntu on my eeePC.

Here's a list of tutorials that I tried in turn:

First, I made an eeeXubuntu USB install using this tutorial: http://wiki.eeeuser.com/ubuntu:eeexubuntu:home

The tutorial and script work quite well, and I created an eeeXubuntu USB drive which boots on my eeePC. Great, right? Well no. Discussion on the eeeUser forum indicates that eeeXubuntu doesn't work so well on the eee PC 901, the model I have. Apparently it's better to install the vanilla version of the newer 8.04 version of Ubuntu or its derivatives Kubuntu or Xubuntu. Alright. I'll do that:

------------------------------------------------------------

So next I tried these:

http://www.pendrivelinux.com/2008/05/21/usb-xubuntu-804-persistent-install-from-live-cd/
http://www.pendrivelinux.com/2008/05/15/usb-kubuntu-804-persistent-install-via-the-live-cd/
http://www.pendrivelinux.com/2008/05/08/usb-ubuntu-804-persistent-install-via-the-live-cd/

All three of these failed with the same fdisk error: "WARNING: re-reading the partition table failed with error: 22. Invalid Argument."

Also, if you can get past this, the tutorials require downloading syslinux during the Live session, and of course, neither ethernet nor wifi worked during the Live session on any of the three computers I used to attempt this.

------------------------------------------------------------

A helpful person on the eeeUser forum suggested Unetbootin: http://unetbootin.sourceforge.net/

I tried this using a Windows machine, and the process went smoothly. However, the eeePC refused to boot from the USB drive, though my MacBook Pro and a PC tower both would.

------------------------------------------------------------

Next I tried this:
http://www.pendrivelinux.com/2008/04/09/usb-ubuntu-804-installation-from-windows/

This created a working Ubuntu installation as well, but again, the eee PC 901 refused to boot from it.

------------------------------------------------------------

At this point I was just really pissed off and about ready to hurl the Live CDs, USB keys and the rest out the window. I'd probably spent about 12 hours trying to make these various USB installs at this point.

The solution? Get an external USB2 DVD drive.

Sunday, August 17, 2008

GTK woes

The OpenCV library provides image capture, processing, and a display GUI for vision programs. It forms the foundation of my guidance programs. It relies on the GTK interface library for image capture and the GUI elements. The GTK binaries are functional on the eeePC, but the development files necessary to compile GTK support into OpenCV are missing. All attempts to install them (from the libgtk2.0-dev package or others) have failed. I think the writing is on the wall for the built-in Xandros OS. I'm going to try to install eeeXubuntu, the modified Ubuntu distro that's configured for the eeePC. We'll see how that goes. I'm going to try to preserve the restore partition so that I can bring back the Xandros if necessary.

Sunday, August 10, 2008

Arduino setup on Linux

The Arduino site has eeePC-specific instructions for setting up the Arduino environment. It turns out to be as simple as installing a few packages and then uncompressing the Linux Arduino software. Just follow the links:

The Arduino Download page.
Arduino for Linux instructions.
Arduino for eeePC Xandros Linux instructions.

Note: while the instructions say to use the Debian repositories to get your packages, it is better to use the Xandros repositories. If you have not already, go back two entries in this blog to see how to set this up.

A pic for scale

Snowtires and the eeePC

So I pulled the laptop podium off the robot and I'm preparing to make a cradle for the eeePC. Above is a picture for scale. The Stampede's suspension takes the weight easily, unlike the Apple which compressed the springs all the way down.

Thursday, August 7, 2008

Setting up the eee PC

For the eee PC to function as the robot's computer, it needs several things:
  1. A fully-featured development tools set, including gcc, make and the standard libraries. These are not installed by default on the stock eee Xandros system.
  2. A regular Linux desktop, with the ability to easily control settings and active devices.
  3. A working install of OpenCV - the Open Computer Vision library, which forms the basis of all my vision code.
  4. The usual extra tools, like a decent text editor, image editor, and video codecs.
The default eee PC interface is a launcher-style tabbed menu. It has a terminal and a file browser, but it's not well-suited to development use. Fortunately, there's an "Advanced Mode" which is just a version of the KDE linux desktop. Instructions for installing and invoking his mode are on the eeeUser wiki: here. Use method #1, "the Easy Way". Do not use method #4. I tried that first and it prevented the system from booting up properly.

** EDIT: The following turned out to be BAD IDEA. Correction Below. ** [ To install the dev tools, follow the instructions on this blog. The short version is to add the main debian repository for the apt-get package manager. With that as a source, apt-get can download and install the package called build-essential, which contains compilers, linkers, debuggers, build tools, and all that good stuff.] ** End Bad Idea **

Installing Debian packages can cause all sorts of incompatibilities, so don't do the above. Instead, install Xandros packages onto your Xandros-based eeePC. What logic. Anyway, the right instructions are here. Once you've set up apt-get to pull software from the Xandros repositories, you can then use the console to run the following commands:

> sudo apt-get install build-essential
> sudo apt-get install pkg-config

This will install compilers such as gcc, build tools, and all the other stuff you need to write/compile software.

Now that you have gcc and all the rest, you can download the OpenCV source from its page on sourceforge. For me, OpenCV installed without a hitch. The final glitch is that any program that uses OpenCV needs to know where to find the OpenCV runtime libraries. The installer placed the libraries in /usr/local/lib/, so I added the line:

export LD_LIBRARY_PATH=/usr/local/lib

to the end of the file ".bash_profile" in th main user's home directory. This sets up the dynamic link path so that the shell can pass this on to the executable and it can find the libraries. Now your executables will run.

Wednesday, August 6, 2008

eee PC Arrives

It's here. The eee PC finally arrived. It's really cool, really small, and has amazing battery life (with its 6-cell battery). The built-in Xandros-Linux-derived interface is pretty slick, and the included software is cool, but I think a Xubuntu install will get the most out of this little beast. The small keyboard is going to take some getting used to, but my first impressions are good.

With regards to the robot, it remains to be seen how well thi machine stands up to the rigors of vision processing, but it can play back video smoothly and it handles the OpenGL Tux Racer game with aplomb, so I'm not too worried. The vision algorithms work just as well at 320x240 resolution as they do in 640x480, so if this machine can b 1/4 as fast as the Apple it should still work.

Saturday, August 2, 2008

Success


The robot works. It rolled around under its own power for the first time. There is a huge amount of work yet to be done, but this proves to concept. I used my MacBook because the eee PC still hasn't arrived. It looks like Canada lost out when it came to getting part of the first wave of shipments. I had to take the rear shocks and springs out and replace them with solid links to take the weight. Hopefully the eee PC will arrive soon and halve the payload.

Here's a video of the robot following a path marked by green lines. It works fairly well, but it definitely makes errors, as witnessed at the end of the video. I don't have a wheel encoder working yet, so I have to adjust the throttle manually to keep the robot moving as the battery level drops.

video

This is a good moment to thank everyone who's helped me get this project going. Particularly everyone in the UBC Thunderbird Robotics Team, without whose help this project would never have even begun, much less gone anywhere.

Thursday, July 17, 2008

USB Communication part II

The Arduino can receive string signals from the computer, but the computer has to send them. I have searched high and low for a multi-platform API to connect to a USB device and send strings to it in C++. No luck. Under windows there's CSerial, and Linux has libUSB, but instructions on how to use them are sparse, particularly on Unix/Linux.
So I turned to Python. Python is an interpreted language, useful for rapid prototyping software and scripting. It also has a brilliant USB communications library called pyserial. It also can be embedded in a C++ program. What follows is at best a hack. At worst it's a terrible kludge. Either way it works quite well. Python is installed by default on the Mac OS, so I didn't have to do anything beyond finding the right include directory. You can download it from python.org and pyserial from sourceforge. Using Python to send messages over the USB connection is impressively simple. The test code looks like this:

import serial
import time

ser = serial.Serial('/dev/tty.usbserial',9600)
time.sleep(2)
ser.write('Any message string you want.')
time.sleep(0.1)
ser.write('Another message string')
time.sleep(1.0)


The sleep commands ensure that the serial connection has time to start up (in the first case), and that it has time to transmit before the script ends (in the last case). In between, the connection buffers all the messages you send so the middle sleep isn't technically necessary.

Now I need to insert these commands into a C++ program. Fortunately, this is simple too. If you #include Python.h you gain access the the Python interpreter. I tried several different tutorials for using the various functions in Python.h, but the one that worked the best was the simple "PyRun_SimpleString(char* str);". With that, you can simply create your Python command in a char[] string in C++ and send it off. With that in mind I created the following wrapper class called serialBridge, which encapsulates the python commands including the setup and shutdown.

Here's the code:
serialBridge.h
serialBridge.cpp

And here's how to use it:

#include "iostream"

#include "Python.h"
#include "serialBridge.h"

using namespace std;

int main()
{
rSerial::serialBridge ser;
ser.setObserverStream(&cout);
ser.init("/dev/tty.usbserial",9600);
ser.delay(2.0);

for(int i = 0; i <>
{
ser.sendString("\"#");
ser.delay(1);
ser.sendString("\"~");
ser.delay(1);
}
return 0;
}

Friday, July 11, 2008

Ordered a computer


I just put in a preorder for an ASUS eee PC 901 at NCIX. They had the Windows-equipped versions sitting right there on the counter, but I decided to wait for the Linux version. Why? Two reasons. The first is that for the same price, the Linux version come with a 20Gb Solid-State hard disk, as compared the 12Gb SSD in the Windows version. This offsets the cost of the Windows license. The second reason is that if I did get the Windows version, I'm stuck with an OEM copy of Windows XP Home on the computer, with no install disks. So that means that putting Xubuntu or some other flavour of Linux on the machine means wiping out that windows install and possibly never getting it back. I'll wait a week or two for the better machine with the free OS, thanks. I don't know if the stock Xandros-based Linux flavour will be okay or whether I should wipe it and install another distro. Time will tell.

The specs look like this:
  • ASUS Eee PC 901.
  • Intel Atom 1.6 GHz Diamondville Processor.
  • 1 Gb of DDR2-533/667 RAM (planning an upgrade to 2Gb).
  • 20 Gb Solid-State Hard Disk (4Gb on motherboard plus 16Gb in removable SSD).
  • 8.9in 1024x600 LCD Display.
  • 802.11n (draft) wireless.
  • 1.3 Megapixel webcam.
  • Bluetooth onboard.
  • Xandros Linux preinstalled (Replace with Xubuntu?).
  • 6 Cell battery - they claim 4-8 hours of life. I'm skeptical, but hopeful.
  • 3 USB ports, an SD card reader, VGA-out and ethernet.
  • Final price: $617.59 CAN.
The only thing missing is firewire, and I'm sure I can find a decent USB camera, so I'm not worried.

Thursday, July 10, 2008

Vision Software


In order to guide the robot I need to process video data from a camera. Initially, the goal is to get the robot to travel down a course defined by two rows of orange cones. This is the basis of the Waterloo Robot Racing competition. A simple algorithm to guide the robot tries to detect two rows of cones as lines forming two sides of a triangle. By heading towards the center of the triangle we will (roughly) head down the course. Obviously, we'll have to handle cases where the robot can't see two distinct lines. This can happen when the robot isn't pointing down the course, or when the rows of cones don't resolve themselves into easily distinguished rows.

For now, I'm using OpenCV to capture frames from a camera. This is surprisingly easy to do with many USB or firewire cameras when you have drivers. OpenCV also provides the functions for the colour space conversion to HSV and the Hough transform line detection. The algorithm looks like this:

  1. Capture a frame from the camera
  2. Convert the image to the HSV (hue, saturation, value) colour space. The hue channel tells us the colour of the pixel as an angle in a colour wheel. The saturation channel tells us how strong the colour is.
  3. Create a binary image where a pixel is zero unless the corresponding image pixel has a hue angle near to orange and a high saturation.
  4. Use a Hough Transform to detect lines in the binary image. The Hough Transform works by comparing many candidate lines to the image, and letting pixels "vote" for any line they lie upon. It returns the lines that have large numbers of votes.
  5. Group the lines into those with positive vs. negative slope. Compute an average for each group of lines.
  6. The triangle is formed by these two average lines. The bottom of the image provides the third line. Compare the center of the triangle to the vertical centerline of the image to get a value for the robot's steering.

Wednesday, June 25, 2008

Spur Gear Wobble

The gears have been making a lot of noise, and it looks like it's because the spur gear is wobbling. (The spur gear is the large black plastic gear that receives power from the metal pinion gear on the motor.) Here's a video of the gear wobbling:

video

The strange thing is that both this and the replacement spur gear wobble in the same way. So I thought it might be the transmission top shaft. With the spur gear off, you can see that the top shaft doesn't wobble.

video

So I'm not sure what's wrong: it might be the slipper clutch assembly that lies inside the spur gear: if it's not square, then the spur gear which attaches to it would also wobble. I hope it's not the clutch: it's expensive.

Tuesday, June 24, 2008

Addendum - Pin # change on the Arduino

If you're actually using the code, you may have noticed that I changed the signal pin numbers (t_chassis.h). They were originally 12 (steering) and 13 (drive). However, pin 13 also connects to the Arduino's onboard LED, so I'd prefer to leave that one unused, or connect it to an LED on the outside of the robot for debugging purposes. Thus, I have changed the signal pins to pins # 11(steering) and #12(drive). I had to make a new adapter board to accommodate this. The only difference is that the connector going to the Arduino has four pins instead of three, plugging into digital pins GND, 13, 12 and 11. Pin 13 is currently not connected to anything. Aide from the pin # changes, everything else is the same.

Thursday, June 19, 2008

USB Communication

Now that the Arduino can control the mechanics, I need to get the Arduino to accept input via the USB connection. The Arduino already has serial communication libraries, so it's a matter of checking for a message from the computer, parsing it, and setting the chassis object.

Here's a new Arduino main program to replace the old one.
serialControl.cpp

I have no idea if there is an established protocol for this sort of thing: so far searching for any info on USB communication in C++ has been fruitless, so I'm making this up as I go along. I want the messages to be short to keep things fast and simple. Since the USB connection works as a sequence of bytes, it's easiest to parse the input as characters. I'm going to use two bytes as a message, the first byte will be the header, and currently that'll only involve two values: one for steering, and one for throttle. The second byte will be the value. It would be possible to do this all with one byte, but with two bytes I get a larger range of possible values, and some flexibility if I want to add additional message types, as there are plenty more possible header values. For ease of testing and debugging, I'm only going to use characters that are represented on a qwerty keyboard. That way I can type messages directly into the Arduino compiler's Serial input to test the system.
Looking at an ASCII table, the lowest value that is not a special character is the spacebar: #32. The highest is #126, the tilde ~. I'm going to reserve the space as a sort of "Null" message - unused whitespace. So, the throttle header will be #33 , the ! character, and the steering header will be #34, the " character. The data will range from #35 to #126. For example:

!# = full reverse
!Q = zero throttle
!~ = full throttle

"# = maximum left turn
"Q = center steering
"~ = maximum right turn

Now I need to write a program for the computer to generate these messages.

Chassis Abstraction

Now that the servo works, it's time to create a class to represent the chassis servo and ESC in the microcontroller code. I want to create a "chassis" object, which can be commanded to set the steering and throttle somewhere between -100% and 100%. The chassis object will be calibrated and will translate the abstract percentage into the correct servo values. Here's the code:

t_chassis.h - header file describing the class
t_chassis.cpp - implementation file
util.h - a few macros and definitions

By including this in the Arduino program, and changing the constants in t_chassis.h to match the correct values for the servo minimum, center and maximum, and the corresponding values for the ESC.

An example Arduino program would look like this:

chassisTest.cpp

Here's a video of the program in action:

video

Monday, June 9, 2008

Choosing a computer

One of the remaining major choices to make is what computer to mount on this thing. There are many choices, but they boil down to three major categories:

  • Mini-ITX computers. These junior-sized motherboards, frequently used for in-car entertainment systems, are quite powerful, relatively cheap, and have lots of options in terms of ports (firewire, USB, serial, ethernet, wireless, bluetooth, PCI-E, etc. However, using one would require an additional battery-powered power supply and dedicated batteries. The other major downside is that I'd need to carry around a monitor, keyboard, and mouse just to be able to do any kinds of programming in the field. This option probably offers the best performance and flexibility, but at the cost of convenience.
  • Mini-laptops. There is a flood of these laptops coming onto the market right now. Priced under $1000 and weighing 3 lbs or less, they seem to be a pretty good choice. The best ones (which have yet to actually hit the market as of this writing) are powered by Intel's new Atom processor (the Diamondville variant being teh most desirable right now). They all have USB, but none have firewire. They all package a VIA C7 or Intel Atom processor, 1-2 Gb of RAM, a screen, keyboard and trackpad, and of course, built-in batteries. The main downside is that it's all locked up in a tidy package that inevitably will be mounted quite high on the robot's body, so some work will be involved to keep all that payload stable.
  • Smaller-scale hardware. There are various options such as Pico-ITX scale motherboards and Gumstix: tiny computers on a board. They have similar disadvantages to the mini-ITX board, with the additional performance hits inherent to miniaturization. Their low power draw means that they could probably be run off the chassis batteries.

Overall, since this will be a development platform, I think I'll go with a Mini-laptop, either the Asus 901, the MSI wind, or the ECS G10-IL. The advantages of the all-in-one nature of a laptop are worth the loss of flexibility. Later robots can use the mini/picoITX boards if necessary.

Here's a comparison table.

Wednesday, May 28, 2008

Servo Wiring

Connecting the Arduino board to the forward servo and the ESC requires an adapter board. Marcel and Ash from the robotics team sketched out the wiring and soldered it for me, as that's a skill I've yet to pick up. Here's a pic:

Arduino and the adapter board.

Sometimes I'll refer to the ESC as a servo, as that's how it needs to be treated electronically. The adapter serves three purposes:
  1. Connects the signal wires from each servo to digital output pins on the Arduino.
  2. Connects the Arduino's ground pin to both servo ground wires. The ground must be common, or none of the signalling will work.
  3. Connects the steering servo's 6V supply to the ESC's 6V line, to provide power. This doesn't connect to the Arduino at all.
Here's the wiring diagram:

Adapter board wiring.

S1 and S2 are the signal lines, going to digital pins 12 and 13 on the Arduino, respectively. Digital pin 13 also happens to control the built-in LED indicator, which flickers now when that signal is sent. The ground is common, of course. The servo lines therefore plug directly into the adapter board, so it can replace the radio receiver.

Everything all connected.

Using the Servo.h library for Arduino, it's relatively easy to control the steering servo: you specify a position between 0 and 180 degrees, and call refresh at least once every 20ms, and the servo will move. The servo doesn't need its full range of motion, as the steering links don't have that much travel. Moving the servo between 40 and 140 degrees is enough to fully articulate the steering: any more and you can hear the servo grinding and the servo saver stressing.
Unfortunately the ESC is another story. So far no signal I've sent it has elicited any response. I'll have to find some documentation on how that one works.

The servo code is based on the tutorial on the Arduino Playground. Here it is:

#include
#define pin1 12
#define pin2 13

Servo servo1;
Servo servo2;

int angle = 90;
int dir = 1;
int counter = 0;
int counterMax = 100;

void setup()
{
servo1.attach(pin2);
Serial.begin(9600);
Serial.print("Ready");
}

void loop()
{
static int v = 0;

if(counter > counterMax)
{
counter = 0;

angle = angle + dir;
if(angle > 140){dir = -1;}
if(angle < dir =" 1;} servo1.write(angle);

Serial.print("angle: ");
Serial.println(angle);
}
counter++;

Servo::refresh();
}

Note that you need to download the Servo.h code, which is available through the tutorial linked earlier. Anyway, here's a video of the Arduino running the steering:

video

Sunday, May 25, 2008

Electrical Anatomy of the Stampede

The first thing was to partially disassemble the Stampede and work out how the pieces go together. I'm not planning any major changes to the chassis mechanics. Most R/C modifications are for better speed and performance, which is not the intention here. The chassis is a rectangular plastic tub with shock towers at each end.

Stampede chassis with wheels removed.

Only the rear wheels are powered, and the steering is controlled by a single servo, visible as a black box between the two front shock absorbers. The shocks attach to the black shock tower, which sports two body mount posts above it. The battery normally lies in the well in the chassis center, and connects to the yellow Electronic Speed Control (ESC). You can also see the blue aftermarket bumper (by RPM Racing) that will protect the front suspension from damage (and hopefully prevent a repeat of the broken caster block).

Front Assembly with steering servo (left under shock tower) and radio receiver (right).

Sorry for the slightly blurry picture. The radio receiver has two channels, channel 1 in the bottom slot controls the steering. A servo has a three-wire interface. The black is the ground wire, the red is the 6V power, and the white is the signal line. The receiver gets its power from the ESC, and returns a signal back to the ESC (channel 2) on the white wire, treating it as a servo. The ESC interprets that signal to control the main motor. The steering servo on channel 1 receives its power from the radio receiver, as well as a signal on the white wire.

If I'm going to replace the receiver with the microcontroller, the steering servo still requires a power supply from the ESC. So, the microcontroller must only send a signal on the white wires, and must be connected into the black ground wire. The red power wire must bypass the microcontroller and remain connected to the servo.

The Electronic Speed Control (ESC)

The ESC receives power from the battery (far left) and passes power to the motor. These wires are heavy-gauge to accommodate the high current passing to the main motor. The thinner three-strand wire at the bottom of the image goes to the receiver, powering the receiver and the steering servo, and receiving back a signal on the white wire, as noted previously.

The main drive motor.

The main motor itself is a Titan 550 12-turn. There's not much need for modifications here: except perhaps to gear the system down. The truck's really fast: far too fast for an autonomous system.

Friday, May 16, 2008

Arduino Diecimila


My very own Arduino Diecimila microcontroller arrived today. The Arduino implements the "wiring" communications library and is open-source to boot. It can serve as the robot's brain, but is limited to simple analog or digital inputs, so vision is right out. It also has a USB-b connector, so it can communicate with a larger computer and can thus serve as a simple chassis interface.

Traxxas Stampede


So there it is: a Traxxas Stampede. It's so much fun to drive around I'm rather reluctant to tear it apart. I'll have to take some care to retain the ability to run it as an R/C car.

The stampede is a 2WD Monster truck. It has a single servo for steering and is capable of 30 mph. I'll reduce the gearing so that it has more torque and a lower top speed for safety.

If you look carefully you can see that the front-right tire is askew. That's because I ran it into a curb and broke the front right caster block. It's currently awaiting a new caster block so it'll run again.

Thursday, May 15, 2008

The Plan

The robot will have the following:
  • An off-road capable R/C chassis in 1/10 scale (good brand names I know: Tamiya and Traxxas)
  • A microcontroller to interface with the chassis electronics and perhaps some of the simpler onboard sensors. (I have a small amount of experience with the Arduino board which makes it my first choice.)
  • An onboard computer for the AI and Vision processing. Right now the leading candidate is the Asus eee PC, but the HP 2133 Mini-Note and various Mini-ITX computers are all in the running. More on this debate later.
  • Camera(s) for vision. Stereo would be great, but that requires two cameras rigidly fixed to one another. I also have to consider the limitations of the computer's USB or Firewire Bus and processor to handle that much incoming camera data at once.
  • Other sensors. Candidates are Ultrasonic Rangefinders, Bump sensors, and Infrared Rangefinders.
  • Power will be supplied by the chassis battery and a additional battery for the computer. Laptops are the most convenient in that regard.
The main task I want the robot to perform initially is roaming with obstacle avoidance, and mapping. Basically the robot should accumulate a map of its surroundings by wandering around and observing them, while keeping track of its own position relative to previously-viewed landmarks. Formally, this is called Simultaneous Localisation And Mapping, or SLAM. Once that's working, who knows what I'll program it to do.

For a software structure the plan is to use Player/Stage with Gazebo, which is an open-source framework for developing robots.

Big plans. We'll see where they go.

The History

This entire project started as a result of participating in the Waterloo Robot Racing competition representing the University of British Columbia as part of the Thunderbird Robotics Team. The challenge was to build a small autonomous robot that could navigate a course demarcated by orange traffic cones. Our entry was based on a Tamiya remote-control Hummer kit, and was controlled by an Arduino microcontroller. The robot had infrared line-following sensors and ultrasonic rangefinders. What the robot really needed was a vision system. I was so enthused by the whole project that I decided that I wanted to build a robot of my own, based on an R/C car.

Wednesday, May 14, 2008

Inception

Welcome to the Snowtires Blog, my personal chronicle of the process of building a vision guided robot. This will be my first foray into electronics building and robot construction, so who knows where it will end up. Bear with me and I hope there will be some interesting times ahead.

-tetracanth