You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 6, 2024. It is now read-only.
Sometimes an opmode that uses the BNO055 gyro sensor will always return readings of zero when it is running. Restarting the opmode will sometimes fix it and sometimes not. The failure rate can be fairly high at times (around 80% of the time with one opmode and robot that this issue was observed on).
I experimented with putting sleep calls (actually calls to the delayLore function) at various places in the initialize method of the AdaFruiteBNO055IMU class and think I found the location in the code that may be causing this.
If an additional call to delayLore is made right after these two lines of code in that function it appears to fix the problem.
I added the following call right after those two lines which appears to fix it:
delayLore(40);
I experimented with different delay values and 40 ms appears to fix it for the one robot and program I tested that was having about an 80% failure rate. 30 ms still had about a 10% failure rate (but much less than without the delay). Perhaps a value of 50 or 60 ms would actually be better than 40 to allow for some variation and robustness.
The text was updated successfully, but these errors were encountered:
Thank you. We’ve seen this intermittently, but nowhere near as high a failure rate that you’re describing. As such, we’ve had a devil of a time tracking it down.
Sometimes an opmode that uses the BNO055 gyro sensor will always return readings of zero when it is running. Restarting the opmode will sometimes fix it and sometimes not. The failure rate can be fairly high at times (around 80% of the time with one opmode and robot that this issue was observed on).
I experimented with putting sleep calls (actually calls to the delayLore function) at various places in the initialize method of the AdaFruiteBNO055IMU class and think I found the location in the code that may be causing this.
If an additional call to delayLore is made right after these two lines of code in that function it appears to fix the problem.
I added the following call right after those two lines which appears to fix it:
delayLore(40);
I experimented with different delay values and 40 ms appears to fix it for the one robot and program I tested that was having about an 80% failure rate. 30 ms still had about a 10% failure rate (but much less than without the delay). Perhaps a value of 50 or 60 ms would actually be better than 40 to allow for some variation and robustness.
The text was updated successfully, but these errors were encountered: