Raspberry Pi-Based Network Monitoring Device

In 2012, Al Anderson, IT director at Salish Kootenai College in Pablo, MT, and his team wired the dorms and student housing units at the small tribal college with fiber and outdoor CAT 5 cable to provide reliable Internet service to students. “Our prior setup was wireless and did not provide very good service,” Anderson says.

The 25 housing units, each with a small unmanaged Ethernet switch, were daisy chained in several different paths. Anderson needed a way to monitor the links from the system’s Simple Network Management Protocol (SNMP) network monitoring software, Help/Systems’s InterMapper. He also wanted to ensure the switches installed inside the sun-exposed utility boxes wouldn’t get too hot.

The Raspberry Pi is a small SBC based on an ARM processor. Its many I/O ports make it very useful for embedded devices that need a little more power than the typical 8-bit microcontroller.

Photo 1: The Raspberry Pi is a small SBC based on an ARM processor. Its many I/O ports make it very useful for embedded devices that need a little more power than the typical 8-bit microcontroller.

His Raspberry Pi-based solution is the subject of an article appearing in Circuit Cellar’s April issue. “We chose the Raspberry Pi because it was less expensive, we had several on hand, and I wanted to see what I could do with it,” Anderson says (see Photo 1).

The article walks readers through each phase of the project:

“I installed a Debian Linux distro, added an I2C TMP102 temperature sensor from SparkFun Electronics, wrote a small Python program to get the temperature via I2C and convert it to Fahrenheit, installed an SNMP server on Linux, added a custom SNMP rule to display the temperature from the script, and finally wrote a custom SNMP MIB to access the temperature information as a string and integer.”

Setting up the SBC and Linux was simple, Anderson says. “The prototype Raspberry Pi has now been running since September 2012 without any problems,” he says in his article. “It has been interesting to see how the temperature fluctuates with the time of day and the level of network activity. As budget and time permit, we will be installing more of these onto our network.”

In the following excerpt, Anderson discusses the project’s design, implementation, and OS installation and configuration. For more details on a project inspired, in part, by the desire to see what a low-cost SBC can do, read Anderson’s full article in the April issue.

DESIGN AND IMPLEMENTATION
Figure 1 shows the overall system design. The TMP102 is connected to the Raspberry Pi via I2C. The Raspberry Pi is connected to the network via its Ethernet port. The monitoring system uses TCP/IP over the Ethernet network to query the Raspberry Pi via SNMP. The system is encased in a small acrylic Adafruit Industries case, which we used because it is inexpensive and easy to customize for the sensor.

The system is designed around the Raspberry Pi SBC. The Raspberry Pi uses the I2C protocol to query the Texas Instruments TMP102 temperature sensor. The Raspberry Pi is queried via SNMP.

Figure 1: The system is designed around the Raspberry Pi SBC. The Raspberry Pi uses the I2C protocol to query the Texas Instruments TMP102 temperature sensor. The Raspberry Pi is queried via SNMP.

Our first step was to set up the Raspberry Pi. We started by installing the OS and the various software packages needed. Next, we wrote the Python script that queries the I2C temperature sensor. Then we configured the SNMP daemon to run the Python script when it is queried. With all that in place, we then set up the SNMP monitoring software that is configured with a custom MIB and a timed query. Finally, we modified the Raspberry Pi case to expose the temperature sensor to the air and installed the device in its permanent location.

OS INSTALLATION AND CONFIGURATION
The Raspberry Pi requires a Linux OS compiled to run on an ARM processor, which is the brain of the device, to be installed on an SD card. It does not have a hard drive. Setting up the SD card is straightforward, but you cannot simply copy the files onto the card. The OS has to be copied in such a way that the SD card has a boot sector and the Linux partitioning and file structure is properly maintained. Linux and Mac OS X users can use the dd command line utility to copy from the OS’s ISO image. Windows users can use a utility (e.g., Win32DiskImager) to accomplish the same thing. A couple of other utilities can be used to copy the OS onto the SD card, but I prefer using the command line.

