0
$\begingroup$

Rosanswers logo

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.


Originally posted by mrtc on ROS Answers with karma: 112 on 2012-03-06

Post score: 0


Original comments

Comment by Ivan Dryanovski on 2012-03-06:
Does the robot pose ekf node subscribe correctly to the imu date? Some simple debugging tools: 1) rxplot 2) "rostopic info /imu_data"

Comment by mrtc on 2012-03-07:
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.

Comment by mrtc on 2012-03-07:
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?

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by Wim with karma: 2915 on 2012-03-07

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by mrtc on 2012-03-07:
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!

Comment by mrtc on 2012-03-08:
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?

Comment by Wim on 2012-03-08:
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.

Comment by mrtc on 2012-03-08:
Great to hear. I've been digging away at the code and I'll upload a fork if I'm successful.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.