DIY Green Energy Design Projects

Ready to start a low-power or energy-monitoring microcontroller-based design project? You’re in luck. We’re featuring eight award-winning, green energy-related designs that will help get your creative juices flowing.

The projects listed below placed at the top of Renesas’s RL78 Green Energy Challenge.

Electrostatic Cleaning Robot: Solar tracking mirrors, called heliostats, are an integral part of Concentrating Solar Power (CSP) plants. They must be kept clean to help maximize the production of steam, which generates power. Using an RL78, the innovative Electrostatic Cleaning Robot provides a reliable cleaning solution that’s powered entirely by photovoltaic cells. The robot traverses the surface of the mirror and uses a high voltage AC electric field to sweep away dust and debris.

Parts and circuitry inside the robot cleaner

Cloud Electrofusion Machine: Using approximately 400 times less energy than commercial electrofusion machines, the Cloud Electrofusion Machine is designed for welding 0.5″ to 2″ polyethylene fittings. The RL78-controlled machine is designed to read a barcode on the fitting which determines fusion parameters and traceability. Along with the barcode data, the system logs GPS location to an SD card, if present, and transmits the data for each fusion to a cloud database for tracking purposes and quality control.

Inside the electrofusion machine (Source: M. Hamilton)

The Sun Chaser: A GPS Reference Station: The Sun Chaser is a well-designed, solar-based energy harvesting system that automatically recalculates the direction of a solar panel to ensure it is always facing the sun. Mounted on a rotating disc, the solar panel’s orientation is calculated using the registered GPS position. With an external compass, the internal accelerometer, a DC motor and stepper motor, you can determine the solar panel’s exact position. The system uses the Renesas RDKRL78G13 evaluation board running the Micrium µC/OS-III real-time kernel.

[Video: ]

Water Heater by Solar Concentration: This solar water heater is powered by the RL78 evaluation board and designed to deflect concentrated amounts of sunlight onto a water pipe for continual heating. The deflector, armed with a counterweight for easy tilting, automatically adjusts the angle of reflection for maximum solar energy using the lowest power consumption possible.

RL78-based solar water heater (Source: P. Berquin)

Air Quality Mapper: Want to make sure the air along your daily walking path is clean? The Air Quality Mapper is a portable device designed to track levels of CO2 and CO gasses for constructing “Smog Maps” to determine the healthiest routes. Constructed with an RDKRL78G13, the Mapper receives location data from its GPS module, takes readings of the CO2 and CO concentrations along a specific route and stores the data in an SD card. Using a PC, you can parse the SD card data, plot it, and upload it automatically to an online MySQL database that presents the data in a Google map.

Air quality mapper design (Source: R. Alvarez Torrico)

Wireless Remote Solar-Powered “Meteo Sensor”: You can easily measure meteorological parameters with the “Meteo Sensor.” The RL78 MCU-based design takes cyclical measurements of temperature, humidity, atmospheric pressure, and supply voltage, and shares them using digital radio transceivers. Receivers are configured for listening of incoming data on the same radio channel. It simplifies the way weather data is gathered and eases construction of local measurement networks while being optimized for low energy usage and long battery life.

The design takes cyclical measurements of temperature, humidity, atmospheric pressure, and supply voltage, and shares them using digital radio transceivers. (Source: G. Kaczmarek)

Portable Power Quality Meter: Monitoring electrical usage is becoming increasingly popular in modern homes. The Portable Power Quality Meter uses an RL78 MCU to read power factor, total harmonic distortion, line frequency, voltage, and electrical consumption information and stores the data for analysis.

The portable power quality meter uses an RL78 MCU to read power factor, total harmonic distortion, line frequency, voltage, and electrical consumption information and stores the data for analysis. (Source: A. Barbosa)

High-Altitude Low-Cost Experimental Glider (HALO): The “HALO” experimental glider project consists of three main parts. A weather balloon is the carrier section. A glider (the payload of the balloon) is the return section. A ground base section is used for communication and display telemetry data (not part of the contest project). Using the REFLEX flight simulator for testing, the glider has its own micro-GPS receiver, sensors and low-power MCU unit. It can take off, climb to pre-programmed altitude and return to a given coordinate.

