DIY Solar-Powered, Gas-Detecting Mobile Robot

German engineer Jens Altenburg’s solar-powered hidden observing vehicle system (SOPHECLES) is an innovative gas-detecting mobile robot. When the Texas Instruments MSP430-based mobile robot detects noxious gas, it transmits a notification alert to a PC, Altenburg explains in his article, “SOPHOCLES: A Solar-Powered MSP430 Robot.”  The MCU controls an on-board CMOS camera and can wirelessly transmit images to the “Robot Control Center” user interface.

Take a look at the complete SOPHOCLES design. The CMOS camera is located on top of the robot. Radio modem is hidden behind the camera so only the antenna is visible. A flexible cable connects the camera with the MSP430 microcontroller.

Altenburg writes:

The MSP430 microcontroller controls SOPHOCLES. Why did I need an MSP430? There are lots of other micros, some of which have more power than the MSP430, but the word “power” shows you the right way. SOPHOCLES is the first robot (with the exception of space robots like Sojourner and Lunakhod) that I know of that’s powered by a single lithium battery and a solar cell for long missions.

The SOPHOCLES includes a transceiver, sensors, power supply, motor
drivers, and an MSP430. Some block functions (i.e., the motor driver or radio modems) are represented by software modules.

How is this possible? The magic mantra is, “Save power, save power, save power.” In this case, the most important feature of the MSP430 is its low power consumption. It needs less than 1 mA in Operating mode and even less in Sleep mode because the main function of the robot is sleeping (my main function, too). From time to time the robot wakes up, checks the sensor, takes pictures of its surroundings, and then falls back to sleep. Nice job, not only for robots, I think.

The power for the active time comes from the solar cell. High-efficiency cells provide electric energy for a minimum of approximately two minutes of active time per hour. Good lighting conditions (e.g., direct sunlight or a light beam from a lamp) activate the robot permanently. The robot needs only about 25 mA for actions such as driving its wheel, communicating via radio, or takes pictures with its built in camera. Isn’t that impossible? No! …

The robot has two power sources. One source is a 3-V lithium battery with a 600-mAh capacity. The battery supplies the CPU in Sleep mode, during which all other loads are turned off. The other source of power comes from a solar cell. The solar cell charges a special 2.2-F capacitor. A step-up converter changes the unregulated input voltage into 5-V main power. The LTC3401 changes the voltage with an efficiency of about 96% …

Because of the changing light conditions, a step-up voltage converter is needed for generating stabilized VCC voltage. The LTC3401 is a high-efficiency converter that starts up from an input voltage as low as 1 V.

If the input voltage increases to about 3.5 V (at the capacitor), the robot will wake up, changing into Standby mode. Now the robot can work.

The approximate lifetime with a full-charged capacitor depends on its tasks. With maximum activity, the charging is used after one or two minutes and then the robot goes into Sleep mode. Under poor conditions (e.g., low light for a long time), the robot has an Emergency mode, during which the robot charges the capacitor from its lithium cell. Therefore, the robot has a chance to leave the bad area or contact the PC…

The control software runs on a normal PC, and all you need is a small radio box to get the signals from the robot.

The Robot Control Center serves as an interface to control the robot. Its main feature is to display the transmitted pictures and measurement values of the sensors.

Various buttons and throttles give you full control of the robot when power is available or sunlight hits the solar cells. In addition, it’s easy to make short slide shows from the pictures captured by the robot. Each session can be saved on a disk and played in the Robot Control Center…

The entire article appears in Circuit Cellar 147 2002. Type “solarrobot”  to access the password-protected article.

Issue 265: Design with End Users in Mind

Whether you’re building or programming microcontroller-based systems, you should always keep your end users and their needs in mind. That means restraining any urges to stuff a project with superfluous functionality and parts. In “What Were They Thinking?” (Circuit Cellar 165), Steve Ciarica argues that over-engineered electronics products are typically more annoying than impressive. Ciarcia writes:

