Fun with the .NET Micro Framework & the FEZ Mini Robot

Microcontrollers can drive anything from watches and tiny MP3 players to industrial control systems and sophisticated robotics, so the opportunity to write C# .NET code on a small and cheap microcontroller is very exciting.  In April 2008 I wrote an article comparing the .NET Micro Framework to Robotics Development Studio (RDS), since they are both used for driving robotics applications.  RDS requires at least the Compact Framework, which in turn requires Windows CE hardware, which is a good deal more power-hungry and more expensive than tiny microcontrollers that can cost as little as a few dollars each (in bulk, developer kits go for $35 and up).

You may have heard of the popular Linux-based Arduino microcontroller prototyping boards.  These boards have standard ports for plugging in other boards (called shields) for adding functionality such as motor and servo controllers, sensor input expansions, radio communications, and much more.  These are really cool boards, but being a spoiled .NET developer myself, I haven’t been strongly motivated to program without my beloved Visual Studio tools, and hitting the steep learning curve of Linux development just never happens during the little free time that I have.

Fortunately, there are now some .NET Micro Framework boards that are Arduino board compatible, providing you the comfort of .NET development with the ability to use any of the Arduino-compatible boards that are out there.  Netduino is a popular, low-cost ($34.95), open source option that makes it easy for any .NET developer to get started.  Another great Arduino-compatible option is the FEZ Domino board from TinyCLR.com.  It’s more expensive than the Netduino ($74.95), but also more powerful.

I’m also a big fan of Phidgets boards, which are USB and therefore very easily extensible for those unfamiliar with the various microcontroller communication standards.  I wrote an article on Phidgets Robotics Programming where I built a pan-tilt camera system controlled by a Wii remote.

Since I enjoy working with robotics applications so much, I decided to try out the FEZ Mini Robot Kit for $149.95.  This is a great kit for beginners as it includes all the tools necessary and can be assembled within 15-20 minutes.  It uses the FEZ Mini board (included with the kit) which is an astonishing 1.1” x 1.9” tiny.  When not being used in the robot, it would be ideal for my own custom MP3 player as well.

The robot kit instructions are a bit rough: lots of pretty bad spelling and grammar errors, but the assembly instructions are easy enough to follow.  The worst part is the code.  Getting the various sensors, motors, and other things to work properly requires that you download individual C# files from all over their website: the reflective sensor code is found on their reflective sensor product page, and so on.  Stitching this all together and correcting mistakes took me a while.  It’s also evident that the folks writing this code are not fluent C# developers.  By the look and feel of things, they’re probably used to low-level assembly and unmanaged C development.

To save you some pain and discomfort, I’ve gone ahead and rewritten all of the drivers for all the components involved, and have reorganized it from the perspective of someone who’s been writing business applications in C# since .NET 1.0.  I’ve reshaped the API to look and feel a lot more natural to those unfamiliar with the gory details of pulse width modulation (PWM) and similar protocols.  And instead of delivering individual code files scattered across a website, I’ve packaged them all in one place as a Visual Studio 2010 solution, which you can download here:

FEZ Mini Robot – Visual Studio Solution

Have fun developing!

Here’s the robot in action:

.NET Micro Framework vs. Microsoft Robotics Studio

The .NET Micro Framework is a compatible subset of the full .NET Framework, similar to how the Compact Framework is a subset.  But the Micro Framework can act as its own real time operating system (RTOS) instead of loading the tiny CLR in a host operating system, and works with a variety of hardware devices, including those that don’t have their own memory management unit (MMU).  The gist is that embedded applications as well as low-level drivers can now be written in managed code (a huge leap forward), and take advantage of garbage collection, strong-typing, and other nice features that are typically absent in embedded systems programming.  This supposedly reduces errors, boosts productivity, and reduces development costs.

I’ve been watching videos like this, reading about the Micro Framework for the past few months, have pre-ordered this book from Amazon, and have been itching to get my hands on a hardware development kit to start experimenting.  The only problem is that the interfaces for these embedded devices are so foreign to me (I2C, GPIO, etc.), and I’m not exactly sure what my options are for assembling components.  What kinds of sensors are available?  Do I have to solder these pieces together or is there a nice modular plug system similar to the SATA, IDE, and PCI connectors on modern computers (but on a smaller scale)?  Do I have to write my own device drivers for anything I plug in, or is there some abstraction layer for certain classes of inputs and outputs?

The other issue that makes me hesitate is the thought of programming without language conveniences like generics on a more resource-constrained device than the Windows Mobile devices I’m already frustrated with (and have been for the past four years).

I’m not saying that I’m not excited about managed code on tiny embedded devices, and I’m not saying I won’t start playing with (and blogging about) this important technology sometime in the next few months, but I’ve discovered another platform for embedded device development with the ability to interact directly with the physical world that offers a much lower technical barrier for entry, so that’s where I’m starting.

What I’m referring to is Microsoft Robotics Studio, which is by all accounts a phenomenal platform for more than just robotics, and seems to overlap somewhat with the Micro Framework’s reach (at the intersection of the computer-digital and physical-analog worlds).  The two critical components of this architecture are the Decentralized Software Services Protocol (DSSP, originally named WSAP) and the Concurrency & Coordination Runtime (CCR).  Make sure you watch this video on the CCR, and note how George emphasizes that “it’s not about concurrency, it’s about coordination”, which I found especially enlightening.  These are highly robust and general purpose libraries, and both of them will run on Compact Framework!  (I was very impressed when I read this.)

Without having studied them both in depth yet, the CCR seems to cannibalize on the Task Parallel Library (TPL), at least conceptually, offering a much more complete system of thread manipulation and synchronization than the original System.Threading types, all for a vertical industry that has much greater demands of a concurrency framework that must, for example, deliver massive concurrency and complex coordination rules in a highly-distributed system, all the while handling full and partial failures gracefully.  Some of the patterns and idioms for making concurrency and synchronization operations easy to write and understand are masterfully designed by Henrik Nielsen and George Chrysanthakopoulos (and I thought Vanderboom was a long name!).

The fact that the CCR and DSSP were developed together is significant.  Tasks running in parallel need to be manipulated, coordinated, and tracked regardless of whether they’re running on four processors in one computer or on 256 processors spread across a hundred devices, and distributed services need a dependable way of parallelizing their efforts on individual machines.  This is a synergistic relationship, each subsystem enhancing the elegance and usefulness of the other.  So why not use the CCR in every application instead of developing the TPL?  Are these two teams actively collaborating, or have they been building the two frameworks in isolation?

I also have to make special mention of the decentralized software services, which as a protocol sits on top of HTTP in a RESTful implementation.  It supports composition of services by creating partnerships with other services, defining securely which partnerships are allowed, offering identification and discovery of services, and much more.  In this assembly then, we have a robust library for building distributed, composable, decentralized services-oriented systems with event publication and subscription, with services that can be hosted on desktop and mobile computers alike.  Wow, call me a geek, but that’s really frickin’ cool!  Some of the ideas I have for future projects require this kind of architectural platform, and I’ve been casually designing bits and pieces of such a system (and got so far as getting the communication subsystem working in CF).  Now, however, I might be turning my attention to seeing if I can’t use the Robotics Studio APIs instead.

One thing to be clear about is that Robotics Studio doesn’t support Micro Framework, at least not yet.  I wonder exactly how much value there would be to adding this support.  With hardware options such as this 2.6″ x 2.3″ motherboard with a 1.6 GHz Intel Atom processor, video support, and up to 1 GB of RAM, capable of running Windows XP or XP Embedded, and priced at $95 (or a 1.1 GHz version for $45), we’re already at a small enough form factor and scale for virtually any autonomous or semi-autonomous robotics (or general embedded) applications.  There’s also the possibility for one or more Micro Framework devices to exchange messages with a hardware module that is supported in Robotics Studio, such as the tiny board just mentioned.

Where do we go next?  For me, I just couldn’t resist jumping in with both feet, so I ordered about $500 in robotics gear from Phidgets: USB interface boards, light and tempature sensors, a 3-axis accelerometer (think Wii controller), motors and servos, an RFID reader with tags, LEDs, buttons, knobs, sliders, switches, and more.  I plan to use some of this for projects at CarSpot, and the rest simply to be creative with and have fun.  I also pre-ordered this book, but the publication date is set for June 10th, so by the time I get it, I may have already figured most of it out.