Barometric Correction of Single-Axis Accelerometer Data

[ihbarddx]

So you have a single axis accelerometer/barometric altimeter recording flight computer and, though the launch was vertical, the flight wasn’t perfectly vertical. Barometric and inertial altitude curves are close but don’t match exactly. Here are some good approximate corrections you can do on the vendor numbers from the accelerometer.

DISCLAIMER: In a vertical launch, there is no valid reason that the barometric altitude should noticeably exceed the inertial altitude. If this occurs, maybe it was very cold and the barometric data are not temperature-adjusted. Always temperature-adjust data. Otherwise, the instrument is no good. Really. In my experience, it’s an accelerometer that has a nonlinear response – data for entertainment only. (Not mentioning brand names…)

Barometric data normally have anomalies near launch and in high-speed regions.

The approximating assumption used is that the work done by thrust and drag in the true trajectory is about the same as that done in the trajectory rendered by the vendor software. There are “exact” formulas, but they propagate noise more than these formulas do.

 

[jderimig]

It won't work because of real world deviations from theory. See my analysis on marsasystems.com tech info .

 

[ihbarddx]

Tested against simulated data and real data. The exact formulas fit perfectly in sims, while this is just a tad off. In practice, they are about the same.

References for real data are the exact formulas, and also off-vertical accelerometer analysis. It does have problems with conspicuously bad baro data.

Will read your stuff.

 

[ihbarddx]

Tested against simulated data and real data. The exact formulas fit perfectly in sims, while this is just a tad off. In practice, they are about the same.

References for real data are the exact formulas, and also off-vertical accelerometer analysis. It does have problems with conspicuously bad baro data.

Will read your stuff.

Skimmed your stuff. Yes. Geometric methods of tilt detection yield nonsense. This method uses conservation of energy, which is a lot more robust than the geometric methods. It took a long time to come up with it.

An early version of this can be found in L. Curcio's NARAM R&D report in NARAM53. I didn't have the sine formula yet, IIRC. (Had to sport fly that report, as I was judging that year.)

A reference on purely inertial off-vertical accelerometer analysis can be found in L. Curcio's NARAM R&D report from NARAM 49. (It uses tilt inference, rather than tilt detection.)

 

[jderimig]

Skimmed your stuff. Yes. Geometric methods of tilt detection yield nonsense. This method uses conservation of energy, which is a lot more robust than the geometric methods. It took a long time to come up with it.

An early version of this can be found in L. Curcio's NARAM R&D report in NARAM53. I didn't have the sine formula yet, IIRC. (Had to sport fly that report, as I was judging that year.)

A reference on purely inertial off-vertical accelerometer analysis can be found in L. Curcio's NARAM R&D report from NARAM 49. (It uses tilt inference, rather than tilt detection.)

Read the PDF and examine the sources of error. Then I suggest testing your algorithm in a Monte-Carlo like way of introducing all the possible error inputs and evaluate.

The main issue with this scheme is the assumption that the inertial altitude is less trusted than the barometric altitude, or the barometric altitude is the truth with a SAM temperature correction. Even if you had a perfectly adjusted atmospheric model (which is unknowable) the barometric altitude is only the truth on the ground and perhaps at apogee. In between the barometric altitude will have large errors due to fact that real pressure sensors in rocket altimeters bays will have significant lag between the true outside static pressure and the pressure in your av-bay.

In my experience in comparing high performance GPS data with altimeter data the inertial altitude is often closer to the GPS altitude even at apogee.

 

[jderimig]

What is your estimated uncertainty in the trajectorySine and trajectoryCos calculation?

 

[waltr]

Yea, examine sources of error. First is accelerometer offset and gain which is easiest to measure, should be 9.8m/s/s sitting still.

Altitude corrections are harder. Apogee Rockets has a newsletter discussing how to correct using weather data. Worth a read.

 

[Charles_McG]

Most of my staged sounding rockets read a baro altitude higher than the eggtimer protons or quantums they carry. Some markedly so - but those have shaped vent port details (rounded domes) that are almost certainly adding error. The fact that the baro-accelerometer difference is very proportional to velocity is a telling hint, too.

 

[ihbarddx]

Yes! Yes! Yes!!! Forgot to mention! You can't stick the altimeter in the nose cone if you want good barometric data. That works for deploying the laundry in a vertical ascent, but it doesn't work if you want to analyze the data.

Thanks for mentioning that!

 

[cerving]

Baro vs. Accelerometer altitude can be fairly close IF you launch straight up, AND you don't go too fast (maybe Mach 0.6), AND your thrust curve is fairly flat. Those are the criteria that the Proton's baro-accelerometer deviation airstart lockout mechanism work best under... if you're outside of them, you will probably see a significant difference in baro and accelerometer altitude, and the "tilt" lockout isn't going to work. I have seen flights where the two altitudes were very close... and I have seen "perfectly straight" flights where they were way off, too.