High-altitude low-cost experimental glider (Source: J. Altenburg)

Autonomous Mobile Robot (Part 1): Overview & Hardware

Welcome to “Robot Boot Camp.” In this two-part article series, I’ll explain what you can do with a basic mobile machine, a few sensors, and behavioral programming techniques. Behavioral programming provides distinct advantages over other programming techniques. It is independent of any environmental model, and it is more robust in the face of sensor error, and the behaviors can be stacked and run concurrently.

My objectives for my recent robot design were fairly modest. I wanted to build a robot that could cruise on its own, avoid obstacles, escape from inadvertent collisions, and track a light source. I knew that if I could meet such objective other more complex behaviors would be possible (e.g., self-docking on low power). There certainly many commercial robots on the market that could have met my requirements. But I decided that my best bet would be to roll my own. I wanted to keep things simple, and I wanted to fully understand the sensors and controls for behavioral autonomous operation. The TOMBOT is the fruit of that labor (see Photo 1a). A colleague came up with the name TOMBOT in honor of its inventor, and the name kind of stuck.

Photo 1a—The complete TOMBOT design. b—The graphics display is nice feature.

In this series of articles, I’ll present lessons learned and describe the hardware/software design process. The series will detail TOMBOT-style robot hardware and assembly, as well as behavior programming techniques using C code. By the end of the series, I’ll have covered a complete behavior programming library and API, which will be available for experimentation.

DESIGN BASICS

The TOMBOT robot is certainly minimal, no frills: two continuous-rotation, variable-speed control servos; two IR (850 nm) analog distance measurement sensors (4- to 30-cm range); two CdS photoconductive cells with good lux response in visible spectrum; and, finally, a front bumper (switch-activated) for collision detection. The platform is simple: servos and sensors on the left and right side of two level platforms. The bottom platform houses bumper, batteries, and servos. The top platform houses sensors and microcontroller electronics. The back part of the bottom platform uses a central skid for balance between the two servos (see Photo 1).

Given my background as a Microchip Developer and Academic Partner, I used a Microchip Technology PIC32 microcontroller, a PICkit 3 programmer/debugger, and a free Microchip IDE and 32-bit complier for TOMBOT. (Refer to the TOMBOT components list at the end of this article.)

It was a real thrill to design and build a minimal capability robot that can—with stacking programming behaviors—emulate some “intelligence.” TOMBOT is still a work in progress, but I recently had the privilege of demoing it to a first grade class in El Segundo, CA, as part of a Science Technology Engineering and Mathematics (STEM) initiative. The results were very rewarding, but more on that later.

BEHAVIORAL PROGRAMMING

A control system for a completely autonomous mobile robot must perform many complex information-processing tasks in real time, even for simple applications. The traditional method to building control systems for such robots is to separate the problem into a series of sequential functional components. An alternative approach is to use behavioral programming. The technique was introduced by Rodney Brooks out of the MIT Robotics Lab, and it has been very successful in the implementation of a lot of commercial robots, such as the popular Roomba vacuuming. It was even adopted for space applications like NASA’s Mars Rover and military seekers.

Programming a robot according to behavior-based principles makes the program inherently parallel, enabling the robot to attend simultaneously to all hazards it may encounter as well as any serendipitous opportunities that may arise. Each behavior functions independently through sensor registration, perception, and action. In the end, all behavior requests are prioritized and arbitrated before action is taken. By stacking the appropriate behaviors, using arbitrated software techniques, the robot appears to show (broadly speaking) “increasing intelligence.” The TOMBOT modestly achieves this objective using selective compile configurations to emulate a series of robot behaviors (i.e., Cruise, Home, Escape, Avoid, and Low Power). Figure 1 is a simple model illustration of a behavior program.

Figure 1: Behavior program

Joseph Jones’s Robot Programming: A Practical Guide to Behavior-Based Robotics (TAB Electronics, 2003) is a great reference book that helped guide me in this effort. It turns out that Jones was part of the design team for the Roomba product.

