Odom Frame moving away from base_link

[Bli9sta]

Please provide the following information:

• OS: Ubuntu 24.04
• ROS 2 Distro: azzy
• Built from source or installed: Installed
• Package version: 2.8.3-1noble.20251110.163552
• Real hardware or simulation: Real Husky A200

This is the whole list of clearpath pkg versions:
dpkg -l | grep clearpath | awk '{print $2, $3}'
ros-jazzy-clearpath-bt-joy 2.8.2-2noble.20251106.172250
ros-jazzy-clearpath-common 2.8.2-2noble.20251106.172708
ros-jazzy-clearpath-config 2.8.1-1noble.20251106.165746
ros-jazzy-clearpath-config-live 2.7.0-2noble.20251008.151847
ros-jazzy-clearpath-control 2.8.2-2noble.20251106.172310
ros-jazzy-clearpath-description 2.8.2-2noble.20251106.172326
ros-jazzy-clearpath-desktop 2.7.0-2noble.20251009.205137
ros-jazzy-clearpath-diagnostics 2.8.2-2noble.20251106.172248
ros-jazzy-clearpath-generator-common 2.8.2-2noble.20251106.172611
ros-jazzy-clearpath-generator-robot 2.8.3-1noble.20251110.163454
ros-jazzy-clearpath-hardware-interfaces 2.8.3-1noble.20251110.162645
ros-jazzy-clearpath-manipulators 2.8.2-2noble.20251106.172309
ros-jazzy-clearpath-manipulators-description 2.8.2-2noble.20251106.172249
ros-jazzy-clearpath-motor-msgs 2.7.0-1noble.20251015.180538
ros-jazzy-clearpath-mounts-description 2.8.2-2noble.20251106.172250
ros-jazzy-clearpath-nav2-demos 2.7.1-1noble.20251106.165953
ros-jazzy-clearpath-offboard-sensors 2.7.0-2noble.20251008.003214
ros-jazzy-clearpath-platform-description 2.8.2-2noble.20251106.172249
ros-jazzy-clearpath-platform-msgs 2.7.0-1noble.20251015.180526
ros-jazzy-clearpath-robot 2.8.3-1noble.20251110.163552
ros-jazzy-clearpath-ros2-socketcan-interface 2.1.4-2noble.20251015.180548
ros-jazzy-clearpath-sensors 2.8.3-1noble.20251110.162645
ros-jazzy-clearpath-sensors-description 2.8.2-2noble.20251106.172249
ros-jazzy-clearpath-tests 2.8.3-1noble.20251110.162648
ros-jazzy-clearpath-viz 2.7.0-2noble.20251009.204556

We just performed a software update on our Husky as described in
https://docs.clearpathrobotics.com/docs/ros/installation/updates

After that, we noticed the odom frame constantly drifting away from the base. This causes the robot to constantly move when launching nav2 + localization + view_navigation
ros2 launch clearpath_nav2_demos nav2.launch.py use_sim_time:=false setup_path:=/
and then
ros2 launch clearpath_nav2_demos localization.launch.py use_sim_time:=false setup_path:=/ map:=/
and finally
ros2 launch clearpath_viz view_navigation.launch.py namespace:=a200_0000

even though it is not being moved at all. This is what the odom frame looks like in rviz

It is slowly but steadily drifting away from the base. Viewing the odom frame in the TF in rviz while nav2 + localization + view_navigation is running reveals:

The odom frame seems to be static with reference to the map frame. The base_link frame position is steadily shifting away from the odom parent frame. Is this normal behavior? The following images shows the vehicle drift on the map after a few minutes without actually moving it

Actual behaviour
We didnt encounter this problem prior to the update. The robot was locked in place on the map as long as it was not actually moving.

This is our robot.yaml file:

serial_number: a200-0758
version: 0
system:
  hosts:
    - hostname: huskyos1
      ip: 192.168.131.1
  ros2:
    namespace: a200_0000
    domain-id: 0
    middleware:
      implementation: rmw_fastrtps_cpp
platform:
  controller: logitech
  battery:
    model: ES20_12C
    configuration: S2P1
  drivetrain:
    control: diff_4wd
    wheels:
      front: outdoor
      rear: outdoor
  attachments:
    - name: front_bumper
      type: a200.bumper
      parent: front_bumper_mount
      xyz: [0.0, 0.0, 0.0]
      rpy: [0.0, 0.0, 0.0]
      enabled: true
    - name: rear_bumper
      type: a200.bumper
      parent: rear_bumper_mount
      xyz: [0.0, 0.0, 0.0]
      rpy: [0.0, 0.0, 0.0]
      enable: true
    - name: top_plate
      type: a200.top_plate
      model: pacs
      parent: default_mount
    - name: sensor_arch
      type: a200.sensor_arch
      model: sensor_arch_300
      parent: default_mount
      xyz: [0.25, 0.0, 0.0]
sensors:
  imu:
    - model: redshift_um7
      urdf_enabled: true
      launch_enabled: true
      parent: base_link
      xyz: [0.0, 0.0, 0.0]
      rpy: [0.0, 0.0, 0.0]
      ros_parameters:
        um7_driver:
          port: /dev/clearpath/um7
          frame_id: imu_0_link
          tf_ned_to_enu: true
  lidar3d:
    - model: ouster_os1
      urdf_enabled: true
      launch_enabled: true
      parent: default_mount
      xyz: [0.2, 0.0, 0.4]
      rpy: [0.0, 0.0, 0.0]
      ros_parameters:
        ouster_driver:
          sensor_hostname: 192.168.132.1
          lidar_port: 7502
          imu_port: 7503
          scan_ring: 15
          azimuth_window_start: 0
          azimuth_window_end: 360000
          proc_mask: PCL|SCAN
          use_system_default_qos: false
          cap_type: fins
          lidar_mode: 512x10
          point_type: original
          max_range: 3.0
          min_range: 0.6

Other notes
Add anything else you think is important.

[tonybaltovski]

The odom frame is coincident to where robot starts (aka base_link). It should move away from this as shown in your image. Localization will determine the transform from the map frame to the odom frame.

[Bli9sta]

Thank you for the fast reply.

What's surprising me is that this shift is happening even though the tires are not spinning. I would expect that the odom frame is calculated based on wheel spins + IMU reading. The IMU may be unprecise and thus measure a moving robot. But as the encoders are not registering any wheel movement, the odom frame shouldn't move at all. Or am I mistaken here?

The issue this is causing is that after a few minutes of no moving, the robot completely loses track of its position. So when setting a nav2_goal, the robot doesn't recognize its position on the map and drives somewhere randomly.