Snowtires

Waterloo Robot Race 2009

2009-07-27T21:38:00.000-07:00

Waterloo Robot Race 2009

Snowtires went to the races, and competed in the Waterloo Robot Race for 2009, competing against 10 other robots, qualifying for the final race, and finally placing second overall. This competition marks the culmination of this project (for now). I was ecstatically pleased with the performance of Snowtires, and happy to note that some of the other UBC robots used elements of the Snowtires guidance code for their own vision systems.

The Waterloo Robot Race is a trio of challenges. The first is a drag race, a flat-out speed competition down a cone-lined track. The second is a round of static judging for aesthetic and technical appeal. The third round is the circuit race: a cone-lined figure-8 track with a moving purple obstacle cone at the intersection. There are also two stop signs and a traffic signal. The robots face penalties if they do not stop for three seconds at the signs and for the duration of the red light at the signal. Additional penalties are levelled when robots take the wrong path or hit the orange cones.

The UBC-CERM3 Thunderbird robotics team entries:

From left to right: Snowfury MkIII, Johnny5, Snowtires, Big Dave, Quartz, and Oscar.

Snowfury MkIII was the original Team Thunderbird 1/10th scale racer, and is shown here in its third incarnation as a vision-guided robot. It uses the snowtires vision code in an underdamped, aggressive configuration. The basic platform is a Tamiya Hummer with an ASUS eeePC 701 computer onboard. Snowfury was constructed and operated by Marcel Veronesi, with assistance from Tim Lee. Snowfury achieved the shortest time in its heat and placed fourth overall in the competition.
Johnny5 is another vision-based robot, which runs a more conservative configuration than Snowfury. Johnny5's creator Tom Huryn pioneered the rear-mounted camera configuration - the further back the camera is, the better peripheral vision the robot has, improving its ability to avoid objects at close ranges. The underlying platform is a Traxxas Rustler, with an eeePC for the brains. Johnny5 placed 5th in the competition.
Snowtires is my machine, seen here with its new bodyshell. We integrated infrared rangefinders for close-range collision avoidance, but in the bright sunlight of race day they were of little use except at point-blank ranges. Snowtires placed second in the competition.
Big Dave is our fourth vision machine, constructed and operated by Tim Lee. It is configured similarly to Snowtires, with an up-front camera and pure vision guidance.
Quartz is the team flagship, constructed and operated by Ash McKay. Equipped with a laser rangefinder, it has an accurate and detailed 2D view of the world. It uses a vision system to detect stop signs and traffic signals. The rangefinder can detect the purple obstacle cone, and so Quartz is distinguished and the only robot in the entire competition with a full suite of features, capable of handling all of the competition challenges. Quartz placed third in the competition, and would have placed first if the penalties for ignoring the traffic signs and lights were of any significance. It wowed the crowd right out of the starting gate for recovering from a guidance error by backing up and correcting its course.
Oscar is the maverick robot, eschewing vision guidance for sonar-modulated odometry guidance. Oscar had a map of the course, and verified its position using sonar readings. However, sonar units have trouble in outdoor areas, particularly under the high winds that we experienced on race day.

Race Day!

Race day opened with an electrical storm. The competition
rules said rain or shine, so we got to work putting the waterproofing
on our robots - plastic bags covering the gaps in their bodyshells.
Fortunately the rain cleared up by the time we got there.

Here's Snowtires in race regalia, during a practice run on the
course. The course was largely dry with puddles by the
time we were practicing.

The crossroads, compete with stop sign and purple cone (with its crane).

