Revision history [back]

One option would be to turn off the map->odom transform broadcast in amcl, and then include both amcl and the UWB sensor output as inputs to the second instance of ekf_localization_node. As long as they both report data in the same coordinate frame (or you provide the necessary transforms so they can), it should work.

If I give output of AMCL and UWB to second instance of ekf_localization_node, it will give me the required transformation (map_frame -> odom_frame) and will publish the output odometry message on odometry/filtered topic but I am using move_base which expects robot pose on /amcl_pose topic. So, I can remap the output on odometry/filtered to amcl_pose and change the message type from nav_msgs/Odometry to geometry_msgs/PoseWithCovarianceStamped, Does that sound okay?

Yes, that's really the point of topic remapping. I would advise not remapping the output of the EKF to /amcl_pose, because you're using /amcl_pose as an input to the filter. Instead, do the remapping within the launch file for move_base, such that move_base now expects /odometry/filtered.

As far as your second question, read the frame descriptions here. Both instances actually generate a transform from the world_frame to the base_link_frame, so internally, you have map->base_link and odom->base_link. But tf doesn't allow a frame to have two parents, so the second EKF instance automatically detects this situation (because world_frame and map_frame match) and uses its internal map->base_link transform, along with the existing odom->base_link transform that is broadcast by the first EKF instance, to produce a map->odom transform, which it then broadcasts. For your use case, I would make sure the UWB data has a frame_id of map.