A Well-Organized Workspace for Home Automation Systems

Organization and plenty of space to work on projects are the main elements of Dean Boman’s workspace (see Photo 1). Boman, a retired systems engineer, says most of his projects involve home automation. He described some of his workspace features via e-mail:

My test equipment suite consists of a Rigol digital oscilloscope, a triple-output power supply, various single-output power supplies, and several Microchip Technology in-circuit development tools.

I have also built a simple logic analyzer, an FPGA programmer, and an EPROM programmer. For PCB fabrication, I have a complete setup from MG Chemicals to expose, develop, etch, and plate boards up to about 6” × 9” in size.

Photo 1: Boman’s workbench includes overhead cabinets to help reduce clutter. The computer in the foreground is his web server and main home-automation system controller. (Source: D. Boman)

Photo 1: Boman’s workbench includes overhead cabinets to help reduce clutter. The computer in the foreground is his web server and main home-automation system controller. (Source: D. Boman)

Boman is currently troubleshooting a small 1-W ham radio transmitter (see Photo 2).

Photo 2: Boman is currently troubleshooting a small 1-W ham radio transmitter (Source: D. Boman)

Photo 2: Here is his workbench with the radio transmitter. (Source: D. Boman)

Boman says the 10’ long countertop surface (in the background in Photo 3) is:

Great for working on larger items (e.g., computers). It is also a great surface for debugging designs as you have plenty of room for test equipment, drawings, and datasheets.

Photo 3: Boman’s setup includes plenty of spacefor large projects. (Source: D. Boman)

Photo 3: Boman’s setup includes plenty of room for large projects. (Source: D. Boman)

Most of Boman’s projects involve in-home automation (see Photo 4).

My current system provides functions such as: security system monitoring, irrigation control, water leak detection, temperature monitoring, electrical usage monitoring, fire detection, access control, weather monitoring, water usage monitoring, solar hot water system control, and security video recording. I also have an Extra Class ham radio license (WE7J) and build some ham radio equipment.

Here is how he described his system setup:

The shelf on the top contains the network routers and the security system. The cabinets on the wall contain an irrigation system controller and a network monitor for network management. I was fortunate in that we built a custom home a few years ago so I was able to run about two miles of cabling in the walls during construction.

Photo 4: Boman has various elements of his home-automation control system mounted on the wall. (Source: D. Boman)

Photo 4: Boman has various elements of his home-automation control system mounted on the wall. (Source: D. Boman)

Boman uses small containers to hold an inventory of surface-mount components (see Photo 5).

Over the past 10 years or so I have migrated to doing surface-mount designs almost exclusively. I have found that once you get over the learning curve, the surface-mount designs are much simpler to design and troubleshoot then the through-hole type technology. The printed wiring boards are also much simpler to fabricate, which is important since I etch my own boards.

Photo 5: Surface-mount components are neatly corralled in containers. (Source: D. Boman)

Photo 5: Surface-mount components are neatly corralled in containers. (Source: D. Boman)

Overall, Boman’s setup is well suited to his interests. He keeps everything handy in well-organized containers and has plenty of testing space In addition, his custom-built home enabled him to run behind-the-scenes cabling, freeing up valuable workspace.

Do you want to share images of your workspace, hackspace, or “circuit cellar”? Send your images and space info to editor<at>circuitcellar.com.

CC25 Is Now Available

Ready to take a look at the past, present, and future of embedded technology, microcomputer programming, and electrical engineering? CC25 is now available.

Check out the issue preview.

We achieved three main goals by putting together this issue. One, we properly documented the history of Circuit Cellar from its launch in 1988 as a bi-monthly magazine
about microcomputer applications to the present day. Two, we gathered immediately applicable tips and tricks from professional engineers about designing, programming, and completing electronics projects. Three, we recorded the thoughts of innovative engineers, academics, and industry leaders on the future of embedded technologies ranging from
rapid prototyping platforms to 8-bit chips to FPGAs.

The issue’s content is gathered in three main sections. Each section comprises essays, project information, and interviews. In the Past section, we feature essays on the early days of Circuit Cellar, the thoughts of long-time readers about their first MCU-based projects, and more. For instance, Circuit Cellar‘s founder Steve Ciarcia writes about his early projects and the magazine’s launch in 1988. Long-time editor/contributor Dave Tweed documents some of his favorite projects from the past 25 years.

The Present section features advice from working hardware and software engineers. Examples include a review of embedded security risks and design tips for ensuring system reliability. We also include short interviews with professionals about their preferred microcontrollers, current projects, and engineering-related interests.

The Future section features essays by innovators such as Adafruit Industries founder Limor Fried, ARM engineer Simon Ford, and University of Utah professor John Regehr on topics such as the future of DIY engineering, rapid prototyping, and small-RAM devices. The section also features two different sets of interviews. In one, corporate leaders such as Microchip Technology CEO Steve Sanghi and IAR Systems CEO Stefan Skarin speculate on the future of embedded technology. In the other, engineers such as Stephen Edwards (Columbia University) offer their thoughts about the technologies that will shape our future.

As you read the issue, ask yourself the same questions we asked our contributors: What’s your take on the history of embedded technology? What can you design and program today? What do you think about the future of embedded technology? Let us know.

CC269: Break Through Designer’s Block

Are you experiencing designer’s block? Having a hard time starting a new project? You aren’t alone. After more than 11 months of designing and programming (which invariably involved numerous successes and failures), many engineers are simply spent. But don’t worry. Just like every other year, new projects are just around the corner. Sooner or later you’ll regain your energy and find yourself back in action. Plus, we’re here to give you a boost. The December issue (Circuit Cellar 269) is packed with projects that are sure to inspire your next flurry of innovation.

