Ask Your Question

Odom frame rotates when driving linearly in RVIZ, encoder issue?

asked 2021-08-11 15:34:02 -0600

AidanK gravatar image

updated 2021-08-11 16:49:06 -0600

I believe I have an encoder issue, where one of my encoders is publishing "backwards". When I drive in a straight line, my odometry frame perfectly rotates relative to my base_link in rviz. When I rotate in place, my odometry frame moves linearly relative to my base_link in rviz. I've confirmed all the hardware is connected properly and working, so it's a software issue somewhere. Could someone guide me where to look within the diff_drive_controller package? I'm not really certain it's even possible to publish the reverse of an encoder output within that package, so I'm a bit lost.

And, this is the same issue as addressed in this post: however I am only using diff_drive_controller, and don't have any Arduino interface.

Thanks in advance

EDIT: My apologies for the formatting, but here is the configuration file for the controller.

  type: "joint_state_controller/JointStateController"
  publish_rate: 50

  type: "diff_drive_controller/DiffDriveController"

  # Encoders are connected from the back wheels
  left_wheel: ['rear_left_wheel'] 
  right_wheel: ['rear_right_wheel']
  publish_rate: 50

  pose_covariance_diagonal: [0.001, 0.001, 0.001, 0.001, 0.001, 0.03]
  twist_covariance_diagonal: [0.001, 0.001, 0.001, 0.001, 0.001, 0.03]
  cmd_vel_timeout: 0.25
  velocity_rolling_window_size: 2

  wheel_separation: 0.86
  wheel_radius: 0.127

  # Base frame_id
  base_frame_id: base_link

  # Published by robot localization
  enable_odom_tf: false

  # roboteq provides wheel velocities
  estimate_velocity_from_position: false

  # Wheel separation and radius multipliers
  wheel_separation_multiplier: 1.0 # default: 1.0
  wheel_radius_multiplier    : 1.0 # default: 1.0

  # Velocity and acceleration limits
  # Whenever a min_* is unspecified, default to -max_*

      has_velocity_limits    : true
      max_velocity           : 0.72  # m/s
      has_acceleration_limits: true
      max_acceleration       : 3.0   # m/s^2

      has_velocity_limits    : true
      max_velocity           : 2.0   # rad/s
      has_acceleration_limits: true
      max_acceleration       : 6.0   # rad/s^2
edit retag flag offensive close merge delete


Can you attach your parameter configuration file for diff drive controller ?

Fetullah Atas gravatar image Fetullah Atas  ( 2021-08-11 16:24:47 -0600 )edit

Yes, I cannot attached, but I've pasted the code in. Working to try and get it formatted but can't get it working yet

AidanK gravatar image AidanK  ( 2021-08-11 16:37:42 -0600 )edit

I think your config file looks ok, if you are sure that one of the encoder is publishing backwards, then you can play with URDF of your robot and rotate left or right wheel joint 3.14 in z axis. It’s a dirty practice but IMO it should work

Fetullah Atas gravatar image Fetullah Atas  ( 2021-08-11 16:47:56 -0600 )edit

I'm confident that somewhere along the way one of the readings is inverted from how it should be, but I'm not sure if it's the encoder, a transformation, or something else entirely.

I'm not sure what you mean by playing with the URDF file. This is a real robot, I don't have an associated URDF description of it. Could you elaborate on what you mean?

AidanK gravatar image AidanK  ( 2021-08-11 16:56:39 -0600 )edit

Even for a real robot you are supposed to have an URDF file to describe the positions of your robot links and joints relative to each other. In the configuration file you have for diff drive controller, left_wheel and right_wheel are supposed to be joint names that are specified in URDF, without the controller knowing the correct position and rotation of your wheel joints calculated odometry won’t be accurate. Have a look at husky robot or turtlebit for example URDF files, your URDF really shouldn’t be that complicated, just specify your wheel link and joints relative to base_link

Fetullah Atas gravatar image Fetullah Atas  ( 2021-08-11 17:04:29 -0600 )edit

Thank you! I see exactly what you mean now, that clarified several areas of confusion for me. That's a good starting point for me to play with, and I'll see what happens tomorrow. Again, thanks!!

I'll update here when I do indeed solve the issue, or find a work around.

AidanK gravatar image AidanK  ( 2021-08-11 17:30:09 -0600 )edit

1 Answer

Sort by » oldest newest most voted

answered 2021-08-12 15:18:31 -0600

AidanK gravatar image

I managed to 'resolve' the issue by flipping the wiring of the encoder that was giving the opposite readings. This is not a full solution, as now I believe I have that encoder technically wired backwards, but it does fix my odometry issue, and now allows Gmapping to construct a reasonable map.

I will update at a later point if I find the root cause of the issue, but this certainly works for now. I'm also not entirely sure how the diff_driver_controller package works, and maybe the way I have my motor mounted I need to account for the flip somewhere. Either way, take away is switching the direction of the encoder readings solved my issue.

For reference, this is my motor controller:

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


Asked: 2021-08-11 15:34:02 -0600

Seen: 52 times

Last updated: Aug 12