Libglew-dev is needed for simulation part but is not checked by the cmake file to be present.

It would be nice if PCL had better support for being built/released into the ROS ecosystem by conforming to the recommendations of REP-0136:

http://ros.org/reps/rep-0136.html

Specifically it would be nice to add a package.xml and a CMake rule to install it into PCL's share folder. This would enable PCL to be built from source and to be released using ROS's distribution infrastructure more easily. I feel that the required changes are fairly un-intrusive, but I can understand that it still may not be desirable, as it is a little like putting platform specific files in upstream (think debian folder), but on the other hand it eases from source building too.

Currently the needed file and install rule are added to PCL as a patch in our release repository (gbp repo):

https://github.com/ros-gbp/pcl-release/blob/bloom/hydro/package.xml

The main benefit is that if we were to move this file and install rule upstream into PCL, then ROS users could clone PCL directly into a ROS workspace and build it. Currently users must fetch PCL from our release repo (which has the patches), or they must integrate these patches into a cloned version of PCL in order to use it in a ROS workspace.

Probably the biggest draw back is maintaining information in the package.xml, which may already exist else where, like the version, description, license, or authors/maintainers. It does help capture those elements and other useful information which is rarely captured otherwise (like the explicit run/build/test dependencies, and websites with urls) in a machine readable format.

If there is interest in this concept I can open a pull request against the https://github.com/sdmiller/pcl/tree/remove_ros version of PCL currently being worked on for PCL-1.7, in order to show the extent of the changes. Otherwise we can continue to maintain these required elements as patches in the ROS specific release repository.

So after a lively discussion over at Stack Overflow (see http://stackoverflow.com/questions/17863125/concatenate-2-stl-vectors-in-constant-o1-time), it appears the type of data structure used in <pcl/point_cloud.h> may not be optimal for all use cases. Specifically, I am trying to concatenate multiple point clouds together while doing as little processing as possible. Unfortunately, the += operator implementation resizes the points vector, then copies across all the points from the other point cloud in O(n) time. This is not good news as I am creating a (near-)real time processing application fed by input from multiple Kinects using the OpenNI grabber.

The suggestions from the discussion are that 'invasive surgery' is probably necessary; this can be done by

1. changing the data structure from std::vector to a std::list and implementing += using list#splice.
2. creating a wrapper data structure to present the illusion of one big concatenated vector, but which in fact contains all the vectors of the concatenated point clouds and has some logic to jump from the end of one vector to the beginning of another.
3. various other suggestions in the discussion which I know less about.

What are the merits and likely impacts of implementing 1) or 2) in point_cloud.h? I am very aware that the gains in point cloud concatenation performance by switching to std::list might impede performance in other operations, but I'm not familiar enough with PCL (nor do I use a large enough portion of it) to call this either way, so I thought you as the library authors might have a better idea.

Thanks in advance, and please excuse a PCL newbie's mistakes if I have made any :)

When building pcl_ros against the pcl-1.7.0rc1 tag on the ROS build farm I get this error:

/opt/ros/hydro/include/pcl-1.7/pcl/common/io.h:47:29: fatal error: pcl/conversions.h: No such file or directory

So a couple ideas here:

• pcl/conversions.h is not being installed
• pcl/conversions.h was removed, but the reference in pcl/common/io.h was missed

Full build log here:

http://jenkins.willowgarage.com:8080/job/ros-hydro-pcl-ros_binarydeb_precise_amd64/17/console

I'll be looking into it building locally on my machine.

Hi,

Pressing 'f' to focus on a point does not work as it used to. First of all, it does not work on some parts of the point cloud, and when it does, it moves the camera the wrong way.
I expect there is some inconsistency between what is displayed in the scene and the selection buffer, aaaaand it might have something to do with the recent point picking changes (hint hint, @nizar-sallem :-) ).

Cheers,
Alex

Hi,

I think this is related to the new lasso select tool.

I get the following effects:

• R and shift+R does not work anymore
• after I press R it goes into click-down mode and the cloud moves as I move my mouse. Pressing R again will stop that, but start a lasso.

This is on Mountain Lion with VTK 5.10.1, latest revision as per the time of writing.

Thanks!
Cheers,
Alex

There was already a previous issue, but the problem still remains.

/home/potthast/pcl-NEWEST-RELEASE/io/src/image_grabber.cpp: In member function ‘bool pcl::ImageGrabberBase::ImageGrabberImpl::getCloudVTK(size_t, sensor_msgs::PointCloud2&, Eigen::Vector4f&, Eigen::Quaternionf&) const’:
/home/potthast/pcl-NEWEST-RELEASE/io/src/image_grabber.cpp:634:34: error: no match for ‘operator=’ in ‘cloud_color.pcl::PointCloudpcl::PointXYZRGBA::header.std_msgs::Header_std::allocator::stamp = timestamp’
/home/potthast/pcl-NEWEST-RELEASE/io/src/image_grabber.cpp:634:34: note: candidate is:
/opt/ros/groovy/include/ros/time.h:169:22: note: ros::Time& ros::Time::operator=(const ros::Time&)
/opt/ros/groovy/include/ros/time.h:169:22: note: no known conversion for argument 1 from ‘uint64_t {aka long unsigned int}’ to ‘const ros::Time&’
/home/potthast/pcl-NEWEST-RELEASE/io/src/image_grabber.cpp:670:28: error: no match for ‘operator=’ in ‘cloud.pcl::PointCloudpcl::PointXYZ::header.std_msgs::Header_std::allocator::stamp = timestamp’
/home/potthast/pcl-NEWEST-RELEASE/io/src/image_grabber.cpp:670:28: note: candidate is:
/opt/ros/groovy/include/ros/time.h:169:22: note: ros::Time& ros::Time::operator=(const ros::Time&)
/opt/ros/groovy/include/ros/time.h:169:22: note: no known conversion for argument 1 from ‘uint64_t {aka long unsigned int}’ to ‘const ros::Time&’
/home/potthast/pcl-NEWEST-RELEASE/io/src/image_grabber.cpp: In member function ‘bool pcl::ImageGrabberBase::ImageGrabberImpl::getCloudPCLZF(size_t, sensor_msgs::PointCloud2&, Eigen::Vector4f&, Eigen::Quaternionf&, double&, double&, double&, double&) const’:
/home/potthast/pcl-NEWEST-RELEASE/io/src/image_grabber.cpp:767:34: error: no match for ‘operator=’ in ‘cloud_color.pcl::PointCloudpcl::PointXYZRGBA::header.std_msgs::Header_std::allocator::stamp = timestamp’
/home/potthast/pcl-NEWEST-RELEASE/io/src/image_grabber.cpp:767:34: note: candidate is:
/opt/ros/groovy/include/ros/time.h:169:22: note: ros::Time& ros::Time::operator=(const ros::Time&)
/opt/ros/groovy/include/ros/time.h:169:22: note: no known conversion for argument 1 from ‘uint64_t {aka long unsigned int}’ to ‘const ros::Time&’
/home/potthast/pcl-NEWEST-RELEASE/io/src/image_grabber.cpp:813:28: error: no match for ‘operator=’ in ‘cloud.pcl::PointCloudpcl::PointXYZ::header.std_msgs::Header_std::allocator::stamp = timestamp’
/home/potthast/pcl-NEWEST-RELEASE/io/src/image_grabber.cpp:813:28: note: candidate is:
/opt/ros/groovy/include/ros/time.h:169:22: note: ros::Time& ros::Time::operator=(const ros::Time&)
/opt/ros/groovy/include/ros/time.h:169:22: note: no known conversion for argument 1 from ‘uint64_t {aka long unsigned int}’ to ‘const ros::Time&’
make[2]: *** [io/CMakeFiles/pcl_io.dir/src/image_grabber.cpp.o] Error 1
make[1]: *** [io/CMakeFiles/pcl_io.dir/all] Error 2

I am trying to visualize the results of ICP between 2 clouds. When I open the results in pcl_viewer I get the result on the left (which is bogus because my ICP error is going down and things converge nicely).
If I convert the .pcd's to .ply's and display them with MeshLab, they look like on the right (closer to 2 properly registered clouds). So it is not the .pcd format, but the visualizer I guess.

@nizar-sallem, I could give you the .pcds if you want to have a look please.

If I compile the pcl, I get:

