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!
Originally posted by AidanK on ROS Answers with karma: 16 on 2021-08-03
Post score: 0
Original comments
Comment by Mike Scheutzow on 2021-08-09:
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.
Comment by AidanK on 2021-08-11:
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?
Comment by Mike Scheutzow on 2021-08-11:
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.