For measuring apogee with most sport flights, baro altitude with the STP model works OK since the pressure and temperature error throughout the flight is pretty much constant. If you wanted to be really accurate, you could compensate for the launch site barometric pressure and use a more responsive temperature sensor than the ones that are integrated into the baro sensors; it would have to be able to respond to changes in about 25 ms, however.

 

[ihbarddx]

Baro vs. Accelerometer altitude can be fairly close IF you launch straight up, AND you don't go too fast (maybe Mach 0.6), AND your thrust curve is fairly flat. Those are the criteria that the Proton's baro-accelerometer deviation airstart lockout mechanism work best under... if you're outside of them, you will probably see a significant difference in baro and accelerometer altitude, and the "tilt" lockout isn't going to work. I have seen flights where the two altitudes were very close... and I have seen "perfectly straight" flights where they were way off, too.

For measuring apogee with most sport flights, baro altitude with the STP model works OK since the pressure and temperature error throughout the flight is pretty much constant. If you wanted to be really accurate, you could compensate for the launch site barometric pressure and use a more responsive temperature sensor than the ones that are integrated into the baro sensors; it would have to be able to respond to changes in about 25 ms, however.

I agree

 

[jderimig]

The theoretical inertial altitude versus "true" (and unknowable) altitude deviation at 10 deg off vertical is 1.3%
The deviation at 15 degrees off vertical is 2.9%.

Both of those deviations is well within the combined baro and accel sensor error band. That's not even taking into account SAM and the pressure transfer function assumptions from outside rocket static pressure to av-bay pressure. You cannot determine the direction of the gravity vector with useful precision from the baro and accelerometers alone that are available to us in this hobby. You may be able to do it by adding a 3rd estimator (gyro, magnetic field sensor or high performance GPS).

 

[cerving]

John is absolutely correct, if you need a 100% accurate altitude you're going to need a really good IMU that you can integrate at a pretty decent rate (I'm thinking 100 samples/sec, although John may pipe in on that) in addition to a properly compensated baro sensor. This IS a hobby, after all... "close" is good enough for about 99% of our flights.

 

[ihbarddx]

I SCREWED UP!!!!!
I made a mistake in the sign of the correction formula. Here is the correction!!! Also changed original post.
e in a sign

 

[ihbarddx]

EXAMPLE!!!!!

Here are data from a LOC Vulcanite on a G40 motor. The launch was at 75th and the inertial readings are adjusted for the self-calibrating accelerometer. i.e.; It thinks g*sin(75) is 1g, so I multiplied all readings by sine(75).

The horizontal ordinate in all the graphs is TIME.

The sines were ill-behaved in the beginning, so I used sin(.75) from launch to the length of the launch rod. Things stabilized from there, after some roughness. Won’t kid you. There is ALWAYS roughness in the early sines. Again… early baro data.

In the altitude graph, CorrH is altitude from the formulas. (VY integrated WRT Time, actually) Note that it corresponds well with the stair-stepped barometric curve. There is some departure early on, in the high-speed regions. The vertical analysis altitude graph… sucks, however. I would say that there is sufficient precision, here, that the correction worked. You can form your own opinion.

The speed graph worked well. There is positive speed at apogee, because the launch was not perfectly vertical. Because the rocket didn’t reach the vertically-analyzed altitude, the speed is higher than the vertically-analyzed speed.

The last graph compares the corrected seed with off-vertically analyzed inertial speed. There is a good overall correspondence, particularly around apogee. I could have corrected this off-vertical inertial data, instead of vertically-analyzed inertial data. The results would probably have been better still. Wanted to illustrate that vertically-analyzed data can be used in this analysis.

 

[waltr]

Nice. I will be launching my first sensor (10DOF) payload this Saturday. Will study your math solutions and apply to my data.
Thanks for posting.

 

[ihbarddx]

Nice. I will be launching my first sensor (10DOF) payload this Saturday. Will study your math solutions and apply to my data.
Thanks for posting.

I'm going to post a spreadsheet with instructions. Turns out, it's sensitive to launch rod length. In essence, you have to extend sign of launch angle until the the data snap. (Normally within launchrod length)The baro graphs should then line up. The speed then looks like off-vertical inertial workup speed.

Let me know when you have questions. (Note the typo in the original version, BTW)

Happy flying!

 

[ihbarddx]

These aren't ready for prime time, but they are Excel spreadsheets that do barometric correction. They have embedded directions in MS WORD. Same spreadsheets, different data. (I actually have Excel VBA programs that do this and more, but they are in old versions of Excel. Also, there's the security aspect of macros, and the autoimmune reaction WIndows has to itself. No one uses such applications...)

Valid for ascents ONLY. After the laundry comes out, it don' work.

 

[ihbarddx]