...
In file included from /opt/ros/fuerte/include/std_msgs/Header.h:49:0,
                 from /home/korn/pcl/common/include/pcl/ModelCoefficients.h:8,
                 from /home/korn/pcl/common/include/pcl/common/intersections.h:40,
                 from /home/korn/pcl/common/src/intersections.cpp:38:
/opt/ros/fuerte/include/ros/message_operations.h: In instantiation of ‘static void ros::message_operations::Printer<M>::stream(Stream&, const string&, const M&) [with Stream = std::basic_ostream<char>, M = unsigned int, std::string = std::basic_string<char>]’:
/opt/ros/fuerte/include/std_msgs/Header.h:239:5:   instantiated from ‘static void ros::message_operations::Printer<std_msgs::Header_<ContainerAllocator> >::stream(Stream&, const string&, const std_msgs::Header_<ContainerAllocator>&) [with Stream = std::basic_ostream<char>, ContainerAllocator = std::allocator<void>, std::string = std::basic_string<char>]’
/opt/ros/fuerte/include/std_msgs/Header.h:102:1:   instantiated from ‘std::ostream& std_msgs::operator<<(std::ostream&, const std_msgs::Header_<ContainerAllocator>&) [with ContainerAllocator = std::allocator<void>, std::ostream = std::basic_ostream<char>]’
...

Like you can see during make the directory /opt/ros/fuerte/include/ is used but USE_ROS is OFF. This is the value of FLANN_INCLUDE_DIR.
The problem is that "sensor_msgs" and "std_msgs" are in /opt/ros/fuerte/include/, too. Because of this pcl/common/include/sensor_msgs/ and pcl/common/include/std_msgs/ are covered.

The Asus Xiton Pro windows driver crashes after 71 minutes when PointXYZRGBA is used (see testcode [1]).

This bug is repeatable across different computers using PCL 1.6.0 for Windows (installed from pre-built binaries). The bug manifests itself when PointXYZRGBA (see figure below). If the grabber object is recreated every time the frame rate drops to zero, then the 71 minutes is repeatable across 100's of cycles (this is not shown in the data below because the test code does not recreate the grabber object)

The bug is not exhibited when PointXYZ is used (see figure below). Note: there are some extraneous data points where the frame rate is 3-4 times the normal 30 fps. Not sure why this is the case.

The repeat-ability of failure after 71 minutes across several computers seems to indicate that this bug is tied/driven by the frame rate.

[1] Testcode:

// Sensor Test Console.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <pcl/io/openni_grabber.h>
//#include <pcl/visualization/cloud_viewer.h>
#include <pcl/point_cloud.h> //basic pcl includes
#include <pcl/point_types.h>
#include <boost/function.hpp>

#include <iostream>
#include <fstream>
using namespace std;

/*
Run the test program below to demonstrate the driver crash.
To recreate the bug
*/


class SensorTest
{
public:


    pcl::OpenNIGrabber sensor;
    bool cb_executed;
    int cb_timeout;
    int time_count;
    int frame_count;
    int min_frame_count;
    ofstream file;

    SensorTest()
    {
        cout << "Consturcting sensor test object" << endl;

        cb_executed = false;
        cb_timeout = 1;  //seconds
        time_count = 0;
        frame_count = 0;
        min_frame_count = 10;
    }

    ~SensorTest()
    {
        cout << "Destruction sensor test object" << endl;
        file.close();

    }

   // Change function signature based on desired cloud type
    //void callback (const pcl::PointCloud<pcl::PointXYZ>::ConstPtr &cloud)
    void callback (const pcl::PointCloud<pcl::PointXYZRGBA>::ConstPtr &cloud)
    {
        //cout << "Callback executed" << endl;
        cb_executed = true;
        frame_count++;
    }

    void run()
    {

      // Change the desired cloud type here (don't forget the function signature
      // above.
        /*
        boost::function<void (const pcl::PointCloud<pcl::PointXYZ>::ConstPtr&)> f =
         boost::bind (&SensorTest::callback, this, _1);
        */

        boost::function<void (const pcl::PointCloud<pcl::PointXYZRGBA>::ConstPtr&)> f =
         boost::bind (&SensorTest::callback, this, _1);



        file.open("SensorTestOutput.csv");
        file << "capture count, capture duration(s), capture duration(m), frame count, fps" << endl; 

        cout << "Registering callback" << endl;
        sensor.registerCallback(f);

        cout << "Starting sensor" << endl;
        sensor.start();

        do
        {
            cb_executed = false;
            boost::this_thread::sleep (boost::posix_time::seconds (cb_timeout));
            time_count++;
            cout << "Elapsed time(count: " << time_count 
                << ", seconds: " << time_count * cb_timeout
                << ", minutes: " << time_count * cb_timeout / 60.0
                << ")"
                << " Frame(count: " << frame_count
                << " , fps: " << frame_count /cb_timeout
                << ")"
                << endl;
            file << time_count << ","
                << time_count * cb_timeout << ","
                << time_count * cb_timeout / 60.0 << ","
                << frame_count << ","
                << frame_count /cb_timeout << ","
                << endl;

            if (float(frame_count)/float(cb_timeout) < min_frame_count)
            {
                cout << "Exiting loop due to min fps" << endl;
                break;
                cb_executed = true;  //in order to keep the loop going.
            }

            frame_count = 0;
        }
        while(cb_executed);

        file.close();
    }

};

int _tmain(int argc, _TCHAR* argv[])
{

    cout << "Main started" << endl;
    SensorTest test;
    test.run();
    cout << "Main ended, press button to end" << endl;
    int a;
    cin >> a;
}

I have been trying to work with pointclouds with sizes above the 300 million points. The creation of the cloud (as a PCD file) seems to be fine but its later visualization is impossible; it always crashes.

I have been studying this issue with different programs. For that I created a random cloud with 300M points. When I tried to load the (4.5 GB) PCD file with pcl::io::loadPCDFile the program crashes at:

[conversions.h] fromPCLPointCloud2, line 212 (in the memcpy)

else
{
  // If not, memcpy each group of contiguous fields separately
  for (uint32_t row = 0; row < msg.height; ++row)
  {
    const uint8_t* row_data = &msg.data[row * msg.row_step];
    for (uint32_t col = 0; col < msg.width; ++col)
    {
      const uint8_t* msg_data = row_data + col * msg.point_step;
      BOOST_FOREACH (const detail::FieldMapping& mapping, field_map)
      {
        memcpy (cloud_data + mapping.struct_offset, msg_data +   mapping.serialized_offset, mapping.size);
      }
      cloud_data += sizeof (PointT);
    }
  }
}

The memcpy fails when col = 30000000 (30M).

If instead of loading the PCD file I directly generate a random point cloud and try to visualize it the crash is harder to understand. I did this with the a pcl::visualization::CloudViewer object and got the following backtrace:

