The Robotics Service Bus (RSB) is a message-oriented, event-driven middleware aiming at scalable integration of robotics systems in diverse environments. Being fundamentally a bus architecture, RSB structures heterogeneous systems of service providers and consumers using broadcast communication over a hierarchy of logically unified channels instead of a large number of point-to-point connections. Nevertheless RSB comes with a collection of communication patterns and other tools for structuring communication, but does not require a particular functional or decomposition style.

RSB is implemented as a flexible, lightweight toolkit. Based on previous experiences, the design and implementation try to avoid centralization and complicated dependency structures. Instead, functionality is organized in layers with minimal, clearly stated dependencies. The core library merely supplies the abstractions and machinery for building communication systems subject to varying requirements. This core is implemented in multiple programming languages with implementations trying to be in the spirit of the respective language as much as possible. As a result, RSB is not tied to a particular network transport, serialization mechanism or programming language. In addition, much effort is put into systematic testing and continuous integration.

These conceptual and implementation properties hopefully allow RSB to scale across a wider range of diverse functional requirements, heterogeneous hardware platforms and varying reliability and timing requirements than other robotics middlewares. Additionally, RSB‘s open architecture and project structure and lightweight implementation enable its use with small entry barriers and little framework lock-in.

For a concise introduction to the basic concepts of RSB, we refer the interested reader to the initial RSB publication [Wienke2011-AMC].


An event is the basic unit of exchanged data in RSB. Hence, all information required to fully specify and trace the condition it represents need to be present in the event. To fulfill these requirements, our event model consists of the following components:


The payload of an event is a user-defined object of the respective programming language which contains the major information specifying the condition the event represents.

It can be of an arbitrary domain type which reduces the framework lock-in by means of an early transition from framework types to domain objects for technical realization.


A unique ID for each event in an RSB-based system to make events addressable and foster traceability.

Meta Data

Each event is supplemented by meta data.

It consist of the event sender’s ID and several timestamps that

  • specify timing information relevant to the condition represented by the event (user-extensible)
  • make the the processing of the event within RSB traceable.

Besides these framework-supplied items, a key-value store for string-based additional meta data items is available for the client and user-defined timestamps can be added.

Causal Vector

This vector allows to represent the causing events of a given event, as proposed in [Luckham2001PEI]. It facilitates automatic system analysis and debugging.

Destination Scope

Specifies the recipients of the event notification by restricting the visibility of event notifications [Muehl2006-DEB].

The next section explains this concept in greater detail.


RSB forms a logically unified bus across different transport mechanisms. Different participants connect to this bus. Informers send events, whereas listeners receive events. From a logical perspective, no point-to-point connections are established.

In order to structure the communication via the bus – or stated differently, restrict the visibility of events for participants – RSB utilizes a hierarchical channelization scheme. This scheme is best explained by its declarative representation as a scope, which is represented in RSB with a hierarchical notation compatible with the path component of URIs [RFC2396-URI]. E.g. sending an event with destination scope /robot/camera/left/ will make this event visible in the channels represented by scopes /robot/camera/left/, /robot/camera/, /robot/, and /. Consequently, / represents a channel where all events of the system are visible. Each participant is associated to one channel, but multiple participants can participate at the same channel (m : n semantics).

The chosen hierarchical channel layout provides benefits for logging purposes and provides a first-class means of the framework to structure the data space, e.g. with subscopes for different services. However, it also increases the chance that a listener receives unexpected data, because a new informer appeared on a subscope of the listener’s scope. RSB’s filter mechanism allows clients to efficiently specify which events which to receive.




RSB is concerned with two kinds of types:

  • wire schemas which describe data being exchanged through transport mechanisms
  • data types which are restricted to individual clients, depend on the respective programming languages and describe domain objects before they get passed to RSB or after they have been obtained from RSB

Mapping between Wire Schema and Programming Language Types

This section documents the mapping between wire schemas, designators of which are included in RSB notifications, and corresponding programming language types. The values that are actually contained in notifications are called “String Designators” of wire schemas here.

Fundamental Types

Wire Schema String Designator C++ Python Java Common Lisp
No value "void" void None null nil
Double precision float "double" double   double double-float
Single precision float "float" float float float single-float
32 bit signed integer "int32" int32   int (signed-byte 32)
64 bit signed integer "int64" int64   long (signed-byte 64)
32 bit unsigned integer "uint32" uint32   int (unsigned-byte 32)
64 bit unsigned integer "uint64" uint64   long (unsigned-byte 64)
bool "bool" bool bool boolean boolean
ASCII string "ascii-string" string str String string
UTF-8 string "utf-8-string" string unicode String string
Sequence of Bytes "bytes" string   ByteString (simple-array (unsigned-byte 8)  (*))


In C++, support for the ASCII string and UTF-8 string schemas is limited in the following ways:

  • When decoding data in either schema, invalid strings will be accepted without signaling an error
  • In both schemas, string values are represented as std::string objects which known nothing about the respective encodings
    • In particular, UTF-8 multi-byte sequences appear as multiple char s

Structured Data




See also

Specification for handling of URI in RSB.

URIs or URLs are used in the following situations


See also

Specification for the configuration of RSB.

Quality of Service

For listeners, any guarantee applies to the stream of events received from the bus (not to the entire processing of a given event). In particular, it is possibly that the effective guarantees are weaker than those specified for the listener (if the informer has weaker guarantees than the listener).

For informer, any guarantee applies to the submitting of events to the bus. Guarantees at the receiving end may effectively be weakened depending on the listener configuration.


In the following lists of guarantees, subsequent items include all guarantees given by preceding items.



Events are delivered in (potentially) arbitrary order.


Every listener receives the events of one informer in the order the informer sent the events. No guarantees are given for events of multiple informers.

Independently of the requested ordering, no relations are guaranteed between events arriving at distinct listeners.



Events may be dropped and not be visible to a listener.


Events are guaranteed to be delivered. An error is signaled when events cannot be delivered.


Informers are thread-safe.

Listener are thread-safe. This implies:

  • Adding/Removing filters from arbitrary threads is allowed, but does not affect already registered handlers.

    The changed filters will be applied at some point in time, which may be much later than the method call.

  • Adding/Removing handlers from arbitrary threads is possible.

    Existing handlers will not notice any effect with respect to the stream of incoming events.

    For the added/removed handler, there is no guarantee that it will be called immediately / will not be called anymore when the add/remove method call returns. However, a flag can be set to achieve these guarantees.