MS Robotics Studio

Microsoft’s Robotics Studio (MSRS) is a programming environment designed to address a wide range of robotic applications. Version 1.5 contains a number of improvements including support for CE 6.0 and Windows Mobile, enhancements to the VPL (Visual Programming Language), a new manifest editor, and new sample applications. MSRS is a .NET/Windows-based development environment that can target a number of Windows platforms from Vista to Windows Mobile although not the Microsoft's smaller .NET Micro Framework (See A Small .NET Makes A Big Catch). Still, the latter will have a part to play as MSRS can support many robotic platforms that are incapable of running MSRS applications natively. For example, the iRobot Create (See Real Robots: iRobot Create) does not have the horsepower but it can be operated as a remote control robot via an MSRS application. I used Whitebox Robotics 9-Series PC-Bot (See White Box Robotics PC-BOT) as a native MSRS test platform. But more on that later.

MSRS Components

The MSRS consists of a number of components that include the development system and deployment/runtime system. Microsoft Visual Studio (VS) is the centerpiece for development where developers can employ C# and VB.NET along with the new scripting language, Iron Python. VS is based on the .NET Framework and can generate applications that utilize it as well. The MSRS runtime is also based on the .NET Framework — hence the target platforms. Another new language is Visual Programming Language (VPL). The other two main components in the MSRS runtime are the Concurrency and Coordination Runtime (CCR) and the DSSP (Decentralized Software Services Protocol). These are designed to address the dynamic kinds of environments that robots encounter and the type of applications necessary to support them. Finally there is the Microsoft Visual Simulation Environment (VSE). Real robots like the PC-Bot tend to be cumbersome to test. While real-world testing and operation is necessary and usually the desired end result, robotic simulation is easier to do and it offers a development environment that is often more sophisticated and changeable. The MSRS also presents some of itself via a web-based interfaceTogether, these components make up an environment targeted at robotic research and development. Still, the combination and components are actually more general and applicable to a wider range of applications. For example, the CCR and DSSP can address a range of real time applications including embedded applications. Likewise, the VPL offers an interesting alternative to text-based applications. Now for a closer look at the major components.

Concurrency and Coordination Runtime (CCR)

At the heart of the MSRS runtime is the Concurrency and Coordination Runtime (CCR). It addresses application asynchrony, concurrency, coordination and failure handling. It is a very general framework that can handle a range of applications, not just robotics. It just turns out that robotics is very demanding in this area. CCR exposes primitives that address tasks and intratask communication. This includes things like ports and portsets, arbiters, tasks, dispatchers and queues. Ports are essentially queues of any data type supported by the .NET CLR (common language runtime). Arbiters are objects that execute when certain conditions are met. They can be combined with ports and portsets. CCR tasks can employ conventional coordination primitives such as locks. They can also utilize features like joins and futures. Joins wait for the occurrence of multiple events while futures are port results that promise to generate data sometime in the future but are available for that occurs. CCR can interact with Asynchronous programming model (APM) .NET APIs. This environment provided by CCR is similar to ones used in other robotic frameworks. Alone, it is just a tool, although it provides primitives that differ significantly from those found in the base .NET Framework. It is possible to use other aspects of the MSRS without delving into CCR but developers doing any low-level component creation will bump into this part of the system. Typically the functionality will be called via programming languages such as C#, Visual Basic and Iron Python.

Decentralized Software Services (DSS)

The Decentralized Software Services is something that all MSRS developers will need to contend with at least in understanding the system’s theory of operation. It is built atop the CCR and employs the Decentralized Software Services Protocol (DSSP) that is a XML/SOAP-based protocol. This means it operates over the Internet as easily as within a robot. Essentially, XML messages are sent to a service that will respond in kind. XML transactions cannot be processed as fast as the lower-level CCR interactions so DSSP tends to be used for higher-level functionality. A DSS service is the basic building block. It contains state information, identification and has ports that can accept messages and service handlers to process these messages. Since these are XML messages using a SOAP protocol they can be generated and responses processed by any application, not just ones developed for the MSRS. Likewise, DSS services can interact with any system that employs the same protocol. In fact, this is the approach taken with many robotic systems that do not run MSRS natively. Instead, the DSS services on the application’s system interact with those on a remote system to obtain environmental status and to control devices such as drive motors. A DSS service can also send notifications and be associated with partner services. DSS projects are started using a command line program. The projects can then be opened using Visual Studio. The Microsoft DSS Manifest Editor is used to define and configure services that are part of MSRS. The editor is not used to create or debug DSS service handlers. This is done using other tools like Visual Studio and programming languages like VPL. Microsoft has a host of other DSS tools as well from one to generate proxies to another for deploying DSS services. DSS services can have or provide a user interface or simply interact with other, non-ui services. For example, a motor control service would not have any user interface associated with it but developers could use standard DSS service user interface controls for handling a motor control directly. Building DSS services can be different than using DSS services depending upon the framework being use. For example, a DSS service written in C# can use other services. The same is true for VPL.

