Twitch - Control
Like all vehicles, Twitch needed a system to deliver instructions from the driver to the various actuators on the robot. Here's a quick overview of what I came up with.
The chain of command works like this: the driver inputs commands into a gamepad. An XBee unit reads these commands and transmits them wirelessly to another XBee on the robot, which sends them to the Arduino via its serial communications hardware. The Arduino interprets these commands, then sends the appropriate signal to a motor controller (via it's built-in serial protocol) or to a servo. Let's start at the beginning.
It's pretty tough to beat a joystick for driving a robot. I wanted a controller that felt nice in my hands and didn't need to be tethered to a computer, so I decided to mod a cheap USB gamepad I picked up from Amazon. If I didn't mind being tethered to a computer I could just plug it in and write some script to relay its commands to an XBee, but where's the fun in that? So I popped off the case and started probing around the circuit board, looking for the leads connected to the potentiometers and buttons. After some careful soldering I was on my way.
A great feature of the XBee (that I didn't know about before starting) is it's ability to act as a standalone polling station. By placing the XBee in API mode, it can read about a dozen digital or analog inputs and transmit them periodically. As a result I didn't need another microcontroller on the gamepad, though I did need this Sparkfun breakout board to get access to the pins and to regulate the gamepad's 5V supply down to the 3.3V the XBee requires.
The data package sent by the standalone XBee follows a pattern detailed in their documentation. For my application, the package looks like this:
The XBee on board the robot reads these packages and relays them to the Arduino serial hardware. Most of the package can be discarded, but I do use the signal strength byte as a safety measure. If I drive the robot outside the range out the XBee it will just keep going, which is pretty hazardous. To prevent this I set a threshold for signal strength a little above the maximum range of the XBees, so if and when a package comes in below that floor the Arduino kills all power to the motors and then enters an infinite loop.
Once the Arduino parses the XBee package, it's time to send commands to the actuators. The Pololu TReX Dual Motor Controllers can take either commands though analog or a serial protocol. Serial commands are a nicer option since you can set speeds, accelerations, set current limits, query the motors, and use all the other features that separate a $100 controller from a $5 H-Bridge.
The Arduino Uno has one hardware serial port, which is already in use by the XBee, but it can emulate more using the SoftwareSerial.h library. If you try to use this library alongside the Servo.h library, you'll run into a nasty bug! During certain functions in SoftwareSerial.h, timers on the microcontroller are disabled. Now the signal that drives a Servo motor is a periodic pulse, where the length of the pulse dictates the target angle of the servo. Unfortunately, the Servo.h library uses timers to generate that pulse, so when you try to use the two together your servos turn into a jittery mess. More on the conflict. The problem, once diagnosed, is easily fixed by switching to the PWMServo.h library.