rmw_cyclonedds/README.md

72 lines
3.5 KiB
Markdown
Raw Permalink Normal View History

2020-04-01 04:45:16 -05:00
# ROS2 RMW for Eclipse Cyclone DDS
2018-07-09 13:22:25 +02:00
2020-04-01 04:45:16 -05:00
**Easy, fast, reliable, small [Eclipse Cyclone DDS](https://github.com/eclipse-cyclonedds/cyclonedds) middleware** for ROS2. Make your **🐢 run like a 🚀** [Eclipse Cyclone DDS has great adopters](https://iot.eclipse.org/adopters/) and contributors in the ROS community and is an [Eclipse Foundation](https://www.eclipse.org) open source project of [Eclipse IoT](https://iot.eclipse.org) and [OpenADx](https://openadx.eclipse.org) (autonomous driving).
Make various introspection features work This leaves as the big gaping holes: * Cyclone DDS does not allow creating a waitset or a guard condition outside a participant, and this forces the creation of an additional participant. It can be fixed in the RMW layer, or it can be dealt with in Cyclone DDS, but the trouble with the latter is that there are solid reasons for not allowing it, even if it is easy to support it today. (E.g., a remote procedure call interface ...) * Cyclone DDS does not currently support multiple domains simultaneously, and so this RMW implementation ignores the domain_id parameter in create_node, instead creating all nodes/participants (including the special participant mentioned above) in the default domain, which can be controlled via CYCLONEDDS_URI. * Deserialization only handles native format (it doesn't do any byte swapping). This is pure laziness, adding it is trivial. * Deserialization assumes the input is valid and will do terrible things if it isn't. Again, pure laziness, it's just adding some bounds checks and other validation code. * There are some "oddities" with the way service requests and replies are serialized and what it uses as a "GUID". (It actually uses an almost-certainly-unique 64-bit number, the Cyclone DDS instance id, instead of a real GUID.) I'm pretty sure the format is wildly different from that in other RMW implementations, and so services presumably will not function cross-implementation. * The name mangling seems to be compatibl-ish with the FastRTPS implementation and in some cases using the ros2 CLI for querying the system works cross-implementation, but not always. The one in this implementation is reverse-engineered, so trouble may be lurking somewhere. As a related point: the "no_demangle" option is currently ignored ... it causes a compiler warning.
2019-06-03 15:45:40 +02:00
2020-04-01 04:45:16 -05:00
This package lets [*ROS2*](https://index.ros.org/doc/ros2) use [*Eclipse Cyclone DDS*](https://github.com/eclipse-cyclonedds/cyclonedds) as the underlying DDS implementation.
Cyclone DDS is ready to use. It seeks to give the fastest, easiest, and most robust ROS2 experience. Let the Cyclone blow you away!
2020-04-01 04:45:16 -05:00
1. Install:
2020-04-16 19:10:29 -05:00
```
apt install ros-eloquent-rmw-cyclonedds-cpp
```
or
```
apt install ros-dashing-rmw-cyclonedds-cpp
```
2020-04-01 04:45:16 -05:00
2020-04-16 19:10:29 -05:00
2. Set env variable and run ROS2 apps as usual:
2020-04-01 04:45:16 -05:00
2020-04-16 19:10:29 -05:00
```export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp```
2020-04-01 04:45:16 -05:00
2020-04-16 19:10:29 -05:00
3. Confirm RMW: In Eloquent and later, to confirm which RMW you're using:
2020-04-01 04:45:16 -05:00
```ros2 doctor --report```
2020-04-16 19:10:29 -05:00
## Performance recommendations
With large samples (100s of kilobytes), excessive latency can be caused by running out of space in the OS-level receive buffer. For this reason, on Linux, we recommend increasing the buffer size:
* Temporarily (until reboot): `sudo sysctl -w net.core.rmem_max=8388608 net.core.rmem_default=8388608`
* Permanently: `echo "net.core.rmem_max=8388608\nnet.core.rmem_default=8388608\n" | sudo tee /etc/sysctl.d/60-cyclonedds.conf`
## Debugging
So Cyclone isn't playing nice or not giving you the performance you had hoped for? That's not good... Please [file an issue against this repository](https://github.com/ros2/rmw_cyclonedds/issues/new)!
The `ddsperf` tool distributed with Cyclone DDS can be used to check that communication works *without* ROS. Run `ddsperf sanity` on two different machines - if the "mean" value is above `100000us`, there are likely network issues.
If you're having trouble with nodes discovering others or can't use multicast *at all* on your network setup, you can circumvent discovery:
`export CYCLONEDDS_URI='<Discovery><Peers><Peer Address='myroshost.local' /><Peer Address='myroshost2.local' /></></>'`
Here are some ways to generate additional debugging info that can help identify the problem faster, and are helpful on an issue ticket:
* Configure Cyclone to create richer debugging output:
* To see the output live:
`export CYCLONEDDS_URI='<Tracing><Verbosity>trace</><Out>stderr</></>'`
* To send to `/var/log/`:
`export CYCLONEDDS_URI='<Tracing><Verbosity>trace</><Out>/var/log/cyclonedds.${CYCLONEDDS_PID}.log</></>'`
* Create a Wireshark capture:
`wireshark -k -w wireshark.pcap.gz`
2020-04-01 04:45:16 -05:00
## Building from source and contributing
Make various introspection features work This leaves as the big gaping holes: * Cyclone DDS does not allow creating a waitset or a guard condition outside a participant, and this forces the creation of an additional participant. It can be fixed in the RMW layer, or it can be dealt with in Cyclone DDS, but the trouble with the latter is that there are solid reasons for not allowing it, even if it is easy to support it today. (E.g., a remote procedure call interface ...) * Cyclone DDS does not currently support multiple domains simultaneously, and so this RMW implementation ignores the domain_id parameter in create_node, instead creating all nodes/participants (including the special participant mentioned above) in the default domain, which can be controlled via CYCLONEDDS_URI. * Deserialization only handles native format (it doesn't do any byte swapping). This is pure laziness, adding it is trivial. * Deserialization assumes the input is valid and will do terrible things if it isn't. Again, pure laziness, it's just adding some bounds checks and other validation code. * There are some "oddities" with the way service requests and replies are serialized and what it uses as a "GUID". (It actually uses an almost-certainly-unique 64-bit number, the Cyclone DDS instance id, instead of a real GUID.) I'm pretty sure the format is wildly different from that in other RMW implementations, and so services presumably will not function cross-implementation. * The name mangling seems to be compatibl-ish with the FastRTPS implementation and in some cases using the ros2 CLI for querying the system works cross-implementation, but not always. The one in this implementation is reverse-engineered, so trouble may be lurking somewhere. As a related point: the "no_demangle" option is currently ignored ... it causes a compiler warning.
2019-06-03 15:45:40 +02:00
The following branches are actively maintained:
* `master`, which targets the upcoming ROS version, [*Foxy*](https://index.ros.org/doc/ros2/Releases/Release-Foxy-Fitzroy/).
* `dashing-eloquent`, which maintains compatibility with ROS releases [*Dashing*](https://index.ros.org/doc/ros2/Releases/Release-Dashing-Diademata/) and [*Eloquent*](https://index.ros.org/doc/ros2/Releases/Release-Eloquent-Elusor/)
2020-04-01 04:45:16 -05:00
If building ROS2 from source ([ros2.repos](https://github.com/ros2/ros2/blob/master/ros2.repos)), you already have this package and Cyclone DDS:
cd /opt/ros/master
rosdep install --from src -i
colcon build
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp