ROS2 type masquerading status and alternatives?

Hey!
I’ve taken on the challenge of porting both the “velodyne” driver package and “perception_pcl” from ROS -> ROS2 and as discussed here https://github.com/ros-perception/perception_pcl/issues/225 and here https://github.com/ros-drivers/velodyne/issues/165 type masquerading is one of the big missing pieces to at least more easily port it to ROS2. Discussions ongoing here as well ROS2 perception porting status

The ROS2 road map (https://index.ros.org/doc/ros2/Roadmap/#id4) also mentions this to be quite a major undertaking. So I have 2 question in relation to this:

  1. Is there any timeline for this, or has anyone started the work on this? Do you have any expected time frame, 1 - 6 months as when this might be available as an alpha implementation ?

  2. What would a viable alternative be ? Trying to do something similar to what is shown here https://github.com/ros2/demos/tree/release-alpha8/intra_process_demo/src/two_node_pipeline passing pointers. The other thing I was thinking about was to implement most of the PCL types as PCL-messages in the “pcl_msgs” package.
    Maybe you have some other/better idea on how to solve this?

Many thanks,
Best regards/Andreas

No, and not yet.

It really depends on when someone has resources (time and/or funding) to work on it. I think it’s a super important feature, but there are a lot of other things that need to be worked on as well. I thought I’d get it implemented for Dashing but then priorities changed and it got dropped. I expect it will take 4-6 months (real-time not necessarily person hours) to implement once we start working on it, but we’re not working on it right now.

You can always convert back and forth to a the ROS point cloud and then intra-process communication will just work, but doing so without converting (just sticking with PCL types) is not going to work right now (at least not without something hacky). There are a lot of workarounds you could do, but none of them will be future proof or really clean right now.

@klintan tangentially to your question - you probably have not seen our port https://gitlab.com/AutowareAuto/AutowareAuto/tree/master/src/drivers/velodyne_node? We will be upstreaming this to https://github.com/ros-drivers/velodyne in the next couple of weeks.

While doing the port we also took the chance and substantially changed the driver design which we then also described in this blog post: https://www.apex.ai/post/porting-algorithms-from-ros-1-to-ros-2.

One of our engineers spent significant time prototyping an optimal type conversion solution. I’ll let him comment on it.

1 Like

Thank you for your answer. I’ve had a brief look but not in depth. The blog looks great, and I will take a deeper look into your velodyne node implementation as well.