Client Profile: Digi International, Inc

Contact: Elizabeth Presson
elizabeth.presson@digi.com

Featured Product: The XBee product family (www.digi.com/xbee) is a series of modular products that make adding wireless technology easy and cost-effective. Whether you need a ZigBee module or a fast multipoint solution, 2.4 GHz or long-range 900 MHz—there’s an XBee to meet your specific requirements.

XBee Cloud Kit

Digi International XBee Cloud Kit

Product information: Digi now offers the XBee Wi-Fi Cloud Kit (www.digi.com/xbeewificloudkit) for those who want to try the XBee Wi-Fi (XB2B-WFUT-001) with seamless cloud connectivity. The Cloud Kit brings the Internet of Things (IoT) to the popular XBee platform. Built around Digi’s new XBee Wi-Fi
module, which fully integrates into the Device Cloud by Etherios, the kit is a simple way for anyone with an interest in M2M and the IoT to build a hardware prototype and integrate it into an Internet-based application. This kit is suitable for electronics engineers, software designers, educators, and innovators.

Exclusive Offer: The XBee Wi-Fi Cloud Kit includes an XBee Wi-Fi module; a development board with a variety of sensors and actuators; loose electronic prototyping parts to make circuits of your own; a free subscription to Device Cloud; fully customizable widgets to monitor and control connected devices; an open-source application that enables two-way communication and control with the development board over the Internet; and cables, accessories, and everything needed to connect to the web. The Cloud Kit costs $149.

Designing Wireless Data Gloves

Kevin Marinelli, IT manager for the Mathematics Department at the University of Connecticut, recently answered CC.Post’s newsletter invitation to readers to tell us about their wearable electronics projects. Kevin exhibited his project,  “Wireless Data Gloves,” at the World Maker Faire New York in September. He spoke with Circuit Cellar Managing Editor Mary Wilson about the gloves, which are based on an Adafruit ATmega32U4 breakout board, use XBee modules for wireless communication, and enable wearers to visually manipulate data and 3-D graphics.

MARY: Tell us a little bit about yourself and your educational and professional background.

KEVIN: I am originally from Sydney, Nova Scotia, in Canada. From an early age I have

Kevin Marinelli

Kevin Marinelli

always been interested in taking things apart and creating new things. My degrees are a Bachelor’s in Computer Science from Dalhousie University in Halifax, Nova Scotia, and a Master’s in Computer Science from the University of New Brunswick in Fredericton, New Brunswick. I am currently working on my PhD in Computer Science at the University of Connecticut (UConn).

My first full-time employment was with ITS (the computer center) at Dalhousie University. After eight years, I moved on to an IT management position the Ocean Mapping Group at the University of New Brunswick. I am currently the IT manager for the Mathematics Department at  UConn.

I am also an active member of MakeHartford, which is a local group of makers in Hartford, Connecticut.

MARY: Describe the wireless data gloves you recently exhibited at the World Maker Faire in New York. What inspired the idea?

KEVIN: The idea was initially inspired 20 years ago when using a Polhemus 6 Degree-of-Freedom sensor for manipulating computer graphics when I was at the University of New Brunswick. The device used magnetic fields to locate a sensor in three-dimensional space and detect its orientation. The combined location and orientation data provides data with six degrees of freedom. I have been interested in creating six degrees of freedom input devices ever since. With the Arduino and current sensor technologies, that is now possible.

Wireless data gloves on display at World Maker Faire New York. (Photo: Rohit Mehta)

Wireless data gloves on display at World Maker Faire New York. (Photo: Rohit Mehta)

MARY: What do the gloves do? What applications are there? Can you provide an example of who might use them and for what purpose?

KEVIN: The data gloves allow me to use my hands to wirelessly transmit telemetry data to a base station computer, which collects the data and provides it to any application programs that need it.

There are a number of potential applications, such as manipulating 3-D computer graphics, measurement of data for medical applications, remote control of vehicles, remote control of animatronics and puppetry.

MARY: Can you tell me about the data gloves’s design and the components used?

