Ask Your Question
0

robot_localization odometry message bursts

asked 2018-05-09 06:28:51 -0500

Jacob Seibert gravatar image

updated 2018-05-17 09:57:20 -0500

Hi,

I'm using robot_localization package to fuse wheel odometry and IMU of a robot with the EKF node. The ekf node outputs the odometry to /odom topic.

When inspecting the rate of this output I spotted weird peaks of the publish rate (see screen shots below). Frequency parameter is set to 100 Hz. It looks as if there are sudden bursts of odometry messages. Some consecutive messages have the exact same time stamp but different pose (second screen shot). That leads to problems with some other nodes (e.g. cartographer).

Any idea why this happens?

rostopic hz output:

$ rostopic hz -w5 /odom
subscribed to [/odom]
WARNING: may be using simulated time
no new messages
average rate: 98.790
    min: 0.010s max: 0.010s std dev: 0.00003s window: 5
average rate: 99.049
    min: 0.010s max: 0.010s std dev: 0.00002s window: 5
average rate: 198.175
    min: 0.000s max: 0.010s std dev: 0.00505s window: 5
average rate: 99.281
    min: 0.000s max: 0.040s std dev: 0.01745s window: 5
average rate: 0.000
    min: 0.000s max: 0.000s std dev: 0.00000s window: 5
average rate: 397.287
    min: 0.000s max: 0.010s std dev: 0.00436s window: 5
average rate: 98.930
    min: 0.000s max: 0.040s std dev: 0.01751s window: 5
average rate: 0.000
    min: 0.000s max: 0.000s std dev: 0.00000s window: 5
average rate: 0.000
    min: 0.000s max: 0.000s std dev: 0.00000s window: 5
average rate: 98.760
    min: 0.000s max: 0.041s std dev: 0.01754s window: 5
average rate: 198.223
    min: 0.000s max: 0.010s std dev: 0.00504s window: 5
average rate: 0.000
    min: 0.000s max: 0.000s std dev: 0.00000s window: 5
average rate: 131.822
    min: 0.000s max: 0.030s std dev: 0.01314s window: 5
average rate: 98.955
    min: 0.000s max: 0.040s std dev: 0.01750s window: 5
average rate: 78.978
    min: 0.000s max: 0.041s std dev: 0.01664s window: 5

Two consecutive messages with same time stamp:

header: 
  seq: 3552
  stamp: 
    secs: 35
    nsecs: 914000000
  frame_id: "odom"
child_frame_id: "base_link"
pose: 
  pose: 
    position: 
      x: 1.04198573467
      y: -0.104723379008
      z: 0.0
    orientation: 
      x: 0.0
      y: 0.0
      z: -0.0586363976445
      w: 0.998279406214
  covariance: [shortened]
twist: 
  twist: 
    linear: 
      x: 0.100029364899
      y: 0.0
      z: 0.0
    angular: 
      x: 0.0
      y: 0.0
      z: -0.00294809162749
  covariance: [shortened]
-----------------------------------------
header: 
  seq: 3553
  stamp: 
    secs: 35
    nsecs: 914000000
  frame_id: "odom"
child_frame_id: "base_link"
pose: 
  pose: 
    position: 
      x: 1.04198614439
      y: -0.104723426958
      z: 0.0
    orientation: 
      x: 0.0
      y: 0.0
      z: -0.0586363976445
      w: 0.998279406214
  covariance: [shortened]
twist: 
  twist: 
    linear: 
      x: 0.100031008838
      y: 0.0
      z: 0.0
    angular: 
      x: 0.0
      y: 0.0
      z: -0.00294809030248
  covariance: [shortened]

Configuration of ekf node:

frequency: 100
    sensor_timeout: 0.05
    two_d_mode: true
    transform_time_offset ...
(more)
edit retag flag offensive close merge delete

Comments

Could I ask you to please not post screenshots of text? There is no need to do that (just copy-paste the console text) and it's also undesirable from a search-engine perspective (text in images is not (yet) searchable).

Please see the support guidelines.

gvdhoorn gravatar imagegvdhoorn ( 2018-05-09 06:57:52 -0500 )edit

Yes, I see your point. I don't have access to the system right now to get the text, but I will replace the images as soon as possible.

Jacob Seibert gravatar imageJacob Seibert ( 2018-05-09 12:10:04 -0500 )edit

Does this happen when you run at lower frequencies?

stevejp gravatar imagestevejp ( 2018-05-10 07:08:55 -0500 )edit

With lower rates it is not as bad as with 100 Hz. See updated original post above.

Jacob Seibert gravatar imageJacob Seibert ( 2018-05-17 09:51:17 -0500 )edit

Just to clarify is it the wheel odometry sensor topic which is displaying rapid bursts or the output from the robot_localization package? Have these been setup as two different topics?

PeteBlackerThe3rd gravatar imagePeteBlackerThe3rd ( 2018-05-17 12:50:42 -0500 )edit

The setup is:

odometry -> /wheel_odom -> robot_localization_ekf -> /odom

So yes, those topics are separated and the messages we are talking about are published (only) by the EKF.

Jacob Seibert gravatar imageJacob Seibert ( 2018-05-18 03:05:22 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2018-05-25 04:51:18 -0500

Jacob Seibert gravatar image

After inspecting the message timing a bit more in detail we found out that it was actually an issue with the IMU messages that we thought was already fixed (USB latency). Thanks @Tom Moore for pointing us in this direction.

edit flag offensive delete link more
2

answered 2018-05-22 04:17:21 -0500

Tom Moore gravatar image

Please post sample input messages as well.

This is most likely a timestamp issue with your sensor inputs. See this post on the package's GH issues page.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-05-09 06:28:08 -0500

Seen: 219 times

Last updated: May 25 '18