Announcement

Collapse
No announcement yet.

Adafruit IMU consistently off by 15 degrees

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

  • Adafruit IMU consistently off by 15 degrees

    So we got our robot stripped down to only the frame, and I've been playing with the Adafuit BNO055 IMU.

    I made a very simple program that drives forward for 2 seconds, then stops for one second, and then turns 90 degrees to the left.

    However, when running the program, the robot turns about 105 degrees, even though the telemetry from the IMU indicates that it's within +-0.5 degrees of 90. The same thing happens if I tell it to turn to the right 90 degrees.

    If I tell the robot to turn 75 degrees, then it turns almost a perfect 90.

    What the heck?

    I'm using SDK 1.77, with AlanG's driver. The IMU is centered on the robot.

  • #2
    Originally posted by 4634 Programmer View Post
    So we got our robot stripped down to only the frame, and I've been playing with the Adafuit BNO055 IMU.

    I made a very simple program that drives forward for 2 seconds, then stops for one second, and then turns 90 degrees to the left.

    However, when running the program, the robot turns about 105 degrees, even though the telemetry from the IMU indicates that it's within +-0.5 degrees of 90. The same thing happens if I tell it to turn to the right 90 degrees.

    If I tell the robot to turn 75 degrees, then it turns almost a perfect 90.

    What the heck?

    I'm using SDK 1.77, with AlanG's driver. The IMU is centered on the robot.
    What is the measured angle before any travel moves are made?
    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


    • #3
      Originally posted by hexafraction View Post
      What is the measured angle before any travel moves are made?
      0 degrees exactly.

      Comment


      • #4
        Originally posted by 4634 Programmer View Post
        So we got our robot stripped down to only the frame, and I've been playing with the Adafuit BNO055 IMU.

        I'm using SDK 1.77, with AlanG's driver. The IMU is centered on the robot.
        Several thoughts come to mind.

        1) Have you tried verifying the gyro operation without running the motors? eg: Start at zero, rotate the robot 90 manually (by hand... a lazy susan helps here) and then watch the heading.
        Does it stay stable at 0 until you turn? Does it stay stable after the turn? Is it correct angle? If the gyro is not flat, it may not be measuring the turn correctly.

        2) Have you tried the turn without driving first? Possibly motor vibration or robot wobble is the cause.

        3) Have you tried turning slowly? It's possible you are exceeding the ability of the gyro, or code to measure and integrate the rate of turn.

        4) Are you resetting the gyro before the turn? I would not do this. I would keep the original zero heading throughout. (If the robot had jerked at the end of it's travel you may be starting at 10-15 off course).

        5) Have you allowed the gyro to fully calibrate before moving? Perhaps it's still calibrating as you start moving.

        6) Do you keep displaying the heading after the end of the turn (until user stop)? Is the heading stable (if it's drifting, this would indicate a bad calibration)

        Note: I had a simmilar problem with the NavX gyro last year, and it was not integrating for a short period after being reset.
        It was a driver bug, so that's why detailed testing can help identify/solve these problems.
        If it's really not working, the key is to determine if there is a specific cause.

        Comment


        • #5
          Thanks for the reply. I did manage to get it working. I'll update this thread later today or tomorrow.

          Comment


          • #6
            Originally posted by 4634 Programmer View Post
            Thanks for the reply. I did manage to get it working. I'll update this thread later today or tomorrow.
            Could you please update? We are having the same issue after testing for the first time, and we even have a P controller for the turn. How did you fix it?
            Programmer for Team 4997 Masquerade -- 2012 World Champions, 2014 - 2016 Division Finalists
            Founding Member of Team 6433 Neutrinos -- 2015 World Champions

            Check out my intro video to the new tech platform
            Check out my team's Robot Reveal for Res-Q

            Comment


            • #7
              Originally posted by Varun Singh View Post
              Could you please update? We are having the same issue after testing for the first time, and we even have a P controller for the turn. How did you fix it?
              Sorry, I forgot. I've been very busy lately.

              The TL;DR version is that it seems there is a bug in AlanG's driver. I spent a ton of time trying to get it to work, and as a last resort, I updated to SDK2.2, which has an "official" driver for it from FIRST. Using the official driver on 2.2, (even without formal calibration), it seems to work very well.

              A word of caution: The data stream coming from the gyro using the above configuration seemed a bit laggy, like it wasn't reading at the full 100Hz or whatever. As a result, my turns always overshot by a huge margin (like 20 degrees), but the gyro KNEW that it had overshot. (As opposed to thinking it hadn't before). Of course, that is always fixable with PID.

              Comment


              • #8
                Originally posted by 4634 Programmer View Post
                Sorry, I forgot. I've been very busy lately.

                The TL;DR version is that it seems there is a bug in AlanG's driver. I spent a ton of time trying to get it to work, and as a last resort, I updated to SDK2.2, which has an "official" driver for it from FIRST. Using the official driver on 2.2, (even without formal calibration), it seems to work very well.

                A word of caution: The data stream coming from the gyro using the above configuration seemed a bit laggy, like it wasn't reading at the full 100Hz or whatever. As a result, my turns always overshot by a huge margin (like 20 degrees), but the gyro KNEW that it had overshot. (As opposed to thinking it hadn't before). Of course, that is always fixable with PID.
                We were using the SDK driver, not Alan G's. We noticed the huge overshoot, but the gyro read it as well. I am wondering why a simple P controller didn't work for controlling the speed.

                For anyone reading this, if you have a way to make the SDK version less laggy, or have made a new driver based on the new architecture, then please let me know! I tried creating one, but it didn't work, so I resorted to the default. Thanks!
                Programmer for Team 4997 Masquerade -- 2012 World Champions, 2014 - 2016 Division Finalists
                Founding Member of Team 6433 Neutrinos -- 2015 World Champions

                Check out my intro video to the new tech platform
                Check out my team's Robot Reveal for Res-Q

                Comment


                • #9
                  Originally posted by 4634 Programmer View Post
                  A word of caution: The data stream coming from the gyro using the above configuration seemed a bit laggy, like it wasn't reading at the full 100Hz or whatever. As a result, my turns always overshot by a huge margin (like 20 degrees), but the gyro KNEW that it had overshot. (As opposed to thinking it hadn't before). Of course, that is always fixable with PID.
                  Can you say more about in what way you perceived the gyro as being 'laggy'?

                  Also: are you only reading getAngularOrientation(), or that and possibly other data? Absent reading anything else (that might necessitate shifting of the read window), the orientation should be being read on every I2cDevice cycle (approx every 17ms if I recall).

                  Comment


                  • #10
                    Originally posted by FTC0417 View Post
                    Can you say more about in what way you perceived the gyro as being 'laggy'?

                    Also: are you only reading getAngularOrientation(), or that and possibly other data? Absent reading anything else (that might necessitate shifting of the read window), the orientation should be being read on every I2cDevice cycle (approx every 17ms if I recall).
                    The heading from the gyro was quite a bit behind. It would take like .25 seconds to catch up.

                    Comment


                    • #11
                      Originally posted by Varun Singh View Post
                      We were using the SDK driver, not Alan G's. We noticed the huge overshoot, but the gyro read it as well. I am wondering why a simple P controller didn't work for controlling the speed.

                      For anyone reading this, if you have a way to make the SDK version less laggy, or have made a new driver based on the new architecture, then please let me know! I tried creating one, but it didn't work, so I resorted to the default. Thanks!
                      I will be sure to try some more things at our next meeting.

                      Good luck creating your own. That's not for the faint of heart

                      Comment


                      • #12
                        Originally posted by 4634 Programmer View Post
                        The heading from the gyro was quite a bit behind. It would take like .25 seconds to catch up.
                        Is that as reported on the driver station using telemetry, or by some other means? There's a (default) 250ms throttle on DS telemetry transmission...just wondering...

                        Comment


                        • #13
                          Originally posted by FTC0417 View Post
                          Is that as reported on the driver station using telemetry, or by some other means? There's a (default) 250ms throttle on DS telemetry transmission...just wondering...
                          Well yes that was with the telemetry... but since Varun Singh is having the same issue, I doubt that's the cause.

                          Though I should note, this thread was originally started because our IMU wasn't accurate with the angles it was reporting. But now it has morphed into the gyro being very laggy to return headings.

                          Comment


                          • #14
                            I am using quaternion data instead of getAngularOrientation(). The telemetry might be the only thing lagging, but I have a P controller on the speed of the turn to slow down, so the robot should have stopped at 90 degrees. And even if I didn't have a P controller, the robot shouldn't be continuing to rotate for an extra 15 to 20 degrees after being told to stop. It seems like the robot stops moving the motors way past the 90 degree mark, which doesn't make any sense; it should stop right at the 90 degree mark.
                            Programmer for Team 4997 Masquerade -- 2012 World Champions, 2014 - 2016 Division Finalists
                            Founding Member of Team 6433 Neutrinos -- 2015 World Champions

                            Check out my intro video to the new tech platform
                            Check out my team's Robot Reveal for Res-Q

                            Comment


                            • #15
                              Was there an issue with this in SDK version 2.1? because I had tested the two IMU drivers against each other previously in that SDK version, and noticed very little heading difference, if any. The readings seemed fairly accurate as well.

                              Comment

                              Working...
                              X