Clarification on potential TF conflict between diff_drive plugin and ekf_filter_node_odom in GPS waypoint follower demo

[Gianstiff]

While reviewing the gps_waypoint_follower_demo, I noticed that the robot SDF used in the demo includes a diff_drive plugin that publishes odometry:

https://github.com/ros-navigation/nav2_minimal_turtlebot_simulation/blob/8b63166dd76829aaa558bf8e801ac9c834a3a56c/nav2_minimal_tb3_sim/urdf/gz_waffle_gps.sdf.xacro#L545

At the same time, the demo uses robot_localization with the ekf_filter_node_odom, which (when world_frame == odom_frame) broadcasts its own odom → base_link transform.

According to the robot_localization documentation:
https://docs.ros.org/en/melodic/api/robot_localization/html/preparing_sensor_data.html#odometry

“Some robot drivers also broadcast this transform along with their odometry message. If users want robot_localization to be responsible for this transform, then they need to disable the broadcast of that transform by their robot’s driver.”

Given this, would it be appropriate to disable the diff_drive plugin’s odometry TF broadcast in the demo to ensure there are no conflicting TF publishers?

Thanks in advance!

[SteveMacenski]

We don't allow the diff drive plugin to publish odometry, it is disabled. I believe that TF is used for the joint states of the wheels. Robot Localization fuses the odometry messages (non-TF) from this plugin + the IMU (if used) so that it mimicks much closer to a 'normal' non-simulated robot which would practically use that fusion for the wheel encoders + IMU to get a decent state estimation.

It is more or less setup this way to mimic the behavior of a real-world robot's architecture.

Let me know if you have any more questions :-)

[Gianstiff]

Thanks a lot for the explanation — that helps clarify the intended architecture.

I’m still trying to fully align my understanding with the behavior I’m observing.
In my setup (following the same plugin configuration used in the tutorial), I notice that the diff_drive plugin appears to publish TF data. For example, when I run:

ign topic -t /<namespace>/tf -e

I can see TF messages being produced and then forwarded through the Gazebo → ROS 2 bridge to /tf. These seem to include an odom → base_link transform.

Here is the plugin configuration I’m using, which matches the tutorial:

<plugin filename="ignition-gazebo-diff-drive-system" name="ignition::gazebo::systems::DiffDrive">
    <left_joint>front_left_wheel</left_joint>
    <left_joint>rear_left_wheel</left_joint>
    <right_joint>front_right_wheel</right_joint>
    <right_joint>rear_right_wheel</right_joint>
    <wheel_separation>${track}</wheel_separation>
    <wheel_radius>${wheel_radius}</wheel_radius>

    <topic>${robot_namespace}/cmd_vel</topic>
    <odom_topic>${robot_namespace}/diff_drive/odom</odom_topic>
    <odom_publish_frequency>10</odom_publish_frequency>
    <tf_topic>${robot_namespace}/tf</tf_topic>
    <gz_frame_id>${robot_namespace}/odom</gz_frame_id>
    <child_frame_id>${robot_namespace}/base_link</child_frame_id>
</plugin>

Since you mentioned that the odometry TF from this plugin is disabled in the demo, I just wanted to check whether there is an additional parameter or configuration step in the example that handles this. It’s possible I’m simply overlooking something.

Thanks again for the clarification — I appreciate the guidance and just want to make sure I’m following the intended setup correctly.