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 <felix.ruess@gmail.com> wrote:
> Hi Radu,
>
> thanks for the quick reply.
>
>
> On Wed, Sep 29, 2010 at 8:46 PM, Radu Bogdan Rusu <rusu@willowgarage.com> 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
>