Perception Pipelines

SIG Coordinator: TBD

Mailing list:

• https://groups.google.com/group/ros-sig-perpip

Old Mailing List

• Archives

Topics: image_pipeline, ROS integration with OpenCV (cv_bridge) and PCL (pcl_ros), image_transport, prototyping with Ecto

Members:

• Jack O'Quin
• Mac Mason
• Chad Rockey
• Vincent Rabaud
• Bhaskara Marthi
• Stéphane Magnenat
• add your name here

PCL packaging

Owner:

Background

Currently there doesn't exist an ideal way to publish point cloud data from 3d sensor drivers. For max efficiency with nodelets using PCL, it's best to publish as the PCL-native pcl::PointCloud<T> type, but that requires pulling in all of PCL. sensor_msgs/PointCloud2 is the low-dependency option, but is harder to use and requires a costly conversion for use with PCL.

Solution: allow drivers to depend on a minimal core of PCL, containing little more than the point cloud type and ROS glue.

Fuerte took us a big step forward, but there was not enough time to break up the PCL library dependencies into smaller components than all of libpcl.

PCL 2.0 will bring new integration challenges. Is that in scope for Groovy?

Goals

• perception_pcl that only depends on pcl_common

  • pcl depends on pcl_common, none of the other libraries

  • pcl_ros depends on pcl_bridge, builds the PCL nodelets etc.

Ecto

http://ecto.willowgarage.com/ is meant to provide a better replacement to nodelets. It is considered done and well documented and is actively used in different perception pipelines.

Ecto already provides several cells to subscribe/publish ROS messages and convert to the standard types (cv::Mat, pcd ...). It also provides an interface to the OpenNI drivers. Cells can be linked in C++ or a Python script and wrapped in a node and launched with the usual roslaunch.

image_transport

We could add a depth image compression format to transmit organized point clouds more efficiently. That would require to also send the calibration matrix and compute the point cloud when receiving the point cloud.

We could compress using lossless (PNG, JPEG2000) or lossy that makes sense (the only one that does to me is GIF, as it is binning the depths; JPEG obviously does not make sense as it is based on perception).