Cathy's Robot Adventures

Welcome to the ramblings of a robot enthusiast. My husband, Tom, and I recently started building and programming robots. Here's how it all started...

Getting Hooked

On March 30, 2003, we attended a talk given by Dean Kamen and were enthralled by his stories. He's invented lots of interesting science/technology stuff, and had great tales to tell about his adventures along the way. His best-known invention is the Segway, but he's also created numerous significant medical devices. We also learned about his FIRST organization (whose goal is to inspire youth to explore science and technology) and their annual robotics competition, a challenge for high school students to build a 130-pound robot to compete with and against other schools in a non-destructive contest. We decided to check it out at the pacific northwest regional competition.

Tom and I went to the FIRST competition mainly to see whether it looked like something we'd want to do with a team at Issaquah High. We didn't expect to get very involved in the contest since we didn't know anyone involved. As it turned out, it was a blast. At the FIRST competition, I met Ron, who encouraged us to get a team started at our high school, offering that the Seattle Robotics Society would help us find mentors for the team.

At around the same time, Tom mentioned that he had heard about a C-like language for programming our Lego Mindstorms brick. I did some research and ended up playing (a lot) with Dave Baum's NQC and our bot. We ordered one for school for the newly-formed robotics club to play with.

Well, all the robotics stuff got me started again on trying to build my own robot, something I've always been interested in, but haven't really ever found a way to get into. I started researching building a bot, even managing to dig up an old recommendation for "Mobile Robots" (cool book). I looked at getting the parts for their Rug Warrior bot, but the price seemed a little high for something I wasn't sure would ever get off the ground (figuratively!). I also googled and found info on the Handy Board, which was a little better, but still more spendy than I thought made sense for a new hobby.

Now I've Done It...

I attended my first SRS meeting in June, just to see what it was all about (are you seeing a trend here?!).

I ended up buying a board and a bag of components from Larry Barello (the ARC 1.1 kit). It was much less than the other stuff I'd seen, but then again it was just a processor: no chassis, motors, wheels, sensors, etc. I ended up getting a PARTS Mark III kit which had all that stuff; I just didn't use its processor.

I decided to try my hand at building a maze-solving robot for SRS's October Robothon event. This year the maze can have loops, so it's a really interesting programming challenge. I was also informed (a bit after this) that most people last year didn't even make it to the end, even without loops. "Shield your sensors" was the common bit of advice; seems that many bots suffered from the uneven light coming from skylights.

That quickly evolved into my wanting more control of the layout of sensors, so I built my own chassis. I also wanted to play with motors, so Tom ended up with most of the Mark III parts, turning it into a successful Mini Sumo bot with another of Larry's boards.

Twisty

As I designed and built a chassis for my maze-solving robot, I discovered her name: Twisty. It comes from the classic Adventure game; one area is a "maze of twisty little passages, all alike."

I taught her to follow lines. With multiple sensors, she could know which way to turn when she lost a line (a big improvement over the educated guessing my single-sensor Mindstorms bot used). A couple of sensors further out detect lines that indicate side paths from a junction.

In order to solve the maze, Twisty needs to know how far she's traveled (this is critical when detecting loops). I tried to use an encoder on the motor, building an IR emitter and detector to put on either side of a disc with holes in it. Major disaster. Next attempt was to use the processor's clock to track how much time it took to travel down a line. That worked fine if Twisty traveled the line nicely, but when she had to wiggle after losing the line, it could add a sizeable amount to time. The error margin was too big to work.

At the September SRS meeting, Jim Wright had some info on using an optical mouse to measure movement. Tom experimented and figured out how to use it with our processor. We found a $6 mouse at Fry's that's got the chip we want and a nice, small, form-factor. Hooking that up gave Twisty a great odometer.

Enough with the Hardware; Let's Write Some Code!