A Debian-based distribution of Linux seems to be the most commonly used Linux distribution on the Raspberry Pi, with the Raspbian “wheezy” as the recommended distribution. However, for this project I chose Adafruit Learning Systems’s Occidentalis V0.2 Linux distribution because it had several hardware-hacker features rolled into the distribution, including the kernel modules for the temperature sensor. This saved me some work getting those installed and debugged.

Before you can copy the OS to the SD card, you need to download the ISO image. The Resources section of this article lists several sources including a link to the Adafruit Linux distribution. Once you have an ISO image downloaded, you can copy it to the SD card. The Resources section also includes a link to an Embedded Linux Wiki webpage, “RPi Easy SD Card Setup,” which details this copying process for several OSes.

The quick and dirty instructions are to somehow get the SD card hooked up to your computer, either using a built-in SD reader or a peripheral card reader. I used a USB attached reader. Then you need to format the card. The best format is FAT32, since it will get reformatted by the copy command anyway. Next, use your chosen method to copy the OS onto the card. On Linux or Mac OS X, the command:

dd bs=4M if=~/linux_distro.img of=/dev/sdd

will properly copy the OS onto the SD card.

You will need to change two important things in this command for your system. First, the
if parameter, which is the name the in file (i.e., your ISO image) needs to match the file you downloaded. Second, the of device (i.e., the out file or our SD drive in this case) needs to match the SD card. Everything, including devices, is a file in Linux, in case you are wondering why your SD drive is considered a file. We will see this again in a bit with the I2C device. You can toast your hard drive if you put the wrong device path in here. If you are unsure about this, you may want to use a GUI utility so you don’t overwrite your hard drive.

Once the OS is copied onto the SD card, it is time to boot up the Raspberry Pi. A default username and password are available from wherever you download the OS. With our OS, the defaults are “pi” and “raspberry.” Make it your first mission to change that password and maybe even add a new account if your project is going to be in production.

Another thing you may have to change is the IP address configuration on the Ethernet interface. By default, these distributions use DHCP to obtain an address. Unless you have a need otherwise, it is best to leave that be. If you need to use a static IP address, I have included a link in the Resources section with instructions on how to do this in Linux.

To access your Raspberry Pi, hook up a local keyboard and monitor to get to a command line. Once you have the network running and you know the IP address, you can use the SSH utility to gain access via the network.

To get SNMP working on the Raspberry Pi, you need to install two Debian packages: snmpd and snmp. The snmpd package is the actual SNMP server software that will enable other devices to query for SNMP on this device. The second package, snmp, is the client. It is nice to have this installed for local troubleshooting.

We used the Debian package manager, apt-get, to install these packages. The commands also must be run as the root or superuser.

The sudo apt-get install snmpd command installs the snmpd software. The sudo part runs the apt-get command as the superuser. The install and snmpd parts of the command are the arguments for the apt-get command.

Next we issued the
sudo apt-get install snmp command, which installed the SNMP client. Issue the ps -ax | grep snmpd command to see if the snmpd daemon is running after the install. You should see something like this:

1444 ? S 14:22 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid

If you do not see a line similar to this, you can issue the sudo /etc/init.d/snmpd command start to start the service. Once it is running, it is time to turn your attention to the Python script that reads the temperature sensor. Configure the SNMP daemon after you get the Python script running.

The Raspberry Pi’s final installation is shown. The clear acrylic case can be seen along with the Texas Instruments TMP102 temperature sensor, which is glued below the air hole drilled into the case. We used a modified ribbon cable to connect the various TMP102 pins to the Raspberry Pi.

The Raspberry Pi’s final installation is shown. The clear acrylic case can be seen along with the Texas Instruments TMP102 temperature sensor, which is glued below the air hole drilled into the case. We used a modified ribbon cable to connect the various TMP102 pins to the Raspberry Pi.

Q&A: Networking Expert Dru Lavigne

