Closed YoshuaNava closed 2 years ago
PRs to implement capabilities you’re interested in are always appreciated.
As @SteveMacenski said. Also, Open3D seems to have an open pr for this https://github.com/intel-isl/Open3D/pull/2074, once it is done we can implement the necessary changes to interface to it
Since this pr is now merged, we can start with adding functions for tgeometry pointclouds. The current functions can remain the same since there don't seem to be any api changes to the legacy open3d pointcloud.
Hi, Thank you very much for making me aware of that new feature from Open3D, sorry of my original message was too direct. I wrote it in a rush, as I saw this new feature coming.
As soon as I find time I'll submit a PR.
Solved by #17
Thank you very much for writing this package and sharing it with the community.
I wanted to point out that the current implementation makes very strong assumptions on the fields of the input point clouds in format sensor_msgs/PointCloud2. While the ROS msgs is quite flexible and compatible with any type of point cloud data, the conversion and Open3D itself are not:
https://github.com/ros-perception/perception_open3d/blob/main/open3d_conversions/src/open3d_conversions.cpp#L81
This means that for example, you automatically discard curvature, reflectivity, ambient noise, and anything that goes beyond RGB or normals.
Would it be possible to implement both in this package and in the Open3D side a more flexible type? Libpointmatcher is a really good example, which is also light in memory (everything is represented as Eigen matrices), and intrinsically handles aspects like memory alignment.
Thank you in advance.