If you have ever dealt with point cloud data either on ROS or with PCL, you might have noticed that there are two different data types; they are PointCloud and PointCloud2. While the naming could be seen as if it is implying PointCloud2 came out later so everyone should stop using the other one. Well, it’s not completely false, but it’s not very wise way of perceiving them.
About PointCloud
It is refered as sensor_msgs::PointCloud in ROS, and PointCloud with a point type in PCL. They are analogous to each other in that they are both in a form of an array(specifically, std::vector) of a point data. That is, a pointcloud is a list of points, and each points has x, y, z (+ possible optional components) values.
In ROS, as documented here, a position of a point is in geometry_msgs::Point32 type. Yes, it is a very ROS-oriented point cloud type that the developers probably endeavoured to comply ROS conventions. In case users need additional components other than xyz(i.e. normals), they could utilize the channel field. In PCL, users first need to define a type of point data, like PointXYZ where a point only has xyz values, PointNormal where a point has xyz and normals, etc. Once that’s done, they pretty much work in the same way.
About PointCloud2
I honestly didn’t see a need for another type of point cloud data since “a list of points” seems intuitive and reasonable enough to deal with at the first place. But apparently, PointCloud2 is more often visible on ROS online communities. There got to be a reason why.
PointCloud2 Documentation is informing about those compoenents that weren’t there in that of PointCloud. (i.e. row_step, data, etc). Essentially, it is composed of meta data that describe the structure of the data and the data, in short, the data and everything else. “data” is an array type, but it is NOT an array of point data type but of 8 bit integer, which would be equivalent to 1 byte char in size. So, data[3] does NOT mean the data of the point with index 3. One byte can’t even hold all that information! Does that mean we can’t access to point data by point indices? We still can do that, but we need some tricks to do it, like reconstructing floating number data out of multiple single-byte data. Seriously, it was so hard to understand why the newer type is harder to utilize. A simple illustration is as below: (please note the order is as defined in
Our demanded data are still there in “data” in orderly manner. Difference is, while we had our data in two-dimentional array in PointCloud(array of data in array of point type), they are all stored in one-dimentional “data” array of 1 byte int in PointCloud2.
Why would anyone use PointCLoud2
Knowing it is actually more intuitive to manipulate PointCloud data type, it might appear that PointCloud2 is useless. Truth is, enginners’ society would never attempt to shack a well-established convention without a strong need to do so, and YES, I do believe there got to be a reason to use PointCloud2. I am not an expert in Computer Science Field, so rather than jotting down my unexperienced guesses, I will refer to this keynote introduction slides presented by a Willow Garage Researcher. Unfortunately, the keynote slides doesn’t have so much detail on it. My interpretation on it is that keyword is Efficiency. I could, however, try to take a guess. If a PointCloud2 is to be tossed by shared pointers, it makes sense that users would want to keep the bulky data packed in a single array as it would be a lot more complicated to hand them over through TCP/IP if all data are scattered throughout the physical memory linked by some sort of linked lists or something. Maybe that’s why? I’ll keep it updated as soon as I figure more about it.