Wii Mouse Droids

Background

This is my first Arduino project. I had heard about them for a while and always wanted to play around with one but never really had any ideas on what to do with it. One day, during a discussion with a coworker, the idea of building little mouse droids modeled after the two in Family Guy: Blue Harvest came up. I decided this was a good enough idea to dive in and learn Arduino and get my feet wet in hobby electronics.

Goal

Primary

Build two model Mouse Droids. Both are to be RC, but when they come in close proximity to each other they autonomously reenact the mouse droid scene from Family Guy: Blue Harvest.

Secondary

Implement RC via Wii Remote.

Materials

Implementation

The Frame

mouse_droid_bottom

For the frame I used a prefabricated universal kit made by TAMIYA. Its basically a little plastic peg board and reminds me of something from an old erector set. It’s nice because, like an erector set, you can assemble pieces to it in many different ways without drilling or sawing. With it I was able to assemble a basic power train rather quickly by combining the wheels, motors, and motor mounts and screwing that right into the peg board. The unused holes proved convenient for running the wiring from the motor up to the top of the peg board to be connected to the motor driver later. Then I placed rubber bands around each pair of opposite-sided motors and mounts (as you can see in the picture to the right). This acts as a suspension system of sorts, and it helps when turning the droid as I’ll explain later on.

mouse_droid_standoffs

I used some nylon standoffs to fasten the motor driver board to the top of the peg board. The board only had two mounting holes on one side so I was worried about it breaking when driving later. To help with that I added one extra nylon standoff centered on the other side of the board that’s only fastened to the peg board. This just keeps the motor driver board from bending down towards the ground when it bounces around while driving.

In a similar way, I’ve fastened the Arduino, with it’s USB Host shield attached, to the frame. I used some little metal L brackets to fasten it vertically. This will be handy for when the outer shell, the body, is added later.

 

Wiring – Power Distribution

mouse_droid_switchI’m using a 7.4v 2-Cell LiPo battery to power each of the two droids. There are 3 breakout boards to power, two of them have a small 2-pin JST power socket, and the Arduino has a coaxial socket. So I need to split the power coming off the battery into 3 different directions. SparkFun sells 2-pin JST connectors with wires already attached, so I used two of those and then combined some of my own wire with a coaxial plug from RadioShack. All the positive leads were soldered onto one side of a rocker switch – so the whole thing can be turned off later – and all negative leads were soldered together. The battery has a JST RCY connector pre-attached so to couple that up with my distribution wires I soldered a Male JST RCY connector to some of my own wire, then soldered the positive lead to the other terminal of the rocker switch and the negative lead to the bundle of negative leads I already soldered together.

On my first run at this I didn’t have a rocker switch, I simply unplugged and plugged in the battery. This was not only inconvenient, but it led to extra wear on connectors and I eventually ended up with a broken solder joint. I couldn’t tell at first, it drove just fine, but the bumping was rapidly disconnecting and reconnecting power as the broken joint bounced around and I ended up blowing out the main power via on the motor driver board. Thankfully, it still worked if I used the JST connector instead of hard wiring into the power terminals. Lesson learned here was to make sure your solder joint is solid, use shrink wrap to reinforce, and secure the wires/joints to the frame better – avoiding as much movement as possible.

mouse_droid_motor_connectorNow that the boards are powered, the motors need to be connected to the driver so that they get power as desired. For this, I used a 4-pin polarized header. It’s sort of like the JST connector, but a bit larger and, of course, has four pins instead of two. The motor driver board has two channels each with a positive and negative through hole, I soldered the header onto these terminals. I’ll be using differential steering, like a tank steers, so one channel will control the two motors on the left and the two on the right are controlled by the second channel. There are 8 leads coming from the motors, 4 positive and 4 negative. The two positive leads coming from the left motors are both soldered into the pin of the female connector that lines up with the positive terminal for channel 1. Likewise the two negative leads for motors on the left are soldered into the female connector’s pin that lines up with negative on channel 1. Repeating this for the right side on channel 2.

 

Wiring – Communication

mouse_droid_comm_pinsThere are three boards in this build that need to communicate with each other. The motor driver board physically switches the motors on and off, but it doesn’t know when to do this. The sound-audio board decodes the audio files onboard it’s microSD card and plays them through the speaker connected to it, but again, it doesn’t know when to do this. Its the Arduino that acts as the brains of the droid, making decisions on what wheels to turn on or off, when to play a sound on the sound-audio board, and maintaining connection and communicating with the Wii remote.  So it needs to be connected to the motor driver and audio boards via serial connection.

