Robot Design with Microsoft Kinect, RDS 4, & Parallax’s Eddie

Microsoft announced on March 8 the availability of Robotics Developer Studio 4 (RDS 4) software for robotics applications. RDS 4 was designed to work with the Kinect for Windows SDK. To demonstrate the capabilities of RDS 4, the Microsoft robotics team built the Follow Me Robot with a Parallax Eddie robot, laptop running Windows 7, and the Kinect.

In the following short video, Microsoft software developer Harsha Kikkeri demonstrates Follow Me Robot.

Circuit Cellar readers are already experimenting Kinect and developing embedded system to work with it n interesting ways. In an upcoming article about a Kinect-based project, designer Miguel Sanchez describes a interesting Kinect-based 3-D imaging system.

Sanchez writes:

My project started as a simple enterprise that later became a bit more challenging. The idea of capturing the silhouette of an individual standing in front of the Kinect was based on isolating those points that are between two distance thresholds from the camera. As depth image already provides the distance measurement, all the pixels of the subject will be between a range of distances, while other objects in the scene will be outside of this small range. But I wanted to have just the contour line of a person and not all the pixels that belong to that person’s body. OpenCV is a powerful computer vision library. I used it for my project because of function blobs. This function extracts the contour of the different isolated objects of a scene. As my image would only contain one object—the person standing in front of the camera—function blobs would return the exact list of coordinates of the contour of the person, which was what I needed. Please note that this function is a heavy image processing made easy for the user. It provides not just one, but a list of all the different objects that have been detected in the image. It can also specify is holes inside a blob are permitted. It can also specify the minimum and maximum areas of detected blobs. But for my project, I am only interested in detecting the biggest blob returned, which will be the one with index zero, as they are stored in decreasing order of blob area in the array returned by the blobs function.

Though it is not a fault of blobs function, I quickly realized that I was getting more detail than I needed and that there was a bit of noise in the edges of the contour. Filtering out on a bit map can be easily accomplished with a blur function, but smoothing out a contour did not sound so obvious to me.

A contour line can be simplified by removing certain points. A clever algorithm can do this by removing those points that are close enough to the overall contour line. One of these algorithms is the Douglas-Peucker recursive contour simplification algorithm. The algorithm starts with the two endpoints and it accepts one point in between whose orthogonal distance from the line connecting the two first points is larger than a given threshold. Only the point with the largest distance is selected (or none if the threshold is not met). The process is repeated recursively, as new points are added, to create the list of accepted points (those that are contributing the most to the general contour given a user-provided threshold). The larger the threshold, the rougher the resulting contour will be.

By simplifying a contour, now human silhouettes look better and noise is gone, but they look a bit synthetic. The last step I did was to perform a cubic-spline interpolation so contour becomes a set of curves between the different original points of the simplified contour. It seems a bit twisted to simplify first to later add back more points because of the spline interpolation, but this way it creates a more visually pleasant and curvy result, which was my goal.


(Source: Miguel Sanchez)
(Source: Miguel Sanchez)

The nearby images show aspects of the process Sanchez describes in his article, where an offset between the human figure and the drawn silhouette is apparent.

The entire article is slated to appear in the June or July edition of Circuit Cellar. RSS Feed

Feed the latest posts from to your RSS reader. Doing so will keep you up-to-date on projects, upcoming issues, and deals! Setting up the feed is simple. Add to your reader and enjoy!

Weekly Elektor Wrap Up: Laser, Digital Peak Level Meter, & “Wolverine” MCU

It’s Friday, so it’s time for a review of Elektor news and content. Among the numerous interesting things Elektor covered this week were a laser project, a digital peak level meter for audio engineering enthusiasts, and an exciting new ultra-low-power MCU.

Are you an embedded designer who wants to start a laser project? Read about “the world’s smallest laser”:

