During my exploration of Microsoft Robotics Studio (MRS) over the course of a several weeks, I frequently referenced the Microsoft Robotics Studio Developer Center, in particular the video and written tutorials. While there is a lot of good information to be found there, it can be hard to follow at times, especially for those beginning with very little C# experience. The following overview is a collection of my "thoughts" about MRS. I refer to them as thoughts because they are based largely on my own experimentation and may or may not be completely accurate. The intent, though, is to fill in some of the gaps left by the tutorials so beginners can achieve a clearer understanding of MRS with less trial and error.
Before beginning, the reader needs to have a decent grasp on programming in general, specifically object-oriented. This goes hand-in-hand with the need for a basic understanding of C#; however, one can brush up on C# in a few days if they have experience with other programming languages such as C, C++, or Java. If a person is completely new to programming however, MRS may prove very frustrating. For those needing a suggestion for where to start learning C#, I recommend the book Microsoft Visual C# .NET Step By Step by John Sharp and Jon Jagger. This is what I used to get up to speed and found it an easy read if you already have programming experience. The book also talks a little about SOAP and XML, which is also used quite a bit in MRS.
Finally, this overview is meant to supplement the information provided in the aforementioned tutorials. Whether or not going through the tutorials first and then reading the overview or vice versa is easier will left for the reader to decide, but going through the tutorials at some point is advised.
Services and Manifests
Almost everything in MRS is done with a service, or different sets of services. A service is essentially a compiled DLL used to control something, whether it is a piece of hardware, another service, or something else. To see how services are combined and utilized, consider a differential driven robot with a bumper (contact) sensor in front. To control this robot in MRS, there would be a service which controls the motors. There would also be a service which controls the sensor. Then there would be what is called an orchestration service which would control both of these services, tying them together.
Orchestration services are the means by which different services are combined and controlled to make a robot do something useful. While the services which run the motors and sensors may be written once and never edited again, it is usually an orchestration service which receives most of the attention and recompiling. Depending on the complexity of the code being written, it is even worthwhile to sometimes have a service which controls an orchestration service. Possible reasons for this will be explained in a moment.
The program dsshost.exe is central to MRS as it is what manages the running services. In order to start a service, you specify its manifest with the dsshost command at the MRS command prompt by including the -manifest switch. A manifest is nothing more than an XML file which tells dsshost.exe what service(s) to start. When a new service is created using the dssnewservice command, a manifest is created for that service. Unedited, specifying only that manifest will only start that service. This is where orchestration services come into play again.
Any service that is used internally by another service is called a partner to that service. So using the example robot described above, the services controlling the motors and the sensors would be partners to that orchestration service, let’s call it RobotControls.manifest.xml. In many instances, a partner service needs to be started before it can be used. One way to do this is to specify all three services like this:
dsshost –port:50000 –tcpport:50001
–mainfest:”C:\examples\RobotMotors.manifest.xml” –manifest:”C:\examples\RobotSensor.manfiest.xml” –manfiest:”C:\examples\RobotControls.manfest.xml”
Although this should work, it is a lot of typing. The other way to open multiple services would be to edit the manifest for the orchestration service such that it automatically starts its partner services whenever it is started. It would then only be necessary to specify one manifest to open all three.
While the use of all these services and manifest may be confusing at first, they can prove to be very useful. For example, let’s consider the task of adding automation to the example robot. One way to do this would be to simply edit the orchestration service, recompile it, and then run it from dsshost.exe. While this works, it can be limiting. One of the nicest features of MRS is its simulation service, which allows for testing of real world robots in a simulated environment. In order to test the example robot in a simulated environment, some code in the orchestration service would need to be rewritten so that it could interact with the simulation and then recompiled (not to mention the manifest would require editing so it starts the simulation service). To go back to the real world tests, these changes would have to be undone. This is not only time consuming, it also makes it hard to determine if bugs are being created from the automation code or the code that makes it work in each environment.
The alternative to this, as briefly discussed above, is to create a separate service for the automation code that interacts with the orchestration service in a generic fashion. This allows for the creation of another set of corresponding services, ones that interact with the simulation. There could be a simulated motor control service, a simulated sensor controls service, and of course the simulated orchestration service. By doing this, all the developer has to do is program in the automation service. If he or she wants to test the robot in a simulated environment, they run the automation service in conjunction with the manifest for the simulated orchestration service from the command prompt. Similarly, the robot can be tested in the real world just as easily by running the real world orchestration service’s manifest.
Concurrency and Coordination Runtime
At the core of MRS is Microsoft’s Concurrency and Coordination Runtime (CCR). CCR is a library which allows things to occur in MRS seemingly at the same time. For instance, a robot can be moving in a programmed trajectory while simultaneously monitoring its contact sensor. Should a sensor be tripped, it can handle this event while still processing the trajectory code.
CCR is a port based system. Ports are first setup to receive certain types of message and then after that, a listener can be activated to monitor the port. The listener is told how it should handle each message type and should a message be sent to the port, such as one indicating the robot has bumped into something, the listener takes the appropriate actions.
Unfortunately, CCR is dealt with in a “learn as you go” fashion in the tutorials, without much emphasis placed on understanding what it really is. The article An Asynchronous Messaging Library for C# 2.0 provides a good overview of what CCR is, how it is used, and references for even more information.
Partnering with Services
In order for a service to interact directly with another service, it needs to be partnered with that service. It should be noted that partnering a service makes the service it is partnered to dependant upon it to start. This relationship is defined more precisely with the Partner creation policy described below.
Creating a Partnership:
- The first step in creating a partnership is to add a reference to the service that will be partnered. When a service is compiled, it produces three files which are, by default, placed in the bin folder of the MRS install directory. When adding a reference, always use the file ending in .proxy.dll.
- After adding the file as a reference, it helps to add a using statement. Using statements reduce the amount of typing needed to access a namespace by allowing aliases to be assigned to them. The using statement
using bumper = Microsoft.Robotics.Services.ContactSensor.Proxy
allows for the Microsoft.Robotics.Services.ContactSensor.Proxy namespace to be referenced with the alias bumper.
- Finally, define the partnership below the _mainPort definition in the ServiceName.cs file. The partnership is defined with two parts. The first is an attribute which denotes the reference where the service resides, its unique contract identifier (which is just the string used to recognize the service), and the creation policy. The creation policy indicates whether the service should use an existing instance of its partner service, create an instance, or check first and create an instance if it does not find one. If the partner service is not started for whatever reason, perhaps the creation policy is UseExisting and an instance is not running, the service will fail to start itself. The second part creates the port object that will be used to communicate with the partner service.
After adding the definition, it should look something like this:
[Partner("bumper", Contract=bumper.Contract.Identifier,
CreationPolicy=PartnerCreationPolicy.UseExisting)]
private bumper.ContactSensorArrayOperations _bumperPort =
new bumper.ContactSensorArrayOperations();
