0
$\begingroup$

Rosanswers logo

Hi,

we are trying to scan and recognize 3D objects with the Kinect and RoboEarth. For the model scanning we followed the video tutorial from RoboEart, resp. the guide from the wiki which results in very bad models. The image below shows a full 3D scan. image badly aligned scans http://s14.directupload.net/images/130218/eyksptkz.png

You can see that the different scans are very bad aligned and we just cant figure out why. The Kinect cameras (both rgb and ir) are calibrated with the ros calibration tool. When starting the re_object_recorder there comes an error saying that the depth_registration of openni is not activated (Depth registration is disabled in the openni driver. This will probably lead to badly aligned pointclouds.). After some reading I suppose this error is deprecated, because depth_registration is turned on automatically when openni_launch finds a configuration file for the cameras (according to the documentation). Setting depth_registration to true will result in empty depth_images anyway (another bug within openni). Another strange issue with the scanning is the reprojection of the recognized marker: image wrong marker reprojection http://s14.directupload.net/images/130218/95irgogb.png

But maybe this is just because the marker are backprojected onto the rectified data ...?

I just cant image whats going wrong here. Maker patterns are printed correctly, the setup is exactly as proposed in the tutorial and the Kinect is calibrated. By using markers for pose estimation of the Kinect, the error of the scan alignment should not even be visible.

System:

  • ros fuerte Ubuntu 12.4 LTE
  • OpenNI-Bin-Dev-Linux-x86-v1.5.4.0 (compiled from source)
  • Sensor-Bin-Linux-x86-v5.1.2.1 (compiled from source)
  • stacks/roboearth -r2235 ipvs.informatik.uni-stuttgart.de/roboearth/repos/public/ -
  • openni_launch hg a6468e10ba4c bitbucket.org/lubosz/openni_launch
  • openni_camera hg a195c7630f52 bitbucket.org/lubosz/openni_camera

Originally posted by stfn on ROS Answers with karma: 287 on 2013-02-18

Post score: 2


Original comments

Comment by alexiip on 2013-02-19:
I am having the same issue. If I set depth_registration to false I can try to build the model but the result is similar to yours. If I set it to true I am getting no point cloud found inside the bounding box above the marker pattern. warning and the points do not come through.

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

I tried the remapping but it didn't help me neither. So I tested a few combination of the packages.

First I completly removed everything installed from source, so just ros-fuerte-openni-launch and ros-fuerte-openni-camera and their dependencies as they come from apt-get.

  • Xtion: Works very well. The depth_registration works as expected. If you turn it off, no dept_registered topics are published. If you turn it on, the point clouds are aligned and the scanning works fine. Both with and without camera calibration.
  • Kinect: Confusing. If depth_registration is turned off, the corresponding topics are published anyway and are not at all depth_registered with the standard calibration files. With our calibration files the registered pointcloud looks ok in rviz. In both cases the scanned pointclouds do not align. When turning depth_registration on, no point clouds (at all!) are published (with/without custom calibration files).

Then I installed Openni and SensorKinect from source (OpenNI-Bin-Dev-Linux-x86-v1.5.4.0, Sensor-Bin-Linux-x86-v5.1.2.1) without touching any ros package.

  • Kinect: works, but confusing. If depth_registration is turned off, same as before. But when turning it on, the topics are published. With custom calibration files the scans do not align, without they do.
  • Xtion: "No devices connected.... waiting for devices to be connected"

So whatever configuration, it's a pain in the ass. One could continue to check different unstable versions of openni-camera and openni-launch against different OpennNi/SensorKinect versions. Maybe there is a working combination for both the Kinect and Xtion, or have a look into the groovy packages, but I'll stop here.

However, this wasn't a RoboEarth issue!


Originally posted by stfn with karma: 287 on 2013-02-20

This answer was ACCEPTED on the original site

Post score: 3


Original comments

Comment by stfn on 2013-02-20:
Some related topics: http://answers.ros.org/question/53706 http://answers.ros.org/question/46163 http://answers.ros.org/question/36997 http://answers.ros.org/question/53779/ http://answers.ros.org/question/55805/

$\endgroup$
0
$\begingroup$

Rosanswers logo

Hi,

We are currently using the Kinect in a similar application. Lately we experienced similar issues as the ones described here, which seems to be related to latest release of the openni_camera package in fuerte. The openni_camera package combined with depth registration set to true resulted in point clouds with NaN values. Putting depth registration to false makes that RGB and depth are not in the same coordinate frame (see openni documentation). Since the centers of the markers have an offset, I can imagine that depth registration is still disabled (or working incorrectly). Since these markers are the reference to map the pointclouds into a common coordinate frame, this probably results in the weird object model.

One of our students working with the kinect bumped into this issues and found a solution that work (at least at his computer). He has posed his solution on answers.ros.org/question/53706/registered-depth-image-is-black/ by Anto1398. Another option could be to explicitly putting depth registration to true: roslaunch openni_launch openni_launch depth_registration:=true

I hope this info helps to solve your problem.


Originally posted by Hamer with karma: 21 on 2013-02-20

This answer was NOT ACCEPTED on the original site

Post score: 1


Original comments

Comment by bit-pirate on 2013-02-27:
I give you an upvote to let you post links soon! :-)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.