Posts Tagged ‘arduino’

Set clock on Arduino Yún

January 14, 2014

In my Arduino Yún project, I’d had the problem of sometimes writing to the log file before the clock had been set (so the log had the wrong date and time). To avoid this, I wanted to force the clock to be set as part of my Arduino sketch.

After poking about on the Linino side of the Yún, I figured it out.

You use ntpd, like this:

p.runShellCommand("ntpd -qn -p");

I figured this out by ssh-ing to the Yún and using ps to see what processes were running. I figured I might be looking for ntp, so I used

ps | grep ntp

I don’t know why the command uses the 0. in, but didn’t work, and the command I saw running in the results from ps used it.


Crazy Arduino Yun solution to a router problem

January 8, 2014

My father-in-law helps out with computer-related stuff at a coffee shop. They’ve been having WiFi troubles; the WiFi signal is strong, but they lose the internet connection. The solution has been to turn the router off and then back on; if they do that, things then work fine. He even installed a wall switch for this purpose, to make it easier.

He asked me whether I could build a device that would do this automatically. It sounded like an interesting project, and there’d be some useful things to learn in the process. Probably they should just buy a new router, but what follows here is a description of my crazy auto-router-resetter: my goal was to build an Arduino-based device that would check for an internet connection, and if the internet was down, use a PowerSwitch Tail (from Sparkfun) to shut off the router, wait 30 seconds, and turn it back on again.

Here’s a picture of the final product:

Arduino Yun project


Arduino robot book

October 31, 2012

O’Reilly has a new book, Make an arduino-controlled robot.

It seems really useful, covering a lot of the questions that I have about my own robot.

And it covers the exact robot kit I’ve been using, from DFrobot.

Arduino/Xbee garage door indicator

September 23, 2012

A month or so ago, I created a garage door indicator using arduino and XBee: LEDs in my bedroom indicate whether my garage doors are open or closed. I was inspired by this project, though I didn’t want to get into the garage door opener itself, to remotely open or close the doors. I’d also been reading about thefts from garages in the neighborhood, and we do tend to leave one of garage doors open now and then, sometimes over night.

Remote sensors

To sense whether my two garage doors are open or closed, I use two magnetic contact switches (like this one, but I’m using the ones that came with my Make: Electronics Components Pack 2b). These are just encased reed switches: they switch on/off based on the proximity of a magnet. The magnet needs to be within about 3/4 inch.

I use a Series 2 XBee and a breakout board from SparkFun (to attach the XBee to a circuit board) to send information about the status of the garage doors to another XBee in my bedroom. The two magnetic contact switches are connected to digital input pins on the XBee, and the XBee is set up to send the status of the two pins every two seconds.

Here’s a picture of the interior of the remote:

And here’s the exterior (I used a project box I purchased from Radio Shack):

And here it is installed:


A second XBee is attached to an Arduino (via an XBee shield from sparkfun). It listens for the open/closed status from the remote XBee and turns on one of a pair of LEDs for each door: red for open (bad) and green for closed (good). Since I have one large garage door and one small one, I use 10mm LEDs for the large door and 5mm LEDs for the small door.

Here’s the original version of the indicators, breadboarded (though with all 5mm LEDs, using a pairs of LEDs for the large door and single LEDs for the small door…the 10mm LEDs hadn’t arrived in the mail yet):

For the final version, I used a cigar box, which I thought would look nicer on my dresser than a plastic project box. I added a lot of bells and whistles. The trickiest part was that the walls of the cigar box are rather thick, and so you have to counter-sink the parts a bit, as they are generally designed for the thinner plastic walls of a project box. And if you counter-sink something, you have to use care in whether to drill the big hole or the small hole first (do the big hole first), and you have to get the size and depth right in the first place; you can’t go back and counter-sink after you’ve drilled the smaller hole.

Here’s the interior:

In addition to the red/green LEDs for the open/closed indicators, there’s a yellow LED to indicate that the XBee is getting a signal, a power jack, an on/off switch, a potentiometer (with a cap) to adjust the brightness of the LEDs, a photoresistor (light sensor), and a button to switch between using the pot or the light sensor to determine the brightness of the LEDs. The light sensor works really well, so I’m really just using that. I’d originally planned to attach the pot directly to the LEDs, but in the end I have everything connected to pins on the arduino and I just use software to read the button/pot/light sensor states and control the LEDs’ brightness.

