Serializer Services - 30,000 Foot Introduction - (MSRS) Post 2

NOTE: These posts assume that you've read through some of the basic Microsoft Robotics Studio Tutorials and worked through some of their sample projects.

Where do I start? There's so much cool stuff to learn!

For the purpose of the next sequence of posts, I'm going to cover our Serializer Services collection only. Then, I'll follow up with our Traxster Drive Service. I want to keep the blog simple, and straightforward. Future posts will build on complexity and cover more advanced topics. Eventually, we'll be cooking with gas!

When I traveled to Redmond to get my two day crash course on MSRS last April, the concepts and archietecture weren't like anything I had ever seen, so I hope to help out newbies to MSRS understand what I didn't. The basic framework and architecture makes sense now (thanks to Joseph Fernando and Andreas Ulbrich), but it took me a while to fully understand how the basic architecture works.

Decentralized Software Services Protocol

Before I get started on the Serializer Services, I think it's important to provide a quick explanation of Services and DSSP, just so we can have them handy.

The following excerpts are from Microsoft's Decentralized Software Services Protocol document. They do a much better job than I could ever do of explaining the jist of DSSP. :)

Microsoft Robotics Studio Services are based on the Decentralized Software Services Protocol (DSSP). DSSP is a simple SOAP-based application protocol that defines a lightweight service model with a common notion of service identity, state, and relationships between services. DSSP defines a set of state-oriented message operations that provide support for structured data retrieval, manipulation, and event notification.

DSSP defines an application as a composition of services that, through orchestration, can be harnessed to achieve a desired task. Services are lightweight entities that can be created, manipulated, monitored, and destroyed repeatedly over the lifetime of an application through operations defined by DSSP.

This last excerpt regarding destruction and creation seemed really cool to me. Why? Because if you have a rogue service which is misbehaving, you can simply terminate it, spawn a new identical service, and continue on your merry way! So, Services beware! Instant discipline for bad behavior! :)

Basic Terminology

I think it's also important to understand, and use, the terminology defined by Microsoft regarding MSRS services. Thus, I'm going to include some basic terminology below, again repeating Microsoft's DSSP document verbatim.

Service - A service is a computational unit that has
identity, state, behavior, and context.

Application - An application is a composition of
services that through orchestration can be harnessed to achieve a desired
task.

Service State - The data representing a service at a
specific point in time

Service behavior/contract - The behavior of a service
(aka the contract) is the combination of the content model describing the state
and the messages exchanges that a service defines for communicating with other
services.

Partner - A partner is a labeled reference representing
a behavioral relationship that a service has to another service.

Message - A message is a one-way message, a request, or
a response participating in a DSSP operation.

Request - A DSSP request is a message participating in
a request-repsonse message exchange pattern.

Response - A DSSP response is a message participating
in a request-repsonse message exchange pattern.

Now I can communicate using this terminology, and you'll understand what I'm writing in this post, and in subsequent posts. :)

What does DSSP really buy me?

Since all Robotics Studio services are based on DSSP, we can take advantage of the fact that they can be distributed. This means that an application can be composed of multiple services running on local, or distributed computers.

Another advantage of DSSP is that services can serve as a basic building blocks to provide simple behavior. These basic services can be assembled together to build more complicated services and behaviors.

Futhermore, once you debug the service, everyone can reuse it (and not have to debug it again). Not only does this promote code reuse, but also improves reliability.

Lastly, DSSP allows you to pick and choose only those services you need "a la carte" using an XML manifest file. I'll discuss the manifest file in upcoming posts. So, as you can see, DSSP is very powerful!

What are Serializer Services?

The Serializer Services are actually a collection of what I call Serializer Peripheral (SP) services, or "SP services" for short. SP services encapsulate well defined functionality built into our Serializer .NET robot controller. Such functionality includes various distance sensor services, motor control services, wheel encoder services, servo services, I/O services, etc.

SP services all use a single central "Serializer service" as their Partner. The Serializer service is responsible for handling communications to and from the physical Serializer robot controller, as well as provide an external command-response interface to SP services. This allows the SP services to send a command to the service, and receive the response back (if needed). The SP services then update their internal state, and if they have subscribers, will send a notification that the state has changed.

An Example Application

I'm going to close by discussing the diagram below, which is composed of a Drive service, several SP services, a single Serializer service, and the actual Serializer robot controller.

Starting on the right, the Drive service sends messages to the main port (red dot) of specific SP services, such as a "SetMotorPower" message sent to the Motor service(s). When the Motor service(s) receive those messages, they in turn, send a message to the main port of the Serializer service. When the Serializer Serializer service receives the message, it sends the proper serial command to the Serializer robot controller.

Once the Motor service(s) receive a response from the Serializer service, they update their state, and in turn, notify the Drive service over the notification ports (yellow/orange rectangles). As the Drive service receives these notifications, it can update it's GUI, since now it knows for sure the motor power was correctly set.

Some of the SP services have internal timers, which fire internally to tell them to periodically update their state. An example is the Sonar service. Every time the internal timer fires, it sends a message to the Serializer service. The Serializer service then sends a command to the Serializer robot controller to query the state of the sensor connected to it. The value the propogates back up to the Sonar service, which updates it's internal state, and as you've probably already guessed, sends a notification to the Drive service.

Although the diagram shows a single notification port on the DriveService, there are in reality, a notification port for each partner.

Conclusion

In the next post, I'll discuss the Serializer service interface in more detail. Subsequent posts will drill down into the SP services, and finally into the Drive Service.

-Jason Summerour

Microsoft Robotics Studio Services (MSRS) Post #1

We have been hard at work integrating our products with Microsoft's new Robotics Studio. We had hoped to make Services for our products available for our customers before now, however, time just hasn't permitted.

What's the holdup?
Between developing new products, documenting products, shipping products, issuing new software releases, handling everyday business, and having some semblance of a life, it's been hard to find the time to complete the services. Not only are we learning how Robotics Studio works, but we're also writing, testing, and documenting the services we're developing.

What we've been doing over the past 3 months:
Our initial set of services (June 06) actaully communicated with our Serializer .NET library (which implements the Serializer Protocol). The Serializer .NET library then communicated w/ the Serializer. Although we did get these services running, there was very poor performace. This was due to the fact that the Serializer .NET library, as well as Robotics Studio, both used the threadpool. This caused massive threadpool contention.

So, Microsoft suggested that we simply implement the Serializer protocol in the Serializer Services, and keep the Serializer .NET library available for customers who want to use it in a .NET application (not Robotics Studio).

I must say that the Robotics Studio group at Microsoft has provided excellent and timely help to us, and has done so with open ears. That shows us that they're dedicated to making a great product, and that they listen to the customer.

When will they be available?
It looks like we'll have an initial set of services for our Serializer .NET Robot controller and Traxster Robot Kit available by the end of September. You will be able to use all of the functionality the Serializer .NET Robot controller provides, as well as drive around one of our Traxster Robot Kits, which use a Serializer as their main controller.

We are also providing some tutorials, and rich diagrams to help explain how our services work, and how customers can tap into them.

Once we have the basic services in place, we'll be adding additional services to support current and future products.

More to come...

-Jason Summerour

Introduction

Welcome to the RoboticsConnection Blog Site. Here we will blog about our various robotic developments, experiences, and activities. Please feel free to post comments.

Best Regards,

Jason Summerour
President,
Summerour Robotics Corp