ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

Regarding a generic pose estimation solution, I also would like to point you to our hector_localization stack. Team Hector Darmstadt uses it since more than a year to estimate the full 3D pose of our rescue robot Hector, within the real-time loop of the Hector quadrotor and even for estimating the position, velocity and attitude of a small airplane as part of our flight mechanics lab.

The design goals have been similar to what Chad Rockey described in his answer. The core package currently provides a system model for generic 6DOF rigid body pose estimation based on pure IMU inputs (rates and accelerations), which can be specialized depending on the robot and for additional input values. As measurement models we currently provide direct and barometric height measurements, GPS postion and velocity, magnetic field sensors as heading reference and a generic pose and twist measurement to fuse nav_msgs/Odometry messages from arbitrary sources (e.g. wheel odometry or SLAM).

The stack consists of a core library without dependencies to ROS beside message types and additional packages providing a node, nodelet or Orocos Real-Time Toolkit TaskContext interface. The system and measurement models could also be implemented and loaded as plugins with some minor modifications. In the background an Extended Kalman Filter based on the Bayesian Filter Library is responsible for fusing all information into a consistent state estimate and additionally keeps track which state variables are observable and which are not.

The major drawback is that hector_localization currently lacks documentation. I hope to find the time to create some wiki pages soon. Currently I am working on a redesign to remove the dependency from BFL and use Eigen directly and give models even more flexibility, e.g. adding augmented variables to the state vector.

However, we never used robot_pose_ekf and I cannot tell if hector_localization can serve as a replacement. In general, I think it is a good idea to come up with a new solution to estimate the robot pose using all available information which is adaptable to as many robots as possbile. I would like to contribute to a community solution after having finished my thesis.