laser scan error

[osmancns]

I keep getting these errors after RTAB-Map runs for a couple of seconds:


[ WARN] (2016-01-21 16:41:21.107) SensorData.cpp:580::uncompressDataConst() Requested laser scan data, but the sensor data (82) doesn't have laser scan.
[ERROR] (2016-01-21 16:41:21.107) Memory.cpp:2813::computeIcpTransform() Depths 2D empty?!? (new[82]=0 old[70]=0)


and these errors for rgbd_odometry

[ WARN] (2015-10-11 00:05:41.095) OdometryBOW.cpp:304::computeTransform() Not enough correspondences (0 < 20)
[ WARN] (2015-10-11 00:05:41.233) OdometryBOW.cpp:308::computeTransform() Not enough inliers (9 < 20)

how can I solve this errors ?

thank you...

[matlabbe]

Hi,

Do you have a laser scan? which launch file do you use?

For OdometryBOW, it means that there are not enough visual matches. See "RED screens" section on this page for more information.

cheers

[osmancns]

I have laser scan but I dont use it for rtabmap. ı use just kinect for 3d mapping and odometry for robot_pose_ekf.
subscribe_scan: false but why ı keep get laser error ?

move_base_turtle_rtabmap.launch

this is my launch file (about rtabmap) :

    <arg name="subscribe_scan"          default="false"/>     

  <group ns="rtabmap">
    <node name="rtabmap" pkg="rtabmap_ros" type="rtabmap" output="screen" args="--delete_db_on_start">
         
         
         
         
       
         
                 
          <remap from="odom" to="/scanmatch_odom"/>

          <remap from="rgb/image" to="/camera/rgb/image_rect_color"/>
          <remap from="depth/image" to="/camera/depth_registered/image_raw"/>
          <remap from="rgb/camera_info" to="/camera/rgb/camera_info"/>
       
         
                   
               
           
    </node>
 
  </group>

<arg name="wait_for_transform"      default="0.1"/>
 
 
  <arg name="strategy"            default="0" />       
  <arg name="feature"             default="6" />     
  <arg name="estimation"          default="0" />     
  <arg name="nn"                  default="3" />     
  <arg name="max_depth"           default="0" />     
  <arg name="min_inliers"         default="8" />     
  <arg name="inlier_distance"     default="0.1" />   
  <arg name="local_map"           default="5000" /> 
  <arg name="variance_inliers"    default="true"/>   

             
    <node pkg="rtabmap_ros" type="rgbd_odometry" name="rgbd_odometry" output="screen">
      <remap from="rgb/image"       to="/camera/rgb/image_rect_color"/>
      <remap from="depth/image"     to="/camera/depth_registered/image_raw"/>
      <remap from="rgb/camera_info" to="/camera/depth_registered/camera_info"/>

     
     
     
     

       
         
       
       
     
       
       
       
             
      
       
       
       
      <remap from="odom" to="vo"/>

    </node>

  </node>

</launch>

[osmancns]

I changed this parameter :
from
="LccIcp/Type" type="string" value="2"/>        

to
="LccIcp/Type" type="string" value="3"/>        

and now I dont see laser scan error.

but I always (after a few seconds ) keep get odometry error.

[ WARN] (2015-10-11 00:05:41.095) OdometryBOW.cpp:304::computeTransform() Not enough correspondences (0 < 20)
[ WARN] (2015-10-11 00:05:41.233) OdometryBOW.cpp:308::computeTransform() Not enough inliers (9 < 20)

I changed
<arg name="feature"     default="6" />       

but result is same.

how can I solve???

[matlabbe]

Hi,

The depth2d empty errors are because "LccIcp/Type"=1 (ICP 2D with laser scans). Set "LccIcp/Type" to 0 (or remove it from the launch file):

<param name="LccIcp/Type" type="string" value="0"/>

"LccIcp/Type"=2 (ICP 3D with depth images) is not recommended with the current rtabmap version, as it can be difficult to correctly set its related parameters.

Well, if you are going to do 2D navigation and you have a laser, I recommend to use it (and keep "LccIcp/Type"=1 for rtabmap node). Probably set "Odom/Force2D"=true for rgbd_odometry node, this will ignore odometry errors in z/roll/pitch.

The odometry is lost, what kind of environment are you trying to map? empty space? no/low textures? You can also try with argument "estimation"=1 of your launch file:

<arg name="estimation"          default="0" />       <!-- Motion estimation approach: 0:3D->3D, 1:3D->2D (PnP) -->

cheers

[osmancns]

thanks... result is much better now. But, when my robot started turn right or left , ı keep get odometry error again. robot turning velocity (max_rot_vel : 5.0  ) is a liitle fast. and ı use a lot of boxes for training area, not empty space.

rtabmap.launch

what can ı do another thing now.? can ı do like that "rosservice call /rtabmap/reset_odom " will work automatically if  odometry lost ?


 

[osmancns]

Odom/ResetCountdown (default 0): Automatically reset odometry after X consecutive images on which odometry cannot be computed (value=0 disables auto-reset).


param name="Odom/ResetCountdown" type="int" value="1"/>

Okay now its doing automatically reset.

[matlabbe]

Hi,

If the frame rate the odometry is low, the robot may need to make its turns slower, otherwise it will loose tracking the visual features. What is the output on the terminal?

cheers

[osmancns]

how can ı solve this problem not change turning velocity ? where is the odometry frame rate ?

this is my out of odom terminal :

[matlabbe]

Hi,

Actually, I was thinking about the terminal output log of the odometry node. Something like

[INFO] Odom: quality=320, std dev=0.001m, update time=0.97s
[INFO] Odom: quality=300, std dev=0.001m, update time=0.11s
...

In that log, you can see the odometry update time (here around 97-110 ms or ~10 Hz). You cannot set explicitly a frame rate for odometry, it depends on the CPU. It processes the input images as fast at it can, dropping the other frames. If the computation power is higher, odometry will run at higher frame rate (up to camera frame rate).

You can see the frame rate of the odometry using this rostopic:

$ rostopic hz /rtabmap/odom

For visual odometry, a frame rate over 10Hz at least is required unless the robot is moving slowly. Reducing the number of features to track can reduce odometry update time. In your previous posts, you used a local map of 5000 features, which is a bit high and requires more processing (default is 1000).

cheers,
Mathieu