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.
Almost there! Known issues:
* mangling/demangling is still wrong
* it necessarily has to run in the Cyclone default domain id: (1)
Cyclone is today still limited to a single domain at a time; and (2)
there is the "extra" participant that pops up here and there for
creating guard conditions and waitsets without a node existing
* almost all query operations create a reader for a builtin topic and
throw it away afterward, that might be a little excessive (on the other
hand, those readers are pretty cheap, so using them as a throwaway
reader is not so bad).
Still missing:
* get_service_names_and_types
* get_service_names_and_types_by_node
I haven't been able to actually try everything yet, so bugs are probably
lurking here-and-there.
passes a decent subset of the tests ...
fixes:
* sequences of simple types: remove accidental alignment
* trigger graph guard on any built-in topic
* create a participant for each node, with node name/namespace in user data
It is still only a proof-of-concept, but it might now actually be usable ...
This commit adds stubs for the missing functions and fixes a few bugs in
the serialisation code and topic creation. With these changes, the
talker and listener demos of ROS2 Crystal Clemmys work.
The changes in this commit make it compile with ROS2 Crystal Clemmys and
current Cyclone DDS. The RMW interface of ROS2 was modified in some
ways and extended in some other ways since Bouncy Bolson; and similarly,
Cyclone now has a somewhat reasonable interface for custom sample
representations and serialization, but the code in this commit probably
contains mistakes in using it.
Therefore, the expectation should be that this doesn't actually work
just yet, though it probably is quite close. As the old state wouldn't
build at all with any version of Cyclone DDS except the early commits,
this is significant progress already.
