You're reading the documentation for a version of ROS 2 that has reached its EOL (end-of-life), and is no longer officially supported. If you want up-to-date information, please have a look at Humble.
Design guide: common patterns in ROS 2
Fast RTPS large data transfer
Context
You want to transfer large data via Fast RTPS.
Problem
DDS/RTPS uses UDP with a maximum message size of 64k
Solution
Configure the middleware so that it fragments large data into messages
Implementation
Use Asynchronous publication mode:
<publishMode>
<kind>ASYNCHRONOUS</kind>
</publishMode>
Fast RTPS Best Effort Video Streaming
Context
You want to transfer video streams and provide up-to-date data. It is OK to lose some of the images.
Problem
Acknowledged data transmission mechanisms (also known as “reliable” delivery) ensure every packet is delivered, which can cause the video stream to fall behind.
Solution
Use “best effort” communication (instead of the usual acknowledgement based mechanism) and prioritize the last frame.
Implementation
Configure “best effort” reliability mechanism
Configure Quality of service history to keep last frame
<reliability>
<kind>BEST_EFFORT</kind>
</reliability>
<historyQos>
<kind>KEEP_LAST</kind>
<depth>1</depth>
</historyQos>
Fast RTPS Reliable Video Streaming
Context
You want to transfer video streams in unreliable network settings.
Solution
Use a reliable communication mechanism. Use fast response by writer and reader.
Implementation
Configure “reliable” reliability mechanism
Configure NACK response delay and suppression duration of writer to 0
Configure heartbeat response delay of reader to 0
<reliability>
<kind>RELIABLE</kind>
</reliability>
# writer
<times>
<nackResponseDelay>
<durationbyname>ZERO</durationbyname>
</nackResponseDelay>
<nackSupressionDuration>
<durationbyname>ZERO</durationbyname>
</nackSupressionDuration>
</times>
# reader
<times>
<heartbeatResponseDelay>
<durationbyname>ZERO</durationbyname>
</heartbeatResponseDelay>
</times>