Visual Programming Language (VPL)

VPL is similar to other graphical programming languages like National Instruments' LabView and The Mathworks Simulink. VPL does not have the extensive support as these two platforms, yet. It is currently a standalone IDE instead of part of Visual Studio. VPL does use a similar drag-and-drop component integrated development environment where components are dropped on a workspace and then “wired” up to each other. The components can have multiple inputs and outputs. The resulting “diagram” is an application that can be executed. VPL is a complete programming environment that runs atop .NET so it is possible to access objects and services created using other programming tools. This includes the MSR runtime hence its use within the robotics studio. Debugging is similar to other graphical environments. Breakpoints can be set along wires so the program can stop when a piece of data is generated. A VPL diagram is converted into C# code that will compile to an assembly containing one or more DSS Services. This allows VPL components to be utilized by other applications as well.

VPL appeals to non-programmers because it is easier to visualize. In fact, VPL is as complex as any text-based system and it will take that level of programming expertise to master VPL as well. Still, the initial startup and the ability to easily access other components will make it very desirable in robotic programming where developers have a wide range of programming backgrounds. VPL is not required to use MSRS but it will likely remain as one of its key aspects.

Microsoft Visual Simulation Environment (VSE)

The Visual Simulation Environment (VSE) is designed to provide a simulated 3D environment based on objects that interact with their simulated environment using DSS services. The environment can be visually appealing or it can be rendered as line drawings. By default it uses the typical physics environment so you can’t put two objects in the same space at the same time. The theory is a robot can be easily simulated with a simple redirection of the DSS services being employed. In practice, it works rather nicely. In fact, developers can take advantage of MSRS exclusively using VSE. It is possible to create a simulated robot from scratch but most developers are likely to employ models developed for them. For example, robots like the iRobot Create (See Real Robots: iRobot Create) have simulated versions available on the Internet. The other advantage of VSE replication is trivial: Want six bots? No problem. Of course, there's also a downside. Simulations are approximations. It is easy to simulate a robot that goes straight on a flat surface, but in the real world that doesn’t happen. Likewise, there is a certain "fuzziness" in the operation of sensors and actuators that is actually hard to simulate. Still, the advantages typically offset any of the disadvantages. Developers simply need to be aware of the extent and limitations of a particular simulation environment. From an application standpoint, a VSE robot and a real robot normally differ only by the DSS connections. Running the VSE demos is a trivial exercise and Microsoft provides a number of examples. Making the sample platforms work with another application is a much more difficult process on par with working on a real robot like the Whitebox Robotics 9-Series PC-Bot.

MSRS On Whitebox Robotics 9-Series PC-Bot

