How to make rtabmap use both visual odometer and wheel odometer?

[willzoe]

When I only use the visual odometer for mapping, I found that the odometer will be lost when the robot bumps over the ground cracks or encounters a scene with a lack of texture.

I would like to know if it is possible to use both the wheel odometer and visual odometer to reduce the occurrence of lost odometers in the above scenario.

[matlabbe]

Yes, this could be done with robot_localization package. You may do the fusion of wheel odometry twist with visual odometry twist. It could be similar to https://github.com/introlab/rtabmap_ros/blob/master/launch/tests/sensor_fusion.launch but fusing two odometry topics instead of one odom and one imu.

I think publish_null_when_lost would need to be false to not affect robot_localization when visual odometry is lost, not sure why it was true in this example. Under rtabmap node, odom_frame_id would be set (to odom) to use fixed covariance (odom_tf_angular_variance and odom_tf_linear_variance) as robot_localization's covariance output may not be suitable for graph optimization inside RTAB-Map.

crossref: https://answers.ros.org/question/347928/how-to-make-rtabmap-use-both-visual-odometer-and-wheel-odometer/

[willzoe]

I guess it may be because publish_tf is false, no matter whether publish_null_when_lost is true or false, it will not work.

Now I can merge the odom published by turtlebot2 and the odom published by stereo_odometry. Now I still have the following confusion, I hope to get your help:

1. I see that guess_from_tf is true in sensor_fusion.launch, but I did not find the description of this parameter in the rtabmap_ros wiki. What is its role and default value?

2. When I use rtabmap_ros/stereo_odometry nodelet, the terminal only outputs the following information without continuous odom information output:

... logging to /home/nvidia/.ros/log/28fd7ac0-8ea6-11ea-84e8-00044b8ceeae/roslaunch-tegra-ubuntu-21818.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://192.168.0.140:37258/

SUMMARY
========

PARAMETERS
 * /rosdistro: kinetic
 * /rosversion: 1.12.14
 * /rtabmap/stereo_odometry/Odom/ResetCountdown: 1
 * /rtabmap/stereo_odometry/Reg/Force3DoF: True
 * /rtabmap/stereo_odometry/approx_sync: False
 * /rtabmap/stereo_odometry/config_path: 
 * /rtabmap/stereo_odometry/frame_id: base_footprint
 * /rtabmap/stereo_odometry/ground_truth_base_frame_id: 
 * /rtabmap/stereo_odometry/ground_truth_frame_id: 
 * /rtabmap/stereo_odometry/guess_frame_id: 
 * /rtabmap/stereo_odometry/guess_min_rotation: 0.0
 * /rtabmap/stereo_odometry/guess_min_translation: 0.0
 * /rtabmap/stereo_odometry/odom_frame_id: odom
 * /rtabmap/stereo_odometry/publish_tf: False
 * /rtabmap/stereo_odometry/queue_size: 10
 * /rtabmap/stereo_odometry/subscribe_rgbd: False
 * /rtabmap/stereo_odometry/wait_for_transform_duration: 0.3

NODES
  /rtabmap/
    stereo_odometry (nodelet/nodelet)

ROS_MASTER_URI=http://192.168.0.140:11311

process[rtabmap/stereo_odometry-1]: started with pid [21857]
[ INFO] [1588668629.610590551]: Loading nodelet /rtabmap/stereo_odometry of type rtabmap_ros/stereo_odometry to manager /mobile_base_nodelet_manager with the following remappings:
[ INFO] [1588668629.610754262]: /rtabmap/left/camera_info -> /zed/zed_node/left/camera_info
[ INFO] [1588668629.610805046]: /rtabmap/left/image_rect -> /zed/zed_node/left/image_rect_color
[ INFO] [1588668629.610867286]: /rtabmap/odom -> /rtabmap/odom
[ INFO] [1588668629.610924406]: /rtabmap/right/camera_info -> /zed/zed_node/right/camera_info
[ INFO] [1588668629.610971926]: /rtabmap/right/image_rect -> /zed/zed_node/right/image_rect_color

However, if I start the stereo_odometry directly without using a nodelet, I will see continuous odom information like this:

[ INFO] [1588668768.465902688]: Odom: quality=0, std dev=99.995000m|99.995000rad, update time=0.057927s
[ INFO] [1588668768.714381182]: Odom: quality=646, std dev=0.010125m|0.064759rad, update time=0.244221s
[ INFO] [1588668768.854250518]: Odom: quality=617, std dev=0.003693m|0.045136rad, update time=0.137973s
[ INFO] [1588668769.010187479]: Odom: quality=654, std dev=0.004047m|0.040232rad, update time=0.154011s
^C[ INFO] [1588668769.142351594]: Odom: quality=647, std dev=0.002223m|0.028215rad, update time=0.130238s

If I want to be able to view the information continuously released by odom when using nodelet, how should I set it up?

3. When I launch ekf_localization_node, the terminal will prompt the following warning:

[ WARN] [1588695262.556509902]: X acceleration is being measured from IMU; X velocity control input is disabled

What does this mean? Is it because which parameter is not set correctly?

4. When I switched to nodelet and loaded RobotLocalization/EkfNodelet, I encountered some errors that prevented it from working properly. I describe the problem in detail here.

5. Is there any way to compare the pros and cons of different odom? That is to say, how can I compare the odom before and after fusion so that I know whether the odom after fusion is better or not?

[willzoe]

6. Under rtabmap node, if I set odom_frame_id to odom, how should I set odom_tf_angular_variance and odom_tf_linear_variance?

[matlabbe]

1. guess_from_tf has been removed, see guess_frame_id on ros wiki instead.
2. The nodelets manager would need to start with output="screen" in xml.
3. Cannot say, check robot_localization documentation
4. The RobotLocalization/EkfNodelet is not found in the ROS path, was it built in local workspace?
5. If you do a big loop, the larger the loop closure is, the larger is the odometry drift. If you have access to a ground truth, it is possible to feed it to rtabmap node to compute RMSE along the trajectory.
6. they should be representative of the odometry drift over time. For example, for Google Tango, we use odom_tf_linear_variance:=0.0001 odom_tf_angular_variance:=0.000001 as Tango's VIO is drifting slowly over time.

[takahiko-hasegawa-hdjp]

so what does guess_frame_id do?
and whats the whole idea of thie guess odom praram?

[matlabbe]

From the doc:

~guess_frame_id (string, default: "")
Use this frame as guess to compute odometry, otherwise odometry guess is done from a constant motion model. tf published by this node will be the correction of actual odometry. If guess_frame_id is odom_combined, odom_frame_id is odom and frame_id is base_footprint, odom -> odom_combined is published by this node to have a tf tree like this: /odom -> /odom_combined -> /base_link.

In other words:

1. can help to better estimate visual/icp odometry, by already guessing where the camera/robot is. It helps for better accurate feature matching or icp registration.
2. if your robot has already wheel odometry, this is a convenient way to get guess from wheel odometry, while not breaking TF tree. For example, your robot has already odom->base_link available, if you would launch visual odometry witohut the guess frame odom, visual odometry will also publish an odom frame -> base_link, which breaks the tree (in that scenario you would have to disable wheel odometry TF publisher). If you set odom_frame_id to vo and guess_frame_id to odom, visual odometry will only publish vo->odom, so the TF tree is not broken (vo->odom->base_link).

[takahiko-hasegawa-hdjp]

Does that mean if we publish the map frame together with the guess frame id then the link would be:
map -> vo -> odom -> base_link?

[matlabbe]

Yes!

[takahiko-hasegawa-hdjp]

Great that makes sense thanks!