Robotics Service Bus

h1. Framework Comparison

h2. Scope

Please note: We are comparing RSB against roscore (or even ros_comm?) not against ROS!

and YARP_OS?

h2. Functional Differences

|_.Aspect            |_.ROS                       |_.YARP                                    |_.XCF/AM                |_.RSB                       |_.OpenRTM-aist |

| Pub/sub Topology   | 1:1                        | m:n                                      | 1:n, m:n over AM       | m:n                        | 1:1           |

| Abstraction        | single level               | single level                             | single level           | hierarchies                | single level  |

| Channel Identifier | Topic                      | none?                                    | name or URI(?)         | Scope                      | ? |

| Channel Scope      | Flat                       | Flat                                     | Flat                   | Hierarchical               | ? |

| Origin Filtering   | ?                          | no?                                      | not required for 1:n   | planned                    | ? |

| Content Filtering  | ?                          | no                                       | yes (via XPath)        | via extension, e.g., XPath | ? |

| Typing             | static,strong              | dynamic                                  | none                   | strong-ish                 | strong |

| IDL                | yes, proprietary           | no                                       | no                     | optional, standardized     | yes |

| QoS                | implicit                   | limited support, mixed with flow-control | limited, local queuing | explicit                   | ? |

| Introspection      | strong                     | nameserver, port admin protocol          | limited                | implicit by multicast      | though component model (interface as well as data)

| Centralized        | yes (master, param server) | yes (nameserver), direct connect. poss.  | yes, dispatcher        | no                         | yes (broker) |

| Event meta-data    | client level               | ?                                        | yes                    | yes                        | ? |

h3. Communication Patterns

| *Aspect*         | *ROS* | *YARP* | *XCF/AM*     | *RSB* | 

| Pub-Sub          | yes   | yes    | yes          | yes   |

| .. Push-receiver | yes   | ?      | yes          | yes   |

| .. Pull-receiver | ?     | ?      | yes          | yes   |

| Client-Server    | yes   | yes    | yes          | yes   |

h3. RPC Features

| *Aspect*            | *ROS*                      | *YARP* | *XCF/AM* | *RSB*                          | 

| Asynchronous RPC    | ?                          | ?      | ?        | yes                            | 

| Parallel Pipelining | ?                          | ?      | ?        | yes                            | 

| Dynamic Typing      | kind-of (schema in header) | yes    | yes      | no (for Protocol Buffers)      | 

| Connection pooling  | manually configurable      | ?      | ?        | no pooling, but reuse          | 

| Delayed return      | ?                          | ?      | ?        | no                             | 

| Event-driven I/O    | ?                          | ?      | ?        | no (one thread per connection) |

_Criteria are based on http://msgpack.org/, explanations "here":http://wiki.msgpack.org/display/MSGPACK/Design+of+RPC#DesignofRPC-MessagePackRPCFeatureList ._

h2. Non-functional Properties

* Architecture

* Dependencies

h3. Openness

| *Aspect*                                | *ROS*           | *YARP*          | *XCF*      | *RSB*                        | *OpenRTM-aist* |

| Lock-in                                 | strong          | ?               | ?          | ?                            | component-model |

| Use of standards/terminology            | partial         | almost none     | XML, XPath | partial                      |

| Protocol Specification                  | yes, inaccurate | yes, inaccurate | no(?)      | yes, uses IDL                |

| Source Code Documentation               | ?               | ?               | partial    | client-level nearly complete |

| Project Layout/Source code organization | monolithic      | confusing       | confusing  | at least, we have a plan...  |

| Transport Extensions                    | ?               | maybe           | no         | yes |

h3. Programming Language Support

| *Language*  | *ROS* | *YARP*   | *XCF*   | *RSB* | 

| C           | ?     | partial? | no      | no    |

| C++         | impl  | impl     | impl    | impl  |

| Java        | impl? | ?        | impl    | impl  |

| Python      | impl  | ?        | binding | impl  |

| Common Lisp | impl  | ?        | binding | impl  |

| Ruby        | ?     | ?        | no      | no    |

h3. Operating System Support

h2. Thoughts

* ZeroMQ

** Socket-level Client API + rich configuration (however, not modeled explicitely)

** Serialization is not considered

h2. Wishes

* We believe in the power of reflection and self-description, such that

** a generic content-based subscription model, e.g., with path-based access such as XPath becomes feasible

** messages can be generally understood by everyone even if parts are not accessible

* We further believe in powerful representations, such that

** component can be re-used without recompiliation if optional parts of message formats change or information is added (this may be a difference to ROS / LCM where every module has to be recompiled)

* RSB shall provide better introspection features, both for programmatic access (e.g., for anomaly detection) but also for developers

* Reduced framework lock-in