A test run with Snowtires (I don't have any race footage as I
was poised over the panic button in case the robot made
an error: I'll post some of my colleague's footage when
I get it. Note how Snowtires avoids puddles when it sees
the reflection of a cone in them.

Here's the drag race: my heat against the Windsor U. robot.
The Windsor robot was a torpedo: it went on to win the competition
due to its mixture of vision guidance and raw power. A little
frightening recovery at the end there, but awesome to behold.

My robot is considerably more conservative. So much so that
this video is of the same drag race, just, you'know... later.

In the second round, I was up against Quartz. My starting timer
didn't engage, so I started three seconds before I should have,
and took a 3 second penalty. It didn't matter anyway as Quartz

passed Snowtires on the straightaway to take the victory.

This is Windsor's Team Invincible running the circuit race.
Their robot has impressive speed, and really pulled out all the
stops for the main race. As they pass the intersection you can
see Johnny5 crossing the finish line as part of the previous heat.

Here's Quartz mere feet from the finish line. Due to a battery issue,
Quartz had a slow second half of the race, but placed third anyway
due to making only a single error in three whole laps.

And here's Snowfury doing its wild weasel routine. The vision
guidance is underdamped, so the robot "bounces" off the sides of
the course, as it usually can only see one side at a time. It had the
second fastest lap time after Windsor, and lapped Snowtires, but
incurred more penalties while doing so. Definitely the
"people's choice" and really entertaining to watch.

Windsor took first, and UBC took places 2-6. None of the other robots fielded were able to qualify to race, in some cases only due to issues with outdoor operation. There were several impressive contenders, but in the end it was a Windsor/UBC field. We're very pleased with the results, and we'll be passing a good legacy on to future Thunderbird robotics club members.

A big thanks goes out to our sponsors, and to everyone who made this possible. To our team leader, Dr. John Meech, and all the robotics club members this has been fantastic, thanks for one wild ride.

-t

Indoor testing with panning camera

2009-06-14T12:16:00.000-07:00

Here's a video of a test run indoors. I've incorporated the pan-tilt unit into the vision system, so the camera now turns in the direction the robot is steering. This allows the vision system to image the road in the predicted direction without having to wait for the robot to roll forward and the chassis to turn. This takes a large amount of latency out of the guidance loop and improves performance, allowing the robot to move faster.

This is an example of cephalisation - placing sensors on a "head" whose orientation is not directly coupled with the main body, allowing the sensor suite to be directed independently from the body orientation.

The new guidance system

2009-06-11T14:09:00.001-07:00

Fig. 1: the guidance visualisation: on the left is the
source image, and on the right is the perspective
warped map of the ground ahead.

Snowtires is a vision-guided robot, so here's a rundown of the the vision system works. The basic idea is really simple: the robot veers away form any objects of a designated colour in front of it. In practice this requires several steps:

Capture an image of the road ahead (left side of Fig. 1)
Determine the horizon line in the image (top of green box)
Determine the perspective transformation from the image to the ground plane.
Transform the section of the image below the horizon to see the image is though it were viewed orthogonally from above. (Fig. 1 , right side)
Filter the transformed image to determine if there are any orange pixels (or whatever colour you're avoiding)
Draw a selection of possible paths onto the image
Compute the number of orange pixels that are within a set distance of each curve - this will be the curve's penalty.
Choose the curve that passes over or near the fewest orange pixels

It sounds fairly simple, and it is with the help of OpenCV. First, OpenCV allows the camera capture using the HighGUI functions. I choose the horizon line manually, and hope that the robot doesn't rock forward or back too much... You could use a horizon detector here, but I can't be bothered right now.

Next comes the transformation. This is really easy. OpenCV has the function GetPerspectiveTransform which takes as inputs the corners of the rectangle in the source image and the corners of the trapezoid in the distorted image, and returns a 3x3 matrix representing the perspective transform in homogeneous coordinates. Next, you feed the matrix and the imge into WarpPerspective, and it deposits the warped image into the map. I draw the trapezoid just to be sure all my math is lining up.

To filter the colour, first convert the map to the HSV (Hue, Saturation, Value) colour space. The hue represents "colour" in the sense of where on the rim of the colour wheel that colour would be (0 is red, orange is 15, yellow is 30, etc etc), so we can filter out any pixels that are not within a threshold of the hue we want. The saturation represents the colour's intensity. The cones have extremely high saturation, whereas the saturation of the pavement is very low. Filter any pixels with low saturation. Finally, Value represents the grayscale illuminance of the colour. I filter out any pixels that have really low value.

That leaves only the bright orange pixels. I create a series of curves, and apply a penalty to each curve dependent on the number of orange pixels within a certain distance (usually the image width/8) of the curve. The curve with the least number of orange pixels within that range "wins" and its curvature is used to determine the steering output. Note that in the figure, due to my ineptitude, curves with high penalties are green and curves with low penalties are red. Sigh.

eeePC battery issues

2009-06-08T08:32:00.001-07:00

Immediately after the practice race I put the eeePC away in its sleeve. About an hour later I pulled it out, only to discover that is was extremely hot - apparently it had not shut down properly and had overheated while unable to cool itself in the sleeve. I removed the battery and allowed it to cool. Fortunately, the eeePC still seems to work normally, however, the battery will no longer charge up - it remains at 33% charge no matter how long you charge it. So, it looks like the battery was thermally damaged somehow. I'll have to get it repaired or a new one - race day is a month away.

The bettery is indeed damaged. I haven't experimented with it yet but I suspect that the 33% reading is accurate and that's where this battery tops out now. Anyhow, I got a new 8800 mAh battery to replace it, and I'm going to try to get NCIX to replace my existing battery under warranty.

So it's been a while...

2009-06-07T17:38:00.001-07:00

Well, after five months I'm blogging again. Only very recently did I make any tangible progress over what's been previously posted. Now things are rolling again, and there's a lot to report from the past month or so of work, so I'll elaborate those over the next little while.

First, what you really want to see: a video.

Here you see Snowtires in its new form doing a lap at the Thunderbird robotics club practice intramurals race day. We set up a race to mock up the conditions of the actual Waterloo race in order to test the robots under realistic conditions. The robots need to do laps of a concrete course lined with the usual orange cones. Doing this outside introduces some new challenges, namely, outside there's an abundance of IR radiation going around, which completely blinds the camera if not filtered. To this effect I installed a mirror-finish sunglass lens and a pair of polarizing filters to reduce glare and block IR. This dims the image enough for effective vision even under direct sunlight. The camera is now on a pan-tilt unit mounted front and center on the chassis. It is coupled to a new guidance system that I will elaborate on later. Other modifications include the replacement of the Arduino-based chassis controller with a Furious Module: a USB-based servo and sensor controller designed by the team's own Ash McKay (for details see: his website).

Snowtires won the practice race by completing three laps of the course with only a single error. At the moment the guidance system only works at very low speed: I'll be attempting to improve that as time goes on, but we're getting close to the July 11th competition date. Other requirements: a stop sign detector, a stop light detector, and a purple-object avoidance routine. TIme to get back to work...

Another test run

2009-01-19T13:58:00.000-08:00

Here's the latest test run, this time using cones for the course markers. It does two successful laps before missing a turn. It would appear that the guidance has the most trouble with sharp turns, particularly if that results in it approaching a wall at a near-perpendicular angle. Future improvements will hopefully address this problem.

P.S. If the video plays absurdly fast, just restart it. Some browsers seem to have an issue with the video playback.

P.P.S. If you're wondering at the three-month gap in posting, I've been finishing my Master's thesis, and have only recently reemerged into the sunlit world.

A new video

2008-10-21T15:34:00.000-07:00

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.

eeePC up and running

2008-10-21T15:19:00.000-07:00

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).

Ubuntu Install via external optical drive

2008-08-19T14:55:00.000-07:00

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

2008-08-19T14:38:00.000-07:00

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.

GTK woes

2008-08-17T09:47:00.000-07:00

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.

Arduino setup on Linux

2008-08-10T23:16:00.000-07:00

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

2008-08-10T23:08:00.001-07:00

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.

Setting up the eee PC

2008-08-07T22:28:00.000-07:00

For the eee PC to function as the robot's computer, it needs several things:

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.
A regular Linux desktop, with the ability to easily control settings and active devices.
A working install of OpenCV - the Open Computer Vision library, which forms the basis of all my vision code.
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.

eee PC Arrives

2008-08-06T14:19:00.000-07:00

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.

Success

2008-08-02T20:10:00.000-07:00

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.

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.

USB Communication part II

2008-07-17T22:21:00.000-07:00

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;
}