What is the biggest constraint in creating tiny lasers? Pump power. Yes sir, all lasers require a certain amount of pump power from an outside source to begin emitting a coherent beam of light and the smaller a laser is, the greater the pump power needed to reach this state. The laser cavity consists of a tiny metal rod enclosed by a ring of metal-coated, quantum wells of semiconductor material. A team of researchers from the University of California has developed a technique that uses quantum electrodynamic effects in coaxial nanocavities to lower the amount of pump power needed. This allowed them to build the world’s smallest room-temperature, continuous wave laser. The whole device is only half a micron in diameter (human hair has on average a thickness of 50 micron).

The nanolaser design appears to be scalable – meaning that they could be shrunk to even smaller sizes – an important feature that would make it possible to harvest laser light from even smaller structures. Applications for such lasers could include tiny biochemical sensors or high-resolution displays, but the researchers are still working out the theory behind how these tiny lasers operate. They would also like to find a way to pump the lasers electrically instead of optically.

Be sure to check out Elektor’s laser projection project.

In other news, Elektor reached out to audio engineering-minded audio enthusiasts and presented an interesting project:

Are you an audio amateur hobbyist or professional? Do you try to avoid clipping in your recordings? To help you get your audio levels right, in January 2012 Elektor published a professional-quality peak level meter featuring 2x 40 LEDs, controlled by a powerful digital signal processor (DSP). As part of the eight-lesson course on Audio DSP, all the theory behind the meter was explained, and the accompanying source code was made available as a free download.

The DSP Board has been available for a while, and now we are proud to announce that the Digital Peak Level Meter is available as an Elektor quality kit for you to build. Although the meter was designed as an extension module for the Audio DSP board, it can be used with any microcontroller capable of providing SPI-compatible signals. So get your Peak Level Meter now and add a professional touch to your recording studio!

And lastly, on the MCU front, Elektor ran interesting piece about the Texas Instruments “Wolverine,” which should be available for sampling in June 2012:

Codenamed “Wolverine” for its aggressive power-saving technology, the improved ultra-low-power MSP430 microcontroller platform from Texas Instruments offers at least 50 % less power consumption than any other microcontroller in the industry: 360 nA real-time clock mode and less than 100 µA/MHz active power consumption. Typical battery powered applications spend as much as 99.9 % of their time in standby mode; Wolverine-based devices can consume as little as 360 nA in standby mode, more than doubling battery life.

Wolverine’s low power performance is made possible by using one unified ferromagnetic RAM (FRAM) for code and data instead of traditional Flash and SRAM memories, allowing them to consume 250 times less energy per bit compared to Flash- and EEPROM-based microcontrollers. Power consumption is further reduced thanks to an ultra low leakage  process technology that offers a 10x improvement in leakage and optimized mixed signal capabilities.

MSP430FR58xx microcontrollers based on the Wolverine technology platform will be available for sampling in June 2012.

Circuit Cellar and are part of the Elektor group.


DIY Cap-Touch Amp for Mobile Audio

Why buy an amp for your iPod or MP3 player when you can build your own? With the proper parts and a proven plan of action, you can craft a custom personal audio amp to suit your needs. Plus, hitting the workbench with some chips and PCB is much more exciting than ordering an amp online.

In the April 2012 issue of Circuit Cellar, Coleton Denninger and Jeremy Lichtenfeld write about a capacitive-touch, gain-controlled amplifier while studying at Camosun College in Canada. The design features a Cypress Semiconductor CY8C29466-24PXI PSoC, a Microchip Technology mTouch microcontroller, and a Texas Instruments TPA1517.

Denninger and Lichtenfeld write:

Since every kid and his dog owns an iPod, an MP3 player, or some other type of personal audio device, it made sense to build a personal audio amplifier (see Photo 1). The tough choices were how we were going to make it stand out enough to attract kids who already own high-end electronics and how we were going to do it with a budget of around $40…

The capacitive-touch stage of the personal audio amp (Source: C. Denninger & J. Lichtenfeld)

