ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

ROS2 pcl_perceptions


While working with ros2, happen to find pcl_perceptions for one of the algorithms developed useful. But, this
supports only with ros1, is there any plans or already available version of the same which supports ros2 native?

@paulbovbel Could you help or guide?

1 Like

Porting is a non-trivial effort. Especially it depends on some ROS2 core features that have not been finalized/ported to ROS2 yet. Example: Replace dynamic_reconfigure and its .cfg files, porting filter plugins to components, etc…

Did anyone contact the maintainers asking about their plans? I guess most people are waiting for ROS2 to be more mature to minimize code rewrite/throw-away, especially huge stacks like perception.

@wjwwood Could you help or guide on this? I wrote an email to you, about the same. I’m ready to put in the effort, but need some initial ideas of for sanity.

+1, from

pcl_conversions is mainly about type masquerading, which isn’t targeted for a release yet.

pcl_ros is primarily input/ouput/pipeline nodes. For porting that, I’d really like to see how (dynamic) parameters and managed nodes shake out in the summer 2018 release.

1 Like

Costmap2D has a dependency on pcl_perceptions, and I don’t see this on the Crystal Roadmap yet. Does anyone have the bandwidth to port it to ROS2?

1 Like

I believe the navigation stack as a whole has dropped pcl_* as a dependency in melodic.

There is certainly interest in a port/refresh of pcl_* to ROS2, but bandwidth is low at the moment. The only thing outstanding from my excuses in February however is type masquerading, and we can probably agree that that isn’t critical for a port.

1 Like

I can confirm that the Melodic branch of navigation is PCL-free, but does depend on the sensor_msgs::PointCloudIterator – not sure the status of that being ported.


1 Like

There is a ROS 2 version of PointCloudIterator available at

1 Like

Yes I saw that melodic no longer has this dependency after I posted. Thanks for the replies!

@Paul_Bovbel, @wkentaro, our team at Persistent System is ready to put the effort in porting perception_pcl to ROS2. Please let us know if you will be interested to obtain our assistance in the porting effort.

It seems no body start on this task. Ref to ROS2 perception porting status. If you have resource on this tasks, I would suggest you announce on ROS 2 Collaboration Bulletin Board, and just start the work.

There is ROS2 pcl_conversion package ported on ROS2 before moving on perception_pcl. The pcl_conversions deprecated on ROS 1, if we port perception_pcl, we could switch to use perception_pcl instead of pcl_conversion on ROS2.

I don’t quite follow you here, but as far as I’m aware nothing related has been deprecated.

+1 to that. I would welcome any PRs for perception_pcl, and I’m happy to provide feedback, but my bandwidth to do actual work is fairly limited.

A few advance points - while a direct port of perception_pcl to ROS2 has value, what would be much more valuable is an overhaul of the perception_pcl ‘filter’ nodelets, taking the new ROS2 lifecycle concepts into account. That said, it would be great to have a design discussion prior to diving in.

It seems to me that questions are more around pcl_conversion deprecation. Having said that, we have already started working on perception_pcl porting effort.

@Paul_Bovbel, Do you want me to setup a call with you with our team who is working on perception_pcl? If so, let me know so that I can setup a call.

@yechun, @swatifulzele from our team has posted in “ROS 2 Collaboration Bulletin Board” for our intend to contribute on this porting effort.

@Paul_Bovbel, as we discussed on PCL_ROS over the email, we at Persistent System are currently evaluating dependencies as a part of our porting effort. As we are planning to have a separate call with you, we are hoping to get further insight and guidance from you on this effort.

For others, Please let us know if anyone else is working on PCL_ROS porting to ROS2? Our team at Persistent System has already started researching the porting requirements for PCL_ROS. Please let us know if anyone has any concern or like to share any vital information that we will help us in this porting effort.

Please refer thread “Dynamic Reconfigure porting” for further information on this effort.

I agree with @Paul_Bovbel, this could use a design discussion.

While the ‘filter’ nodelets work, chaining them can be problematic, particularly if a new point cloud arrives before the current one is finished being processed. Perhaps the ROS2 lifecycle could be used to start a new filter chain if, for example, the current cloud is taking longer than usual to ICP. Something similar to a worker/scheduler model.

It may also be worth looking at ecto.

In the long term I’d like to see a means of passing a point cloud to a GPU and having it to run a set of filter/operations on it. Perhaps something like shaders in OpenGL’s rendering pipeline or gstreamer’s approach to video processing.

Indeed one of the design elements for the executor based threading model in ROS2 is that we wanted to be able to support synchronous pipelines. To achieve that we’ll need to develop a custom executor that’s aware of the pipeline flow, but once that is configured it can synchronously call each element in the pipeline. This in combination with the unique pointer publishing API supporting zero copy intraprocess message passing should be quite powerful.

Hi Paul,

Hope you are doin good.
We were busy in migrating some other packages so post-poned work on pcl_ros.
Now we are again back on the pcl_ros work.
As you suggested, we are working on the design part of it which involves component and ros2 parameter features.
It would be appriciated if you help us to understand few of our doubts.

  1. In the process of piplelining, if any node crashes or breaks down,how is this handled in ros?
  2. Pipelining of filters is happening serially or parallely?
  3. I have observed that all the operations of pcl_ros are not getting tested with either gtest or launch. Please confirm.


Hi @poonam1120,

I believe ros2 launch should handle restarting a node if it crashes, however I can’t find an example of this in source or documentation (

A ‘port’ of ROS1 would involve instantiating several lifecycle nodes inside one process. See the ‘composition’ demos:

A more interesting implementation would have an executor aware of the pipeline structure (ROS2 pcl_perceptions), however I don’t think any implementation or demo of this exists in the wild.

Correct, this certainly would be valuable to fix in the context of a porting effort.

Thanks @Paul_Bovbel for your response.
All these questions were related to existing code of pcl_ros in ROS.
As per my analysis, nodelet/node monitoring is handled by bond package which is already added to nodelet.

I am working on design doc for pcl_ros migration to ros2. Also I am checking how these things will be handled in ros2. Once the document is in good shape, will share with you.