Segmentation using an (unchanging) subset of points

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Segmentation using an (unchanging) subset of points

Patrick Bouffard
I would like to use the SACSegmentation PCLNodelet with an indices
input to only segment a subset of the points in the cloud being input.
It looks like this is supported in general but that the expectation is
that each PointCloud2 message will be paired with a distinct
PointIndices message. In my use case, the PointIndices would be
unchanging. I thought initially that the approximate_sync option might
be able to be abused to make this happen, but I see the docs that
"Messages are used only once. Two sets cannot share the same message.
" [1]. So I suspect that the SACSegmentation code would need at least
a bit of tweaking to make work.

Radu, I believe you were asking about new features for 0.7... :)

Incidentally I was wondering why indices are specified by signed
integers; do negative values have a special significance, eg. indexing
backwards from the last point as in a Python array?

Cheers,
Pat

[1] http://www.ros.org/wiki/message_filters/ApproximateTime
_______________________________________________
[hidden email] / http://pointclouds.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation using an (unchanging) subset of points

Radu B. Rusu
Administrator
Pat,

On 12/12/2010 01:53 PM, Patrick Bouffard wrote:

> I would like to use the SACSegmentation PCLNodelet with an indices
> input to only segment a subset of the points in the cloud being input.
> It looks like this is supported in general but that the expectation is
> that each PointCloud2 message will be paired with a distinct
> PointIndices message. In my use case, the PointIndices would be
> unchanging. I thought initially that the approximate_sync option might
> be able to be abused to make this happen, but I see the docs that
> "Messages are used only once. Two sets cannot share the same message.
> " [1]. So I suspect that the SACSegmentation code would need at least
> a bit of tweaking to make work.

Hmm, let me see...

Is this the pcl_ros Nodelet or the pcl class? Maybe I can fix it right now.

The approximate time synchronizer does need that set of point indices to be resent unfortunately... and of course, if
the timestamp is not approximately the same as the cloud, it won't do a good job in matching them.


Interesting use case! So you want to send the indices once, and use them with different clouds. How does that work btw,
just out of curiosity? What do the indices represent in your case?


> Radu, I believe you were asking about new features for 0.7... :)

Sure did! :)

> Incidentally I was wondering why indices are specified by signed
> integers; do negative values have a special significance, eg. indexing
> backwards from the last point as in a Python array?

Interesting point. Nope, we never used it that way. I suppose we always had vector<int> because sometimes in older code
we were marking some indices as -1  if we didn't want them to be used (silly, I know). This is no longer the case.

Are we advocating a switch from "int" to "unsigned int" for 1.0? Is everyone ok with that?

_______________________________________________
[hidden email] / http://pointclouds.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation using an (unchanging) subset of points

Patrick Bouffard
On Sun, Dec 12, 2010 at 1:59 PM, Radu Bogdan Rusu <[hidden email]> wrote:
> Is this the pcl_ros Nodelet or the pcl class? Maybe I can fix it right now.

The nodelet. AFAICT the PCL class already supports it (sac_model.h:88-96):

      //////////////////////////////////////////////////////////////////////////////////////////////////////////////////
      /** \brief Constructor for base SampleConsensusModel.
        * \param cloud the input point cloud dataset
        * \param indices a vector of point indices to be used from \a cloud
        */
      SampleConsensusModel (const PointCloudConstPtr &cloud, const
std::vector<int> &indices) :
                            input_ (cloud),
                            indices_ (boost::make_shared
<std::vector<int> > (indices)),
                            radius_min_ (-DBL_MAX), radius_max_ (DBL_MAX) {};

> Interesting use case! So you want to send the indices once, and use them
> with different clouds. How does that work btw, just out of curiosity? What
> do the indices represent in your case?

Right. This is related to what we were talking about before. I'll
apply some kind of 'masking' (that's the better term I've come up with
for what I was calling "generalized downsampling" earlier..) when
creating the cloud in the first place, which is based on the source
'pixels' from the depth map (i.e. kinect output) that generates the
point cloud. So for that video that I made, e.g., I took only a 19,200
pixel rectangular window (that I expect will be mainly points on the
floor) out of the 307,200 pixel depth map and output that as the point
cloud, then segmented it to find a model of the floor, etc..

