This article introduces Microsoft Robotics Developer Studio, the development environment for robotics created by Microsoft. The purpose of this article is to position Microsoft Robotics Developer Studio within the development ecosystem for robotics programs.

Some history

In June 2006, during the RoboBusiness Conference and Exposition 2006, Microsoft announced the availability of Microsoft Robotics Studio (MSRS), a standardised development platform for robotics. This announcement was the culmination of a new effort from Microsoft, initiated by Bill Gates himself in an article in Scientific American magazine in December 2006 entitled “A Robot in Every Home[1] [1]”. In that article, Bill Gates commented that the robotics industry found itself in the same situation as the PC industry 30 years ago, namely lacking standardisation in terms of OS, hardware or programming language. The companies involved in robotics lack the equivalent of an operating system making it possible to run the same code on several different hardware platforms. In fact, each programmable robot seller offers its own programming environment and its own language.

In strategic terms, Bill Gates believes that robotics is a priority field in technology development and that each household will interact with robotic devices every day. “I believe that technologies such as distributed computing, voice and visual recognition, and wireless broadband connectivity will open the door to a new generation of autonomous devices that enable computers to perform tasks in the physical world on our behalf. We may be on the verge of a new era, when the PC will get up off the desktop and allow us to see, hear, touch and manipulate objects in places where we are not physically present.”

Bill Gates goes on to add that the cost of hardware is falling, which means that robotics can only become more widespread. Based on this observation, a working party was set up in 2004 headed by Tandy Trower (photo), chief architect of Microsoft Robotics Group. The outcome of this effort was the release of Microsoft Robotics Studio at the end of 2006. This application targets quite a broad population ranging from manufacturers, through researchers and teaching staff, to enthusiasts, who are referred to as hobbyists by Microsoft.

What is Microsoft Robotics Studio?

The principles that led to the proposed architecture

A single standardised platform

The main idea is to offer an integrated programming environment making it possible to build, test and debug robotics applications, without having to make any assumptions about the underlying hardware. Code portability is one of the major objectives.

Microsoft has opted to build on the .NET framework, a real cornerstone of programming at Microsoft.

Straightforward handling of issues specific to robotics

One of the main problems that robotics application developers need to deal with is application complexity resulting from the highly parallel nature of robotics programming. What is a robot? For the sake of simplicity, a robot is composed of three elements:

• A series of sensors enabling the robot to perceive its environment
• A computing unit (a processor)
• Effectors, typically motors, enabling the robot to act on its environment following orders given by the computing unit

The problem is that the sensors supply data to the computing unit continuously and in parallel, and it has to process this data in real time and order the actuators to act. It is not possible to stop the robot from working to wait for all the sensors to supply their data. Similarly, what happens if one of the sensors takes some time to react?

Robotics engineers have known the answer for a long time. Development is massively parallel, and so calls for the careful management of multi-threading. This can rapidly become troublesome, and can even take up the majority of development time to the detriment of that devoted to the program for the robot itself.

Microsoft has opted to do away with this entire component by offering an integrated multi-threading management model. One of the components of Microsoft Robotics Studio (see below) is CCR (Concurrency and Coordination Runtime). This is a library for C# .Net 2.0 code developed by George Chrysanthakopoulos within a group at Microsoft called Advanced Strategies. At the outset, therefore, CCR had nothing to do with Microsoft Robotics Studio, but it was integrated into Software Development Kits (SDK) as it meets the needs of robotics development perfectly. In fact, this library, as its name suggests, makes it possible to coordinate and manage service concurrency (multi-threading) both simply and safely.

Technological components

Microsoft Robotics Studio is a SDK that consists of three key technological components:

1. A runtime environment used to run .NET programs produced for any type of robot, i.e. CCR and DSS.
2. A set of development and debugging tools; tt is possible to use either Visual Studio for development based on .NET, or a new visual development tool called Visual Programming Language.
3. A simulation tool, making it possible to test programs built in a three-dimensional virtual environment simulating physical conditions (gravity, friction, forces, etc.).

