Robotics StackExchange | Archived questions

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.

initial setup

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.

moving_forward

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.

rotating

I have some ideas of what the problem could be:

  1. The nxtbasecontroller (see graph below) uses some strange constants to calculate the effect/effort that it publish in the jointcommand topic. It looks to me that the nxtbase_controller is adapted to a dedicated robot and is not a generic algorithm - but I could easily be mistaken here.
  2. 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.
  3. The nxtbasecontroller 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:

rosgraph

rosgraph2

Asked by Henrik on 2018-12-19 21:02:50 UTC

Comments

Are the "base_parameters" correctly calibrated? I found this two parameters in a launch file in the repo you posted:

<param name="wheel_radius" value="0.022"/>
<param name="wheel_basis" value="0.055"/>

If they are not correct that would cause the drifting you are observing.

Asked by juanlu on 2019-01-04 04:19:12 UTC

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

Asked by Henrik on 2019-01-06 13:03:40 UTC

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

Asked by Henrik on 2019-01-06 13:08:50 UTC

  1. The drawing below shows again the robot when it is driving forwards and backwards. The odom looks very fine.
    moving forward

Asked by Henrik on 2019-01-06 13:28:28 UTC

  1. The next two drawings show the change in the odom when the robot turns left and right with full speed. The first drawing is with the USB cables on the ground and the other the USB cables in air ...

Asked by Henrik on 2019-01-06 13:47:06 UTC

Turn, full speed, cables on ground
Turn, full speed, cables in air

Asked by Henrik on 2019-01-06 13:49:17 UTC

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.

Asked by Henrik on 2019-01-06 13:55:02 UTC

  1. The following two drawings show the change in the odom when the robot turns left and right with 70% speed. The first drawing is with the USB cables on the ground and the other the USB cables in air ...

Asked by Henrik on 2019-01-06 13:57:09 UTC

Turn, 70% speed, cables on ground
Turn, 70% speed, cables in air

Asked by Henrik on 2019-01-06 14:00:10 UTC

There is still some drift in the odom - it is not as bad as with full speed. The USB cables seems again to have no impact on the odom whether they are on ground or in air.

Asked by Henrik on 2019-01-06 14:03:28 UTC

I finally tried to make the same experiment with a Turtlebot3 Burger, The result was surprisingly similar to what my Lego robot shows - Actually it looks a bit worse? Is this the expected behavior???

Asked by Henrik on 2019-01-06 14:06:41 UTC

Turning Turdelbot3 Burger

Asked by Henrik on 2019-01-06 14:09:43 UTC

My case is similar. I am using a RPLIDAR A1 with a differential robot and when the robot moves back and forth it works acceptable, but when it rotates around its own axis there is a bad drift in AMCL.

Any suggestion?

Asked by mateusguilherme on 2019-11-06 09:27:14 UTC

Answers