Dru Lavigne wasn’t always interested in networking applications. I recently interviewed her about how she discovered UNIX and launched her career as an OS specialist and technical writer. She also described her “to-do” list, which includes more writing, and her hopes for the future of the BSD OS.—Nan Price, Associate Editor

 

Dru LavigneNAN: What is your current occupation?

DRU: I’m the lead tech writer for iXsystems, a hardware solutions provider and corporate sponsor of the FreeNAS and PC-BSD open-source projects. Since both of these projects publish a comprehensive user’s guide with each software release, most of my time is spent making sure each guide is kept up to date as changes are made to these OSes. I’m also involved in the FreeBSD Documentation Project and I am currently assisting in updating and preparing the FreeBSD Handbook for publication in a two-volume format.

NAN: What is the FreeBSD Foundation?

DRU: The FreeBSD Foundation is a 501.c3 nonprofit that provides financial support and a legal entity for the FreeBSD Project.

The FreeBSD Foundation provides grants so developers can attend conferences and developer summits, sponsors developers to work on specific software projects that would benefit the FreeBSD community, interacts with companies that use FreeBSD to determine their needs, and assists in introducing developers to the community. As a director, I assist in fundraising and advocacy, reviewing project proposals, and developing relationships.

NAN: What is BSD? What is the difference between BSD and Linux?

DRU: BSD is a UNIX-like OS that was originally developed at the University of California Berkeley in the 1970s. When the university stopped developing the OS, several open-source projects began to continue development.

Its lineage differs from Linux as Linux is derived from a different UNIX branch known as SysV. Traditionally, the most noticeable difference is that SysV systems use run levels whereas BSD systems do not. The release engineering process also differs between BSD and Linux. BSD projects release an entire OS with a set of base tools included in the OS’s userland. The entire OS has a release engineering team that is responsible for the release and a security team that is responsible for security advisories until a release reaches its end-of-life (EOL). In contrast, Linux itself is only the kernel. Each distro integrates that kernel into its installer, package management system, and userland to create a complete OS.

NAN: How long have you been using BSD? When and how did you become interested?

DRU: I started using FreeBSD in 1997. I went “cold turkey” by installing it on my only computer and learned how to do what I needed to do as I needed to do it. Once I was comfortable with FreeBSD, I ventured into learning how to use NetBSD and OpenBSD, and when PC-BSD came along, I switched to that as my main desktop system.

NAN: Describe your involvement with the BSD Certification Group.

DRU: I founded the BSD Certification Group to create a community-based and psychometrically valid certification exam for system administrators of BSD OSes. The group is composed of volunteers who have been involved in BSD for quite some time as educators, authors, and/or system administrators. We have worked hard to provide a globally affordable examination that provides real value to employers.

NAN: You’ve written several books, including BSD Hacks, The Best of FreeBSD Basics and The Definitive Guide to PC-BSD. What can readers expect to learn from the books?

DRU: How to be comfortable on a UNIX system and how to think using the logic of a UNIX system.

NAN: Do you consider your books introductory or are they written for more experienced engineers?

DRU: These books are written in the style: “Now that you have BSD, did you know that you can do these cool things?” I’m a hands-on person and I like to know what I can do and to understand what I’m seeing when something I do acts differently than I expected it to.

The great thing about UNIX is that you can learn how to do something useful now, even if you have never seen a UNIX command line before. And, even if you’ve been around forever, there is always something you haven’t come across before or a cool new way to do something that you haven’t thought of before. So, these books can appeal to both the introductory user (the main target audience) as well as the advanced user (who will still pick up a trick or two before passing the book along to an introductory user).

NAN: Are you currently working on or planning any books or projects?

DRU: I do have a to-do list, book-wise. It’s interesting that I currently write the equivalent of three 300ish page books per year, but these are available for free online at doc.freenas.org  and wiki.pcbsd.org.

In addition, my current big project is the two-volume set for the FreeBSD Handbook, which will be a good 900 pages when it is complete. Once that project is finished, next in line is modernizing The Best of FreeBSD Basics for FreeBSD 10.x. Then, I’d like to write a second BSD Hacks-type book.

