44

Next-Gen Autonomous System Design Made Easier With DDS and ROS

 5 years ago
source link: https://www.tuicool.com/articles/hit/Bnquqe6
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Key Takeaways

  • ROS (Robot Operating System) is an open-source framework for robotics research.
  • DDS (Data Distribution Service) is an open-standard connectivity framework for real-time systems, which enables distributed systems to operate securely as an integrated whole.
  • The newest version of ROS (ROS2) is based on DDS, enabling easy 3D visualization of distributed robotics systems.
  • Standard bodies in Automotive (AUTOSAR), Mil/Aero (FACE), and cross-industry (IIC) have adopted DDS for connectivity in next-gen / autonomous applications.
  • DDS implementations range from free/open-source, to commercially-supported with enhanced capabilities for performance, security and safety.

In early July of this year, Open Robotics announced the second official release of their next-gen Robotics platform,  ROS2 . Codenamed “Bouncy Bolson,” this release continues to enhance ROS2, highlighted by the inclusion of the “ RViz ” 3D visualizer.

For those unfamiliar, ROS (Robot Operating System) is an open-source software framework for developing robot software applications.  It started as an open-source project in 2007, and is a mainstay in robotics research because of its ease-of-use and open-source hackability. As a result, it has grown to include tools for 3D simulation and visualization, route planning, pose estimation and support for nearly every type of robotic arm, actuator, gripper, etc.

While the tools in ROS are impressive, the performance and scalability of ROS itself could not keep pace with the needs of next-gen robotics applications, such as autonomous vehicles, multi-robot swarms and operating in distributed environments. ROS was designed to control a single robot from a desktop Linux environment, but these new applications required real-time performance with safety-critical implications, and potentially to operate in a distributed environment with limited memory and unreliable networking. Open Robotics needed a next-gen redesign of ROS, using the best technology to improve these underlying limitations in the original ROS. That led them to adopt DDS as the connectivity framework for ROS2.

DDS (Data Distribution System) is an open-standard connectivity framework, supported by around a dozen commercial and open-source implementations. DDS creates a virtual ‘databus’ to efficiently connect the participants in a distributed system, handling the details of discovery, routing, security, reliability, etc., thereby freeing system developers to focus on their application software.   

Autonomous systems often require large amounts of data to be moved quickly, and must be held to a higher standard of safety and security. In addition to ROS2, DDS has been adopted by AUTOSAR for their  Adaptive Platform (designed for autonomous-drive vehicles), by the Future Airborne Capability Environment ( FACE) Consortium for military aircraft, and is identified as a Core Connectivity Standard by the  Industrial Internet Consortium (IIC). DDS is used in the world's largest and most demanding systems and applications

In this tutorial we will set up ROS2 on multiple computers with different operating systems (Linux, Windows, and Apple) to create a distributed robotics system that operates as an integrated whole.  Later, we’ll extend it beyond the boundaries of ROS to interoperate with a DDS-only system. To start, I followed the installation instructions from the ROS2 Wiki site .

Installation: Linux PC

This was the simplest of the three installations: add the ROS2 repository to my apt sources list, then do an apt update / apt install of the ROS2 packages. ROS2 was ready-to-go in a few minutes.

I made sure to install the additional RMW implementation for RTI Connext DDS . ROS2 is architected to use a “ROS Middleware Wrapper” (RMW) to give users a choice of DDS implementations.  The default RMW is for a subset implementation that uses the DDS wire protocol but does not include the capabilities of the DDS framework (this will become important later in the article). 

Installation: Windows PC

This was a bit more involved than the Linux installation; the original ROS had always been a Linux-only application, and Windows offers fewer conveniences for package installation. After a manual installation of Chocolatey (package manager), Python, OpenSSL, OpenCV and Visual Studio -- and the RTI Connext DDS Libraries -- I had ROS2 running on a Windows system.

Installation: Apple MacOS / OS X

Of the three installations, this required the most steps.

I’d started with a factory-new MacBook and needed to install Brew -- then fix some issues that Brew revealed. Once that was done, Brew was very convenient for installing the prerequisite components (Python, ASIO, OpenCV, OpenSSL, etc.), but it was a teeth-clenching manual process to disable the System Integrity Protection (reboot into Recovery OS mode, edit a text file, reboot again). Once that was complete, I could install ROS2 by downloading and extracting a .tar archive (very old-school), and from there I could install the RTI Connext DDS Libraries to get a complete DDS implementation under ROS2.

Results

Under normal conditions, it can be difficult to get computers running the same operating system to talk to each other.  This test is looking to get computers running a mixture of different operating systems working together, which often takes the skills of an IT department to accomplish.

I braced myself to solve problems…

It was almost anti-climatic how easily the “demo_nodes” talker/listener applications worked when I tried them in any combination of the three different systems. Multiple talkers, multiple listeners -- they interoperated as if they were all part of the same computer.

1ros2-dds-communication-2-1540242933212.pngTalker and listener on the same PC

1ros2-dds-communication-3-1540242934505.pngAfter another talker (on a different PC) is added.

What Just Happened?

One of the brilliant things about DDS is that it implements a data-centric approach to system interoperability. DDS applications communicate with the data itself; not with messages and not with other applications. It’s a very powerful way to decouple the components of a distributed system. In this instance, the talker/listener applications were communicating using a data topic named “chatter”:

1ros2-dds-communication-4-1540242935071.jpg

