| ### Iceoryx Introspection Client ### 2020-06-10 15:37:39 |
| ### MemPool Status ### |
| Segment ID: 0
Shared memory segment writer group: chenying
Shared memory segment reader group: chenying |
| MemPool | Chunks In Use | Total | Min Free | Chunk Size | Payload Size |
| 1 | 1 | 250 | 246 | 800 | 736 |
| 2 | 1 | 10 | 8 | 24672 | 24608 |
| 3 | 1 | 10 | 8 | 41056 | 40992 |
| 4 | 1 | 10 | 8 | 1171552 | 1171488 |
| 5 | 1 | 10 | 8 | 1718496 | 1718432 |
| Segment ID: 1
Shared memory segment writer group: chenying
Shared memory segment reader group: chenying |
| MemPool | Chunks In Use | Total | Min Free | Chunk Size | Payload Size |
| 1 | 2 | 10000 | 9997 | 192 | 128 |
| 2 | 0 | 5000 | 5000 | 1088 | 1024 |
| 3 | 0 | 1000 | 1000 | 16448 | 16384 |
| 4 | 0 | 200 | 200 | 131136 | 131072 |
| 5 | 0 | 50 | 50 | 524352 | 524288 |
| 6 | 0 | 30 | 30 | 1048640 | 1048576 |
| 7 | 0 | 10 | 10 | 4194368 | 4194304 |
| ### Processes ### |
| PID: 29719 Process: /roudi
PID: 2132 Process: /2132_1591774610365270357
PID: 2198 Process: /2198_1591774612762464836
PID: 3578 Process: /introspection
### Connections ### | | | | | | |
# 7.2.4 Performance Test
ADLINK provides a benchmarking tool to test the performance of ROS 2 communication. The tool is based on the benchmark tool from Apex AI. Neuron SDK has several launch files which can load the settings and run all the processes of the benchmarking tools.
```batch
ros2 launch nsdk_benchmark_tools benchmark_cyclonedds.launch.py topic:=Array1k rate:=0
ros2 launch nsdk_benchmark_tools benchmark_cyclonedds_shmem.launch.py topic:=Array1k rate:=0
```
The commands below show how to test the performance of Cyclone DDS and Cyclone DDS with shared memory. benchmark\_cyclonedds.lauch.py is only for Cyclone DDS, while benchmark\_cyclonedds\_shmem.launch.py is for Cyclone DDS with shared memory. After performance testing is done, a log file is generated in csv format.
Change the topic and publish rate by adjusting the arguments. Some arguments supported include:
• topic: Topic name. Used this to change the data size. For example, Array1k, Array4k, Array16k, Array32k, Array60k, Array1m, Array2m, Array4m PointCloud512k, PointCloud1m, PointCloud2m, PointCloud4m, and PointCloud8m.
• rate: Publish rate. Default is 1000. 0 is unlimited.
• max\_runs: How many times the test runs.
# 7.2.5 Limitations
Although Cyclone DDS with shared memory is very powerful, there are some limitations.
• No multi-publisher support
Cyclone DDS with shared memory currently does not support multi-publisher mode, meaning you cannot have multiple publishers that publish to the same topic.
• No support for QoS in Cyclone DDS
Some QoSes need to utilize writer history cache (WHC) in DDS. When using shared memory, the data will go through shared memory directly and not enter into WHC. However, when using shared memory, the focus is often on large quantities and high rates of data. Under these conditions, QoS may not play an important role.
# 7.3 QoS
The latest version ROS 2 (Foxy Fitzroy) supports the following built-in QoS (Quality-of-Service):
• Reliability
• Durability
• History
• Lifespan
• Deadline .
• Liveliness
Although these built-in QoSes are able to fulfill most use cases in robotics applications, there are still around 20 QoSes in a typical DDS implementation. Therefore, as a contributor of Cyclone DDS, ADLINK allows Neuron SDK to support an additional QoS, Ownership (see section 7.3.2).
# 7.3.1 ROS 2 Built-in QoS
The ROS 2 built-in QoS allows developers to tune communication between nodes by adjusting QoS policies. ROS 2 benefits from the flexibility of the underlying DDS transport in environments with lossy wireless networks where a “best effort” policy would be more suitable, or in real-time applications which Quality of Service is needed to set deadlines.
# Introduction
ROS 2 provides a set of predefined QoS profiles for common use cases. The base QoS profile includes settings for the following policies.
# Reliability
The Reliability QoS indicates the level of guarantee offered by the DDS in delivering data to DataReaders. The reliability of a connection between a DataWriter and DataReader is entirely user configurable.
The figure below describes a system diagram of a wireless earthquake rescue robot. There are three tasks in the automaton: a robot controller, a life detector, and a camera. There is also a remote station used to control and monitor the robot. In this case, low latency communication between the camera and control command is needed to ensure the robot still working by receiving the new data. However, it is also important that the life detecting signal be extremely reliable so that no survivors are overlooked even when the wireless network is unstable.
WirelessEarthquakeRescueRobot
Possible variants include:
• Best Effort:
This variant indicates that it is acceptable to not retry propagation of any samples. This is the fastest and most efficient method of getting the last-published value, but there is no guarantee that the data sent will be received. For instance, camera image and control command should be set as Best Effort as it is especially suited for use cases where a robot is working in a dangerous situation, such as sending control commands for a drone or robot arm.
• Reliable:
This variant attempts to deliver all samples in its history. Missed samples may be retried. In steady-state the middleware guarantees that all samples in the DataWriter history will eventually be delivered to all DataReaders. Therefore, a life detecting signal should be set as Reliable. The Reliable delivery is particularly suited for rigorous use cases. For example, the video stream should be reliable during visual odometry calculation, because it may cause feature points to lose track if there are too many frames lost.
The figure above illustrates how Reliability works. Every time a packet is successfully sent to DataReader, it will feedback an acknowledgment to DataWriter. In contrast, when a packet fails to be sent to DataReader, it will feedback a negative acknowledgment to DataWriter to re-send the packet.