You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I understand that there are significant computational and storage efficiencies associated with the built-in pcl datatypes (e.g., pcl::PointCloudpcl::PointXYZRGBNormal), I find these datatypes very limiting. I am a ROS user, and I frequently find myself wishing RTABMAP would simply store the full original PointCloud2 object in the database. As a result, I have been working on a modified version of RTABMAP that adds three new database entries, pc2_info, pc2_fields, and pc2_data. These entries are simply a breakdown of a PCLPointCloud2 objects into blobs that can be stored in a sql database. I am close to having a usable product and would love the official RTABMAP team's advice and feedback moving forward. My hope is that this approach will provide a lot of flexibility for data storage. It many cases, I believe it will provide a very straight forward path for capturing user generated data.
I am currently creating the scan and scan_info blobs consistent with the main branch and simultaneously populating the pc2_info, pc2_fields, and pc2_data blobs with the full original PCLPointCloud2 object. While this means that basic pointcloud information is stored twice right now, I believe the efficiency of pcl::PointCloud objects for common operations justifies keeping the scan/scan_info blobs, and I wasn't ready to couple the scan and pc2 database entries in a way that would allow the pc2 data to exist without the x, y, z fields. Hopefully, it is something that can be improved in the future.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
While I understand that there are significant computational and storage efficiencies associated with the built-in pcl datatypes (e.g., pcl::PointCloudpcl::PointXYZRGBNormal), I find these datatypes very limiting. I am a ROS user, and I frequently find myself wishing RTABMAP would simply store the full original PointCloud2 object in the database. As a result, I have been working on a modified version of RTABMAP that adds three new database entries, pc2_info, pc2_fields, and pc2_data. These entries are simply a breakdown of a PCLPointCloud2 objects into blobs that can be stored in a sql database. I am close to having a usable product and would love the official RTABMAP team's advice and feedback moving forward. My hope is that this approach will provide a lot of flexibility for data storage. It many cases, I believe it will provide a very straight forward path for capturing user generated data.
https://github.com/Nosille/rtabmap/tree/AddPc2ToDatabase
https://github.com/Nosille/rtabmap_ros/tree/AddPc2ToDatabase
I am currently creating the scan and scan_info blobs consistent with the main branch and simultaneously populating the pc2_info, pc2_fields, and pc2_data blobs with the full original PCLPointCloud2 object. While this means that basic pointcloud information is stored twice right now, I believe the efficiency of pcl::PointCloud objects for common operations justifies keeping the scan/scan_info blobs, and I wasn't ready to couple the scan and pc2 database entries in a way that would allow the pc2 data to exist without the x, y, z fields. Hopefully, it is something that can be improved in the future.
Beta Was this translation helpful? Give feedback.
All reactions