ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org
Ask Your Question
0

robot_localization: Strange frequency of odometry message output

asked 2021-11-04 13:26:13 -0600

nparker2020 gravatar image

Hello,

I'm using the robot_localization package on ROS noetic, on an Ubuntu 20.04LTS system with a 4 Core i5. I am running an EKF node, and trying to get the odometry/filtered message output at a fairly high frequency (~200Hz)

I am running into some strange behavior when increasing the frequency configuration parameter for the filter. If the frequency parameter is set to ~30Hz or less, each odometry/filtered message is output at the expected frequency, and the delta between each message is evenly distributed. (i.e. at 20Hz, 20 odometry messages are received in a second, and they are each 50ms apart)

As soon as the frequency is increased to 40Hz, something strange happens. Several odometry messages are sent with very high frequency (~10 microseconds between each message), followed by a 50 millisecond gap. This behavior is consistent increasing the frequency up to 200Hz.

Even at 200Hz, the filter does output an odometry message 200 times in a second. However, the timing between each message is not evenly distributed at all.

I have reduced the number of sensors to 1, a simple odometry source from wheel encoders. This message is published at 200Hz. I have tried modulating the frequency at which this odometry message is published, as well as adjusting the queue sizes for the message.

Has anyone else experienced this? Is this the expected behavior for the filter?

Following section 1.3 of the troubleshooting guide, below is an output of the odom message:

header: 
  seq: 1942
  stamp: 
    secs: 1636049205
    nsecs: 696457465
  frame_id: "odom"
child_frame_id: "base_link"
pose: 
  pose: 
    position: 
      x: 0.0
      y: 0.0
      z: 0.0
    orientation: 
      x: 0.0
      y: 0.0
      z: 0.0
      w: 0.0
  covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
twist: 
  twist: 
    linear: 
      x: 0.01
      y: 0.0
      z: 0.0
    angular: 
      x: 0.0
      y: 0.0
      z: 0.0
  covariance: [1e-06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0001]

I am just hard-setting the X velocity to 0.01 for testing purposes. Also, here is my configuration file:

frequency: 40

silent_tf_failure: false

sensor_timeout: 0.1

two_d_mode: false

transform_time_offset: 0.0

transform_timeout: 0.0

print_diagnostics: true

debug: false

publish_tf: true

publish_acceleration: false

permit_corrected_publication: false

smooth_lagged_data: false

map_frame: map ...
(more)
edit retag flag offensive close merge delete

Comments

1

Odom is not a small message, but perhaps you're seeing Nagel's algorithm at work.

However, the timing between each message is not evenly distributed at all.

how did you measure dT? By looking at message arrival times, or the stamps?

gvdhoorn gravatar image gvdhoorn  ( 2021-11-04 14:55:44 -0600 )edit

Thanks for the reply. Yes, I assumed originally that Nagel's could be at work. I set the odom0_nodelay value to true in an effort the address that.

I was calculating dT upon receipt (arrival time). I see now that the stamps might tell another story. I will run a test looking at the stamps and reply back.

nparker2020 gravatar image nparker2020  ( 2021-11-04 14:59:47 -0600 )edit

Wow. OK. Comparing the stamps in the header yields exactly what I would expect. Each odometry message is delivered in 1/freq. increments. Any advice in addressing this massive delay in message delivery?

EDIT: After looking over the docs and other forum threads, I added a TransportHints with tcpNoDelay() set to the subscribe call for the /odometry/filtered message. This completely resolved my issue. Thank you!

nparker2020 gravatar image nparker2020  ( 2021-11-04 15:13:26 -0600 )edit

Good to hear you got it resolved.

gvdhoorn gravatar image gvdhoorn  ( 2021-11-04 15:30:23 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-11-04 15:27:08 -0600

nparker2020 gravatar image

ANSWER:

The answer to this issue, provided by gvdhoorn (Thanks again!), was to disable Nagel's algorithm for the /odometry/filtered topic. In order to do this, I added a ros::TransportHints to the subscribe call on the /odometry/filtered topic:

ros::TransportHints transportConfig;
  transportConfig.tcpNoDelay();
  ros::Subscriber sub = n.subscribe("/odometry/filtered", 1000, <callback>, transportConfig);
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

Stats

Asked: 2021-11-04 13:26:13 -0600

Seen: 60 times

Last updated: Nov 04 '21