Hi Adams,
It seems to be a TF problem when using zed odometry. Just tried the latest zed_wrapper with this launch file and with/without zed odometry it should work:
<launch>
<arg name="use_zed_odometry" default="false"/>
<arg name="rtabmap_args" default="--delete_db_on_start"/>
<arg name="run_rviz" default="false"/>
<group ns="camera">
<include file="$(find zed_wrapper)/launch/zed_camera.launch">
<arg name="publish_tf" value="$(arg use_zed_odometry)"/>
</include>
</group>
<include file="$(find rtabmap_ros)/launch/rtabmap.launch">
<arg name="rtabmap_args" value="$(arg rtabmap_args)"/>
<arg name="frame_id" value="zed_center"/>
<arg name="approx_sync" value="false"/>
<arg name="depth_topic" value="/camera/depth/depth_registered"/>
<arg name="rviz" value="$(arg run_rviz)"/>
<arg if="$(arg use_zed_odometry)" name="visual_odometry" value="false"/>
<arg if="$(arg use_zed_odometry)" name="odom_topic" value="/camera/odom"/>
</include>
</launch>
Run with or without zed odometry:
$ roslaunch test.launch use_zed_odometry:=true
$ roslaunch test.launch use_zed_odometry:=false
The only problem I see is when ZED odometry gets lost, rtabmap cannot know it is lost, so it cannot trigger a new map to correctly add frames when odometry is estimating again. When zed odometry can estimate again, it continues from the last pose even if the camera has moved/rotated during the time it was lost. For meaningful comparison, make sure zed odometry is always able to track motion.
cheers,
Mathieu
Locked
