Ask Your Question

robot_pose_ekf ignoring imu_data

asked 2012-03-06 11:24:12 -0500

mrtc gravatar image

updated 2012-03-06 11:39:33 -0500

I originally posted a question here to which I'm gradually finding the answer to. I'm successfully inputting the data through a vo topic into robot_pose_ekf, however it appears to be ignoring imu_data, also published. Is there a way to verify that robot_pose_ekf is successfully using this data?


I should clarify this appears to be the case since disabling imu_data publishing has no visual effect on the robot's pose, it continues to update the position at the frequency of the localization system with no change in orientation.

edit retag flag offensive close merge delete


Does the robot pose ekf node subscribe correctly to the imu date? Some simple debugging tools: 1) rxplot 2) "rostopic info /imu_data"

Ivan Dryanovski gravatar image Ivan Dryanovski  ( 2012-03-06 12:50:11 -0500 )edit

Thanks for the reply, Ivan. rostopic show that it is indeed subscribed to robot_post_ekf, and rxplot is showing that IMU data is sucessfully being inputted and updates over time, about 40Hz. Additionally the launch file is requesting data at 30Hz and the vo data is updated at 4Hz.

mrtc gravatar image mrtc  ( 2012-03-07 04:38:19 -0500 )edit

Hmm, I may have figured this out, according to the documentation the filter only updates when new data has been received from both sensors, i.e., the lowest frequency. I guess pose interpolation isn't possible with this package then?

mrtc gravatar image mrtc  ( 2012-03-07 06:23:51 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2012-03-07 07:30:20 -0500

Wim gravatar image

The filter only updates when new data has been received from _all_ active sensors, and is therefore limited by the rate of the slowest sensor. So the filter does not do predictions based on one of the sensor sources alone. This is a choice between a 'better prediction' and a 'faster prediction'. When the filter would provide predictions as soon as one of the sensors give some information, then you would get a prediction really fast. But that prediction would not be your most accurate prediction the filter can offer, because a better prediction is possible when information from other sensors arrives. The robot pose ekf has the build-in design decision to only provide 'best' predictions.

edit flag offensive delete link more


Thanks, Wim. I actually just read about the requirement for data from all sensors in the documentation, guess I should check that first next time!

mrtc gravatar image mrtc  ( 2012-03-07 07:58:08 -0500 )edit

Based on what you said then it would be theoretically possible to modify the robot_pose_ekf package so that in lieu of waiting for all sensors, any single sensor's measurement could be submitted to the filter, which would yield this "fast" but not "best" result. Am I correct in saying this?

mrtc gravatar image mrtc  ( 2012-03-08 05:42:24 -0500 )edit

Yes, this is definitely possible. The difference with the current codebase is large enough that the result would probably be a fork of the robot pose ekf codebase as opposed to a configuration option in the robot pose ekf.

Wim gravatar image Wim  ( 2012-03-08 06:36:07 -0500 )edit

Great to hear. I've been digging away at the code and I'll upload a fork if I'm successful.

mrtc gravatar image mrtc  ( 2012-03-08 07:40:03 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2012-03-06 11:24:12 -0500

Seen: 671 times

Last updated: Mar 07 '12