Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
DrTom opened this issue Jun 24, 2024 · 6 comments
Open

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

DrTom opened this issue Jun 24, 2024 · 6 comments
Labels
software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime) topic: imu Issues related to IMU/gyro/accelerometer

Comments

@DrTom
Copy link

DrTom commented Jun 24, 2024

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.

@DrTom DrTom added the triage Issues that have not been triaged yet label Jun 24, 2024
@laurensvalk laurensvalk added software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime) topic: imu Issues related to IMU/gyro/accelerometer and removed triage Issues that have not been triaged yet labels Jun 24, 2024
@laurensvalk
Copy link
Member

laurensvalk commented Jun 24, 2024

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
Copy link
Author

DrTom commented Jun 28, 2024

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
Copy link
Member

laurensvalk commented Jun 28, 2024

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 🌞

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.

image

@laurensvalk
Copy link
Member

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.

image

@afarago
Copy link

afarago commented Jul 21, 2024

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.

@DrTom Would you be willing to show the phenomena on a video here or even in pm?
During FLL, WRO I have not seen this with pybricks and would be keen to lean and debug.

@DrTom
Copy link
Author

DrTom commented Jul 24, 2024

@afarago

Would you be willing to show the phenomena on a video here or even in pm?

Yes we can do either. However, it will have to wait until we are back from vacations in about 3 weeks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime) topic: imu Issues related to IMU/gyro/accelerometer
Projects
None yet
Development

No branches or pull requests

3 participants