Most Accurate Way to Measure Velocity: Accelerometer vs Barometer vs ?

[Charles_McG]

I have worried the same thing about the PID.

That is a really interesting alternative, not sure how I would sim the brakes though. Also I wonder if the sim could produce realistic enough results to be accurate? An advantage of the PID is it is based completely off of real time variables, and the quadratic drag equation (where drag is actually measured empirically in real-time).

Fly more than once, activating different drag amounts. Build a model. Do it empirically, but not real time. Dig into openrocket add-ins and build one to do a variable drag profile, a bit like the way someone built an add-in to do winds by altitude.

And before someone notices and asks, the V discontinuity at ~1sec is a booster seperation event. The sustainer didn't light (open circuit at timer - I need to look for that loose wire). I have no idea what the burp near 2 seconds is.

 

[mikec]

Another thought: it seems the error in the vertical velocity calculation will sum over time, how significant should I expect this to be?

Would using a pitot tube on the nose be simpler/more accurate?

To do the full 3D thing, you have to integrate the gyro rates, form a rotation matrix or quaternion, etc. Doable but complicated.

Do some simulations and see how the errors in accel sensing, off-angle flight, etc, combine. You have to assume that the accel values are accurate and linear, unless the datasheet gives you some guidance here.

I know nothing about pitot tubes. That probably works for low speeds, I expect it's complicated if you're close to transonic or supersonic.

 

[jderimig]

The implementation I wrote relies on the gyro to sense orientation and one-axis of the accelerometer, using basic trig to get the actual vertical acceleration. It sounds like this thinking is flawed, due to inability to trust orientation measurments from gyro? I would appreciate being corrected.

Your thinking is NOT flawed but your 'mission' may not require that much complexity. As MikeC posted, the cos(theta) error in accelerometer integration is likely to be small for modest deviation from verticality. Any gyro error will most likely be a larger contributor to altitude error than the off-vertical assumption error. If you are way off axis then your flight has other problems and your mission success become further unlikely anyways.

Also another trick you can do if you are rolling your own processing (which sounds like you are) is you don't have to assume a -1g correction to your acceleration. That -1g correction is only correct for a purely vertical flight. Guess what, that is probably the lowest probability scenario. If you assume a 5 degree off vertical flight, then your acceleration integration has a 10 degree window for the same error budget as a 5 degree window for asssuming straight up. Start with the simplest solution first.

 

[Joshua Koehler]

Fly more than once, activating different drag amounts. Build a model. Do it empirically, but not real time. Dig into openrocket add-ins and build one to do a variable drag profile, a bit like the way someone built an add-in to do winds by altitude.

And before someone notices and asks, the V discontinuity at ~1sec is a booster seperation event. The sustainer didn't light (open circuit at timer - I need to look for that loose wire). I have no idea what the burp near 2 seconds is.

Thanks for the direction. One limitation, only one full-scale test launch will be possible. As such, testing will be done on a third-scale model, which should be close enough to be trustworthy.
I have never used open rocket, but will dig into it this week.

A question about measuring boost: were you suggesting that I sum the total boost, and only start deploying brakes after burn-out? Or were you suggesting some other method? A possible concern could be if the motor burns slower or faster than normal.

 

[Joshua Koehler]

To do the full 3D thing, you have to integrate the gyro rates, form a rotation matrix or quaternion, etc. Doable but complicated.

Do some simulations and see how the errors in accel sensing, off-angle flight, etc, combine. You have to assume that the accel values are accurate and linear, unless the datasheet gives you some guidance here.

I know nothing about pitot tubes. That probably works for low speeds, I expect it's complicated if you're close to transonic or supersonic.

Gotcha, sounds like a bit more than I was predicting. And to confirm, pitot tubes have very low errors sub AND supersonic, but have trouble in the transonic region.

 

[mikec]

One limitation, only one full-scale test launch will be possible.

Oh geez!

Make sure you start by building a good test framework for your software that can feed it sensor inputs derived from simulation, and then test the cr*p out of it. Monte Carlo all of the error sources. Without that you don't stand a chance. And then fly as many subscale tests as possible, you will almost certainly learn a lot.

Unfortunately I don't think OR allows variable drag conveniently, maybe this can be done as a plugin or by hacking up the source.

 

[Joshua Koehler]

Your thinking is NOT flawed but your 'mission' may not require that much complexity. As MikeC posted, the cos(theta) error in accelerometer integration is likely to be small for modest deviation from verticality. Any gyro error will most likely be a larger contributor to altitude error than the off-vertical assumption error. If you are way off axis then your flight has other problems and your mission success become further unlikely anyways.

Also another trick you can do if you are rolling your own processing (which sounds like you are) is you don't have to assume a -1g correction to your acceleration. That -1g correction is only correct for a purely vertical flight. Guess what, that is probably the lowest probability scenario. If you assume a 5 degree off vertical flight, then your acceleration integration has a 10 degree window for the same error budget as a 5 degree window for asssuming straight up. Start with the simplest solution first.

Thanks for the clarification and suggestion, that sounds like a good idea.

 

[Joshua Koehler]

Oh geez!

Make sure you start by building a good test framework for your software that can feed it sensor inputs derived from simulation, and then test the cr*p out of it. Monte Carlo all of the error sources. Without that you don't stand a chance. And then fly as many subscale tests as possible, you will almost certainly learn a lot.

Unfortunately I don't think OR allows variable drag conveniently, maybe this can be done as a plugin or by hacking up the source.