Meanwhile, I wrote and tested a cool system for storing junctions in the maze and deciding how to navigate based on that, including solving loops. I tested the heck out of it with a DOS-based test program. It was cool. It also used 2k of (stack) memory, not a lot for a modern desktop PC, but several times what was available on Twisty's Atmel ATMega16 (yes, that's really 2k, not 2M!). I learn something new about that chip every day... (Most of it has been cool features.) Interestingly, before I discovered that lack of memory was the problem when running the code on Twisty, I was trying to figure out what was going wrong by adding code to show status via the serial port. As it turns out, adding that code just made things worse since it exacerbated the memory problem. So, my debugging kept making things worse.

Atmel makes a chip with more memory that I could use to replace the Mega16. Unfortunately, it was out of stock everywhere, so I couldn't get it in the week remaining before Robothon. At the SRS meeting shortly after discovering this problem, I asked Larry if he had any Mega32's, but he doesn't stock them. Bummer. But, he did mention that he'd written a paper on line-following and that his algorithm would help with Twisty's wiggling when she loses a line.

So, back to the drawing board... I came up with an algorithm that works in the 500 or so bytes available. I tested/debugged that with the PC-based program, added loop handling, and turned Twisty loose on a test board. After fixing a few bugs, things were looking great. I also added code to use Larry's method for following a line; Twisty was now making small, smooth, and nearly imperceptible course corrections to stay on the line instead of jerking back and forth. Nifty!

Robothon Here We Come

So, Twisty is ready. It's late (after midnight) the day before the contest and I decide that I'll try again to get the parallel port in my new portable computer's port replicator to talk to Twisty, just so I've got a backup plan in case I encounter problems running the sample maze. I've got a couple values I can easily (and relatively safely) change to get her to move more slowly if it looks like she's missing lines. After giving up on the computer, I put Twisty on my sample maze, just to be sure everything is still OK. She behaves really oddly, exhibiting multiple problems. In my experimenting, something happened to Twisty.

Now it's really late, and my bot is broken. But, I can't sleep with this situation! I try re-downloading her program; no help. I reset some memory; still no dice. Now I'm starting to panic, wondering what random commands she responded to in the failed attempts at a good communication with the portable. I check some things; they're still OK. Finally, I check some of her memory and find the problem (corruption of some values stored in EEPROM). After fixing that, I head to bed. Tom's already given up and turned out the light... that never happens; it must be insanely late!

Nothing Ever Goes As Planned

Sunday morning, Tom and Dad and I get to Robothon and I try Twisty on their test maze. She fails to find the cross lines. I figure it's a metering problem. I track down the board with a large black circle and use it to set black level. She's still blowing past junctions. I run downstairs to Tom's computer and use it to check her memory. She's clearly recognizing the difference between black and white really well. I reprogram her to move more slowly, run back upstairs, and expectantly run her again. Argh! She's still having problems. At some point shortly after this, I realize that her problem is that the optical mouse sensor wasn't working on the slick white surface of the maze. In addition to using distance to help with loop detection, Twisty uses it to move forward a little past a junction before turning (to see if there's also a path going straight). As that dawns on me, I realized that I'm screwed. I sit there is a daze, looking forlorn enough for someone to comment on it.

I figure it's time to throw in the towel. Without some way of measuring distance, Twisty's got no way to recognize that she's looped back to a place she's been before. At some point (maybe as a result of talking to someone who was sympathizing with my plight), I realize that I could at least try using time again. Now that Twisty is following lines smoothly, she had a good chance of getting consistent, reliable times between junctions. I am encouraged as I realize that my code would be really easy to update with this change. Modularity/abstraction is good!

Last-Minute Changes

I race downstairs to get started. A few minutes later, I've got code written to use time instead of distance to measure between junctions. I dash back upstairs to try again. Clearly a big improvement. This verifies that detecting lines was not the problem, since she's turning after each junction. She's just moving forward about four times as much as she should before each turn. Oh, yeah, I'll need to scale that value to account for time instead of distance. I make a rough estimate (based on my crude measurements and with assistance from Tom and the circular slide rule on his watch) and try again. Close, but still a little off. I'm getting my exercise running up and down the stairs today. I finally get it right and run her on a longer section of the maze. All goes well for a while, then she appears to miss a junction. OK, so I'll slow her down (I sped her back up when I realized that the optical mouse was the problem). Now it's time for Traditional Mini Sumo (I've mostly missed the Advanced Mini Sumo while fixing Twisty) and I want to watch Tom compete. So, I change the code to slow Twisty down, deem her done, and set her aside.