Turn to page 16 to learn how Dan Karmann built the “EBikeMeter” Atmel ATmega328-P-based bicycle computer. He details the hardware and firmware, as well as the assembly process. The monitoring/logging system can acquire and display data such as Speed/Distance, Power, and Recent Log Files.

The Atmel ATmega328-P-based “EBikeMeter” is mounted on the bike’s handlebar.

Another  interesting project is Joe Pfeiffer’s bell ringer system (p. 26). Although the design is intended for generating sound effects in a theater, you can build a similar system for any number of other uses.

You probably don’t have to be coerced into getting excited about a home control project. Most engineers love them. Check out Scott Weber’s garage door control system (p. 34), which features a MikroElektronika RFid Reader. He built it around a Microchip Technology PIC18F2221.

The reader is connected to a breadboard that reads the data and clock signals. It’s built with two chips—the Microchip 28-pin PIC and the eight-pin DS1487 driver shown above it—to connect it to the network for testing. (Source: S. Weber, CC269)

Once considered a hobby part, Arduino is now implemented in countless innovative ways by professional engineers like Ed Nisley. Read Ed’s article before you start your next Arduino-related project (p. 44). He covers the essential, but often overlooked, topic of the Arduino’s built-in power supply.

A heatsink epoxied atop the linear regulator on this Arduino MEGA board helped reduce the operating temperature to a comfortable level. This is certainly not recommended engineering practice, but it’s an acceptable hack. (Source: E. Nisley, CC269)

Need to extract a signal in a noisy environment? Consider a lock-in amplifier. On page 50, Robert Lacoste describes synchronous detection, which is a useful way to extract a signal.

This month, Bob Japenga continues his series, “Concurrency in Embedded Systems” (p. 58). He covers “the mechanisms to create concurrently in your software through processes and threads.”

On page 64, George Novacek presents the second article in his series, “Product Reliability.” He explains the importance of failure rate data and how to use the information.

Jeff Bachiochi wraps up the issue with a article about using heat to power up electronic devices (p. 68). Fire and a Peltier device can save the day when you need to charge a cell phone!

Set aside time to carefully study the prize-winning projects from the Reneas RL78 Green Energy Challenge (p. 30). Among the noteworthy designs are an electrostatic cleaning robot and a solar energy-harvesting system.

Lastly, I want to take the opportunity to thank Steve Ciarcia for bringing the electrical engineering community 25 years of innovative projects, essential content, and industry insight. Since 1988, he’s devoted himself to the pursuit of EE innovation and publishing excellence, and we’re all better off for it. I encourage you to read Steve’s final “Priority Interrupt” editorial on page 80. I’m sure you’ll agree that there’s no better way to begin the next 25 years of innovation than by taking a moment to understand and celebrate our past. Thanks, Steve.

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.

CC 25th Anniversary Issue: The Past, Present, and Future of Embedded Design

In celebration of Circuit Cellar’s 25th year of publishing electrical engineering articles, we’ll release a special edition magazine around the start of 2013. The issue’s theme will be the past, present, and future of embedded electronics. World-renowned engineers, innovators, academics, and corporate leaders will provide essays, interviews, and projects on embedded design-related topics such as mixed-signal designs, the future of 8-bit chips, rapid prototyping, FPGAs, graphical user interfaces, embedded security, and much more.

Here are some of the essay topics that will appear in the issue:

  • The history of Circuit Cellar — Steve Ciarcia (Founder, Circuit Cellar, Engineer)
  • Do small-RAM devices have a future? — by John Regehr (Professor, University of Utah)
  • A review of embedded security risks — by Patrick Schaumont (Professor, Virginia Tech)
  • The DIY electronics revolution — by Limor Fried (Founder, Adafruit Industries)
  • The future of rapid prototyping — by Simon Ford (ARM mbed, Engineer)
  • Robust design — by George Novacek (Engineer, Retired Aerospace Executive)
  • Twenty-five essential embedded system design principles — by Bob Japenga (Embedded Systems Engineer, Co-Founder, Microtools Inc.)
  • Mixed-signal designs: the 25 errors you’ll make at least once — by Robert Lacoste (Founder, Alciom; Engineer)
  • User interface tips for embedded designers — by Curt Twillinger (Engineer)
  • Thinking in terms of hardware platforms, not chips — by Clemens Valens (Engineer, Elektor)
  • The future of FPGAs — by Colin O’Flynn (Engineer)
  • The future of e-learning for engineers and programmers — by Marty Hauff (e-Learning Specialist, Altium)
  • And more!

Interviews

We’ll feature interviews with embedded industry leaders and forward-thinking embedded design engineers and programmers such as:

More Content

In addition to the essays and interviews listed above, the issue will also include:

  • PROJECTS will be available via QR codes
  • INFOGRAPHICS depicting tech-related likes, dislikes, and ideas of hundreds of engineers.
  • And a few surprises!

Who Gets It?

All Circuit Cellar subscribers will receive the 25th Anniversary issue. Additionally, the magazine will be available online and promoted by Circuit Cellar’s parent company, Elektor International Media.

Get Involved

Want to get involved? Sponsorship and advertising opportunities are still available. Find out more by contacting Peter Wostrel at Strategic Media Marketing at 978-281-7708 (ext. 100) or peter@smmarketing.us. Inquire about editorial opportunities by contacting the editorial department.

About Circuit Cellar

Steve Ciarcia launched Circuit Cellar magazine in 1988. From its beginning as “Ciarcia’s Circuit Cellar,” a popular, long-running column in BYTE magazine, Ciarcia leveraged his engineering knowledge and passion for writing about it by launching his own publication. Since then, tens of thousands of readers around the world have come to regard Circuit Cellar as the #1 source for need-to-know information about embedded electronics, design, and programming.