Our first concern was how we were going to mix and amplify the low-power audio input signals from iPods, microphones, and electric guitars. We decided to have a couple of different inputs, and we wanted stereo and mono outputs. After doing some extensive research, we chose to use the Cypress Semiconductors CY8C29466-24PXI programmable system-on-chip (PSoC). This enabled us to digitally mix and vary the low-power amplification using the programmable gain amplifiers and switched capacitor blocks. It also came in a convenient 28-pin DIP package that followed our design guidelines. Not only was it perfect for our design, but the product and developer online support forums for all of Cypress’s products were very helpful.
Let’s face it: mechanical switches and pots are fast becoming obsolete in the world of consumer electronics (not to mention costly when compared to other alternatives). This is why we decided to use capacitive-touch sensing to control the low-power gain. Why turn a potentiometer or push a switch when your finger comes pre-equipped with conductive electrolytes? We accomplished this capacitive touch using Microchip Technology’s mTouch Sensing Solutions series of 8-bit microcontrollers. …


The audio mixer flowchart

Who doesn’t like a little bit of a light show? We used the same aforementioned PIC, but implemented it as a voltage unit meter. This meter averaged out our output signal level and indicated via LEDs the peaks in the music played. Essentially, while you listen to your favorite beats, the amplifier will beat with you! …
This amp needed to have a bit of kick when it came to the output. We’re not talking about eardrum-bursting power, but we wanted to have decent quality with enough power to fill an average-sized room with sound. We decided to go with a Class AB audio amplifier—the TPA1517 from Texas Instruments (TI) to be exact. The TPA1517 is a stereo audio-power amplifier that contains two identical amplifiers capable of delivering 6 W per channel of continuous average power into a 4-Ω load. This quality chip is easy to implement. And at only a couple of bucks, it’s an affordable choice!


The power amplification stage of the personal audio amp (Souce: C. Denninger & J. Lichtenfeld)

The complete article—with a schematic, diagrams, and code—will appear in Circuit Cellar 261 (April 2012).








Organic Magnetism & Electronic Applications

Innovative researchers in Japan are looking closely at organic magnetism and how it can be applied to electronic systems. Could carbon-based organic materials eventually replace inorganic materials (i.e., silicon and other metals) in future electronic applications?

In a post titled “Organic Electronics: The Secret of Organic Magnets Unlocked” at, Tessel Renzenbrink explains the results of exciting research by Japanese scientists studying the origin of magnetism in organic compounds. Tessel writes:

Organic light- emitting diodes (OLEDs) are already commercially in use in displays of mobile devices and significant progress has been made in applying organic photovoltaic cells to a light-weight flexible fabric to generate low-cost solar energy. But an entirely new range of applications is possible such as disposable biodegradable RFID tags and biomedical implants.

One of the limiting factors of organic materials is that they rarely exhibit magnetic properties because their atomic structure is fundamentally different from metals. But for electronic applications such as data storage and electric motors magnetism is essential.

Now a team of scientists from the RIKEN research center has established an exact theoretical model which could aid materials scientists to develop organic magnetic materials.

You can read the entire post at is part of the Elektor group. 



Aerial Robot Demonstration Wows at TEDTalk

In a TEDTalk Thursday, engineer Vijay Kumar presented an exciting innovation in the field of unmanned aerial vehicle (UAV) technology. He detailed how a team of UPenn engineers retrofitted compact aerial robots with embedded technologies that enable them to swarm and operate as a team to take on a variety of remarkable tasks. A swarm can complete construction projects, orchestrate a nine-instrument piece of music, and much more.

The 0.1-lb aerial robot Kumar presented on stage—built by UPenn students Alex Kushleyev and Daniel Mellinger—consumed approximately 15 W, he said. The 8-inch design—which can operate outdoors or indoors without GPS—featured onboard accelerometers, gyros, and processors.

“An on-board processor essentially looks at what motions need to be executed, and combines these motions, and figures out what commands to send to the motors 600 times a second,” Kumar said.

Watch the video for the entire talk and demonstration. Nine aerial robots play six instruments at the 14:49 minute mark.

Issue 260: Embedded Control Languages

