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

Revision history [back]

First to answer the question:

Initialization

robot_pose_ekf initializes to the odometry just so that it is comparable with the wheel odometry. It's arbitrary and could be fixed.

Corrections

robot_pose_ekf only uses the EKF logic to determine dx, dy, and dheading (equivalent to calculating the Twist) for the N sensors. It then integrates these outside of the EKF - producing an odometry - not a localization estimate. This is common when you do not have absolute references and your variance estimates for x, y, and yaw will tend toward infinity.

When using GPS in robot_pose_ekf, it is difficult to not lose the global reference. If you chose to use the global reference, then you tend to wash out your other corrections in GPS noise and your initial "corrections" will tend to be very large.


The future: I'm working on an odometry and localization filter to be released in Hydro. https://github.com/chadrockey/graft

It's built on Eigen and is probably going to be a UKF implementation, thus the generic name, although in version + N, I may support EKF implementations as well.

It's going to start out small and replace robot_pose_ekf level of functionality. The eventual difference is that it will also support global localization sensors. The best way to add GPS to these measurements is through a chain like the following:

drifty GPS frame (like 'map' from amcl) -> fused odometry -> robot

Then the GPS version just sends corrections from the origin of the fused odometry to the GPS origin/UTM origin. This will likely rely on geographic_info for the GPS to meter conversion, so I don't expect it the integration to be 100% in Hydro.

I'm not taking feature requests at this time, as my priority is to get something out for Hydro so that we can all stop struggling with using robot_pose_ekf outside of what it was designed for. It will support nav_msgs::Odometry and sensor_msgs::Imu in various configurations for the locally continuous version, so between this and my other projects, I'd prefer to properly unit test and rostest as opposed to supporting modifications just quite yet.