Re: [ros-users] PCL nodelet PointCloudConcatenateFieldsSynchronizer

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

Re: [ros-users] PCL nodelet PointCloudConcatenateFieldsSynchronizer

Radu B. Rusu
Administrator
Dear Felix,

On 09/29/2010 11:39 AM, Felix Ruess wrote:
> Hi,
>
> I'm using the pcl::concatenateFields(cloud_a, cloud_b, cloud_out)
> function to concatenate
>    pcl::PointCloud<pcl::PointXYZ>  cloud_a;
>    pcl::PointCloud<pcl::Normal>  cloud_b;
> to
>    pcl::PointCloud<pcl::PointNormal>  cloud_out;
> and it works great!

Thanks! We're happy to hear that.


> Is there any possibility to specify the output cloud type for the
> nodelet pcl/PointCloudConcatenateFieldsSynchronizer somehow as well?
> (This is used in the normal estimation launch file for example).

By output cloud type you mean you want to copy only certain fields, and not all? That is, if you have

PointCloud<PointXYZ> a;
PointCloud<Normal> b;

you want
PointCloud<PointXYNormal> c
instead of
PointCloud<PointXYZNormal> c

?

> The problem I have with the nodelet is that I'm trying to convert the
> output pointcloud2 message to
>      struct PointNormal;
>      // Members: float x, y, z; uint32_t w; float normal[3], curvature;
> to read the data.
> Now of course this does not work as the padding w is missing from the
> output pointcloud2 message I get from the nodelet since it "only"
> concatenates the existing fields of the input clouds.
>
> So, is there some way to adapt the nodelet to output a pointcloud2
> message that corresponds to a specific pcl PointCloud<specified point
> type>?

In general yes, we've been working on making that possible by publishing pcl::PointCloud<T> types instead of
sensor_msgs::PointCloud2 types. However, that's not fully finished yet (CC-ing Patrick who is the mastermind behind all
that magic).

>
> P.S. I did not sent this to pcl-users because the nodelet lives in pcl_ros

You can definitely send it there as pcl-users@ deals both with PCL _and_ PCL_ROS. :)

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

Re: [ros-users] PCL nodelet PointCloudConcatenateFieldsSynchronizer

Felix Ruess
Hi Radu,

thanks for the quick reply.


On Wed, Sep 29, 2010 at 8:46 PM, Radu Bogdan Rusu <[hidden email]> wrote:

> Dear Felix,
>
> On 09/29/2010 11:39 AM, Felix Ruess wrote:
>>
>> Hi,
>>
>> I'm using the pcl::concatenateFields(cloud_a, cloud_b, cloud_out)
>> function to concatenate
>>   pcl::PointCloud<pcl::PointXYZ>  cloud_a;
>>   pcl::PointCloud<pcl::Normal>  cloud_b;
>> to
>>   pcl::PointCloud<pcl::PointNormal>  cloud_out;
>> and it works great!
>
> Thanks! We're happy to hear that.
>
>
>> Is there any possibility to specify the output cloud type for the
>> nodelet pcl/PointCloudConcatenateFieldsSynchronizer somehow as well?
>> (This is used in the normal estimation launch file for example).
>
> By output cloud type you mean you want to copy only certain fields, and not
> all? That is, if you have
>
> PointCloud<PointXYZ> a;
> PointCloud<Normal> b;
>
> you want
> PointCloud<PointXYNormal> c
> instead of
> PointCloud<PointXYZNormal> c
>
> ?

No, not quite.
I just want to solve the problem that when I concatenate PointXYZ and
Normal (using the nodelet) I get a message that I can then convert
back to pcl PointNormal.
This fails because PointNormal is padded with the field w to be SSE friendly.
As long as the fields are simply concatenated there is no "magic"
happening to make sure I can convert it back to an already existing
pointcloud type (e.g. PointNormal).


