ekf_localization: odometry/filtered topic:Frequency too low?

edit

I am using robot_localization to fuse gps and imu referencing this Tom Moore answer: http://answers.ros.org/question/20007...

My setup is the same with a full-size SUV vehicle, Beaglebone Black board, Phidgets imu w/mag, ublox gps, with no odometry sensors. I am running Ubuntu 14.04.4 LTS, deb 4.1.15-ti-rt-r40 armv7l, ros indigo, and robot_localization with the ekf filter.

I've been able to produce decent results, but the mobile trial awaits resolving issues, so everything is tested in the static position. I've calibrated the magnetometer for hard and soft iron on the vehicle and incorporate the factors in the driver. I use an overall launch file that separately calls the devices and robot_localization. REP's 103 and 105 were adhered to with the imu (as far as I can tell), since the raw mag points (X) east at zero and the other checks (Y and Z) work out. Declination is accounted for in the navsat_transform launch file.

The issue arises with the diagnostic output where this occurs:

level: 1 
  name: ekf_localization: odometry/filtered topic status 
  message: Frequency too low. 
  hardware_id: none 
  values: 
    - 
      key: Events in window 
      value: 17 
    - 
      key: Events since startup   
      value: 172 
    - 
    key: Duration of window (s) 
    value: 16.443676 
    - 
      key: Actual frequency (Hz)  
      value: 1.033832 
    - 
      key: Minimum acceptable frequency (Hz) 
      value: 55.800000 
    -
      key: Minimum acceptable frequency (Hz) 
      value: 72.600000

I've checked the frequencies of all the incoming topics and they all seem ok except for the /tf topic which also shows around 1 hz. The transform frames correctly seem to tie odom to base_link with child frames phid_imu and gps.

A secondary factor may be in play is the 0 yaw covariance factor produced by the Phidgets imu driver. I cannot seem to find where this can be adjusted to help convergence. The gps is running at 4hz(fortunately) so it will determine all gps inputs (ie. /odometry/gps).

I am asking how to resolve the low ekf_localization diagnostic issue and will likely have to ask another question about the yaw covariance in the Phidgets driver.

I've placed the diagnostic output, device output, launch files, node graph, and transform tree on Dropbox https://www.dropbox.com/sh/u3kznp4oiy...

Any ideas towards this end? Please forgive the text formatting.

Regards and Thank you,

b2256

EDIT 03/10/16 Per Tom Moore's comment below, I did perform the ekf/imu test and found that if the data rate value in the imu was slowed to 40ms, the frequencies of /odometry/filtered and /tf were helped. I then implemented the full launch with the same result although it takes a few minutes to stabilize. Will these values at 25 hz be sufficient for operation? Additional tweaks involved reducing the ekf data rate to 28 hz hoping to stabilize (with limited success at ~25.6 hz, std dev 0.0155s, and max of 0.353s). Note that these results were via ssh (from a Windows laptop) into the ...