I’ve mentioned this before, but the original BMW iDrive on my 2002 745iL was a prime example of overzealous design. Back then, somebody had the bright idea of condensing nearly all the switches and knobs formerly found on typical car dashboards down to a large knob, called iDrive, on the center console. Combined with a fancy graphics LCD, the joystick provided the driver with 3-D motion control for selecting specific subsystems and individual functions within that subsystem. The bad news was that zooming into and backing out of various control functions was so complicated it was a real driving hazard.

I’m guessing the iDrive designers got caught up in the process of creating a slick design and completely forgot about the basic reason you’re in the car in the first place—to drive, not to run a computer! Let’s face it, when you’re driving, it’s more expedient to reach for a single-function control you can locate out of the corner of your eye. The world was not ready to deal with a 3-D joystick, a complex decision tree on an LCD, and a dozen hand motions to tell a computer to accomplish the same thing. With the original iDrive, you either left the same Sirius station on forever with the hot air blowing in your face or learned to use the voice-response system to at least jump over some of the “slick” functionality and get directly to the heater or radio LCD screens.

It took until I got my 2010 X5 for them to get it right. (My three BMWs in between had iterative improvements.) The solution? They put most of the buttons back! Yeah, like most other cars these days, it still has a joystick knob and an LCD that controls individual settings, but a “real” button takes you directly to the right subsystem.

Circuit Cellar Project Editor Dave Tweed related another example to me while I was talking to him about this editorial idea. He told me about the Kawasaki intelligent proximity activation start system (KIPASS), which is an ignition system for some of Kawasaki’s high-end motorcycles that’s based on a “proximity fob” (RFID). If the physical key is in the ignition and you bring the fob within a few feet of the bike, you can start it (by turning and pushing the key). Sounds nice, right?

You can leave the key in the ignition all the time. When you walk away with the fob in your pocket, the key is captured by an electric latch so it can’t be stolen. All’s well and good. But it seems that most riders are in the habit of stopping the engine by using the “kill switch” instead of turning off the key. That’s fine until you realize that the headlight is only controlled by the ignition key—the light stays on until you turn the key to the “off” position. On a normal bike, you would do this anyway in order to pocket the key before walking away. But with the KIPASS fob, you don’t need the key and lots of bikers simply stop the engine and walk away—leaving the headlight on and killing the battery.

Here’s where it gets fun. With a dead battery, you can’t start the bike except by jumping it using another vehicle. The Allen wrench you need to open the panel you have to remove to get at the battery is in the tool kit under the seat, which is locked by the ignition key. In a real Catch-22, the ignition key is still “captured” by KIPASS even without power, and you can’t remove it to unlock the seat! The only solution is to find a friend or a tow truck with both jumper cables and the correct Allen wrench.

Home theater equipment is another irritation. Forgiving for now that most functions can be accessed only from the remote control, you’d think the few buttons they do have would work correctly. For some reason, I’m finding the built-in buttons are a lot less responsive than the remote. I suspect the interrupt handling software for the IR receiver has a much higher priority than the hardwired switches. My Blu-ray player, in particular, virtually never responds to the physical change disc button on the front, and I almost always have to use the button on the remote. Even powering up the unit takes two to three firm panel button presses but only one click on the remote. My HDTV is similar. There’s a manual button to change the input selection, and it always takes two to three presses before it actually starts to switch inputs. On the IR remote, it is instant. Grrrr.

The point is, when designing a new piece of equipment, don’t get caught up demonstrating as much technology as possible to the exclusion of all other considerations. How hard can it be to design a piece of equipment to respond equally to a few hardwired buttons as well as the IR? Similarly, just because you have the computing power and software expertise, sometimes it’s counterproductive to put all functional control only in the remote control or to put every function into one multi-option/multitasking joystick. As a designer, you have a responsibility to reduce hardware costs by eliminating excess manual controls, but you should always take the time to put yourself in the place of the end user who has to deal with your choices. More importantly, think about what happens after the dog eats the remote.