>> The problem I have with the nodelet is that I'm trying to convert the
>> output pointcloud2 message to
>>     struct PointNormal;
>>     // Members: float x, y, z; uint32_t w; float normal[3], curvature;
>> to read the data.
>> Now of course this does not work as the padding w is missing from the
>> output pointcloud2 message I get from the nodelet since it "only"
>> concatenates the existing fields of the input clouds.
>>
>> So, is there some way to adapt the nodelet to output a pointcloud2
>> message that corresponds to a specific pcl PointCloud<specified point
>> type>?
>
> In general yes, we've been working on making that possible by publishing
> pcl::PointCloud<T> types instead of sensor_msgs::PointCloud2 types. However,
> that's not fully finished yet (CC-ing Patrick who is the mastermind behind
> all that magic).


Yes, I guess that would potentially solve the problem as it then would
be easier to write a new nodelet where you can specify the template
type for the output cloud (or even uses the concatenateFields
function).


>> P.S. I did not sent this to pcl-users because the nodelet lives in pcl_ros
>
> You can definitely send it there as pcl-users@ deals both with PCL _and_
> PCL_ROS. :)
>
> Cheers,
> Radu.

:-)

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

Re: [ros-users] PCL nodelet PointCloudConcatenateFieldsSynchronizer

Felix Ruess
A good example is the output you get from the concatenate fields
nodelet from the normal_estimation.launch (launchfile in pcl/launch/).
If you only have a PointXYZ cloud as input (and not a PointXYZI) then
the pointcloud2 message (concatenate_data/output) cannot be converted
back to any pointcloud of standard point types via pcl::fromROSMsg.
It works for PointXYZI input cloud because in for the PointXYZINormal
type there is no additional padding done.


On Wed, Sep 29, 2010 at 9:10 PM, Felix Ruess <[hidden email]> wrote:

> Hi Radu,
>
> thanks for the quick reply.
>
>
> On Wed, Sep 29, 2010 at 8:46 PM, Radu Bogdan Rusu <[hidden email]> wrote:
>> Dear Felix,
>>
>> On 09/29/2010 11:39 AM, Felix Ruess wrote:
>>>
>>> Hi,
>>>
>>> I'm using the pcl::concatenateFields(cloud_a, cloud_b, cloud_out)
>>> function to concatenate
>>>   pcl::PointCloud<pcl::PointXYZ>  cloud_a;
>>>   pcl::PointCloud<pcl::Normal>  cloud_b;
>>> to
>>>   pcl::PointCloud<pcl::PointNormal>  cloud_out;
>>> and it works great!
>>
>> Thanks! We're happy to hear that.
>>
>>
>>> Is there any possibility to specify the output cloud type for the
>>> nodelet pcl/PointCloudConcatenateFieldsSynchronizer somehow as well?
>>> (This is used in the normal estimation launch file for example).
>>
>> By output cloud type you mean you want to copy only certain fields, and not
>> all? That is, if you have
>>
>> PointCloud<PointXYZ> a;
>> PointCloud<Normal> b;
>>
>> you want
>> PointCloud<PointXYNormal> c
>> instead of
>> PointCloud<PointXYZNormal> c
>>
>> ?
>
> No, not quite.
> I just want to solve the problem that when I concatenate PointXYZ and
> Normal (using the nodelet) I get a message that I can then convert
> back to pcl PointNormal.
> This fails because PointNormal is padded with the field w to be SSE friendly.
> As long as the fields are simply concatenated there is no "magic"
> happening to make sure I can convert it back to an already existing
> pointcloud type (e.g. PointNormal).
>
>
>>> The problem I have with the nodelet is that I'm trying to convert the
>>> output pointcloud2 message to
>>>     struct PointNormal;
>>>     // Members: float x, y, z; uint32_t w; float normal[3], curvature;
>>> to read the data.
>>> Now of course this does not work as the padding w is missing from the
>>> output pointcloud2 message I get from the nodelet since it "only"
>>> concatenates the existing fields of the input clouds.
>>>
>>> So, is there some way to adapt the nodelet to output a pointcloud2
>>> message that corresponds to a specific pcl PointCloud<specified point
>>> type>?
>>
>> In general yes, we've been working on making that possible by publishing
>> pcl::PointCloud<T> types instead of sensor_msgs::PointCloud2 types. However,
>> that's not fully finished yet (CC-ing Patrick who is the mastermind behind
>> all that magic).
>
>
> Yes, I guess that would potentially solve the problem as it then would
> be easier to write a new nodelet where you can specify the template
> type for the output cloud (or even uses the concatenateFields
> function).
>
>
>>> P.S. I did not sent this to pcl-users because the nodelet lives in pcl_ros
>>
>> You can definitely send it there as pcl-users@ deals both with PCL _and_
>> PCL_ROS. :)
>>
>> Cheers,
>> Radu.
>
> :-)
>
> Cheers, Felix
>
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: [ros-users] PCL nodelet PointCloudConcatenateFieldsSynchronizer