NAN: What do you consider to be the “next big thing” in the industry?

DRU: Since my expertise is in BSD, I’ll frame my answer from that perspective.
The first is creating usable frameworks for securing/sandboxing existing non-secure applications. FreeBSD is leading the development and research in this area in its Capsicum framework (see the article “Capsicum: Practical Capabilities for UNIX” on the University of Cambridge website).

The second is modern file systems that aren’t limited by the hardware restrictions that were around when most file systems were created. Examples include the OpenZFS storage platform and DragonFly BSD’s HAMMER file system.

NAN: Give us some background information. Where are you located? Where and what did you study?

DRU: I’m a recent transplant to Northwest Arkansas, having lived in Canada for many years. I went back to school in my early 30s to get a technical diploma in Networking and Telecommunications. I also earned the following certifications: MCSE, CNE, CCNA, CCSA, Security+, and probably others, which I have since forgotten.

NAN: How did you become interested in OSes and IT?

DRU: I was working in a dead-end position for a municipal department (low pay, very low glass ceiling) and wanted to expand my horizons. Many of our clients were being referred to a technical college for a networking program at a time when networking was a “hot” topic.

I had no idea what networking was, but figured it couldn’t be any worse than what I was doing, so I negotiated half days with my employer so I could attend classes. I quickly found that the course interested me and I seemed to be good at it.

Toward the end of the program, when I was researching employment opportunities, I noticed that the interesting and well-paying positions wanted UNIX experience. Having no idea what that was, and having no money as a poor student, I did an Internet search for “free UNIX.” The first hit was freebsd.org. I went to the website and my gut told me “this is it.” The rest, as they say, is history.

Turn Your Android Device into an Application Tool

A few years ago, the Android Open Accessory initiative was announced with the aim of making it easier for hardware manufacturers to create accessories that work with every Android device. Future Technology Devices International (FTDI) joined the initiative and last year introduced the FTD311D multi-interface Android host IC. The goal was to enable engineers and designers to make effective use of tablets and smartphones with the Android OS, according to Circuit Cellar columnist Jeff Bachiochi.

The FTD311D “provides an instant bridge from an Android USB port(B) to peripheral hardware over general purpose input-out (GPIO), UART, PWM, I2C Master, SPI Slave, or SPI Master interfaces,” Bachiochi says.

In the magazine’s December issue Bachiochi takes a comprehensive look at the USB Android host IC and how it works. By the end of his article, readers will have learned quite a bit about how to use FTDI’s apps and the FT311D chip to turn an Android device into their own I/0 tool.

Bachiochi used the SPI Master demo to read key presses and set LED states on this SPI slave 16-key touch panel.

Bachiochi used the SPI Master demo to read key presses and set LED states on this SPI slave 16-key touch panel.

Here is how Bachiochi describes the FT311D and its advantages:

The FT311D is a full-speed USB host targeted at providing access to peripheral hardware from a USB port on an Android device. While an Android device can be a USB host, many are mobile devices with limited power. For now, these On-The-Go (OTG) ports will be USB devices only (i.e., they can only connect to a USB host as a USB device).

Since the USB host is responsible for supplying power to a USB peripheral device, it would be bad design practice to enable a USB peripheral to drain an Android mobile device’s energy. Consequently, the FT311D takes on the task of USB host, eliminating any draw on the Android device’s battery.

All Android devices from V3.1 (Honeycomb) support the Android Open Accessory Mode (AOAM). The AOAM is the complete reverse of the conventional USB interconnect. This game-changing approach to attaching peripherals enables three key advantages. First, there is no need to develop special drivers for the hardware; second, it is unnecessary to root devices to alter permissions for loading drivers; and third, the peripheral provides the power to use the port, which ensures the mobile device battery is not quickly drained by the external hardware being attached.

Since the FT311D handles the entire USB host protocol, USB-specific firmware programming isn’t required. As the host, the FT311D must inquire whether the connected device supports the AOAM. If so, it will operate as an Open Accessory Mode device with one USB BULK IN endpoint and one USB BULK OUT endpoint (as well as the control endpoint.) This interface will be a full-speed (12-Mbps) USB enabling data transfer in and out.