(gdb) bt
#0 0x00007f7c8df6ce9d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f7c8218bcab in ?? () from /usr/lib/nvidia-current/libnvidia-glcore.so.319.37
#2 0x00007f7c8218c92e in ?? () from /usr/lib/nvidia-current/libnvidia-glcore.so.319.37
#3 0x00007f7c8a5dc8aa in vtkOpenGLPainterDeviceAdapter::SendAttribute(int, int, int, void const*, long long) () from /usr/lib/libvtkRendering.so.5.8
#4 0x00007f7c8a4fa45c in vtkPointsPainter::RenderPrimitive(unsigned long, vtkDataArray_, vtkUnsignedCharArray_, vtkDataArray_, vtkRenderer_) () from /usr/lib/libvtkRendering.so.5.8
#5 0x00007f7c8a50772e in vtkPrimitivePainter::RenderInternal(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#6 0x00007f7c8a4fff6b in vtkPolyDataPainter::Render(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#7 0x00007f7c8a414261 in vtkChooserPainter::RenderInternal(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#8 0x00007f7c8a4fff6b in vtkPolyDataPainter::Render(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#9 0x00007f7c8a4fff6b in vtkPolyDataPainter::Render(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#10 0x00007f7c8a5f5917 in vtkOpenGLRepresentationPainter::RenderInternal(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#11 0x00007f7c8a4fff6b in vtkPolyDataPainter::Render(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#12 0x00007f7c8a5d9370 in vtkOpenGLLightingPainter::RenderInternal(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#13 0x00007f7c8a4fff6b in vtkPolyDataPainter::Render(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#14 0x00007f7c8a5c69de in vtkOpenGLDisplayListPainter::RenderInternal(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#15 0x00007f7c8a5c5d18 in vtkOpenGLClipPlanesPainter::RenderInternal(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#16 0x00007f7c8a5f5fd9 in vtkOpenGLScalarsToColorsPainter::RenderInternal(vtkRenderer_, vtkActor_, unsigned long, bool) () from /usr/lib/libvtkRendering.so.5.8
#17 0x00007f7c8a4d60b2 in vtkPainterPolyDataMapper::RenderPiece(vtkRenderer_, vtkActor_) () from /usr/lib/libvtkRendering.so.5.8
#18 0x00007f7c8a4ff2ce in vtkPolyDataMapper::Render(vtkRenderer_, vtkActor_) () from /usr/lib/libvtkRendering.so.5.8
#19 0x00007f7c8a41cdfa in vtkDataSetMapper::Render(vtkRenderer_, vtkActor_) () from /usr/lib/libvtkRendering.so.5.8
#20 0x00007f7c8a5c4fa2 in vtkOpenGLActor::Render(vtkRenderer_, vtkMapper_) () from /usr/lib/libvtkRendering.so.5.8
#21 0x00007f7c8a4c5fc9 in vtkLODActor::Render(vtkRenderer_, vtkMapper_) () from /usr/lib/libvtkRendering.so.5.8
#22 0x00007f7c8a4c5e5f in vtkLODActor::RenderOpaqueGeometry(vtkViewport*) () from /usr/lib/libvtkRendering.so.5.8
#23 0x00007f7c8a51d4ee in vtkRenderer::UpdateGeometry() () from /usr/lib/libvtkRendering.so.5.8
#24 0x00007f7c8a5f1f02 in vtkOpenGLRenderer::DeviceRender() () from /usr/lib/libvtkRendering.so.5.8
#25 0x00007f7c8a5206dc in vtkRenderer::Render() () from /usr/lib/libvtkRendering.so.5.8
#26 0x00007f7c90070851 in pcl::visualization::PCLVisualizer::resetCameraViewpoint (this=0x7f7c6c0008e0, id=...) at /usr/pcl/visualization/src/pcl_visualizer.cpp:1964
#27 0x00007f7c9009ba3b in pcl::cloud_showpcl::PointCloud<pcl::PointXYZRGB >::poppcl::visualization::PointCloudColorHandlerRGBField<pcl::PointXYZRGB > (this=this@entry=0x2251320, handler=...) at /usr/pcl/visualization/src/cloud_viewer.cpp:70
#28 0x00007f7c90094fd1 in pcl::cloud_showpcl::PointCloud<pcl::PointXYZRGB >::pop (this=0x2251320) at /usr/pcl/visualization/src/cloud_viewer.cpp:110
#29 0x00007f7c90096da1 in pcl::visualization::CloudViewer::CloudViewer_impl::operator() (this=0x2250e70) at /usr/pcl/visualization/src/cloud_viewer.cpp:191
#30 0x00007f7c8dc106c9 in ?? () from /usr/lib/libboost_thread.so.1.49.0
#31 0x00007f7c91176e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#32 0x00007f7c8df11ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#33 0x0000000000000000 in ?? ()

I am using the trunk version of PCL in a Ubuntu 12.10 64 bits desktop computer with 64 GB of RAM and a graphic card Nvidia GeForce GTX 680 (4 GB of memory). I don't think the problem is due to a memory limitation. It must be something else.

Please, could you tell someone tell me how to contribute with more information about this issue? (the core file size is 49 GB).

This is a robustness issue for deserialization of ROS PointCount2 messages.

The following program does not terminate in a reasonable amount of time.

#include <sensor_msgs/PointCloud2.h>
#include <pcl/ros/conversions.h>
#include <pcl/point_cloud.h>
#include <pcl/point_types.h>

int
main (int argc, char** argv)
{
    sensor_msgs::PointCloud2 msg;
    msg.width -= 1;
    msg.height -= 1;

    pcl::PointCloud<pcl::PointXYZ> cloud;
    pcl::fromROSMsg(msg, cloud);

}

It appears to get stuck in the loop near line 203 of conversions.h. https://github.com/PointCloudLibrary/pcl/blob/master/common/include/pcl/conversions.h

Similarly, the below program can be frozen by sending it a single ROS message:

$ rostopic pub /input sensor_msgs/PointCloud2 \
    "{'width':4294967295,'height':4294967295}" -1

#include <ros/ros.h>
#include <sensor_msgs/PointCloud2.h>
#include <pcl/ros/conversions.h>
#include <pcl/point_cloud.h>
#include <pcl/point_types.h>

void
cloud_cb (const sensor_msgs::PointCloud2ConstPtr& input)
{
  pcl::PointCloud<pcl::PointXYZ> cloud;
  pcl::fromROSMsg(*input, cloud);
  ROS_INFO("done processing message");
}

int
main (int argc, char** argv)
{
  // Initialize ROS
  ros::init (argc, argv, "my_pcl_tutorial");
  ros::NodeHandle nh;

  // Create a ROS subscriber for the input point cloud
  ros::Subscriber sub = nh.subscribe ("input", 1, cloud_cb);

  // Spin
  ros::spin ();
}

Some values for width and height, like those below, cause the program to crash with a std::bac_alloc exception instead.

$ rostopic pub /input sensor_msgs/PointCloud2 \
    "{'width':4000000000,'height':4000000000}" -1

I am on 64-bit Ubuntu 12.04, using the PCL that was packaged with ROS Groovy. It appears that this issue has not been fixed in newer versions.

When I Configure PCL Source Code with CMake, this is no problem. But when I compile the pcl_kinfu_app project,there are some errors like Undefined identifiers “scriptNode” and xn::Context::CreateProductionTree”: Function does not accept two parameters. It puzzles me a lot.

Visualizing a vtk and a pcd file using the pcd_viewer with different rendering properties (fc, ps) is not possible. The pcd_viewer in the current version can only handle different rendering properties if just one of the two supported formats is used, but not both at once. Using both at once results in a false indexing of the rendering properties.

Radu B. Rusu asked me to forward this problem tothe git hub. He thinks that this might be an aligning bug.

I am using the PCL 1.6.0 in VS 2010 together with VTK and QT. When I use the normal estimation with the kdtree my program crashes with the std::length_error when kdtree setInputCloud is called. I had to include the #define EIGEN_DONT_ALIGN Macro earlier to get the code running with another problem and somebody wrote that this could provocate my problem.

pcl::PointCloudpcl::PointXYZ::Ptr tempCloud (new pcl::PointCloudpcl::PointXYZ);

pcl::NormalEstimation<pcl::PointXYZ, pcl::Normal> ne;

ne.setInputCloud (tempCloud);

pcl::search::KdTreepcl::PointXYZ::Ptr tree (new pcl::search::KdTreepcl::PointXYZ ());

ne.setSearchMethod (tree);

pcl::PointCloudpcl::Normal::Ptr cloud_normals (new pcl::PointCloudpcl::Normal);

ne.setRadiusSearch (0.3);

ne.compute (*cloud_normals);

The program then crashes in kdtree.h at row 134:

tree_->setInputCloud (cloud, indices);

when the function is called with the indices variable

with the given error

Hi Alex,

I've just traced this to your commit: 4bd780e. The unit test looks rather strange and I didn't find any comments for it. Can you fix it, or should we just revert it? I guess this is the same problem as in #106.

Cheers Jochen

...
[ 26%] Building CXX object visualization/CMakeFiles/pcl_visualization.dir/src/image_viewer.cpp.o
In file included from /home/mozgiii/pclb/pcl/visualization/src/image_viewer.cpp:44:0:
/home/mozgiii/pclb/pcl/visualization/include/pcl/visualization/image_viewer.h:956:25: ошибка: нет декларации «vtkImageSlice» в этой области видимости
         vtkSmartPointer<vtkImageSlice> slice_;
                         ^
/home/mozgiii/pclb/pcl/visualization/include/pcl/visualization/image_viewer.h:956:38: ошибка: некорректный аргумент шаблона 1
         vtkSmartPointer<vtkImageSlice> slice_;
                                      ^
make[2]: *** [visualization/CMakeFiles/pcl_visualization.dir/src/image_viewer.cpp.o] Ошибка 1
make[1]: *** [visualization/CMakeFiles/pcl_visualization.dir/all] Ошибка 2
make: *** [all] Ошибка 2

The problem is that vtkImageSlice is not defined any where in image_viewer.h. Can you fix it for me please?

PS: sry for error messages in russian, I'm too lazy to redo everything...