Radu B. Rusu
Administrator
A-ham! You found a bug!

PointNormal should not contain "w" anymore.

We took great care to make Normal, PointXYZ, and similar structures SSE friendly under the hood, so the padding is no
longer necessary.

Can you work of trunk until we make a new release? If so, I'll push the changes in later today.

Cheers,
Radu.


On 09/29/2010 12:31 PM, Felix Ruess wrote:

> A good example is the output you get from the concatenate fields
> nodelet from the normal_estimation.launch (launchfile in pcl/launch/).
> If you only have a PointXYZ cloud as input (and not a PointXYZI) then
> the pointcloud2 message (concatenate_data/output) cannot be converted
> back to any pointcloud of standard point types via pcl::fromROSMsg.
> It works for PointXYZI input cloud because in for the PointXYZINormal
> type there is no additional padding done.
>
>
> On Wed, Sep 29, 2010 at 9:10 PM, Felix Ruess<[hidden email]>  wrote:
>> Hi Radu,
>>
>> thanks for the quick reply.
>>
>>
>> On Wed, Sep 29, 2010 at 8:46 PM, Radu Bogdan Rusu<[hidden email]>  wrote:
>>> Dear Felix,
>>>
>>> On 09/29/2010 11:39 AM, Felix Ruess wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm using the pcl::concatenateFields(cloud_a, cloud_b, cloud_out)
>>>> function to concatenate
>>>>    pcl::PointCloud<pcl::PointXYZ>    cloud_a;
>>>>    pcl::PointCloud<pcl::Normal>    cloud_b;
>>>> to
>>>>    pcl::PointCloud<pcl::PointNormal>    cloud_out;
>>>> and it works great!
>>>
>>> Thanks! We're happy to hear that.
>>>
>>>
>>>> Is there any possibility to specify the output cloud type for the
>>>> nodelet pcl/PointCloudConcatenateFieldsSynchronizer somehow as well?
>>>> (This is used in the normal estimation launch file for example).
>>>
>>> By output cloud type you mean you want to copy only certain fields, and not
>>> all? That is, if you have
>>>
>>> PointCloud<PointXYZ>  a;
>>> PointCloud<Normal>  b;
>>>
>>> you want
>>> PointCloud<PointXYNormal>  c
>>> instead of
>>> PointCloud<PointXYZNormal>  c
>>>
>>> ?
>>
>> No, not quite.
>> I just want to solve the problem that when I concatenate PointXYZ and
>> Normal (using the nodelet) I get a message that I can then convert
>> back to pcl PointNormal.
>> This fails because PointNormal is padded with the field w to be SSE friendly.
>> As long as the fields are simply concatenated there is no "magic"
>> happening to make sure I can convert it back to an already existing
>> pointcloud type (e.g. PointNormal).
>>
>>
>>>> The problem I have with the nodelet is that I'm trying to convert the
>>>> output pointcloud2 message to
>>>>      struct PointNormal;
>>>>      // Members: float x, y, z; uint32_t w; float normal[3], curvature;
>>>> to read the data.
>>>> Now of course this does not work as the padding w is missing from the
>>>> output pointcloud2 message I get from the nodelet since it "only"
>>>> concatenates the existing fields of the input clouds.
>>>>
>>>> So, is there some way to adapt the nodelet to output a pointcloud2
>>>> message that corresponds to a specific pcl PointCloud<specified point
>>>> type>?
>>>
>>> In general yes, we've been working on making that possible by publishing
>>> pcl::PointCloud<T>  types instead of sensor_msgs::PointCloud2 types. However,
>>> that's not fully finished yet (CC-ing Patrick who is the mastermind behind
>>> all that magic).
>>
>>
>> Yes, I guess that would potentially solve the problem as it then would
>> be easier to write a new nodelet where you can specify the template
>> type for the output cloud (or even uses the concatenateFields
>> function).
>>
>>
>>>> P.S. I did not sent this to pcl-users because the nodelet lives in pcl_ros
>>>
>>> You can definitely send it there as pcl-users@ deals both with PCL _and_
>>> PCL_ROS. :)
>>>
>>> Cheers,
>>> Radu.
>>
>> :-)
>>
>> Cheers, Felix
>>
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: [ros-users] PCL nodelet PointCloudConcatenateFieldsSynchronizer

