ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

LaserScan rotates when moving

asked 2021-08-03 18:07:24 -0600

AidanK gravatar image

updated 2021-08-09 16:35:25 -0600

I'm new to ROS, and picked up a robot that used to be able to perform SLAM with gmapping. I'm working on getting it up and running after years of sitting in a lab, but I can't get the robot to map or localize in it's surroundings.

With teleoperation, I noticed that driving in a straight line causes the Velodyne point cloud readings to rotate. For example, it takes about 15 or 20 feet to complete a full rotation. Driving straight shouldn't cause any rotation at all, so this is clearly wrong. Can anyone point me in the right direction? Is there some small setup mistake I'm making, am I misinterpreting rviz, is there a checkbox I'm missing in rviz, etc.? I suspect it's an odometry related issue, simply because the map rotates when my wheels rotate, but I'm also not really sure how to tackle that yet.

I also have half a dozen deprecation warning when launching the move_base node, but I assume those will be easier to sort out once I see the Velodyne point cloud readings function as expected. Right now if I set a 2d goal, the robot just moves back and forth a few feet for a couple of seconds before aborting because a controller couldn't be found. I assume the primary culprit at this point is because of the rotation of the Velodyne point cloud.

EDIT: After playing around, I've found the problem is entirely within my odometry. The odometry frame relative to the base frame rotates when driving straight, and moves linearly when rotating. I believe it's a hardware issue, but still looking into it.

Thanks in advance!

edit retag flag offensive close merge delete


Are you using diff_drive_controller/DiffDriveController? Have you checked the successive values from the wheel encoders? When robot is moving forward, both wheel axels should report increasing values for their angular position i.e. positive delta.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-08-09 18:19:58 -0600 )edit

I am, what is a good way to directly check the wheel encoder values?

When using rviz and checking the TF, it appears that one of them is reporting in the exact opposite direction it should be, leading to the behavior that I'm seeing. Is it possible for one of the encoders to be reversed?

AidanK gravatar image AidanK  ( 2021-08-11 14:21:57 -0600 )edit

The encoder isn't really "reversed"; it's just mounted on the axel facing the other direction. And there's a trick to handle it: flip the corresponding ~{left|right}_wheel_radius_multiplier to a negative value.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-08-11 19:12:19 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2021-08-11 15:27:33 -0600

AidanK gravatar image

updated 2021-08-11 19:34:10 -0600

Closing this question out. I haven't solved the issue, but I now understand that it's an odometry issue with the diff_drive_controller. I've posted a new question to allow more direct discussion. Thanks for all the feedback!

Followup post here:

edit flag offensive delete link more



Please provide cross links with follow up posts like this so others can follow your logic in the future.

tfoote gravatar image tfoote  ( 2021-08-11 17:37:59 -0600 )edit

Thanks for the edit/update!

tfoote gravatar image tfoote  ( 2021-08-11 19:42:27 -0600 )edit

answered 2021-08-09 17:27:02 -0600

tfoote gravatar image

Yeah, that sounds like a hardware/sensor issue if the odometry is systematically drifting. You might also want to check if there's any sort of calibration for wheel sizes etc.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2021-08-03 18:07:24 -0600

Seen: 532 times

Last updated: Aug 11 '21