Ask Your Question
0

Robot_localization diagnostic question #2

asked 2016-05-14 15:48:34 -0600

b2256 gravatar image

I'm still underway attempting to fine-tune an instance of (ekf) robot_localization using gps and single imu devices. The diagnostic message for the ekf filter "appears to be functioning properly." However the next message states "odometry/filtered topic status message: Frequency too low." The value is less than 5Hz with the frequency of both the ekf and the navsat transform are at 60 Hz. The imu delivers at around 55 Hz (set at 16ms ~ 62.5 Hz) using the ImuFilterNodelet of imu_filter_madgwick; so there is some latency.

My goal is to get as close as possible to 60 Hz to enable the gps/filtered topic to deliver a data set that allows around this frequency for post processing sync with dynamic images. How can I rectify the filtered topic status with this latency?

Thank you as always, B2256

edit retag flag offensive close merge delete

Comments

Can you please post sample inputs and config files? The EKF can run at hundreds of Hz even with multiple inputs, so I suspect that something else is amiss.

Tom Moore gravatar imageTom Moore ( 2016-05-14 20:09:31 -0600 )edit

Thanks Tom. Here is the dropbox link: https://www.dropbox.com/sh/u3kznp4oiy...

Still getting low output when initiate bag recording; bandwidth on the Beaglebone Black perhaps.

b2256 gravatar imageb2256 ( 2016-05-19 17:38:09 -0600 )edit

The link only appears to have launch files. Do you have sample input messages?

Tom Moore gravatar imageTom Moore ( 2016-05-19 20:18:13 -0600 )edit

Input messages are now on the above dropbox link as "TRIAL007_INPUT.odt". Still suspecting bandwidth issue with the Beaglebone Black, but hopefully some launch file or configurations can be identified for the source of error? Thank you Tom.

b2256 gravatar imageb2256 ( 2016-05-22 15:11:50 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2016-05-30 05:25:12 -0600

Tom Moore gravatar image

I'm not sure what's causing your trouble, as I don't really see anything wrong with the data. However, you may want to look into the following:

  1. Since all your high-frequency data appears to fall victim to decreased frequency when bagging, can you try bagging to another disk? It seems like very strange behavior to me, and unrelated to r_l.
  2. Can you run top or htop to see if something is consuming a lot of CPU? Also, let me know how much CPU r_l is using.
  3. I noticed in your config file that the debug flag and corresponding path are specified, although I recognize that debug is set to false. Just an FYI: if you're running live and turn on debug mode, it's going to eat a lot of CPU and slow down the filter.
  4. Are you running from binaries? If so, which version? If you're running from source, which version, and did you build in release mode?
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: 2016-05-14 15:48:34 -0600

Seen: 183 times

Last updated: May 30 '16