ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Some errors and warning using Robot Localization

asked 2022-03-23 11:10:47 -0500

Johart24 gravatar image

updated 2022-03-29 15:25:37 -0500

Hello, im using robot_localization package. I am working GPS+IMU+ENCODER and using a RPLidar . The situation is the next one:

  • When i launch all the necesary files to send goals and create paths ( move_base, map_server with a empty map, fusion senso for lozalization ) I see some things that are not working properly.
  1. The first one is related with localization: I am getting a continuous jumping of position (x,y) in the final /odometry/filtered topic on the map frame. I read that is normal to get that discrete jumps, but they are being agressive and they're afecting the paths created because when the robot do that discrete jumps, the laser readings also changue repect to the map and if the robot moves enough the path could be totally distortioned trying to avoid forbiden areas that before was free.

Just to notice im getting this Warning on the Sheell (of NAVSTAT NODE):

Transform from base_link to map was unavailable for the time requested. Using latest instead
  1. I am getting some error on the MOVE_BASE node, i don´t know why:

    - [ERROR] Extrapolation Error: Lookup would require extrapolation into the future.  Requested time 1647649070.614538908 but the latest data is at time 1647649070.575517893, when looking up transform from frame [odom] to frame [map]  
    
    - [ERROR] Global Frame: odom Plan Frame size 287: map
    
    - [ WARN]  Could not transform the global plan to the frame of the controller
    

I really would be gratefull to everybody can help me.

Thanks

...

EDIT1 (Files and TF tree)

Local EKF:

#Configuation for robot odometry EKF
#
  frequency: 20
  sensor_timeout: 0.06
  two_d_mode: true
  transform_time_offset: 0.0
  transform_timeout: 0.0
  print_diagnostics: false
  debug: false

  map_frame: map
  odom_frame: odom
  base_link_frame: base_link
  world_frame: odom

# -------------------------------------
# Wheel odometry:

  odom0: /odom_enc
  odom0_config: [false, false, false,
                 false, false, false,
                 true,  true,  false,
                 false, false, true,
                 false, false, false]
  odom0_queue_size: 10
  odom0_nodelay: true
  odom0_differential: false
  odom0_relative: false

# --------------------------------------
# imu configure:

  imu0: /imu/data
  imu0_config: [false, false, false,
                true,  true,  true,
                false, false, false,
                true,  true,  true,
                true,  false,  false]
  imu0_nodelay: false
  imu0_differential: false
  imu0_relative: false
  imu0_queue_size: 10
  imu0_remove_gravitational_acceleration: false

  process_noise_covariance: [1e-3, 0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                             0,    1e-3, 0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                             0,    0,    1e-3, 0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0.03,  0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0.03,  0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0,    0.01, 0,     0,     0,    0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0,    0,    0.5,   0,     0,    0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0,    0,    0,     0.5,   0,    0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0,    0,    0,     0,     0.1,  0,    0,    0,    0,    0,    0,
                             0,    0,    0,    0,    0,    0 ...
(more)
edit retag flag offensive close merge delete

Comments

Can you add tf tree and if possible robot_localization yaml files? This will help to get a better understanding of the problem.

Tahir M. gravatar image Tahir M.  ( 2022-03-24 05:17:52 -0500 )edit

Sure, ill edit the question with this information. Sorry for the late reply.

Johart24 gravatar image Johart24  ( 2022-03-29 15:21:39 -0500 )edit

Please also include a sample message from each sensor input.

Tom Moore gravatar image Tom Moore  ( 2022-05-24 02:50:40 -0500 )edit

1 Answer

Sort by » oldest newest most voted
2

answered 2022-05-24 03:05:13 -0500

Tom Moore gravatar image

So I see a bunch of things, some of which could be related to your issue, and some of which should just be corrected. It's always helpful if you also include a sample message from every sensor input. And in this case, a video of what you're seeing would help.

  1. Re: this error,

    [ERROR] Extrapolation Error: Lookup would require extrapolation into the future.  Requested time 1647649070.614538908 but the latest data is at time 1647649070.575517893, when looking up transform from frame [odom] to frame [map]
    

    The issue is likely that you have your map-frame EKF instance producing states at 15 Hz, but move_base is running at a higher frequency. So move_base will start a new control cycle and it will need a transform at that time, but the EKF will not have published yet. You can increase the output rate of the map-frame EKF, or you can see if whatever part of move_base is complaining has an option to wait longer for transforms to be available.

  2. Your odom-frame EKF has a sensor_timeout of 0.06. For now, I'd remove that until everything is working as you expect. Not a big deal (and almost certainly not related to your issue here), but it's going to make the EKF do more predictions without corrections, which will lead to error accumulation in the odom frame.

  3. Your magnetic_declination_radians parameter has a comma (,) in it: <param name="magnetic_declination_radians" value="0,11"/>. That should be a period/full stop, i.e., 0.11.

  4. GPS sensors are noisy, sometimes very much so. If the sensor is causing the robot to jump excessively, I might suggest you double-check that the covariance value in your GPS are accurate. If the GPS is regularly jumping, e.g., over a meter, but the variance in the position is very small, then the sensor is being overconfident, and that will affect the output. Filters aren't magic: garbage in, garbage out, as the saying goes.

  5. Minor issue: you have two_d_mode enabled, but you are attempting to fuse roll and pitch from your IMU. Those will be ignored.

edit flag offensive delete link more

Comments

Hi Toom, I dont have the robot with me in this moments so I can't update the sensor messages, but I followed your advices. I deleted the sensor_timeout, and I corrected the comma in the magnetic_declination_radians parameter.

About the Extrapolation error, I got a better power source for the robot, on Jetson Nano this lets me to use the 4 cores of the processor. When i did that, the error dissapear.

Following some advices, we translate the GPS goals from UTM to Odom frame to plan the trayectory, and if I understood the REP, this is the right frame to plan trajectories. We also add covariances to the IMU message (and to the encoder odometry), and made sure that the IMU was working correctly, due if it was failing, the gps odometry would be wrong.

I just have some warning, but in some videos of Clearpath they also have ...(more)

Johart24 gravatar image Johart24  ( 2022-05-24 10:35:21 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2022-03-23 11:10:47 -0500

Seen: 647 times

Last updated: May 24 '22