The AOAM USB host has a set of string descriptors the Android OS is capable of reading. These strings are (user) associated with an Android OS application. The Android then uses these strings to automatically start the application when the hardware is connected. The FT311D is configured for one of its multiple interfaces via configuration inputs at power-up. Each configuration will supply the Android device with a unique set of string descriptors, therefore enabling different applications to run, depending on its setup.

The FT311D’s configuration determines whether each application will have access to several user interface APIs that are specific to each configuration.

The article goes on to examine the various interfaces in detail and to describe a number of demo projects, including a multimeter.

Many of Bachiochi's projects use printable ASCII text commands and replies. This enables a serial terminal to become a handy user I/O device. This current probe circuit outputs its measurements in ASCII-printable text.

Many of Bachiochi’s projects use printable ASCII text commands and replies. This enables a serial terminal to become a handy user I/O device. This current probe circuit outputs its measurements in ASCII-printable text.

Multimeters are great tools. They have portability that enables them to be brought to wherever a measurement must be made. An Android device has this same ability. Since applications can be written for these devices, they make a great portable application tool. Until the AOAM’s release, there was no way for these devices to be connected to any external circuitry and used as an effective tool.

I think FTDI has bridged this gap nicely. It provided a great interface chip that can be added to any circuit that will enable an Android device to serve as an effective user I/O device. I’ve used the chip to quickly interface with some technology to discover its potential or just test its abilities. But I’m sure you are already thinking about the other potential uses for this connection.

Bachiochi is curious to hear from readers about their own ideas.

If you think the AOAM has future potential, but you want to know what’s involved with writing Android applications for a specific purpose, send me an e-mail and I’ll add this to my list of future projects!

You can e-mail Bachiochi at jeff.bachiochi@imaginethatnow.com or post your comment here.

 

Autonomous Mobile Robot (Part 2): Software & Operation

I designed a microcontroller-based mobile robot that can cruise on its own, avoid obstacles, escape from inadvertent collisions, and track a light source. In the first part of this series, I introduced my TOMBOT robot’s hardware. Now I’ll describe its software and how to achieve autonomous robot behavior.

Autonomous Behavior Model Overview
The TOMBOT is a minimalist system with just enough components to demonstrate some simple autonomous behaviors: Cruise, Escape, Avoid, and Home behaviors (see Figure 1). All the behaviors require left and right servos for maneuverability. In general, “Cruise” just keeps the robot in motion in lieu of any stimulus. “Escape” uses the bumper to sense a collision and then 180 spin with reverse. “Avoid” makes use of continuous forward looking IR sensors to veer left or right upon approaching a close obstacle. Finally “Home” utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source.

Figure 1: High-level autonomous behavior flow

Figure 2 shows more details. The diagram captures the interaction of TOMBOT hardware and software. On the left side of the diagram are the sensors, power sources, and command override (the XBee radio command input). All analog sensor inputs and bumper switches are sampled (every 100 ms automatically) during the Microchip Technology PIC32 Timer 1 interrupt. The bumper left and right switches undergo debounce using 100 ms as a timer increment. The analog sensors inputs are digitized using the PIC32′s 10-bit ADC. Each sensor is assigned its own ADC channel input. The collected data is averaged in some cases and then made available for use by the different behaviors. Processing other than averaging is done within the behavior itself.

Figure 2: Detailed TOMBOT autonomous model

All behaviors are implemented as state machines. If a behavior requests motor control, it will be internally arbitrated against all other behaviors before motor action is taken. Escape has the highest priority (the power behavior is not yet implemented) and will dominate with its state machine over all the other behaviors. If escape is not active, then avoid will dominate as a result of its IR detectors are sensing an object in front of the TOMBOT less than 8″ away. If escape and avoid are not active, then home will overtake robot steering to sense track a light source that is immediately in front of TOMBOT. Finally cruise assumes command, and takes the TOMBOT in a forward direction temporarily.

