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 |_.OpenRTM-aist |
*Aspect* | *ROS* | *YARP* | *XCF/AM* | *RSB* |
| Pub-Sub | yes | yes | yes | yes | yes |
| .. Push-receiver | yes | ? | yes | yes | ? |
| .. Pull-receiver | ? | ? | yes | yes | ? |
| Client-Server | yes | 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