This project was an exploration of engineering and embedded programming. The robot itself (pictured below) is a differential-drive, tracked vehicle controlled by remote. Both the robot and the remote are each controlled with a Pololu WixelOpens in new window. Even if upside-down, the robot will always drive in the proper direction.

The Flipbot and its remote

The Flipbot is mostly made from left over parts. The chassis itself and the remote control are built from plastic enclosures, which involved a bit of cutting and drilling. Since the Wixel libraries don't come with much robotic control firmware (such as PWM output), we had to write our own. This is really good practice for those wanting to learn robotics or self-torture.

How It Works

Wixels were used for the robot controller and remote because they contain radio transceivers. My previous robotics projects used Wixels only as serial-radio bridges, but with a little bit of effort, we could eliminate the middle man. A tiny bit of embedded programming wasn't going to frighten us (much), so we took on the task. Below is a schematic of the Flipbot build.

Wiring schematic for the Flipbot

An accelerometer is used to detect the pull of gravity relative to the robot's orientation. Therefore, if the robot is upside down, the z-axis sensor will detect an upwards force, instead of a downwards one. If the robot is upside down, it internally reverses the direction of the radioed y-axis of the joystick, causing it to drive in the proper direction.

Motor control is done using Timer 3 on the Wixel. An interrupt service routine for this timer is used to generate PWM duty cycles to move the motors. The interested reader is directed to the datasheet for the CC2511F32Opens in new window, upon which the Wixel is based. (Warning: it's a fairly technical read if you've never read a datasheet or done embedded programming before.) Motor movement is directed by a software PWM that sets the outputs of four pins on the Wixel, which are used as inputs to the motor driver. If you're not familiar with PWM duty cycles, the Wikipedia entry on this topicOpens in new window, especially the animation, explains this simple concept very well.

Unfortunately, when the motors are running, they generate electrical noise. This is common for many electronic devices, especially brushed DC motors. This had the unfortunate side effect of seriously messing up our accelerometer readings - so much so that the robot would jitter back and forth while moving, due to the robot occasionally thinking that it was upside down. Our solution to this problem was two-fold. First, we soldered one 0.1μF capacitor to each motor. Then, we altered the robot's firmware to only re-adjust the motor directions if the robot consistently reads itself at a particular orientation for a certain number of consecutive frames. This solution worked perfectly.

Note: it can be difficult to decode the markings on various ceramic capacitors to determine their type. There is a pretty good site hereOpens in new window that lists common markings and how to read them.

Parts List

For the robot:

  • 1 x rechargeable 3.7 NiMH cell
  • 1 x plastic enclosure
  • 1 x Pololu Wixel
  • 1 x small perfboard
  • 1 x DR8833 motor driver
  • 1 x MMA7361L 3-axis accelerometer (only one axis is actually used)
  • 1 x 4-wheel and track set
  • 2 x high-power gear motors
  • 2 x 0.1μF ceramic capacitors (symbol on the capacitor: 104)
  • 1 x mini switch

For the remote:

  • 1 x 4LR44 6v battery
  • 1 x plastic enclosure
  • 1 x Pololu Wixel
  • 1 x small perfboard
  • 1 x toggle switch
  • 1 x thumb joystick
  • 1 x 5mm LED

Firmware source code for the Flipbot and its remote is available in the downloads section. If you're interested in learning more about the Flipbot or feel we've left something out, please feel free to email me.