KEVIN: The basic design guidelines were to make the gloves self-contained, lightweight, easy to program, wireless, and rechargeable. The main electronic components are an Adafruit ATmega32U4 breakout board  (Arduino Leonardo software compatible), a SparkFun 9d0f sensor board, an XBee Pro packet radio, a LiPo battery charger circuit, and a LiPo battery. These are all open hardware projects or, in the case of the battery, are ordinary consumer products.

The choice of the ATMega32U4 for the processor was made to provide a USB port without any external components such as an FTDI chip to convert between serial and USB communications. This frees up the serial port on the processor for communicating with the XBee radio.

For the sensors, the SparkFun 9dof board was perfect because of its miniscule size and

Top of glove

Top of glove

because it only requires four connections: two connections for power and two connections for I2C. The board has components with readily available data sheets, and there is access to working example code for the sensor board. This reduced the design work greatly by using an off-the-shelf product instead of designing one myself.

The choice of an 800-mAh LiPo battery provides an excellent lightweight rechargeable power supply in a small form factor. The relatively small battery powers the project for more than 24 h of continuous use.

Palm of glove

Palm of glove

A simple white cotton glove acts as the structure to mount the electronics. For user-controlled input, the glove has conductive fabric fingertips and palm. Touching a finger to the thumb, or the pad on the palm, closes an electrical pathway, which allows the microcontroller to detect the input.

For user-selectable input, each fingertip and the palm of the hand has a conductive fabric pad connected to the Adafruit microcontroller. The thumb and palm act as a voltage source, while the fingertips act as inputs to the microcontroller. This way, the microcontroller can detect which fingers are touching the thumb and the palm pads. Insulated wires of 30 gauge phosphor bronze are sewn into the glove to connect the pads to the microcontroller.

MARY: Are the gloves finished? What were some of the design challenges? Do you plan any changes to the design?

KEVIN: The initial glove design and second version of the prototype have been completed. The major design challenges were finding a microcontroller board with sufficient capabilities to fit on the back of a hand, and configuring the XBee radios. The data glove design will continue to evolve over the next year as newer and more compact components become available.

Initially I was designing and building my own microcontroller circuit based on the ATmega32U4, but Adafruit came out with a nice, usable, designed board for my needs. So I changed the design to use their board.

SparkFun has a well-designed micro USB-based LiPo battery charger circuit. This would have been ideal for my project except that it does not have an On/Off switch and only has some through-hole solder points for powering an external project. I used their CadSoft EAGLE files to redesign the circuit to make it slightly more compact, added in a power switch and a JST connector for the power output for projects.

The XBee radios were an interesting challenge on their own. My initial design used the standard XBee, but that caused communication complications when using multiple data gloves simultaneously. In reading Robert Faludi’s book Building Wireless Sensor Networks: With ZigBee, XBee, Arduino, and Processing, I learned that the XBee Pro was more suited to my needs because it could be configured on a private area network (PAN) with end-nodes for the data gloves and a coordinator for the base station.

One planned future change is to switch to the surface-mount version of the XBee Pro. This will reduce both the size and weight of the electronics for the project.

The current significant design challenge I am working on is how to prevent metal fatigue in the phosphor bronze wires as they bend when the hand and fingers flex. The fatigue problem occurs because I use a small diamond file to remove the Kapton insulation on the wires. This process introduces small nicks or makes the wires too thin, which then promotes the metal fatigue.

A third version is in the design stage. The new design will replace the SparkFun 9dof board with a smaller single-chip sensor, which I hope can be mounted directly on the Adafruit ATmega32U4 board.

MARY: What new skills or technologies did you learn from the project, if any?

KEVIN: Along the way to creating the gloves, I learned a great deal about modern electronics. My previous skills in electronics were learned in the ’70s with single-sided circuits with through-hole components and pre-made circuit boards. I can now design and create double-sided circuit boards with primarily surface-mounted components. For initial prototype designs, I use double-sided photosensitized circuit boards and etch them at home.

Learning to program Arduino boards and Arduino clones has been incredible. The fact that the boards can be programmed using C in a nice IDE with lots of support libraries for common programming tasks makes the platform an incredibly efficient tool. Having an enormous following makes it very easy to find technical support for solving problems with Arduino products and making Arduino clones.

