View Single Post
  #10   Spotlight this post!  
Unread 13-04-2016, 17:37
Richard100 Richard100 is offline
Registered User
FRC #0836 (RoboBees)
Team Role: Mentor
 
Join Date: Nov 2009
Rookie Year: 2008
Location: Southern Maryland
Posts: 79
Richard100 is a splendid one to beholdRichard100 is a splendid one to beholdRichard100 is a splendid one to beholdRichard100 is a splendid one to beholdRichard100 is a splendid one to beholdRichard100 is a splendid one to behold
Re: Got Sensor Fusion?

Quote:
Originally Posted by sraque View Post
I'm looking for any reports of how this device has worked in competition. Does it work as expected? Is it reliable? Any problems?

Steve -

The RoboBees (FRC 836) used the BNO055 during both our Chesapeake District events and the DChamps. We used the 'IMU' mode rather than one of the 'NDOF' modes, which removes the Magnetometer. Although tests indicated the fusion algo compensated well for magnetic anomalies, there’s still an issue where it still takes a moment to decide where North is, so the zero position of Yaw will get updated early in the match (moves from relative to absolute). I wanted to avoid that issue so just went with the IMU mode as risk reduction.

The IMU was used to control our autonomous routine, and the IMU data was quite uniform. Basically we run a pattern to cross any of the non-manipulated defenses and line up on the tower goal … vision tracking takes us on final approach. The IMU Yaw data controlled our turns, and Pitch was used to know when we completed the defense crossing, and when to fire the Boulder while climbing the Batter. Our defense crossing detector would sporadically fail, but that was due to the detector logic, not the IMU performance.

One issue seemed to be the roboRIO’s USB port, which doesn’t seem to be up to the punishing field conditions in this year’s game. There were times when the IMU would not successfully go through calibration at startup, which appeared to be because the cal file wasn’t found on the Flash Drive (loosened on previous match). Once we relocated the cal file to the roboRIO the issue went away. Automatically falling back to analog gyros (Yaw and Pitch) was a useful redundancy, and saved our auto several times while we gathered necessary experience with the device.

We did have several times where the IMU would drop out during the match, but we think root cause here was loose wiring. We’re planning on running a redundant IMU, monitoring the device status and automatically switching over when SGAM all report 0. This is mostly an exercise for educating students on the value of redundancy in critical systems, but it might prove useful for us in St. Louis.

In post #6 I mention that there is an issue where Roll exceeding ~45 degrees causes an orientation error, speculating a possible BNO055 firmware issue. This appears to be confirmed by other users outside of FIRST (AdaFruit forums), see this, “Why doesn’t Euler output seem to match Quaternion output?”. Bosch essentially admits to the problem in their code. Appears this can be overcome by reading Quaternion orientations instead and converting them to Euler angles, which I’ll likely add to our LabVIEW drivers on a future release.

Finally, I continue to recommend using the MXP I2C port, and not the On-Board port to connect the BNO055 IMU. Using the On-Board I2C port causes Lo-byte / Hi-byte pairing failures – which will translate into IMU measurement glitches. For some reason the same code runs differently on the two different I2C busses.
Reply With Quote