ROS2 Version

[JWhitleyWork]

Are the maintainers of this repo interested in releasing a ROS2 version of this package? If not, would you be interested in contributing to the udp_driver package in https://github.com/ros-drivers/transport_drivers? It seems like these serve similar purposes but for different ROS releases.

[github-actions]

Thankyou for creating your first issue for the udp_com ROS package! Our team will review your issue soon and see what we can do to help.' first issue

[flynneva]

hey @JWhitleyWork, yes we do actually already have a udp_com ROS2 version of this code on our internal github.

we were planning on releasing the ROS2 version of this package on a branch within this repo quite soon (next two weeks).

I actually was checking out the transport drivers repo earlier this week - i didnt realize ROS had this package to be honest. when we started developing this ROS package interally over three years ago now we didnt see anything that would work for us.

I'd definitely be interested in collaborating if at all possible - especially if the packages do similar things.

[JWhitleyWork]

@flynneva transport_drivers was an offshot of the Autoware.AUTO project for which I am the Software Architect. @esteve wrote most of transport_drivers. The major feature that is currently missing is being able to send data via UDP - receiving is already implemented. The repo is farily new and is only available for ROS2 which may have been why you didn't see it before.

The major feature that is currently missing from udp_driver is the ability to send out UDP data - receiving is fully implemented. Additionally, we are removing the LifecycleNode functionality from it because it isn't really fully implemented. We also use boost/asio so it shouldn't be too difficult to merge the code.

We would be greatful for any contributions you could make to the project. We hope to provide low-level interfaces for as many communication protocols as possible (TCP, UDP, TTL/Serial, etc.) but we're currently busy with the rest of the Autoware.AUTO project.

[flynneva]

i like the idea of creating generic "transport_drivers" and a central place within ROS/ROS2 to store them. it would make logical sense for this location to be in the ros-drivers/transport_drivers repo.

just doing a quick once-over of the code i noticed that you still have the udp_driver namespace within the autoware and drivers namespaces. is there any plan to remove this? or is this required to keep in there due to legacy of some other code somewhere else?

from an architecture perspective I really liked our approach with udp_com - ROS services to create a socket and also to send data. this provides a ton of flexibility for end users and really makes the udp_com package generic. i dont see any use of ROS services in your code - is this the type of thing you would like to add to the udp_driver package?

[JWhitleyWork]

@flynneva Autoware.AUTO was the origin of the code. We can remove it but we'd need to coordinate the changes between that repo and Autoware.AUTO.

Regarding the implementation, I'm fine with having a Composable node implementation of a stand-alone UDP node. I think this does add flexibility and functionality for members. However, I want to keep the existing library-only option for users who don't want to add the overhead of the stand-alone node and also the additional ROS traffic. If you would like to implement this in udp_driver (and maybe serial_driver too?), it would be much appreciated. However, if you are unable to do the development, I can put it on my list (but no timeline promises).

[flynneva]

unfortunately from my side ive been asked to keep focused on getting the ROS/ROS2 releases done for our udp_com and hfl_driver packages first.

once these are steady-state and the release/CI pipeline is up and running I might get pulled into other things - but I also might end up having a little bit more time to support you over on the transport drivers.

lets keep in touch and go from there....im sure something will cause a convergence between the udp_com and udp_driver packages eventually.