Circuit Cellar August 2012 is now available.

Q&A: Guido Ottaviani (Roboticist, Author)

Guido Ottaviani designs and creates innovative microcontroller-based robot systems in the city from which remarkable innovations in science and art have originated for centuries.

Guido Ottaviani

By day, the Rome-based designer is a technical manager for a large Italian editorial group. In his spare time he designs robots and interacts with various other “electronics addicts.” In an a candid interview published in Circuit Cellar 265 (August 2012), Guido described his fascination with robotics, his preferred microcontrollers, and some of his favorite design projects. Below is an abridged version of the interview.

NAN PRICE: What was the first MCU you worked with? Where were you at the time? Tell us about the project and what you learned.

GUIDO OTTAVIANI: The very first one was not technically an MCU, that was too early. It was in the mid 1980s. I worked on an 8085 CPU-based board with a lot of peripherals, clocked at 470 kHz (less than half a megahertz!) used for a radio set control panel. I was an analog circuits designer in a big electronics company, and I had started studying digital electronics on my own on a Bugbook series of self-instruction books, which were very expensive at that time. When the company needed an assembly programmer to work on this board, I said, “Don’t worry, I know the 8085 CPU very well.” Of course this was not true, but they never complained, because that job was done well and within the scheduled time.

I learned a lot about how to optimize CPU cycles on a slow processor. The program had very little time to switch off the receiver to avoid destroying it before the powerful transmitter started.

Flow charts on paper, a Motorola developing system with the program saved on an 8” floppy disk, a very primitive character-based editor, the program burned on an external EPROM and erased with a UV lamp. That was the environment! When, 20 years later, I started again with embedded programming for my hobby, using Microchip Technology’s MPLAB IDE (maybe still version 6.xx) and a Microchip Technology PIC16F84, it looked like paradise to me, even if I had to relearn almost everything.

But, what I’ve learned about code optimization—both for speed and size—is still useful even when I program the many resources on the dsPIC33F series…

NAN: You worked in the field of analog and digital development for several years. Tell us a bit about your background and experiences.

GUIDO: Let me talk about my first day of work, exactly 31 years ago.

Being a radio amateur and electronics fan, I went often to the surplus stores to find some useful components and devices, or just to touch the wonderful receivers or instruments: Bird wattmeters, Collins or Racal receivers, BC 312, BC 603 or BC 1000 military receivers and everything else on the shelves.

The first day of work in the laboratory they told to me, “Start learning that instrument.” It was a Hewlett-Packard spectrum analyzer (maybe an HP85-something) that cost more than 10 times my annual gross salary at that time. I still remember the excitement of being able to touch it, for that day and the following days. Working in a company full of these kinds of instruments (the building even had a repair and calibration laboratory with HP employees), with more than a thousand engineers who knew everything from DC to microwaves to learn from, was like living in Eden. The salary was a secondary issue (at that time).

I worked on audio and RF circuits in the HF to UHF bands: active antennas, radiogoniometers, first tests on frequency hopping and spread spectrum, and a first sample of a Motorola 68000-based GPS as big as a microwave oven.

Each instrument had an HPIB (or GPIB or IEEE488) interface to the computer. So I started approaching this new (for me) world of programming an HP9845 computer (with a cost equivalent to 5 years of my salary then) to build up automatic test sets for the circuits I developed. I was very satisfied when I was able to obtain a 10-Hz frequency hopping by a Takeda-Riken frequency synthesizer. It was not easy with such a slow computer, BASIC language, and a bus with long latencies. I had to buffer each string of commands in an array and use some special pre-caching features of the HPIB interface I found in the manual.

