Building Bots With Kids

One of my posts back in late November was about the Arduino open source microcontroller platform. In that article I mentioned that my 8 year old son, Nakoa, and I were embarking on a little father/son electronics exploration. Not long after I wrote that, he and I went to see the IMAX presentation "Roving Mars" which was a nice documentary on the Mars Rover work at JPL. We started talking robots...not the Jetson's Rosie-the-maid kind that would clean up your room for you, though I'm sure Nakoa wouldn't mind one of those either, but real rovers. We had a compelling need to build something that would move. Stormy recently told me of a friend of hers who did some work with kids and robots and blogged it on radar.oreilly.com. Both that article and mine were influenced by a Salon article "Why Johnny Can't Code." (the lament that no simple BASIC interpreter came built-in to any modern machines.) For whatever reason, the natural response of many of us is to start getting kids connected again through tangible, kinesthetic activities. We believe if we can "make it real" for them, we'll help them touch what we've touched. Developing software, designing anything that doesn't yet exist, is a true mind-body experience. Our particular project was to build a simple rover from scratch. Below is Nakoa with one of the two bots we're making - we've already named them Click and Clack. Since Click comes before Clack, this pic is Nakoa with Click right before we took him for his maiden stroll. (Clack is still on the drawing board but is shaping up like a Caterpillar tractor - likely a snow-cat given the weather we've had this winter. ) Click is a wireless, battery powered, two-wheeled bot with a wheelie-castor. To build Click, we used a lot of different components, but the main ones were:

• Arduino for the microcontroller
• Tamiya dual motor gearbox
• Pololu motor controller
• XBee Pro - (ZigBee) 2.4 GHz wireless comms

The picture below is Click splayed out on the workbench under test, but all working with wireless comm: The Arduino microcontroller has a TTL level serial port that we use to talk to the motor controller. The motor controller can drive each gearbox motor independently so we can turn the rover in-place. Only the transmit part of the Arduino serial port was used to talk to the motor controller which left the receive port open for us to pipe commands to it over the XBee data radio. To control it we came up with a simple command structure which was something like: [direction][speed] where direction was a numeral:

• 1 - forward (both motors forward)
• 2 - left
• 3 - right
• 4 - backup (both motors backward)
• 5 - stop

The speed was given by a letter between a and g which divvied up the 127 motor speeds we could use into reasonable graduations without being too granular. So, a typical command sequence might be:

• 1f
• 2c
• 5a

To send these commands, we hooked up another XBee data radio to the USB port of a laptop and fired up a raw terminal emulator on that port (at 9600 baud.) In effect, using XBee, we had a very simple, very reliable wireless serial "virtual cable" with which to control Click. Below is Nakoa, the rover driver with the laptop command center: After having seen the "Roving Mars" flick, he really fancied himself as a JPL rover driver. Towards the end of the project when we had to start bolting it all together, it was clear the Arduino board was going to be too large, but I had the Arduino Mini stamp sized version in the wings for this occasion. So, we tore down the circuits and rewired it with a smaller Arduino chip on a breadboard that could be shared with the motor controller. The Mini and the full-sized Arduino are electrically compatible, as is the firmware. The main difference is the mini is built on an AVR microcontroller that has more memory. Anyway, a few observations around the experience and I'll wrap this up:

• Nakoa and I talked through all the logic and in the process he learned some simple C syntax for if/then statements and loops. Yes, I helped a lot, but I always made sure he thought through it before we took the next step. I would guide him but it was through a socratic, questioning mode.
  For example, we had the motor controller connected to the gearbox motors on the bench. We had to implement the turning code. It's not immediately obvious to an 8 year old that in order to turn left, you would have to make the right wheel turn and left wheel stop (or go backwards.) After it dawned on him what would need to happen, we'd code it up together.

   

• This kind of project is probably not for every 8 year old, but it's definitely within the grasp of some as long as there's some close guidance. Kids that young really can learn the logic of programming I have no doubt.
• Nakoa's already chomping at the bit to get me to help him write software that can use cursor keys to send the commands instead of having to type the encoding. He's already on the software rev cycle of constant improvement. That's one of the most addictive things about coding. In many ways, coders are like gamblers. Just one more pull of that one-armed bandit == "Just one more compile and I know it'll work."
• This is a more difficult approach than going the Lego Mindstorms route. The Mindstorms approach is going to provide much the same learning experiences w/r to thinking through navigation and control problems. It's a more packaged, streamlined way to get where we eventually got, that's for sure. Our approach was a lot more like jumping off the cliff and hoping the parachute pops (it should, you just don't know if it will.)
  The unpackaged approach will take longer to get something rolling, but it's also a much deeper learning exercise if you have the time. Consequently, there's a lot more to get out of it.... particularly understanding:
  • mechanics (we built the gearbox and had to sort out some issues with friction and chatter)
  • motors (back EMF can kill stuff)
  • electronics (don't forget to fry a few things along the way - everyone loves the magic blue smoke)
  • batteries (what voltage, regulation, duration?)
  • connectors (we found R/C stores a gold mine for the connectors we used.)
  All these things are a big part of making it happen. So, also, is getting help from a community. There were guys on the Sparkfun forum who really helped me out when I got into a pickle. We all had a good time working it out online, much of it during the Christmas blizzard.

  Along those lines I was surprised at the amount of attention Nakoa was able to devote. That was when things were going good. When things didn't work quite right, well, that's the mind-share challenge.

  There was a point early on with the motor controller when every time we'd start to drive the motor, the motor controller would go belly up. After about 20 minutes of watching his dad mumbling over that problem, he declared "Dad, I'm losing focus" which were his code-words for "Dad, you're bum-fuzzled and I'm bored - fix it and ping me when you're done."

  
  Between the IMAX vid and this project he clearly understands that things won't just work the first time. And that's just a huge life lesson when you get right down to it.

Here's the code we wrote to control Click. It compiles and loads through the Arduino IDE. The code reads commands from the XBee data radio through the Arduino receive serial port and sends motor commands to the Pololu motor controller through the Arduino transmit serial port.

Here's the link to the full gallery documenting our rover project to build Click. Maybe later this spring we'll get Clack built and it will be a caterpillar (with snow plow) we can plow our driveway with it while we're inside sipping hot chocolate.

Follow @openlogic
Follow @OSCloudServices

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.