[Bug] Gryro Drift Issue During Longer Runs - How To Debug

[DrTom]

This is from this years WRO competition. One of the teams is experiencing quite severe gyro drift. This is an advanced team with their own gyro drive function base on reading imu.heading() and feeding the deviation with a simpleproportional controller into drivebase.drive(). This is used throughout the run for all straight movements.

The main run is composed of 4 sections, where in between those sections realignment against the boarder is performed and imu.reset_heading(angle) as well as drivebase.reset() is called.

This works very well for the first 3 sections or when each of the 4 sections is performed in isolation. However, if all sections are run in sequence imu.heading() drifts off significantly towards the very end of the run. We have observed deviations of more than 15 degrees. The deviation is so large that this seems not to be a simple accumulation as well as running isolated sections is inconspicuous. The deviation is always towards the same direction.

So we would like to debug this (unless there is a immediate solution).

For one thing we would suggest to investigate the current state of internal drift compensation and see how it changes under certain circumstances and influences. Is there a way to read the values (and output them to the console)? Is there a way to force the hub explicitly to recalibrate during a run? How long would we have to pause the robot so that auto recalibration occurs?

Do you have any other ideas of what we can look at?

I can rebuild the firmware and perform some simple changes like changing constants if that helps.

[laurensvalk]

Thanks for your detailed feedback.

This works very well for the first 3 sections or when each of the 4 sections is performed in isolation. However, if all sections are run in sequence imu.heading() drifts off significantly towards the very end of the run. We have observed deviations of more than 15 degrees.

• Is the robot flat during its 4th run, or perhaps driving over objects or driving on ramps?
• Does it also happen if you do the first 3 sections, twice?

Is there a way to read the values (and output them to the console)?

You can use the print command for this. You can print multiple columns:

For example you could do this in a loop, or as part of the rest of your code.

print(timer.time(), hub.imu.heading(), hub.imu.angular_velocity(Axis.Z), sep=",")

Then copy the output to Excel to easily make a graph.

I would be especially curious if that 15 degrees builds over time, or whether there is a discontinuous jump.

This is used throughout the run for all straight movements.

Do you run straight with respect to the start of that maneuver each time, or do you try to maintain an overal compass-like angle?

The main run is composed of 4 sections, where in between those sections realignment against the boarder is performed and imu.reset_heading(angle) as well as drivebase.reset() is called.

It's worth trying drivebase.stop(), as well. This will also reset any "holding mode", in case you were using it.

[DrTom]

Some preliminary observations:

• We can reproduce the drift by only running the first 3 sections (in a loop), too. But it takes quite a bit longer to manifest: about 5 to 6 minutes.

• The fourth section shows the problem in much shorter time. There is more stopping, starting, forth and back, and also turning in the fourth section.

• We suspect there is a particular operation in the fourth section which makes this worse. But we are still trying to isolate that.

Apart from that we found an external factor: ambient temperature. In hindsight the worst runs seem to have happen either when the ambient temperature was relatively high or wenn there were a lot of runs in a short time (we suspect some heat accumulated inside the hub) or both together. After heating up the entire robot to 45 degrees Celsius (above freezing point) the problem manifested rather quickly and much more severely.

Does the IMU have temperature compensation? It seems to be an LsM6DS3(TR-C). I did not find anything hinting to this. However https://community.st.com/t5/mems-sensors/lsm6ds3-temperature-compensation/td-p/294475 seems to confirm the problem.

[laurensvalk]

we suspect some heat accumulated inside the hub

Good point!

Does the IMU have temperature compensation?

It can measure temperature, but does not automatically account for it. Potentially, we could do that in our own driver.

I've attached the datasheet below in case anyone is looking for some light reading over the holidays :sun_with_face:

lsm6ds3tr-c.pdf

These are the nominal sensitivities to temperature, for both the rate magnitude and the drift (the "zero rate"). Both will affect the result of a turn.

[laurensvalk]

On a slightly unrelated note, I think we can also improve the usual calibration on boot a bit. Right now, we wait for stationarity but assume 0 until then. We could potentially save the offset values just like we will be saving a few other IMU calibration settings. Then it will drift a bit less until the first calibration has occured.