robot_pose_ekf ignoring imu_data

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

112 ●7 ●9 ●15

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?

EDIT:

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.

Comments

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 ( 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 ( 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 ( 2012-03-07 06:23:51 -0500 )edit

add a comment

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

Wim
2915 ●14 ●34 ●43

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

Comments

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 ( 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 ( 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 ( 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 ( 2012-03-08 07:40:03 -0500 )edit

add a comment

robot_pose_ekf ignoring imu_data

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

robot_pose_ekf ignoring imu_data edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

robot_pose_ekf ignoring imu_data