A received command from the XBee RF module can stop and start autonomous operation remotely. This is very handy for system debugging. Complete values of all sensors and battery power can be viewed on graphics display using remote command, with LEDs and buzzer, announcing remote command acceptance and execution.

Currently, the green LED is used to signal that the TOMBOT is ready to accept a command. Red is used to indicate that the TOMBOT is executing a command. The buzzer indicates that the remote command has been completed coincident with the red led turning on.

With behavior programming, there are a lot of considerations. For successful autonomous operation, calibration of the photocells and IR sensors and servos is required. The good news is that each of these behaviors can be isolated (selectively comment out prior to compile time what is not needed), so that phenomena can be isolated and the proper calibrations made. We will discuss this as we get a little bit deeper into the library API, but in general, behavior modeling itself does not require accurate modeling and is fairly robust under less than ideal conditions.

TOMBOT Software Library
The TOMBOT robot library is modular. Some experience with C programming is required to use it (see Figure 3).

Figure 3: TOMBOT Library

The entire library is written using Microchip’s PIC32 C compiler. Both the compiler and Microchip’s 8.xx IDE are available as free downloads at www.microchip.com. The overall library structure is shown. At a highest level library has three main sections: Motor, I/O and Behavior. We cover these areas in some detail.

TOMBOT Motor Library
All functions controlling the servos’ (left and right wheel) operation is contained in this part of the library (see Listing1 Motor.h). In addition the Microchip PIC32 peripheral library is also used. Motor initialization is required before any other library functions. Motor initialization starts up both left and right servo in idle position using PIC32 PWM peripherals OC3 and OC4 and the dual Timer34 (32 bits) for period setting. C Define statements are used to set pulse period and duty cycle for both left and right wheels. These defines provide PWM varies from 1 to 2 ms for different speed CCW rotation over a 20-ms period and from 1.5 ms to 1 ms for CC rotation.

Listing 1: All functions controlling the servos are in this part of the library.

V_LEFT and V_RIGHT (velocity left and right) use the PIC32 peripheral library function to set duty cycle. The other motor functions, in turn, use V_LEFT and V_RIGHT with the define statements. See FORWARD and BACKWARD functions as an example (see Listing 2).

Listing 2: Motor function code examples

In idle setting both PWM set to 1-ms center positions should cause the servos not to turn. A servo calibration process is required to ensure center position does not result in any rotation. For the servos we have a set screw that can be used to adjust motor idle to no spin activity with a small Philips screwdriver.

TOMBOT I/O Library

This is a collection of different low level library functions. Let’s deal with these by examining their files and describing the function set starting with timer (see Listing 3). It uses Timer45 combination (full 32 bits) for precision timer for behaviors. The C defines statements set the different time values. The routine is noninterrupt at this time and simply waits on timer timeout to return.

Listing 3: Low-level library functions

The next I/O library function is ADC. There are a total of five analog inputs all defined below. Each sensor definition corresponds to an integer (32-bit number) designating the specific input channel to which a sensor is connected. The five are: Right IR, Left IR, Battery, Left Photo Cell, Right Photo Cell.

The initialization function initializes the ADC peripheral for the specific channel. The read function performs a 10-bit ADC conversion and returns the result. To faciliate operation across the five sensors we use SCAN_SENSORS function. This does an initialization and conversion of each sensor in turn. The results are placed in global memory where the behavior functions can access . SCAN_SENOR also performs a running average of the last eight samples of photo cell left and right (see Listing 4).

Listing 4: SCAN_SENOR also performs a running average of the last eight samples

The next I/O library function is Graphics (see Listing 5). TOMBOT uses a 102 × 64 monchrome graphics display module that has both red and green LED backlights. There are also red and green LEDs on the module that are independently controlled. The module is driven by the PIC32 SPI2 interface and has several control lines CS –chip select, A0 –command /data.

Listing 5: The Graphics I/O library function

