Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Is robot_pose_ekf acting correctly?

I'm working towards getting gmapping to work on my turtlebot clone right now but I keep getting the following

[ WARN] [1326075941.066724233]: Costmap2DROS transform timeout. Current time: 1326075941.0667, global_pose stamp: 1326075940.4574, tolerance: 0.3000
[ WARN] [1326075941.066806436]: Could not get robot pose, cancelling reconfiguration

So I try rosrun tf view_frames to see if there's anything wrong: view_frames.png

Seems like the only weird area is the broadcast rate of /odom->/base_footprint of 10000Hz. So I did a rosservice call /robot_pose_ekf/get_status

status: Input:
 * Odometry sensor
   - is active
   - received 2578 messages
   - listens to topic /odom
 * IMU sensor
   - is NOT active
   - received 2686 messages
   - listens to topic /imu/data
 * Visual Odometry sensor
   - is NOT active
   - received 0 messages
   - listens to topic 
Output:
 * Robot pose ekf filter
   - is active
   - sent 215 messages
   - pulishes on topics /robot_pose_ekf/odom and /tf

What I find odd is the IMU is supposedly not active yet rostopic hz /imu/data shows

    subscribed to [/imu/data]
average rate: 20.001
    min: 0.048s max: 0.052s std dev: 0.00078s window: 20
average rate: 20.001
    min: 0.048s max: 0.052s std dev: 0.00066s window: 40
average rate: 20.000
    min: 0.048s max: 0.052s std dev: 0.00054s window: 60

Anybody has any idea how I can fix this problem? Or am I looking at the wrong area (robot_pose_ekf seems to be the issue right now since I'm using it to handle my transform broadcast)?