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

Revision history [back]

Your video looks as if there is something wrong with your odometry data. Did you try setting the fixed frame in RViz to /odom (or whatever your odometry frame is called)? If you do that and show the laser scans, the scans should still be roughly aligned while the robot is moving around. That needs to be working before moving on to AMCL.

Your video looks as if there is something wrong with your odometry data. It looks as if the odometry information tells AMCL that it's turning twice as fast than it actually is. That can be caused for example by having a wrong wheel size or wheel distance in the odometry calculation.

Did you try setting the fixed frame in RViz to /odom (or whatever your odometry frame is called)? If you do that and show the laser scans, the scans should still be roughly aligned while the robot is moving around. That needs to be working before moving on to AMCL.

Your video looks as if there is something wrong with your odometry data. It looks as if the odometry information tells AMCL that it's turning twice as fast than it actually is. That can be caused for example by having a wrong wheel size or wheel distance in the odometry calculation.

Did you try setting the fixed frame in RViz to /odom (or whatever your odometry frame is called)? If you do that and show the laser scans, the scans should still be roughly aligned while the robot is moving around. That needs to be working before moving on to AMCL.

Update: (how to compute the odometry)

There is some code that I wrote for computing the odometry here: gazebo_ros_diffdrive_uos.cpp:196-207

It's a Gazebo plugin for a six-wheeled robot, but it works basically the same on a real robot or with a different number of wheels.

It computes the odometry pose from the wheel velocities, and it also has a parameter that accounts for slippage etc. when turning corners (where the wheels are "fighting" each other). That parameter is called turning_adaptation in the code, and some values that we used both in Gazebo and on different physical robots are 0.64, 0.69, 0.95 (just to give you some idea). We found those parameters by visualizing the laser scan in the odom frame and rotating the robot in place. If it looked as if the robot rotated too fast, we reduced turning_adaptation, if it was too slow, we increased it.

That parameter turning_adaptation is the same what I called angular_factor in the comments below. (Both are bad names). The Gazebo plugin doesn't have a linear_factorsince we never needed that. In the code, it would be a factor that's multiplied onto the variable dr.

Your video looks as if there is something wrong with your odometry data. It looks as if the odometry information tells AMCL that it's turning twice as fast than it actually is. That can be caused for example by having a wrong wheel size or wheel distance in the odometry calculation.

Did you try setting the fixed frame in RViz to /odom (or whatever your odometry frame is called)? If you do that and show the laser scans, the scans should still be roughly aligned while the robot is moving around. That needs to be working before moving on to AMCL.

Update:Update (Mon May 2): (how to compute the odometry)

There is some code that I wrote for computing the odometry here: gazebo_ros_diffdrive_uos.cpp:196-207

It's a Gazebo plugin for a six-wheeled robot, but it works basically the same on a real robot or with a different number of wheels.

It computes the odometry pose from the wheel velocities, and it also has a parameter that accounts for slippage etc. when turning corners (where the wheels are "fighting" each other). That parameter is called turning_adaptation in the code, and some values that we used both in Gazebo and on different physical robots are 0.64, 0.69, 0.95 (just to give you some idea). We found those parameters by visualizing the laser scan in the odom frame and rotating the robot in place. If it looked as if the robot rotated too fast, we reduced turning_adaptation, if it was too slow, we increased it.

That parameter turning_adaptation is the same what I called angular_factor in the comments below. (Both are bad names). The Gazebo plugin doesn't have a linear_factorsince we never needed that. In the code, it would be a factor that's multiplied onto the variable dr.