Whitebox Robotics's 9-Series PC-Bot has a Mini-ITX motherboard that is capable of running operating systems like Windows and Linux. This allows the PC-Bot to run MSRS applications or even be used as a development platform. It is possible to attach a monitor to the robot but it is much easier to use remote desktop software instead. The advantages of this approach is having a single environment for development, testing and deployment. The disadvantage is the power of the system is less that the latest desktop or laptop PC. The big problem installing and using MSRS on almost any platform including the PC-Bot is the complexity of MSRS and all the related components. Likewise, some items come from other sources like the .NET drivers for the PC-Bot. For simplicity, I installed MSRS completely on the PC-Bot and a separate instantiation on a PC that would use the VSE almost exclusively. I won’t go through all the gory details but it starts with the .NET Framework and a copy of Visual Studio plus any of the desired languages. Next comes the MSRS software and then Whitebox Robotics' DSS services for the PC-Bot. Reserve at least an afternoon because there is a lot of software. The actual installation process isn't lengthy, but getting used to where everything is and what it does in general will take some time. The DSS services available from Whitebox Robotics support the robot as a service in addition to a service that implements a GUI interface. The latter is similar to the B.R.I.A.N. interface that comes with the PC-Bot but it is completely implemented using MSRS. One thing I did run into was the differences between MSRS 1.0 and 1.5. There is evidently enough difference between the two that an update will be required to handle the latest version of MSRS. MSRS is still a project in flux so these kinds of quirks are to be expected. The GUI provides access to all of the stock features including the motors, sensors and webcam. The webcam support can take snapshots or video clips. It is possible to toggle IO ports and drive the system using the mouse or a joystick. The big advantage over B.R.I.A.N. is that the host services are a completely separate DSS service. The GUI worked equally well on the PC-Bot or a remote PC. One interesting aspect of the client/server architecture that MSRS highlights is the ability to have an application utilizing the PC-Bot services and also using the GUI. This is handy for performing maintenance such backing up the robot when it gets stuck. I actually worked with the PC-based simulation environment to get the hang of MSRS. Unfortunately there is no support for a simulated PC-Bot at this point but there are enough other platforms to choose from to experiment with MSRS. I still don’t have a good feel for the entire MSRS environment but I can address the basics at this point. For programmers like me with C/C++ background it is probably faster to do some of the initial experimentation using C# instead of VPL or Iron Python. Then again, others may prefer those depending upon their background. If you run through the online tutorials and such you can spend at least a week getting comfortable the system. Replicating the basic functionality of the Brian user interface (See Robots: White Box Robotics PC-BOT) that comes with the PC-Bot using Whitebox Robotic’s components was the first chore. It took a day or so, more due to the lack of familiarity with MSRS than complexity of the job.

MSRS In General

MSRS is definitely more complex than the other robotic platforms I have looked at, and it is potentially more powerful as well. It provides a standardized platform, although it's tightly coupled to Microsoft's tools and operating system platforms. Granted, DSS communication can work across standardized networks but building a similar framework on a different platform is no small task. For those familiar with .NET, C# and the like, Microsoft's robotic framework makes sense. It builds on .NET assemblies. On the plus side, MSRS is now the target for most vendors of robotic platforms. DSS services to control these platforms are now becoming available. Prior to MSRS, there was not common platform for developers to target. MSRS is becoming popular because it is a rallying point around which developers can provide their product specific aspects as well as algorithms that others can then utilize. Its web-based roots allow control and cooperation across standard network links. On the other hand, MSRS is possibly too complex. It's harder to use than any of the other robotic development environments I've looked at in this series. Even a quick run-through of the numerous Microsoft provided tutorials is enough to deter even the determined developer. Unfortunately, the tutorials often tell how to do something but there are so many details that it is difficult to understand the context. Part of the problem is the amount of code needed just to get started. Granted, much of this is generated by things like the command line tools for creating a new DSS service but this makes it very easy to accidentally creating a problem. For example, a minor deviation from a tutorial can result in something that will not build properly. This tends to be less of an issue for those familiar with Visual Studio but it may make MSRS less preferable as a starting point. MSRS still utilizes a good deal of text-based commands and interfaces. This can be an advantage for some and the diagnostics are very useful. GUI interfaces tend to have a problem by isolating users from these details but it is exactly what is required when doing low level development. MSRS is improving steadily from 1.0 to 1.5 and I expect even more when it finally hits version 2.0. Its dependency on command line programs highlights its rough edges at this point. The big problem at this point is that MSRS is still growing. The basic support being delivered by most vendors provides access to the sensors and movement controls, not more sophisticated navigation and algorithmic support. The plus side is that MSRS appears to be a good platform to deliver these kinds of services. Some video tracking support is provided by Microsoft which is a good start. MSRS is an impressive platform whose components are not restricted to only robotic applications. Much of the MSRS protocols are covered the Microsoft Open Specification Promise license. It is, in theory, an open license but I have not had a chance to examine it in detail and neither can I render a legal opinion on it. It is clearly nothing along the lines of other open source licenses like GPL or LGPL but it may provide the openness that standards committees will find acceptable. Microsoft is talking with Open Source Initiative (OSI) about its licenses so this is likely to be fodder for another story. Microsoft’s commitment to MSRS is probably the most impressive part of the environment. It is clear that Microsoft intends to stick with this platform although it remains to be seen whether the path changes of the past (like COM, DCOM, WIN32 etc.) are replicated with MSRS.