Perception Pipelines
SIG Coordinator: TBD
Mailing list:
Old Mailing List
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
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).
