Update ROS 2 publisher sink to use NodeInterfaces#68
Conversation
…osed to splitting constructors to accept lifecycle vs node
…or to transfer Interface handles to Sink
… to allow for backwards compatability with previous datatamer versions
…er, adding ros2 pub sink tests
|
Also, I added new ROS2 Publisher Sink Tests in: |
…cutable from Conan block
|
@henrygerardmoore , sorry for the delay in getting this PR resolved, I think I fixed the broken Conan build with this change here: 5974247 When you have a moment, can you rerun the workflow, and let me know if that is fixed. Thanks again ! -Jacob |
|
@henrygerardmoore , looks like all the Checks are passing now, thanks for re-running! What are the next steps for merging? |
|
@coderjake91 let me just review when I get a chance (sorry for the delay 😅) and then it should be good to merge! |
|
@henrygerardmoore , thanks so much! No worries at all ! Please don't feel rushed. I really appreciate your time. Sounds good about review. |
|
@coderjake91 thanks for your patience! I changed a few very minor things and merged it |
Hello!
First off — thanks for creating DataTamer. It’s an awesome library.
I’ve been developing a ROS2 Jazzy system using a composition-based architecture with both lifecycle and regular nodes. We use DataTamer to collect time-series data and pipe it into Foxglove, and the ROS2 publisher sink makes that integration super smooth.
I ran into an issue when adding the ROS2 publisher sink inside composable nodes. In composition, node ownership changes — the executor owns the shared pointer and spins the nodes — so you often don’t have direct access to the node
shared_ptrin the same way as when running standalone nodes. This affects both lifecycle and regular nodes.I tried workarounds like
shared_from_this(), but those are fragile and can easily lead to invalid weak pointers.I noticed recent support for lifecycle nodes was added via additional constructor overloads, and this PR builds on that idea by updating
ROS2PublisherSinkto accept aNodeInterfacesfaçade instead of requiring ashared_ptr. Since this sink only needs the topics interface, this lets users pass either:NodeInterfacesobject directlyNode/LifecycleNodeshared_ptrto eitherwhile remaining fully backwards compatible.
I took my colleague @jlack1987’s advice (he’s been working with DataTamer for a while) and structured this to preserve all existing usage patterns.
Thanks again — happy to adjust anything if needed!