When I was little, I was fascinated by what I now know are the break lights that are in the rear window of most cars.  When it was nighttime and we came to a stoplight, I noticed how even though I couldn’t see that the stoplight itself was red, there was a correlation between the stoplight being red and the red light in the rear window of the car in front of us.  I wondered by what mechanism the car in front of us knew that the light was red, and thought that it was very useful for cars to relay that information to the cars behind them.

I know now that the key element in making that happen was the driver tapping on the breaks, and in fact the light didn’t signify anything directly about any stop light, just that the driver had his foot on the break pedal.  Even so, I have always been interested in what makes technology tick, and (even more) how to design something that has some kind of interactivity or pseudo intelligence.  To me, code is a form of magic—now hear me out!

When I write a program, I pull the words out of nowhere.  I can take an idea, describe how a program should behave, and it will simply happen.  I said that this was like magic, but now let me step back a bit.  To me code lets me perform a kind of magic that applies to the virtual world rather than the physical, with a bit of crossover via different kinds of human-computer interaction.  The kind of magic that code can accomplish applies to information rather than physical objects.  For example, the idea of someone seeing something and capturing that moment to be displayed on a picture frame in his grandparents’ house is whimsical at least—without any explanation anyway.  However, with a digital camera, an Eye-Fi wireless SD card, and an appropriate digital picture frame, one could take a picture, the Eye-Fi could find an open wifi hotspot, connect to Flickr, and upload the picture for the digital picture frame to download and display.

Did you just yawn there?  Most people would, but that’s kind of the point.  Technology can accomplish amazing things—the sky is hardly the limit.  When dreaming up an idea, it isn’t always important to have it seem realistic at first.  Furthermore, no matter how cool the demo, the actual magic will come down to bits and bytes… but that’s great!  To me, in creating software, the biggest barriers are knowledge, skill, and time.  With those three things one person could create a software product that works better than a similar product by a big company.  Two identical pieces of hardware could be made vastly different with different software.  Firmware updates for portable devices are a good example of this, as are videos games for any given console.  On a console, every development team has the same canvas to work with, and it is amazing to see the wildly varied experiences that different games can create.

I’ve always been facinated by this stuff, and always will be.  That’s great for me, though, because it’s an inexpensive hobby and a well-paying profession.  Ah, I think I’ll write a bit of code right now.

Here’s the Soapbox video:

My goal was to have a generic robot with a camera on it that all of the club members could write code for.  First the task was to make the robot bounce around in an arena marked off with red tape, then the goal was to make the robot follow a line (curvy, with sharp edges, with dead ends, whatever), then it was to make the robot solve a maze.  It was a lot of fun, and a great learning experience.

One look at the robot shows that I definitely care about software way more than hardware.

 

It may not look like much, but surely you know that personality is more important than appearance, and besides this little guy has spunk.  If I were to continue this project, though, the next step would be to make him less fat.

Here’s the maze.  In theory the robot can solve any maze of this style.  (Yes, the end of the maze is a mouse pad. )

Here is the robot solving the maze.  Keep in mind that the robot can be placed in any part of the maze with the end anywhere else in the maze.�

I found by experimentation that the longest time it can take the robot to solve this maze, given any start and any end, is 1 minute and 54 seconds.

If there’s one bit of advice that I think new Botball members need to know, it’s to be patient.  The first version of my maze-solving code was really just code that made the robot follow lines.  A later version would only solve a maze if it never encountered a dead end, and there’s always the version of the code that makes the robot flail about sporadically.  So be patient, and don’t try to tackle the whole project at once.  Get little pieces to work, and use that to build off of.  I in no way assert to be the authority on robotics, but I have learned a thing or two.

Oh, also precise names.  Don’t go calling methods “dog” or “cat”.

Download the code here.

Here I made a video explaining in general terms how the robot stays on track when following a wall:

So you may want the code to mess around with, and if you do then you’re in luck!  Not only is there a link to download the code at the bottom of this post, but I also recorded two videos of me explaining it, or attempting to anyway.   Warning: It may be a little boring!

In this video I explain the defines, whose values you can change to make the robot behave differently:

In this video I explain how the rest of the code works:

(Note:  I found an error in the deadEndInSight method.  I fixed it incorrectly on video, but it should be right in the download below.)