On the far off-chance that anyone is intersted, here is a derivation of the barometric adjustment speed and trajectory tilt sine. It's a draft paper. It goes with the spreadsheets above. I don't recommend it, but it did help my Tsinghua University EE major wife get the sleep she so desperately needed.

 

[ihbarddx]

Here's a spreadsheet for a 30K-ft vertical launch on a GWIZ.

 

[waltr]

Wonderful derivation of equations. Starting from Work was a good idea.

Launched my 10DOF sensor payload last Saturday. This was in a BMS 3" school rocket.
Launch mass = 835gram, 146cm long, pushed with a Aerotech 29/40-120 F52-6T motor.
OR predicted ~800feet apogee.
Weather was cold (~30F), very light wind (<4mph). Flight was nearly straight up.

Attached is an Excel spreadsheet with all data and calculations.
Sheet 1 is the Raw data and the corrected/calibrated data.
Sheet 2 is calculation of Launch rail angle.
Sheet 3 is Drag Cd calc.
Sheet 4 is your WGX calculations

In general they make sense. The Sine looks odd and not like any of your examples. since flight was straight up the rocket stayed on a vertical path so Sine should stay close to 1. Also means the InertH is very close to BaroH.
At 6.627 sec the BaroH exceeded the InertH so the VI2 result was negative. Only possiblity I can come up with is that the Baro H is reading a bit too high. The Raw Baro altitude is corrected for Base Alitude (launch altitude) and Temperature.

I have also ran the 9DOF Sensor data through a Madgwick fusion (Python AHRS package) to create a rotation Quanternion. Then used this to display a model of the rocket motion in Vpython. This seems to work well.

 

[jderimig]

Wonderful derivation of equations. Starting from Work was a good idea.

Launched my 10DOF sensor payload last Saturday. This was in a BMS 3" school rocket.
Launch mass = 835gram, 146cm long, pushed with a Aerotech 29/40-120 F52-6T motor.
OR predicted ~800feet apogee.
Weather was cold (~30F), very light wind (<4mph). Flight was nearly straight up.

Attached is an Excel spreadsheet with all data and calculations.
Sheet 1 is the Raw data and the corrected/calibrated data.
Sheet 2 is calculation of Launch rail angle.
Sheet 3 is Drag Cd calc.
Sheet 4 is your WGX calculations

In general they make sense. The Sine looks odd and not like any of your examples. since flight was straight up the rocket stayed on a vertical path so Sine should stay close to 1. Also means the InertH is very close to BaroH.
At 6.627 sec the BaroH exceeded the InertH so the VI2 result was negative. Only possiblity I can come up with is that the Baro H is reading a bit too high. The Raw Baro altitude is corrected for Base Alitude (launch altitude) and Temperature.

I have also ran the 9DOF Sensor data through a Madgwick fusion (Python AHRS package) to create a rotation Quanternion. Then used this to display a model of the rocket motion in Vpython. This seems to work well.

If you are using the Madgwick algorithm you will need to disable the gravity (accelerometer) compensation of the gyro after launch. In your case of a nearly vertical flight it doesn't matter, but if you have a non-vertical flight the algorithm with the gravity loop will underestimate your actual rotation.

 

[waltr]

I really do not know what you mean by "disable the gravity (accelerometer) compensation of the gyro after launch".

 

[jderimig]

I really do not know what you mean by "disable the gravity (accelerometer) compensation of the gyro after launch".

If the Python AHRS package (I haven't used it) has the option to not use accelerometer data to determine the vehicle heading or attitude then you should use it. If it doesn't then the package isn't suitable for rocket dynamics.

 

[waltr]

Ahh..ok. No, the Python AHRS does not have an option to not use Accel data. There is an option for Magnetometer data but Acc & Gryo are required.

The output is a rotation Quanternion which does not have any altitude.heading info. Only the rotation info. This does seem to work.
I have a feeling that it does not do much with Acc data of rocket flight since it has Magnetometer data.
Could I simply set all the Accel data to Zeros to feed the Madgwich algorithm?
I can try this and see what the Quanternion looks like.

 

[jderimig]

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.

 

[waltr]

Thanks for the explanation.
If I posted the Quanternion output of the Madgwick algorithm and the Raw input data could you look to see if the the algorithm is working?
I can start another thread if you do not want this here.

 

[jgavlik]

John...you said..."In a rocket flight the the gravitational force cannot be detected by the accelerometer...."

Does this mean that accelerometers don't work in flight??

 

[UhClem]

Does this mean that accelerometers don't work in flight??

Of course they work, but gravity is a field that effects every particle of the rocket equally. So your MEMS sensor doesn't see gravity. Ever.

 

[jderimig]

John...you said..."In a rocket flight the the gravitational force cannot be detected by the accelerometer...."

Does this mean that accelerometers don't work in flight??

Your accelerometers only measure the accelerations due to net external force on the rocket, like thrust and drag. Body force acceleration (gravity) is not measured.