On Ubuntu 13.04 building 1.70rc2 using default build settings does not build pcl_geometry. "BUILD_GEOMETRY" is activated in cmake, but the library is not being built. IOW, no libpcl_geometry.so.1.7.0 is generated.
pcl_geometry is being reference by diverse pkg-config files.

+++++++++++++++++++++++++++++++++++++++++++++++++++++
Using CPU native flags for SSE optimization: -march=native
Performing Test HAVE_MM_MALLOC
Performing Test HAVE_MM_MALLOC - Success
Performing Test HAVE_POSIX_MEMALIGN
Performing Test HAVE_POSIX_MEMALIGN - Success
Performing Test HAVE_SSE4_2_EXTENSIONS
Performing Test HAVE_SSE4_2_EXTENSIONS - Success
Performing Test HAVE_SSE4_1_EXTENSIONS
Performing Test HAVE_SSE4_1_EXTENSIONS - Success
Performing Test HAVE_SSE3_EXTENSIONS
Performing Test HAVE_SSE3_EXTENSIONS - Success
Performing Test HAVE_SSE2_EXTENSIONS
Performing Test HAVE_SSE2_EXTENSIONS - Success
Performing Test HAVE_SSE_EXTENSIONS
Performing Test HAVE_SSE_EXTENSIONS - Success
-- GCC > 4.3 found, enabling -Wabi
Try OpenMP C flag = [-fopenmp]
Performing Test OpenMP_FLAG_DETECTED
Performing Test OpenMP_FLAG_DETECTED - Success
Try OpenMP CXX flag = [-fopenmp]
Performing Test OpenMP_FLAG_DETECTED
Performing Test OpenMP_FLAG_DETECTED - Success
Found OpenMP: -fopenmp
Found OpenMP
Boost version: 1.49.0
Found the following Boost libraries:
system
filesystem
thread
date_time
iostreams
checking for module 'eigen3'
found eigen3, version 3.1.2
Found Eigen: /usr/include/eigen3
Eigen found (include: /usr/include/eigen3)
checking for module 'flann>=1.7.0'
found flann, version 1.7.1
Found FLANN: /usr/lib/libflann_cpp.so (Required is at least version "1.7.0")
FLANN found (include: /usr/include, lib: optimized;/usr/lib/libflann_cpp.so;debug;/usr/lib/libflann_cpp.so)
Found LIBUSB_1: /usr/lib/x86_64-linux-gnu/libusb-1.0.so
checking for module 'libusb-1.0'
found libusb-1.0, version 1.0.12
Found USB_10: /usr/lib/x86_64-linux-gnu/libusb-1.0.so
Found OpenNI: /usr/lib/libOpenNI.so
OpenNI found (include: /usr/include/ni, lib: /usr/lib/libOpenNI.so)
Could NOT find FZAPI (missing: FZAPI_LIBS FZAPI_INCLUDE_DIR)
Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.7")
Found PNG: /usr/lib/x86_64-linux-gnu/libpng.so (found version "1.2.49")
Found Qhull: /usr/lib/libqhull.so
QHULL found (include: /usr/include/qhull, lib: optimized;/usr/lib/libqhull.so;debug;/usr/lib/libqhull.so)
Looking for Q_WS_X11
Looking for Q_WS_X11 - found
Looking for Q_WS_WIN
Looking for Q_WS_WIN - not found
Looking for Q_WS_QWS
Looking for Q_WS_QWS - not found
Looking for Q_WS_MAC
Looking for Q_WS_MAC - not found
Found Qt4: /usr/bin/qmake (found version "4.8.4")
Found QVTK: /usr/lib/libQVTK.so
VTK found (include: /usr/include/vtk-5.8;/usr/include, lib: /usr/lib/;/usr/lib)
Found Doxygen: /usr/bin/doxygen (found version "1.8.3.1")
PCAP NOT found
Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
Looking for gethostbyname
Looking for gethostbyname - found
Looking for connect
Looking for connect - found
Looking for remove
Looking for remove - found
Looking for shmat
Looking for shmat - found
Looking for IceConnectionNumber in ICE
Looking for IceConnectionNumber in ICE - found
Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so
DOXYGEN_FOUND YES
HTML_HELP_COMPILER
checking for module 'sphinx-build'
package 'sphinx-build' not found
Found PythonInterp: /usr/bin/python (found version "2.7.4")
Could NOT find Sphinx (missing: SPHINX_EXECUTABLE)
Found CPack generators: DEB
The following subsystems will be built:
common
kdtree
octree
search
sample_consensus
filters
io
2d
features
keypoints
geometry
visualization
outofcore
ml
segmentation
people
registration
recognition
surface
global_tests
stereo
tools
tracking
The following subsystems will not be built:
simulation: Disabled by default.
examples: Code examples are disabled by default.
apps: Disabled by default.
Configuring done

A pointcloud consist of 8 points, making up a bounding box in 3D. I wanted to select all points inside the boundingbox in another point cloud by computing a convex hull of the points and filtering the cloud by the crop hull filter in 3 dimensions. The result changed when I duplicated two points in the cloud. In both cases, approximatley one half of the points were selected.

In line 68 of pcl/tools/oni2pcd.cpp, the %zu format specifier is not compatible with the MSVC compiler. Changing to %lu resolves the issue for the MSVC compiler.

@nizar-sallem , @mmunaro

I am playing with the people detector, and the plane selection is really messed up. I click on some points, and get completely random points in the scene. They seem to be rolled around the z-axis by 180 degrees (see the screenshot). But I cannot seem to find the problem in the code. Nizar, can you have a look, the code is super short in apps/main_ground_base_rbgd_people_detector.cpp ?

Thanks guys!

https://travis-ci.org/PointCloudLibrary/pcl/jobs/7453279

Mail from Peter Soetens to pcl-developers:

Hi,

Setup is an Xtion Live, OpenNI 1.5.4.0 and Sensor 5.1.0.41, with our
callbacks added to the PCL openni grabber, and capturing images+depth.
Segfault occurs before our callback is called, and valgrind points
to nothing interesting (we're not corrupting anything).

So it happens only once every so many hours, but the core file always
points to the same line, a null pointer reference here:
#0 openni_wrapper::ImageYUV422::fillRGB (this=,

width=, height=480,
rgb_buffer=0x7f31f412cdb0
"V^bW_cTcTcW^eX_fTcVbeUadVbeV^bXdYaeYaeVbeVbeYaeYaeYaeYaeX_fX_fUadTcQ]O[^RY`RY`RX]RX]SY^SY^R[ZR[ZRZ^RZ^S[_S[TZaTZaTZ_TZ_SZaSZaS[T]\SZaU\cU]aU]aU]aU]aU\cU\cU]aU]aV^bV^bU]aV^bU\cV]dU\cV]dU\cW^eT"...,
rgb_line_step=) at
/home/intermodalics/ros/pcl/io/src/openni_camera/openni_image_yuv_422.cpp:91

There are only two reasons why yuv_buffer can possibly be null: a bug
in the OpenNI driver code, or a bug in PCL's image copying mechanism.
I'm suspecting it's the last (for now)

It appears that in openni_device.cpp (line 879), the image is copied like this:

image_data->CopyFrom (image_md);

There are two serious issues in this line:

1. the return value is not checked, but the alloc may fail, in which
   case image_data is not a copy but something 'undefined'.
2. CopyFrom makes a 'deep' copy, but only if you access it through
   'WritableData()' , not through 'Data()'. Incidentally, the openni
   wrapper code consistently uses 'Data()'. So the CopyFrom() has no real
   effect, and we keep accessing the original data pointer.

IMHO the real bug is in OpenNI itself, where it should return the copy
of the data in Data() after a CopyFrom(), but it certainly doesn't...

The attached patch for your review addresses both issues. It's hard to
say that this is it, but it's certainly fishy. I haven't been able to
reproduce the segfault in Debug builds, maybe it jumps tomorrow...

Another wild theory is that this CopyFrom is completely unneccesary if
image_md is never updated outside the ImageDataThreadFunction()....and
that the bug is indeed elsewhere.

I'm now also seeing that DepthMetaData::operator[] uses 'Data()' as
well when reading/converting depth images. So in any case, there's
more work to do to figure this out and consistently fix all 3 streams.

Peter

Patch applied here:
#104

Hi,

there are a few glitches with the pkg-config files provided by the PCL modules:

