Incorrect odometry when turning vehicle with Ackermann steering controller (ROS2 Humble).

[aizmailovs]

Description of the bug When turning the vehicle with Ackermann steering controller, the odometry gets wrong. This issue looks similar to the #789.

To Reproduce To reproduce the bug, launch the car-like robot with the ackermann_steering_controller. My .yaml file is:

controller_manager:
  ros__parameters:
    update_rate: 50

    use_sim_time: true

    joint_state_controller:
      type: joint_state_broadcaster/JointStateBroadcaster

    ackermann_steering_controller:
      type: ackermann_steering_controller/AckermannSteeringController

ackermann_steering_controller:
  ros__parameters:

    reference_timeout: 2.0
    front_steering: true
    open_loop: false
    velocity_rolling_window_size: 10
    position_feedback: true
    use_stamped_vel: true   # Use true to make controller topic /ackermann_steering_controller/reference listen to TwistStamped type data
                            # Use false ro make controller topic /ackermann_steering_controller/reference_unstamped listen to Twist type data
    rear_wheels_names: [right_rear_joint, left_rear_joint]
    front_wheels_names: [front_steer_right_joint, front_steer_left_joint]

    wheelbase: 0.65               # Distance between front and rear wheel axes
    front_wheel_track: 0.605      # Distance between front wheels
    rear_wheel_track: 0.605       # Distance between rear wheels
    front_wheels_radius: 0.165
    rear_wheels_radius: 0.165

joint_state_controller:
  ros__parameters:
    type: joint_state_controller/JointStateController

Reality and expected behavior While the robot is going in a straight line, the odometry is pretty accurate, but when the robot turns the odometry starts to spin with much shorter radius than expected.

odometry2.webm

Just curious if anybody else have similar issue with Ackermann steering controller.

[aizmailovs]

Two (out of three) ways to calculate the odometry is to use position of the steering whells with position of the traction wheels or with the velocity of the traction wheels according to: https://github.com/ros-controls/ros2_controllers/blob/13a43c32b5b4d0040c96d4e192db4f1ed6d4f046/ackermann_steering_controller/src/ackermann_steering_controller.cpp#L57-L91 https://github.com/ros-controls/ros2_controllers/blob/13a43c32b5b4d0040c96d4e192db4f1ed6d4f046/steering_controllers_library/src/steering_odometry.cpp#L116-L140 https://github.com/ros-controls/ros2_controllers/blob/13a43c32b5b4d0040c96d4e192db4f1ed6d4f046/steering_controllers_library/src/steering_odometry.cpp#L165-L175 The thing I do not really understand why the same value (rear_right_wheel_value, rear_left_wheel_value) is used as inputs for two different functions (update_from_position and update_from_velocity), which expect positions or velocities of the traction wheels respectively.

Both ways to calculate the odometry result in similar outcome as on a video above.

[kartman88]

I'm trying to reproduce your error but when I launch everything I don't have odom fixed frame in Rviz. But the odometry topic is published. Is there some param to set to enable odometry in the controller settings?

[aizmailovs]

I did not use Rviz, refer to the https://github.com/ros-controls/ros2_controllers/issues/937#issuecomment-1875040977.

I have only looked at the topic "/ackermann_steering_controller/odometry" for odometry data from the controller. Then, I visualized it.

[BalazsPh21]

I think I have the same issue and also looking for a solution. Someone installed my project and reported the same issue. Also, running it in Docker doesn't help.

Here is a recording I made of what I believe is a really similar problem:

https://github.com/ros-controls/ros2_controllers/assets/66018083/75d2d3af-1c27-4f43-bd40-8e657bc769ef

In case you want to try it yourself, you can find my project here. I hope it helps.

[rbretmounet]

I think I have the same issue and also looking for a solution. Someone installed my project and reported the same issue. Also, running it in Docker doesn't help.

Here is a recording I made of what I believe is a really similar problem:

Screencast.from.2024.01.18.18_52_49.mp4 In case you want to try it yourself, you can find my project here. I hope it helps.

@BalazsPh21 @aleksandrsizmailovs Did you ever resolve this issue?