Announcement

Collapse
No announcement yet.

IMU Initialization time

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

  • DanOelkeFTA
    started a topic IMU Initialization time

    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.

    Thanks

    Code:
     
    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
    imu.initialize(parameters);
    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"));
    }

  • 4634 Programmer
    replied
    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.

    Leave a comment:


  • DanOelkeFTA
    replied
    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.

    Leave a comment:


  • 4634 Programmer
    replied
    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.

    Leave a comment:


  • markdmatthews
    replied
    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

    Leave a comment:

Working...
X