[ros-users] point cloud questions

Radu Bogdan Rusu rusu at willowgarage.com
Fri Jul 30 01:09:20 UTC 2010


Hi Michael,

On 07/29/2010 05:55 PM, Michael Styer wrote:
> Hi Radu,
>
> Thanks a lot for the detailed response -- it was extraordinarily
> helpful. I have a couple of minor follow-up questions/comments, but
> you've basically answered all the questions I had (for today :) ).

Sure, glad I could help. :)

> On Thu, 2010-07-29 at 16:26 -0700, Radu Bogdan Rusu wrote:
>>> * a pcl::PointCloud object can be obtained from a PointCloud2 message
>>> using the point_cloud::fromMsg() function;
>>
>> this got changed in 0.2.x (small rename), but yes, the principle is the same. sensor_msgs::PointCloud2 ->
>> pcl::fromROSMsg () ->  pcl::PointCloud<T>
>
> Got it. I see the new function now; I found the old one in the
> point_cloud namespace and didn't look in pcl for another. I guess the
> point_cloud::fromMsg() function will be removed at some point?

Yes. The plan was to remove it before 0.2, but I had to keep it for another iteration until I fix all packages that 
depend on it.

>
>>> 2) What's the function of the height and width fields in the
>>> pcl::PointCloud<T>   class? In particular, in my node I want to create an
>>> output point cloud which is a subset of the points in the input point
>>> cloud; given the subset, what should the height and width of the output
>>> point cloud be? Do the height and width of the input point cloud refer
>>> to the geometric area enclosing the points, or to the size of the point
>>> cloud vector/matrix?
>> Good question. We should document this a little bit better (though it is documented in the format message itself). The
>> new sensor_msgs::PointCloud2 can represent organized datasets, while the older format (sensor_msgs::PointCloud)
>> couldn't. This means that now we can represent stereo 3D point cloud data, (or TOF, or even laser, etc), by specifying a
>> width and a height which corresponds to an image. What does this mean?
>>
>> - Say you have an RGB image organized as width x height, given by some sensor (i.e., stereo camera)
>> - Say you have a point cloud acquired using the same stereo camera, organized as width x height
>> - Now you have a perfect 1-1 correspondence between the RGB texture at each pixel and each point in the cloud! Hooray!
>
> OK -- I see the rationale for it now. So if I filter a pointcloud,
> removing some subset of the points, I've broken the organizational
> structure and I should probably set width=1 and height=points.size(),
> regardless of what the original width and height were.

Correct, except we decided to make the width = points.size (), and height = 1. :)

> It doesn't look like there's a structured accessor for organized point
> clouds, i.e. a way to index into the points array as a 2-d matrix rather
> than a vector -- is that right, or have I just missed it?

You're absolutely right, there isn't any, as we thought that index = v * cloud.width + u is easy (and vice versa). 
However, if you have any good idea on how to wrap this without causing confusion, we could do that!

>> (between you and me, we're working on a 2D to 3D feature estimation architecture as we speak - one that would allow you
>> to estimate any 2D feature and attach it to a 3D point in a PointCloud2).
>
> Sounds cool, look forward to seeing it.

You can already check intermittent commit messages into point_cloud_perception_experimental. Ideas are also welcome, 
though right now it's just a matter of time to get the implementation right.

>>> 3) For a given node that publishes a sensor_msgs::PointCloud2 topic, is
>>> there any way for another node to determine the type of the enclosed
>>> points? Or is that information only visible in the source?
>>
>> It is. That's the reason why we have "fields" inside the PointCloud2 topic. take a look at sensor_msgs::PointField.
>
> Aha. I see what you mean. So that at least tells you what the datatype
> and name of each field is. What I was really wondering, though, was
> whether there might be a way to figure out, for a given PointCloud2
> topic, what the class (such as PointXYZ) of the contained points is,
> e.g. through rostopic info or something similar. That would be
> convenient if someone wanted to write a node to subscribe to a topic
> published by a node from some other package. It doesn't seem like that
> exists now; maybe something for the roadmap.

That sounds interesting. We'll think about implementing something like that later, but we're not sure how it will work 
out until we get those publishers that I mentioned.

> In any case, thanks very much again for your help. PCL is significantly
> clearer to me now than it was this morning.

You're welcome! If you don't mind contributing with some of these things to the wiki (Q & A), that would be great!

Cheers,
Radu.
-- 
| Radu Bogdan Rusu | http://rbrusu.com/



More information about the ros-users mailing list