Microsoft supplies a broad set of tutorials and code samples to enable anyone and everyone to gain proficiency in the tool.

In the remainder of this document, we will further describe each of the tools offered in this SDK. Let’s first look at the various versions of Microsoft Robotics Studio offered by Microsoft.

Prerequisites

Being an SDK, Microsoft Robotics Studio needs a set of tools to work. Fortunately, free versions of some of these tools exist:

• NET Framework 2.0
• Visual 2008 (the Express version of this tool is free)

Microsoft Robotics Studio is 64-bit compatible.

Licensing

Since the version MSRS 2008 R3, Microsoft Robotics Developer Studio is free (see http://www.microsoft.com/robotics)

The different releases

As of late 2008, the current version of Microsoft Robotics Studio is the third version, renamed Microsoft Robotics Developer Studio 2008 R3. Before this, two previous versions were issued.

Table 1: MSRS version history

Version 1.5 also provides (in the form of a separate download) an extra set of tutorials and program code called “Introductory Courseware for Microsoft Robotics Studio (1.5)”, which remains useful for the 2008 version.

CCR

Description

CCR (Concurrency and Coordination Runtime) is a managed library (.DLL) accessible from any .NET language that can be used to avoid the difficulties inherent in robotics multi-thread programming.

CCR is a library used to meet the following requirements:

• Asynchronism: The fact that different sections of the program can work independently and in parallel, without any one part causing the whole program to fail in the event of a problem.
• Concurrency: If the program is organised into several independent sections, the fact that more than one section may want to access the same resource at the same time needs to be dealt with.
• Coordination and error handling: Coordinating the various sections of the program and handling any errors that may arise.

By providing top-level methods, development complexity is much reduced and the application made more resilient.

Programming model

The main concepts of CCR programming are defined by certain key objects that we will now introduce.

Ports

Ports are FIFO (First In First Out) lists that can contain any .NET object. As we will see later, CCR ports are used by DSS to get services to communicate with each other. The CCR also defines collections of ports, which are named PortSets.

Arbiters

Arbiters are classes within which the user code will be run.

Tasks

Tasks are the objects generated when messages reach a port.

Dispatchers and DispatcherQueues

These objects are used to manage task scheduling and load balancing.

The DSS described in the following paragraph is based on CCR.

DSS

A service-based model

DSS is a runtime environment that sits on top of CCR, and which is used to run services that have been built using Microsoft Robotics Studio. DSS exposes the services that can be used (or “consumed”) by another program, another service or a user interface in a standardised manner. Under this model, a service may represent:

• A hardware component such as a sensor or actuator
• A software component in the user interface (such as a command window), a directory, a storage device, etc.
• A combination of the previous elements

There are a number of benefits in representing the various parts of a robot as services:

• ROBUSTNESS: Each service runs independently, making it possible to offer a loosely-coupled architecture. Consequently, if the service running a robot’s arm fails, the rest of the robot can continue to work. Services are insulated not only in terms of execution but also in terms of data.

• COMPOSABILITY: Services are standardised, which means that the way they are used, the way to communicate with them and the way to query their state are standardised. This simplifies code development enormously, because the developer does not have to reinvent the wheel for these different operations. Furthermore, services built in this way can be ported from one DSS node to another.

• OBSERVABILITY: DSS can be used to observe service states, thereby making it possible to determine the status of a system as a whole. This is known as observability. To do this, DSS attributes a URI to each service and exposes the state of those services. Furthermore, each service is accessible via a web browser, thereby increasing the system’s monitoring options.

Services are run within the context of a DSS node, which behaves like the services support environment. Services are able to communicate with each other in a standardised way, whether they are running within the same DSS node, or whether they are remote and using the network to communicate. Two protocols are used to access services, i.e. HTTP (making it is possible to view a service’s status from a browser) and DSSP (Decentralised Software Services Protocol), a protocol similar to SOAP, which is the protocol used to interact with web services.

What is a service?

- DSS is used to manage all parts of a robot and the related software in the form of services. DSS makes use of CCR to manage parallel processing.

A service is a programming model involving the following elements:

• A contract
• An identifier
• A state
• Communication ports
• Service handlers to handle incoming and outgoing messages
• Notifications
• Partner services

The figure below shows a service diagrammatically:

To create a service, simply create a project with Visual Studio and compile it, or create a project using Visual Programming Language, or indeed use the DSS New Service Generation Tool (DSSNewService.exe) command line utility.

The contract

Each service exposes a contract describing its behaviour. In a way, it is the service’s identity card and user guide. This contract enables other services to automatically set up a relationship with the service. The contract for a service can be inspected using the DDS Contract Information Tool (DssInfo.exe). Contracts are accessed via a URI named the “contract identifier”. This identifier is automatically created when creating the service.

Service identifier

Service state

This is a very important concept. The state is a representation of the service at a time T. One way to picture it is to imagine a document showing the contents of the service at a given point in time. The concept of observability described earlier is largely based on service states.

Any information about a service that can be obtained, changed or monitored must be described as being part of that service’s state.

For example, for a service representing a motor, the state may include:

• The number of revolutions per minute
• The hydraulic pressure
• The temperature
• The resistance
• Etc.

Partner services

Services must work together to achieve the application’s overall objective. When a service starts, it does not necessarily know where to find the services with which it needs to interact and whether they have started running.

To resolve this problem, DSS introduces the concept of partner services. Partner services are the list of services on which the current service depends or with which it interacts.

There are two types of partnership available:

• The service may declare that a partner service is mandatory, in which case, if the partner is not found, the current service does not start; or
• The service may declare a partner service as optional, in which case, if the partner is not found or does not start, the main service may nonetheless continue.

Main port

The main port (or operation port) is a CCR port where messages are exchanged with other services. Services do not in fact communicate directly, they simply send messages that are exchanged through their main port.

The main port is a private attribute in the service class, identified through the ServicePort attribute as shown in the example below.

[ServicePort("/myExample")]

private MyOperationExamples _mainPort = new MesOperationExemples();

The messages accepted on the main port are defined by the port type (in this case, the MyExampleOperations class). The list of possible operations on a port is declared in the port constructor. These are DSSP operations (Decentralised Software Service Protocol) or HTTP operations. An example of a port constructor is shown below:

public class MyOperationExamples : PortSet<DsspDefaultLookup, DsspDefaultDrop,
 Get,Replace, HttpGet, HttpPost>{}

The port set up using the above constructor defines six possible operations. The messages arriving on the port must therefore trigger one of these six methods.

Service handlers

A service handler has to be defined for each of the methods accepted on the main port (except for the two DsspDefaultLookup and DsspDefaultDrop operations, for which DSS defines default handlers). A handler is a method that describes what has to be done when a message received on the main port triggers the DSSP method.

The service handler can carry out any kind of operation changing the service state. It can also send a message to another service. To do so, it uses a service forwarder, which is a local CCR port representing the main port of the service to which the service handler wants to send a message. We see here that the service handler does not address the remote port directly, but uses a local port, which itself communicates with the remote port. For those familiar with them, it is very similar to how asynchronous messaging systems such as MSMQ or MQSeries work.

Event notifications

A service may also be notified if the state of another service is changed. This is called event notification. When a service A has subscribed to event notifications from a service B, service B generates and sends a message on service A’s main port.

Visual programming language

Visual Programming Language (VPL) is another component delivered with Microsoft Robotics Studio. This is a visual programming environment generating .NET code. Visual Programming Language therefore makes use of DSS and CCR. The .NET code generated can be opened and edited with Visual Studio (Microsoft’s professional development environment) and, similarly, programs coded using Visual Studio can be loaded into VPL.

The following figure shows a screen shot of this application.

The visual elements moved by drag-and-drop in this application are services. The left-hand panel lists the services found on the machine. VPL is delivered with a large number of services that can be integrated directly.

This environment is easy to use and makes it possible to build a program for a robot in a few minutes.

The main benefit of this environment compared with NXT-G, the development environment supplied with Lego Mindstorms NXT (which is also graphical and works in the same way by drag-and-drop), is that VPL works with virtually any robotics platform and not only with Lego Mindstorms NXT. In addition, special services for Lego Mindstorms NXT are supplied with VPL.

VPL can be used not only to run the code generated but also to debug it. VPL can be used not only to transfer code to a robot, but also to view how the code runs on a virtual robot developed in the visual simulation environment, as we will see in the next section.

Visual Simulation Environment

The last component delivered with Microsoft Robotics Studio is the Visual Simulation Environment (VSE), used to test the code you have produced in a 3-D virtual environment. The benefit of such a tool is obvious when you think that a poor program can damage a robot or its environment.

The environment rendering engine is based on the Microsoft XNA Framework, which is the framework used by Microsoft for developing games for the Xbox games console. To make the simulation realistic and thus provide added value, the VSE includes the AGEIA^TM PhysX^TM technology, which is a physics rendering engine. Such engines add our world’s laws of physics to the virtual world (the fact that up and down have meaning, impacts, gravity, friction, etc.).

The screen shots below show simulations produced using the Visual Simulation Environment:

To test code produced using VPL on a robot in the VSE, all you need are manifests (XML configuration files) specifying that you would like to use the VSE. Such manifests are supplied as standard in VPL for some robots, such as Lego Mindstorms NXT.

Using Microsoft Robotics Studio with a personal robot

We will see here a simple example used to simulate the steering of a Lego Mindstorms robot in a Visual Simulation Environment. The code will be generated using Visual Programming Language.

Creating the VPL diagram

Generic Differential Drive

Start the Visual Programming Language application from your PC’s Start menu. From the service tab on the left, select the Generic Differential Drive service and drag it into the working diagram (the central section of the VPL screen). When the Generic Differential Drive box is selected, in the properties column, on the right, there is a drop-down list named Configuration. Select “Use a manifest”. By doing this, the Generic Differential Drive service, whose objective is to steer a robot with two motors and two wheels (one for each wheel), will use an existing XML configuration file (a manifest).

Click on the Import button that has appeared. The following window pops up:

This window lists all the manifests found on your PC. These are XML files that you have either built or installed with MSRS. The manifest indicates the list of services that need to be started.

Select LEGO.NXT.Tribot.Simulation.Manifest.xml. This manifest tells MSRS that the robot to be launched is the Lego Mindstorms NXT tribot, and that it will be launched in the simulation environment. Note that if we had chosen Lego.NXT.Tribot.xml, that would have meant that the robot is a real robot. As you can see, switching from the simulation to the real environment is as straightforward as simply changing the manifest!

Simple Dashboard

Find the Simple Dashboard service in the list of services in the left-hand menu, and drag it onto the diagram.

Project generation

Save your work and then click on the Start button in the shape of a green arrow. This opens the RUN window, which shows you the technical stages of your program.

Then two other windows are opened:

• Microsoft Visual Simulation Environment (since specified in the manifest)
• The dashboard

In order to control the Tribot using the dashboard, the dashboard has to be told where to find the robot. To do so, enter your machine’s local IP address (127.0.0.1) in the Machine field, then click on the Connect button. You should see the Dashboard as shown in the figure below:

In the text field centre-right, the Dashboard has discovered the Tribot. Double click on it, then click the Drive button found on the left.

Direct the Tribot around the simulation environment using the direction ball found top-left. Note how the laws of physics are obeyed in the simulation environment, by charging at the block for example.

Through this simple example, we have shown how creating a robotics program can be both quick and easy using VPL, and we have also shown MSRS’ ability to create programs for different hardware platforms.

Conclusion

By way of conclusion, it is advisable to practice with MSRS using not only the many tutorials included within the MSRS help, but also the webcasts (online videos) offered by Microsoft.

We are convinced that if Microsoft continues its efforts, the robotics developer community will soon enjoy the kind of professional generic environment likely to ensure the lasting evolution of personal robotics.

Generation Robots (http://www.generationrobots.co.uk)

–

All use and reproduction subject to explicit prior authorization.