Drifting odom when rotating my robot
Hi,
I am trying to create a simple robot based on the NXT Lego Mindstorrms and an RPLIDAR A2. The goal of my project is to get it to move around autonomously in a simple map I have created. Please see RxROS for more information about the project and the ROS components that have used.
I have run into a problem I hope you can help me with: The following picture shows the robot and laserscan seen from the odom frame. acml and map has been disabled/turned off. The robot has not moved and the laserscan shows straight lines. Observe that the laserscan decay time has been set to 30 sec as I want to demonstrate some problems with the odometry of the robot. Please also observe the small red dots in the picture. They are USB wires that runs from my PC to the robot.
The next picture shows the laserscan after the robot has moved straight forward and backwards a couple of times. There is very little drift in the odometry of robot. When amcl is activated it is actually able to correct the position of the robot. This indicates to me that the drift of the odometry is acceptable.
Now we come to the actual problem. When I start to rotate the robot the drift of the odometry goes crazy as shown in the picture below. I cannot determine the actual cause of this drift, but it has a bad impact on amcl. I actually thinks it disable amcl as I see no corrections of the position after I have make a couple of turns with the robot.
I have some ideas of what the problem could be:
- The nxt_base_controller (see graph below) uses some strange constants to calculate the effect/effort that it publish in the joint_command topic. It looks to me that the nxt_base_controller is adapted to a dedicated robot and is not a generic algorithm - but I could easily be mistaken here.
- The motor of the robot sounds to be more busy/loaded when the robot turns compared to when it drives straight ahead. This could be caused by the USB cables.
- The nxt_base_controller does not take acceleration into account, but brings the robot up to full speed immediately. Its not really a desired effect, but is seems not to be a problem when the robot drives straight ahead.
I cannot really isolate problem or find a work around/solution to it. So, if you have any comments or ideas of could cause this problem please let know.
I don't know if it is of any help, but here are finally a couple of views of the robot shown in rosgraph. They should give an idea of the ROS components I have used:
Are the "base_parameters" correctly calibrated? I found this two parameters in a launch file in the repo you posted:
If they are not correct that would cause the drifting you are observing.
Hi Juan,
Thanks a lot for your comment. The parameters do not represent the actual values of the robot I was using for the test. The numbers represent a early version of the Lego robot I was using. But never the less, I think you have have hit the origin of the problem...
... I was actually testing with a wheel_basis that was 5 mm's off. This does explain some of the behavior, but not all of it. I have made some further investigation of the problem. This time with with a slightly enhanced Lego robot where the new wheel radius and basis has been double checked: ...
moving forward
Turn, full speed, cables on ground
Turn, full speed, cables in air
As can be seen from the drawings there is still some drift in the odom. However there seems not to be any difference between when the USB cables are on ground on in air.