No announcement yet.

IMU Initialization time

  • Filter
  • Time
  • Show
Clear All
new posts

  • IMU Initialization time

    My team is pushing for 95 point autonomous. Every fraction of a second counts as they work on that.

    Last night they found that they are losing about 1 second due to IMU initialization at the beginning of autonomous. Probably 2 seasons back they moved the IMU initialization to after hitting Start due to IMU drift when sitting on the playing field for minutes between hitting "Init" and Start. By doing the imu.initialize() call it would zero the angles and things worked better. Until now when they really want that 1 second of time.

    Below is the pretty stock code they use. It is called right after hitting start.

    Any suggestions for how to initialize the IMU earlier but zero it out when Start is hit?
    We didn't see any methods that seemed like they would do that.


    public void IMUinit () {
    // Set up the parameters with which we will use our IMU. Note that integration
    // algorithm here just reports accelerations to the logcat log; it doesn't actually
    // provide positional information.
    BNO055IMU.Parameters parameters = new BNO055IMU.Parameters();
    parameters.angleUnit = BNO055IMU.AngleUnit.DEGREES;
    parameters.accelUnit = BNO055IMU.AccelUnit.METERS_PERSEC_PERSEC;
    parameters.calibrationDataFile = "BNO055IMUCalibration.json"; // see the calibration sample opMode
    parameters.loggingEnabled = true;
    parameters.loggingTag = "IMU";
    parameters.accelerationIntegrationAlgorithm = new JustLoggingAccelerationIntegrator();
    // Retrieve and initialize the IMU. We expect the IMU to be attached to an I2C port
    // on a Core Device Interface Module, configured to be a sensor of type "AdaFruit IMU",
    // and named "imu".
    imu = hwMap.get(BNO055IMU.class, "imu");
    Log.d("catbot", String.format("IMU initialized - starting init"));
    //the initialize method is taking a whole second
    Log.d("catbot", String.format("IMU initialized - finishing init starting integration"));
    imu.startAccelerationIntegration(new Position(), new Velocity(), 250);
    Log.d("catbot", String.format("IMU initialized - finished integration"));

  • #2
    We've successfully used the concept of a "logical" encoder count on our motors for dealing with a similar issue. It should be possible to have a logical IMU reading that is "zeroed" by hitting start. The object-oriented way would be to wrap the IMU with an interface that looks the same, but that for every reading returns a delta between what the current real reading is and a reading taken at the "zeroed" time. Depending on how long you need to read values from the IMU you may have to account for wrap?

    - Mark


    • #3
      The BNO055 really doesn't drift at all when sittting still. Perhaps you were using the MR gyro before? (The drift on the MR gyro when sitting still is just stupid, and it drifts faster the longer its powered on). At any rate, I think you'll be just fine intializinng before start. At least that has worked fine for us. We initialize the gyro against the wall prior to hanging the robot on the lander.


      • #4
        I bet it was the MR gyro before. And when switched to the BNO055 in the Rev module we didn't think to retest if it drifted. Will have to do that.
        Do you know if the BNO055 needs to be stationary when initializing? i.e. how much wiggling will throw it off.


        • #5
          Originally posted by DanOelkeFTA View Post
          I bet it was the MR gyro before. And when switched to the BNO055 in the Rev module we didn't think to retest if it drifted. Will have to do that.
          Do you know if the BNO055 needs to be stationary when initializing? i.e. how much wiggling will throw it off.
          You absolutely need to have it stationary when calibrating/initializing it. If it is not stationary, the best case would be that it would drift like crazy. The worst case would be that it would fail the calibration entirely.


          • #6
            An interesting characteristic of the BNO055 Gyro is that it automatically calibrates when it thinks that it is stationary.

            The UP side of this is that you accidentally init when the robot is moving, as long as it remains stationary for several seconds prior to actually starting the match, it will have re-calibrated automatically.

            The DOWN side of this is that if for some reasons the robot has a period when it is turning really slowly (less than some threshold) the gyro will recalibrate to this slow rotation and when the robot actually stops, they gyro will think it's running backwards...

            Weird, I know, but I discovered this once when testing the robot's auto heading code on a lazy susan, using the REV Hub's internal IMU.

            What we do is init the IMU when we init the opmode., and then when the driver hits start, we read the gyro, and just subtract that value from all subsequent readings.


            • #7
              Phil, while working on improving the accuracy of turns using our drive chassis from last year, I noticed that our rev imu now does not produce reproducible heading info, either using the sample opmodes. The json file has been deleted and a several second long init should give the IMU plenty of time at rest to calibrate. (gyro calibration is always g3, but system is always s0. the accelerometer is always a0 if the rev hub is at rest.)

              I am at a loss for getting accurate turns to a heading when turning through large angles. I can get the mechanical chassis to turn accurately to a heading provided by the imu but I don't believe the imu is behaving correctly. For instance, if I initialize the imu and then manually turn the robot 180 degrees and then return it to the original orientation based on some external reference ( a line or straight edge for instance that is easy to see) the imu gives a heading that is off by several degrees. It is easy to see a heading error that big.

              This issue is hard to distinguish from mechanical turning inaccuracies that you might solve with tuned proportional control algorithms. If the IMU is off by several degrees the robot orientation will be unpredictably off in its turns even if the control is correct.

              I think I did see this inaccuracy of turning during auto last year, but I attributed it to mechanics and our turning code. Now in checking I find the IMU reading is not reproducible. Have you seen this? I thought maybe it was a IMU calibration issue, but for IMU mode this shouldn't matter.

              FTC 9808