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.

Propeller Games (P2): Game Logic

In the first part of this article series on Parallax Propeller-based gaming projects, I hooked up the hardware for the Hi/Lo game on a breadboard. Now I’ll write the game logic. The finished code is available here.

The power of the Propeller chip is in its multiple CPU cores. But you can do just fine with one processor, especially for a simple game like Hi/Lo. You program each of the processors in assembly or in the Parallax-invented SPIN high-level language. Assembly programs run blazingly fast directly in the CPU core. SPIN compiles to a binary format that is interpreted by the SPIN interpreter (written in assembly). The interpreter runs in the CPU core.

The CPU core is designed for speed, but it only has room for 512 instructions. The SPIN interpreter fetches your program byte by byte from shared RAM. Your code runs more slowly, but you have 32K of space to work with. I’ll use assembly in future projects, but SPIN is perfect for Hi/Lo.

A SPIN file is a collection of functions and data (shared by all functions in the file). The functions use local variables kept on a call stack. You break up your programming task into smaller functions that build on one another and call each other. You pass parameters to the functions and use the return values. It is all very similar to C programming though the syntax is different. The interpreter begins with the first function in your file no matter what you name it.

I started the project with a test “main” and the functions to control the Hi/Lo speaker, LEDs, and switches. 

This function plays a tone on the speaker (Source: C. Cantrell)

The “playTone” function generates a square wave on the speaker pin. The “cnt” register is a built-in 32-bit value that increments with every system clock. I run the prop stick full out with an 80-MHz clock configuration (5M-Hz crystal with a *16 internal multiplier). The “waitcnt” instruction puts the CPU to sleep until the system clock reaches the requested value. There are two waits in the loop that generates one clock cycle. Thus the generated frequency is roughly 40 MHz/freq. I say “roughly” because each instruction takes a little time to execute. The actual generated frequency is slightly less. There are much better ways to generate a precise square wave with the propeller hardware, but this is function is easy to understand, and it works fine for the simple Hi/Lo game.

The LED display is a collection of 14 segments and two dots that are turned on or off by writing a 1 or 0 to the Propeller port pins. The program use a look-up table that defines the various segment patterns to be shown.

The output pin bit patterns for numeric digits (Source: C. Cantrell)

The look-up table is defined in a data (DAT) section in the program. The SPIN language allows you to define binary constants with a “%” prefix. You can use the underscore (“_”) anywhere in any numeric constant to make it easier to read. The comment line just above the table shows how the segments map to bit positions in the propeller’s output register.

