12. And now a DEMO
(PUBSUB)
[Note]
My terminal has run:
export RMW_IMPLEMENTATION=rmw_zenoh_cpp
And I am running the logger at the DEBUG level
--ros-args --log-level debug
13. PUBSUB STEPS
- Init RMW
- Create Node
- Automatically create support pubsub and
services
- Create Publisher
- Create Subscription
- Publish
- Wait
- Take Messages
- Destroy Pubsub, Services, and Nodes
- Shutdown
14. Note: (The pain of many layers of abstraction)
Calls trickle down from RCLCPP, to
RCL, then to RMW.
Making it quite hellish to properly
debug.
Fully implement the necessary RMW
functions first before trying.And try
to only debug on the RMW layer.
22. There’s a lot more, but what’s
been shown is sufficient for fully
working Pubsub and Services!
(Parameters should work in principle. But not tested yet.)
(Actions will take a bit more, and so will drawing the node graph, etc.)
23. What’s Left Unimplemented
(There were some implemented stuff that weren’t
necessary, and omitted for brevity)
(Some of the other unhighlighted sources also have
unimplemented, but unnecessary functions for now.)
28. Vendor Specific Implementations are
important…
Because they are what actually do the
work of data de/serialisation,
publishing and subscribing!
You must implement those in
whatever middleware you are using!
29. CODE WALKTHROUGH
PUBSUB FLOW
(and Wait)
PUBLISHER SUBSCRIPTION
- Create and Populate Publisher
- Create Zenoh publisher
- Publish Data on Zenoh
- Create and Populate Subscription
- Create Zenoh subscriber
- (Receive data via Zenoh callback)
- Take Data
34. The Motivation
Zenoh publishes char arrays
(char *)!
Something needs to turn ROS
messages with any number of
fields into this serialised byte
array
This is precisely what
typesupport does!
37. Note:
Using FastCDR was just a super fast way to get
everything up.The Zenoh typesupport package is a
slight modification of the package for FastRTPS
We might want to use a different (more modern)
serialisation routine in the future…
(It’s not trivial to use a new serialisation library,
because it means writing your own code
generation templates for your typesupport
library…)
38. The StaticTypesupportTL;DR:
If a typesupport package is sourced
when messages are built…
Typesupport code for each message
package will be generated!
40. The package XML is supposed to ensure the
package is built first…
But it doesn’t.
No idea why. (Probably because RMWs are
meant to be installed in the underlay…)
42. They get passed in on pub/sub creation
And in rmw_zenoh’s case, shoved into a custom
implemented TypeSupport class
This class is then used in
serialisation/deserialisation
61. WHY IS IT DIFFERENT FROM THE REST.
(The other request_headers were of type rmw_service_info_t)
PS: I got bamboozled by
this once
rmw_send_response()