Radu B. Rusu
Administrator
In reply to this post by Felix Ruess
Felix,

Check r32960:

* [pcl] field W is no longer needed in `pcl::PointNormal`, as it was only used for SSE optimization. Same for
`pcl::PointXYZW`, which means we can remove them.

Cheers,
Radu.


On 09/29/2010 12:31 PM, Felix Ruess wrote:

> A good example is the output you get from the concatenate fields
> nodelet from the normal_estimation.launch (launchfile in pcl/launch/).
> If you only have a PointXYZ cloud as input (and not a PointXYZI) then
> the pointcloud2 message (concatenate_data/output) cannot be converted
> back to any pointcloud of standard point types via pcl::fromROSMsg.
> It works for PointXYZI input cloud because in for the PointXYZINormal
> type there is no additional padding done.
>
>
> On Wed, Sep 29, 2010 at 9:10 PM, Felix Ruess<[hidden email]>  wrote:
>> Hi Radu,
>>
>> thanks for the quick reply.
>>
>>
>> On Wed, Sep 29, 2010 at 8:46 PM, Radu Bogdan Rusu<[hidden email]>  wrote:
>>> Dear Felix,
>>>
>>> On 09/29/2010 11:39 AM, Felix Ruess wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm using the pcl::concatenateFields(cloud_a, cloud_b, cloud_out)
>>>> function to concatenate
>>>>    pcl::PointCloud<pcl::PointXYZ>    cloud_a;
>>>>    pcl::PointCloud<pcl::Normal>    cloud_b;
>>>> to
>>>>    pcl::PointCloud<pcl::PointNormal>    cloud_out;
>>>> and it works great!
>>>
>>> Thanks! We're happy to hear that.
>>>
>>>
>>>> Is there any possibility to specify the output cloud type for the
>>>> nodelet pcl/PointCloudConcatenateFieldsSynchronizer somehow as well?
>>>> (This is used in the normal estimation launch file for example).
>>>
>>> By output cloud type you mean you want to copy only certain fields, and not
>>> all? That is, if you have
>>>
>>> PointCloud<PointXYZ>  a;
>>> PointCloud<Normal>  b;
>>>
>>> you want
>>> PointCloud<PointXYNormal>  c
>>> instead of
>>> PointCloud<PointXYZNormal>  c
>>>
>>> ?
>>
>> No, not quite.
>> I just want to solve the problem that when I concatenate PointXYZ and
>> Normal (using the nodelet) I get a message that I can then convert
>> back to pcl PointNormal.
>> This fails because PointNormal is padded with the field w to be SSE friendly.
>> As long as the fields are simply concatenated there is no "magic"
>> happening to make sure I can convert it back to an already existing
>> pointcloud type (e.g. PointNormal).
>>
>>
>>>> The problem I have with the nodelet is that I'm trying to convert the
>>>> output pointcloud2 message to
>>>>      struct PointNormal;
>>>>      // Members: float x, y, z; uint32_t w; float normal[3], curvature;
>>>> to read the data.
>>>> Now of course this does not work as the padding w is missing from the
>>>> output pointcloud2 message I get from the nodelet since it "only"
>>>> concatenates the existing fields of the input clouds.
>>>>
>>>> So, is there some way to adapt the nodelet to output a pointcloud2
>>>> message that corresponds to a specific pcl PointCloud<specified point
>>>> type>?
>>>
>>> In general yes, we've been working on making that possible by publishing
>>> pcl::PointCloud<T>  types instead of sensor_msgs::PointCloud2 types. However,
>>> that's not fully finished yet (CC-ing Patrick who is the mastermind behind
>>> all that magic).
>>
>>
>> Yes, I guess that would potentially solve the problem as it then would
>> be easier to write a new nodelet where you can specify the template
>> type for the output cloud (or even uses the concatenateFields
>> function).
>>
>>
>>>> P.S. I did not sent this to pcl-users because the nodelet lives in pcl_ros
>>>
>>> You can definitely send it there as pcl-users@ deals both with PCL _and_
>>> PCL_ROS. :)
>>>
>>> Cheers,
>>> Radu.
>>
>> :-)
>>
>> Cheers, Felix
>>
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: [ros-users] PCL nodelet PointCloudConcatenateFieldsSynchronizer