Yep, sounds like my test framework and methods will have the biggest impact on success here.

Looks like the source code is written in Java. Software is actually my background, so this should be a really fun project.

 

[mikec]

In my efforts I've made good use of David Schultz's launch detect algorithm. Unfortunately it's not all online any more, but the core is at https://web.archive.org/web/2016062....net/~david.schultz/rnd/launch_detect/ld.html

FWIW, here's my code. I've flown it about 10 times and it's always seemed to perform well.

float filtered_accel[3];

/* DON'T SET THIS FOR FLIGHT!! */
int testmode = 0;

enum { INIT = 0, PRELAUNCH, ASCENT, DESCENT } state = INIT;

void filter(float accel);
float velocity = 0, biased_velocity = 0, acceleration, altitude = 0;

void alt_init(float accel) {
  /* Initialize the offset filter. */
   filtered_accel[0] = accel;
   filtered_accel[1] = 0;
   filtered_accel[2] = 0;
  /* Initialize velocity */
  biased_velocity = velocity = 0;
}

#define G 9.81f
#define RATE 50 // in Hz
#define ABIAS G*0.1f
#define FAC 0.125f
#define ORATE 5
#define VTHRESH 10 // 10 for flight, 1 for test (meters/sec)

void xoutput(float, float, float);

int do_velocity(float accel)
{
    float dt = 1.0f/RATE;
    static int count = 0;

#ifdef UNIT
    accel *= 256.0;
#endif
    accel = accel/256.0*G;
    filter(accel);

    /* remove the 1G offset. If the filtered value isn't available
       yet, skip all the rest.
    */
    if(filtered_accel[2] != 0) {
    acceleration = accel - filtered_accel[2];
    biased_velocity += (acceleration-ABIAS)*dt;
    velocity += acceleration*dt;

    /*
      The biased_velocity has its acceleration biased by ABIAS
      during pre-launch.
    */
    switch(state) {
        case INIT:
        if(filtered_accel[2] > G*0.9 && filtered_accel[2] < G*1.1) {
            state = PRELAUNCH;
        }
                if(testmode) state = PRELAUNCH;
        biased_velocity = 0;
        velocity = 0;
        break;
        case PRELAUNCH:
        if(!testmode && filtered_accel[2] < G*0.8) {
            state = INIT;
        }
        if(biased_velocity < 0) {
            biased_velocity = 0;     /* floor the integrals */
            velocity = 0;
        }
        if(velocity > VTHRESH) {
            state = ASCENT;
            altitude = 0;
        }
        break;
        case ASCENT:
        if(velocity < 0) state = DESCENT;
        altitude += velocity*dt;
        if(count == RATE/ORATE-1) {
            xoutput(acceleration, velocity, altitude);
            count = 0;
        }
        else {
            count += 1;
        }
        break;
        case DESCENT:
        break;
    }
#ifdef UNIT
    printf("%d %f %f %f\n", state, acceleration, velocity, altitude);
#endif
    //Serial.println(acceleration);
    }
    //return state == ASCENT;
    return state == INIT || state == ASCENT;
}

/*
  Run the acceleration data through a simple digital filter.

  Every two seconds the current value is copied and double
  buffered. This prevents the early part of the motor thrust
  from corrupting the value.
*/
int count = 0;

void filter(float accel)
{
  filtered_accel[0] += FAC*(accel-filtered_accel[0]);

  /* Every two seconds copy the current value.
     Once launch is detected, this stops to lock
     in the offset.

   */
  if(++count == 2*RATE && state <= PRELAUNCH)
    {
      count = 0;

      filtered_accel[2] = filtered_accel[1];
      filtered_accel[1] = filtered_accel[0];
    }
}

 

[Adrian A]

So barometric altimeters work well for measuring one data point, which is one very useful data point, the apogee altitude. They also work well for parachute deployment, for while the accuracy decreases as the velocity is higher both before and after apogee, the accuracy is still good enough for parachute deployment.

To make barometric altimeters even more accurate, you launch weather balloons prior to launch, and using the data from the weather balloons you correct the barometric altimeter data. Very few rocketeers do this. Barometric altimeters provide good accuracy for apogee altitude without adding weather balloon data. It's obviously a lot of effort to launch weather balloons with the atmospheric sensors required to get the balloon data.

Many of the RASAero altitude comparisons with flight data on the RASAero web site ( www.rasaero.com ) are based on barometric altitude flight data, again using just the apogee altitude from the barometric altimeter.

Charles E. (Chuck) Rogers

Weather balloon data is also available on-line, at dozens of sites across the U.S., updated twice daily IIRC. https://weather.uwyo.edu/upperair/sounding.html
But this data is useful for quasi-static pressure data vs. GPS altitude, i.e. making your baro sensor as accurate for apogee as the GPS of the balloon sounding payload. I agree an accelerometer is the best way to go for decent-quality maximum velocity data.

 

[Chuck Rogers]

Weather balloon data is also available on-line, at dozens of sites across the U.S., updated twice daily IIRC. https://weather.uwyo.edu/upperair/sounding.html
But this data is useful for quasi-static pressure data vs. GPS altitude, i.e. making your baro sensor as accurate for apogee as the GPS of the balloon sounding payload. I agree an accelerometer is the best way to go for decent-quality maximum velocity data.

Thanks Adrian!

(Who in the past has graciously provided flight data for CD and altitude comparisons on the RASAero web site.)

Charles E. (Chuck) Rogers