I am excited about presenting on this topic for the Charlotte Alt.Net users group on May 8th in Charlotte. Head on over to the event posting and sign up to attend.

Here are the details about the talk:

The most recent release of Microsoft Robotics Developer Studio 4 (RDS4) has introduced two very exciting  concepts that make building robotic applications a reality to all developers: Kinect and Reference Platform Design specification.  The Kinect is the hot device that gives a new perspective on sensing your surroundings.  RDS 4 fully supports the Kinect and opens up all kinds of opportunities for awesome applications.  Do you want skeletal tracking in a robotics application, RDS 4 gives you that.  Do you want to perform obstacle avoidance with Kinect's depth sensor, RDS 4 gives you that. Do you want to simulate a Kinect in a virtual environment  to test out your high level code, RDS 4 gives you that.  The Reference Platform gives vendors a common design specification for building a working robot that includes sensors, motors and low level control. This allows for a developer that has little hardware experience to get up and running fast.  In this session I will introduced you to RDS 4 using the Kinect and an Eddie robot.

Eddie Robot http://www.parallax.com/eddie

Microsoft Robotics Developer Studio http://www.microsoft.com/robotics/

I really enjoy being able to write C# code and deploy/debug it on my Netduino device.  However there are many cases where I would like to do a little Test Driven Development to flush out a coding problem without deploying to the actual hardware.  This becomes a little difficult since the .Net Micro Framework doesn’t have an easily available testing framework.  There are some options that you have in order to write and execute tests:

Well I have another option that works with the full blown NUnit framework if you follow a few conventions when writing your Netduino code.  This approach does not use the emulator so you need to be able to break up your application into two different types of classes:

  • Classes that use .Net Micro or Netduino specific libraries
  • Classes that do not use .Net Micro or Netduino specific libraries.

This seems a little strange but another way to look at the organization of your classes is that if any code does any IO then it belongs in the non testable classes.  Any other code that performs logical decisions or calculations belongs in the testable classes.  This is a common approach that is done in a lot of systems and the IO classes are usually categorized as a hardware abstraction layer.  You can use interfaces to the hardware abstraction layer so that during unit testing you can fake or mock out the hardware and simulate conditions that test the decision making code.

Enough talking about approaches to unit testing lets get going on an example project that shows how this will work.  For this example I am creating a Netduino application that reads an analog sensor that measures the intensity of light and turns an LED on or off.   

Here is how the solution is set up so that I can do unit testing.

The solution consists of two projects:

  • Netduino.SampleApplication - a Netduino Application built against the .Net Micro Framework
  • Netduino.SampleApplication.UnitTests – a .Net 4.0 Class Library

The Netduino.SampleApplication.UnitTests project references the following:


Notice that this unit test project does not reference the assembly that it will be targeting for testing.  This is done on purpose because a .Net 4.0 Assembly cannot reference an assembly built against the .Net Micro Framework.  The project does reference the NUnit testing framework.  

Now lets talk about the class that we are going to write tests against. Since analog sensors can sometimes be a little noisy I wanted to take multiple samples of the sensor and average the results so that any noisy readings will be smoothed out.  This class is able to accept sensor readings and provides an average of the last N readings. 

Here is the AnalogSmoother class


This is a pretty simple class that exposes one operation called Add and one property called Average.  One thing to notice is that I have removed any using statements (Microsoft.SPOT) that would make this class .Net Micro specific or Netduino specific. 

To test this we need to use a cool Visual Studio feature called “Add as Link” where you can add an existing class to another project by linking to the original file.  If you change the original file the project that has the linked file will also see the change.  To add the linked file you simply right click on the Netduino.SampleApplication.UnitTests project and select Add –> Existing Item and navigate to the AnalogSmother.cs file and select the down arrow on the Add button.


So now you have a single file that is compiled in the Netduino project and the Unit Test project.  This makes it very easy to create a test fixture class in the unit test project that exercises the linked class. 

Here is the test fixture class:


So I was able to test this class without starting up an emulator or deploying to the Netduino.  This is great for classes that do not need to perform any IO but eventually you are going to run into a case where you need to access the specific hardware of the Netduino.  This is where the hardware abstraction layer comes into play. 

In this sample application I created the following interface:


Here is the class that implements the interface and does all the actual IO:


Here is the class that uses the IHardwareLayer interface that has some more logic that can be tested using the same approach of adding the linked file to the unit test project.


This class will have to be tested a little differently though because it actually expects the IHardwareLayer to return values when calling ReadLight.  We can simulate the hardware returning correct values by providing a fake implementation of the IHardwareLayer interface.  This can be done easily by creating a FakeHardwareLayer that implements the IHardwareLayer and returns the expected values.  Or you can use a mocking framework such as Moqto do the work for you.


The Moq mocking framework allows you to Setup specific scenarios and Verify that those scenarios are working.  The above test verifies that the LED does turn on and off for specific values of Light Readings.


I have been able to show you that unit testing is doable for Netduino projects if you follow a couple design patterns and you don’t have to wait for a testing framework to be available for the .Net Micro Framework.   

UPDATE: I made a couple small tweaks to the code and posted it on my NetduinoExamples repository under the UnitTestingExample subfolder.

UPDATE: The feed changed a little bit from the first time I published the format

I made changes to the twitter feed format to match the game for the FIRST FRC 2010 Season.  You can follow the tweets for this season at http://twitter.com/Frcfms 

The new format is as follows:

#FRCABC - where ABC is the Event Code. Each event has a unique code.
TY X - where x is P for Practice Q for qualification E for Elimination
MC X - where X is the match number
RF XXX - where XXX is the Red Final Score
BF XXX - where XXX is the Blue Final Score
RE XXXX YYYY ZZZZ - where XXXX is red team 1 number, YYYY is red team 2 number, ZZZZ is red team 3 number
BL XXXX YYYY ZZZZ - where XXXX is blue team 1 number, YYYY is blue team 2 number, ZZZZ is blue team 3 number
RB X - where X is the Bonus the Referee gave to Red
BB X - where X is the Bonus the Referee gave to Blue
RP X - where X are the Penalties the Referee gave to Red
BP X - where X are the Penalties the Referee gave to Blue
RG X - where X is the Goals scored by Red
BG X - where X is the Goals scored by Blue
RGP X - where X is the Goal Penalties by Red
BGP X - where X is the Goal Penalties by Blue

Example tweet in text:

#FRCTEST TY Q MC 2 RF 5 BF 3 RE 3224 2119 547 BL 587 2420 342 RB 1 BB 1 RP 0 BP 0 RG 0 BG 5 RGP 2 BGP 1

I sure would like to know if anyone builds anything that parses these tweets.