I built a remote-controlled robotics platform using a 4WD mobile platform, an Arduino (Seeeduino Mega), an Adafruit motor shield, and two XBee radios for communication. There are also some super-bright white LEDs on the front for headlights. The point of the project was to show how an XBee radio can be used to send joystick sensor data without using a microcontroller on the remote.
The vehicle is very easy to control using a joystick and a couple of buttons to control the lights. First I’ll describe how the remote control unit works, then I’ll show how the vehicle was built.
The Remote
Here’s a picture of the remote control unit that I built on a breadboard. A Parallax joystick is used to control the vehicle, one button turns the headlights on/off, and another button puts the headlights in “scanner” mode, you know, like Kitt or like a cylon. The radio requires a 3.3V supply, but the analog pins cannot take more than 1.2V, so I used some precision resistors to form a voltage divider so that the analog input voltage was stepped down to less than 1.2V. Also note that the joystick is rotated 90 degrees so that it worked on a breadboard with this orientation.
To make this work, one radio needs to be running the “coordinator” firmware, and the other running the “router” firmware. In this project, the coordinator is on the vehicle and the router is on the remote control, but it should not really manot the AT/transparent firmware.
I used the X-CTU tool from Digi to write the appropriate firmware to the radios and configure them. If you have not done this before, this is not a good project to start with. It is best to start with 2 radios that you already have working together using the API firmware.
The XBee on the remote control unit is configured to send analog/digital sample packets every 100ms. Pins AD1 (pin 19) and AD2 (pin 18) are configured as analog inputs and are connected to the potentiometers in the joystick. Pins DIO3 (pin 17) and DIO4 (pin 11) are configured as digital inputs for the two buttons on the remote that control the lights on the vehicle. Here is a list of the configuration parameters that were set on the remote radio:
AD1/DIO1 = 2 (configured as analog input)
AD2/DIO2 = 2 (configured as analog input)
AD3/DIO3 = 3 (configured as digital input)
DIO4 = 3 (configured as digital input)
IR = 0×64 (sample rate set to 100ms)
PR = 0x1FFF (all pullup resistors enabled — this is the default)
This is a schematic of the remote control unit:
The Vehicle
The wiring for the vehicle is fairly simple. Inside the 4WD platform are 5 AA batteries for powering the motors, and a 9V battery for the Arduino. I’m using a Seeeduino Mega because that’s what I had handy but any Arduino will work. The Adafruit motor shield is connected to the 4 DC motors inside the chassis. I used the 3.3V power supply on hte Arduino to power the XBee radio. The TX/RX lines of the radio are connected to the RX/TX pins on the Arduino. There’s a ribbon cable connecting 4 output pins to the LED headlights, and a ground wire running to the headlight assembly. Here is the bottom of the headlight assembly. These are 100 ohm resistors to keep the current draw below 20mA per LED.
The Software
This code depends on the Adafruit library for using the motor shield, so download that and install it as an Arduino library. The Arduino sketch for this vehicle RobotVehicle.zip can be downloaded from here. Read the code for an explanation of how it works. The basic idea is to decode the incoming XBee API packets and map the joystick position information to the motor speeds. If the joystick is forward, all four wheels move forward. If the joystick is turned slightly to one corner, then the vehicle will move along an arc. If the joystick is hard left or right, then the wheels on the left side and right side will turn in opposite directions, causing the vehicle to rotate in place. By studying the code carefully, you should be able to understand how all of it works. Enjoy!
All of the hardware and software setup details are below, but before I explain how it works, let’s see it in action:
How It Works
This is not a beginner project, so if you don’t have experience doing any Android development, you’ll need to be patient. Just getting your Eclipse development environment set up for Android development with the OpenCV and IOIO libraries took me a couple of hours, and I’ve been using Eclipse for about 10 years.
An Android app running on the phone captures video frames and processes them down to a lower resolution suitable for the 16×32 LED matrix. OpenCV is a powerful computer vision/image processing library, and there’s a version that runs on Android. I used the OpenCV library to convert the video frames to 16×32 pixel resolution to match the LED matrix. I also constrained the color space of the frames to 12 bit color. That is, each pixel has 4 bits each for red, green, and blue. That means that each pixel can have 16 different brightness levels of red/green/blue, yielding 4096 possible colors. In other words, all of the image processing is performed on the phone because it’s much more powerful than the Arduino.
The 16×32 12-bit image uses 1024 bytes of memory on the phone (2 bytes per pixel). The Android then uses the IOIO library to write this data out one of the IOIO board’s serial ports. Each frame starts with a two-byte frame marker 0xF0 0×00, then the bytes for the pixel values are written. The performance bottleneck is between the phone and the IOIO board. I can only write about 4 frames per second, even though the serial interface between the IOIO and Arduino is 115200 baud. Since each pixel really only needs 1.5 bytes instead of 2, I could pack the pixel data tighter to get perhaps one more frame per second, but didn’t think it was worth the trouble.
The green wire in the picture below is a serial connection from the IOIO and Arduino. The Arduino code simply reads the pixel values, using the frame marker to know when a new frame begins. The pixel values are written to the LED matrix panel using the Adafruit library for controlling the panel. Driving this matrix is no small feat for the Arduino, since the matrix panel does not do any PWM on its own; the Arduino needs to generate the PWM. This matrix driver software could have been written for the IOIO to control the matrix directly without an Arduino, but Adafruit had really tuned this library for high-performance and very precise timing, so I thought I’d better stay with the Arduino code for now. The result is video at about 4 frames per second. Not very fast, but the color rendition is pretty good.
Hardware Setup
The RGB matrix panel is wired to the Arduino just as Adafruit’s instructions describe. They have an excellent page that describes how the panel works and how to use it.
The RGB matrix and the Arduino are powered by a 5V regulated power supply that can provide 2A (also from Adafruit). The IOIO board is powered independently by a 9V supply that can provide 1A. It’s important to provide plenty of current to the IOIO board so that the phone can charge, however you can adjust a potentiometer on the IOIO to reduce the charging current. As with any project with multiple power supplies, all the grounds must be connected. A single green wire provides the serial data feed from the IOIO to the Arduino RX pin.
I used a diffuser in front of the display to make it look much better. Without a diffuser, the LEDs are simply blinding and it’s not easy to see any image. My diffuser is a piece of acrylic with paper vellum on it. The diffuser is held about 5mm in front of the LED panel (with a little roll of duct tape as a spacer).
The phone (a Samsung Nexus S) is connected to the IOIO via USB. I mounted above the panel by holding it very gently with a Panavise.
Software Setup
Android + IOIO + OpenCV Software
The hardest part of the software setup is preparing your development environment for Android, IOIO, and OpenCV development. The details of how to do this are beyond the scope of this article, but all of the steps are documented in various places.
Set up your Android development environment: this is documented on the Android SDK website. After you have performed this step, you will be able to write simple Android programs and run them on your phone.
Install the IOIO library: see this great Sparkfun tutorial which describes how to run Android apps that communicate with a connected IOIO board. After you have performed this step, you will be able to upload the HelloIOIO app to your phone and have it communicate with your IOIO board. Don’t move on to the next step until you are sure you have the IOIO working with your phone.
Install the OpenCV library for Android by following these instructions. After successfully doing this, you should be able to run the OpenCV Android examples on your Android phone. Don’t proceed until you have this working successfully.
Now that you have all the supporting libraries in place, download the RGBMatrixDriver Android application project and install it in your Eclipse workspace and open it. With luck, it will compile cleanly. If not, make sure that the project is correctly pointing to the IOIO and OpenCV libraries as in the image below.
You may need to customize the code a bit. I used IOIO pin 7 to send serial data to the Arduino, so you may need to change the pins specified in the call to openUart in RGBMatrixActivity.java. You may also need to change some screen dimensions specified in RGBMatrixView.java to work with your phone — just follow the comments.
Once you have the application running on your phone, this is what it looks like in action. The video image is displayed with the same resolution and colors as the RGB matrix.
Arduino Software
Now that the hard part is done, it’s easy to get the Arduino software installed.
First, you’ll need Adafruit’s library for driving the panel. It’s available here. Install it in your Arduino sketchbook libraries folder just like any other library.
Then download and install the RGBMatrixSerial sketch and install it in your Arduino sketchbook. Compile it and upload it onto your Arduino. The sketch is so simple, I’ll show the whole thing here:
#include "RGBmatrixPanel.h"
#define A A0
#define B A1
#define C A2
#define CLK 8
#define LAT A3
#define OE 9
#define WIDTH 32
int count = 0;
byte currentByte = 0;
byte lastByte = 0;
uint16_t color;
RGBmatrixPanel matrix(A, B, C, CLK, LAT, OE, true);
void setup()
{
Serial.begin(115200);
matrix.begin();
}
void loop() {
int index;
while (Serial.available()) {
lastByte = currentByte;
currentByte = Serial.read();
// Look for the frame marker 0xF000
if ((lastByte == 0xF0) && (currentByte == 0x00)) {
count = 0;
matrix.swapBuffers(false);
} else {
if ((count % 2) == 1) {
color = (lastByte << 8) | currentByte;
index = (count-1)/2;
matrix.drawPixel(index % WIDTH, index / WIDTH, color);
}
count++;
}
}
}
Future Ideas
increase the framerate a bit by packing 2 pixels in 3 bytes of transmitted data (only really need 1.5 bytes per pixel), but need different frame marker detection.
I recently got a chipKIT Uno32 prototyping platform from Newark so I could take it for a spin. Newark is the US distribution arm of Farnell and they carry both the chipKIT Uno32 and the chipKIT Max32.
Nice looking board!
The chipKIT boards are manufactured by Diligent and claim compatibility with Arduino boards. The Uno32 is similar to the Arduino Uno, and the chipKIT Max32 is similar to the Arduino Mega, but they are both based on Microchip PIC32 microcontrollers. The Uno32 that I have has a PIC32MX320F128H microcontroller.
There are plenty of powerful features of the Uno32 that make it compelling, especially when comparing to the Arduino. There are 42 I/O pins, which is nice. The clock speed is 80MHz versus 16MHz on the Arduino. For most hobbyists this won’t matter much; I have not often found CPU speed to be a limiting factor in projects. There’s more Flash memory to store your programs: 128K versus Arduino 32K. Again, I have never felt limited by the size of a program. In fact, the largest Arduino program I’ve written is a full-featured implementation of Asteroids and this only took 28K of Flash memory for the program.
But when it comes to SRAM, the memory that you use in your programs to store data structures, buffers, stack, etc, the chipKIT Uno32 has 16K versus 2K on the Arduino. This is a vast improvement for me. I’ve done a lot of video work with the Arduino (e.g. the Video Experimenter shield, Hackvision game system, etc.) and the size of SRAM is a significant barrier to video frame storage.
There are also 2 UARTs used for serial communication, versus the 1 on Arduino. When using Arduino, if you want to communicate with two serial devices at once (for example, the Serial Monitor on your computer and a GPS module), you had to use a software implementation of serial communication for one of the devices. But with 2 UARTs, the chipKIT Uno32 allows 2 independent hardware implementations. I like that a lot. There’s also a realtime clock and calendar (RTCC) on the PIC32MX320F128H microcontroller with the option of connecting a 32.768KHz clock crystal. That could be useful for some projects.
Make sure you check out the Hackaday article where they did an in-depth review of these boards from a performance perspective.
But what I was really interested in understanding is Diligent’s claim that the chipKIT boards are “Arduino Compatible”. What does this mean in practical terms for the hobbyist?
Compatibility: The Good News
Well, you can program the Uno32 using the normal Arduino API, like digitalWrite, digitalRead, analogRead, etc. For most hobbyists, this will allow them to read sensors, light LEDs, control motors, and the like. Maybe you need lots of digital outputs — the Uno32 has 42 pins instead of 19 on the ordinary Arduino. The Uno32 is a lot cheaper than the Arduino Mega.
So, the normal Arduino API works, but what about direct access to ports in order to more efficiently control digital I/O? I often use direct manipulation of the AVR microcontroller ports instead of using digitalWrite and digitalRead calls. That is, I set a digital pin HIGH with something like PORTB |= 0×2 instead (for speed). Will this code work with the chipKIT boards? Yes! I was surprised, but apparently the chipKIT compiler makes the appropriate adjustments to the resulting compiled code to allow direct port manipulation using the AVR semantics.
Compatibility: The Bad News
Here are some things that I think are bad news with regard to Arduino compatibility.
Outputs are 3.3V — This means that the output voltage of the digital pins isn’t high enough to be recognized as an input HIGH voltage by many 5V CMOS chips. For example, you can’t use the digital outputs on chipKIT boards to drive a 74HC595 shift register. The 3.3V output is not high enough to trigger the input pins on CMOS chips which generally require at least 3.5V. This problem can be address by adding more components to your circuits (e.g. a transistor to translate to a higher input voltage), but that defeats the purpose of convenient Arduino shields.
Current limitations — On the Arduino, each digital pin can source/sink up to 40mA as an absolute maximum, but in practice you should limit to 20mA. However, the chipKIT boards have a maximum of +/-18mA per pin, and the reference manual states that this should be limited to +7/-12mA per pin. This is going to be a disappointment to people wanting to drive LEDs, 7-segment displays, etc. Furthermore, the maximum current that can be sourced/sunk across ALL I/O pins simultaneously is only 200mA. That’s not much current to spread across 42 pins! I tried to light a bright blue LED and was only able to draw a dim 8mA (with no current limiting resistor at all!) because the forward voltage of the LED is just barely over the 3.3V board output voltage. Again, this can be solved with external circuitry, but that’s not convenient.
Code rewrites — If your Arduino code accesses AVR registers directly (for example to use timers) or involves AVR assembly, you are going to have to rewrite it. This means that using my Video Experimenter on the chipKIT board would b e a total rewrite of the gnarly AVR assembly.
Incompatible pin assignments — If you use special microcontroller functions found on the AVR, you will not find them on the same pins on the chipKIT boards. For example, my Video Experimenter shield utilizes the analog comparator function to compare the voltage of a video signal with a reference voltage. The analog comparator pin is D6 on the Arduino, but is D11 on the chipKIT Uno32. This is another barrier to using Arduino shields on the chipKIT boards. The pins don’t have the same functions.
Bottom Line
The chipKIT Uno32 is a nice board and will give many Arduino users a boost in speed and in the number of pins available. Users doing more sophisticated things that involve direct AVR register access, timers, and libraries written in AVR assembly won’t be able to simply switch to the chipKIT for their work without a lot of rewriting. Most disappointing to me is that many Arduino shields simply aren’t going to work on the chipKIT. And due to the 3.3V output, even projects using LEDs (the bread-and-butter of the Arduino world!) may have some challenges due to current limitations and the lower voltage available to light up all those blinky lights. Nonetheless, I welcome Microchip and Diligent’s efforts and hope to see some great chipKIT projects in the future!
This may look like a dangerous device, but it’s really just an ordinary alarm clock — with a twist.
I thought it would be fun to build an alarm clock that looks just like the type of bomb that we always see in Hollywood movies. I certainly don’t know anything about how a real bomb might look, but in the movies they always have sticks of dynamite strapped together, a red digital readout, and a bunch of curly wires. Instead of just building an ordinary clock, I thought it should have a detonation sequence with a scary countdown just like in the movies. And why not make it “defusable” so I an try to stop the countdown by cutting the correct wire?
The Defusable Clock is a fully-functional alarm clock just like you’d expect (a normal beeping alarm, snooze alarm, etc.). But at any time you can press the big red button to start a scary countdown sequence exactly like bombs in Hollywood movies. There are 4 wires across the top of the clock. You have 10 seconds to choose the correct wire to cut: one wire stops the countdown and saves the day, two have no effect, and one will “detonate” the device immediately. These role of each wire is randomly assigned when the detonate button is pressed, so it’s a new challenge every time. Also, the wires are attached with screw terminals, so you can replace them easily. If you don’t want to actually cut the wires, you can just pull them out of the screw terminals if you keep the screws a little loose.
The microcontroller is an ATmega328 with the Arduino bootloader, so this clock is programmable with the Arduino IDE. The ATmega328 is certainly more powerful than needed for a clock, but this device has lots of inputs/outputs, and ATmega328 chips are now about the same price as the older ATmega168. It keeps very accurate time and requires a simple 9V “wall wart” power adapter. A special alarm mode lets you even use the countdown sequence as the alarm and require it to be defused when you wake up in the morning. What a stressful way to start the day!
We are going to offer this as an electronics kit later this fall. Only the electronics will be in the kit — nothing that looks like dangerous explosives! With some imagination, I’m sure you can make a great looking Defusable Clock for yourself, but don’t go scaring anyone with it, and don’t bring it anywhere near an airport, ok? The product page will have plenty of warnings not to use this kit for any evil purposes or get into trouble with your school, employer, or local law enforcement! There will also be a picture gallery where you can submit a picture of your clock after you build it.
I’m sure some of you will have some ideas and comments, so please leave them below. Keep in mind that this is no more dangerous than any other alarm clock, and yes, we have already spoken to a lawyer about all of this.
Here’s one more version I made using clay for plastic explosives:
Clay used to simulate C4
Published by Michael, on September 5th, 2011 at 7:06 am. Filed under: Arduino,Art. | 68 Comments |
One of the coolest things you can do with the nootropic design Video Experimenter shield for Arduino is decode the closed caption data embedded in NTSC (North American) television broadcasts. I figured out how to do this and documented it in a another project, so if you want to understand all the details of how to capture and decode closed captions, refer to that project. With this project, I take it a step further and show how the spoken dialog embedded in a television show can be visualized on a computer in a “cloud” of words. This is the same type of cloud (often called a “tag cloud”) that you see on blogs, where the frequency of a particular word is reflected in the size of the word. More frequent == larger word.
Hardware Setup
First, here’s how the hardware is set up. It’s really simple. The Video Experimenter needs a composite video feed from a TV tuner like a DVR (e.g. Tivo) or VCR. You can also use a DVD player because DVDs usually have closed captioning data. The USB cable connects to your computer where you run a Processing sketch (program) to visualize the words as they are decoded by the Arduino. The Processing sketch dynamically builds the TV cloud as the words are extracted from the closed caption stream!
Hardware setup
Demo Video
Here’s a video where I show a TV cloud of spoken dialog being created dynamically. I superimposed a video of the television broadcast so you can correlate the broadcast with the Processing application, but note that the Processing application doesn’t acutally display the video. Words spoken with higher frequency are larger.
Example TV Clouds
I always have noticed that whenever I happen to see a US national news broadcast, all the commercials are for drugs. I guess only old people watch the news on TV anymore. Here’s a TV cloud of the commercials shown during NBC Nightly News. Can you guess which drugs are being advertised? Can you guess which maladies they claim to cure? Look at all those nasty side effects!
TV cloud made from drug commercials. Click to enlarge.
Here is a TV cloud made while watching a baseball game. For US readers familiar with baseball, can you guess which teams were playing? Answer is at the end of this post.
TV cloud built from part of a baseball game broadcast. Click to enlarge.
The Processing sketch reads words from the serial line and filters out any word less than 3 letters and some very common words like “the”, “and”, “for”, etc. This application relies on the very nice OpenCloud Java library, so you’ll need to download that and use it in your Processing environment. Create this structure in your Processing sketchbook libraries directory: opencloud/library/opencloud.jar
