The ROS 2 Vision
For Advancing the Futureof Robotics Development
Sep. 21st 2017
Dirk Thomas, Mikael Arguedas
ROSCon 2017, Vancouver, Canada

"Unboxing"

Icons made by Freepik from www.flaticon.com is licensed by CC 3.0 BY

Getting Started
command data

video data

Moving Outdoor
command data

video data

Quality of Service
ComputerRobot

joysticknode/cmd_velreliableflight cntrl
node

image viewnode

/imagebest eﬀort

cameranodeExtend Capabilities: Hardware
ComputerRobot

image view
node/imagecamera
node

image view
node #2/image2camera
node #2

Rename topic
at runtime

Extend Capabilities: So ware
Robot/cmd_vel

flight cntrl
node/image_lele cameranode/image_right

right camera
node/obstacles

stereo imagepipeline nodeRecap #1

Multi-OS support: Linux, Mac OS, Windows
Binary packages for Mac OS and WindowsDiﬀerent client libraries share common implementation
Quality of Service: variety of configuration options
DDS provides even more configuration options, directly accessible
Hardware with "native" communication interface(no need for separate protocols and driver packages)
Event based notifications (rather than need for polling)
Remapping of topics at runtime

Undeterministic Startup
Robotnodes ready/cmd_velflight cntrl
node/image_lele cameranode/image_right/obstacles
no obstacles reported

stereo image
pipeline noderight camera
node
node not readyLifecycle State Machine

unconfigured

inactive

activefinalized

Deterministic Startup
Robot
all active/cmd_velflight cntrl
node/obstacles
Ready to fly/image_le/image_rightle cameranoderight camera
node

stereo image
pipeline node

Coexistance with ROS 1/cmd_velreliable/image
best eﬀort

running ROS 1

Usage Patterns of the "ros1_bridge"
Beta
TurtleBot 2 demo
Robot using ROS 2 onboard
Computer uses ROS 1 tools,
leverage existing ROS 1 packages
Beta
HSR demo (see talk)
Robot using ROS 1 onboard
Computer uses ROS 2 tools,
leverage intrinsic advantagesof the communication protocol

Usage of the "ros1_bridge"
ROS 1 Robot/cmd_velreliableflight cntrl
node
ros1_bridge
node/image
best eﬀort

processing
nodecameranode

Usage Patterns of the "ros1_bridge"

Incrementally migrate a ROS system

RobotROS 2 nodebridge

Beta
TurtleBot 2 demo
Robot using ROS 2 onboard
Computer uses ROS 1 tools,
leverage existing ROS 1 packages
Beta
HSR demo (see talk)
Robot using ROS 1 onboard
Computer uses ROS 2 tools,
leverage intrinsic advantagesof the communication protocol

ROS 1 node

ROS 1 nodeMulti Robot

Distributed discovery useful for on-demand robot-to-robot comm.
All current ROS middleware implementations support it
As long as all robots use the same comm. protocol
they can communicate (independent of the vendor)

Quality of Service settings to tailor the comm. for the specific scenario(see eProsima's talk @ 11:35)

Dynamic remapping of topics enables various diﬀerent approaches, e.g.:
Flip namespaced robot spec. topics to be "global"/robotA/pose → /pose
Subscribe to a specific topic from a group of robots/**/pose or /floor2/*/pose

Adding a Custom Sensor
RobotHomeMCU module
Same ROS 2 code!
receivernode/found_beacon
BeaconPose estim.
nodeGPS receivernodeFlight Controller Internals
Flight controller node
Subscription thread

Realtime thread

Publication thread/found_beacon/return_home

Recap #2

Lifecycle nodes
Basic Python-based launch files
Launch utilizing lifecycle state machine
Dual-home bridge to exchange msgs / srvs between ROS 1 and ROS 2
More configuration options
Multi robot benefiting from the communication protocol:
distributed discovery, configurable QoS, dynamic remapping"Native" communication protocol with micro controllers (DDS-XRCE)
Proof of concept for real time support using custom allocators
No usage of real time kernel yet, no continuous testingProcess Layout Decision
Robot/cmd_vel

flight cntrl
node

Save configuration/obstacles
as launch fileSingle Process/image_le/image_rightle camera
noderight camera
nodestereo image
pipeline nodeFault Tolerance and Fallback Behaviors
Fallback behavior #2:
switch to monocular det.

right camera
node/image

mono. obst.
detect node

Unsecure Systemcommand data
Command spoofed

video dataSecuring the Systemcommand data
Authentication

Encrypt sensitive data
video data

Validation and Certification

Use certified hardware components (which talks DDS)
Use certified DDS implementation
Use certified / validated so ware components

Select only the subsystems of ROS 2 which are required for the use case
Build your own subsystem on top→ Reduced eﬀort to validate the custom application by
Using certified subsystem
Reducing footprint as much as possible

Recap #3

Choose process layout at deploy time
Support from launch to easily configure thisEvent based system providing the infrastructure for fault detection,
no tooling yet
Security following the DDS-Security standard
Fine grain configuration
None of the ROS 2 development is certified
But it can interoperate with certified implementations

Questions...

For more information go to:ros2.org