Barometric Correction of Single-Axis Accelerometer Data

[mikec]

Ahh..ok. No, the Python AHRS does not have an option to not use Accel data.

You could try using the Integration estimator, which only uses gyro data. What you really want to do is use the accel data on the pad to determine the initial orientation, then use pure integration (or ideally, gyro/magnetometer fusion) to compute orientation thereafter. You could try passing all zeros for accel, but if that didn't work it wouldn't surprise me.

 

[jgavlik]

How about centripital force as the rocket is decending from max altitude and swinging around on the shock cord? Is there acceleration then, as well?

 

[cerving]

Accelerometers' X-Y axis readings are thrown off by any rotation around the Z axis, which is why you need a gyro to compensate. Integration of only the z-axis will give you a "path distance", independent of what your rocket is actually doing... you can't correct your baro readings with that, but you can compare the two and if they're close you can be reasonably sure that the rocket is going "straight up".

 

[waltr]

I don't know if forcing acclerometer values to 0 will work you can try it and see what happens.

The Madgwick algorithm uses the magetometer data to correct the accelerometer data. Then uses the assumed gravity direction to correct the gyro's. If the gyro is indicating a rotation but the gravity vector isn't moving then the algorithm assumes the gyro is drifting and trusts the gyro reading less. That works in a plane or drone because the average external acceleration over the flight profile is close to zero and the gravitational force dominates. In a rocket flight the the gravitational force cannot be detected by the accelerometer so the algorithm doesn't work while the rocket is flying.

I have been reading the AHRS documentation and found that when the Accelerometer values goes above a threshold the Accel data is reduced or equal to Zero. This prevents a False reference when a vehicle moves with high acceleration.
Therefore, this MARG python function Will work for a rocket.
See: https://ahrs.readthedocs.io/en/latest/filters/aqua.html
Adaptive Gain.

 

[jderimig]

I have been reading the AHRS documentation and found that when the Accelerometer values goes above a threshold the Accel data is reduced or equal to Zero. This prevents a False reference when a vehicle moves with high acceleration.
Therefore, this MARG python function Will work for a rocket.
See: https://ahrs.readthedocs.io/en/latest/filters/aqua.html
Adaptive Gain.

Good find, that will protect errors during boost but may be vulunerable during the cost phase.

 

[waltr]

That may be in error... I went through the source code in Github. The MARG function does not use this Acc reduction. It simply Normalizes the Acc value to a unit vector. So not great for a rocket but might not be too bad.
Not sure how the math would work if the Acc vector is less than a unit vector. The Acc vector is subtracted so setting to zero may still work.

# Accelerometer data = acc, a = acc unit vector
a = acc/a_norm    # multiply this by gain factor out from the Adaptive Gain function

# Gradient objective function (eq. 31)
            f = np.array([2.0*(qx*qz - qw*qy)   - a[0],
                          2.0*(qw*qx + qy*qz)   - a[1],
                          2.0*(0.5-qx**2-qy**2) - a[2],
                          2.0*bx*(0.5 - qy**2 - qz**2) + 2.0*bz*(qx*qz - qw*qy)       - m[0],
                          2.0*bx*(qx*qy - qw*qz)       + 2.0*bz*(qw*qx + qy*qz)       - m[1],
                          2.0*bx*(qw*qy + qx*qz)       + 2.0*bz*(0.5 - qx**2 - qy**2) - m[2]])  # (eq. 31)

I have a Vpython visualation of the rocket launch using the MARG Quanternion output. The graphic shows the rocket moving (rotations) much as it did go at launch. I need more launches to check this further. Next launch is February and planning to angle the rail a little more (or let wind weather cock rocket) so to get a non-vertical flight. This is to test data against your WGX and the MARG algorithms.
Fun stuff.