William Wong
|
ED Online ID #16631 |
September 5, 2007
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.
My existing project in vc++ 6. I want to make My project GUI based Like LabView, GraphEditor,etc using MS Robotics Studio. So if You have some idea regarding how to use DSS service of MS Robotics Studio in My vc++ application please help me.
Anonymous -August 26, 2008
Your Comments:
Enter the text from the image below
Please refresh the page if you have trouble reading this text.
Search Electronic Design
Web Seminar
Sponsored By:
Title: Read Pacing: A Performance Enhancing Feature of PCI Express Gen 2 Switch Devices
Reprints
