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
|
|
|
# A ROS2 RMW implementation for Eclipse Cyclone DDS
|
2018-07-09 13:22:25 +02:00
|
|
|
|
2019-08-13 18:13:59 +02:00
|
|
|
With the code in this repository, it is possible to use [*ROS2*](https://index.ros.org/doc/ros2)
|
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
|
|
|
with [*Eclipse Cyclone DDS*](https://github.com/eclipse-cyclonedds/cyclonedds) as the underlying DDS
|
|
|
|
|
implementation.
|
|
|
|
|
|
2019-08-13 18:13:59 +02:00
|
|
|
## Getting, building and using it
|
2019-09-19 11:56:26 +02:00
|
|
|
|
2019-09-13 04:54:06 -05:00
|
|
|
All it takes to get Cyclone DDS support into ROS2 is to clone this repository into the ROS2 workspace
|
|
|
|
|
source directory, and then run colcon build in the usual manner:
|
2019-08-13 18:13:59 +02:00
|
|
|
|
|
|
|
|
cd ros2_ws/src
|
2019-09-19 08:18:42 -07:00
|
|
|
git clone https://github.com/ros2/rmw_cyclonedds
|
2019-09-18 12:49:39 -05:00
|
|
|
git clone https://github.com/eclipse-cyclonedds/cyclonedds
|
2019-08-13 18:13:59 +02:00
|
|
|
cd ..
|
2019-09-13 04:54:06 -05:00
|
|
|
rosdep install --from src -i
|
2019-09-18 12:49:39 -05:00
|
|
|
colcon build
|
2019-08-13 18:13:59 +02:00
|
|
|
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
|
|
|
|
|
|
|
|
|
|
This seems to work fine on Linux with a binary ROS2 installation as well as when building ROS2 from
|
|
|
|
|
source. On macOS it has only been tested in a source build on a machine in an "unsupported"
|
|
|
|
|
configuration (macOS 10.14 with SIP enabled, instead of 10.12 with SIP disabled), and apart from a
|
|
|
|
|
few details that are caused by the machine configuration, that works fine, too. There is no reason
|
|
|
|
|
why it wouldn't work the same on Windows, but I haven't tried.
|
|
|
|
|
|
|
|
|
|
If you want to use a pre-existing installation of Cyclone DDS, you don't need to clone it, but you
|
2019-09-18 12:49:39 -05:00
|
|
|
may have to tell CMake where to look for it using the `CycloneDDS_DIR` variable. That also appears
|
2019-08-13 18:13:59 +02:00
|
|
|
to be the case if there are other packages in the ROS2 workspace that you would like to use Cyclone
|
|
|
|
|
DDS directly instead of via the ROS2 abstraction.
|
|
|
|
|
|
|
|
|
|
## Known limitations
|
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-03-05 21:08:26 +00:00
|
|
|
Cyclone DDS doesn't yet fully implement the Lifespan, Deadline and some of the Liveliness QoS modes.
|
|
|
|
|
Consequently these features of ROS2 are also not yet supported when using Cyclone DDS.
|