Announcement

Collapse
No announcement yet.

How to get the best results from the Adafruit IMU?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to get the best results from the Adafruit IMU?

    Hello,

    My team purchased the Adafruit IMU (BNO055) and I'm wondering how to get the best results from it.

    I read on a thread here that one team would calibrate it before each match by turning the robot on each side, etc..

    On yet another thread, one team said they enabled the internal compass for absolute headings, rather than relative headings.

    If any teams would care to provide some hints on how to get the best results, that would be much appreciated!

    Thanks,
    - Lead Programmer for team 4634

  • #2
    Some thoughts:
    • Our experience with any form of compass sensor in FTC competition is poor: things will work fine in your team's build space, but then you go to that next competition and the fields are near a large amount of steel in the floor, or power, or ..., and all hell breaks loose. We had a devil of a time with this very issue back in Get Over It, and our team has avoided compasses ever since.
    • Besides, you don't care about absolute orientation; you care about orientation relative to the field. Record a baseline from the gyro as things start, then do some math during the match relative to that.
    • Aside from the compass, the AdaFruit IMU's other sensors are internally self calibrating. The gyro self-calibrates quite quickly so long as it's still for a few seconds. The accelerometer takes longer, and it does need to see some varying geometry to full calibrate, as you mention, but even before it gets fully calibrated, it does a remarkable job. Last year our team never bothered trying to formally calibrate the IMU.
    • The calibration data can be stored and then reloaded. This can improve the amount of time that it takes to achieve full calibration

    Comment


    • #3
      Just wondering, what did you guys use the acelerometer data for specifically?

      Comment


      • #4
        Originally posted by FTC0417 View Post
        Some thoughts:
        • Our experience with any form of compass sensor in FTC competition is poor: things will work fine in your team's build space, but then you go to that next competition and the fields are near a large amount of steel in the floor, or power, or ..., and all hell breaks loose. We had a devil of a time with this very issue back in Get Over It, and our team has avoided compasses ever since.
        • Besides, you don't care about absolute orientation; you care about orientation relative to the field. Record a baseline from the gyro as things start, then do some math during the match relative to that.
        • Aside from the compass, the AdaFruit IMU's other sensors are internally self calibrating. The gyro self-calibrates quite quickly so long as it's still for a few seconds. The accelerometer takes longer, and it does need to see some varying geometry to full calibrate, as you mention, but even before it gets fully calibrated, it does a remarkable job. Last year our team never bothered trying to formally calibrate the IMU.
        • The calibration data can be stored and then reloaded. This can improve the amount of time that it takes to achieve full calibration
        Thanks for the quick reply!

        That was a very vivid description... Guess we won't enable the compas!

        My team actually had a simmilar experience in Cascade Effect. Our dual IR sensors with custom 3D-printed shrouds gave us near 100% accuracy in our space. But then at states, the autonomous literally detonated in our faces. Turns out the scrore projectors were flooding the air with IR

        I thought about that, but I'll wager that kind of math with accumulate errors very fast.

        Hmmmm... So no need to calibrate the accelerometer? Cause I was thinking about using it in the custom PID I'm writing...

        But if what you said about all the steel and such at the real competition is true, I'd never reload data from our testing at the competition...

        Comment


        • #5
          Originally posted by FTC8686 View Post
          Just wondering, what did you guys use the acelerometer data for specifically?
          I'm using it for the custom PID I'm writing, to help determine if the robot hit debris or something like that.

          Comment


          • #6
            Slightly off topic, but does anyone have a 3D model of a case for this thing?

            Comment


            • #7
              http://swerverobotics.org/wp/index.p...table-housing/

              Comment


              • #8
                AWESOME!!! Thanks!

                I hope some other people will give their input on how to get the best results from the IMU though...

                Comment


                • #9
                  Anybody else care to chime in?

                  Comment


                  • #10
                    Originally posted by 4634 Programmer View Post
                    Anybody else care to chime in?
                    I found that sensor fusion is really useful. Gyro is good, but double-integrating acceleration is not. A math-strong team with someone knowing linear algebra may choose to apply Kalman algorithm. I'm actually working on a commercial FTC-compatible navigation sensor that uses optical cues from the floor (similar to an optical mouse) as something that can be fused with the gyro since it is good at precise linear tracking while the gyro tracks angles well.
                    FTC6460 mentor (software+computer vision+electronics), FPGA enthusiast. In favor of allowing custom electronics on FTC bots.
                    Co-founder of ##ftc live chat for FTC programming--currently you may need to join and wait some time for help--volunteer basis only.

                    Comment


                    • #11
                      Question: When I ran the sample code that came with AlanG's driver, the Euler and Quaternion angles were always nearly identical. Is that to be expected?

                      Comment


                      • #12
                        Originally posted by 4634 Programmer View Post
                        Question: When I ran the sample code that came with AlanG's driver, the Euler and Quaternion angles were always nearly identical. Is that to be expected?
                        Quaternions are mainly useful for cases of gimbal lock, where euler angles stop being useful due to sudden jumps and a situation where both roll and yaw contribute to the same actual angular displacement.
                        FTC6460 mentor (software+computer vision+electronics), FPGA enthusiast. In favor of allowing custom electronics on FTC bots.
                        Co-founder of ##ftc live chat for FTC programming--currently you may need to join and wait some time for help--volunteer basis only.

                        Comment


                        • #13
                          Ah.

                          Another question: I saw another thread here where the OP said they had a lot of success putting the IMU into NDOF mode, but they never posted their code. Do you have any experience with it, and/or know how to implement it?

                          Comment


                          • #14
                            My worry is that the magnetic fields from the motors would make for a very bad day.

                            Comment

                            Working...
                            X