Having two separate TF trees (which is what is shown in your screenshot) is not correct for a single robot. Your _1 suffix for the frames based on your encoders is the root cause of the issues you have with gmapping. Take a look at REP 105 for some details on standard frames in ROS, but I'll detail how you should fix your frames below.
First off, since your Kinect is connected to the robot's base at some point and doesn't just sort of float, your transform should be between openni_camera
and base_link
, not between openni_camera
and odom
. Next, your encoders (possibly fused with any other relative type sensors like a gyro or visual odometry using something like robot_pose_ekf
) should determine the transformation between base_link
and odom
. gmapping then publishes the odom
to map
transform so that you can localize your robot in the fixed map
reference frame. You can check that your localization is ready for gmapping if, in rviz
, you can set your fixed frame to odom
and view your LaserScan
output while driving the robot around. If you set rviz
to buffer some amount of scans, you should get something that approximates a map of your environment.
gmapping doesn't output a base_link
to odom
transform at all (that's what your encoders are generating) - it uses that transform to determine how far your robot has moved between scans. gmapping only outputs the odom
to map
transform, so it cannot "overwrite" the base_link
to odom
transform.
Once you correct your TF tree, you should be able to use the default gmapping temporal update parameters. You had to enable that to force updates after a certain amount of time because, since your encoders were publishing in a separate TF tree, gmapping was waiting for your robot to move (as indicated by some amount of difference in the base_link
to odom
transform, which is what the linearUpdate
and angularUpdate
parameters control).
If you want to figure out how much error there is in your odometry from the encoders, you could look at how much the gmapping correction (odom
to map
transform) drifts over time. In an ideal situation, and assuming gmapping doesn't move it's origin point while you are mapping, the drift in the odom
to map
transform should be zero.
Why are you adding the _1 suffix to frames from your encoders? What is supplying your base_link->odom transform (the not suffixed versions)? Some other odometry source?
I added the suffix to distinguish it from the corrected odom supplied by slam_gmapping, to elicit the encoder errors. However, I don't recall being able to visualize it properly, so I think there's a (logical) flaw in that system. Does slam_gmapping overwrite the odom published by the encoders?