Ordered a computer

2008-07-11T15:13:00.000-07:00

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.

Vision Software

2008-07-10T18:23:00.000-07:00

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:

Capture a frame from the camera
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.
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.
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.
Group the lines into those with positive vs. negative slope. Compute an average for each group of lines.
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.

Spur Gear Wobble

2008-06-25T18:01:00.001-07:00

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:

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.

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.

Addendum - Pin # change on the Arduino

2008-06-24T15:25:00.000-07:00

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.

USB Communication

2008-06-19T20:17:00.000-07:00

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

2008-06-19T19:36:00.000-07:00

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:

Choosing a computer

2008-06-09T14:27:00.000-07:00

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.

Servo Wiring

2008-05-28T22:21:00.000-07:00

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:

Connects the signal wires from each servo to digital output pins on the Arduino.
Connects the Arduino's ground pin to both servo ground wires. The ground must be common, or none of the signalling will work.
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:

Electrical Anatomy of the Stampede

2008-05-25T19:35:00.000-07:00

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.

Arduino Diecimila

2008-05-16T00:58:00.000-07:00

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

2008-05-16T00:35:00.000-07:00

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.

The Plan

2008-05-15T08:50:00.001-07:00

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

2008-05-15T08:43:00.000-07:00

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.

Inception

2008-05-14T13:35:00.000-07:00

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