RGB-D Odometry ignores "publish_tf" flag?

[g.bartoli]

H Mathieu,
I'm testing the Extended Kalman Filter integration between visual and wheel odometry.

Since EKF publishes the filtered odometry and the corrected "odom --> base_link" transformation, I thought it would be a good idea to disable the same publishing from the two odometry sources to not interfere with EKF.

I already disabled the TF from my motor driver and I verified that now it only publishes nav_msgs::Odometry messages. I tried to do the same with rtabmap rgbd_odometry setting "publish_tf" to false in the launch file, but it seems to ignore it and still publishes "odom --> base_link" together with odometry.

I verified this with RViz (TF coordinates are moving while teleoperating) and with rqt_graph (notice the interaction between rgbd_odometry and tf):



I also took a look at TF frames and in fact the "odom --> base_link" transformation is actually published by rgbd_odometry, confirming this:



Am I doing something wrong?

Many thanks,
Guido

UPDATE: Sorry, maybe I found the problem, but I'm still not sure if it is right or not. I set "frame_id" to "camera_link" instead of "robot_link" and now "odom --> base_link" is published by EKF and "base_link --> camera_link" by rgbd_odometry (figure below). I think it is still wrong, since rgbd_odometry should not publish TF with "publish_tf" set to false. If I want to integrate the visual odometry node with the full robot setup with rtabmap SLAM, what frame do I have to set for "frame_id" in rgbd_odometry?

[matlabbe]

Hi,

Make sure you set the parameter like this:

<param name="publish_tf" type="bool" value="false"/>

and not

<param name="publish_tf" type="string" value="false"/>

Type "string" should be used only for RTAB-Map's parameters (from the standalone library).

In the code, it is here where the TF is published by the odometry. You should have something like this:


cheers

[matlabbe]

Just saw your update after replying...

The frame_id should be "base_link", the same as your wheel odometry.

[g.bartoli]

Thanks Mathieu, it was exactly that, I used "string" instead of "bool", it was my fault! :)

One more question: currently I'm using a "base_link --> camera_link" static transform (the Asus Xtion is 27 cm above wheel axis), but if I set frame_id to "base_link", how can rgbd_odometry know that the visual data is relative to the camera frame instead of the robot frame? Does this introduces a translation error in the odometry? In your rgbd_mapping.launch file you used "camera_link", but I suppose that was for hand-held Kinect mapping without robot, right?

[matlabbe]

Hi Guido,

rgbd_odometry will generate odometry accordingly to frame_id parameter, which doesn't need to be the camera frame. The camera should be fixed on the robot though (not on a pan-tilt), so that the transform between base_link and the camera_rgb_optical_frame remains always fixed.
For example, if frame_id=base_link, odometry will be in base_link frame: base_link->camera_link->camera_rgb_frame->camera_rgb_optical_frame. Another example is the Stereo Outdoor Tutorial, where the camera is about 1 meter (with an angle) over base_footprint (frame_id used by odometry).

cheers

[g.bartoli]

Perfect, I understood.
Thank you Mathieu, you're always very kind to explain! :)

Guido