IMUs under rocket dynamics

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Altay

Member
Joined
Mar 10, 2020
Messages
20
Reaction score
1
Location
Istanbul, Turkey
Hello everyone, last year we launched a rocket aiming for 1.5km apogee. But while rocket was ascending wrong gyro readings from MPU6050 caused an early ejection and because of that we missed 1.5km apogee and landed with 900m apogee. Our algorithm was triggering ejection if pitch value after launch changes by 70 degrees.

This is the gyro outputs of MPU6050 during the flight:

mpu6050_ejection.png
Red line shows when ejection happened (around T + 8 sec). The reason it didn't trigger ejection right away was because of a safety condition in our algorithm.

As shown in the graph, data we got from MPU6050 gave us very faulty data and we're not really sure why that happened. Our best guess is combination of not using a proper filter and vibrations in the rocket. If you have a idea can you please share with us?

Also we're designing a new flight computer which will also feature an IMU but this time we're not going to try to detect apogee by tilt detection, we will try to measure speed of the rocket and detect the apogee when speed gets close to zero. And we think cheap IMUs like MPU6050 or MPU9250 can't be used in this kind of applications. We're thinking about few options like BNO055 but we're not sure which IMU can handle rocket dynamics. Can you suggest us a IMU or can you share with us what should we watch out while selecting an IMU for our new design?

Thank you for reading.

 
As was pointed out to me just yesterday, the BNO055 is a great sensor but it has 2 limitations to it.

1) It's accelerometer maxes out at 16G and so it would end up maxed out on most launches.
2) Since it has a Cortex M0 processor in it, it can and does, filter/manipulate data. If the processes it used were open and documented, that would be something you might be able to work around or accept.

It has a HUGE benefit for it though. It can output quaternions directly at 100hz

Using it as a secondary sensor would probably be fine but I wouldn't use it as a primary
 
We used this library with Arduino.
Even with the pointer to the library, I have no clue how you used it. You could be using the raw gyro data and processing that in some way you haven't explained. Or you could be using the DMP library which combines the accel and gyro data in mysterious ways that are not suitable for use with rockets.
 
Just out of curiosity, why were you using a gyro to predict apogee for deployments at 1.5 km? Was it a requirement for a university project? At that altitude, barometric altimeters work extremely well, and at only 1.5 km I'm guessing that your rocket's velocity was nowhere near Mach so that's not even an issue.
 
Just out of curiosity, why were you using a gyro to predict apogee for deployments at 1.5 km?
This is one of those Turkish student projects with the weird (would I be being rude to call them nonsensical?) requirements.
 
This is one of those Turkish student projects with the weird (would I be being rude to call them nonsensical?) requirements.
Kinda figured, I've shipped a fair amount of stuff to Turkey. It's a good learning experience for them, though... it shows that sometimes things that seem relatively straightforward in theory don't come out that way in practice. It would be difficult to get anything useful out of all the noise in their gyro data.
 
We had a main flight computer with BMP280 and it worked fine. One of requirements for the contest was having a redundant backup flight computer without using same sensors with main computer. And we used MPU6050 for our backup to detect tilt at apogee.

These are functions from our backup computer code:

C:
void startMPU() // Called in setup to initialize MPU6050
{
    devStatus = mpu.dmpInitialize();

    mpu.setXGyroOffset(220);
    mpu.setYGyroOffset(76);
    mpu.setZGyroOffset(-85);
    mpu.setZAccelOffset(1788); // 1688 factory default for my test chip

    if (devStatus == 0)
    {
        mpu.CalibrateAccel(6);
        mpu.CalibrateGyro(6);
        mpu.PrintActiveOffsets();
        mpu.setDMPEnabled(true);
        attachInterrupt(digitalPinToInterrupt(INTERRUPT_PIN), dmpDataReady, RISING);
        mpuIntStatus = mpu.getIntStatus();
        dmpReady = true;

        packetSize = mpu.dmpGetFIFOPacketSize();
    }

    else
    {
        while(true) // error indication
        {
          digitalWrite(buzzerPin, HIGH);
          delay(750);
          digitalWrite(buzzerPin, LOW);
          delay(25);
        }
    }
}