Wireless networking is a key component for the success of the project. I was lucky to have a course in wireless sensor network design at UConn, which taught me how to leverage wireless technology and avoid many of the pitfalls. That, combined with some excellent reference books I found, insured that the networking is stable. The network design provides for more network bandwidth than a single pair of data gloves require, so it is feasible to have multiple people collaborating manipulating the same on the same project.

Designing microcontroller circuits using EAGLE has been an interesting experience. While most of the new components I use regularly in designs are available in libraries from Adafruit and SparkFun, I occasionally have to design my own parts in EAGLE. Using EAGLE to its fullest potential will still take some time, but I have become reasonably proficient with it.

For soldering, I mostly still use a standard temperature controlled soldering iron with a standard tip. Amazingly, this allows me to solder 0402 resistors and capacitors and up to 100 pitch chips. When I have components that need to be soldered under the surface, I use solder paste and a modified electric skillet. This allows me to directly control the temperature of the soldering and gives me direct access to monitoring the process.

The battery charger circuit on my data glove is hand soldered and has a number of 0402-sized components, as  well as a micro USB connector, which also is a challenge to hand solder properly.

MARY: Are there similar “data gloves” out there? How are yours different?

There are a number of data glove projects, which can be found on the Internet. Some are commercial products, while others are academic projects.

My gloves are unique in that they are lightweight and self-contained on the cotton glove. All other projects that you can find on the Internet are either hard-wired to a computer or have components such as the microcontroller, batteries, or radio strapped to the arm or body.

Also, because the main structure is a self-contained cotton glove; the gloves do not interfere with other activities such as typing on a keyboard, using a mouse, writing with a pen, or even drinking from a glass. This was quite handy when developing the software for the glove because I could test the software and make programming corrections without having the inconvenience of putting the gloves on and taking them off repeatedly.

MARY: Are you working on any other projects you’d like to briefly tell us about?

KEVIN: At UConn, we are lucky to have one of the few academic programs in puppetry in the US. In the spring, I plan on taking a fine arts course at UConn in designing and making marionette puppets. This will allow me to expand the use of my data gloves into controlling and manipulating puppets for performance art.

I am collaborating on designing circuit boards with a number of people in Hartford. The more interesting collaborations are with artists, where they think differently about technology than I do. Balam Soto of Open Wire Labs is a new media artist and one of the creative artists I collaborate with regularly. He is also a member of MakeHartford and presents at Maker Faires.

MARY: What was the response to the wireless data gloves at World Maker Faire New York?

KEVIN: The response to the data gloves was overwhelmingly positive. People were making comparisons to the Nintendo Power Glove and to the movie “Minority Report.” Several musicians commented that the gloves should be excellent for performing and recording virtual musical instruments such as a guitar, trumpet and drums.

For the demonstration, I showed a custom application; which allowed both hands (or two people) to interactively manipulate points and lines on a drawing. Many people were encouraged to use the gloves for themselves, which enhanced the quality of the feedback I received.

The gloves are large-sized to fit my hands, which was quite a challenge for younger children to use because their hands were “lost” in the gloves. Even with the size challenge, it was fun watching younger children manipulating the objects on the computer screen.

I look forward to the Maker Faire next year, when I will have implemented the newer design for the data gloves and will have additional software to demonstrate. I plan on trying to put together a presentation on some form of performance art using the data gloves.

Small Plug-In Embedded Cellular Modem

Skywire plug-in modem

Skywire plug-in modem

The Skywire is a small plug-in embedded cellular modem. It uses a standard XBee form factor and 1xRTT CDMA operating mode to help developers minimize hardware and network costs. Its U.FL port ensures antenna flexibility.

The Skywire modem features a Telit CE910-DUAL wireless module and is available with bundled CDMA 1xRTT data plans from leading carriers, enabling developers to add fully compliant cellular connectivity without applying for certification. Future versions of the Skywire will support GSM and LTE. Skywire is smaller than many other embedded solutions and simple to deploy due to its bundled carrier service plans.

Skywire is available with a complete development kit that includes the cellular modem, a baseboard, an antenna, a power supply, debug cables, and a cellular service plan. The Skywire baseboard is an Arduino shield, which enables direct connection to an Arduino microcontroller.

Skywire modems cost $129 individually and $99 for 1,000-unit quantities. A complete development kit including the modem costs $262.

NimbeLink, LLC
www.nimbelink.com

Q&A: Andrew Spitz (Co-Designer of the Arduino-Based Skube)

Andrew Spitz is a Copenhagen, Denmark-based sound designer, interaction designer, programmer, and blogger studying toward a Master’s interaction design at the Copenhagen Institute of Interaction Design (CIID). Among his various innovative projects is the Arduino-based Skube music player, which is an innovative design that enables users to find and share music.

The Arduino-based Skube

Spitz worked on the design with Andrew Nip, Ruben van der Vleuten, and Malthe Borch. Check out the video to see the Skube in action.

On his blog SoundPlusDesign.com, Spitz writes:

It is a fully working prototype through the combination of using ArduinoMax/MSP and an XBee wireless network. We access the Last.fm API to populate the Skube with tracks and scrobble, and using their algorithms to find similar music when in Discover mode.

The following is an abridged  version of an interview that appears in the December 2012 issue of audioXpress magazine, a sister publication of Circuit Cellar magazine..

SHANNON BECKER: Tell us a little about your background and where you live.

Andrew Spitz: I’m half French, half South African. I grew up in France, but my parents are South African so when I was 17, I moved to South Africa. Last year, I decided to go back to school, and I’m now based in Copenhagen, Denmark where I’m earning a master’s degree at the Copenhagen Institute of Interaction Design (CID).

SHANNON: How did you become interested in sound design? Tell us about some of your initial projects.

Andrew: From the age of 16, I was a skydiving cameraman and I was obsessed with filming. So when it was time to do my undergraduate work, I decided to study film. I went to film school thinking that I would be doing cinematography, but I’m color blind and it turned out to be a bigger problem than I had hoped. At the same time, we had a lecturer in sound design named Jahn Beukes who was incredibly inspiring, and I discovered a passion for sound that has stayed with me.

Shannon: What do your interaction design studies at CIID entail? What do you plan to do with the additional education?

Andrew: CIID is focused on a user-centered approach to design, which involves finding intuitive solutions for products, software, and services using mostly technology as our medium. What this means in reality is that we spend a lot of time playing, hacking, prototyping, and basically building interactive things and experiences of some sort.

I’ve really committed to the shift from sound design to interaction design and it’s now my main focus. That said, I feel like I look at design from the lens of a sound designer as this is my background and what has formed me. Many designers around me are very visual, and I feel like my background gives me not only a different approach to the work but also enables me to see opportunities using sound as the catalyst for interactive experiences. Lots of my recent projects have been set in the intersection among technology, sound, and people.

SHANNON: You have worked as a sound effects recordist and editor, location recordist and sound designer for commercials, feature films, and documentaries. Tell us about some of these experiences?

ANDREW: I love all aspects of sound for different reasons. Because I do a lot of things and don’t focus on one, I end up having more of a general set of skills than going deep with one—this fits my personality very well. By doing different jobs within sound, I was able to have lots of different experiences, which I loved! nLocation recording enabled me to see really interesting things—from blowing up armored vehicles with rocket-propelled grenades (RPGs) to interviewing famous artists and presidents. And, documentaries enabled me to travel to amazing places such as Rwanda, Liberia, Mexico, and Nigeria. As a sound effects recordist on Jock of the Bushvelt, a 3-D animation, I recorded animals such as lions, baboons, and leopards in the South African bush. With Bakgat 2, I spent my time recording and editing rugby sounds to create a sound effects library. This time in my life has been a huge highlight, but I couldn’t see myself doing this forever. I love technology and design, which is why I made the move...

SHANNON: Where did the idea for Skube originate?

Andrew: Skube came out of the Tangible User Interface (TUI) class at CIID where we were tasked to rethink audio in the home context. So understanding how and where people share music was the jumping-off point for creating Skube.

We realized that as we move more toward a digital and online music listening experience, current portable music players are not adapted for this environment. Sharing mSkube Videousic in communal spaces is neither convenient nor easy, especially when we all have such different taste in music.

The result of our exploration was Skube. It is a music player that enables you to discover and share music and facilitates the decision process of picking tracks when in a communal setting.

audioXpress is an Elektor International Media publication.

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.