Autonomous Quadrotor for RFID Inventorying

We’re using the AscTec Pelican to do automated inventorying!  In this demo, we placed three RFID tags on the walls (left, front, and right).  The Pelican begins by performing an automated routine where it launches, stabilizes at 1 meter above the ground (using sonar), and then spins 360 degrees.  It does this to get a full LIDAR scan of its environment while building a map using simultaneous localization and mapping (SLAM).

After initialization, the Pelican finds the closest point along the wall, faces it, and moves to within a predefined distance of the wall.  One this goal has been achieved, the Pelican proceeds by strafing along the wall and scanning for passive RFID tags.  The data shown on the upper-left illustrates when a tag data is being detected.  The movement pattern was calculated using morphological operations on the binary floor map obtained from LIDAR SLAM.  This allows the Pelican to define exterior walls and safely avoid obstacles.

Finally, the Pelican decides it’s time to land and nothing breaks or starts on fire => Success!!

LPCXpresso “Hello, World” and Breadboard LED Blinking

20131003-2347

NXP has a collection of low-cost development boards — their LPCXpresso line — that are great for getting into ARM development. As I mentioned in my previous post, the LPCXpresso is a development board that consists of various NXP target processors (depending on the actual board you get), as well as an LPC-Link debugger. What’s unique about the LPCXpresso board is that you can actually cut the board apart, separating the LPC-Link from the target, and allowing you to debug projects on custom boards — or as we’ll see in a minute, solderless breadboards.

Development hardware is worthless without good quality software, and NXP’s Code Red Suite has you covered. The free version (which only works with NXP MCUs) is code-size-limited, but it’s a very generous 256 KB download limit. Most beginners would be hard-pressed to reach that limit (and there are only a handful of MCUs out there that even have that much capacity).

Continue reading

Getting Started with ARM Microcontrollers — An Overview of the ARM Ecosystem

Almost every design that leaves my desk has a microcontroller in it, and basically everything I’ve worked on over the last two years has used ARM microcontrollers. These can be quite overwhelming to get started with, so I wanted to write a blog post about what ARM microcontrollers are (and aren’t), and what’s out there in terms of development boards and tools. There are lots of tutorials covering specific ARM microcontrollers, but I wanted to operate more broadly, and explain what exactly is out there, and what you need to get started.

Continue reading

Great Faces, Great Places

DPP_0241

Hello from South Dakota! We’re up here presenting not one, not two, but three papers at the 2013 IEEE International Conference on Electro/Information Technology held at the South Dakota School of Mines in Rapid City. Jay presented his paper, Exploring the Microsoft .NET Micro Framework for Prototyping Applied Wireless Sensor Networks; Steven presented his paper, Improved Microcontroller-Based Electronic Respiratory Training, and Eric presented Real-time Temporal Stereo Matching using Iterative Adaptive Support Weights.

DPP_0145It was a lot of fun to see what other researchers in the area were working on, and we got a chance to do some sight-seeing as well. We’re pictured at the Badlands National Park above, and to the right, we do our best presidential impressions at Mount Rushmore. YOLO?

FEZ Cerberus firmware image compiled for STM32F4 Discovery

I’m a huge proponent of .NET Micro Framework — by running the .NET VM on bare metal, application developers can write managed-language applications targeting embedded devices that are typically programmed in C/C++. With .NET MF, your embedded projects can use the same sorts of features you’re used to when writing desktop applications — like Events, Threads, Collections, Exceptions, and Visual Studio’s awesome debugging engine.

There are two components of the .NET Micro Framework ecosystem: the managed application, that you, the user, write in C#. And the firmware running on the actual processor, which is written in C/C++. The firmware provides the VM, as well as hardware services, like UART/SPI/I2C interfaces, GPIO, PWM pins, LCD interfacing, etc. The firmware code is fixed to the actual “target” — the particular hardware you’re using; this firmware source code only needs to be deployed once to the target; once it is on the target, the rest of the development is done in the managed language. This allows end users to develop embedded systems applications without having to write low-level C/C++ code (or have to buy all the associated software toolchains and debuggers to set up that sort of system). All these users need is a copy of Visual Studio (.NET MF supports the free Express Edition).