void mpuCalculate() // Called in loop for getting acceleration and yaw/pitch/roll data
{
  if (!dmpReady) return;

  while (!mpuInterrupt && fifoCount < packetSize)
  {
      if (mpuInterrupt && fifoCount < packetSize)
      {
        fifoCount = mpu.getFIFOCount();
      } 
  }

    mpuInterrupt = false;
    mpuIntStatus = mpu.getIntStatus();

    fifoCount = mpu.getFIFOCount();
  if(fifoCount < packetSize){
          //Lets go back and wait for another interrupt. We shouldn't be here, we got an interrupt from another event
      // This is blocking so don't do it   while (fifoCount < packetSize) fifoCount = mpu.getFIFOCount();
  }
    else if ((mpuIntStatus & _BV(MPU6050_INTERRUPT_FIFO_OFLOW_BIT)) || fifoCount >= 1024)
    {
        // reset so we can continue cleanly
        mpu.resetFIFO();
      //  fifoCount = mpu.getFIFOCount();  // will be zero after reset no need to ask

    } else if (mpuIntStatus & _BV(MPU6050_INTERRUPT_DMP_INT_BIT)) {

  while(fifoCount >= packetSize)
  { // Lets catch up to NOW, someone is using the dreaded delay()!
    mpu.getFIFOBytes(fifoBuffer, packetSize);
    // track FIFO count here in case there is > 1 packet available
    // (this lets us immediately read more without waiting for an interrupt)
    fifoCount -= packetSize;
  }

            // display Euler angles in degrees
            mpu.dmpGetQuaternion(&q, fifoBuffer);
            mpu.dmpGetGravity(&gravity, &q);
            mpu.dmpGetYawPitchRoll(ypr, &q, &gravity);
            yaw = ypr[0] * 180/M_PI;
            pitch = ypr[1] * 180/M_PI;
            roll = ypr[2] * 180/M_PI;

            mpu.dmpGetQuaternion(&q, fifoBuffer);
            mpu.dmpGetAccel(&aa, fifoBuffer);
            mpu.dmpGetGravity(&gravity, &q);
            mpu.dmpGetLinearAccel(&aaReal, &aa, &gravity);
            mpu.dmpGetLinearAccelInWorld(&aaWorld, &aaReal, &q);
            AccX = aaWorld.x / 16384.0;
            AccY = aaWorld.y / 16384.0;
            AccZ = aaWorld.z / 16384.0;
    }
}
 
You are using the DMP library which is a mistake since you have no idea what it is doing to the data. Is your sensor really in the default orientation expected by the DMP library?

The DMP library tries to fuse the accel and gyro data (gyro zero offset drifts a lot on time scales greater than a few minutes) and in order to do that it makes assumptions about vehicle dynamics. Assumptions that work pretty well for things like RC aircraft or quadcopters but are completely wrong for a rocket. Resulting in garbage data out. Rocket flights (suborbital amateur rockets like ours anyway) are short enough so that gyro drift simply isn't a problem.

It is just barely possible that you can get the DMP library to do what you want but it will require a deep dive into the documentation to find out. The raw gyro readings on the other hand can do the job but will also require effort on your part to process them into vehicle attitude.

Either way you have some work to do.
 
If you get the DMP into DMP_FEATURE_LP_QUAT mode that should get it to run just on the gyro and ignore the accelerometers except for ground calibration; but the documentation for the DMP is pretty poor so I'm not certain this will do what you need; my flight experience with this approach is limited.
 
Thank you all for your answers, it means a lot to us.

What I understood is using DMP library for rocket applictions is wrong. And probably that's the reason for our failure. And we learned that we need to check libraries we're using more carefully. But I have few more questions:
  • Can we use BNO055, MPU9255 or just an accelerometer like ADXL150 to detect apogee? If yes is it possible with Atmega MCUs? If atmega isn't possible we're planning on using STM32 MCUs.
  • Can we rely on use BMP280 or any other barometric altimeter above 1 mach?
 
yes accel based apogee can be done on atmega. It's just addition .

With baro the readings as you pass through mach are unreliable. So you will need to ignore them. There are many ways to do this. Brainstorm with your team on how to do this. It's how to learn.
 
Back
Top