But say I'd like to grab some more non-floor areas so that I can get
more advance knowledge of upcoming obstacles. I do that by making,
say, indices 19201 through 20200 of the cloud come from an additional
1000 pixels in the depth image, above the rectangular window. Now, I
don't want to use those extra pixels in the segmentation as I'm pretty
sure they won't be part of the floor anyway, so they'll just slow down
that algorithm and potentially confuse it. But they will always be the
_same_ 1000 pixels, since my masking scheme is effectively fixed
relative to the sensor's camera coordinate system. Does that make
sense? Again, it's really only necessary in this case due to the
limited abilities of the onboard CPU but I expect there could be other
cases.

Actually a slight generalization on this would be a "sample-and-hold"
version of the ApproximateTime filter, where every point cloud comes
through but if there are not updates to the indices then the most
recent one is kept. I could see that being useful in more complex
behaviours, say if we want to not only detect an object using a
minimal number of points, but also identify it by boosting the number
of points in that region.

But for now, the simple version with a fixed set of indices would do
what I need.

> Are we advocating a switch from "int" to "unsigned int" for 1.0? Is everyone
> ok with that?

I'm not necessarily advocating a switch; if I'm not mistaken you
should be able to represent up to 2 billion or so points with a signed
int, which seems like it should be enough. Then again I don't have a
Velodyne to play with.. :)

Probably best to let sleeping dogs lie.. :)

Cheers,
Pat
_______________________________________________
[hidden email] / http://pointclouds.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation using an (unchanging) subset of points

Radu B. Rusu
Administrator

On 12/12/2010 02:41 PM, Patrick Bouffard wrote:
> On Sun, Dec 12, 2010 at 1:59 PM, Radu Bogdan Rusu<[hidden email]>  wrote:
>> Interesting use case! So you want to send the indices once, and use them
>> with different clouds. How does that work btw, just out of curiosity? What
>> do the indices represent in your case?
[...]

> But say I'd like to grab some more non-floor areas so that I can get
> more advance knowledge of upcoming obstacles. I do that by making,
> say, indices 19201 through 20200 of the cloud come from an additional
> 1000 pixels in the depth image, above the rectangular window. Now, I
> don't want to use those extra pixels in the segmentation as I'm pretty
> sure they won't be part of the floor anyway, so they'll just slow down
> that algorithm and potentially confuse it. But they will always be the
> _same_ 1000 pixels, since my masking scheme is effectively fixed
> relative to the sensor's camera coordinate system. Does that make
> sense? Again, it's really only necessary in this case due to the
> limited abilities of the onboard CPU but I expect there could be other
> cases.


I wonder if all we need is some form of a latched topic or something...

Let's see how the new pcl_ros::Publisher/Subscriber is looking like tomorrow, and maybe we can come up with a plan. So
the feature request here is:

  * send indices once on topic /foo
  * send cloud periodically on topic /bar

Synchronize /foo with /bar, without resending /foo. Did I get it right?


Cheers,
Radu.
--
http://pointclouds.org
_______________________________________________
[hidden email] / http://pointclouds.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation using an (unchanging) subset of points

Patrick Bouffard
Hi Radu,

I just realized that you asked a question in your last post.

On Fri, Dec 17, 2010 at 1:26 AM, Radu Bogdan Rusu <[hidden email]> wrote:
> Let's see how the new pcl_ros::Publisher/Subscriber is looking like
> tomorrow, and maybe we can come up with a plan. So the feature request here
> is:
>
>  * send indices once on topic /foo
>  * send cloud periodically on topic /bar
>
> Synchronize /foo with /bar, without resending /foo. Did I get it right?

Yes, I think so, but it should be "receive" rather than "send" in the
first bullet. Also I'm not sure I understand what you mean by
synchronize. The node(let) should simply segment using either all
points (if it never receives indices) or only the indices that were
most recently received. There needn't be any synchronization between
the indices and cloud inputs, in fact it would be difficult for them
to be synchronized, since they probably will come from different
places.