We’ve been using the GHI .NET Gadgeteer platform to prototype a WSN project we’re working on in the lab, and it has been, by far, the least-stressful embedded project I’ve ever worked on. We’re using the FEZ Cerberus ($29) and FEZ Hydra ($79) — both of which are a great value, and offer a lot of connectivity. I strongly recommend either board for anyone started out in embedded design.

However, for the best bang-for-your buck, nothing beats the STM32F4 Discovery boards, which have an on-board ST-Link JTAG debugger, an accelerometer, RGB LED, and an audio codec. At less than $15, ST is basically giving them away.

Wouldn’t it be great if you could put .NET Micro Framework on the STM32F4 Discovery?

The only difference between the two is the 8 MHz crystal on the Discovery and the 12 MHz crystal on the FEZ Cerberus. So, all we need to do is update the firmware; specifically,  change line 78 of FEZ Cerberus’s platform_selector.h file from:

#define SYSTEM_CRYSTAL_CLOCK_HZ         12000000   // 12MHz external clock

to

#define SYSTEM_CRYSTAL_CLOCK_HZ         8000000   // 8MHz external clock

Unfortunately, getting the source code *compiled* is an entirely different story. You’ll need a copy of MDK to be able to compile the firmware, and it’s not cheap — more than $4000.

We have a copy of MDK, so I’ve taken the time to recompile the FEZ Cerberus firmware to target the Discovery board. Here is a ZIP archive with the files needed: http://mc2.unl.edu/uploads/discoveryCerberus.zip

You’ll need to use the ST-LINK utility to erase the chip and flash it with tinybooter.hex. Once this is done, reboot the board and install the GHI WinUSB drivers. This should provide a .NET MF Debugging interface. Now, use MFDeploy (it’s a tool found in the .NET MF SDK) to deploy the two files in tinyclr.hex — ER_CONFIG and ER_FLASH.

After that, you should be good to go!

A pulse generator for synchronizing camera capture

We love our Point Grey USB 3.0 cameras, but our stereo vision work requires cameras to capture frames in perfect synchronicity, and these cameras don’t provide a reference clock input or output, like many professional cameras have. They do, however, have a GPIO interface that allows for triggering. So, we decided to build a little pulse generator to run into both cameras, which would give us a hardware dial control over frame rate, and at the same time, ensuring the cameras are capturing frames at the same instant — maintaining synchronous operation.

Pulse generators are nothing new, and we’re sure we could have bought something off the shelf that would work — but instead, we decided to save a couple bucks and build our own. Eric prototyped the system on a breadboard using an Arduino, a pot (to set the input frequency), and a two-digit 7-segment display to show the current frequency. The output of the device can be run directly into any arbitrary number of cameras that need to synchronize; and the frequency can be set anywhere between 1 Hz and 60 Hz.

We made a little PCB for it by toner-transfering the design to some copper clad FR4 using Pulsar’s Toner Transfer Paper. The design isn’t going to win any signal integrity awards, but it’s single-layer, and low-tolerance (12mil width/space), so it should be relatively easy for people to make, using a wide variety of methods.

We etched the board in the patented Don’t Try This At Home, Kids® etch solution, composed of 12M hydrochloric acid and 35% hydrogen peroxide, which etches boards extremely quickly (like, 20 seconds, with little to no agitation).

Design Files:

Schematic
PCB Artwork
Arduino sketch 

 

 

Most expensive tripod. Ever.

Eric is putting together some preliminary datasets to do some vision-based SLAM work using optical flow, which basically tracks a set of feature points of a rigid structure (say, a room in a building) in a stream of video shot from a moving camera to judge relative distance between points in space — in effect, creating a 3D map of whatever the camera is looking at.

Eric mounts his Canon D-SLR onto our vintage 1980s Seiko D-TRAN RT-3000 industrial automation robot to get some video with clear, predictable movement.

Although the algorithm will be designed to work with arbitrary camera movements, he thought it might be useful to have a video stream with known camera movements. So, I decided to build essentially a jib arm using our lab’s Seiko RT-3000 industrial automation robot (circa-1984), which was then programmed to control the movement of the camera precisely.

We didn’t have time to machine a custom mount for the robot, so a roll of tape had to do.

What we ended up with was pretty cool for 10 minutes of work. Here’s a short (and kind of lame) video of it in action:

(Also, Dr. Shane Farritor’s mechanical engineering research lab deserves a shout out for giving us the robot — thanks guys! It’s a fun toy to have around!)