Every circuit, even if it was analog, was interfaced with digital ports. The boards were full of SN74xx (or SN54xx) ICs, just to make some simple functions as switching, multiplexing, or similar. Here again, my lack of knowledge was filled with the “long history experience” on Bugbook series.

Well, audio, RF, programming, communications, interfacing, digital circuits. What was I still missing to have a good background for the next-coming hobby of robotics? Ah! Embedded programming. But I’ve already mentioned this experience.

After all these design jobs, because my knowledge started spreading on many different projects, it was natural to start working as a system engineer, taking care of all the aspects of a complex system, including project management.

NAN: You have a long-time interest in robotics and autonomous robot design. When did you first become interested in robots and why?

GUIDO: I’ve loved the very simple robots in the toy store windows since I was young, the same I have on my website (Pino and Nino). But they were too simple. Just making something a little bit more sophisticated required too much electronics at that time.

After a big gap in my electronics activity, I discovered a newly published robotic magazine, with an electronic parts supplement. This enabled me to build a programmable robot based on a Microchip PIC16F84. A new adventure started. I felt much younger. Suddenly, all the electronics-specialized neurons inside my brain, after being asleep for many years, woke up and started running again. Thanks to the Internet (not yet available when I left professional electronics design), I discovered a lot of new things: MCUs, free IDEs running even on a simple computer, free compilers, very cheap programming devices, and lots of documentation freely available. I threw away the last Texas Instruments databook I still had on my bookshelf and started studying again. There were a lot of new things to know, but, with a good background, it was a pleasant (if frantic) study. I’ve also bought some books, but they became old before I finished reading them.

