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

robot_localization dual-EKF: where did the idea come from?

asked 2019-01-04 18:13:59 -0600

Rick Armstrong gravatar image

updated 2019-01-04 18:15:22 -0600

We're currently using the dual-EKF scheme described in the documentation and the configuration example for using two instances of robot_localization: one for estimating the map->odom transformation, and another for odom->base_link transformation. So far, it's a working pretty well. My question: who invented this scheme? Is it common practice for UGV localization, and if yes, is there some literature out there about it? I haven't had any luck turning up a paper that talks about the pros/cons of this technique.

edit retag flag offensive close merge delete


I guess that would be a good question for @Tom-Moore to answer.

Martin Günther gravatar image Martin Günther  ( 2019-01-07 03:16:38 -0600 )edit

1 Answer

Sort by » oldest newest most voted

answered 2019-01-28 02:25:01 -0600

Tom Moore gravatar image

It's all really just a reflection of what's specified in REP-105. From the "Frame Authorities" section:

The transform from odom to base_link is computed and broadcast by one of the odometry sources.

The transform from map to base_link is computed by a localization component. However, the localization component does not broadcast the transform from map to base_link. Instead, it first receives the transform from odom to base_link, and uses this information to broadcast the transform from map to odom.

The whole REP is worth a read. I haven't updated r_l to work with the changes involving the earth frame, but I believe it conforms to the rest.

Note that you don't have to have a dual EKF setup. It's just that if you want your state estimate to come from fused data, rather than a single data source, then r_l can support that. Other approaches, such as letting amcl handle the map frame state estimate (and transform publication) by itself, or letting your wheel encoder odometry source (e.g., the differential drive controller) provide the odom frame state estimate/transform by itself, will also work.

edit flag offensive delete link more

Question Tools



Asked: 2019-01-04 18:13:59 -0600

Seen: 622 times

Last updated: Jan 28 '19