rreid's profile - activity

If you're following the tutorial then you'll be using: roslaunch vslam_system stereo_vslam.launch

If you look at the stereo_vslam.launch file, it has:

<node name="stereo_vslam_node"...

This is launching the binary compiled from the source vslam_system/src/nodes/stereo_vslam_node.cpp. If you check that file, you'll see that it only subscribes to these topics:

// Synchronize inputs
l_image_sub_.subscribe(it_, "left/image_rect", 1);
l_info_sub_ .subscribe(nh_, "left/camera_info", 1);
r_image_sub_.subscribe(it_, "right/image_rect", 1);
r_info_sub_ .subscribe(nh_, "right/camera_info", 1);
sync_.connectInput(l_image_sub_, l_info_sub_, r_image_sub_, r_info_sub_);

So to answer your question, there's no tf inputs needed. You may be able to get it to broadcast odometry data as tf's if you provide the base_footprint transform. However that code (in the latest svn) is disabled with an if (0).

The intrinsic calibration for the Kinect is already available in the Openni driver. This answer describes where to find it.

You'll want to use the 'camera/rgb/camera_info' topic, which gives a sensor_msgs/CameraInfo message.

Hi Koen, for the extrinsic calibration of multiple cameras it is considerably more difficult to generate feature correspondences and initial poses for the optimisation.

In the stereo-vision case multiple views of a checkerboard are ideal: we can make assumptions about the relative views eg. the cameras are roughly pointing in the same direction and share the same "up". After extracting the checkerboard corners it's easy to assume the feature correspondences. Given the checkerboard size we can also estimate the relative camera pose.

You'll probably need to calibrate each cameras' intrinsics separately, and then investigate either 1) using some sort of fiduciary marker, or 2) a rich feature descriptor (eg SURF) and a lot of random objects in your scene to generate the feature correspondences for bundle adjustment. This really becomes a full bundle adjustment problem. Most of the code you'll need is in this stack.

If you have a small separation between your cameras you might get away with a checkerboard pattern with one corner modified so you can uniquely identify "up" on the board. You could then generate initial relative camera pose estimates and feature correspondences from that.

Edit: The camera_pose_calibration package recently appeared on the ROS wiki. It looks like what you're after.

This is a duplicate of this problem and answer.

The same problem occurs doing the tutorial on Diamondback and the bag file as of 22nd March. (md5sum is f5aece448b7af00a38a993eb71400806)

To check:

rosbag check vslam_tutorial.bag
The following migrations need to occur:
 * From: sensor_msgs/CameraInfo [1b5cf7f984c229b6141ceb3a955aa18f]
   To:   sensor_msgs/CameraInfo [c9a58c1b0b154e0e6da7578cb991d214]

To fix:

rosbag fix vslam_tutorial.bag vslam_tutorial_diamondback.bag

To play the modified bag:

rosbag play --clock vslam_tutorial_diamondback.bag

1. ASUS are supposed to be releasing the Xtion PRO Developer Kit, an Primesense SDK based device. It may be easier to obtain than the Primesense SDK. Details are sketchy for a Q2 2011 release. Note that some photos show it without the color sensor (ie. depth only).

2. Have you tried playing with the RGBD-6D-SLAM entry in the recent OpenNI competition?

3. Given bandwidth limitations, you may want to decimate the point cloud. This tutorial may be a good starting point.