Open MrOCW opened 3 years ago
Some events that can cause odometry lost: https://github.com/introlab/rtabmap/wiki/Kinect-mapping#lostodometry
What is the computation time of odometry when it is tracking? You may also want to do visual odometry with IR cameras instead of the RGB camera, you will get better field of view and less motion blur, see http://wiki.ros.org/rtabmap_ros/Tutorials/StereoHandHeldMapping#Bring-up_example_with_RealSense_cameras
Some events that can cause odometry lost: https://github.com/introlab/rtabmap/wiki/Kinect-mapping#lostodometry
What is the computation time of odometry when it is tracking? You may also want to do visual odometry with IR cameras instead of the RGB camera, you will get better field of view and less motion blur, see http://wiki.ros.org/rtabmap_ros/Tutorials/StereoHandHeldMapping#Bring-up_example_with_RealSense_cameras
@matlabbe how do i check the computation time of odometry? Is it update time? update time is longer than usual when the warning appears
Also, does the example you linked still use the depth camera for the D435i?
[ INFO] [1617950348.595065278]: Odom: quality=197, std dev=0.002557m|0.056744rad, update time=0.135430s
[ WARN] (2021-04-09 14:39:08.801) OdometryF2F.cpp:141::computeTransform() Failed to find a transformation with the provided guess (xyz=-0.007323,0.006732,-0.000843 rpy=-0.002262,-0.000847,0.051729), trying again without a guess.
[ WARN] (2021-04-09 14:39:08.964) OdometryF2F.cpp:171::computeTransform() Trial with no guess succeeded.
[ INFO] [1617950348.967375479]: Odom: quality=207, std dev=0.001881m|0.050171rad, update time=0.351689s
Hi,
yes, the update time on log begging with "Odom:" is the odometry update time. The stereo example uses IR cameras of D435i as a stereo camera, the depth is not used. It could be possible to use IR stereo topics for stereo_odometry node, but use RGB-D topics for rtabmap node by launching nodes separately.
cheers, Mathieu
Hi,
Any update on this issue? I have the same issue where the map, the occupancy gird, (/map
topic) gets recreated all the time. Under re-created, I mean it disappears and a new map, with different dimensions (usually smaller), gets created. As a warning message on the command line I get:
OdometryF2M.cpp:525::computeTransform() Registration failed: "Not enough inliers 13/20 (matches=118) between -1 and 384"
When the camera is steady, the map does not get re-created. When the camera moves re-creation happens. The initial thought was that camera moves fast, but even with slow motion, re-creation happens.
I took a look at this link https://github.com/introlab/rtabmap/wiki/Kinect-mapping#lostodometry and implementing one of the solutions mentioned there are not practical, especially if you have a robot navigating autonomously:
So, is there a way to prevent the map from re-creating even if we lose the odometry?
Odometry update time for me:
Odom: quality=303, std dev=0.002696m|0.036256rad, update time=0.117297s
Using: ROS2 Foxy on Ubuntu 20.04.
Regards, Nedim
What is your sensor setup? If you are using a D435, please don't use the RGB camera for visual odometry, use the left/right IR cameras instead (they have wider field of view and lower motion blur).
For the general issue about visual odometry and autonomous navigation. Even if you get the best visual odometry approach, it is often not reliable enough for indoor robot navigation, because of areas where there are just no visual features to track because of featureless walls or it is too dark. Having Fisheye stereo camera helps a lot for robustness, even more if you use a Visual Inertial Odometry approach. If you are on a robot, consider also using wheel odometry, even combined with a lidar which can be pretty robust.
For the problem of new maps always re-created when odometry resets, set publish_null_when_lost
to false for odometry node with Odom/ResetCountdown
to 1. Example for ROS1:
<node pkg="rtabmap" type="rgbd_odometry" name="rgbd_odometry">
<param name="publish_null_when_lost" value="false"/>
<param name="Odom/ResetCountdown" value="1"/>
</node>
cheers, Mathieu
Hi @matlabbe,
Thank you for your quick and detailed answer. Yes, we are using realsense D435i. I will try with your suggestions, but in the meantime, I have a follow-up question.
Since we have wheel odometry, and transform odom
-> base_link
present, and the rtabmap launch file frame_id
set to base_link
, shouldn't mean that we are using in fact odometry coming from the wheels? Or I need to set some explicit parameter in rtabmap? Also, is there a way to know when this happens (lost odometry) via some ROS topic?
Regards, Nedim
Hi Nedim,
To know when lost odometry happens, the odometry node will send a null pose in its odom topic (e.g., the pose quaternion will be invalid x=0,y=0,z=0,w=0) and the odom_info topic will have lost
parameter set to true.
Not sure which launch file you are using or how you start rtabmap, but rtabmap will use the odometry topic that is linked to. If you are using rtabmap.launch, set visual_odometry
to false, then set odom_topic
to your wheel odometry topic.
https://github.com/introlab/rtabmap_ros/blob/f7beb23061654fba970fc8770e37425d43967491/launch/rtabmap.launch#L96-L98
If you are using nodes directly, see this example: http://wiki.ros.org/rtabmap_ros/Tutorials/SetupOnYourRobot#Kinect_.2B-_Odometry, replacing kinect by realsense2_camera
cheers, Mathieu
Hi Mathieu,
Thank you for the input. For me, the map is not being re-created and behavior is much better.
If I have more questions, will post them, but for now, I am good!
Regards, Nedim
HI @matlabbe , I am using a D435i with Jetson to run RTABMap on ROS with RViz. I find that odometry is easily lost even though the view is not featureless.
I get lots of such warnings whenever the camera faces a new area that hasnt been mapped.
OdometryF2F.cpp:294::computeTransform() Registration failed: "Not enough inliers 0/20 (matches=12) between 0 and 0"
I get these errors every now and then as well
odometry: Could not get transform from odom to camera_link (stamp=1617684985.570663) after 0.200000 seconds ("wait_for_transform_duration"=0.200000)! Error="Lookup would require extrapolation into the future. Requested time 1617684985.570663214 but the latest data is at time 1617684984.665417194, when looking up transform from frame [camera_link] to frame [odom]. canTransform returned after 0.201946 timeout was 0.2."
Rtabmap.cpp:1148::process() RGB-D SLAM mode is enabled, memory is incremental but no odometry is provided. Image 14831 is ignored!