Within a few months, jumping among all the hardware and software versions Microchip released at an astonishing rate, I found Johann Borenstein et al’s book Where Am I?: Systems and Methods for Mobile Robot Positioning (University of Michigan, 1996). This report and Borenstein’s website taught me a lot about autonomous navigation techniques. David P. Anderson’s “My Robots” webpage ( inspired all my robots, completed or forthcoming.

I’ve never wanted to make a remote-controlled car, so my robots must navigate autonomously in an unknown environment, reacting to the external stimuli. …

NAN: Robotics is a focal theme in many of the articles you have contributed to Circuit Cellar. One of your article series, “Robot Navigation and Control” (224–225, 2009), was about a navigation control subsystem you built for an autonomous differential steering explorer robot. The first part focused on the robotic platform that drives motors and controls an H-bridge. You then described the software development phase of the project. Is the project still in use? Have you made any updates to it?

The “dsNavCon” system features a Microchip Technology dsPIC30F4012 motor controller and a general-purpose dsPIC30F3013. (Source: G. Ottaviani, CC224)

GUIDO: After I wrote that article series, that project evolved until the beginning of this year. There is a new switched power supply, a new audio sensor, the latest version of dsNav dsPIC33-based board became commercially available online, some mechanical changing, improvements on telemetry console, a lot of modifications in the firmware, and the UMBmark calibration performed successfully.

The goal is reached. That robot was a lab to experiment sensors, solutions, and technologies. Now I’m ready for a further step: outdoors.

NAN: You wrote another robotics-related article in 2010 titled, “A Sensor System for Robotics Applications” (Circuit Cellar 236). Here you describe adding senses—sight, hearing, and touch—to a robotics design. Tell us about the design, which is built around an Arduino Diecimila board. How does the board factor into the design?

An Arduino-based robot platform (Source: G. Ottavini, CC236)

GUIDO: That was the first time I used an Arduino. I’ve always used PICs, and I wanted to test this well-known board. In that case, I needed to interface many I2C, analog sensors, and an I2C I/O expander. I didn’t want to waste time configuring peripherals. All the sensors had 5-V I/O. The computing time constraints were not so strict. Arduino fits perfectly into all of these prerequisites. The learning curve was very fast. There was already a library of every device I’ve used. There was no need for a voltage level translation between 3.3 and 5 V. Everything was easy, fast, and cheap. Why not use it for these kinds of projects?

NAN: You designed an audio sensor for a Rino robotic platform (“Sound Tone Detection with a PSoC Part 1 and Part 2,” Circuit Cellar 256–257, 2011). Why did you design the system? Did you design it for use at work or home? Give us some examples of how you’ve used the sensor.

GUIDO: I already had a sound board based on classic op-amp ICs. I discovered the PSoC devices in a robotic meeting. At that moment, there was a special offer for the PSoC1 programmer and, incidentally, it was close to my birthday. What a perfect gift from my relatives!

This was another excuse to study a completely different programmable device and add something new to my background. The learning curve was not as easy as the Arduino one. It is really different because… it does a very different job. The new PSoC-based audio board was smaller, simpler, and with many more features than the previous one. The original project was designed to detect a fixed 4-kHz tone, but now it is easy to change the central frequency, the band, and the behavior of the board. This confirms once more, if needed, that nowadays, this kind of professional design is also available to hobbyists. …

NAN: What do you consider to be the “next big thing” in the embedded design industry? Is there a particular technology that you’ve used or seen that will change the way engineers design in the coming months and years?

GUIDO: As often happens, the “big thing” is one of the smallest ones. Many manufacturers are working on micro-nano-pico watt devices. I’ve done a little but not very extreme experimenting with my Pendulum project. Using the sleeping features of a simple PIC10F22P with some care, I’ve maintained the pendulum’s oscillation bob for a year with a couple of AAA batteries and it is still oscillating behind me right now.

Because of this kind of MCU, we can start seriously thinking about energy harvesting. We can get energy from light, heat, any kind of RF, movement or whatever, to have a self-powered, autonomous device. Thanks to smartphones, PDAs, tablets, and other portable devices, the MEMS sensors have become smaller and less expensive.

In my opinion, all this technology—together with supercapacitors, solid-state batteries or similar—will spread many small devices everywhere to monitor everything.

The entire interview is published in Circuit Cellar 265 (August 2012).

Electronics Engineering Crossword (Issue 265)

Here are the answers to the crossword puzzle in Circuit Cellar 265, August 2012. The issue is now available.


1.     CUTOFFFREQUENCY—The frequency where a filter’s output has fallen by 3 dB from the maximum level that can be achieved through the filter [two words]

3.     SHAMIR—Israeli cryptographer and one of inventors of the RSA algorithm

6.     AVOGADROSLAW—V/n = k, where V is the volume of the gas, n is the amount of substance of the gas, and k is a proportionality constant [two words]

8.     NOISEFIGURE—Columnist Robert Lacoste’s article, “Noise Filters 101” (Circuit Cellar, April 2012), discussed how to determine this and measure it in a radio frequency filter [two words]

11.   JAVASCRIPT—ECMAScript-approved language that supports a lot of C-structured programming syntax

12.   VOLTAGESPIKE—Lightening or a tripped circuit wire, for example [two words]

15.   THEAMPHOUR—Name of the radio show co-hosted by two recent Circuit Cellar Q&A interviewees [three words]

16.   BLOCKED—When a software thread relinquishes control of the processor to the operating system

17.   KILBY—American physicist (1923-2005) who worked with Robert Noyce to create the first integrated circuit

18.   OCTAVE—The interval between one musical pitch and another with half or double its frequency

19.   PYROELECTRICDETECTOR—A capacitive sensor that changes its polarization in response to a change in temperature [two words]

20.   KYZPULSE—In a mechanical electrical meter, a pulse that changes state every half rotation of the meter’s disk and represents a quanta of energy [two words]


2.     TOOLCHAIN—Software used to create other software, usually including a text editor, a compiler, a linker, and a debugger

4.     HENRY—A unit of inductance; abbreviation “H”

5.     RADIOFREQUENCY—An amount of oscillation ranging from 3 kHz to 300 GHz [two words]

7.     DEPTHCAMERA—Miguel Sanchez’s article, “Image Processing Development” (Circuit Cellar, June 2012), used one of these along with an MCU and bipolar stepper motors to accomplish some computer vision-related tasks [two words]

9.     OHIOSCIENTIFIC—In 1978, this company released one of its first products—a simple, MOS Technology 6502 microprocessor-based, single-board computer [two words]

10.   PHOTOVOLTAICCELL—According to Jeff Bachiochi’s article in this issue, a single one of these is “a translucent sandwich of P-type and N-type material forming a huge diode junction that can be exposed to a light source” [two words]

13.   LOGPOT—Abbreviation; used as a volume control in audio amplifiers [two words]

14.   AMPERE—An SI unit of electric current


Issue 265: Embedded Systems Abound

I recently read on the transcript of an interview (May 9, 2002) with arachnologist Norman Platnick who stated: “You’re probably within seven or eight feet of spider no matter where you are. The only place on earth that has no spiders at all—as far as we know—is Antarctica.” It didn’t take long for me to start thinking about embedded systems and my proximity to them. Is the average person always within several feet of embedded systems? Probably not. But what about 50% or 60% of the time? E-mail me your thoughts.

Circuit Cellar 265, August 2012 - Embedded Development

Embedded systems are becoming ubiquitous. They’re in vehicles, mobile electronics, toys, industrial applications, home appliances, and more. If you’re indoors, the temperature is likely monitored and controlled by an embedded system. When you’re engaged in outdoor activities (e.g., hiking, golfing, biking, or boating), you probably have a few MCU-controlled devices nearby, such as cell phones, rangefinders, pedometers, and navigation systems. This month we present articles about how embedded systems work, and our authors also provide valuable insight about topics ranging from concurrency to project development.

Freescale’s Mark Pedley kicks off the issue with a revealing article about a tilt-compensating electronic compass (p. 16). Now you can add an e-compass to your next MCU-based project.

E-compass technology (Source: M. Pedley, CC265)

Turn to page 24 for an in-depth interview with Italy-based engineer Guido Ottaviani. His fascination with electronics engineering, and robotics in particular, will inspire you.

Have you ever come across a product that you know you could have designed better? Scott Weber had that experience and then acted on his impulse to build a more effective system. He created an MCU-based light controller (p. 32).

The MCU-based light controller is on the right (Source: S. Weber, CC265)

If you want to ensure a microcontroller works efficiently within one of your systems, you should get to know it inside and out. Shlomo Engelberg examines the internal structure of an I/O pin with a pull-up resistor (p. 40).

Bob Japenga continues his series “Concurrency in Embedded Systems” on page 44. He covers atomicity and time of check to time of use (TOCTTOU).

On page 48 George Novacek presents the second part of his series on project development. He covers project milestones and design reviews.

Ed Nisley’s June 2012 article introduced the topic of MOSFET channel resistance. On page 52 he covers his Arduino-based MOSFET tester circuitry and provides test results.

The MOSFET tester PCB hides the Arduino that runs the control program and communicates through the USB cable on the left edge. (Source: E. Nisley, CC265)

If you read Robert Lacoste’s June 2012 article, you now understand the basics of frequency mixers. This month he presents high-level design methods and tools (p. 58).

Jeff Bachiochi wraps up the issue with an examination of a popular topic—energy harvesting (p. 68). He covers PV cell technology, maximum power point tracking (MPPT), and charge management control.

A great way to investigate MPPT for your design is to use an STMicroelectronics evaluation board, such as this STEVAL-ISV006V2 shown in the top of the photo. The smaller cell in the center is rated at 165 mW (0.55-V output at 0.3 A) measuring 1.5” × 0.75”. At the bottom is a Parallax commercial-quality solar cell that is rated at 2.65 W (0.534-V output at 5.34 A) measuring 125 mm. (Source: J. Bachiochi, CC265)

Circuit Cellar 265 is currently on newsstands.