Distributed Networks within ROS: Challenges and Possibilities

Distributed Multimodal Information Processing Group
Prof. Dr. Matthias Kranz Technische Universität München

Distributed Networks within ROS:

Challenges and possibilities

Luis Roalter

Technische Universität München, Germany


About

Studied 2004
Electrical Engineering and Information Technology
Technische Universität München

Starting PhD thesis 2009
Technische Universität München

Research Topics:

•  Intelligent Systems, esp. for home-automation

•  Systems for homecare

•  Wireless Sensor Systems and Smartphones

•  Human-Computer Interfaces

20.09.2012 Luis Roalter 2


Challenges

•  Large Intelligent Environments will have a substantial number of devices

•  Integration of sophisticated robots into Intelligent Environments

•  Make use of the “Internet of Things” within Intelligent environment

•  Transition to modern IPv6 protocol stack to be prepared for future networks

•  Make use of a distributed master-network

•  Security concerns in large networks



Problems to Solve:

•  Internet of Things (which could be a robot as well) commonly depends on
IPv6, so ROS needs to be able to speak IPv6

•  Large environment are equipped with a huge number of sensors. A central
ROS master would be inappropriate

•  Communication has to work over borders of networks (Routers or different
radios). Creating bridges between networks will increase the number of
use-cases

•  Internet of Things and Embedded systems have lower power. Decrease the
size of the core-system and ease the configuration (low-weight nodes)

•  A large number of nodes can lead to namespace-collisions. Usage of clear
naming rules have to be established



The IPv6 protocol

•  Expands the IP address range
•  Easier routing techniques possible within IPv6
•  Uses 128 bits for single addresses
•  Always get the same address within a network
•  Coding host-specific parts into the address (features, device-id, …)



IPv6-Ideas for ROS

•  Code the current location of the device inside the IP
•  Directly connect to devices from the Internet of Things
–  In short: with a local proxy master (gateway to devices)
–  In long: Full multimaster capability inside the client libraries

•  Communicate directly over network borders
–  No more NAT in the way
–  Smartphones with IPv6 connection can become part of the network from
any place
–  Problem: security concerns (when accessible from everywhere)



Multimaster Capabilities

•  Local masters reduce latency and CPU load
•  Multiple masters increase the reliability of the whole network

•  Robots with on-board master would integrate easily (nodes to ::1)
•  /remote/<master-name> namespace for non-local nodes:
–  Nodes on different master can have the same name
–  Less collisions
–  Namespace of the node contains its approximate location



Proxy Master Concept

•  Replace a full ROS master
•  Looks for another master and redirects all traffic to it
•  Very small memory footprint as no internal state has to be kept
–  Interesting for embedded devices



Naming in ROS: Metadata for Nodes

•  Achieve a common and collision free namespace
•  No reconfiguration of any node for a specific network layout
•  Central set of rules controls the whole namespace
•  Nodes can look for services of local nodes or search the whole namespace



Routing of Traffic Between Different Networks

•  Routes access to topics
–  Reduce network load for nodes
–  Interesting for low bandwidth and low power nodes (wsn)
•  No benefit when calling services
•  Usage of a VPN tunnel between two machines can be used to bridge two
networks
–  If a tunnel fails, the two networks continue to operate autonomously



Security Risks

•  Problems may occur due to problems in the HTTP-calls
–  DoS (Denial of Service)
–  Man-in-the-Middle Attack

•  The attacker may fakes information that leads the robot trough the wall
–  Integrity of data
–  Certificates for connections
–  Encrypting of data transferred



Adapting ros_comm  ros_comm6

•  Full IPv6 support for the master, client and libraries

•  ROS extensively uses names to address other nodes
•  Names can be provided by:
–  /etc/hosts and regular stateless address auto configuration
–  By DHCPv6
–  DHCPv6 allows to specify how the IP address is generated

•  IPv6 is disabled by default and controlled with the environment variable
$ROS_IPV6
–  Has been tested with the PR2 simulation, virtual machines and on
network running on a set of Beagle Boards
–  Implemented for C++ and Python; Java and Lisp still missing



Stability Enhancements

•  Better handling of temporary errors due to name resolving:

–  Nodes can loose connections over a longer period of time and get found
again