Dejan Pangercic
Hey Radu, thx a lot, I just tested and it works.
We have now a node here that visualizes normals in RVIZ as marker array:
http://tum-ros-pkg.svn.sourceforge.net/viewvc/tum-ros-pkg/mapping/pcl_cloud_tools/src/pcl_normal_visualization.cpp?revision=671&view=markup

And test launch file:
http://tum-ros-pkg.svn.sourceforge.net/viewvc/tum-ros-pkg/mapping/pcl_cloud_tools/launch/normal_estimation_rviz.launch?revision=671&view=markup
D.

On Thu, Sep 30, 2010 at 1:20 AM, Radu Bogdan Rusu <[hidden email]> wrote:

> Felix,
>
> Check r32960:
>
> * [pcl] field W is no longer needed in `pcl::PointNormal`, as it was only used for SSE optimization. Same for
> `pcl::PointXYZW`, which means we can remove them.
>
> Cheers,
> Radu.
>
>
> On 09/29/2010 12:31 PM, Felix Ruess wrote:
>> A good example is the output you get from the concatenate fields
>> nodelet from the normal_estimation.launch (launchfile in pcl/launch/).
>> If you only have a PointXYZ cloud as input (and not a PointXYZI) then
>> the pointcloud2 message (concatenate_data/output) cannot be converted
>> back to any pointcloud of standard point types via pcl::fromROSMsg.
>> It works for PointXYZI input cloud because in for the PointXYZINormal
>> type there is no additional padding done.
>>
>>
>> On Wed, Sep 29, 2010 at 9:10 PM, Felix Ruess<[hidden email]>  wrote:
>>> Hi Radu,
>>>
>>> thanks for the quick reply.
>>>
>>>
>>> On Wed, Sep 29, 2010 at 8:46 PM, Radu Bogdan Rusu<[hidden email]>  wrote:
>>>> Dear Felix,
>>>>
>>>> On 09/29/2010 11:39 AM, Felix Ruess wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm using the pcl::concatenateFields(cloud_a, cloud_b, cloud_out)
>>>>> function to concatenate
>>>>>    pcl::PointCloud<pcl::PointXYZ>    cloud_a;
>>>>>    pcl::PointCloud<pcl::Normal>    cloud_b;
>>>>> to
>>>>>    pcl::PointCloud<pcl::PointNormal>    cloud_out;
>>>>> and it works great!
>>>>
>>>> Thanks! We're happy to hear that.
>>>>
>>>>
>>>>> Is there any possibility to specify the output cloud type for the
>>>>> nodelet pcl/PointCloudConcatenateFieldsSynchronizer somehow as well?
>>>>> (This is used in the normal estimation launch file for example).
>>>>
>>>> By output cloud type you mean you want to copy only certain fields, and not
>>>> all? That is, if you have
>>>>
>>>> PointCloud<PointXYZ>  a;
>>>> PointCloud<Normal>  b;
>>>>
>>>> you want
>>>> PointCloud<PointXYNormal>  c
>>>> instead of
>>>> PointCloud<PointXYZNormal>  c
>>>>
>>>> ?
>>>
>>> No, not quite.
>>> I just want to solve the problem that when I concatenate PointXYZ and
>>> Normal (using the nodelet) I get a message that I can then convert
>>> back to pcl PointNormal.
>>> This fails because PointNormal is padded with the field w to be SSE friendly.
>>> As long as the fields are simply concatenated there is no "magic"
>>> happening to make sure I can convert it back to an already existing
>>> pointcloud type (e.g. PointNormal).
>>>
>>>
>>>>> The problem I have with the nodelet is that I'm trying to convert the
>>>>> output pointcloud2 message to
>>>>>      struct PointNormal;
>>>>>      // Members: float x, y, z; uint32_t w; float normal[3], curvature;
>>>>> to read the data.
>>>>> Now of course this does not work as the padding w is missing from the
>>>>> output pointcloud2 message I get from the nodelet since it "only"
>>>>> concatenates the existing fields of the input clouds.
>>>>>
>>>>> So, is there some way to adapt the nodelet to output a pointcloud2
>>>>> message that corresponds to a specific pcl PointCloud<specified point
>>>>> type>?
>>>>
>>>> In general yes, we've been working on making that possible by publishing
>>>> pcl::PointCloud<T>  types instead of sensor_msgs::PointCloud2 types. However,
>>>> that's not fully finished yet (CC-ing Patrick who is the mastermind behind
>>>> all that magic).
>>>
>>>
>>> Yes, I guess that would potentially solve the problem as it then would
>>> be easier to write a new nodelet where you can specify the template
>>> type for the output cloud (or even uses the concatenateFields
>>> function).
>>>
>>>
>>>>> P.S. I did not sent this to pcl-users because the nodelet lives in pcl_ros
>>>>
>>>> You can definitely send it there as pcl-users@ deals both with PCL _and_
>>>> PCL_ROS. :)
>>>>
>>>> Cheers,
>>>> Radu.
>>>
>>> :-)
>>>
>>> Cheers, Felix
>>>
> _______________________________________________
> [hidden email] / http://pcl.ros.org
> https://code.ros.org/mailman/listinfo/pcl-users
>



