Robotics StackExchange | Archived questions

Robot_localization diagnostic question #2

I'm still underway attempting to fine-tune an instance of (ekf) robotlocalization 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 imufilter_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

Asked by b2256 on 2016-05-14 15:48:34 UTC

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.

Asked by Tom Moore on 2016-05-14 20:09:31 UTC

Thanks Tom. Here is the dropbox link: https://www.dropbox.com/sh/u3kznp4oiygbuan/AADAD_QmU_LieGK3y_sbxR65a?dl=0

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

Asked by b2256 on 2016-05-19 17:38:09 UTC

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

Asked by Tom Moore on 2016-05-19 20:18:13 UTC

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.

Asked by b2256 on 2016-05-22 15:11:50 UTC

Answers

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?

Asked by Tom Moore on 2016-05-30 05:25:12 UTC

Comments