1. The package version should never be encoded into the module filename. For example it should be just pcl_io.pc, not pcl_io-1.7.pc. Otherwise users of libpcl have to hardcode version numbers into their build scripts. For example, I now have
   PKG_CHECK_MODULES([libpcl_io], [pcl_io >= 1.6], [],
   [PKG_CHECK_MODULES([libpcl_io], [pcl_io-1.7 >= 1.7], [],
   [PKG_CHECK_MODULES([libpcl_io], [pcl_io-1.6 >= 1.6], [], .....
   and I have to extend this with each new version. That should just be one line:
   PKG_CHECK_MODULES([libpcl_io], [pcl_io >= 1.6], [], .....

2. pcl_io-1.7.pc and pcl_visualization-1.7.pc list 'openni-dev' as a dependency. At least on Ubuntu, that package does not exist; it should be replaced with 'libopenni2' (or similar?)

In one of my packages I am doing find_package(PCL REQUIRED COMPONENTS COMMON), but I get errors on Linux when doing this. I cannot reproduce this on my Mac for some reason (it might be to do with different CMake versions) or it might be because another package in my catkin workspace calls find_package(PCL) first. You can reproduce this bug with this CMakeLists.txt:

cmake_minimum_required(VERSION 2.8.3)
project(test_pcl)

# find_package(PCL REQUIRED)
find_package(PCL REQUIRED COMPONENTS COMMON)

Invoking mkdir build && cd build && cmake ..; cd .. in the same folder as this CMakeLists.txt will produce the error on my machine:

% cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- looking for PCL_COMMON
-- Could NOT find PCL_COMMON (missing:  PCL_COMMON_LIBRARY PCL_COMMON_INCLUDE_DIR)
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE):
  Could NOT find PCL (missing: PCL_LIBRARIES)
Call Stack (most recent call first):
  /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:252 (_FPHSA_FAILURE_MESSAGE)
  /tmp/pcl_ws/pcl_install/share/pcl-1.7/PCLConfig.cmake:712 (find_package_handle_standard_args)
  CMakeLists.txt:5 (find_package)


-- Configuring incomplete, errors occurred!

I think this is the important line:

  Could NOT find PCL (missing: PCL_LIBRARIES)

So, interestingly if I call find_package(PCL REQUIRED) before the COMMON, like this:

cmake_minimum_required(VERSION 2.8.3)
project(test_pcl)

find_package(PCL REQUIRED)
find_package(PCL REQUIRED COMPONENTS COMMON)

Then it works. Also, obviously, this works:

cmake_minimum_required(VERSION 2.8.3)
project(test_pcl)

find_package(PCL REQUIRED)
# find_package(PCL REQUIRED COMPONENTS COMMON)

I am using pcl-1.7.0rc1, but I don't see anything in pcl-1.7.0rc2 which would address this problem:

pcl-1.7.0rc1...pcl-1.7.0rc2

On Linux:

% cmake --version
cmake version 2.8.7

On Mac:

% cmake --version
cmake version 2.8.11.1

Hi Julius, Here is minimum code for encoder that can reproduce the crash. You can use the one in trunk for decoder. I also attached the snapshot of stack trace: stack_trace_1: 1st time call encoder without crash; stack_trace_1: 2nd time call encoder might cause crash. Sorry for the format, it's the first time I start a ticket on github, I don't know how to keep the indentation better. I don't know how to assign it to jkammerl as well:(

include <pcl/point_cloud.h>

include <pcl/point_types.h>

include <pcl/io/openni_grabber.h>

include <pcl/visualization/cloud_viewer.h>

include <pcl/console/parse.h>

include <pcl/common/time.h>

include <pcl/filters/passthrough.h>

include <pcl/compression/octree_pointcloud_compression.h>

include

include

include <stdio.h>

include

include <stdlib.h>

include "stdio.h"

include

include

include <boost/asio.hpp>

using boost::asio::ip::tcp;

using namespace pcl;
using namespace pcl::io;

using namespace std;

struct EventHelper
{
EventHelper (ostream& outputFile_arg, OctreePointCloudCompression* octreeEncoder_arg,
const std::string& field_name = "z", float min_v = 0, float max_v = 3.0) :
outputFile_ (outputFile_arg), octreeEncoder_ (octreeEncoder_arg)
{
pass_.setFilterFieldName (field_name);
pass_.setFilterLimits (min_v, max_v);
}

void
cloud_cb_ (const pcl::PointCloud<pcl::PointXYZRGBA>::ConstPtr &cloud)
{
    if (!outputFile_.fail ())
    {
        PointCloud<PointXYZRGBA>::Ptr cloud_out (new PointCloud<PointXYZRGBA>);

        // Use a PassThrough filter to clean NaNs and remove data which is not interesting
        pass_.setInputCloud (cloud);
        pass_.filter (*cloud_out);

        octreeEncoder_->encodePointCloud (cloud_out, outputFile_);
    }

}

void
run ()
{
    // create a new grabber for OpenNI devices
    pcl::Grabber* interface = new pcl::OpenNIGrabber ();

    // make callback function from member function
    boost::function<void
    (const pcl::PointCloud<pcl::PointXYZRGBA>::ConstPtr&)> f = boost::bind (&EventHelper::cloud_cb_, this, _1);

    // connect callback function for desired signal. In this case its a point cloud with color values
    boost::signals2::connection c = interface->registerCallback (f);

    // start receiving point clouds
    interface->start ();

    while (!outputFile_.fail ())
    {
        boost::this_thread::sleep(boost::posix_time::seconds(1));
    }

    interface->stop ();
}

pcl::PassThrough<PointXYZRGBA> pass_;
ostream& outputFile_;
OctreePointCloudCompression<PointXYZRGBA>* octreeEncoder_;

};

int
main (int argc, char *argv)
{
OctreePointCloudCompression octreeCoder;

pcl::io::compression_Profiles_e compressionProfile;

double pointResolution;
float octreeResolution;
bool doVoxelGridDownDownSampling;
bool showStatistics;
bool doColorEncoding;
unsigned int iFrameRate;
unsigned int colorBitResolution;

bool bShowInputCloud;

// default values
pointResolution = 0.001;
octreeResolution = 0.01f;
doVoxelGridDownDownSampling = false;
showStatistics = false;
doColorEncoding = true;
iFrameRate = 30;
colorBitResolution = 6;
compressionProfile = pcl::io::LOW_RES_OFFLINE_COMPRESSION_WITH_COLOR;

bShowInputCloud = false;

std::string hostName = "localhost";

std::string field_name = "z";
float min_v = 0.0f, max_v = 3.0f;

if (compressionProfile != MANUAL_CONFIGURATION)
{
  // apply selected compression profile
  // retrieve profile settings
  const pcl::io::configurationProfile_t selectedProfile = pcl::io::compressionProfiles_[compressionProfile];

  // apply profile settings
  pointResolution = selectedProfile.pointResolution;
  octreeResolution = float (selectedProfile.octreeResolution);
  doVoxelGridDownDownSampling = selectedProfile.doVoxelGridDownSampling;
  iFrameRate = selectedProfile.iFrameRate;
  colorBitResolution = selectedProfile.colorBitResolution;
}


octreeCoder = new OctreePointCloudCompression<PointXYZRGBA> (compressionProfile, showStatistics, pointResolution,
                                                            octreeResolution, doVoxelGridDownDownSampling, iFrameRate,
                                                            doColorEncoding, static_cast<unsigned char> (colorBitResolution));

// ENCODING
try
{
    boost::asio::io_service io_service;
    tcp::endpoint endpoint (tcp::v4 (), 6666);
    tcp::acceptor acceptor (io_service, endpoint);

    tcp::iostream socketStream;

    std::cout << "Waiting for connection.." << std::endl;

    acceptor.accept (*socketStream.rdbuf ());

    std::cout << "Connected!" << std::endl;

    EventHelper v (socketStream, octreeCoder, field_name, min_v, max_v);
    v.run ();

    std::cout << "Disconnected!" << std::endl;

    boost::this_thread::sleep(boost::posix_time::seconds(3));

}
catch (std::exception& e)
{
    std::cerr << e.what () << std::endl;
}


delete (octreeCoder);
return (0);

}

Restricting allowed values for filter_limit_min, filter_limit_max parameters to range [-5, 5] is very limiting and makes the filter useless for many use cases, especially for outdoor scenarios where corresponding values are often in the order of tens or hundreds. I don't understand why to introduce such limitations. (Having a nice step size for reconfigure_gui is not a good reason, IMHO.)

I am dealing with octree box search. It seems it could not produce valid result. For test purpose, I deal with only eight points, and I set lower & upper corner values. It is expected it will produce all values from input cloud. Here is my code.

int main(..)
{
pcl::PointCloudpcl::PointXYZ cloud;
cloud.width = 8;
cloud.height = 1;
cloud.is_dense = false;
cloud.points.resize (cloud.width * cloud.height);

float box_point[8][3] = {
{0, 0, 0},
{0, 2, 0},
{0, 1, 1},
{0, 3, 1},
{0, 0, 3},
{0, 2, 3},
{0, 1, 4},
{0, 3, 4}
};

for (size_t i = 0; i < cloud.points.size (); ++i)

{

cloud.points[i].x = box_point[i][0]; 
cloud.points[i].y = box_point[i][1]; 
cloud.points[i].z = box_point[i][2]; 

}

float resolution = 0.1;
pcl::octree::OctreePointCloudSearchpcl::PointXYZ octree (resolution);
octree.setInputCloud (cloud.makeShared());
octree.addPointsFromInputCloud ();

std::vector pointIdxVec;
Eigen::Vector3f min_pt(0,0,0);
Eigen::Vector3f max_pt(0,3,4);

octree.boxSearch(min_pt,max_pt,pointIdxVec);

for (size_t i = 0; i < pointIdxVec.size (); ++i)
std::cout << " " << cloud.points[pointIdxVec[i]].x
<< " " << cloud.points[pointIdxVec[i]].y
<< " " << cloud.points[pointIdxVec[i]].z << std::endl;
cout<<"PointIdxVec size:"<<pointIdxVec.size ()<<endl;
}

My understanding is output would be 8 points, but i got 0 point. ur suggession most appreciable. Thanks in advance.

I'm having this error when building the tools module on Mac OSX 10.8.4:

Linking CXX shared library ../../lib/libpcl_cc_tool_interface.dylib
brew: superenv removed: -Wno-invalid-offsetof -O3
Undefined symbols for architecture x86_64:
  "pcl::cloud_composer::PropertiesModel::copyProperties(pcl::cloud_composer::PropertiesModel const*)", referenced from:
      pcl::cloud_composer::AbstractTool::AbstractTool(pcl::cloud_composer::PropertiesModel*, QObject*) in abstract_tool.cpp.o
  "pcl::cloud_composer::PropertiesModel::PropertiesModel(QObject*)", referenced from:
      pcl::cloud_composer::AbstractTool::AbstractTool(pcl::cloud_composer::PropertiesModel*, QObject*) in abstract_tool.cpp.o
  "pcl::cloud_composer::MergeCloudCommand::MergeCloudCommand(QList<pcl::cloud_composer::CloudComposerItem const*>, QUndoCommand*)", referenced from:
      pcl::cloud_composer::MergeCloudTool::createCommand(QList<pcl::cloud_composer::CloudComposerItem const*>) in moc_abstract_tool.cxx.o
  "pcl::cloud_composer::ModifyItemCommand::ModifyItemCommand(QList<pcl::cloud_composer::CloudComposerItem const*>, QUndoCommand*)", referenced from:
      pcl::cloud_composer::ModifyItemTool::createCommand(QList<pcl::cloud_composer::CloudComposerItem const*>) in moc_abstract_tool.cxx.o
  "pcl::cloud_composer::SplitCloudCommand::SplitCloudCommand(QList<pcl::cloud_composer::CloudComposerItem const*>, QUndoCommand*)", referenced from:
      pcl::cloud_composer::SplitItemTool::createCommand(QList<pcl::cloud_composer::CloudComposerItem const*>) in moc_abstract_tool.cxx.o
  "pcl::cloud_composer::NewItemCloudCommand::NewItemCloudCommand(QList<pcl::cloud_composer::CloudComposerItem const*>, QUndoCommand*)", referenced from:
      pcl::cloud_composer::NewItemTool::createCommand(QList<pcl::cloud_composer::CloudComposerItem const*>) in moc_abstract_tool.cxx.o
ld: symbol(s) not found for architecture x86_64

#85 fixed the bug for Windows and MacOS but apparently that is not enough on Linux with vtk 5.8.

A quote from that thread that might help:

I've looked into the pcl code and into some vtk references and it seems to me that the odd Linux behavior depends on a potentially incomplete implementation of the vtkRendererWindowInteractor's specialization for the X environment (I'm not 100% sure about this though, I don't have enough knowledge of the vtk internals).

What makes me think so is the following:
The vtkRendererWindowInteractor's TerminateApp documentation states that the function "should be overridden by platform dependent subclasses to provide a termination procedure if one is required." The Win32 and MacOS versions apparently are doing so but the X version has those "question marks" in the docs. That leaves me thinking that the implementation might have some issues..

Still, I'm not a vtk nor an X programming expert, I honestly have no idea. If someone else wants to take a look at this it might be better...

Win7 64bit
VS 2010
CUDA 5.5 RC

Compiling error in gpu/octree/src/cuda/octree_builder.cu
Error message: Can not find definition for "device_ptr"
Add #include <device_ptr.h> to solve it.

When saving PointCloud with XYZRGBL points PlyWriter ignores label field and instead somehow adds alpha in header. In output file's body label field is inclouded but some extra field (probably alpha) is there, which yields parsing error (field count in line does not match field count in header.

https://gist.github.com/mitjap/5615779 (cloud.ply, main.cpp, cout)

When linking an application that uses master PCL, I get an error due to pcl_visualization not finding pcl_geometry-1.7 :

Package pcl_geometry-1.7 was not found in the pkg-config search path.
Perhaps you should add the directory containing `pcl_geometry-1.7.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pcl_geometry-1.7', required by 'pcl_visualization', not found

I think this is due to commit 10d42e9 which disable the generation of the pcl_geometry-1.7.pc pkgconfig file.

Since pcl_visualization still depends on pcl_geometry, the pcl_visualization-1.7.pc file contain a reference to the non-existing pcl_geometry-1.7.pc

Dear PCL maintainers,
PCL fails to build from source with the following error on Debian Sid (VTK 5.10):

 [ 80%] Building CXX object examples/segmentation/CMakeFiles/pcl_example_supervoxels.dir/example_supervoxels.cpp.o
 cd /home/moulard/debian-science/pcl/obj-x86_64-linux-gnu/examples/segmentation && /usr/lib/ccache/c++   -DEIGEN_USE_NEW_STDVECTOR -DEIGEN_YES_I_KNOW_SPARSE_MODULE_IS_NOT_STABLE_YET -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -Dqh_QHpointer -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2  -pthread -fopenmp  -Wno-deprecated -O2 -g -DNDEBUG -isystem /usr/include/eigen3 -isystem /usr/include/ni -isystem /usr/include/qt4 -isystem /usr/include/qt4/QtGui -isystem /usr/include/qt4/QtCore -I/home/moulard/debian-science/pcl/obj-x86_64-linux-gnu/include -I/home/moulard/debian-science/pcl/common/include -I/home/moulard/debian-science/pcl/io/include -I/home/moulard/debian-science/pcl/features/include -I/home/moulard/debian-science/pcl/search/include -I/home/moulard/debian-science/pcl/kdtree/include -I/home/moulard/debian-science/pcl/octree/include -I/home/moulard/debian-science/pcl/filters/include -I/home/moulard/debian-science/pcl/keypoints/include -I/home/moulard/debian-science/pcl/segmentation/include -I/home/moulard/debian-science/pcl/sample_consensus/include -I/home/moulard/debian-science/pcl/outofcore/include -I/home/moulard/debian-science/pcl/geometry/include -I/home/moulard/debian-science/pcl/visualization/include -I/usr/include/vtk-5.8    -DBOOST_DISABLE_ASSERTS -DEIGEN_NO_DEBUG -o CMakeFiles/pcl_example_supervoxels.dir/example_supervoxels.cpp.o -c /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp
 /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp: In function 'void addSupervoxelConnectionsToViewer(PointT&, PointCloudT&, std::string, boost::shared_ptr<pcl::visualization::PCLVisualizer>&)':
 /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:472:11: error: invalid use of incomplete type 'class vtkPolyLine'
    polyLine->GetPointIds  ()->SetNumberOfIds(points->GetNumberOfPoints ());
            ^
 In file included from /usr/include/vtk-5.8/vtkPolyDataAlgorithm.h:38:0,
                  from /usr/include/vtk-5.8/vtkVectorText.h:35,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/impl/pcl_visualizer.hpp:44,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/pcl_visualizer.h:2004,
                  from /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:7:
 /usr/include/vtk-5.8/vtkPolyData.h:65:7: error: forward declaration of 'class vtkPolyLine'
  class vtkPolyLine;
        ^
 /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:474:13: error: invalid use of incomplete type 'class vtkPolyLine'
      polyLine->GetPointIds ()->SetId (i,i);
              ^
 In file included from /usr/include/vtk-5.8/vtkPolyDataAlgorithm.h:38:0,
                  from /usr/include/vtk-5.8/vtkVectorText.h:35,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/impl/pcl_visualizer.hpp:44,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/pcl_visualizer.h:2004,
                  from /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:7:
 /usr/include/vtk-5.8/vtkPolyData.h:65:7: error: forward declaration of 'class vtkPolyLine'
  class vtkPolyLine;
        ^
 /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:475:34: error: invalid user-defined conversion from 'vtkSmartPointer<vtkPolyLine>' to 'int' [-fpermissive]
    cells->InsertNextCell (polyLine);
                                   ^
 In file included from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/point_cloud_geometry_handlers.h:48:0,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/point_cloud_handlers.h:41,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/common/actor_map.h:40,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/pcl_visualizer.h:47,
                  from /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:7:
 /usr/include/vtk-5.8/vtkSmartPointer.h:73:3: note: candidate is: vtkSmartPointer<T>::operator T*() const [with T = vtkPolyLine] <near match>
    operator T* () const
    ^
 /usr/include/vtk-5.8/vtkSmartPointer.h:73:3: note:   no known conversion for implicit 'this' parameter from 'vtkPolyLine*' to 'int'
 In file included from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/point_cloud_geometry_handlers.h:48:0,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/point_cloud_handlers.h:41,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/common/actor_map.h:40,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/pcl_visualizer.h:47,
                  from /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:7:
 /usr/include/vtk-5.8/vtkSmartPointer.h: In instantiation of 'static vtkSmartPointer<T> vtkSmartPointer<T>::New() [with T = vtkPolyLine]':
 /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:459:73:   required from here
 /usr/include/vtk-5.8/vtkSmartPointer.h:113:38: error: incomplete type 'vtkPolyLine' used in nested name specifier
      return vtkSmartPointer<T>(T::New(), NoReference());
                                  ^
 In file included from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/point_cloud_geometry_handlers.h:48:0,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/point_cloud_handlers.h:41,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/common/actor_map.h:40,
                  from /home/moulard/debian-science/pcl/visualization/include/pcl/visualization/pcl_visualizer.h:47,
                  from /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:7:
 /usr/include/vtk-5.8/vtkSmartPointer.h: In instantiation of 'T* vtkSmartPointer<T>::operator->() const [with T = vtkPolyLine]':
 /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:472:11:   required from here
 /usr/include/vtk-5.8/vtkSmartPointer.h:90:40: error: invalid static_cast from type 'vtkObjectBase* const' to type 'vtkPolyLine*'
      return static_cast<T*>(this->Object);
                                         ^
 /usr/include/vtk-5.8/vtkSmartPointer.h: In instantiation of 'vtkSmartPointer<T>::operator T*() const [with T = vtkPolyLine]':
 /home/moulard/debian-science/pcl/examples/segmentation/example_supervoxels.cpp:475:34:   required from here
 /usr/include/vtk-5.8/vtkSmartPointer.h:75:40: error: invalid static_cast from type 'vtkObjectBase* const' to type 'vtkPolyLine*'
      return static_cast<T*>(this->Object);
                                         ^
 make[4]: *** [examples/segmentation/CMakeFiles/pcl_example_supervoxels.dir/example_supervoxels.cpp.o] Error 1
 make[4]: Leaving directory `/home/moulard/debian-science/pcl/obj-x86_64-linux-gnu'
 make[3]: *** [examples/segmentation/CMakeFiles/pcl_example_supervoxels.dir/all] Error 2
 make[3]: Leaving directory `/home/moulard/debian-science/pcl/obj-x86_64-linux-gnu'
 make[2]: *** [all] Error 2
 make[2]: Leaving directory `/home/moulard/debian-science/pcl/obj-x86_64-linux-gnu'
 dh_auto_build: make -j1 returned exit code 2
 make[1]: *** [override_dh_auto_build] Error 2
 make[1]: Leaving directory `/home/moulard/debian-science/pcl'
 make: *** [build] Error 2

Apparently, the header providing the vtkPolyLine class is not included.

According to the travis build farm, the following test fail

The following tests FAILED:
6 - test_non_linear (Failed)
25 - feature_normal_estimation (Failed)
26 - feature_pfh_estimation (Failed)
42 - filters_sampling (Failed)
Errors while running CTest
make: *** [test] Error 8

see also https://travis-ci.org/PointCloudLibrary/pcl/jobs/7680719

Hi all.

I noticed that, while running, ESFEstimation has an unpredictable behavior eventually causing a segmentation fault due to illegal access of the vector h_d1 at line 241 of the file features/impl/esf.hpp

The index used to access the h_d1 vector is computed using the contents and the maximum value of the d1v vector.

Unfortunately, the d1v vector is never initialized but its memory occupancy is based only on a reserve operation that is performed on line 63.
After this operation the vector is never filled with values and, on lines 222-234 its maximum value is extracted. Sadly, this value is the content of the raw memory where the vector is placed.

This does not cause a segmentation fault right away but it crashes the program when the "random" value is used to index the h_d1 vector.

BTW, I have also noticed that the d1v vector could have been filled on line 140 but the code is commented out and, looking at the history of the file, that bit of code has never been uncommented.

Moreover I didn't find any unit test for this class, that would have pointed out this bug earlier.

VTK 6 is out. I'd like to update it in Fedora rawhide, but pcl does not compile against it.

@sdmiller, @jspricke, @wjwwood:

When using PCL 1.7 with ROS Hydro I experienced something similar to a bug with the new PCLHeader struct.

With previous ROS, I could grab Kinect pointclouds with this kind of callback (with PointCloudT being a pcl::PointCloud of templated type):

void pointcloudT_cb(const PointCloudT::ConstPtr& callback_cloud)
{
ROS_INFO("PointCloudT header:");
ROS_INFO_STREAM(callback_cloud->header);
}

while now, if I use that code, I obtain empty headers (of type PCLHeader):
[ INFO] [1376399822.191852015]: PointCloudT header:
[ INFO] [1376399822.191942196]: seq: 0 stamp: 0 frame_id:

One option which works is instead:

void pointcloud2_cb(const pcl::PointCloud2& callback_cloud)
{
ROS_INFO("PointCloud2 header:");
ROS_INFO_STREAM(callback_cloud.header);
}

which produces:
[ INFO] [1376399822.191382507]: PointCloud2 header:
[ INFO] [1376399822.191509950]: seq: 3596 stamp: 1315582148454853 frame_id: /openni_rgb_optical_frame

Is it possible to grab pointclouds with callbacks waiting for PointCloudT and this is a bug or is it normal that with the new changes we can only use callbacks waiting for binary messages (PCLPointCloud2 / PointCloud2)?

I report here a link to a minimal ROS package which uses these callbacks.
Both callbacks correctly output headers in ROS Fuerte while only the one using the PointCloud2 type outputs a valid header in ROS Hydro:
https://dl.dropboxusercontent.com/u/9455593/test_callback_Fuerte.zip
https://dl.dropboxusercontent.com/u/9455593/test_callback_Hydro.zip

Cheers,
Matteo

I am looking at the source code for pcl_visualizer.cpp (located in pcl/visualization/src) and in the function renderViewTesselatedSphere there is this snippet of code:

//rotate model so it looks the same as if we would look from the new position 
vtkSmartPointer<vtkMatrix4x4> view_trans_inverted = vtkSmartPointer<vtkMatrix4x4>::New (); 
vtkMatrix4x4::Invert (cam->GetViewTransformMatrix (), view_trans_inverted); 
vtkSmartPointer<vtkTransform> trans_rot_pose =  vtkSmartPointer<vtkTransform>::New (); 
trans_rot_pose->Identity (); 
trans_rot_pose->Concatenate (view_trans_inverted); 
trans_rot_pose->Concatenate (cam_tmp->GetViewTransformMatrix ());
vtkSmartPointer<vtkTransformFilter> trans_rot_pose_filter = vtkSmartPointer<vtkTransformFilter>::New (); 
trans_rot_pose_filter->SetTransform (trans_rot_pose); 
trans_rot_pose_filter->SetInputConnection (trans_filter_scale->GetOutputPort ()); 

//translate model so we can place camera at (0,0,0) 
vtkSmartPointer<vtkTransform> translation = vtkSmartPointer<vtkTransform>::New (); 
translation->Translate (first_cam_pos[0] * -1, first_cam_pos[1] * -1, first_cam_pos[2] * -1); 
vtkSmartPointer<vtkTransformFilter> translation_filter = vtkSmartPointer<vtkTransformFilter>::New (); 
translation_filter->SetTransform (translation); 
translation_filter->SetInputConnection (trans_rot_pose_filter->GetOutputPort ()); 

//modify camera 
cam_tmp->SetPosition (0, 0, 0); 
cam_tmp->SetFocalPoint (first_cam_pos[0] * -1, first_cam_pos[1] * -1, first_cam_pos[2] * -1); 
cam_tmp->Modified (); ```

Which is supposed to translate and rotate the model so that it looks the same as if the camera were at the position described, but now we can put the camera at the origin.

However the following two lines:
trans_rot_pose->Concatenate (view_trans_inverted);
trans_rot_pose->Concatenate (cam_tmp->GetViewTransformMatrix ());

show that it is applying the inverse of the view matrix followed by the view matrix to the mesh which to me looks like a bug as this is not rotating it at all (correct?) as it does apply the inverse rotation but then multiplies it by that inverse with the net effect of nothing?

Am I correct in thinking this is a bug, or have I misunderstood.

Simulation depends on libopencv but fails to check.

The CMakeFile.txt (https://github.com/PointCloudLibrary/pcl/blob/master/apps/point_cloud_editor/CMakeLists.txt) for the app contains on line 118 sets extra compiler options:

 SET(CMAKE_CXX_FLAGS "-Wno-invalid-offsetof -Wno-extra-tokens")

With Visual Studio 2012 this results in a D8021 compiler error (invalid numeric argument).

Removing that line and generating new project files solves that issue but I'm unsure whether there'd be sideeffects resulting from this. I couldn't find any info on those flags so I'm not sure what the intention here was.

If I pass -DBUILD_io:BOOL=OFF to cmake, pcl will fail to build when linking pcl_surface:

[ 59%] Built target pcl_segmentation
Linking CXX shared library ../lib/libpcl_surface.dylib
ld: library not found for -lpcl_io
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libpcl_surface.1.7.0.dylib] Error 1
make[1]: *** [surface/CMakeFiles/pcl_surface.dir/all] Error 2
make: *** [all] Error 2

This code assumes pcl_io is always available:

https://github.com/PointCloudLibrary/pcl/blob/master/surface/CMakeLists.txt#L157

Should pcl_surface be completely disabled is pcl_io is disabled or should this code just check and link against pcl_io only if it is being built?

I get undefined reference to the timestamp type's > operator, within the cloud types' += operator. Probably some old ROS stuff left in the codebase.

Error message

Linking CXX executable concatenate_clouds
CMakeFiles/concatenate_clouds.dir/concatenate_clouds.cpp.o: In function `pcl::PointCloud::operator+=(pcl::PointCloud const&)':
concatenate_clouds.cpp:(.text._ZN3pcl10PointCloudINS_8PointXYZEEpLERKS2_[pcl::PointCloud::operator+=(pcl::PointCloud const&)]+0x28): undefined reference to `ros::TimeBase::operator>(ros::Time const&) const'

Relevant code
line 67:doc/tutorials/content/sources/concatenate_clouds/concatenate_clouds.cpp

line 250: common/include/pcl/point_cloud.h

I have been trying to build the recent experimental code. It ends with following error:

CMakeFiles/pcl_organized_pcd_to_png.dir/organized_pcd_to_png.cpp.o: In function pcl::io::savePNGFile(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, pcl::PointCloud<pcl::PointXYZL> const&)': organized_pcd_to_png.cpp:(.text+0x2b0): undefined reference topcl::io::saveShortPNGFile(std::basic_string<char, std::char_traits, std::allocator > const&, unsigned short const_, int, int, int)'
CMakeFiles/pcl_organized_pcd_to_png.dir/organized_pcd_to_png.cpp.o: In function pcl::io::saveRgbPNGFile(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned char const_, int, int)': organized_pcd_to_png.cpp:(.text+0x147): undefined reference to pcl::io::saveCharPNGFile(std::basic_string<char, std::char_traits, std::allocator > const&, unsigned char const*, int, int, int)'
CMakeFiles/pcl_organized_pcd_to_png.dir/organized_pcd_to_png.cpp.o: In functionpcl::io::savePNGFile(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, pcl::PointCloud<unsigned char> const&)': organized_pcd_to_png.cpp:(.text+0x161): undefined reference to pcl::io::saveCharPNGFile(std::basic_string<char, std::char_traits, std::allocator > const&, unsigned char const*, int, int, int)'
CMakeFiles/pcl_organized_pcd_to_png.dir/organized_pcd_to_png.cpp.o: In functionpcl::io::savePNGFile(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, pcl::PointCloud<unsigned short> const&)': organized_pcd_to_png.cpp:(.text+0x181): undefined reference to pcl::io::saveShortPNGFile(std::basic_string<char, std::char_traits, std::allocator > const&, unsigned short const*, int, int, int)'
CMakeFiles/pcl_organized_pcd_to_png.dir/organized_pcd_to_png.cpp.o: In functionvoid pcl::io::savePNGFilepcl::RGB(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, pcl::PointCloudpcl::RGB const&)': organized_pcd_to_png.cpp:(.text._ZN3pcl2io11savePNGFileINS_3RGBEEEvRKSsRKNS_10PointCloudIT_EE[void pcl::io::savePNGFilepcl::RGB(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, pcl::PointCloudpcl::RGB const&)]+0xc1): undefined reference to pcl::io::saveCharPNGFile(std::basic_string<char, std::char_traits, std::allocator > const&, unsigned char const_, int, int, int)'
collect2: ld returned 1 exit status
make[2]: *_* [bin/pcl_organized_pcd_to_png] Error 1
make[1]: *** [tools/CMakeFiles/pcl_organized_pcd_to_png.dir/all] Error 2

Does anyone know how to solve it?

Hi,

I tried using the PCD Video player today and when I start it, it segfaults immediately. I traced the problem to line 281 in pcl_visualizer.cpp. After commenting the vtkAreaPicker, things worked.

The problem is that in the other setupInteractor (...) method, these 2 lines were already commented. This smells like some inconsistent hack.

@nizar-sallem, can you have a look?

Thanks,
Alex

The OpenNI grabber only has event-based callbacks available; this means that if the grabber is used to feed a processing chain which can't always keep up with it, the program will crash after a short time. Would it be possible to expose the underlying OpenNI loop, so an API user can write a data source with a while loop that controls when data is grabbed off the device? (It may be that frame dropping is the preferable solution in this case, rather than building up a buffer of outdated readings.)

Hi,
I would like to reopen issue 969 (http://dev.pointclouds.org/issues/969) regarding the
choice of a color interpolation method for PolygonMesh (not flat as default).

The solution proposed by Alexandru to use

setShapeRenderingProperties(pcl::visualization::PCL_VISUALIZER_SHADING, pcl::visualization::PCL_VISUALIZER_SHADING_PHONG, "my_mesh_id");

does not work with a PolygonMesh.

The ID of a PolygonMesh is not added to the attribute shape_actor_map_ of PCLVisualizer when addPolygonMesh is called, and thus when calling setShapeRenderingProperties the function quit with error message

"[setShapeRenderingProperties] Could not find any shape with id <%s>" in pcl/visualization/src/pcl_visualizer.cpp line 1435.

Is there a reason why the id of a PolygonMesh is added to the attribute cloud_actor_map_ and not shape_actor_map_ ?
(cf. addPolygonMesh in pcl/visualization/include/pcl/visualization/impl/pcl_visualizer.hpp line 1514)

Thanks,
Romain Brégier

Looks like pcl_context_item.h relies on vtkContextItem, which doesn't seem to exist in vtk-5.4. I suppose our official documentation says ">5.4" but it does seem a shame.

It appears that a change introduced for pcl-1.7.0rc2 breaks downstream packages by not installing required headers. See:

7014b27#L1L59

Hello,
Today I build the trunk. When I try to run pcl_kinfu_largeScale, I didn't found the executable in the pcl-trunk/build/bin folder.
Could anybody help me with this?