--
MSc. Dejan Pangercic
PhD Student/Researcher
Intelligent Autonomous Systems Group
Technische Universität München
Telephone: +49 (89) 289-26908
E-Mail: [hidden email]
WWW: http://ias.cs.tum.edu/people/pangercic
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: [ros-users] PCL nodelet PointCloudConcatenateFieldsSynchronizer

Radu B. Rusu
Administrator
Awesome!

Btw, did you check out pcd_viewer's normal visualization? Also there is an online_pointcloud_viewer tutorial that shows
how to display PointCloud2 data online, for situations where you don't want to load up rviz, or when rviz is too slow
for rendering many points.

Cheers,
Radu.


On 09/29/2010 06:04 PM, Dejan Pangercic wrote:

> Hey Radu, thx a lot, I just tested and it works.
> We have now a node here that visualizes normals in RVIZ as marker array:
> http://tum-ros-pkg.svn.sourceforge.net/viewvc/tum-ros-pkg/mapping/pcl_cloud_tools/src/pcl_normal_visualization.cpp?revision=671&view=markup
>
> And test launch file:
> http://tum-ros-pkg.svn.sourceforge.net/viewvc/tum-ros-pkg/mapping/pcl_cloud_tools/launch/normal_estimation_rviz.launch?revision=671&view=markup
> D.
>
> On Thu, Sep 30, 2010 at 1:20 AM, Radu Bogdan Rusu<[hidden email]>  wrote:
>> Felix,
>>
>> Check r32960:
>>
>> * [pcl] field W is no longer needed in `pcl::PointNormal`, as it was only used for SSE optimization. Same for
>> `pcl::PointXYZW`, which means we can remove them.
>>
>> Cheers,
>> Radu.
>>
>>
>> On 09/29/2010 12:31 PM, Felix Ruess wrote:
>>> A good example is the output you get from the concatenate fields
>>> nodelet from the normal_estimation.launch (launchfile in pcl/launch/).
>>> If you only have a PointXYZ cloud as input (and not a PointXYZI) then
>>> the pointcloud2 message (concatenate_data/output) cannot be converted
>>> back to any pointcloud of standard point types via pcl::fromROSMsg.
>>> It works for PointXYZI input cloud because in for the PointXYZINormal
>>> type there is no additional padding done.
>>>
>>>
>>> On Wed, Sep 29, 2010 at 9:10 PM, Felix Ruess<[hidden email]>    wrote:
>>>> Hi Radu,
>>>>
>>>> thanks for the quick reply.
>>>>
>>>>
>>>> On Wed, Sep 29, 2010 at 8:46 PM, Radu Bogdan Rusu<[hidden email]>    wrote:
>>>>> Dear Felix,
>>>>>
>>>>> On 09/29/2010 11:39 AM, Felix Ruess wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm using the pcl::concatenateFields(cloud_a, cloud_b, cloud_out)
>>>>>> function to concatenate
>>>>>>     pcl::PointCloud<pcl::PointXYZ>      cloud_a;
>>>>>>     pcl::PointCloud<pcl::Normal>      cloud_b;
>>>>>> to
>>>>>>     pcl::PointCloud<pcl::PointNormal>      cloud_out;
>>>>>> and it works great!
>>>>>
>>>>> Thanks! We're happy to hear that.
>>>>>
>>>>>
>>>>>> Is there any possibility to specify the output cloud type for the
>>>>>> nodelet pcl/PointCloudConcatenateFieldsSynchronizer somehow as well?
>>>>>> (This is used in the normal estimation launch file for example).
>>>>>
>>>>> By output cloud type you mean you want to copy only certain fields, and not
>>>>> all? That is, if you have
>>>>>
>>>>> PointCloud<PointXYZ>    a;
>>>>> PointCloud<Normal>    b;
>>>>>
>>>>> you want
>>>>> PointCloud<PointXYNormal>    c
>>>>> instead of
>>>>> PointCloud<PointXYZNormal>    c
>>>>>
>>>>> ?
>>>>
>>>> No, not quite.
>>>> I just want to solve the problem that when I concatenate PointXYZ and
>>>> Normal (using the nodelet) I get a message that I can then convert
>>>> back to pcl PointNormal.
>>>> This fails because PointNormal is padded with the field w to be SSE friendly.
>>>> As long as the fields are simply concatenated there is no "magic"
>>>> happening to make sure I can convert it back to an already existing
>>>> pointcloud type (e.g. PointNormal).
>>>>
>>>>
>>>>>> The problem I have with the nodelet is that I'm trying to convert the
>>>>>> output pointcloud2 message to
>>>>>>       struct PointNormal;
>>>>>>       // Members: float x, y, z; uint32_t w; float normal[3], curvature;
>>>>>> to read the data.
>>>>>> Now of course this does not work as the padding w is missing from the
>>>>>> output pointcloud2 message I get from the nodelet since it "only"
>>>>>> concatenates the existing fields of the input clouds.
>>>>>>
>>>>>> So, is there some way to adapt the nodelet to output a pointcloud2
>>>>>> message that corresponds to a specific pcl PointCloud<specified point
>>>>>> type>?
>>>>>
>>>>> In general yes, we've been working on making that possible by publishing
>>>>> pcl::PointCloud<T>    types instead of sensor_msgs::PointCloud2 types. However,
>>>>> that's not fully finished yet (CC-ing Patrick who is the mastermind behind
>>>>> all that magic).
>>>>
>>>>
>>>> Yes, I guess that would potentially solve the problem as it then would
>>>> be easier to write a new nodelet where you can specify the template
>>>> type for the output cloud (or even uses the concatenateFields
>>>> function).
>>>>
>>>>
>>>>>> P.S. I did not sent this to pcl-users because the nodelet lives in pcl_ros
>>>>>
>>>>> You can definitely send it there as pcl-users@ deals both with PCL _and_
>>>>> PCL_ROS. :)
>>>>>
>>>>> Cheers,
>>>>> Radu.
>>>>
>>>> :-)
>>>>
>>>> Cheers, Felix
>>>>
>> _______________________________________________
>> [hidden email] / http://pcl.ros.org
>> https://code.ros.org/mailman/listinfo/pcl-users
>>
>
>
>
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users