Ask Your Question
0

diff drive controller giving wrong odometry data (radius and separation multipliers)

asked 2020-09-07 13:47:47 -0500

jorgemia gravatar image

I'm working on a 4WD skid steer robot which uses ros control and the diff drive controller.

If I set my wheel radius multiplier to 1.0, the robot seems to go extremely slow (doesn't seem to be moving at the speed I tell it to) and the odometry data seems off. When checking the odometry topic published by the diff drive controller, if I move the robot forward 60cm (checked with a ruler), the controller thinks the robot has moved over 2m...

If I change my radius multiplier to 0.195 the position data of the odometry seems more accurate, reflecting my real life measurements. With this multiplier however, when I go at very high speed and look at the odom TF in Rviz the robot starts going backwards suddenly (in Rviz and in the odom topic as well but the actual robot is moving forward). This doesn't happen when the multiplier is set to 1.0 though.

What could possibly be happening? I understand that I have to play with the wheel separation multiplier because of the skid steer nature of the robot vs differential style, but the radius multiplier should stay at 1? I have checked my urdf and hardware interface and don't think they're the issue but anything I should look for?

Here's my diff drive config file:

robot_joint_publisher:
  type: "joint_state_controller/JointStateController"
  publish_rate: 100

robot_velocity_controller:
  type: "diff_drive_controller/DiffDriveController"
  left_wheel: ['front_left_wheel', 'rear_left_wheel']
  right_wheel: ['front_right_wheel', 'rear_right_wheel']
  publish_rate: 100
  pose_covariance_diagonal: [0.001, 0.001, 0.001, 0.001, 0.001, 0.03] #Need to define?
  twist_covariance_diagonal: [0.001, 0.001, 0.001, 0.001, 0.001, 0.03] #Need to define?
  cmd_vel_timeout: 0.25
  velocity_rolling_window_size: 2

  wheel_separation : 0.42 #Distance between left and right
  wheel_radius : 0.1651

  # Base frame_id
  base_frame_id: base_link

  # Odometry fused with IMU is published by robot_localization, so
  # no need to publish a TF based on encoders alone.
  enable_odom_tf: true

  # Navvy hardware provides wheel velocities
  estimate_velocity_from_position: false

  # Wheel separation and radius multipliers
  wheel_separation_multiplier: 2.0 # husky 1.875 - Will need to adjust based on odom readings
  wheel_radius_multiplier    : 0.195 # default: 1.0

  # Velocity and acceleration limits - To define
  # Whenever a min_* is unspecified, default to -max_*
  linear:
    x:
      has_velocity_limits    : true
      max_velocity           : 3.0   # m/s
      has_acceleration_limits: true
      max_acceleration       : 3.0   # m/s^2
  angular:
    z:
      has_velocity_limits    : true
      max_velocity           : 9.0   # rad/s
      has_acceleration_limits: true
      max_acceleration       : 6.0   # rad/s^2
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2020-09-10 09:49:40 -0500

jorgemia gravatar image

So I figured out the reason behind having to set my multiplier to 0.195 was that my hub motors have a 5:1 gearbox inside and I was not considering that in my hardware interface. So I was multiplying by 0.195 (essentially 0.2, the gear ratio) to get accurate readings. By considering the gear ratio in my hardware interface, I now get accurate readings.

In terms of the position data suddenly reversing at high speeds, I believe this has to do with my code and some overflow management I used from someone else that was wrong for my application. I've now changed my motor controller code to calculate the wheel position using a different function provided by the motor controller and no longer get the problem.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2020-09-07 13:47:47 -0500

Seen: 724 times

Last updated: Sep 10 '20