The Graphics display relies on the use of an 8 × 8 font stored in as a project file for character generation. Within the library there are also cursor position macros, functions to write characters or text strings, and functions to draw 32 × 32 bit maps. The library graphic primitives are shown for intialization, module control, and writing to the module. The library writes to a RAM Vmap memory area. And then from this RAM area the screen is updated using dumpVmap function. The LED and backlight controls included within these graphics library.

The next part of I/O library function is delay (see Listing 6). It is just a series of different software delays that can be used by other library function. They were only included because of legacy use with the graphics library.

Listing 6: Series of different software delays

The next I/O library function is UART-XBEE (see Listing 7). This is the serial driver to configure and transfer data through the XBee radio on the robot side. The library is fairly straightforward. It has an initialize function to set up the UART1B for 9600 8N1, transmit and receive.

Listing 7: XBee library functions

Transmission is done one character at a time. Reception is done via interrupt service routine, where the received character is retrieved and a semaphore flag is set. For this communication, I use a Sparkfun XBee Dongle configured through USB as a COM port and then run HyperTerminal or an equivalent application on PC. The default setting for XBee is all that is required (see Photo 1).

Photo 1: XBee PC to TOMBOT communications

The next I/O library function is buzzer (see Listing 8). It uses a simple digital output (Port F bit 1) to control a buzzer. The functions are initializing buzzer control and then the on/off buzzer.

Listing 8: The functions initialize buzzer control

TOMBOT Behavior Library
The Behavior library is the heart of the autonomous TOMBOT and where integrated behavior happens. All of these behaviors require the use of left and right servos for autonomous maneuverability. Each behavior is a finite state machine that interacts with the environment (every 0.1 s). All behaviors have a designated priority relative to the wheel operation. These priorities are resolved by the arbiter for final wheel activation. Listing 9 shows the API for the entire Behavior Library.

Listing 9: The API for the entire behavior library

Let’s briefly cover the specifics.

  • “Cruise” just keeps the robot in motion in lieu of any stimulus.
  • “Escape” uses the bumper to sense a collision and then 180° spin with reverse.
  • “Avoid” makes use of continuous forward looking IR sensors to veer left or right upon approaching a close obstacle.
  • “Home” utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source.
  • “Remote operation” allows for the TOMBOT to respond to the PC via XBee communications to enter/exit autonomous mode, report status, or execute a predetermined motion scenario (i.e., Spin X times, run back and forth X times, etc.).
  • “Dump” is an internal function that is used within Remote.
  • “Arbiter” is an internal function that is an intrinsic part of the behavior library that resolves different behavior priorities for wheel activation.

Here’s an example of the Main function-invoking different Behavior using API (see Listing 10). Note that this is part of a main loop. Behaviors can be called within a main loop or “Stacked Up”. You can remove or stack up behaviors as you choose ( simply comment out what you don’t need and recompile). Keep in mind that remote is a way for a remote operator to control operation or view status.

Listing 10: TOMBOT API Example

Let’s now examine the detailed state machine associated with each behavior to gain a better understanding of behavior operation (see Listing 11).

Listing 11:The TOMBOT’s arbiter

The arbiter is simple for TOMBOT. It is a fixed arbiter. If either during escape or avoid, it abdicates to those behaviors and lets them resolve motor control internally. Home or cruise motor control requests are handled directly by the arbiter (see Listing 12).

Listing 12: Home behavior

Home is still being debugged and is not yet a final product. The goal is for the TOMBOT during Home is to steer the robot toward a strong light source when not engaged in higher priority behaviors.

The Cruise behavior sets motor to forward operation for one second if no other higher priority behaviors are active (see Listing 13).

Listing 13: Cruise behavior

The Escape behavior tests the bumper switch state to determine if a bump is detected (see Listing 14). Once detected it runs through a series of states. The first is an immediate backup, and then it turns around and moves away from obstacle.

Listing 14: Escape behavior

This function is a response to the remote C or capture command that formats and dumps (see Listing 15) to the graphics display The IR left and right, Photo left and Right, and battery in floating point format.

Listing 15: The dump function

