MSRS contains services and tools that allow you to design, deploy, and debug your robotics applications. Applications built with MSRS will run over the Web or a local intranet as a collection of state-bound services that are isolated from each other. This will allow developers to build Web-based robotics applications that are lightweight and flexible. This section will provide an overview of the key components that make up MSRS.
The MSRS runtime, as depicted in Figure 1-2, makes use of three lower-level runtimes: Concurrency and Coordination Runtime (CCR), Decentralized Software Services (DSS), and the .NET Common Language Runtime (CLR) 2.0. CCR is a message-oriented model that allows applications to coordinate asynchronous processes and exploit concurrency in a very efficient way. DSS is a lightweight, service-oriented runtime that combines the principles used to power the World Wide Web with the architecture used to design Web services. CLR supports both base runtimes and provides access to the .NET Framework.
Figure 1-2. The MSRS runtime is built on top of CLR 2.0 and uses two key technologies—CCR and DSS—to build a set of services that supports the central object in MSRS, the service.
The CCR is the piece that ties the MSRS runtime to a service. Introduced at the same time as MSRS, the CCR allows applications to perform asynchronous operations. The CCR is a .NET library that can be used in any application that requires asynchronous processing. It shields developers from all the difficulties involved with writing their own threading code.
You might ask why asynchronous processing is so important for robotics applications. It’s important because, without asynchronous processing, your robot could move only one wheel at a time or one arm or leg at a time. Without asynchronous processing, the robot would have to wait for each service to complete what it is doing before it can start another service.
Robots are typically equipped with multiple sensors that read all sorts of data in their environments. At the same time, they have actuators that are used to perform a movement or accomplish a goal. All of these sensors and actuators must be coordinated to accomplish a common goal, which is operating the robot. The CCR manages the individual threads that are needed to make this happen.
Sensors
Robots use sensors to gather input about their environments. Essentially, they allow your robot to see, hear, touch, and smell. The types of sensors your robot uses will vary; dozens are available. Most robots come with at least one type of contact sensor. This can include whiskers that are sensitive to touch or phototransistors that are sensitive to light. Beyond that, the robot could have a sensor to record temperature or a GPS receiver to identify its location.
Without the CCR, developers would have to create several callback methods to coordinate services. Applications would also require complex threading code to prevent blocking of asynchronous operations. This could quickly become cumbersome to manage. The developer is shielded from all of the work being done under the covers to manage asynchronous operations and deal with parallel execution. For more information about the CCR, refer to the CCR user guide available at http://msdn2.microsoft.com/library/bb483107.
DSS is a lightweight application model that allows developers to monitor services interactively in real time. DSS is based on the Representational State Transfer (REST) design principles. REST encompasses a set of principles used to define the technologies that power the World Wide Web. The Web is a stateless environment, which means that every time you access a new Web page, the information returned from the last request is discarded. Each request is independent of the last. Although .NET Web developers can use server-based containers such as session variables to store information between requests, each request is independent of any other.
REST is not a standard, but it does use standards to accomplish its goals. The REST principles specify how resources are used, and the requested information is transmitted across the Web. It enables the Web to be stateless, layered, cacheable, and thus highly scaleable. These simple principles are what allow millions of people to successfully use the Internet each day.
To operate and monitor robots remotely, MSRS needed a distributed solution that operated efficiently. It made sense to use the REST principles because they provided an efficient way of traversing the Web. REST supported the widely used Hypertext Transfer Protocol (HTTP) communication protocol, and, along with Extensible Markup Language (XML), this could be used to return structured XML data quickly.
MSRS also needed a transport protocol that was flexible and able to accommodate distributed scenarios in a platform-independent manner. The transport protocol Simple Object Access Protocol (SOAP) was the best choice, but the MSRS developers needed something like SOAP, only with a few extra benefits. They needed to support subscriptions. Subscriptions allow a service, the core object used by MSRS, to receive event notifications.
Service
A service, which is accessible over the Web and local intranet with a Uniform Resource Identifier (URI), is a key object in an MSRS robotics application. A service is a set of code used to perform some operation on one or more objects. Services are like building blocks for a robotics application, and one or more are used to collect data from robots and then instruct them on what to do.
To support subscriptions, the MSRS designers incorporated principles from Web services. This allowed them to provide a flexible solution that took advantage of structured data manipulation and event notification. By using principles from the REST model along with Web services, MSRS is able to offer an extensible and efficient platform that supports access across different machines. When you combine this with the ability of DSS to isolate each service from one another and the ability to separate state from behavior, you have a powerful tool in the development of distributed robotics applications.
DSS also offers the ability to transport services through Transmission Control Protocol (TCP). This is sometimes advantageous because TCP provides minimal Central Processing Unit (CPU) utilization and reduced latency. At the same time, TCP provides an HTTP/XML path to every service. This gives you the ability to observe remotely the behavior of your robot through a Web browser.
Note
Just because MSRS uses Internet protocols as the basis for the runtime does not mean that your robotics applications will have to run across the Internet or even the local intranet. In fact, all the components of your robotics application can reside on the same machine. It also does not mean you have to become a Web developer and start designing Web sites. This section was meant to provide an understanding of the principles that underlie the base DSS runtime.
MSRS offers a SOAP-based protocol named Decentralized Software Services Protocol (DSSP). DSSP, which was created specifically for MSRS, extends upon HTTP and offers an alternative method for message-based operations. For example, one of the HTTP operations allowed through MSRS is GET. This operation is used to return requested data as raw XML. Although MSRS supports the HTTP GET operation, in order for one service to handle the data sent from another service, it needs to be sent as a SOAP message.
One of the primary advantages to using services is that they can work together to accomplish a common task. It is often necessary for one service to pass information to another service. For this to be done, each service must accept incoming messages in a machine-readable format, such as a SOAP message.
DSSP offers comparable replacements for all the HTTP-based operations, such as GET, POST, PUT, and QUERY. DSSP also offers additional operations that specifically support functionality required by MSRS. For example, to support subscriptions, MSRS needs an operation that requests event notifications be sent to a subscribing service. HTTP does not support a SUBSCRIBE operation, but DSSP does. The SUBSCRIBE operation was added specifically to support this functionality in MSRS.
DSSP is not meant to be a replacement for HTTP or Web services; it is simply an extension of HTTP that takes advantages of some of the things offered by Web services. For more information about DSSP, refer to the specification document available at http://download.microsoft.com/download/5/6/B/56B49917-65E8-494A-BB8C-3D49850DAAC1/DSSP.pdf.
DSS provides an extensible foundation that allows it to offer a set of infrastructure services known as the runtime services. These services are used to manage other services created with MSRS. Services managing services might seem confusing, but that is exactly what is happening. For example, there is a runtime service that renders an HTML-based user interface known as the Control Panel. The Control Panel, which lists all the services running on your development machine, is used to locate and run other services.
The Visual Simulation Environment (VSE) tool included with MSRS offers programmers a way to enter the world of robotics without any robotics hardware. Powered by the AGEIA PhysX engine, VSE renders advanced physics graphics comparable to graphics used in the best computer games on the market. VSE also uses the Microsoft DirectX 9 runtime components and Microsoft XNA (not acronymed) to do 3-D rendering. This means the machine you use to do simulations must support DirectX 9 pixel/vertex shader standards, but that is not a problem for most of today’s mid- to high-end desktop machines.
VSE is great for students and hobbyists who want to learn about robotics and who do not have the time or money to invest in expensive robots. Typically, the expense of advanced hardware forces teams of students or commercial developers to schedule time to work with a single robot. With VSE, each team member can work with the simulation tool as long as required and then apply his or her individual work directly to the actual robot.
VSE can also be useful for developers wanting to prototype their robotics project. Instead of having to spend a lot of time building and configuring robots, programmers can test their code before they risk damaging expensive equipment. Obviously, the downside to using a simulation tool is that it is not entirely realistic. In the "real world," of course, robots encounter unforeseen obstacles and have to react in ways their programmers never expected. For this reason, simulation is useful at the beginning of a project, but only use of an actual robot will yield "real world" results.
The simulation engine, which in itself is just another service, uses a native physics engine wrapper and library that are built on top of the AGEIA PhysX engine. (See Figure 1-3.) Optionally, you can purchase the PhysX processor, which was created specifically to enhance the PC gaming experience. The PhysX processor will support hardware acceleration, which may be necessary when working with some heavily CPU-intensive simulations.
Tip
You can still work with simulations without the add-in card; you will be limited to working with a smaller number of objects. If you need to do simulations involving several hundred robots performing at the same time, you will likely need to purchase the PhysX processor.
Figure 1-3. The VSE simulation engine is based on the AGEIA PhysX engine, along with Microsoft XNA Framework and the DirectX 9 runtime.
The simulation engine is also based on the Microsoft XNA Framework and DirectX 9 software development kit (SDK). The XNA Framework is a set of class libraries built against the .NET Framework that allow game developers to create games easily by using C#. The DirectX 9 runtime, which is used by the XNA Framework, allows developers to build cutting-edge multimedia applications such as VSE. If you do not already have these libraries on your development machine, the MSRS installation program will include them and tell you if you first need to uninstall an incompatible version of the DirectX 9 runtime.
VSE works by managing entities, which can represent any physical object, such as a robot, an obstacle, a camera, and even the sky. Services are used to move the robots around and gather data from sensors. Orchestration services are used to coordinate a group of services. You can use the same services in the simulated world as you do using the MSRS runtime. This makes VSE a useful tool for prototyping a robotics project.
Graphics scenes can be rendered in one of four modes: visual, wireframe, physics, or a combination of all three. Visual mode (see Figure 1-4) represents what the robot would look like in the real world. Wireframe mode is a pixilated version that shows just an outline of the objects. Physics mode is a simpler view that shows how objects are modeled by the physics engine. The simulation tool will be covered in detail in Chapter 4.
MSRS includes the visual code-generation tool named VPL. Integrated with Visual Studio, VPL can be used by both beginning and experienced programmers. To build a program, a user only needs to drag and drop blocks, which represent activities or services, onto the design surface. VPL offers two kinds of activities. The first, basic activities, includes input data, calculations, and variables. The second, service activities, includes the built-in services that come with MSRS as well as the services that you build. VPL also includes the runtime services used to power MSRS.
Connections are used to specify that the output from one block will be used as the input for another block. Figure 1-5 displays a basic program that consists of two blocks with one connection. This program displays the phrase "Hello World" inside a dialog box. In this case, the "Hello World" string is entered into the first block and then sent as output to the second block. The second block receives it as input and then displays it as an alert.
VPL can be used to build complex programs such as those that collect and process data from multiple robot sensors. It can also be used to create autonomous behavior for any robot that has a distance-measuring device and differential drive system. Even experienced programmers may find that it’s quicker to build an application using VPL and the built-in services provided with MSRS.
Figure 1-5. The VPL tool provides a visual application design environment in which users drag and drop blocks onto a design surface.
VPL can be used to build complex programs such as those that collect and process data from multiple robot sensors. It can also be used to create autonomous behavior for any robot that has a distance-measuring device and differential drive system. Even experienced programmers may find that it’s quicker to build an application using VPL and the built-in services provided with MSRS.
Differential drive system
Many robots today (and especially those currently supported by MSRS) are wheeled robots. To operate a wheeled robot, you must utilize the robot’s differential drive system. This is used to steer the robot in any direction. Each wheel on a robot is powered by a motor, and these motors accept values that indicate how much power to apply to each wheel. The direction that your robot moves is determined by the difference between the power sent to the right and left wheels. At this point, it is not important for you to know exactly what values to use, but understanding how this works is critical to operating most robots. And do not worry: MSRS comes with built-in services that will help you drive your robot.
You can save VPL applications as files with an .mvpl file extension. Several of the robotics tutorials that come with MSRS include VPL files. This will be particularly helpful for new and experienced programmers as they are learning how robotics programming works. Chapter 3, will provide more information about how VPL works.