This image was captured from the RTI Admin Console, a diagnostic utility for visualizing and troubleshooting DDS system connectivity.  The data-centric approach of DDS allows talkers (publishers) and listeners (subscribers) to be added to or removed from the system as needed, without any special consideration in the application code.

DDS also supports the use of ‘keys’ (designating a specific element as a unique identifier for the topic) in the topic data, allowing multiple publishers to share the same topic.  Subscribers can accept data from specific keyed topics, or all keys.

Let’s do something a little more interesting than “Hello World”…

3D Visualization

Some of the most valuable parts of ROS are its 3D visualization tools (RViz and Gazebo) and their support of a wide range of data types: Image, LiDAR, navigation, position, etc.   A great use-case would be to use these tools for general-purpose 3D visualization of application data outside of ROS.

Let’s try this out using a 3D-appropriate data type: the LiDAR point cloud.

The ROS “PointCloud2” data type gives me just what I need: control over the size, colouring, and quantity of data points to represent in 3-dimensional (x, y, z) space.

Here’s what’s contained in the PointCloud2 data type:

Header		 header,	 	 // ID and timestamp
	uint32		 height,		// count of rows in data
	uint32		 width,		   // count of columns in data
	PointField[]	 fields,		// type, offset, count of points
	bool		 is_bigendian,	// endianness of data
	uint32		 point_step,	// bytes per point
	uint32		 row_step,  	// bytes per row
	uint8[]	 data,		       // byte array of (x,y,z) point data
	bool		 is_dense		// complete or partial data set

I’ll make a publisher of this 3D data type, and to make it visually interesting I’ll use an outside source of coordinate data: the DDS Shapes Demo.   The ‘Shapes Demo’ is a 2D graphical program used for interoperability testing between different DDS vendors; squares/ circles/triangles bouncing around in a 2D space, it will make for a nice visualization in the 3D point cloud space.

Better yet, let’s combine the data from multiple instances of Shapes Demo into a single 3D space. This kind of “Sensor Fusion” is used extensively in autonomous vehicle systems to provide a more complete picture of the surrounding environment.

Here’s a system diagram of this test (below) -- note the addition of an Android device, which is also running the RTI Shapes Demo:

1ros2-dds-communication-5-1540242934232.jpg

The updated test system: 4 different operating systems running 4 instances of the Shapes Demo, providing 2D position data to a rendering application which publishes 3D point cloud data to several visualizer applications.  As an interesting side-note: the OSX and Android systems are connected over WiFi, while the Windows and Linux systems are using wired Ethernet.

Point Conversion and QoS

This Sensor Fusion application will subscribe to the 2D(x,y) ShapeType data produced by the multiple Shapes Demo applications running on 4 separate devices, and convert it to a 3D(x,y,z) PointCloud2 data type, with all 4 inputs combined into the same 3D space. For brevity, the 2D points were mapped directly to 3D space using the ‘shapesize’ variable of the input for the Z axis, and the Sensor Fusion application was limited to converting 2D circles to 3D spheres only.

Interoperation with the ROS tools required some adjustment to the DDS Quality of Service (QoS) and other settings, in summary:

  1. Prefix the data topic names with “rt/” .
    The topic name for the PointCloud2 data needed to be prefixed with “rt/” to let the ROS     tools know this is a “ROS Topic” -- for example:             “rt/lidar_points”.
  2. Use unbounded sequences and strings . Unbounded sequences and strings are used in ROS2. In this example, I used them for the LiDAR data array, this also enabled the number of data points to be freely adjusted at each sample publication.
  3. Suppress TypeCode information . DDS uses a discovery process that may include the exchange of data type information, but this type code exchange should be suppressed when working with ROS2 (Bouncy        Bolson).

With a compatible set of names and QoS policies in place -- the system, again, just worked, resulting in a distributed system running on four different platforms, all with different operating systems.

1ros2-dds-communication-6-1540242935354.jpg

What Just Happened?

This demonstration is running a pure-DDS system -- but is using ROS-compatible data type and QoS settings to allow interoperation with the ROS 3D visualization tools. This resulted in a system, with the performance and flexibility of DDS, being able to use the visualization and planning tools of ROS.

This system was running at modest sample rates -- 16 to 25Hz for the Shapes Demo applications, and 10Hz for the output of the Sensor Fusion application; DDS is capable of running many times faster and with much larger (>GB) sample sizes.

Summary

ROS2 was wisely designed to use DDS, resulting in a merger of their respective ecosystems. Autonomous system designers can truly have it all:

  • The visualization, simulation and planning tools of ROS.
  • The performance, security, scalability and resilience of DDS.
  • The layered services and tools of RTI DDS, including record/playback, web          integration, database integration and routing service that enables the  IIC-recommended  ‘layered databus architecture’ for large systems.

For next-gen robotics applications, this combination lets system developers quickly create large-scale systems - and have the ability to surgically connect, debug, and visualize each robot or participant individually.

Resources

About the Author

1Neil-Puthuff-1540242933959.jpg Neil Puthuff is a Technical Marketing Engineer for  Real Time Innovations (RTI) and a named inventor on 13 U.S. patents.

News update

On the 16th of October RTI released a new version of their Connext product suite: Connect 6. One major update to this version is optimizing their throughput and latency of large data samples. For developers of autonomous vehicles, this can provide major data savings for high-volume data such as LiDAR data. Their new version still integrates with ROS2 and AUTOSAR Adaptive.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK