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: Robotics Mentor and Champion

Peter Matteson, a Senior Project Engineer at Pratt & Whitney in East Hartford, CT, has a passion for robotics. We recently discussed how he became involved with mentoring a high school robotics team, the types of robots the team designs, and the team’s success.—Nan Price, Associate Editor

 

NAN: You mentor a FIRST (For Inspiration and Recognition of Science and Technology) robotics team for a local high school. How did you become involved?

Peter Matteson

Peter Matteson

PETER: I became involved in FIRST in late 2002 when one of my fraternity brothers who I worked with at the time mentioned that FIRST was looking for new mentors to help the team the company sponsored. I was working at what was then known as UTC Power (sold off to ClearEdge Power Systems last year) and the company had sponsored Team 177 Bobcat Robotics since 1995.

After my first year mentoring the kids and experiencing the competition, I got hooked. I loved the competition and strategy of solving a new game each year and designing and building a robot. I enjoyed working with the kids, teaching them how to design and build mechanisms and strategize the games.

The FIRST team’s 2010 robot is shown.

The FIRST team’s 2010 robot is shown.

A robot’s articulating drive train is tested  on an obstacle (bump) at the 2010 competition.

A robot’s articulating drive train is tested on an obstacle (bump) at the 2010 competition.

NAN: What types of robots has your team built?

A temporary control board was used to test the drive base at the 2010 competition.

A temporary control board was used to test the drive base at the 2010 competition.

PETER: Every robot we make is purposely built for a specific game the year we build it. The robots have varied from arm robots with a 15’ reach to catapults that launch a 40” diameter ball, to Frisbee throwers, to Nerf ball shooters.

They have varied in drive train from 4 × 4 to 6 × 6 to articulating 8 × 8. Their speeds have varied from 6 to 16 fps.

NAN: What types of products do you use to build the robots? Do you have any favorites?

PETER: We use a variant of the Texas Instruments (TI) cRIO electronics kit for the controller, as is required per the FIRST competition rules. The motors and motor controllers we use are also mandated to a few choices. We prefer VEX Robotics VEXPro Victors, but we also design with the TI Jaguar motor controllers. For the last few years, we used a SparkFun CMUcam webcam for the vision system. We build with Grayhill encoders, various inexpensive limit switches, and gyro chips.

The team designed a prototype minibot.

The team designed a prototype minibot.

For pneumatics we utilize compressors from Thomas and VIAIR. Our cylinders are primarily from Bimba, but we also use Parker and SMC. For valves we use SMC and Festo. We usually design with clipart plastic or stainless accumulator tanks. Our gears and transmissions come from AndyMark, VEX Robotics’s VEXPro, and BaneBots.

The AndyMark shifter transmissions were a mainstay of ours until last year when we tried the VEXPro transmissions for the first time. Over the years, we have utilized many of the planetary transmissions from AndyMark, VEX Robotics, and BaneBots. We have had good experience with all the manufacturers. BaneBots had a shaky start, but it has vastly improved its products.

We have many other odds and ends we’ve discovered over the years for specific needs of the games. Those are a little harder to describe because they tend to be very specific, but urethane belting is useful in many ways.

NAN: Has your team won any competitions?

Peter’s FIRST team is pictured at the 2009 championship at the Georgia Dome in Atlanta, GA. (Peter is standing fourth from the right.)

Peter’s FIRST team is pictured at the 2009 championship at the Georgia Dome in Atlanta, GA. (Peter is standing fourth from the right.)

PETER: My team is considered one of the most successful in FIRST. We have won four regional-level competitions. We have always shined at the competition’s championship level when the 400 teams from the nine-plus countries that qualify vie for the championship.

In my years on the team, we have won the championship twice (2007 and 2010), been the championship finalist once (2011), won our division, made the final four a total of six times (2006–2011), and were division finalists in 2004.

A FIRST team member works on a robot “in the pits” at the 2011 Hartford, CT, regional competition.

A FIRST team member works on a robot “in the pits” at the 2011 Hartford, CT, regional competition.

Team 177 was the only team to make the final four more than three years in a row, setting the bar at six consecutive trips. It was also the only team to make seven trips to the final four, including in 2001.

NAN: What is your current occupation?

PETER: I am a Senior Project Engineer at Pratt & Whitney. I oversee and direct a team of engineers designing components for commercial aircraft propulsion systems.