The “drawNumber” function displays a two digit value on the display. The function first divides the value by 10. The whole part (value/10) is the digit in the 10s place. The remainder (value//10) is the digit in the 1s place. The function looks up the separate patterns, ORs them together, and writes to the “outa” output register to toggle the lights.

I wrote LED functions to “drawBlank” (blank the display) and “drawHi” (show “Hi”) and “drawLo” (show “Lo”). These one-line functions are easy enough to code inline where they are used. But having the functions in distinct blocks makes the using code easier to understand and modify.

The functions to read the buttons return Boolean values: true if the switch is pressed or false if it is not. When a button is pressed, the corresponding input bit in “ina” goes to “1.” There are five buttons and five functions—one for each. There is also an “isAny” function to detect if any button is pressed.

The function returns "true" if a button is pressed. (Source: C. Cantrell)

The game itself has two distinct modes. The “splash” mode flashes “Hi/Lo” and waits for a player to press a button. This is an “attract” mode that draws players to the game. The “splash” function returns when a button has been pressed. The “playGame” function is the game logic. The function returns when the game is over. Thus the main loop simply calls the two functions in an infinite loop.

???????????. (Source: C. Cantrell)

The “splash” function calls “drawHi” and “drawLo” with a pause between.

The function attracts a player to the game. (Source: C. Cantrell)

The “pauseStopOnAnyButton” function counts up the delay and watches for “isAny”. It aborts the pause and returns true if a button is pressed. The “SPLASH_DELAY” is defined in the constant (“CON”) area of the program. I keep all “magic numbers” like delay counts and tone values in the CON area for easy tweaking.

The “playGame” function uses three helper functions: “getPlayerGuess,” “showWin,” and “showHint.” The “showWin” and “showHint” functions are just a couple of lines each and could be coded inline. Having them separate allows you to enhance the visual effects without changing the game logic code.

The “getPlayerGuess” does the real work of the game. It watches the buttons and changes the displayed number accordingly.

The function takes the player input. (Source: C. Cantrell)

The “getPlayerGuess” function is an infinite loop with five IF checks for each button. When the middle button is pressed the function returns with the global “playerGuess” variable holding the input value. The other buttons increment or decrement the digits on the display. Each IF block checks for overflow and plays a feedback tone.

There you have it: a simple Hi Lo game. The visual and input effects are in separate functions ready to be spruced up. I bet your solution has many more bells and whistles! I look forward to reading your ideas in the comments of this blog.

Next time I’ll wrap up the Hi Lo game with a little multitasking. I’ll write parallel programs to run in two new CPU cogs to manage sound effects and the LED display.

Chris Cantrell earned an MSEE from the University of Alabama. He writes Java and Flex for Emerson Network Power in Huntsville, Alabama. Circuit Cellar published 10 of his articles between 2002 and 2012: Issue 145, Issue 152, Issue 161, Issue 184, Issue 187, Issue 193, Issue 205, Issue 209, Issue 139, and Issue 260.

Propeller Games (P1): Hi Lo

Welcome to the Propeller Games! In a few installments, I’ll present several gaming projects that use the Parallax Propeller chip. The Propeller is perfect for gaming with its multiple CPU cores to handle simultaneous gaming activities and its on-board video generation circuitry.

My first game project is the classic “higher/lower” game, where the computer thinks of a number between 0 and 99 and you guess it. You have probably seen this played as the “Clock Game” on The Price is Right TV show, though some contestants struggle with a basic binary search algorithm. (You can watch videos of the game at YouTube.com.)

This entire project is built on a solderless breadboard. If you are new to the Propeller, this is the perfect project to get acquainted with the hardware and programming. If you are a Propeller guru, you will enjoy the nostalgia of gaming on LEDs and push buttons. Grab your breadboard and follow along.

Parts

What you’ll need:

  • Breadboard and wire
  • 9-VDC wall transformer
  • Parallax PropStick USB
  • Two-digit 7-segment LED display
  • Five SPST pushbuttons
  • Audio speaker
  • Sixteen 200-Ω resistors
  • Five 10-kΩ resistors

The board and basic parts

The Parallax Propeller chip requires a few external components. You need a 3.3-VDC power regulator, a crystal, and a USB-to-serial converter. You also need a serial EEPROM if you want the Propeller to run your program at power up. You can buy all these separately and wire them up on the breadboard. Or you can save time and space with the Parallax PropStick USB. It combines all these external parts on the same footprint as the 40-pin Propeller chip.

I bought the LED display for this project from Mouser Electronics (part number 630-HDSP-521E). The large red segments are common anode (common ground). You supply positive voltage from a propeller port pin through a 220-Ω resistor to light the segments.

I bought the push buttons from Pololu Robotics & Electronics (part number 1400). They are specially designed for mounting on a breadboard. One side of each switch is connected to 3.3 V and the other is connected to a propeller port pin and pulled to ground with a 10-kΩ resistor.

I bought the speaker from Digi-Key (part number 668-1140-ND). The negative terminal of the speaker hooks to the breadboard’s ground. The positive terminal hooks directly to a Propeller port pin.

A speaker, one LED segment, and one switch wired to the Propeller

I placed four of the switches on the corners of the display. These switches are used as up/down inputs for each digit allowing the player to select a number from 00 to 99. The fifth button to the right of the display is the “Enter” button.

The photo above shows the speaker, one LED segment, and one switch wired to the Propeller. I tested the hardware and software incrementally as I hooked it up instead of trying to debug the final system as a whole.

The Parallax Propeller Tool is the free graphical Integrated Development Environment (IDE) you use to develop code for the Propeller. The code editor colors and highlights your work making it easy to see functions and keywords. It also manages indentation. The SPIN programming language uses indentation to identify code blocks much as Python does.

Basic hardware test

The code above is my basic hardware test. The CON (constants) section at the top configures the clock speed of the chip: 5 MHz × 16 = 80 MHz. The OBJ (object) section pulls in the serial terminal driver library. This library object allows you to use the USB cable for both programming and an input/output terminal. The one second pause on line 12 gives you time to switch from the IDE program to the terminal program on your PC once the code is downloaded. The Propeller tool download includes the parallax serial terminal for your PC.

Line 10 sets general I/O pin 0 (P0) as an output (they are inputs by default). Line 17 reads the switch connected to P11 and turns the LED segment on or off accordingly. Line 18 prints the state of the input pins to the PC terminal in an infinite loop.

Parallax serial terminal

It took me a while to warm up to the SPIN programming language. It is syntactically very different from C and its derivatives. But conceptually it is familiar: you break your software up into functions and local/global variables. In the end the simplicity of the syntax and the friendliness of the IDE won me over!

I really like the “Propeller font” used in the Propeller Tool IDE. It includes special symbols you can use to draw circuits and timing diagrams in your code comments. For instance:

Check out the font

Now to wire up the rest of the LEDs and switches. I thought about wiring the left digit to the first port byte and the right digit to the second port byte so that the segments are laid out the same way in each byte. This would make the software easier to write. But the pins for the segments on the display are kind of scattered around at random. The wiring is easier and neater if you wire the segments from the bottom of the display to the bottom of the propeller and from the top of the display to the top of the propeller. You can make up for the scattered pattern with software.

Two tips: Wire the segments from the bottom of the display to the bottom of the Propeller. Wire from the top of the display to the top of the Propeller.

Hi/Lo breadboard layout

That’s it for this installment. Now I’ll clean up all the little wire stripping sprinkles I left around my workbench. In Part 2 of this series, I’ll switch modes from hardware to software and write the Hi/Lo game. Hopefully you are following along. Until next time, may the COGs be ever in your favor.

Chris Cantrell earned an MSEE from the University of Alabama. He writes Java and Flex for Emerson Network Power in Huntsville, Alabama. Circuit Cellar published 10 of his articles between 2002 and 2012: Issue 145, Issue 152, Issue 161, Issue 184, Issue 187, Issue 193, Issue 205, Issue 209, Issue 139, and Issue 260.

Project Spotlight: “3D-Printed Mouse” Circuitry & Design

I get to meet and interact with creative engineers and researchers around the world who are working on innovative MCU-based projects. Some of them show up at our office to chat. Others I meet with when I travel to California for events like the Embedded Systems Conference. But many of the most interesting people and projects I find are on the Net. A perfect example is David Mellis, whose projects and research grabbed my attention recently while I was browsing the MIT Media Lab website. He is a PhD student in the High-Low Tech research group at the MIT Media Lab.

Mellis gave me permission to write about the projects and post some of the photos from his website, so let’s take a look at one of them—the “3D-Printed Mouse.”

The 3D-Printed Mouse design (Source: D. Mellis)

Check out the mouse strapped to a hand.

The mouse in hand (Source: D. Mellis)

Mellis writes:

This mouse combines a traditional electronic circuit board and components with a 3D-printed enclosure. The mouse is open-source: the original files necessary to make or modify its design are available for download below.

Download

Enclosure
Rhino: mouse.3dm
STLs: mouse-shell.stl, mouse-base.stl

Circuit board
Eagle files: mouse.brd, mouse.sch
Gerbers: mouse-gerbers.zip
Schematic: mouse.pdf

Component Datasheets

Button: SS-P_1110.pdf
Mouse Chip: ADNS2620.pdf

Code: hid-mouse.zip

Mellis notes that the circuitry and code are based on SparkFun’s ADNS2620 Evaluation Board, but “have been modified to include buttons.”

The first prototype with the SparkFun board (Source: D. Mellis)

Click here to access the project site.

 

Wireless Data Control for Remote Sensor Monitoring

Circuit Cellar has published dozens of interesting articles about handy wireless applications over the years. And now we have another innovative project to report about. Circuit Cellar author Robert Bowen contacted us recently with a link to information about his iFarm-II controller data acquisition system.

The iFarm-II controller data acquisition system (Source: R. Bowen)

The design features two main components. Bowen’s “iFarm-Remote” and the “iFarm-Base controller” work together to as an accurate remote wireless data acquisition system. The former has six digital inputs (for monitoring relay or switch contacts) and six digital outputs (for energizing a relay’s coil). The latter is a stand-alone wireless and internet ready controller. Its LCD screen displays sensor readings from the iFarm-Remote controller. When you connect the base to the Internet, you can monitor data reading via a browser. In addition, you can have the base email you notifications pertaining to the sensor input channels.

You can connect the system to the Internet for remote monitoring. The Network Settings Page enables you to configure the iFarm-Base controller for your network. (Source: R. Bowen)

Bowen writes:

The iFarm-II Controller is a wireless data acquisition system used to remotely monitor temperature and humidity conditions in a remote location. The iFarm consists of two controllers, the iFarm-Remote and iFarm-Base controller. The iFarm-Remote is located in remote location with various sensors (supports sensors that output +/-10VDC ) connected. The iFarm-Remote also provides the user with 6-digital inputs and 6-digital outputs. The digital inputs may be used to detect switch closures while the digital outputs may be used to energize a relay coil. The iFarm-Base supports either a 2.4GHz or 900Mhz RF Module.

The iFarm-Base controller is responsible for sending commands to the iFarm-Remote controller to acquire the sensor and digital input status readings. These readings may be viewed locally on the iFarm-Base controllers LCD display or remotely via an Internet connection using your favorite web-browser. Alarm conditions can be set on the iFarm-Base controller. An active upper or lower limit condition will notify the user either through an e-mail or a text message sent directly to the user. Alternatively, the user may view and control the iFarm-Remote controller via web-browser. The iFarm-Base controllers web-server is designed to support viewing pages from a PC, Laptop, iPhone, iTouch, Blackberry or any mobile device/telephone which has a WiFi Internet connection.—Robert Bowen, http://wireless.xtreemhost.com/

iFarm-Host/Remote PCB Prototype (Source: R. Bowen)

Robert Bowen is a senior field service engineer for MTS Systems Corp., where he designs automated calibration equipment and develops testing methods for customers involved in the material and simulation testing fields. Circuit Cellar has published three of his articles since 2001: