ROS2 Port

[LucidOne]

Is there a central place where we are tracking architectural issues for a ROS2 interface to PCL?

The big one I recall is handling pipelined pcl operations with nodelets. Zero copy is great until an old point cloud gets over written by a new one before you are done with it.

[paulbovbel]

Not really, as no one has declared they have time/inclination to make it happen. The way I see it, the two missing pieces required for a nominally useful ROS2 PCL pipeline are:

• type masquerading - serializing/deserializing between every pipeline step is unpleasant
• a way to compose and execute a pipeline from a bunch of managed nodes. I suspect most of the pieces are there (other than perhaps a pipeline-aware executor), but documentation is a bit sparse at the moment.

The big one I recall is handling pipelined pcl operations with nodelets. Zero copy is great until an old point cloud gets over written by a new one before you are done with it.

I imagine it's the middleware's job to handle object lifetime, and intraprocess comms in ROS2 works by more-or-less passing a dummy message with a memory address. So there's probably an internal mechanism that keeps the messages around until all const smart_pointers have expired.

---

EDIT, well not no-one, but no-one currently. https://discourse.ros.org/t/ros2-pcl-perceptions/3596/23

[LucidOne]

I'll jot down some of my other thoughts as I remember them here until there is a designated place to keep track of design notes.

I'd like to consider adding time delta information to ordered point clouds so the temporal dewarping code doesn't need to be reimplemented for each lidar. My recollection is that the rotation speed of a spinning lidar was slightly susceptible to power supply fluctuations but the PLL did a fairly good job besides that. This may be more or less of an issue in the future with solid state lidars.

I think there are some potential algorithmic benefits to to considering the projective origin of a pointcloud. Along this line of thinking, it may be worth evaluating non-cartesian error modeling as many of the current lidar designs have anisotropic error. As I understand it, a Velodyne HDL-32 for example has a maximum measurement error along the beam path, fixed angular offset error between the set of diodes epoxied to the PCB, minimal gyro wobble and minimal encoder error around the axis of rotation. Projective origin information can also allow diagnostics to detect hardware failures, an encoder failure in a rotating lidar might be detected by a change in the bin counts of an angular histogram from the projective origin..

Some of my conversations with lidar manufacturers seem to indicate that solid state lidar are capable of beam steering so it may be worth considering what might be needed to support a variable angular resolution.

Depending on how things like temporal dewarping are handled it may be worth generating accurate test data before working on implementation. Has anyone already generated a dataset with a Velodyne mounted on an industrial robot arm and having it move the lidar through a calibration trajectory with large planes (walls) in the background? Having "ground truth" data from the arm encoders may be helpful for validation.

[LucidOne]

It may be a little speculative but in terms of serialization, it may be worth looking at how multiple operations can be offloaded to a GPU/FPGA. I'm thinking something like OpenGL shaders or OpenVX to avoid serializing and deserializing between each hardware accelerated operation. Can this be done by type masqing a cloud in GPU/FPGA/ASIC?

[paulbovbel]

Just to avoid scaring anyone considering taking this on, I can't help but think that while those projects are worthwhile to consider taking on in PCL proper, they're probably out of scope for a ROS2 migration of pcl_ros.

[LucidOne]

I agree that some of this is outside of a minimum viable port for ROS2, however some of these items will require changes from hardware drivers generating PointClouds across to PCL itself, but I figured this was about the midpoint.

[klintan]

I started this (lets hope I didn't bite off more than I can chew) as it is a dependency in the velodyne device driver library, and I'm trying to get that to ROS2.

Could you create a crystal-devel branch? that way I can start a draft PR for you guys to follow and give feedback as I progress.

Regardless of the end results, it might at least serve as inspiration for future efforts.

[LucidOne]

done

[abylikhsanov]

Any update on this?

[klintan]

Any update on this?

A lot in the package requires type masquerading which is yet to be supported in ROS2, and it will probably take some time before it's ready. I put my PR for ROS2 on hold. I'll see if I take it up again. Feel free to check out my fork and continue if you feel like it, all additions are welcome.

[blacksoul000]

any news?

[paulbovbel]

perception_pcl has been ported to ROS2, https://github.com/ros-perception/perception_pcl/tree/foxy-devel

[SteveMacenski]

@paulbovbel I don't think that's true https://github.com/ros-perception/perception_pcl/tree/foxy-devel/pcl_ros pcl_ros has a big ol' COLCON_IGNORE in the root. I don't think its been ported at all yet

[paulbovbel]

oh wow, i'm just completely misinformed, thanks!

[SteveMacenski]

https://github.com/ros-perception/perception_pcl/pull/285

ROS1 ticket that should be added to ROS2 once ported

[mitsudome-r]

Are there any updates about the foxy porting? It looks like nodelets and filters are not ported yet, but transform library has been ported. I think it would be valuable for many users if it is released as binary package with current status.

[SteveMacenski]

No users have shown interest in porting parts of it yet. If you’d like to, I’d be more than happy to review PRs

[joe28965]

Does pcl_conversions work in ROS 2 Foxy? I have tried using it, but I can't get pcl_conversions::toPCL working. It keeps giving a no instance of overloaded function "pcl_conversions::toPCL" matches the argument list error. I was looking at the code, but void toPCL(const sensor_msgs::msg::PointCloud2 &pc2, pcl::PCLPointCloud2 &pcl_pc2) is the function which I would need, however I can't get it to work. Does anybody have any experience?

[SteveMacenski]

Does pcl_conversions work in ROS 2 Foxy?

Yes, it should

[joe28965]

do you know of any examples, or anybody who has used it?

[ShepelIlya]

Is there any new information about pcl_ros port?

[zmk5]

@SteveMacenski and @theseankelly is there any way I can assist in porting this over to ROS 2?

[SteveMacenski]

I think the big thing is someone that needs it to take it on to port it. Another reason this has been waiting around is that type masquerading still isn't implemented in ROS2 so the use of pcl nodelets in a chain to make a processing pipeline is going to be really inefficient right now since each time you'll have to convert from the sensor_msgs to pcl back to sensor_msgs rather than being able to publish the pcl type across them all until complete.

I think that's a major reason no real work has gone into it yet.

[zmk5]

Ok cool. I'll look into this and see what I can do.

[cardboardcode]

do you know of any examples, or anybody who has used it?

@joe28965 I can verify that , at the very least, pcl_conversions, is working on ROS2 Foxy.

@joe28965 Apologies. My phrasing made it look like I am asking a question.

[joe28965]

@cardboardcode Yes I can, for me, this works:

void cloud_cb(const sensor_msgs::msg::PointCloud2::SharedPtr msg)
{
    pcl::PointCloud<pcl::PointXYZ>::Ptr cloud(new pcl::PointCloud<pcl::PointXYZ>);
    pcl::fromROSMsg<pcl::PointXYZ>(*msg, *cloud);

    ...

    pcl::PointCloud<pcl::PointXYZ> final;
    sensor_msgs::msg::PointCloud2 output;
    pcl::toROSMsg<pcl::PointXYZ>(final, output);

Hope it helps

[zmk5]

Hey @SteveMacenski, I've been attempting a port of pcl_ros and I'm curious if I'm heading in a good direction for the group before I continue with the other libraries. My work so far is here. To prevent ruining the original library, I created a different package called pcl_ros2 until most of the port is complete. I'm attempting to make each library into a components instead of individual nodelets. I'm running into issues with filter being virtual, but other than that I have moved the functionality to ROS 2.

[paulerikf]

Just to clarify, is pcl_ros ported now? I don't see any COLCON_IGNOREs anywhere, but also having trouble building it.

[vincentrou]

One library pcl_ros_tf has been ported by @theseankelly . Have a look at the commented CMakeLists : https://github.com/ros-perception/perception_pcl/blob/ros2/pcl_ros/CMakeLists.txt @zmk5 You can make a PR with your port so it can be reviewed ? There is also a closed PR on this here : https://github.com/ros-perception/perception_pcl/pull/255

[MannavaVivek]

Is the port for pcl_ros complete? Because, while I am able to build the pcl_ros package, the point_cloud.hpp file still has code from ROS1 which gives me trouble when I attempt to migrate other functionalities built on top of it.

[PeterMitrano]

Not sure if this is the place to put this, but bag_to_pcd and other tools don't seem to be ported. Just wanted to :+1: that

[bryangd34]

Is the port for pcl_ros complete? Because, while I am able to build the pcl_ros package, the point_cloud.hpp file still has code from ROS1 which gives me trouble when I attempt to migrate other functionalities built on top of it.

I too am trying to #include "pcl_ros/point_cloud.hpp"but it does not seem to be ported yet to ROS2. Is there possibly a work-around that someone could suggest please?