Choosing a programming language is an essential part of any serious embedded design project. But the task can be daunting. When should you use a processor-specific language? Why not just use C?

In the March issue of Circuit Cellar, Steve Ciarcia reviews a handful of programming languages and types of and processors—and projects—for which they are intended.

Here’s Steve’s take:

Let’s talk about languages—specifically, embedded control languages. Everyone has their favorite, typically whatever they learned first, but when you get right down to it, all languages offer the same basic features.

First of all, you need to be able to specify a sequence of steps and then select between two (or more) alternative sequences—the if-then-else construct. You also need to be able to repeat a sequence, or loop, and exit that loop when a condition is met. Finally, you want to be able to invoke a sequence from multiple places within other sequences—a call function.

Assembly language is the lowest-level language you can use on most machines. Its statements bear a one-to-one relationship with the instructions the hardware executes. If-then-else and loop-exit constructs are implemented using conditional and unconditional branch instructions, and there’s usually a hardware stack that facilitates subroutine call and return. This is both a blessing and a curse—it enables you to become familiar with the hardware and use it most effectively, but it also forces you to deal with the hardware at all times.

Very early on in the development of computers, the concept of a high-level language (HLL) was developed to reduce this hardware focus. By creating a set of abstract computer operations that aren’t necessarily tied to a particular processor, the HLL frees the programmer from a specific hardware architecture and enables him to focus on the actual algorithm development. The compiler and library writers took these abstractions and efficiently mapped them onto the hardware. HLL opened up programming to “non-hardware” people whose first interest was the application problem and its solution.

Today, there are literally hundreds of computer languages (see Some of them are completely general-purpose, while others are very domain-specific. Two languages have been implemented on virtually every microprocessor ever invented: C and BASIC. (There’s no way I can mention them all, so I’ll just touch on some popular embedded ones.) Of the two, C is by far the more popular for embedded apps, since it runs more efficiently on most hardware. Many people would argue that C isn’t a “true” HLL; but even still, it’s a huge step up from Assembly language in terms of productivity.

There have been some niche languages intended for small systems. For example, there’s what you might call a family of reverse-Polish notation (RPN) languages: Forth, Postscript, and does anyone remember a tiny interpreted language called Mouse? These never caught on in any big way, except for Postscript, which is almost universally available these days on printers as a page-description language. But it’s a full programming language in its own right—just ask Don Lancaster!

Along the way, there have been a few processor-specific languages invented. For example, there’s JAL—just another language—which is optimized for 8-bit Microchip PIC processors, and Spin, which is designed to support the parallel-processing features of the Parallax Propeller chip.

Once you start getting into larger 16- and 32-bit chips, the set of available tools expands. Many of these processors have C/C++ toolchains based on the GNU Compiler Collection (GCC). However, this means you can really use any number of languages in the collection on these processors, including Fortran, Java, and Ada.

The designers of some embedded systems want to include the ability for the system to be programmed by their end users. To this end, the concept of an “extension language” was developed. Two notable examples are TCL and Lua. These provide a standard notation for control constructs (branching, looping and function calls) wrapped around application-specific primitive operations implemented by the system designer.

Once you start getting into systems that are large enough to require an operating system (real-time or otherwise), many of the available choices support the POSIX API. This means you can use any of the mainstream scripting languages—such as shell scripts, Perl, Python, Ruby, PHP, etc.—either internally or exposed to the end user.

And finally, there’s the web-based user interface. Even relatively simple embedded applications can have sophisticated GUIs by pushing much of the programming out to the browser itself by means of ECMAscript (JavaScript) or Java. The embedded app just needs to implement a basic HTTP server with storage for the different resources needed by the user interface running on the browser. There are all kinds of toolkits and frameworks out there that help you build such a system.

I’ll stop now. The point is, even in the world of embedded computer applications, there’s a wide variety of tools available, and picking the right set of tools for the job at hand is part of the system design process. Taking a higher-level view, this brief survey might give you an idea of what kinds of tools you would want to put some effort into learning, based on where your interests lie or the application dictates.