@coffinfish I think actually the code should be fixed to use ekf_filter_node so that it is consistent with the other distribution branches. We have tutorials for pre-Jazzy using ekf_filter_node and switching the name seems unncessary in the code.

If you update these launch files and the name in the config file, that would have the same impact: https://github.com/search?q=repo%3Aros-navigation%2Fnavigation2_tutorials%20ekf_node&type=code

This tutorial page is shared with Pre- and Post- Jazzy's setup, so I think we should keep the name the same across the board so it doesn't break either users' setup guide

That makes a lot of sense. I (hopefully) ended up doing the changes you mentioned above correctly. I kept the most of the original documentation the same and only changed the config yaml file and the name parameter in the launch file.

@coffinfish There's also a few places in this repository you missed on the following pages (grep / search to find):

• docs.nav2.org/setup_guides/sensors/mapping_localization.rst

  Line 144 in 73fb3aa

  We will first launch ``display.launch.py`` which launches the robot state publisher that provides the ``base_link`` => ``sensors`` transformations in our URDF, launches Gazebo that acts as our physics simulator, and provides the ``odom`` => ``base_link`` from the differential drive plugin or the ekf_node. It also launches RViz which we can use to visualize the robot and sensor information.

• docs.nav2.org/setup_guides/odom/setup_robot_localization.rst

  Line 9 in 73fb3aa

  A usual robot setup consists of at least the wheel encoders and IMU as its odometry sensor sources. When multiple sources are provided to ``robot_localization``, it is able to fuse the odometry information given by the sensors through the use of state estimation nodes. These nodes make use of either an Extended Kalman filter (``ekf_node``) or an Unscented Kalman Filter (``ukf_node``) to implement this fusion. In addition, the package also implements a ``navsat_transform_node`` which transforms geographic coordinates into the robot’s world frame when working with GPS.

The other PR is also missing a couple, but once those are added, this is an easy merge! Thanks for the help and noticing this discrepancy!

It looks like #812 supersedes this

@coffinfish Thanks for the effort here!