Hope that makes some sense. I was thinking since I already have trunk
perception_pcl checked out right now for that recent bugfix (thanks),
I might take a stab at implementing this but I want to first check if
you already have something underway. I'm thinking that the ROS API
will include a new parameter, 'latch_indices', defaulting to false.
When set to true, a subscriber will listen to ~indices and update an
internal vector of indices to use in the segmentation whenever its
callback is triggered.

Cheers,
Pat
_______________________________________________
[hidden email] / http://pointclouds.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation using an (unchanging) subset of points

Radu B. Rusu
Administrator
Patrick,


On 12/28/2010 09:38 AM, Patrick Bouffard wrote:

>>
>>   * send indices once on topic /foo
>>   * send cloud periodically on topic /bar
>>
>> Synchronize /foo with /bar, without resending /foo. Did I get it right?
>
> Yes, I think so, but it should be "receive" rather than "send" in the
> first bullet. Also I'm not sure I understand what you mean by
> synchronize. The node(let) should simply segment using either all
> points (if it never receives indices) or only the indices that were
> most recently received. There needn't be any synchronization between
> the indices and cloud inputs, in fact it would be difficult for them
> to be synchronized, since they probably will come from different
> places.

Well, synchronize = pair in this case.

> Hope that makes some sense. I was thinking since I already have trunk
> perception_pcl checked out right now for that recent bugfix (thanks),
> I might take a stab at implementing this but I want to first check if
> you already have something underway. I'm thinking that the ROS API
> will include a new parameter, 'latch_indices', defaulting to false.
> When set to true, a subscriber will listen to ~indices and update an
> internal vector of indices to use in the segmentation whenever its
> callback is triggered.

Yup, it makes total sense. Did you read the follow up e-mail that I sent regarding the implementation details? I'd be
happy to rewrite one nodelet, and it would be great if you could help us do the rest if you have time.

Cheers,
Radu.
_______________________________________________
[hidden email] / http://pointclouds.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation using an (unchanging) subset of points

Patrick Bouffard
On Tue, Dec 28, 2010 at 11:12 AM, Radu Bogdan Rusu
<[hidden email]> wrote:
> Yup, it makes total sense. Did you read the follow up e-mail that I sent
> regarding the implementation details?

If it was on pcl-users, ros-kinect or ros-users, then yes. :) But
maybe you should point me to it to be sure. Are you talking about this
thread: http://code.ros.org/lurker/thread/20101211.014708.bab91254.en.html?

> I'd be happy to rewrite one nodelet,
> and it would be great if you could help us do the rest if you have time.

I was thinking that all the changes could be made in
pcl_ros/src/pcl_ros/segmentation/sac_segmentation.cpp (and
corresponding header of course). Which other nodelets are you
referring to?

Cheers,
Pat
_______________________________________________
[hidden email] / http://pointclouds.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation using an (unchanging) subset of points

Radu B. Rusu
Administrator
Happy New Year! :)

On 12/28/2010 04:15 PM, Patrick Bouffard wrote:
> On Tue, Dec 28, 2010 at 11:12 AM, Radu Bogdan Rusu
> <[hidden email]>  wrote:
>> Yup, it makes total sense. Did you read the follow up e-mail that I sent
>> regarding the implementation details?
>
> If it was on pcl-users, ros-kinect or ros-users, then yes. :) But
> maybe you should point me to it to be sure. Are you talking about this
> thread: http://code.ros.org/lurker/thread/20101211.014708.bab91254.en.html?

No, I meant
http://point-cloud-library-pcl-mailing-list.967500.n3.nabble.com/PCL-ROS-Publisher-latched-or-not-td2097987.html

(Looks like I replied to the wrong e-mail - whoops)

>> I'd be happy to rewrite one nodelet,
>> and it would be great if you could help us do the rest if you have time.
>
> I was thinking that all the changes could be made in
> pcl_ros/src/pcl_ros/segmentation/sac_segmentation.cpp (and
> corresponding header of course). Which other nodelets are you
> referring to?

I think we can add the option "latched_indices" to all nodelets that operate on <Cloud,Indices>, as it might be useful.
I can go ahead and do sac_segmentation now. I'll send a notice after it's pushed in trunk.

Cheers,
Radu.
_______________________________________________
[hidden email] / http://pointclouds.org
https://code.ros.org/mailman/listinfo/pcl-users