Barometric Correction of Single-Axis Accelerometer Data

The Rocketry Forum

Help Support The Rocketry Forum:

ihbarddx

Well-Known Member
Joined
Jan 18, 2019
Messages
51
Reaction score
7
Location
Pittsburgh
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.
 

Attachments

Last edited:

jderimig

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,828
Reaction score
1,392
It won't work because of real world deviations from theory. See my analysis on marsasystems.com tech info .
 

ihbarddx

Well-Known Member
Joined
Jan 18, 2019
Messages
51
Reaction score
7
Location
Pittsburgh
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

Well-Known Member
Joined
Jan 18, 2019
Messages
51
Reaction score
7
Location
Pittsburgh
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

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,828
Reaction score
1,392
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

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,828
Reaction score
1,392
What is your estimated uncertainty in the trajectorySine and trajectoryCos calculation?
 

waltr

Well-Known Member
Joined
Jul 18, 2021
Messages
135
Reaction score
92
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

Ciderwright
Joined
Sep 12, 2013
Messages
3,018
Reaction score
1,132
Location
SE Wisconsin
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

Well-Known Member
Joined
Jan 18, 2019
Messages
51
Reaction score
7
Location
Pittsburgh
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

Owner, Eggtimer Rocketry
TRF Sponsor
Joined
Feb 3, 2012
Messages
4,771
Reaction score
2,400
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

Well-Known Member
Joined
Jan 18, 2019
Messages
51
Reaction score
7
Location
Pittsburgh
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

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,828
Reaction score
1,392
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

Owner, Eggtimer Rocketry
TRF Sponsor
Joined
Feb 3, 2012
Messages
4,771
Reaction score
2,400
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

Well-Known Member
Joined
Jan 18, 2019
Messages
51
Reaction score
7
Location
Pittsburgh
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.



Vulcanite 75 Degrees.png
 

waltr

Well-Known Member
Joined
Jul 18, 2021
Messages
135
Reaction score
92
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

Well-Known Member
Joined
Jan 18, 2019
Messages
51
Reaction score
7
Location
Pittsburgh
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

Well-Known Member
Joined
Jan 18, 2019
Messages
51
Reaction score
7
Location
Pittsburgh
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.
 

Attachments

Last edited:

ihbarddx

Well-Known Member
Joined
Jan 18, 2019
Messages
51
Reaction score
7
Location
Pittsburgh
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.
 

Attachments

waltr

Well-Known Member
Joined
Jul 18, 2021
Messages
135
Reaction score
92
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.
 

Attachments

jderimig

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,828
Reaction score
1,392
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

Well-Known Member
Joined
Jul 18, 2021
Messages
135
Reaction score
92
I really do not know what you mean by "disable the gravity (accelerometer) compensation of the gyro after launch".
 

jderimig

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,828
Reaction score
1,392
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

Well-Known Member
Joined
Jul 18, 2021
Messages
135
Reaction score
92
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

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,828
Reaction score
1,392
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

Well-Known Member
Joined
Jul 18, 2021
Messages
135
Reaction score
92
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

Active Member
Joined
Sep 2, 2020
Messages
32
Reaction score
1
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

Well-Known Member
Joined
Feb 6, 2009
Messages
1,925
Reaction score
341
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

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,828
Reaction score
1,392
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.
 

Latest posts

Top