Here’s the exterior of the indicator box:

Actually, those pictures are before I’d quite finished: the pot is just sitting inside, and I’d not yet added the button or the light sensor.

Here’s the completed interior:

Here’s the completed exterior. The photo sensor is on the top, toward the right rear. The pot and button are on the left side.

A few issues

Power jack

I drilled too big a hole for the power jack in the back. I guess I didn’t measure properly. But the toggle switch came with a metal plate that I wasn’t going to use and which worked perfectly to cover over my mistake. And it’s on the back, anyway. (One side of the plate is labeled on/off, but the other side is blank and so worked nicely.)

Upside-down XBee becoming detached

The remote XBee, which is hanging upside down in the garage, tended to become detached. I strapped it to the circuit board using a zip tie:

Stuck reed switch

One of the reed switches tends to get stuck, and so one of the garage door indicators has a tendency to say it’s closed when it’s really open, and this is the smaller garage door which tends to be the problem one and is really the whole reason for this project!

It took a while to figure this out. At first, I thought that the XBee was over-heating (it was really hot at the end of July), and so I drilled some holes on the side of the project box. But that didn’t help.

I then tried swapping the XBee pins for the two doors. (I should have tried that first!) The problem was still with the particular garage door, so this indicated that it was not the XBee but the reed switch for the small garage door.

I then flicked the reed switch with my finger, and that did it. And every time since, when the indicator stops working, if I give it a quick tap, that fixes the problem. So it’s clear that the reed switch is getting stuck with the circuit closed.

I’m ordering another reed switch, to replace it. For now, I’ve switched the connection to the reed switch from the “normally closed” connection to the “normally open” connection, and then revised the software to match. (Update: Changing the wire connection on the reed switch from “normally closed” to “normally open” didn’t seem to help, so I switched it back, but then swapped the reed switches between the two doors, so that the bad one is on the large door, which we seldom leave open accidentally.)

I also need to install some sort of screen inside, covering the holes I’d drilled, thinking that the electronics were overheating. I don’t want bugs or spiders to get inside.


Here’s the code for the project. (It’s within my XBee repository.)

Data logging shield: update

July 24, 2012

I ran my fridge data logger a bit longer, with the following results; not too different from the previous results.

I’ve posted the code and data at github, including the R code to make the above plot.

I ran the data logger for a couple of days, but it seemed that the battery went mostly dead after just one: the date and time started getting reset as 165/165/165 165:165:85 and then it seemed that the arduino went off and on, so that it would start writing to a new file. I clipped off all the messy bits to make the figure above.

Here is the clipped file, and here is the longer file with some of the messy bits.

Data logging shield

July 11, 2012

I bought the data logging shield from adafruit, as well as the 6 x AA battery holder, so I could try out their refrigerator logger: logging the light and temperature of my fridge, to see how the temperature fluctuates and how much the temperature rises when the door opens.

First, I needed to do some soldering. I hadn’t soldered in a while, so I first put the jack on the battery pack. I’ve done a bunch of these, and Lady Ada has a clear tutorial, but I botched this rather badly.

  • When you do the black wire, on the outer tab, you need to put the solder on the inside rather than the outside. I got too much on the outside and wasn’t able to screw on the plug cover.
  • Cut it off and put on a different one, but realized afterwards that I’d used a 2.5 mm plug instead of a 2.1 mm plug. The larger plug fits into the arduino, but it’s a bit loose and so the connection is unreliable.
  • Cut it off and tried again, but forgot to put the plug cover on the wires first.
  • Cut if off and tried again, and finally got it. The wires are a bit short, but the battery pack works.

I moved on to soldering together the data logging shield. Lady Ada’s instructions are, as always, superb and easy to follow. It all went together easily.

It wasn’t too clear what the LEDs were for, but when I got to the instructions about the light/temp logging, it became clear. You use jumpers to connect them to digital pins 2 and 3 (green will be 3 and red will be 2): note the two short yellow wires in the top right of this picture. Then you do whatever you want with them. (In the light/temp logging sketch, they use green to indicate that a reading is being taken and red to indicate either an error or that data is being written to the SD card; see the walk-through of the code.)

