The Man: 1, Mike: 0 (but maybe you can help)

(for how to help, skip to the end)

My friend Michael had a recent vendetta against The Man (Southwest Airlines, in this case). They bumped him from a flight and gave him a $350 travel voucher in return. He wrote down the number and threw away the paper, happily dreaming of trips to exotic locations.

There was just one small problem: he only wrote down one number—the voucher number. Turns out that you also need the security code, or your voucher number is useless. He contacted Southwest, and they said they couldn't help him. Rather than give up, though, he vowed to try all 9999 possible security codes at Southwest's web site until he found the right one. He estimated that after 25 days he'd have a 50% chance of finding the right one.

I saw Mike's blog entry about his fight, and as one who detests The Man as much as the next guy, I took pity on him. No, I didn't start spending my free time entering numbers at southwest.com; instead, I wrote a computer program to enter them for me.

The robot

After a bit of work, I had created a robot that would go through the booking process on Southwest's web site all the way to the point where you enter the voucher number. Over the course of a few hours (while I slept last night), it tried all 9999 four-digit security codes.

Unfortunately, I discovered when I woke up this morning that none of the security codes had worked. None of them. (On the bright side, at least Mike didn't have to spend 50 days entering numbers manually, only to discover that none had worked.)

What went wrong?

There are a few possible reasons why it didn't work:

1. Mike wrote down the wrong voucher number.
2. The security code format isn't a 4-digit number.
3. There's a bug in my program.

Reason #1 is a lost cause. If that's the real explanation, there's no hope.

Reason #2 seems possible, but Southwest's booking site, as well as pages found by Googling, lead me to believe that it is, in fact, a four-digit numeric code. (Anybody know for sure?)

How to help

So that leaves Reason #3: I messed up. However, you can help me debug my program. I need two things:

1. If you're a programmer, you can take a look at my program and let me know if you find any bugs.
2. If you have a Southwest voucher number and security code, you could let me test my program with them. (I promise I won't steal your flight...)
   

If you're a Python programmer, feel free to take a look at voucherbuster.py. (Warning: really ugly quick-and-dirty code. Also, you'll need mechanize to run it.)

Because I don't have a working voucher number/security code combination, I can't be 100% sure that my program will recognize a correct combination. I'm pretty confident that it works, but I can't be sure unless I test it with a real voucher number/security code pair. If you too want to get back at The Man, and you're willing to let me try your voucher number (not to buy a ticket, just to validate my program), drop me a line. Thanks!

How to batch adjust photo timestamps on a Mac without iPhoto

Synopsis:

• If you use iPhoto, just use Photos -> Adjust Date and Time (as pointed out by Silus Grok).
• If you use Aperture, follow these instructions.
• If you have neither, you can use PhotoInfo.

More details:

I take a lot of pictures, and often when I get home I discover that my camera's clock wasn't set correctly—because of a timezone change while traveling, daylight saving time, dead batteries (and thus a reset clock), or just simple clock skew due to inaccuracy in the quartz crystal and the circuit that drives the clock ticks.

Why timestamps matter: Incorrect timestamps aren't just annoying: they can cause inaccuracy with automatic geotagging (e.g. with GPSPhotoLinker), and they can cause your photos to be in the wrong order when you combine yours with a friend's and sort by time. To combat incorrect timestamps, I usually take a picture of an accurate time source with my camera—either my GPS, or a cell phone. Then, when I get home, I can change the timestamps of all of the pictures on my computer.

No good free tools: Well, that's the theory, at least. I've been looking for years for a free, easy to use tool that will let me change timestamps, but with little success. A Better Finder Attributes will do the trick, but it costs money. I'm cheap, so instead I have used exiv2 for quite a while. It gets the job done, but it's an unfriendly command line tool.

PhotoInfo to the rescue: Happily, today I discovered PhotoInfo by Jim Merkel, which is a Mac OS X application that does almost exactly what I want. It lets you select several pictures (or a folder), enter a time offset in hours:minutes:seconds, preview the changes, and then adjust all of the pictures with one click. It can adjust both EXIF and filesystem timestamps, and it works with JPEG, TIFF, and raw files. Thanks Jim!

The only other feature I'd like to see is for it to automatically calculate the time offset, like iPhoto. I'd like to be able to enter the correct time for one photo, and then adjust all of the other photos by the same amount.

Screenshots of PhotoInfo 2.0.1:

The main window, after opening a folder

Preview window (pops up after clicking Show Changes)

Preferences

Creativity

Microsoft is getting very creative... or at least its marketing droids are.

They just started a "Get the Facts" (mis)information campaign about Internet Explorer, claiming that IE has security, privacy, ease of use, developer tools, reliability, and compatibility, while Firefox and Chrome don't. They also claim that IE supports web standards.

Every single one of those assertions is false. Laughably so.

I don't know a single computer-savvy person who would agree with those statements. Not one—and I know a lot of computer-savvy people. Every web developer I know uses Firefox because it offers far superior development tools to IE. Every web developer I know despises IE's lack of standards support. Many of my friends love customizing Firefox with extensions. Many security experts recommend not using IE.

Seems like Microsoft is trying to deliberately mislead the uninformed masses. Just because you say it doesn't make it true. Not cool.

(Incidentally, I really liked working at Microsoft. I had great coworkers, and worked on a really cool project. However, part of the reason I didn't go back there was that I wasn't a fan of the company's business culture. This is a good example.)

Bug report

My roommate went to an Apple Store a few days ago to have them fix his Mac laptop, and he received poor service. In response, I submitted this bug report to Apple's internal bug tracking system:

Title: Customer was turned away for being eight minutes late
Component: Apple Store

Description:
03-Jun-2009 10:30 PM Bruce Christensen :
* SUMMARY
My roommate Brian was turned away from his Genius Bar appointment for being eight minutes late. Count them: 1 2 3 4 5 6 7... 8!

* STEPS TO REPRODUCE
0. Have a MacBook whose optical drive makes funny noises, like it has indigestion or something.
1. In an effort to fix your optical drive, set up an appointment with the friendly neighborhood Apple Store Genius Bar.
2. Arrive for your appointment eight minutes late.

* RESULTS
Apple Genius stated that there is a five minute grace period for appointments. Since the grace period had been exceeded by approximately 180 seconds (which is less time than some [admittedly very dentally hygenic] people spend brushing their teeth), he offered several options:
1. Wait an hour for the next appointment.
2. Ship the system to AppleCare for service.
3. Schedule an appointment for a different time.

Expected results:
An Apple Genius provides service as soon as possible, or at least apologizes.

* REGRESSION
Occurred in a largely-empty store, when Apple Genius appeared to have no other customers to serve. He was already booked for the hour, after all.

Scope of this defect is unknown. It was observed only at Stanford Shopping Center location, but may be more widespread.

It is unknown if the root cause of this defect is policy or autonomous Apple Genius action.

* NOTES
None of the Apple Genius-suggested options was acceptable.

Brian's generally favorable impression of Apple has been degraded by 20%.

The optical drive of the MacBook in question still makes interesting noises.

This retail experience exhibits several indications of suckiness:
1. Service was refused despite apparent ability to provide service.
2. Apple representative turned away customer for being three minutes later than protocol dictated. What are we, robots?
3. No apology was offered. Can't we at least be nice jerks if we're going to be jerks?

(For an example of how to be a nice jerk, see item 9 at http://blog.moosejaw.com/2009/03/30/clothing-donation-for-discount-promotion-announced-by-moosejaw-mountaineering/: "Sorry to be so mean about it, but you’ll have to pay for shipping your donation off to us.")

Whoever got the bug report apparently didn't have a sense of humor, because she just sent the ticket back to me with a note saying to contact someone else for help.

Rocket video camera

My ward had an activity over the last few weeks building and flying model rockets. A group of 2 or 3 people assembled and painted each small rocket. They were cool, but they were all the same, with the exception of the paint job. A couple of my friends and I decided to do something different.


Scott, Adam, and I are all engineers, and we put our engineering skills to use building a rocket with an on board video camera. The camera was designed for RC planes, not rockets, and the rocket wasn't designed for a camera, so it took a little ingenuity to put it all together. Scott built the rocket body, Adam painted it, and I installed the camera in the rocket. It took two types of epoxy, some hardware from Home Depot, an old shampoo bottle, a bit of Velcro, a little styrofoam, and some balsa wood, but things came together nicely in the end.


We launched the rocket last Saturday at a really cool location: Moffett Field at NASA Ames Research Center. NASA Ames is home to Hangar One, which is one of the world's largest freestanding buildings, as well as the world's largest wind tunnel, which is big enough to put a full-size plane in. A local rocketry club holds a monthly launch event at the airfield, and our ward tagged along.

Here's the finished product:


The launch was a success, unlike my last launch attempt. We had a delayed ejection motor, so we were getting a little worried as the rocket hurtled toward the ground, but the ejection charge fired, and the parachute safely brought our camera back to the ground. Here's the result:


(First photo by Brian Crapo, others by Adam Findley)

Airplanes are amazing

Airplanes are amazing. Case in point: last Friday a plane landed safely after one of its engines quit on the way from Boston to Houston (link courtesy of Erik). The plane was a Boeing 737, which only has two engines!

Catastrophes get a lot of the attention, but they're relatively infrequent. Incidents like Friday's are far more common. Something could have gone terribly wrong, but the system was designed to work even when problems come up.

The engineering that goes into airplanes is amazing. Critical systems are either redundant or are designed with large safety factors. Engineers analyze every failure mode and design systems to account for problems that may arise.

About a year ago, I talked to a pilot who flies for United, and I learned something cool: FAA regulations prohibit pilots from landing planes manually in certain conditions, such as in fog or high cross winds. The pilots are actually required to let the autopilot land the plane! So next time you're landing in fog, just remember that it's not that handsome pilot up front, but rather some pudgy Boeing engineer in Seattle who's getting you home safely. :) (Of course, it's still good to have a pilot on board; no computer could have done something like January's Hudson River landing.)

To illustrate what planes are designed to withstand, here's a video of a test that Boeing did for the 777. They calculated the maximum load that the wings could experience during flight, and then designed them to withstand 150% of that load. Next time you see the wings bounce when your flight hits a little turbulence, just remember that they're designed to withstand this:



Happy flying!

I also made this

First the iPod shuffle, now this: Google announced Google Voice this week.

Google Voice evolved from Google's acquisition of GrandCentral in the middle of 2007. I was an intern on Google's telephony team at the time, and my small team handled the acquisition. While I was there, I helped integrate GrandCentral's technology into Google's systems. I worked with Craig Walker, Vincent Paquet, and Wesley Chan, the guys who made the announcement in Google's blog.

This post's title is a slight exaggeration, since Google Voice was just in its infant stages while I was at Google. I did help lay the foundation for phone-enabled applications at Google, but I can't really take much direct credit for Google Voice. My team certainly can, though. Nice job, guys!

I made this

Cool, huh?

And for all of the complainers who say you can't use third-party headphones, chill out: the shuffle starts playing automatically when you turn it on.

Things to learn

Yesterday was a day of lasts:

• I went to my last undergrad class (CS 431, compilers, with Dr. Mercer).
• I turned in my last undergrad homework (a EE 380 problem set on the z-transform).
• I turned in my last undergrad lab (a EE 380 lab on elliptic filters).
• I turned in my last undergrad project (a peephole optimizer for my compilers class).

Next week I'll take my last undergrad final ever, and, with that, I'll be done with college.

I feel like I've just started learning, though. There are lots of things that I'd like to learn but haven't had time to because of school. Well, now's my chance.

Here's a sampling of things that I'd like learn about:

• Global poverty and public health, and ways to improve things
  
• Programming stuff: Cocoa programming in Objective-C, Android development, Haskell, AVR programming, MapReduce
  
• China, India, and Africa
  
• Spanish. I think I might take a class. I'm getting rusty.
• Trad climbing
  
• Medicine. I'd like to become an EMT or wilderness first responder.
• Algorithms (especially graph algorithms) and algorithm analysis.
  
• Maybe join a search and rescue team. Maybe.
  
• Child development
  
• Literature. I've learned a lot in college, but I've been too busy to read as much as I'd like. Time to get back to the books.
  
• Cooking
• Psychology
• Probability, Bayesian statistics, and graphical modeling
• Economics

That should keep me busy for a while.

Technology and the Church

I'm a member of The Church of Jesus Christ of Latter-day Saints, so I've followed with interest the Church's adoption of technology to help it accomplish its mission. The Church has used computers for years to keep track of financial and membership information in wards and branches, and it first set up shop (er, church) on the internet in 1996.

Things have come a long way in the last few years. Today, the Church's web site is useful, easy to use, and well designed. You can view ward directory information online, and mormon.org is a great resource for sharing our beliefs with the world.

Joel Dehlin became the Church's Chief Information Officer in 2004, and a lot of good things have happened since then. The Church's web sites have been redesigned, and they now both work and look better than before. A new, more capable graphical program for managing unit information has been deployed, replacing the ancient DOS-based program that had been in use for over a decade. The recently unveiled maps.lds.org site is a great way to locate a place to attend church.

Of course, there's still lots of work to do. For example, it would be great if I could view and report on my home teaching assignment online, or if leaders could view an interactive map that shows where each ward member lives. I would love it if I could subscribe to a feed that automatically showed church relevant church events on my calendar. I spent some time as a missionary in working in the mission office, and there's tons of room for technology to help out there.

I was happy to discover today that the Church is reaching out to the technology community through its LDS Tech web site. They're sharing what they're working on, soliciting feedback and help with the Church's technology projects, and working to develop some of the missing features mentioned above. Some of the projects on the site are a new home and visiting teaching application and a system for managing mission offices.

One of the coolest sections of the site is the LDS Tech Wiki, where people with technical skills can contribute to unfinished projects. If you have design, programming, editing, or other skills, and you're looking for a great place to put them to work, take a look.

Sometimes I worry that spending so much of my time studying and developing technology isn't the best way to contribute to the world. It's encouraging to see that technology is being used by the Church (and others) to accomplish great good in the world. I'm excited to see what the future brings.

Dangerous password recovery questions

You probably saw recently that someone hacked into Sarah Palin's personal email account and posted some screenshots of a few messages on the web. The news has stirred some noise among government accountability proponents, who argue that public officials should use only official email for official business, so that it can be properly retained and audited. Those questions are interesting, but another point piqued my interest.

As a curious technologist, my first question was, "How did they do it?". The article linked to above provided an explanation a day after the story broke: the attackers used Yahoo!'s password recovery system. You know the drill: when you set up an account, you have to fill in in the answers to one or two questions, like "What was the name of your favorite teacher?" or "What was your first pet's name?". Then, when you lose your password, you go to the site and fill in the answer, and then they'll unlock your account.

This password recovery method started gaining popularity a few years ago. (Before that, password recovery was almost always done by sending a new password to the email account you have on file.) Although it avoids the insecurities of email (which is usually transmitted in plain text over the internet), it has an even bigger problem: knowing the answer to password recovery questions is just as good as knowing the password itself.

As the person who hacked into Sarah Palin's account has shown the world, answering password recovery questions can be significantly easier than guessing a password. Anyone who knew me well in elementary school would probably be able to answer most password recovery questions.

Because of this inherent insecurity, I never answer password recovery questions truthfully. (If you're wondering, my first grade teacher was Ms. Pierce.) Instead, I take one of two approaches:

• If it's a throwaway account at a site I don't really care about, I do something like this: "Q: What was your first pet's name?. A: woierhjasldkfna;osighaw;ljkgnas;dflligha;sgfh." Try guessing that one!
• If it's an account that I may want to recover my password from in the future, I enter a different password as my answer to one of the questions. Ideally the site allows me to make up my own question, which is "What's the password recovery password?". If I can't make up my own question, then I just fill in another password as the answer to one of the dangerously obvious questions.

Next time you set up an account, be smarter than Sarah Palin and don't fill in obvious, easily-discovered answers. Remember that answers to password recovery questions are just as good as a password itself.

Rocket science

I have a little secret: I'm a rocket scientist.

OK, so maybe that's stretching the truth a little bit. I don't do ballistics calculations in my sleep, and I barely know what a Rayleigh number is, but I have worked on the 20-foot-tall BYU ARES rocket for the last three years. The rocket has a custom-built composite airframe with aluminum cross braces. It is powered by a hybrid liquid-solid rocket motor, using a ceramic nozzle manufactured by ATK—the same company that makes some of the rockets for the space shuttle.

So, how does someone like me go from being an average Joe to a contributor to a big huge rocket? My roommate initially roped me into the whole situation. He worked on the avionics system (all of the computers and electronics in the rocket), and one day while we were hiking way up in the mountains, he convinced me to join the project. I've been working on it ever since—until last month, that is.

Last month was our launch date. I flew out from California to Utah and drove out into the barren desert near Green River, where there was a university rocket competition. The goal was to get as close as possible to 10,000 feet above ground level. At least, that's what the stated goal was. Our real goal was just to launch the thing. We had all spent lots of time (hundreds of hours for me) on the project, and we really wanted to see it fly.

Since I had to fly in, I showed up a little bit late. When I got there, everyone was really glad to see me, because there were some problems with the avionics system. Matt (the other avionics guy who was there) and I got things straightened out, and we did a dry run test of the launch. Things went almost flawlessly. It was too late in the day to attempt a launch at that point, so we were going to go first thing in the morning.

The next day we showed up, fastened down the final screws, and rounded up a big crew to lift the rocket from its support cart and slide it onto the launch rail. The plan was to slide it onto the rail, raise the rail so that the rocket was vertical, fill it with fuel, and then launch the rocket.

Reality turned out to be a little bit different. As we were sliding it onto the rail, someone smelled something funny. Then someone heard a hissing sound. We stopped sliding the rocket onto the rail, and Matt frantically unfastened one of the aluminum skins that covered the avionics system in the rocket. When he got it off, he found that the batteries were self-destructing, spraying electrolyte all over and getting really hot. He disconnected them (which wasn't an easy task, since the wires were all melting together at that point), and so the situation was under control.

After three years of work and 1000's of man-hours of work, we weren't too excited about the now very real possibility that we would have to scrub the launch. It was crunch time for me to determine if we could repair the system in a few hours.

The power supply system was almost completely destroyed, melted into one big blob of plastic and metal. A fuse was blown. A power connector on the data communication radio was melted into its socket. Things smelled funny. The batteries were completely destroyed. We were out in the middle of the desert without access to an electronics store. It wasn't looking good.

I determined the absolute minimum system that we would need to launch safely: a way to open the oxidizer (liquid fuel) system valve and a way to actuate the igniters.

We tried to find batteries to borrow from other teams. We soldered a new power connection onto the radio. We bypassed a lot of the power system. After all of that, though, we discovered that our main control circuit board was fried. There was no way to control anything without that.

As we considered our options, two ideas emerged: either "hot wire" the system directly to a couple of car batteries (borrowed from our vehicles) and launch the rocket essentially as missile with no way to deploy the parachute, or scrub the launch. We talked to our faculty adviser and debated for several minutes. Many of us were graduating, and this would be our last chance to see a launch. Our faculty adviser was moving on to another project, so things were losing steam. The arguments for just lighting the fuse and running were pretty persuasive. In the end, though, our adviser decided to not launch. That was the end of the road. We packed up and went home. We had seen several other schools launch their rockets, but our own launch just barely slipped through our collective fingers.

I feel really bad about the situation, because it was my system that failed. It failed, and I feel a bit like I failed. If my system had worked, all of the time that everyone spent on the project would have been culminated in a launch. It didn't work, though, so now there's a beautiful blue rocket sitting in a lab somewhere on BYU campus, waiting to hopefully fly another day.

I'm still not sure what happened. Obviously something shorted out the batteries, but what? And why? Why did our test the day before go almost perfectly, and then why did the system short when we were loading the rocket onto the rail? I'm going to do a postmortem in the fall when I get back to school, but we may never know.

The project may be "off" right now, but I'm hopeful that the big blue rocket will fly one day. Even if it doesn't, I've enjoyed working on it, and I've learned a lot from the project.

More pictures:

• Test of the launch rail at BYU
• Green River launch

Nerd pilgrimage

I'm a computer engineering student, and I'm living in Silicon Valley for the summer. That's sort of like being a kid and living at Disneyland, so I figured that I'd go one a couple of the "rides" while I'm here: a Don Knuth lecture, and a visit to the Computer History Museum.

Don Knuth Lecture

On Thursday I went to a Computer Musings lecture at Stanford given by computer scientist Don Knuth. Most of you reading this won't really appreciate who Knuth is, so let me help you out: if Knuth were a geneticist, he might be Charles Darwin; if he were a composer, he might be J.S. Bach. He has spent the last 50 years writing The Art of Computer Programming, which is the Bible of computer algorithms. He's the stuff that legends are made of. He's so good that he'll write you a check for $2.56 (one hexadecimal dollar) if you find an error in one of his books. He writes even larger checks (in values of powers of two, like any good computer scientist) to anyone who finds a bug in one of his programs. The checks are so rare that they usually end up in frames on people's walls rather than in their bank accounts.

Despite his towering stature among computer scientists, Dr. Knuth is a very friendly, down to earth person. Nothing about him gives off an aura of academic untouchability; rather, he looks like he would be right at home working on the farm with my grandpa—and he's about the same age, too. He spent the minutes before the lecture started mingling with the audience, asking people where they were from, and having conversations with many people that he knew. His interested in people impressed me. He made lots of wry jokes, and he's still clearly quite on top of his game, despite his age.

Computer science is a unique field, because many of the pioneers are still alive. Not many physicists have had the the opportunity to sit in a lecture by someone like James Clerk Maxwell, but I had that opportunity this week.

(Most of you probably don't care, but for the curious, the topic of Knuth's lecture was binary decision diagrams. BDDs are an interesting and often compact way to represent arbitrary boolean functions in a way that makes it efficient to solve many problems that were previously considered insoluble. If that sounds like gobbeldygook to you, try this: they're useful for making computer chips faster. We now return to your regularly scheduled blog post.)

Computer History Museum

Pilgrimage number two for the week was a visit to the Computer History Museum today. Located just down the road from Google, it is filled with thousands of "artifacts" (aren't artifacts supposed to be thousands-of-years-old objects from Egypt?) from all ages of computing. There were early models of supercomputers, mainframes, minicomputers, personal computers, calculators, and semiconductors. I saw some really cool things, including:

• An Interface Message Processor. It was one of the original nodes on the internet.
• A Xerox Alto. The Alto could be considered the first personal computer. It pioneered the ball mouse, the GUI desktop metaphor, and WYSIWYG layout.
• Several early supercomputers, including a Cray-1 supercomputer, which I'm pictured inside of at the top of this post.
  
• An IBM System/360, the first wildly commercially successful computer.

Even cooler than all of these, though, were demonstrations of a Babbage Difference Engine No. 2 and a PDP-1. The Difference Engine is a mechanical calculator (but not general-purpose computer) designed by Charles Babbage in the Victorian era of the 19th century. Due to funding problems, he never completed it, but the Science Museum in London recently built a complete replica, which I saw when I visited there last year.

The really cool thing about the Difference Engine that I saw today is that I saw it working! It computes polynomials, and it did, in fact, compute the correct answer. Even cooler, though, was watching it in motion. It's really pretty amazing. Here's a video of it performing a carry:



There was also a demonstration of one of the museum's PDP-1 computers today, which was even cooler because:

• It's the only working one in the world.
• It was demonstrated by some of the original hackers who worked on it. They were as much a part of the museum as the computer itself.
  

The PDP-1 was one of the first minicomputers, hitting the market 48 years ago. Of course, "mini" is relative. It was small compared to the behemoth mainframes and special-purpose computers of the day, but it's enormous compared to today's computers. DEC, the manufacturer, donated the second model to MIT, and MIT allowed undergraduates to use it late at night after all of the professors and grad students had gone home. Two of the men who demonstrated it today were some of those undergraduates.

Peter Samson wrote a musical synthesizer for the PDP-1. You can hear the synthesizer and listen to him talk about it here:



That, my friends, was the world's first iPod. :)

The man who wrote the world's first "shoot 'em up" video game was also there today. Steve Russell, a friend of Peter Samson, wrote Spacewar! in the 60's, and it provided lots of entertainment to early MIT hackers. I got to play the game today on the museum's original PDP-1. I don't even like to play video games very much, but that was really cool!

News coverage of our senior project

KSL, the local TV station, wrote up an article about our senior project last week. They also did a TV segment on it, which you can watch here:

(If the embedded video player doesn't work for you, try the watching the video on KSL's page.)

Robot obedience training

Over the weekend, Nick (one of my my senior project teammates) came in and worked on our robot for a few hours. Here are the results:



If you're interested in the technical details of how our robot works, take a look at our team web site.

My disobedient robot

My senior project this semester has been to build an autonomous robot racer with a team of four other people. Translated into English, that means that we take a remote control toy monster truck, stick a computer and camera on it, and make it drive around all by itself. It's been a lot of fun—and a lot of work. We had our final competition yesterday and fared horribly.

The goal of the project was to get our robot to use computer vision to drive a race course all by itself. The course was a bunch of orange and green pool noodles (we call them "pylons" to sound sophisticated) that were set up vertically and spaced out on the floor. Orange meant that the robot had to pass them on the right and then turn to the left; green meant the opposite. The robot was supposed to use its camera to find a noodle, drive to it, make a turn, and repeat until it had finished the course.

That was the idea, anyway. None of the five teams that competed in the project were completely successful. Our team fared the worst.

There are several components to a system that can autonomously control a racer:

• A color segmenter that can identify areas in the image that are the specific shade of green or orange that we're looking for.
• A feature extractor that can take those areas and identify the precise position of the pylon.
• A vision-guided control system that uses the data from the feature extractor to control the robot's steering and throttle to drive toward pylons.
• A dead reckoning control system that "drives blind" to control the robot while pylons are out of view.
• A "mission control" computer program that runs on a desktop computer that communicates wirelessly with the robot. This program doesn't control the robot; it's just used to monitor its state, fine-tune parameters, and send an emergency stop command if the robot gets out of control.
  

Our robot could (mostly) successfully drive toward pylons, but it had a really hard time correctly executing turns. We got it working a week ago on a simple two-pylon course, but that's about the most advanced thing it could do. It was pretty disobedient, and our competition yesterday was an embarrassment.

What went wrong? A lot of things. Most of it boils down to poor planning and a rushed schedule.

• We optimized prematurely. We tried to implement our feature extractor in hardware (VHDL) because we wanted it to run fast. Developing hardware is a lot trickier than developing software, and we spent three weeks trying to get it to work. We finally decided to cut our losses, and I wrote the object extractor in C and had it working in two hours. In hindsight, I should have written it in C to begin with, and only converted it to hardware if it was too slow. As it turns out, the software, running at 100MHz, was plenty fast enough to process images at the camera's full 35 fps frame rate.
  
• We added too much complexity too quickly. When we finally got our feature extractor working a couple of weeks ago, we tried to throw everything else into the pot all at once. When you add a lot of complexity all at the same time, it's hard to tell where to look when something doesn't work. Instead, we should have tested each feature independently. When we were confident that a feature was working by itself, we could add it to the rest of the system and make sure that it works when integrated. That way it's a lot easier to isolate problems.
  
• We didn't have a consistent schedule. With a semester-long project like this, it's easy to put it off and work on more pressing assignments for other classes. That hurt us in the long run, though. There were also several times when one person was assigned to complete an important part of the project by a certain day, and they didn't have it done. That then delayed everyone else who couldn't make progress until that part was in place.
  
• It was hard to work in parallel. We had only a single development computer, so only one or two people could work on the project at once. That wasn't an issue for most of the semester, but when it was crunch time, it would have been really helpful to have two or three workstations.
• Attitude. Most school project are very well-defined and self-contained. This project was different: it was very open ended, both in approach and schedule. This type of project requires more discipline and more creativity than typical school projects. It also requires a different attitude. When something doesn't work—and it seems that nothing works on the first try—you can either give up and say "I tried", or you can buckle down, try a different approach, do research, talk to others, and make things happen, even though the problem is hard. Some members of our team were better than others at taking the reins and making things happen. That's not mean to bash my team members, though; I feel like everyone contributed to meaningfully to the project.
  

I feel like with another day or two of work, we could have our racer driving courses pretty well. It's a shame that we didn't finish in time. However, I think that everyone on our team learned a lot, and the project was definitely worth doing. We accomplished in the last three weeks what took the other teams most of a semester to accomplish. I think that we have about 90% of the functionality of most other teams, but that last 10% is key to having a working robot.

I'm really happy with the work that everyone on our team did. I'm also really happy that I'll be able to get a little sleep again. :)