ddimarco's profile - activity

I have no plans to port the object recording packages to Groovy in the near future (due to lack of time).

Probably you already know the tutorials at http://www.ros.org/wiki/cram_core/Tutorials. There are some more advanced examples by the authors of CRAM in their GitHub repository, see e.g. https://github.com/cram-code/cram_pr2.git.

I would start out by writing some simple CRAM plans without KnowRob at first to get used to the system. Later you can extend these to make use of KnowRob queries.

To make the include files from the project show up in QtCreator, you can just add them as sources for your executable (in your example, add ${QT_MOC} to the rosbuild_add_executable line, or create a new GLOB collecting all the projects header files). This won't mess up the build process, I do that quite often.

However, I do not know whether there is a way to add system headers or other file types to the QtCreator project view.

I cannot reproduce that problem, the stack does not depend on ros-fuerte-perception-pcl-addons. Please open a new issue and describe your problem in detail.

You are basically right on how the detection works. The re_kinect_object_detector detection uses SURF features from the camera image. It also compares the depth information from the Kinect for the feature points with the model to discard implausible correspondences. You can find a (rather short) description here. Note that this means that a badly aligned model will give bad detection results.

Our intent was to provide a fast and computationally cheap way to create object models. So as you probably noticed, the detection rate depends quite heavily on object properties like the texture of the object and the glossyness of the surface. We had good detection rate on a range of ~0.7m to 1.2m.

You might want to try the detection with the model for the game that comes with Kinect cameras (the model has the id "videogames.kinectadventures" in the DB).

Also note that the object recording and -detection is somewhat a side project of RoboEarth stuff. We recently restructured the wiki page to reflect that.

Oops, sorry. We recently moved the wiki page and forgot to adjust the install instruction. Try it again with rosinstall ~/ros /opt/ros/fuerte 'http://www.ros.org/wiki/roboearth_stack?action=AttachFile&do=get&target=roboearth.rosinstall'

Are you sure you are using the instructions for ROS Fuerte from http://www.ros.org/wiki/roboearth_stack#Installation ?

The packages listen on the /camera/depth_registered/points, /camera/depth_registered/image and /camera/depth_registered/camera_info. According to this answer, the openni driver publishes the not-registered point clouds under said topics.

As a first trial, I would try remapping the /camera/depth_registered/image and /camera/depth_registered/camera_info topics to camera/rgb/camera_info and camera/depth/image, respectively, and see what happens.

The error message stating that rosbuild.cmake could not be found occurs when the ROS environment variables are not set (i.e. when setup.bash/zsh/whatever is not sourced).

So if you start qtcreator from your terminal where the ROS variables are set, it should work as expected.

If you look closely, you'll notice that you are using http instead of https in the URL. Try $ svn info https://ipvs.informatik.uni-stuttgart.de/roboearth/repos/public/tags/latest.

ROS Electric is not officially supported. If you really can't update to Fuerte, try Revision r2047:

roscd roboearth
svn up -r2047

As I said, the software only uses 2D image features. You'll need to use another package if you require to detect single-colored objects.

Ok, it is hard to figure out the problem like this. Well textured objects like the one at http://api.roboearth.org/data/objects/beverage/icetea/preview.png should work very well. So all advice I can offer is to record an object model for something like that and try it again.

DEBUG_VIS does not really change anything, it is just there to help you find problems. Please note that we use 2D features only, so maybe the coke bottle does not provide enough features. What happens if you try it with another, more textured object?

Make sure that the camera is ~60 cm away from the object, from your screenshot it looks a bit too close. To get some visual debug information, you can uncomment the "#define DEBUG_VIS" line in re_kinect_object_detector/src/recognitionmodel.h. This will show you the images from the model, the SURF features and possible matches from the model as lines.

It admittedly takes a bit of experience to find a working setup. Take a look at these hints.

Seeing your picture, I suggest to make sure that the marker pattern is completely planar. If all fails, you can adjust the 'marker_dist_threshold' parameter as described in the page linked above.

There are 2 ROS parameters you might want to adjust:

• /marker_spacing is the distance (in m) between the center points of 2 adjacent markers.
• /marker_size is the side length (in mm) of one marker.

As a first trial, I would try to scale up the whole marker pattern to a size meeting your requirements and then adjust these parameters.

Please note that what you are using there is basically a 2D-feature based recognition algorithm. The depth information from the Kinect is just used for filtering out implausibly detected object poses. So you will get best results with a well-textured object. A good first test is to use the video game package that usually comes with a Kinect.

With that said, I really wonder about the problem with the depth registration here. It really should not make a difference for receiving a point cloud. Can you check with RViz if there is a point cloud published when you have depth registration enabled?

If you did not see them already, maybe also take a look at these hints.

Please try it again now :)

Sorry about that, please run "svn up" and try it again.

We need some more time to get it fixed properly, unfortunately. I will update the answer as soon as we are done. In the meantime, I reverted it to the previous version, so that it works at least in electric.

Sorry, this was my mistake, I guess I was a bit careless with committing. As I am currently not at my office, I will fix this next week when I am back.

We recently upgraded it to be compatible to ROS Fuerte, so you might try it again.

Please try it again. It should compile under ROS Fuerte now.

The detected pose of the object is published as a tf transformation named "OBJECTCLASS.OBJECTNAME", as written on this page.