TrackedVehicleSystem Yaw Incorrect

[Rob-Dawson]

Environment

• OS Version: 24.04
• Source or binary build?
  gz-sim 8.7.0

Description

• Expected behavior: Yaw in Gazebo and odom should be accurate or reasonably accurate
• Actual behavior: Wildly Inaccurate

Steps to reproduce

1. Launch the Standard tracked_vehicle_simple.sdf
2. Print Odom to terminal
3. Compare

Output

I know the odom is printed as a quaternion so I converted it
yaw = math.atan2(2*(w*z+x*y), 1-2*(z**2 + y**2))
The yaw (in Gazebo) is -1.56 whereas the yaw output from odom is -2.4960000000000058.

I have changed the tracks_seperation to <tracks_separation>0.50017</tracks_separation> as this was the size of the box and removed the empty space between the base_link and the left and right tracks to ensure this is correct but i'm still getting incorrect odom (Gazebo Yaw -1.66, Odom yaw -1.852000000000027 which if left running will get progressively worse).

Has anyone been able to get an accurate reading from this? Is there a way to get a more accurate reading? I eventually want to get the robots odom but add some noise to make it more real world realistic

[azeey]

cc @peci1

[peci1]

Well, tracked vehicles are "skid-steer". They turn by skidding. And if you're skidding and you don't exactly know the parameters of the skid, your odometry goes... elsewhere :)

On our physical tracked robots (as well as the simulated ones) we only use forward velocity component of the odometry and completely throw away the rotation velocity from odometry. We use gyro instead, which is way more precise.

This (im)precision should normally be visible from the covariance of the odometry, but I fear that Gazebo outputs all zeros in odometry (which, by definition, is unknown covariance).

Anyways, the position component of odometry provided by Gazebo is a super-simple integrator of velocity * time_step, so I wouldn't use it long-term on any kind of robot (not even diff-drive). It just drifts too far too quickly. You need some kind of clever estimator to get better results (EKF, factorgraph, SLAM...). And use only the velocity components of the Gazebo-provided odometry.

It would help if you plotted some trajectory. Gazebo GUI offers a plotting window, so please open it and record the output of odometry. Unless the graph shows something very strange (like a random-looking curve), I would consider this issue closed.

If you need the exact position of the robot in the world, you should rather subscribe to its world pose instead of odometry.

[Rob-Dawson]

Thank you for the clarification.

I attempted to build my own odometry by getting the actual angular and linear speeds of the robot provided by Gazebo and then add some random gaussian noise to the speeds to arrive at a more "real world" realistic value as I don't want it to be exact. I've then fused the IMU data to hopfully provide a reasonable approximation of a real world odom.

Based on what you've said, would you recommend creating the odom by using the track speed and the IMU angular velocity? The reason I wanted the exact linear and angular velocity (with some sensor noise) was to provide feedback (like ordinary encoders) and create a speed controller for the robot ?

[peci1]

Great you managed to cope with the problem. I suggest using tracks vel+IMU angular speed for odometry both in simulation and in real world.

[Rob-Dawson]

Does the tracks vel provide realtime feedback in both the Gazebo Classic and Gazebo Sim versions for me to create a speed controller? In addition, i've noticed that only velocity control is supported and no effort controller is available. Will this be available in a future update? Reason being, if a real robot were to travel up a hill or hit a wall, the motors may slow down due to not having enough torque. Would you again recommend fusing the IMU and encoder to get a better approximation of speed?

[peci1]

The current simulation of the tracks circumvents the physics a bit so it is impossible to measure any forces regarding track movement. The velocity controller is all we have (though I'd like to provide a true torque-based controller, but I still haven't figured the correct approach).

The feedback you get from Gazebo is just the velocity that was set using the last command. So you don't need to implement any velocity controller in Gazebo. To simulate the behavior of the real drivetrain, you could use some hacks, e.g. decreasing the commanded track velocity if pitch is nonzero. But all of that would be just very rough heuristics.