Distributed Networks within ROS: Challenges and Possibilities

transcript

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

Distributed Networks within ROS:

Challenges and possibilities

Luis Roalter

Technische Universität München, Germany

20.09.2012 Luis Roalter 2

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

Starting PhD thesis Technische Universität München

Research Topics:

•  Intelligent Systems, esp. for home-automation

•  Systems for homecare

•  Wireless Sensor Systems and Smartphones

•  Human-Computer Interfaces

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?

? ? 20.09.2012 Luis Roalter 21

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} }