Tom does well; his 2 losses are to the 1st and 3rd place robots. Great job, especially considering this is also Tom's first bot. (We think he ended up 7th out of 32 robots.)

As Mini Sumo is wrapping up and the judges' awards are being presented, Dad asks some question about the line maze and/or what I've changed with Twisty. In answering, it triggers something and I realize that I've neglected to change the value that indicates how "close" we are to a junction -- we'll never get back perfectly, so Twisty uses a tolerance value to decide whether we've looped. Yikes! It's still at the large number from when junctions were measured in distance. Now that we're using time, we need to use a much smaller tolerance. That's why she "missed" a junction in my last try -- she thought she'd already been there and reacted accordingly. I make a wild (OK, reasonably mathematical) guess at what value I should change to. My test mazes with loops are at home, and the sample maze here has no loops, so I can't test it. I've basically given up hope on doing well at the maze this year, and hope that at least I don't embarrass myself too much. Twisty is doing well at following lines and detecting paths, and I'm pretty confident that she can solve the maze if she can correctly identify where she is, so it's worth giving it a shot.

Time to Compete

Line Maze time comes. I'm really nervous. There are eight bots registered. I hope I'm first because the tension is killing me. After they explain the rules, they call for the first bot. Twisty! (Because I was the first to pre-register.) I put her down. I'm only shaking a little. I start her, and she progresses nicely. She handles the first path (a loop!) nicely; I can tell from her actions that she recognized the loop! She detects and handles the next junction well, and I'm feeling a little more relaxed. Then, the announcer decides there should be running commentary, so now I'm answering questions while Twisty does her thing. She continues to behave beautifully, even correctly performing a U-turn I tell the crowd to expect as she reaches an interesting junction in another loop.

The commentary is cool. I'm used to talking to groups of people (teaching), and while the crowd is larger than my class, they're friendly and tend to clap and cheer as Twisty makes progress, so I'm having fun. I get to tell stories and talk about how sensors aren't to be trusted, even how I had to make a last-minute change to compensate for the optical sensor not working. I think being able to babble about my robot experiences is helping to calm me a little.

Twisty finishes her first of three runs after making great progress, one second before her allotted three minutes is up. I start her on her second run, and she zips expertly down the path she's found to be good (I feel like a proud parent!), back to where she was at the end of the first run, then keeps exploring. She makes it to the end point after 2 minutes and 10 seconds, detects that she's done, and stops.

For her third run, she can just motor straight to the end; she knows how to get there. By now I'm really shaking, though. I bobble something (I still don't know what), and end up doing something that resets her, making her start all over again as if it were the first run. That's OK, her score is the best of the 3 runs, and she even gets a 10-second bonus for detecting and stopping on the end circle. So, she records a score of 2:00. I'm feeling pretty pleased -- she solved the maze, and that's reportedly something that many of last years bots didn't manage.

Next up is CYclops. He takes off at something like 3 times Twisty's top speed. I wonder whether he'll be able to spot side paths as he flies past them, but he does, making nice smooth turns and cruising on to the next junction. He makes it to the end (and stops) in something like a minute and a half. His next run, he skips all the dead ends he found the first time and makes it to the end in 23 seconds! With his 10-second bonus that gives him a score of 13 seconds.

OK, now I'm feeling a little embarrassed about all the commentary I gave when Twisty was running. I'm clearly out of my league.

Fortunately, after that, the bots generally had trouble solving the maze, so it turns out that Twisty did actually perform quite well! One other bot made it to the end, but it kept going, so it didn't get the 10-second bonus. That was enough to keep Twisty in second place. I have a very nice plaque to commemorate her success.

Robothon was a blast. I can't wait for next year, but first I really have to get caught up on all the stuff I've been neglecting for the last month!

For those of you that have managed to stick it out through this entire dissertation, your reward is a peek at the construction and programming info!