NAN: How and when did you become interested in robotics?

PETER: I have been interested in robotics for as long as I can remember. The tipping point was probably when I took an industrial robotics course in college. That was when I really developed a curiosity about what I could do with robots.

The industrial robots course started with basic programming robots for tasks. We had a welding robot we taught the weld path and it determined on its own how to get between points.

We also worked with programming a robot to install light bulbs and then determine if the bulbs were working properly.

In addition to practical labs such as those, we also had to design the optimal robot for painting a car and figure out how to program it. We basically had to come up with a proposal for how to design and build the robot from scratch.

This robot from the 2008 competition holds a 40” diameter ball for size reference.

This robot from the 2008 competition holds a 40” diameter ball for size reference.

NAN: What advice do you have for engineers or students who are designing robots or robotic systems?

PETER: My advice is to clearly set your requirements at the beginning of the project and then do some research into how other people have accomplished them. Use that inspiration as a stepping-off point. From there, you need to build a prototype. I like to use wood, cardboard, and other materials to build prototypes. After this you can iterate to improve your design until it performs exactly as expected.

Wireless Data Links (Part 2): Transmitters and Antennas

If you built your own ham radio “back in the day,” you’ll recall the frustration of putting it together with components that were basic at best.

But as columnist George Novacek points out in the second installment of his series examining wireless data links: “Today you can purchase excellent, reasonably priced low-power gear for data communications off the shelf.”

Transmitter and receiver

Photo 1: SparkFun Electronics’s WRL-10524 transmitter and WRL-10532 receiver are low cost, basic, and work well.

Part 2 of Novacek’s series, appearing in the March issue, looks at transmitters and antennas.

In one section, Novacek expands upon the five basic data-transmitter modules—a data encoder, a modulator, a carrier frequency generator, an RF output amplifier, and an antenna:

Low-power data transmitters often integrate the modulator, the carrier frequency generator, and the amplifier into one circuit. A single transistor can do the job. I’ll discuss antennas later. When a transmitter and a receiver are combined into one unit, it’s called a transceiver.

Modulation may not be needed in some simple applications where the mere presence of a carrier is detected to initiate an action. A simple push button will suffice, but this is rarely used as it is subject to false triggering by other transmitters working in the area in the same frequency band.

Digital encoder and decoder ICs are available for simple devices (e.g., garage door openers) or keyless entry where just an on or off output is required from the receiver. These ICs generate a data packet for transmission. If the received packet matches the data stored in the decoder, an action is initiated. Typical examples include Holtek Semiconductor HT12E encoders and HT12D decoders and Freescale Semiconductor MC145026, MC145027, and MC145028 encoder and decoder pairs. For data communications a similar but more advanced scheme is used. I’ll address this when I discuss receivers (coming up in Part 3 of this series).

Novacek’s column goes on to explain modulation types, including OOK and ASK modulation:

OOK modulation is achieved by feeding the Data In line with a 0-to+V-level  datastream. ASK modulation can be achieved by the data varying the transistor biasing to swing the RF output between 100% and typically 30% to 50% amplitude. I prefer to add a separate modulator.

The advantage of ASK as opposed to OOK modulation is that the carrier is always present, thus the receiver is not required to repeatedly synchronize to it. Different manufacturers’ specifications claim substantially higher achievable data rates with ASK rather than OOK.

For instance, Photo 1 shows a SparkFun Electronics WRL-10534 transmitter and a WRL-10532 receiver set for 433.9 MHz (a 315-MHz set is also available), which costs less than $10. It is a bare-bones design, but it works well. When you build supporting circuits around it you can get excellent results. The set is a good starting point for experimentation.

The article also includes tips on a transceiver you can purchase to save time in developing ancillary circuits (XBee), while noting a variety of transceiver, receiver, and transmitter modules are available from manufacturers such as Maxim Integrated, Micrel, and RF Monolithics (RFM).  In addition, the article discusses design and optimization of the three forms of antennas: a straight conductor (monopole), a coil (helical), and a loop.

“These can be external, internal, or even etched onto the PCB (e.g., keyless entry fobs) to minimize the size,” Novacek says.

Do you need advice on what to consider when choosing an antenna for your design?  Find these tips and more in Novacek’s March issue article.

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.

MCU-Based Prosthetic Arm with Kinect

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

He also submitted a block diagram.

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

Kim explains:

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

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

The system includes:

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