ROS 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	RSB
Pub/sub Topology	1:1	m:n	m:n
Abstraction	single level	single level	hierarchies
Channel Identifier	Topic	none?	Scope
Channel Scope	Flat	Flat	Hierarchical
Origin Filtering	?	no?	planned
Typing	static,strong	dynamic	strong-ish
IDL	yes, proprietary	no	optional, standardized
QoS	implicit	limited support, mixed with flow-control	explicit
Introspection	strong	nameserver, port admin protocol	implicit by multicast
Centralized	yes (master, param server)	yes (nameserver), direct connect. poss.	no

Communication Patterns¶

Aspect	ROS	YARP	RSB		Push-receiver	yes	?	yes
Pull-receiver	?	?	yes

RPC Features¶

Aspect

ROS

YARP

RSB

Asynchronous RPC

?

?

yes

Parallel Pipelining

?

?

yes

Dynamic Typing

kind-of (schema in header)

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/

Non-functional Properties¶

• Architecture

Openness¶

Aspect	ROS	YARP	RSB		Lock-in	strong	?	?
Use of standards/terminology	partial	almost none	partial
Protocol Specification	yes, inaccurate	yes, inaccurate	yes, uses IDL
Source Code Documentation	?	?	?
Project Layout/Source code organization	monolithic	confusing	?

Programming Language Support¶

Language	ROS	YARP	RSB		C	?	partial?	no
C++	yes	yes	yes
Java	yes	?	yes
Python	yes	?	yes
Common Lisp	yes	?	yes
Ruby	?	?	no

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
• RSB shall provide better introspection features, both for programmatic access (e.g., for anomaly detection) but also for developers
• Reduced framework lock-in