Revision history [back]

I would have thought that the odom->base_link transform ought to "reset" to 0 whenever the map->odom tf is update

I'm not clear on what this would achieve.

The first thing I want to suggest is that you simplify your config. You have a whole bunch of advanced parameters in there that should only be added once you have your setup working as you want.

That aside, there are a bunch of issues with what you're trying to do. First, I'd recommend that you read REP-105 if you haven't yet. The thing to bear in mind is that tf does not allow a given frame to have two parents. Your particle filter is technically calculating the map->base_link transform, and your EKF instance is calculating odom->base_link. But tf doesn't allow that, so your particle filter is (or should be) taking in the odom->base_link transform and using that to generate a map->odom transform. This provides a consistent tf tree.

In a normal "two tier" setup like this, you would have your particle filter (or a second EKF instance) publish the pose data and its transform, and then the EKF would just fuse wheel odometry and IMU data (continuous input sources only).

What I think you're trying to do is "fill in the gaps" between your particle filter updates. If so, this is the wrong way to go about it. You are fusing your map frame pose into the odom frame EKF, which is then using that information to generate the odom->base_link transform, which the particle filter is then using to generate the map->odom transform again. Without going through the math, I think you're creating a kind of positive feedback loop that will cause the state estimate to change more rapidly than it is.

If you are just trying to create a smooth state estimate, you have three options:

1. Change the particle filter so it can do predictions and provide higher-rate updates to the map->odom transfrom, and then stop fusing the particle filter pose in the EKF.
2. Nodes like move_base will require you to have both a map and an odom frame for global and local planning, respectively, but if you aren't using move_base or just generally don't require both frames, then change the output frame of the particle filter to odom, and turn off the transform publication for it. Then the EKF will use the particle filter data (again, whose frame_id should now be odom) whenever it's available, and fill in the gaps with fused odom/IMU data.
3. Similar to (2), you can introduce another EKF. You need to once again tell your particle filter to not publish any transforms, but you can make your map frame EKF fuse the particle filter, IMU, and wheel encoder data, and then make the odom frame EKF only fuse the wheel encoder and IMU data.

(3) is a common practice for mobile robots, where you fuse the same continuous velocity data in both EKFs, but in the map frame one, you also fuse a global pose estimate.