This behavior uses the IR sensors and determines if an object is within 8″ of the front of TOMBOT (see Listing 16).

Listing 16: Avoid behavior

If both sensors detect a target within 8″ then it just turns around and moves away (pretty much like escape). If only the right sensor detects an object in range spins away from right side else if on left spins away on left side (see Listing 17).

Listing 17: Remote part 1

Remote behavior is fairly comprehensive (see Listing 18). There are 14 different cases. Each case is driven by a different XBee received radio character. Once a character is received the red LED is turned on. Once the behavior is complete, the red LED is turned off and a buzzer is sounded.

Listing 18: Remote part 2

The first case toggles Autonomous mode on and off. The other 13 are prescribed actions. Seven of these 13 were written to demonstrate TOMBOT mobile agility with multiple spins, back and forwards. The final six of the 13 are standard single step debug like stop, backward, and capture. Capture dumps all sensor output to the display screen (see Table 1).

Table 1: TOMBOT remote commands

Early Findings & Implementation
Implementation always presents a choice. In my particular case, I was interested in rapid development. At that time, I selected to using non interrupt code and just have linear flow of code for easy debug. This amounts to “blocking code.” Block code is used throughout the behavior implementation and causes the robot to be nonresponsive when blocking occurs. All blocking is identified when timeout functions occur. Here the robot is “blind” to outside environmental conditions. Using a real-time operating system (e.g., Free RTOS) to eliminate this problem is recommended.

The TOMBOT also uses photocells for homing. These sensitive devices have different responses and need to be calibrated to ensure correct response. A photocell calibration is needed within the baseline and used prior to operation.

TOMBOT Demo

The TOMBOT was successfully demoed to a large first-grade class in southern California as part of a Science, Technology, Engineering and Mathematics (STEM) program. The main behaviors were limited to Remote, Avoid, and Escape. With autonomous operation off, the robot demonstrated mobility and maneuverability. With autonomous operation on, the robot could interact with a student to demo avoid and escape behavior.

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.

Tech Highlights from Design West: RL78, AndroPod, Stellaris, mbed, & more

The Embedded Systems Conference has always been a top venue for studying, discussing, and handling the embedded industry’s newest leading-edge technologies. This year in San Jose, CA, I walked the floor looking for the tech Circuit Cellar and Elektor members would love to get their hands on and implement in novel projects. Here I review some of the hundreds of interesting products and systems at Design West 2012.

RENESAS

Renesas launched the RL78 Design Challenge at Design West. The following novel RL78 applications were particularly intriguing.

  • An RL78 L12 MCU powered by a lemon:

    A lemon powers the RL78 (Photo: Circuit Cellar)

  • An RL78 kit used for motor control:

    The RL78 used for motor control (Photo: Circuit Cellar)

  • An RL78 demo for home control applications:

    The RL78 used for home control (Photo: Circuit Cellar)

TEXAS INSTRUMENTS

Circuit Cellar members have used TI products in countless applications. Below are two interesting TI Cortex-based designs

A Cortex-M3 digital guitar (you can see the Android connection):

TI's digital guitar (Photo: Circuit Cellar)

Stellaris fans will be happy to see the Stellaris ARM Cortex -M4F in a small wireless application:

The Stellaris goes wireless (Photo: Circuit Cellar)

NXP mbed

Due to the success of the recent NXP mbed Design Challenge, I stopped at the mbed station to see what exciting technologies our NXP friends were exhibiting. They didn’t disappoint. Check out the mbed-based slingshot developed for playing Angry Birds!

mbed-Based sligshot for going after "Angry Birds" (Photo: Circuit Cellar)

Below is a video of the project on the mbedmicro YouTube page:

FTDI

I was pleased to see the Elektor AndroPod hard at work at the FTDI booth. The design enables users to easily control a robotic arm with Android smartphones and tablets.

FTDI demonstrates robot control with Android (Photo: Circuit Cellar)

As you can imagine, the possible applications are endless.

The AndroPod at work! (Photo: Circuit Cellar)