Otherwise each writer/reader gets its own, and at approximately 1kB
each, with hundreds of endpoints that starts adding up to a meaningful
amount of memory.
Signed-off-by: Erik Boasson <eb@ilities.com>
The built-in topics readers in the RMW node are currently not used for
anything other than triggering the guard condition. All the query
functions just get their own data set from Cyclone. Taking all samples
instead of just the not-alive ones reduces memory usage.
Signed-off-by: Erik Boasson <eb@ilities.com>
struct ddsi_sertopic will shortly change a little bit by the removal of
two members that should never have been in it in the first place and
that had to be initialized to 0. Relying on memset makes the source
code independent of this difference.
Signed-off-by: Erik Boasson <eb@ilities.com>
Misuse of std::vector resize as if it would leave any reserved entries
unchanged caused a misinterpretation of entries whenever the number of
triggering entities was larger than the number of triggering entities in
the preceding call to rmw_wait: these would all be mapped to the first
entity in the set.
If the waitset is reused from call to call and spurious events are
handled gracefully, this is recoverable; otherwise, no such luck.
Moreover, not accounting for a sentinel entry added to the list of
triggered entities means it would never return RMW_RET_TIMEOUT.
Signed-off-by: Erik Boasson <eb@ilities.com>
The graph guard condition is triggered whenever the underlying DDS
topology changes using a listener set on readers for the DDS built-in
topics. The graph guard condition was destroyed before ensuring the listeners
would no longer be invoked, and this would lead to trying to trigger the
graph guard condition after it had been destroyed.
With this commit, the built-in readers are deleted explicitly before
destroying the graph guard condition.
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.
