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

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: https://answers.ros.org/question/2864... however I am only using diff_drive_controller, and don't have any Arduino interface.

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

trog_joint_publisher:
type: "joint_state_controller/JointStateController"
publish_rate: 50

trog_velocity_controller:
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

# Base frame_id

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_*

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

angular:
z:
has_velocity_limits    : true
max_velocity           : 2.0   # rad/s
has_acceleration_limits: true
max_acceleration       : 6.0   # rad/s^2

edit retag close merge delete

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

( 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

( 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

( 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?

( 2021-08-11 16:56:39 -0600 )edit
1

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

( 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.

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

Sort by » oldest newest most voted

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: https://www.roboteq.com/products/prod...

more