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

Discussion in 'Rocketry Electronics and Software' started by Joshua Koehler, Feb 25, 2020.

Help Support The Rocketry Forum by donating:

  1. Feb 25, 2020 #31

    Charles_McG

    Charles_McG

    Charles_McG

    Ciderwright

    Joined:
    Sep 12, 2013
    Messages:
    2,419
    Likes Received:
    515
    Location:
    SE Wisconsin
    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.
     
    Joshua Koehler likes this.
  2. Feb 25, 2020 #32

    mikec

    mikec

    mikec

    Well-Known Member

    Joined:
    May 9, 2009
    Messages:
    2,238
    Likes Received:
    212
    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.
     
  3. Feb 25, 2020 #33

    jderimig

    jderimig

    jderimig

    Sponsor TRF Sponsor

    Joined:
    Jan 23, 2009
    Messages:
    3,043
    Likes Received:
    462
    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 likes this.
  4. Feb 25, 2020 #34

    Joshua Koehler

    Joshua Koehler

    Joshua Koehler

    Member

    Joined:
    Feb 25, 2020
    Messages:
    17
    Likes Received:
    0
    Gender:
    Male
    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.
     
  5. Feb 25, 2020 #35

    Joshua Koehler

    Joshua Koehler

    Joshua Koehler

    Member

    Joined:
    Feb 25, 2020
    Messages:
    17
    Likes Received:
    0
    Gender:
    Male
    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.
     
  6. Feb 25, 2020 #36

    mikec

    mikec

    mikec

    Well-Known Member

    Joined:
    May 9, 2009
    Messages:
    2,238
    Likes Received:
    212
    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 likes this.
  7. Feb 25, 2020 #37

    Joshua Koehler

    Joshua Koehler

    Joshua Koehler

    Member

    Joined:
    Feb 25, 2020
    Messages:
    17
    Likes Received:
    0
    Gender:
    Male
    Thanks for the clarification and suggestion, that sounds like a good idea.
     
  8. Feb 25, 2020 #38

    Joshua Koehler

    Joshua Koehler

    Joshua Koehler

    Member

    Joined:
    Feb 25, 2020
    Messages:
    17
    Likes Received:
    0
    Gender:
    Male
    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.
     
  9. Feb 26, 2020 #39

    mikec

    mikec

    mikec

    Well-Known Member

    Joined:
    May 9, 2009
    Messages:
    2,238
    Likes Received:
    212
    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.

    Code:
    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];
        }
    }
    
     
    Joshua Koehler likes this.
  10. Mar 8, 2020 #40

    Adrian A

    Adrian A

    Adrian A

    Sponsor TRF Sponsor TRF Lifetime Supporter

    Joined:
    Jan 22, 2009
    Messages:
    2,258
    Likes Received:
    230
    Weather balloon data is also available on-line, at dozens of sites across the U.S., updated twice daily IIRC. http://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.
     
  11. Mar 10, 2020 #41

    Chuck Rogers

    Chuck Rogers

    Chuck Rogers

    Well-Known Member

    Joined:
    Jun 7, 2011
    Messages:
    144
    Likes Received:
    41
    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
     

Share This Page

Group Builder