There was one other thing that wasn’t clear: the shield came with a 6-pin ICSP header, but it isn’t mentioned in the assembly instructions, though it does appear in the picture of the shield, next to the two jumpers for the LEDs. I soldered it there but I’m not sure what it would be used for. (As mentioned at the adafruit forum, it’s for programming the arduino via ICSP rather than USB; I don’t think I’ll be doing that.)

Lady Ada used the prototype section of the data logging shield to permanently solder the sensors. I instead put extra long headers in the shield, so that I could easily plug in jumper cables and attach sensors via a breadboard. I also put a single pin of extra long header in the 3V spot on the shield.

Here’s the assembled stuff:

It was super easy to follow the code; I had no trouble getting it all to work.

Here’s the shield in the refrigerator:

I’d planned to leave it in for 24 hours, but I pulled it out after 16 hours so that I could make a plot of the results.

Here’s a plot I made (in R) of the temperature over time. The dots at the bottom indicate when the door was opened; red dots indicate the door was open for more than 10 seconds.

The temperature is mostly below 40 degrees, as it’s supposed to be. I was surprised to see it dip so far below freezing. Just before noon, I left one side of the refrigerator door slightly ajar (a not uncommon mistake in our house). I went into work last night and stayed absurdly late; I opened the fridge when I got home, at a bit after 2am.

I’ll add R code and a sketch of the circuit later. I ended up using the light/temp logging sketch from adafruit without changes, so there’s no need to include that.

Given our tendency to leave the refrigerator door ajar, maybe I should create a temperature-based alarm. No; I think the batteries would cost too much.

Ethernet shield

July 8, 2012

After a long delay, I’m back to playing with electronics.

I bought an arduino ethernet shield from dfrobot (cheap, because it’s the old version that doesn’t have an SD card slot). I got it to work fine with the arduino Ethernet library. The only tricky bit was the MAC address: I tried using a random one, and the arduino would hang at Ethernet.begin(mac). But for some reason if I switched the initial hex digits to 00, then it worked. I ended up just adding 01 to the MAC address for my laptop.

After trying out the very simple examples that come with the arduino Ethernet library, I hooked up a temperature sensor to it, got an account at, and used the CosmClient example to log temperature data for my living room for a day. It was a bit too easy, so I don’t feel particularly accomplished. And the precision of the TMP36 temperature sensor I used (from the Sensor Pack 900 from adafruit) is rather crappy. It’s attached to an analog input and gives temperature in 1° increments.

I’m not sure what I’m going to do with the ethernet shield, but it seems like it’d be cool to be able to turn lights on and off via the web.

I ordered the data logging shield from adafruit, because I wanted to log the temperature inside my refrigerator, as Lady Ada had done. (I guess I should have just ordered the proper ethernet shield, which would have included ethernet and SD card access!)

The code for my little temperature logging project is on github.

Music shield triggered by PIR sensor

March 17, 2012

I recently got a Seeeduino music shield, and I spent last night and a bit today trying to get it to be triggered by a PIR sensor, so that the music would turn on when there’s movement and turn off when there’s not been movement for 5 seconds.

It took a bit of tinkering and studying. Initially, I could just get it to turn on with movement and then run through a full song. But today I was finally able to get it to work.

The music shield library has rather ugly code with a lot of extraneous commented-out lines and little documentation. But it is rather easy to follow and to get working. Most importantly, it was quite easy to do the modifications to handle the PIR sensor information. I did need to make a change to the actual library, which is less than ideal, but it was only a couple of lines.

The file player.cpp contains a function AvailableProcessorTime() that gets called repeatedly in order to handle user interface events. Then there’s a global variable playStop that indicates whether the player should be playing (playStop == 1) or stopped (playStop == 0). So I just needed to add a line to check the sensor and change playStop accordingly.

What I did was create a generic user-defined function,

void userInterruptFunction(void) { /* ... */ }

that gets called within AvailableProcessorTime(). The user would need to be sure to define that function, but it could be left empty, or it could be used (as with my code) to check a sensor and then change a setting.

