Odometry drift in ackermann controller

[Sarxell]

Hi @miguelriemoliveira , Doing tests with the two odometries I came across a problem. Since the robot drifts in gazebo, the odometry from the ackermann controller also drifts which in the long time gets a very different value from the odometry of the python code. The values in question:

Python odometry

pose: 
  pose: 
    position: 
      x: 33.52832900205622
      y: 0.0
      z: 0.0
    orientation: 
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
...
twist: 
  twist: 
    linear: 
      x: 0.0
      y: 0.0
      z: 0.0
    angular: 
      x: 0.0
      y: 0.0
      z: 0.0

ackermann controller odometry

pose: 
  pose: 
    position: 
      x: 33.518611540783525
      y: -0.01387301223711008
      z: 0.0
    orientation: 
      x: 0.0
      y: 0.0
      z: -0.00020072386327466468
      w: 0.9999999798549651
...
twist: 
  twist: 
    linear: 
      x: -1.9479035983982484e-05
      y: 0.0
      z: 0.0
    angular: 
      x: 0.0
      y: 0.0
      z: 4.910143044064103e-12

What should I do?

• Improving the urdf model with the inertia and mass which is what some answers tell me to check. https://answers.gazebosim.org//question/12952/robot-base-slowly-drifting/ https://github.com/ROBOTIS-GIT/turtlebot3_simulations/issues/149

• Should I add drift in the python code? Doesn't seem very possible but I know the real car also drifts

-Should I leave it? With this the values in the long term become imprecise...

[Sarxell]

With inertial values tending to infinite (in this case 1000000000000.0) we get values like this:

pose: 
  pose: 
    position: 
      x: 35.28116784527102
      y: 1.924409111229197e-09
      z: 0.0
    orientation: 
      x: 0.0
      y: 0.0
      z: -2.640759797793107e-09
      w: 1.0
...
twist: 
  twist: 
    linear: 
      x: 2.1270807115669754e-08
      y: 0.0
      z: 0.0
    angular: 
      x: 0.0
      y: 0.0
      z: 8.226988294801665e-10

But I can use real values (mass, the inertia formula) which gives us a value more realist ... Do I use the real value, compare with the no-drift odometry? Do I try to find a formula which can gives us the car drift to more precise results?

[miguelriemoliveira]

Do I use the real value, compare with the no-drift odometry? Do I try to find a formula which can gives us the car drift to more precise results?

Hi @Sarxell thanks for the work. I think you should use a python code for computing the odometry in a realistic way, but its expected that the odometry has some error, especially after several meters. I think the first results you showed are good.

[Sarxell]

Okay, since the python code still doesn't compute the odometry realistically I will look into it. The odometry node from the ackermann_steering_controller may have something more complex to give better results

[Sarxell]

Hi @miguelriemoliveira Seeing the odometry.cpp I discovered that they use some variables to simulate the drift, such as multiplying the angular velocity by 0.5 to create the wheel slippage and others which can be seen below in the code.

  void Odometry::integrateRungeKutta2(double linear, double angular)
  {
    const double direction = heading_ + angular * 0.5;

    /// Runge-Kutta 2nd order integration:
    x_       += linear * cos(direction);
    y_       += linear * sin(direction);
    heading_ += angular;
  }

  /**
   * \brief Other possible integration method provided by the class
   * \param linear
   * \param angular
   */
  void Odometry::integrateExact(double linear, double angular)
  {
    if (fabs(angular) < 1e-6)
      integrateRungeKutta2(linear, angular);
    else
    {
      /// Exact integration (should solve problems when angular is zero):
      const double heading_old = heading_;
      const double r = linear/angular;
      heading_ += angular;
      x_       +=  r * (sin(heading_) - sin(heading_old));
      y_       += -r * (cos(heading_) - cos(heading_old));
    }
  }

Does the professor think that it is a good idea to recreate these functions in python? I can also create a new code with these changes and compare both, with simulated data and with the real vehicle values

[miguelriemoliveira]

Hi @Sarxell ,

I don't think it is a good idea to recreate this sliding in python. The question is that the simulation is trying to emulate sliding, which is something that occurs in reality and that the odometry cannot tackle. It is one of the reasons why odometry accumulates error.

So I would leave the python odometry calculation as is, unless there is a realistic way of getting information about the sliding which can be used to more accurately estimate the odometry, but I think there is not.

I like simulation a lot, but I think in this case we are reaching the limits of simulation. I think that If we do more work on the odometry node we would be fine tuning our node to the intricacies of the simulation, which may not be realistic.

[Sarxell]

So I would leave the python odometry calculation as is, unless there is a realistic way of getting information about the sliding which can be used to more accurately estimate the odometry, but I think there is not.

I also don't think so , I only found ways how to introduce errors

Since I introduced the real masses and the inertia formula for the vehicle it drifts even more since the vehicle was with masses of 2 , 0.3 etc .. but I will send here the results

[manuelgitgomes]

Done