mouse_droid_audio_boardI chose serial because it only uses two wires per connection and the Arduino doesn’t have very many pin-outs to work with, especially with the USB Host shield using the SPI bus which takes up 5 of those pins. This means I only need to use 4 pins on the Arduino for communication with the two boards. Both the audio and motor driver boards have through-hole serial terminals, so I just soldered a 2-pin polarized header onto the terminals of each board. Now the boards can be connected using simple breadboard jumper cables, connected as follows:

 

Audio CLK to Arduino Pin 5
Audio DI to Arduino Pin 6

Driver Rx to Arduino Pin 4
Driver Tx to Arduino Pin 7

 

Outer Shell

I built the “skin” out of LEGO. LEGO has a rather nice CAD program for building models on your computer, it even gives you a PDF instruction booklet on how to build it when you’ve finished – like the ones you’d get in a retail set. I have plenty of legos left over from when I was a kid so once I had a model CADed up I used what I had to build a mockup, eventually I’ll purchase new bricks so that it’s a more uniform color.

You can download the software here, it’s free.

Software

You can find all the code I’m using for the mouse droid here.

Third party repositories referenced:

The code, or Sketch, is made up of several classes. I’ll list out the classes with a short description below, then explain them in more detail further down:

  • MouseDroid (.ino) – Main loop, this ties the rest of the classes together to produce the work needed to oporate the droid
  • AudioDriver (.h .cpp) – Handles communication with the Audio-Sound Board
  • MotorDriver (.h .cpp) – Handles communication with the motor driver board
  • InterComm (.h .cpp) – Drives communication over an attached XBee radio (used for localization)
  • Max3421e (.h .cpp) – 3rd party library, drives the Max chip on the USB Host Shield
  • Usb (.h .cpp) – 3rd party library, facilitates the USB protocol over the Max chip
  • WiiRemote (.h .cpp) – Modified 3rd party library, facilitates the Blue Tooth protocol used by the Wii Remote
  • XBee (.h .cpp) – System library, facilitates the XBee wireless networking protocol
  • SoftwareSerial – System library, implements a serial connection on any two digital pins of the Arduino

 

AudioDriver

This was the most challenging code in the project so far, but the most fun. There was no library implementing the protocol used by the chip on the audio board, at least not at the time I purchased it, so I had to write my own. To issue commands to the chip you have to maintain a steady clock signal and transmit a byte of data over the digital in pin on every rise of the clock voltage.

MotorDriver

The motor driver board is really simple to work with. It accepts text commands over a serial connection. The commands are 3 character codes that tell the driver which channel to affect a change on, what direction to spin the motor, and how fast. The code works like this:

Char 1: Channel Number (1 or 2)
Char 2: Direction
Char 3: Speed Number (0 through 9, where 0 is stop and 9 is full speed)

i.e. “1F5” = run motors on channel 1 forward at half speed

I implemented two types of differential steering; tank-like where the wheels on one side spin in reverse of the other side, and by slowing down the speed of one side relative to the other. The tank-like steering is the most effective, the other style causes a very large turn radius. However the later allows you to turn while moving forward where as the tank-like steering requires you to stop and spin in place. At some point I may convert it to rack and pinion, but I’m keeping it simple for now.

InterComm

This bit of code is in there for use later. It will likely be the most complicated part of this build and I’m saving it for last. I want the bots to perform a little animatronic scene from a cartoon when they get within a certain proximity of each other. My thought is that I can use a XBee on each bot and estimate distance by a mixture of transmission speed and signal strength. When they are in range, the scene will play out automatically – which is where the audio comes in as well. There’s a scene in Family Guy: Blue Harvest where two mouse droids converse about meeting Chewbacca and it digresses into a conversation about Tyra Banks.

MouseDroid

This is what controls it all. This file houses the main loop for the Arduino sketch. The majority of the code in this file handles the Wii remote commands. The GetCommand_Wii_12YAx() monitors for button presses and sends commands to the motor driver as a result. As it’s coded up now the Wii buttons do the following:

Button 2: Forward
Button 1: Reverse
Button 1 + Button 2 + Rotate WiiMote Left: Spin Left
Button 1 + Button 2 + Rotate WiiMote Right: Spin Right
D Pad Left: Plays audio track 3
D Pad Right: Plays audio track 1 (You ain’t gonna believe what I just seen)
D Pad Down: Plays audio track 2
D Pad Up: Plays audio track 4
Minus Button: Plays audio track 0 (music)

References

 

Videos

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *