Here's the latest on my homebrew solar-powered Arduino-based remote sensor platform.
The basic parts manifest, clockwise from top left, includes a solar battery charger regulator, an Arduino Uno board with an XBee radio shield and a Xbee Series 1 radio module, a 12V gel cell rechargeable lead-acid battery, and a solar panel designed to recharge 12V batteries. I bought the regulator and solar panel at my local Harbor Freight hardware store in Westminster Colorado. I purchased the Arduino, Xbee radio shield, and Xbee radios over the web from SparkFun Electronics in nearby Boulder Colorado (who are very nice folks, BTW). I also bought some miscellaneous parts and connectors at my local Radio Shack at the Colorado Mills outlet mall in Lakewood Colorado (who know me quite well by now, and have been known to whip out a multimeter when I have a question).
Everything except the solar panel fits nicely into a five dollar plastic box I bought at the local Office Depot office supply store in Wheat Ridge Colorado. The box isn't intended to be water tight, just to keep the worst of the elements off the electrical bits.
Here's a closeup of what gets stuffed into the box. The battery, purchased at my local Interstate Battery store in Arvada Colorado, is the largest and heaviest item, and the most expensive single component as well. What would I do without my Brother thermal label maker?
I used my Dremel tool to cut a tiny slot in the plastic box through which I feed the cable to the solar panel. I also used the Dremel to drill holes in the bottom of the box, which has a bit of a lip around its bottom, so if any moisture does seep into the box it might have a chance of draining out. No air vents though, so we'll see if things get too warm. The box itself will sit in the shade of the roof over my rear deck.
With the lid on you can see that the slot for the cable is conveniently protected by the lip of the lid.
I sat what I am now calling the "Instrument Pod" on a table on my back deck just to make it less likely that I won't trip over it or kick it over. You can easily see the LEDs on the Arduino, the Xbee shield, and the regulator through the transparent plastic.
The solar panel sits on a couple of zinc-coated nails on the conveniently angled open lattice portion of the south-facing roof over my back deck where it's not shaded by any of the nearby trees. It's pretty secure but can be easily lifted off the nails with a little jiggling. Did I mention that Colorado gets more sunny days than any other state in the U.S.? Sorry, California. I have no idea how weather proof this solar panel is, the instruction sheet wasn't helpful in this regard.
Stepping back a little bit, here's what it all looks like: solar panel above, instrument pod below. I've since moved the table a little further back under the roof to the left where it's more consistently shaded.
The test software on the Arduino logs how long it's been running since it's last reset. If the board loses power, the application will restart automatically if and when power is restored. It's talking over a wireless serial channel using the Zigbee (IEEE 802.15.4) protocol to a similar tiny little radio hooked up to my Mac desktop in my office on the second floor. I use the Mac screen utility with a little script that prepends a timestamp to each line it receives from the instrument pod, and logs it all to a file.
My goal at this phase is to see whether I can get enough sunlight to run the Arduino and keep a small battery charged during the day, and to run the Arduino on battery power at night. I'm guessing I'll need a larger solar panel (or at least use this as an excuse to buy one) but this is a cost effective way to get some empirical data.
The ever helpful folks at Office Depot asked me what I was going to store in the plastic box. When I explained it was a microcontroller, radio, battery, and solar charge regulator, they backed away slowly. I get similar strange looks from most (but not all) of the handymen and women my local Lowes hardware store when I explain that "I'm making something from nothing".
Subscribe to:
Post Comments (Atom)
2 comments:
I'm intrigued with your amigo platform after messing with duinOS. It looks like the duinOS folks wrote macro expansions for FreeRTOS, while you wrote either wrapper classes or templates. Is this the case? Also, have you used it with the arduino bootloader and core, or is it standalone but runs on arduino compatible boards?
Lastly, did you have to cut the diode trace from your xbee shield and replace it with a resistor, or did you get one that actually worked?
First, I should note that this specific article describes a project in which I am using the Arduino software. I find using FreeRTOS on the ATmega328P-based systems, like the Arduino Uno, a little painful and generally unnecessary. I'm using Amigo on the ATmega2560-based boards.
Yes, I used C++ wrapper classes around FreeRTOS. With just a little inspection you can see that the wrapper classes add almost no overhead: just a few bytes per object and almost no run-time overhead since the wrappers are for the most part inlined.
I did use the Arduino bootloader (there was no compelling reason not to), but not any other of the Arduino software core.
No, I didn't have to modify my XBee shield. Maybe I got a later rev or something?
At the risk of tl;dr:
One of my soapboxes that I climb onto frequently is the benefits of the use of OO design and implementation in embedded systems. The best way to accomplish this on most such systems is using C++ (although Android is making the use of Java increasingly feasible on larger systems).
One of my goals with Amigo was to demonstrate that you could easily use OO principles, interrupt driven I/O, and multitasking, on even an eight-bit microcontroller. The Arduino boards made a convenient ready-made hardware platform, and FreeRTOS turned out to be a great software platform.
I initially planned to try to make Amigo transparent and maintain the Arduino interfaces, but after working on it for a bit I decided that that Arduino interfaces didn't quite match the interface style I had developed since using C++ for embedded products for more than fifteen years. So unlike duinOS, Amigo is not Arduino-software-compatible.
While I think Amigo, or something like it, is completely usable in a production environment or a commercial product, my initial motivation was that it might be used in teaching (something I used to do and would like to get back to).
Thanks for your interest!
Post a Comment