Debugging a mobile platform that is executing a series of concurrent behaviors can be daunting task. So, to make things easier, I implemented a complete remote control using a wireless link between the robot and a PC. With this link, I can enable or disable autonomous behavior, retrieve the robot sensor status and mode of operations, and curtail and avoid potential robot hazard. In addition to this, I implemented some additional operator feedback using a small graphics display, LEDs, and a simple sound buzzer. Note the TOMBOT’s power-up display in Photo 1b. We take Robot Boot Camp very seriously.

Minimalist System

As you can see in the robot’s block diagram (see Figure 2), the TOMBOT is very much a minimalist system with just enough components to demonstrate autonomous behaviors: Cruise, Escape, Avoid, and Home. All these behaviors require the use of left and right servos for autonomous maneuverability.

Figure 2: The TOMBOT system

The Cruise behavior just keeps the robot in motion in lieu of any stimulus. The Escape behavior uses the bumper to sense a collision and then 180° spin with reverse. The Avoid behavior makes use of continuous forward-looking IR sensors to veer left or right upon approaching a close obstacle. The Home behavior utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source. It all should add up to some very distinct “intelligent” operation. Figure 3 depicts the basic sensor and electronic layout.

Figure 3: Basic sensor and electronic layout

TOMBOT Assembly

The TOMBOT uses the low-cost robot platform (ArBot Chassis) and wheel set (X-Wheel assembly) from Budget Robotics (see Figure 4).

Figure 4: The platform and wheel set

A picture is worth a thousand words. Photo 2 shows two views of the TOMBOT prototype.

Photo 2a: The TOMBOT’s Sharp IR sensors, photo assembly, and more. b: The battery pack, right servo, and more.

