-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
Thanks for your detailed feedback.
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.
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?
It's worth trying |
Some preliminary observations:
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. |
Good point!
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 🌞 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. |
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. |
@DrTom 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. |
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 intodrivebase.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 asdrivebase.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.
The text was updated successfully, but these errors were encountered: