Framework Comparison¶
Scope¶
Please note: We are comparing RSB against roscore (or even ros_comm?) not against ROS!
and YARP_OS?
Functional Differences¶
| Aspect |
ROS |
YARP |
XCF/AM |
RSB |
OpenRTM-aist |
| Pub/sub Topology |
m:n |
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 |
? |
Communication Patterns¶
| Aspect |
ROS |
YARP |
XCF/AM |
RSB |
OpenRTM-aist |
| Pub-Sub |
yes |
yes |
yes |
yes |
yes |
| .. Push-receiver |
yes |
? |
yes |
yes |
? |
| .. Pull-receiver |
? |
? |
yes |
yes |
? |
| Client-Server |
yes |
yes |
yes |
yes |
yes |
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 .
Non-functional Properties¶
- Architecture
- Dependencies
Openness¶
| Aspect |
ROS |
YARP |
XCF |
RSB |
OpenRTM-aist |
| Lock-in |
strong |
? |
? |
? |
yes (component-model) |
| Use of standards/terminology |
partial |
almost none |
XML, XPath |
partial |
yes (CORBA) |
| Protocol Specification |
yes, inaccurate |
yes, inaccurate |
no(?) |
yes, uses IDL |
yes, IDL |
| Source Code Documentation |
? |
? |
partial |
client-level nearly complete |
yes, sometimes only japanese |
| Project Layout/Source code organization |
monolithic |
confusing |
confusing |
at least, we have a plan... |
jp website only |
| Transport Extensions |
? |
maybe |
no |
yes |
? |
Programming Language Support¶
| Language |
ROS |
YARP |
XCF |
RSB |
_OpenRTM-aist |
| C |
? |
partial? |
no |
no |
no |
| C++ |
impl |
impl |
impl |
impl |
impl |
| Java |
impl? |
? |
impl |
impl |
impl |
| Python |
impl |
? |
binding |
impl |
impl |
| Common Lisp |
impl |
? |
binding |
impl |
no |
| Ruby |
? |
? |
no |
no |
no |
Operating System Support¶
Thoughts¶
- ZeroMQ
- Socket-level Client API + rich configuration (however, not modeled explicitely)
- Serialization is not considered
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