Revision history [back]

Lately I've been using robot_localization package to fuse IMU, GPS, and wheel odometry, and below is my current understanding concerning two EKFs.

Why do we need two EKFs (in the context of fusing IMU, GPS, and wheel odometry)

The short answer is that using one EKF in such case is against REP 105.

We want a map EKF so that we can report robot pose in map frame, in the form of published topic and transform. The published topic is odometry/filtered (nav_msgs/Odometry), it contains the estimated map->base_link transform information. If we directly publish the map->base_link transform, we will be against REP 105. It specifies that only map->odom, and odom->base_link transform publish is acceptable. To adhere to REP 105, we use odom ekf to publish odom->base_link transform, and map ekf to publish map->odom transform.

How do two EKFs interact with one another

This has been well addressed in Tom's above answer. Just to summarize:

1) The odom EKF fuses IMU , wheel odometry. It generates odom->base_link transform.
2) The map EKF fuses IMU, wheel odometry, and GPS. It utilizes the odom->base_link transform generated by odom EKF in two areas:
A. Calculate the map->odom transform
B. Converts sensor measurements of odom frame (like those from wheel odometry) to map frame in order to have them fused.

Interpretation of map frame and odom frame

Odom frame is usually decided by sensor source. For example, a wheel odometry may set the starting pose as odom frame. Per the "odom Frame Consistency" section in REP 105, odom frame is subject to change, in the sense that we would need to reset the odom frame when "the integrated position error accumulates enough to make the data invalid". In other words, we would probably need to reset the odom frame of wheel odometry after running for some time, if we are to leverage the position information in the sensor message.

map frame is designated by us, and can be anywhere in the map.

map EKF calculates the relative transform estimate between map and base_link, and odom EKF calculates the relative transform estimate between base_link and odom. If we fix map frame, we can track down base_link, and then we can further track down odom frame. As both EKFs keep updating their estimates, the map->odom transform is not fixed and keeps updating too.

Lately I've been using robot_localization package to fuse IMU, GPS, and wheel odometry, and below is my current understanding concerning two EKFs.

The short answer is that using one EKF in such case is against REP 105.

We want a map EKF so that we can report robot pose in map frame, in the form of published topic and transform. The published topic is odometry/filtered (nav_msgs/Odometry), it contains the estimated map->base_link transform information. If we directly publish the map->base_link transform, we will be against REP 105. It specifies that only map->odom, and odom->base_link transform publish is acceptable. To adhere to REP 105, we use odom ekf to publish odom->base_link transform, and map ekf to publish map->odom transform.

This has been well addressed in Tom's above answer. Just to summarize:

1) The odom EKF fuses IMU , wheel odometry. It generates odom->base_link transform.
2) The map EKF fuses IMU, wheel odometry, and GPS. It utilizes the odom->base_link transform generated by odom EKF in two areas:
A. Calculate the map->odom transform
B. Converts sensor measurements of odom frame (like those from wheel odometry) to map frame in order to have them fused.

Odom frame is usually decided by sensor source. For example, a wheel odometry may set the starting pose as odom frame. Per the "odom Frame Consistency" section in REP 105, odom frame is subject to change, in the sense that we would need to reset the odom frame when "the integrated position error accumulates enough to make the data invalid". In other words, we would probably need to reset the odom frame of wheel odometry after running for some time, if we are to leverage the position information in the sensor message.

map frame is designated by us, and can be anywhere in the map.

map EKF calculates the relative transform estimate between map and base_link, and odom EKF calculates the relative transform estimate between base_link and odom. If we fix map frame, we can track down base_link, and then we can further track down odom frame. As both EKFs keep updating their estimates, the map->odom transform is not fixed and keeps updating too.