Toolduino is an open-source software tool that you use to test your Arduino circuits. Toolduino communicates with your Arduino through a serial connection so that you can manipulate the pin outputs and read the inputs. Go to the Toolduino page to download it and for all the details on how to use it!
This was a fun project I built using a perf-board Arduino with GPS receiver, some LEDs, some long wire, some clever code, and a car!
I have this friend that has a speeding problem. So I built this device for my friend so he’ll know when he’s speeding. How will he know? Because when the small perf-board Arduino device with a GPS module detects that his vehicle’s speed is over the speed limit, it turns on a police lights display that is mounted on the inside of his car’s rear windshield. When he sees those flashing police lights in the rear-view mirror, he’ll know he needs to slow down!
Police in the rear view mirror!
OK, it’s me, but you already figured that out. If you weren’t smart, you wouldn’t be here. Here’s a rundown of this project’s features:
A simple perf-board Arduino circuit with an EM-406a GPS Receiver connected to the microcontroller
A pair of CAT-5 cables running from the circuit to the back of my Honda Civic
A small perf-board with red and blue LEDs and two white LEDs representing the headlights of a police car. This small board is mounted on the inside of the rear windshield using suction cups.
The software running on the microcontroller is programmed to know the speed limit in different locations near where I live and drive. I did this by specifying “speed zones” which are polygons and a speed limit. The polygons are defined as a list of latitude/longitude vertices.
Whenever the GPS module reports the current position and speed (every second) the code determines which bounding polygon or “speed zone” the car is located in. If the GPS receiver reports that the current speed is greater than the speed zone’s limit, the police lights are activated. If below the speed limit, the lights will be turned off.
Most keypads like this are wired so it makes it straightforward to figure out what button is being pressed. With 3 columns and 4 rows of buttons, you only need 7 wires. Typically all the buttons in a column are connected together with the same wire, and all the buttons in a row are connected together with the same wire. To determine which button is pressed, you apply a voltage to the wire attached to a column and then check the wires attached to each row to see if current is flowing through any of them. If so, then the switch for a particular button is closed (button pressed). Then you proceed to the next column and try each row again, etc. Not rocket science — just scanning a bunch of switches to see which one is closed. In fact, there is a keypad library in the Arduino Playground that makes it easy to do this.
Well, the keypad I bought here has 10 wires instead of 7, and it’s wired in a really goofy way. I’m not sure if this is common, but I thought keypads were generally wired as described above. Here’s the schematic that shows how this one is actually wired:
Schematic of my non-standard keypad
Notice that the gray wire is used only for the 9 key. And the orange wire is only used for the * key. And the brown wire is only used for the # key. Why is this built so inefficiently? I have no idea!
Regardless, here is Arduino code that I used to scan this keypad. You can do something similar if you have a keypad that is not wired in a straightforward way.
// Pins
#define BLACK 2
#define WHITE 3
#define GRAY 4
#define PURPLE 5
#define BLUE 6
#define GREEN 7
#define YELLOW 8
#define ORANGE 9
#define RED 10
#define BROWN 11
#define STAR 10
#define POUND 11
void setup() {
Serial.begin(115200);
// Rows
pinMode(BLACK, INPUT);
digitalWrite(BLACK, HIGH); // set pull-up resistors for all inputs
pinMode(WHITE, INPUT);
digitalWrite(WHITE, HIGH);
pinMode(GRAY, INPUT);
digitalWrite(GRAY, HIGH);
pinMode(PURPLE, INPUT);
digitalWrite(PURPLE, HIGH);
pinMode(ORANGE, INPUT);
digitalWrite(ORANGE, HIGH);
pinMode(BROWN, INPUT);
digitalWrite(BROWN, HIGH);
// Columns
pinMode(BLUE, OUTPUT);
digitalWrite(BLUE, HIGH);
pinMode(GREEN, OUTPUT);
digitalWrite(GREEN, HIGH);
pinMode(YELLOW, OUTPUT);
digitalWrite(YELLOW, HIGH);
pinMode(RED, OUTPUT);
digitalWrite(RED, HIGH);
}
void loop() {
int key = scanKeypad();
if (key != -1) {
if (key == STAR) {
Serial.println("*");
} else {
if (key == POUND) {
Serial.println("#");
} else {
Serial.println(key);
}
}
}
}
int scanKeypad() {
int key = -1;
// Pull the first column low, then check each of the rows to see if a
// button is pressed.
digitalWrite(BLUE, LOW);
if (digitalRead(BLACK) == LOW) {
key = 1;
}
if (digitalRead(WHITE) == LOW) {
key = 4;
}
if (digitalRead(PURPLE) == LOW) {
key = 7;
}
digitalWrite(BLUE, HIGH);
// Moving on to the second column....
digitalWrite(GREEN, LOW);
if (digitalRead(BLACK) == LOW) {
key = 2;
}
if (digitalRead(WHITE) == LOW) {
key = 5;
}
if (digitalRead(PURPLE) == LOW) {
key = 8;
}
digitalWrite(GREEN, HIGH);
// Third "column". Note that the 0 key is wired to this column even though
// the 0 is really in the second column.
digitalWrite(YELLOW, LOW);
if (digitalRead(BLACK) == LOW) {
key = 3;
}
if (digitalRead(WHITE) == LOW) {
key = 6;
}
if (digitalRead(GRAY) == LOW) {
key = 9;
}
if (digitalRead(PURPLE) == LOW) {
key = 0;
}
digitalWrite(YELLOW, HIGH);
// Last "column" is not really it's own column. Only wired to * and #
digitalWrite(RED, LOW);
if (digitalRead(ORANGE) == LOW) {
key = STAR;
}
if (digitalRead(BROWN) == LOW) {
key = POUND;
}
digitalWrite(RED, HIGH);
return key;
}
This is a mood lamp I build using 16 LEDs of different colors and small glass vials. The square bottoms of the vials look a lot like glass block, and the glass diffuses and scatters the light in beautiful ways. The software shows random patterns of light and the brightness of each LED can vary — they aren’t simply “on” or “off”.
The Arduino code is pretty complex because it implements PWM (pulse-width modulation) for all 16 LEDs. The Arduino board only has 5 PWM-capable pins, so providing PWM for all 16 pins is accomplished purely in the code. The lamp randomly displays different lighting patterns and can be really mesmerizing. Ok, I know you want to see it in action, so here it is (note that the music is just in the background — the lights are not reacting to it):
Construction
The base of the lamp is a piece of plexiglass about 5 inches square, and all of the wiring is on the underside of the plexi. Each of the 16 LEDs goes into a small socket made from two pins of a female header. I used sockets instead of soldering the LEDs directly so that I could rearrange the colors any way I like.
I built a wireless robotics platform from a cheap R/C car, an Arduino with XBee shield, small microswitch sensors, and a Processing program running on a remote computer to control the vehicle. The vehicle is completely controlled by the code running on the remote computer which allows very rapid prototyping of the code to tell the vehicle what to do and how to react to the sensor events received from the vehicle. I’m hoping this is a good way to teach my 9-year old son about programming.
Wireless computer-controlled robotics platform built on cheap RC vehicle, Arduino microcontroller, and XBee radios
Before I get into details, here’s an overview of the features:
All logic controlling the vehicle is performed in a Processing program running on remote computer. The Arduino program listens for commands from the remote computer.
Bi-directional wireless communication over XBee radios with (theoretical) 1-mile range. I’ve accomplished 1/4 mile range with these radios.
Sensor events are transmitted from the vehicle to the controlling computer. This vehicle has 3 microswitches – two on front bumper and one at the rear.
Original circuitry of vehicle replaced with dual H-Bridge circuit to control drive motor and turn motor. Drive motor is controlled with variable speed.
Power: Vehicle motors powered by 4 AA batteries. Arduino with XBee shield powered by 9V battery mounted at front of vehicle.
Simple communications protocol: 2 byte commands from controller to vehicle, one byte sensor readings from vehicle to controller.
The Hardware
There’s nothing special about the configuration of the XBee radios. They are running the AT firmware (“transparent mode”) which allows them to simply exchange serial data. The Libelium XBee shield on top of the Arduino makes it easy to read/write serial data from Arduino code.
Arduino and XBee shield on top of the vehicle
Inside the vehicle is a simple circuit board with an L293 quadruple half-H driver to drive the motors. The drive motor and turn motor are connected. I had to rip out the original circuit board (but I saved it!). Read more…
I’m happy to finally announce my new product, the EZ-Expander shield. After several months of hard work of sourcing parts, designing the PCB, and setting up a store, my first product is now available for purchase in the nootropic design store!
This is an amusing project inspired by flashing blue and red lights on police cars, ambulances, etc. This is a perf board Arduino with 5 blue and 5 red LEDs, and the Arduino code lights them up in a pattern similar to police lights.
First, the Arduino built on a perf board. It’s not hard to build your own Arduino. I use a real Arduino board to upload code to the ATMega328 chip, then just move it to the project board.
Perfboard Arduino with blue and red LEDs for police lights mini-project
Now here it is in action — I really think if you don’t know what you’re looking at, it looks realistic in the dark.
Here’s the code that makes it work. Notice that some of the LEDs are controlled using PWM; the second and fourth LED in each of the blue and red groups. I would invite people to build something similar and tweak this to get the most realistic effect possible!
After tearing down an old CD player, I was inspired by the CD laser scanning assembly to build a door lock for my subterranean lab. The assembly has two motors: one for turning the CD (I’m not using this one) and one for slowly moving the laser across the CD’s surface. This second motor provides a nice linear motion that I wanted to use to build an electronically-controlled dead bolt lock for my lab.
Here’s the assembled lock. The circuit board in the middle is an H-bridge circuit I built to allow the motor to move in both directions. There are two position sensing switches so the Arduino senses when the motor has reached its limit in either direction. A 9V power supply powers the Arduino board, and a separate 5V supply drives the motor through the H-bridge. The dead bolt is literally a bolt — connected to the assembly with a piece of scrap circuit board — that travels through the door jamb and into the door.
The lock in the closed (locked) position.
The black CAT5 cable connected to pins 2-8 goes through a small hole in the wall (under a desk) to the keypad on the outside of the lab (I wasn’t sure I wanted to permanently mount the keypad in the wall). The user types in the correct code and presses the # key to open or close the lock. The green LED indicates the door is unlocked. Red indicates locked.
Lock keypad - green indicates that it's unlocked, red indicates locked.
Let’s see the lock in action. (While recording, I gave instructions to my son to lock and unlock using the keypad off camera.)
I decided to explore the more advanced features of XBee radios by building a remote temperature sensor. You can get quite a bit of control over an XBee radio without a microcontroller at all. You can configure the radio to send sensor readings at particular intervals when it detects changes on certain input pins. For the details on configuring XBee radios, see the documentation at Digi International.
For this project, I configured the radio at the sensor end to read the analog input of pin 19 every 4 seconds and to send a sensor reading packet. Both the sender and receiver radios should be running the API firmware. Input pin 19 on my sensor radio is configured (parameter D1) with value ‘2′ which means that it will read analog input, and the IO sampling rate (parameter IR) is set to ‘1000′ which sends a sample every 4096ms.
An LM34 temperature sensor outputs a variable voltage depending on the temperature. The mapping is extremely simple: 10mV for every Fahrenheit degree. So, at 72 degrees F, the output is 720mV.
Why did I choose pin 19? I started with pin 20, but I burned it out. The pins can only handle an analog input of up to 1.2V, and I think I may have sent too much into the pin. How? Well, let’s say it involved holding a cold Pepsi can on the circuit to cool off the temperature sensor, and I shorted out a connection with the can. Oops. I’m lucky I didn’t burn out the entire XBee chip.
Remote temperature sensor
Here is the circuit for the remote sensor:
Schematic for remote sensor circuit
For the receiving side, I used an Arduino with an XBee shield and a two digit LED display: Read more…
Here is a device I call the Hack-a-Sketch. The screen is a normal laptop (an old one), but it has real knobs which control the stylus on the screen.
The Hack-a-Sketch
An Arduino board reads the inputs from two potentiometers (the knobs), and sends the information via USB to a Processing sketch which displays the path of the stylus on the screen. This was extremely easy to build because the Arduino is just running the StandardFirmata firmware. No custom code on the board. The Processing sketch was surprisingly easy to write. Using this really did feel like using an Etch-a-Sketch.
Here’s the Hack-a-Sketch in action. Wait for the big finish where I erase the image…
How did I erase the drawing by shaking the computer? There’s a mercury switch hidden behind the panel holding the knobs. When the code senses shaking, the image is slowly erased. More shaking = more erasure. Read more…