locked
ROS user considering move to MS Robotics RRS feed

  • Question

  • Hi all, (apologies for the long first post!)

    I've recently changed jobs from a robotics research and development role in a predominantly Linux environment to a product developer in a predominantly MS Windows environment. In my previous role I used ROS and other publish/subscribe middleware heavily (e.g. DDX - a shared memory/multicast publish subscribe framework and CORBA/DDS).

    Does anyone here have suggestions on the easiest way to obtain similar functionality in a windows environment? I'm not so much after robotics algorithms, but more a simple to use, effective, lightweight publish subscribe framework to base our products upon in a distributed loosely coupled architecture.

    So far I've seen some msdn articles about using WCF for publish subscribe, but it's up to the reader to implement significant amounts of the supporting framework from what I understand. I understand that the MS robotics studio provides these over the dss, but I haven't had time to go through the tutorials yet. We've looked briefly at named pipes but had trouble getting them to work reliably in a flexible manner for a loosely coupled system.

    Key things that were very useful under ROS and DDX:

    * Share a simple file that defines message structures for the publisher and subscriber clients (in ddx it was a header file that was included in the publisher and subscribers, ROS had something similar though I can't recall off the top of my head, CORBA has the .idl file). Basically I'm after a simple file or other mechanism that can be shared between parties to define the message structures.

    * Simple implementation for use. In ROS and DDX, the publisher basically fills in the message structure with the desired information then does a call to some publish() function with the structure and topic name as an argument in a loop. The subscriber defines a callback and message topic name as an argument to a subscribe() function that is then called every time a message comes through with that topic. There is almost no other coding from the user required to get the message passing going. All the detail is handled by the middleware process and the libraries.

    * Logging of the passed messages. All messages (or a user selection of messages on particular topics) that go through the ROS and DDX comms layer can be logged by running an inbuilt utility. This can then be replayed later as if the system is running, or the messages from a particular topic loaded up as a simple text file for offline analysis.

    Can anyone shed some light on what MS tools provide the above and the best way to get up and running with them quickly? If it isn't readily available then I guess we'll just have to invest effort into getting some in-house solution based on WCF or pipes going.

    Also, can I install the MS robotics studio without all the simulation and other extraneous stuff (ie. just minimal DSS and its dependencies) for deployment on our prototype systems? Its nice to have some basic development functionality so when a dev is in the field debugging some new product they can remote desktop into the hardware and recompile the app with some minor changes on the fly.

    Sadly I've found trying to get overview information out of the documentation on MSDN sites a painful and slow process, hence this thread. please help us make an informed decision!


    • Edited by nickopen Thursday, January 5, 2012 2:32 AM
    Thursday, January 5, 2012 2:29 AM

Answers

  • Robotics Developer Studio is probably the best solution for you at this point in time. To avoid confusion, I will use MSRDS to refer to Robotics Developer Studio. We do not normally use that acronym, but in print RDS can look similar to ROS.

    Firstly, some background. At a conceptual level ROS and MSRDS are similar. Both have Service Oriented Architectures and use message passing. However, they differ a lot in implementation.

    A ROS Node is called a Service in MSRDS. In MSRDS a DSS (Decentralized Software Services) Node is roughly equivalent to the Master in ROS, although you can have multiple DSS Nodes on the same or different machines each running multiple services.

    MSRDS is based on REST (Representational State Transfer) so a key feature of MSRDS services is their internal State which can only be accessed and modified by a set of defined Operations. In this regard, MSRDS is much more similar to Web Services than ROS. In fact, one transport that MSRDS can use is XML SOAP messages. There is however a binary transport, called dssp-tcp, for the sake of efficiency (similar in principle to TCPROS). MSRDS does not use named pipes, although there was a sample transport that did this in a previous release. We find that people do not generally care about the transport.

    Both ROS and MSRDS support a publish/subscribe paragidm. Under ROS you publish Topics explicitly, but in MSRDS any Service you write can provide Notifications. In both cases you must explicitly subscribe and you specify a "callback" handler for incoming messages.

    Services in MSRDS are orchestrated, i.e. partnerships are established amongst them, using an XML Manifest document. This allows for easy re-configuration of services at runtime. ROS has XML Launch documents that perform a similar function.

    MSRDS configuration information is stored in the form of saved XML State files. These are loaded when services start. In contrast, ROS uses a Parameter Server for its configuration information, and parameters can be loaded from the command-line or in the Launch file.

    Now to answer your questions:

    * Share a simple file that defines message structures for the publisher and subscriber clients (in ddx it was a header file that was included in the publisher and subscribers, ROS had something similar though I can't recall off the top of my head, CORBA has the .idl file). Basically I'm after a simple file or other mechanism that can be shared between parties to define the message structures.

    MSRDS does not share information about Service Contracts via header files. Instead, you add a reference to a Service Proxy in your service project (source code) and this exposes the available Operations (message types) and the service State so that you can create instances of messages and extract information from the state. If you want somebody to interact with your service, you give them the proxy DLL. (Visual Studio takes care of the details using .NET Reflection).

    * Simple implementation for use. In ROS and DDX, the publisher basically fills in the message structure with the desired information then does a call to some publish() function with the structure and topic name as an argument in a loop. The subscriber defines a callback and message topic name as an argument to a subscribe() function that is then called every time a message comes through with that topic. There is almost no other coding from the user required to get the message passing going. All the detail is handled by the middleware process and the libraries.

    An MSRDS service publishes notifications by creating a Subscription Manager (to handle all the distribution issues) and then sending Notifications whenever its state changes. Subscribers must issue an explicit subscribe request to the relevant service and specify the particular Notification messages that they are interested in. The specified handler will then be called whenever a new Notification of that type arrives. (There is a Service Directory and you can look up services dynamically, but usually the partnerships are established in Manifests). Obviously there are syntax differences, but the process is basically the same as ROS.

    * Logging of the passed messages. All messages (or a user selection of messages on particular topics) that go through the ROS and DDX comms layer can be logged by running an inbuilt utility. This can then be replayed later as if the system is running, or the messages from a particular topic loaded up as a simple text file for offline analysis.

    For MSRDS, you can turn message logging on or off in the DSS config file. You can also explicitly add a logging header to messages to use as a filter because logging all traffic can impose a significant burden on the computer, e.g. 30 frames per second of image and depth data from a Kinect sensor is a lot of data! Logs are stored on a per-service basis with timestamps on the messages. You can write your own log analysis tools (as services) using the DSS Log Analyzer that uses a "plug-in" model.

    Also, can I install the MS robotics studio without all the simulation and other extraneous stuff (ie. just minimal DSS and its dependencies) for deployment on our prototype systems? Its nice to have some basic development functionality so when a dev is in the field debugging some new product they can remote desktop into the hardware and recompile the app with some minor changes on the fly.

    Once you have installed MSRDS you will find a Redistributables folder. In there is a package that installs CCR (Concurrency and Coordination Runtime) and DSS (Decentralized Software Services), i.e. the runtime for MSRDS. However, with a little bit of care you can create xcopy deploy packages for MSRDS systems, i.e. no installation required, just splat the files on the hard drive. Just be aware that recompiling will require Visual Studio 2010 to be installed on the target computer. You can currently use Visual Studio C# Express for this, which is free.

    Trevor

     



    • Edited by Trevor Taylor Saturday, January 7, 2012 9:40 PM
    • Marked as answer by nickopen Monday, January 9, 2012 1:05 AM
    Saturday, January 7, 2012 9:36 PM

All replies

  • Robotics Developer Studio is probably the best solution for you at this point in time. To avoid confusion, I will use MSRDS to refer to Robotics Developer Studio. We do not normally use that acronym, but in print RDS can look similar to ROS.

    Firstly, some background. At a conceptual level ROS and MSRDS are similar. Both have Service Oriented Architectures and use message passing. However, they differ a lot in implementation.

    A ROS Node is called a Service in MSRDS. In MSRDS a DSS (Decentralized Software Services) Node is roughly equivalent to the Master in ROS, although you can have multiple DSS Nodes on the same or different machines each running multiple services.

    MSRDS is based on REST (Representational State Transfer) so a key feature of MSRDS services is their internal State which can only be accessed and modified by a set of defined Operations. In this regard, MSRDS is much more similar to Web Services than ROS. In fact, one transport that MSRDS can use is XML SOAP messages. There is however a binary transport, called dssp-tcp, for the sake of efficiency (similar in principle to TCPROS). MSRDS does not use named pipes, although there was a sample transport that did this in a previous release. We find that people do not generally care about the transport.

    Both ROS and MSRDS support a publish/subscribe paragidm. Under ROS you publish Topics explicitly, but in MSRDS any Service you write can provide Notifications. In both cases you must explicitly subscribe and you specify a "callback" handler for incoming messages.

    Services in MSRDS are orchestrated, i.e. partnerships are established amongst them, using an XML Manifest document. This allows for easy re-configuration of services at runtime. ROS has XML Launch documents that perform a similar function.

    MSRDS configuration information is stored in the form of saved XML State files. These are loaded when services start. In contrast, ROS uses a Parameter Server for its configuration information, and parameters can be loaded from the command-line or in the Launch file.

    Now to answer your questions:

    * Share a simple file that defines message structures for the publisher and subscriber clients (in ddx it was a header file that was included in the publisher and subscribers, ROS had something similar though I can't recall off the top of my head, CORBA has the .idl file). Basically I'm after a simple file or other mechanism that can be shared between parties to define the message structures.

    MSRDS does not share information about Service Contracts via header files. Instead, you add a reference to a Service Proxy in your service project (source code) and this exposes the available Operations (message types) and the service State so that you can create instances of messages and extract information from the state. If you want somebody to interact with your service, you give them the proxy DLL. (Visual Studio takes care of the details using .NET Reflection).

    * Simple implementation for use. In ROS and DDX, the publisher basically fills in the message structure with the desired information then does a call to some publish() function with the structure and topic name as an argument in a loop. The subscriber defines a callback and message topic name as an argument to a subscribe() function that is then called every time a message comes through with that topic. There is almost no other coding from the user required to get the message passing going. All the detail is handled by the middleware process and the libraries.

    An MSRDS service publishes notifications by creating a Subscription Manager (to handle all the distribution issues) and then sending Notifications whenever its state changes. Subscribers must issue an explicit subscribe request to the relevant service and specify the particular Notification messages that they are interested in. The specified handler will then be called whenever a new Notification of that type arrives. (There is a Service Directory and you can look up services dynamically, but usually the partnerships are established in Manifests). Obviously there are syntax differences, but the process is basically the same as ROS.

    * Logging of the passed messages. All messages (or a user selection of messages on particular topics) that go through the ROS and DDX comms layer can be logged by running an inbuilt utility. This can then be replayed later as if the system is running, or the messages from a particular topic loaded up as a simple text file for offline analysis.

    For MSRDS, you can turn message logging on or off in the DSS config file. You can also explicitly add a logging header to messages to use as a filter because logging all traffic can impose a significant burden on the computer, e.g. 30 frames per second of image and depth data from a Kinect sensor is a lot of data! Logs are stored on a per-service basis with timestamps on the messages. You can write your own log analysis tools (as services) using the DSS Log Analyzer that uses a "plug-in" model.

    Also, can I install the MS robotics studio without all the simulation and other extraneous stuff (ie. just minimal DSS and its dependencies) for deployment on our prototype systems? Its nice to have some basic development functionality so when a dev is in the field debugging some new product they can remote desktop into the hardware and recompile the app with some minor changes on the fly.

    Once you have installed MSRDS you will find a Redistributables folder. In there is a package that installs CCR (Concurrency and Coordination Runtime) and DSS (Decentralized Software Services), i.e. the runtime for MSRDS. However, with a little bit of care you can create xcopy deploy packages for MSRDS systems, i.e. no installation required, just splat the files on the hard drive. Just be aware that recompiling will require Visual Studio 2010 to be installed on the target computer. You can currently use Visual Studio C# Express for this, which is free.

    Trevor

     



    • Edited by Trevor Taylor Saturday, January 7, 2012 9:40 PM
    • Marked as answer by nickopen Monday, January 9, 2012 1:05 AM
    Saturday, January 7, 2012 9:36 PM
  • Thank you very much for the detailed reply.
    Monday, January 9, 2012 1:05 AM
  • Fantastic write-up, Trevor--thanks! Might be good for a blog post :-)

    I did a quick Google (er, Bing) search for other ROS-vs-MSRDS comparisons and came across this very high-level write-up: http://find.botmag.com/021187

    Arthur

    Monday, January 9, 2012 8:08 PM
    Moderator
  • Thanks for the link. I am aware of that article - I subscribe to the magazine.

    In fact, Ben was an intern in the Robotics Group several years ago and I know him.

    Trevor

     

    Tuesday, January 10, 2012 8:22 AM
  • Sure--I just figured the original poster might find the article useful, if he hasn't stumbled on it yet.

    Arthur

    Tuesday, January 10, 2012 4:56 PM
    Moderator