The code for my project is at my github page.

Boty Bot: Batteries

March 16, 2012

The DFRobot platform that I used for Boty Bot has the batteries placed inside the bottom compartment, near the motors. It would be a real hassle to exchange batteries, as you’d have to take the whole thing apart. And the kit does come with a DC power jack plus a hole for it in the back, next to another hole for a SPDT switch.

So it was obvious to me from the start that I’d want a rechargeable battery. And I was quite proud of myself for working out the following wiring diagram for the battery.

When the switch is in the up position, the battery is connected to the motor shield, and the motors receive power. When the switch is in the down position, the battery is connected to the DC power jack and can be charged. I guess the scheme is pretty obvious, but I was still pleased with myself.

After a bit of searching, I chose a 6V 2000 mAh NiMH battery pack that is like 5 AAs shrink-wrapped together, plus a related charger. I considered a more expensive universal charger, but decided to just get this cheaper one, as I didn’t think I’d be using lots of different kinds of batteries, and I’ve been spending too much money on this hobby.

The 6V battery worked great. But then a day after putting the robot together, the robot started acting crazy: going backwards and not responding to the remote, giving crazy Ping distance measurements, etc. I finally concluded that it was the 9V battery driving the arduino, ping sensor and servo: the battery was running low, but rather than stopping working completely, the robot was just stopping working properly.

So, I got a second rechargeable battery to drive the arduino, ping and servo (i.e., everything but the motors): a 7.2V 2000 mAh NiMH battery pack just like the 6V one driving the motors, but with 6 AAs shrink-wrapped together rather than just 5.

I soldered a 2.1mm male plug onto the 7.2V pack, then realized I’d forgotten to thread the plastic sleeve onto the wires first, and so had to cut them, desolder, and solder again. That won’t be the last time I screw up in that way, I’m sure.

I then made a couple of adapters for the charger, since one battery is connected to a 2.1mm female jack and the other to a 2.1mm male plug.

The robot has been working well since I got the 7.2V battery pack.

I also got a mini volt meter so I can monitor the battery charge. I’m not sure whether I should monitor the power to the arduino (the Vin pin) or the regulated power (the 5V pin). Currently, I’m monitoring the Vin pin.

Boty Bot: Overview

March 15, 2012

I learned quite a number of things in the process of creating my arduino robot, Boty Bot. (I initially called it “Boxy Bot”, but my son changed it to “Boty Bot”.) I’ll explain various things over the next several posts, separately considering the batteries, the motors, the Apple remote, etc. (The code is at github.)

A robot seemed a fun way to start with Arduino: something that drives around, to please the kids, and an opportunity to play with different sensors. I started with the adafruit motor party pack: the adafruit motor shield plus several motors to play with. I destroyed the DC motor by tearing off one of the soldering tabs (those things are delicate!); more on that later.

It seemed the easiest way to make a robot would be with a kit; after a bit of searching I decided on the DFRobot 4WD platform: simple and relatively inexpensive. I also got the Ping sensor and mounting bracket, a sonar sensor that looks like a pair of eyes, with a servo motor so the “head” can scan back and forth.

There is quite a bit of information online about this DFRobot kit:

It went together quite easily. There were a number of snags, but in the end I’m happy with it. The wheels are a bit cheap and wobbly, but overall it is good.

The highlights of what I learned:

  • It would be a hassle to change the motor batteries, as you’d have to take the whole thing apart. Rechargeable batteries and a power jack are critical.
  • A 9V battery to run the arduino plus the Ping sensor is not enough. I needed a second rechargeable battery for the controller. A mini volt meter is nice for keeping track of the battery charge.
  • Fancy jumper cables fall out too easily; it’s better to use hand trimmed wires. Even better would be screw terminals, like on a screw shield.
  • The soldering tabs on DC motors can be quite delicate, and if you break one, you pretty much ruin the motor. The best advice I’ve seen on soldering DC motors was in the instructions for the Makey Robot; see step 15.
  • I’ve had trouble with the Ping sensor giving sporadic 0s. I haven’t figured out why, but just ignoring strict 0s seems to work.