–  IP can change as long as the name stays the same

–  There is no timeout for local nodes if they loose the connection.
This could be a problem as the master does not check for alive nodes



Planned implementation

•  Local sync node registers with remote master

•  The remote master send updates of its status to the sync node

•  The local sync node updates the local master with new information

•  The local master informs local nodes about new remote nodes

•  All remote nodes are put into the /remote/-namespace
–  Prevents cycles: The sync node only cares about changes of nodes which
are not in the /remote/-Namespace



The “Multimaster”

•  Fully mashed network between sync nodes and the masters
–  Other sync nodes are discovered using multicast
–  High network load for masters with frequent changes
–  High failure tolerance if a master is not reachable anymore
•  Nodes of an unreachable master are still available
•  All the network is still connected on loss of a master



Metadata for Nodes

•  Generate system wide and unique topic and service names
•  They may contain:
–  Name, location, function, owner and group of a node
–  Name, location, function and group for each topic and service



Transformation service

•  Metadata is loaded as XML by roslaunch as a parameter
–  Can also be YAML
•  System node provides a transformation service
–  No change to the client libraries needed
–  Transformation is encapsulated, implementation resides in a single place
–  Returns the namespace of specific topic/service
–  Remap commands in launch-files will still work for incoming topics

•  Use XSLT processor to apply an XSLT style sheet
–  XSLT gets loaded at the node start-up
–  XSLT must be the same for the whole system

•  ROS-wide naming service, also usable for additional features for ROS



Routing between sync nodes

•  Replaces the fully meshed network with a routed network
–  Total bandwidth usage gets reduced
–  Makes the system more brittle

•  Building routes between different networks:
–  Discovery of other sync nodes might fail in routed networks
–  Master and Sync-Node need to communicate to connect two networks
–  No more problems to reach each other



Routing for topics and services

•  Local sync nodes registers itself with the local master
•  Local nodes contact their sync node, which forwards the request through the
routed network to remote sync nodes
•  Remote sync node subscribes to the topic/calls the service



Security Implementation

•  Provide data integrity trough checksums and pre-shared secrets (e.g. per
node or service)
•  Encrypt connections by certificates

•  Missing failure tests for the ROS communication stack:
–  DoS Attacks
–  Code injections
–  Manipulation of connections (overriding parameters)

•  Security concept for ROS



Thank you for your attention!
Questions?

?
?
roalter@tum.de
www.vmi.ei.tum.de/team/luis-roalter.html



Paper Reference

•  Please find the associated paper at:
https://vmi.lmt.ei.tum.de/publications/2011/IE11_preprint.pdf

•  Please cite this work as follows:
•  Luis Roalter, Andreas Möller, Stefan Diewald, Matthias Kranz. 2012.
Developing Intelligent Environments: A Development Tool Chain for Creation,
Testing and Simulation of Smart and Intelligent Environments
In: Proceedings of the 7th International Conference on Intelligent
Environments (IE2011), pp. 214-221, Nottingham, UK, July 2011



If you use BibTex, please use the following entry
to cite this work:

@INPROCEEDINGS{ie2011,
author = {Roalter, Luis and M{"o}ller, Andreas and Diewald, Stefan and Kranz, Matthias},
title = {{Developing Intelligent Environments: A Development Tool Chain for Creation,
Testing and Simulation of Smart and Intelligent Environments}},
booktitle = {Proceedings of the 7th International Conference on Intelligent Environments (IE)},
year = {2011},
pages = {214--221},
month = {july},
doi = {10.1109/IE.2011.43},
isbn = {978-0-7695-4452-6},
keywords = {Android, Development, Development Process, Intelligent Environments,
Middleware, Mobile Devices, ROS, Smart Spaces},
numpages = {8}
}


Distributed Networks within ROS: Challenges and Possibilities

Recommended

Recommended

More Related Content

What's hot

What's hot (13)

Similar to Distributed Networks within ROS: Challenges and Possibilities

Similar to Distributed Networks within ROS: Challenges and Possibilities (20)

More from Distributed Multimodal Information Processing Group

More from Distributed Multimodal Information Processing Group (15)

Recently uploaded

Recently uploaded (20)

Distributed Networks within ROS: Challenges and Possibilities