Photo 2a shows dual Sharp IR sensors. Just below them is the photocell assembly. It is a custom board with dual CdS GL5528 photoconductive cells and 2.2-kΩ current-limiting resistors. Below this is a bumper assembly consisting of two SPDT Snap-action switches with lever (All Electronics Corp. CAT# SMS-196, left and right) fixed to a custom pre-fab plastic front bumper. Also shown is the solderless breakout board and left servo. Photo 2b shows the rechargeable battery pack that resides on the lower base platform and associated power switch. The electronics stack is visible. Here the XBee/Buzzer and graphics card modules residing on the 32-bit Experimenter. The Experimenter is plugged into a custom carrier board that allows for an interconnection to the solderless breakout to the rest of the system. Finally, note that the right servo is highlighted. The total TOMBOT package is not ideal; but remember, I’m talking about a prototype, and this particular configuration has held up nicely in several field demos.

I used Parallax (Futaba) continuous-rotation servos. They use a three-wire connector (+5 V, GND, and Control).

Figure 5 depicts a second-generation bumper assembly.  The same snap-action switches with extended levers are bent and fashioned to interconnect a bumper assembly as shown.

Figure 5: Second-generation bumper assembly

TOMBOT Electronics

A 32-bit Micro Experimenter is used as the CPU. This board is based the high-end Microchip Technology PIC32MX695F512H 64-pin TQFP with 128-KB RAM, 512-KB flash memory, and an 80-MHz clock. I did not want to skimp on this component during the prototype phase. In addition the 32-bit Experimenter supports a 102 × 64 monographic card with green/red backlight controls and LEDs. Since a full graphics library was already bundled with this Experimenter graphics card, it also represented good risk reduction during prototyping phase. Details for both cards are available on the Kiba website.

The Experimenter supports six basic board-level connections to outside world using JP1, JP2, JP3, JP4, BOT, and TOP headers.  A custom carrier board interfaces to the Experimenter via these connections and provides power and signal connection to the sensors and servos. The custom carrier accepts battery voltage and regulates it to +5 VDC. This +5 V is then further regulated by the Experimenter to its native +3.3-VDC operation. The solderless breadboard supports a resistor network to sense a +9-V battery voltage for a +3.3-V PIC processor. The breadboard also contains an LM324 quad op-amp to provide a buffer between +3.3-V logic of the processor and the required +5-V operation of the servo. Figure 6 is a detailed schematic diagram of the electronics.

Figure 6: The design’s circuitry

A custom card for the XBee radio carrier and buzzer was built that plugs into the Experimenter’s TOP and BOT connections. Photo 3 shows the modules and the carrier board. The robot uses a rechargeable 1,600-mAH battery system (typical of mid-range wireless toys) that provides hours of uninterrupted operation.

Photo 3: The modules and the carrier board

PIC32 On-Chip Peripherals

The major PIC32 peripheral connection for the Experimenter to rest of the system is shown. The TOMBOT uses PWM for servo, UART for XBee, SPI and digital for LCD, analog input channels for all the sensors, and digital for the buzzer and bumper detect. The key peripheral connection for the Experimenter to rest of the system is shown in Figure 7.

Figure 7: Peripheral usage

The PIC32 pinouts and their associated Experimenter connections are detailed in Figure 8.

Figure 8: PIC32 peripheral pinouts and EXP32 connectors

The TOMBOT Motion Basics and the PIC32 Output Compare Peripheral

Let’s review the basics for TOMBOT motor control. The servos use the Parallax (Futaba) Continuous Rotation Servos. With two-wheel control, the robot motion is controlled as per Table 1.

Table 1: Robot motion

The servos are controlled by using a 20-ms (500-Hz) pulse PWM pattern where the PWM pulse can from 1.0 ms to 2.0 ms. The effects on the servos for the different PWM are shown in Figure 9.

Figure 9: Servo PWM control

The PIC32 microcontroller (used in the Experimenter) has five Output Compare modules (OCX, where X =1 , 2, 3, 4, 5). We use two of these peripherals, specifically OC3, OC4 to generate the PWM to control the servo speed and direction. The OCX module can use either 16 Timer2 (TMR2) or 16 Timer3 (TMR3) or combined as 32-bit Timer23 as a time base and for period (PR) setting for the output pulse waveform. In our case, we are using Timer23 as a PR set to 20 ms (500 Hz). The OCXRS and OCXR registers are loaded with a 16-bit value to control width of the pulse generated during the output period. This value is compared against the Timer during each period cycle. The OCX output starts high and then when a match occurs OCX logic will generate a low on output. This will be repeated on a cycle-by-cycle basis (see Figure 10).

Figure 10: PWM generation

Next Comes Software

We set the research goals and objectives for our autonomous robot. We covered the hardware associated with this robot and in the next installment we will describe the software and operation.

Tom Kibalo holds a BSEE from City College of New York and an MSEE from the University of Maryland. He as 39 years of engineering experience with a number of companies in the Washington, DC area. Tom is an adjunct EE facility member for local community college, and he is president of Kibacorp, a Microchip Design Partner.

MCU-Based Prosthetic Arm with Kinect

James Kim—a biomedical student at Ryerson University in Toronto, Canada—recently submitted an update on the status of an interesting prosthetic arm design project. The design features a Freescale 9S12 microcontroller and a Microsoft Kinect, which tracks arm movements that are then reproduced on the prosthetic arm.

He also submitted a block diagram.

Overview of the prosthetic arm system (Source: J. Kim)

Kim explains:

The 9S12 microcontroller board we use is Arduino form-factor compatible and was coded in C using Codewarrior.  The Kinect was coded in C# using Visual Studio using the latest version of Microsoft Kinect SDK 1.5.  In the article, I plan to discuss how the microcontroller was set up to do deterministic control of the motors (including the timer setup and the PID code used), how the control was implemented to compensate for gravitational effects on the arm, and how we interfaced the microcontroller to the PC.  This last part will involve a discussion of data logging as well as interfacing with the Kinect.

The Kinect tracks a user’s movement and the prosthetic arm replicates it. (Source: J. Kim, YouTube)

The system includes:

Circuit Cellar intends to publish an article about the project in an upcoming issue.

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.

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 (www.geology.smu.edu/~dpa-www/myrobots.html) 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).