Flight Computers: Accelerometers vs Barometric Sensors

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Gary Mac

Active Member
Joined
Sep 3, 2018
Messages
38
Reaction score
4
Location
Colorado
I've got some experience with the basic eggtimer flight computer, which I understand is a barometric sensor based flight computer. I'm now working towards my L3 and needing to invest in a 2nd flight computer to meet the redundancy requirements.

I've heard that for an L3-cert level flight, it's wise to have the 2nd (primary) flight computer include an accelerometer in addition to the standard barometric sensor. I assume this is particularly useful if one goes to an extreme altitude where barometric sensors don't work as well for triggering drogues at apogee, or if the rocket exceeds mach 1 and distorts the pressure reading. The eggtimer's documentation makes me think the designer was aware of this problem since it states "Filtered altitude/velocity sampling to eliminate false triggering of ejection charges due to mach transition."

However, there really aren't all that many flight computers that include an accelerometer, and they're all pretty high priced. From looking at the old chart at https://rocketsetc.com/altimeter-comparison/, my options for a dual-deployment are limited to the models below, which are all a lot more expensive/complex than something more familiar like the eggtimer quark or RRC3 I was hoping to use. (Unfortunately, the Adept22 appears to be no longer available).

Anyone care to share their experiences on how necessary an accelerometer is? From a brief skim through other's L3 build docs, it looks like some people go with barometric sensors only, though many do indeed use an accelerometer.

If you've got other options for accelerometer flight computers not shown on the list below, feel free to post them too.
altimeters.JPG

For reference, I'm looking at hitting Mach 1.2 and 10k feet on my L3 cert flight. Should be well within our field's altitude limits.
 
Accelerometers are really useful if you want accurate velocity measurements if you are exceeding Mach, as you mentioned baro's get wonky at that threshold. I have several flight beyond Mach 1 with baro only, never an issue with deployment. There are a few out there with accelerometers: Altus Metrum products, MARSA54 and the Raven3 but Raven3 is currently unavailable as the developer is working on next gen Raven 4. I like them all, but the Raven is most compact.
 
Not necessary at all. Accel altimeters are useful for collecting data to analyze speed, thrust, and drag. They need good calibration, are susceptible to the programmer's integration errors, and not reliable for apogee detection. Unless you fly above 40k feet (I don't remember the exact threshold), baro altimeters are preferred for deployment. Mach is not an issue.
 
On the raven 3 transonic to supersonic flight was an issue and you had to code it velocity vs time was recommended. There’s a pressure change across a shockwave and that trips up a pressure sensitive barometric altimeter during supersonic staging of multistage rockets in theory. The accelerometer altimeter has the advantage of not being fooled as easily once set up programmed correctly and calibrated and flown within G limits. That’s what I remember about supersonic multistages and altimeters. The manual clearly stated use different settings than when subsonic. I’ve only done two supersonic multistages as college capstone projects. Mentored two more. We had no problems with raven once coded correctly. I’ll credit the raven to saving our lives. It didn’t fire the sustainer when a interstage imploded at M1.5. The Raven 3 was the best thing this forum recommended to us novices. We had no HPR experience and it was simple to program, ground test, and fly. By our second rocket we had sustainer ignition and successful recovery. You could export OR data in excel then import that to raven then ground test it in a raven sim. By third team they had their first multistage rocket first flight work with our code. I know this group will love the Raven 4 when released. It enables college groups with very low rocket experience to compete in L-1 multistage competition SEDS. That is the end of my raven experience. I’m still novice. We didn’t have mentors and we got the raven to work that speaks volumes for how easy it is to use. Thanks Adrian.
 
On the raven 3 transonic to supersonic flight was an issue and you had to code it velocity vs time was recommended. There’s a pressure change across a shockwave and that trips up a pressure sensitive barometric altimeter during supersonic staging of multistage rockets in theory. The accelerometer altimeter has the advantage of not being fooled as easily once set up programmed correctly and calibrated and flown within G limits. That’s what I remember about supersonic multistages and altimeters. The manual clearly stated use different settings than when subsonic. I’ve only done two supersonic multistages as college capstone projects. Mentored two more. We had no problems with raven once coded correctly. I’ll credit the raven to saving our lives. It didn’t fire the sustainer when a interstage imploded at M1.5. The Raven 3 was the best thing this forum recommended to us novices. We had no HPR experience and it was simple to program, ground test, and fly. By our second rocket we had sustainer ignition and successful recovery. You could export OR data in excel then import that to raven then ground test it in a raven sim. By third team they had their first multistage rocket first flight work with our code. I know this group will love the Raven 4 when released. It enables college groups with very low rocket experience to compete in L-1 multistage competition SEDS. That is the end of my raven experience. I’m still novice. We didn’t have mentors and we got the raven to work that speaks volumes for how easy it is to use. Thanks Adrian.

Aren’t you supposed to be studying or trying to find where your mother hid your rocket part?
 
I found my rocket stuff and finished thermal component.
 
If you’re a data junkie, get something with an accelerometer. Otherwise the baro only options are quite sufficient.

As for accel detection of apogee, I know my MARSA let you program it for baro deployment as one of several options.
 
Accelerometers work well for rockets with transitions, odd shapes, etc where there is disturbed airflow that can cause problems with barometric altimeters.
 
I've heard that for an L3-cert level flight, it's wise to have the 2nd (primary) flight computer include an accelerometer in addition to the standard barometric sensor. I assume this is particularly useful if one goes to an extreme altitude where barometric sensors don't work as well for triggering drogues at apogee, or if the rocket exceeds mach 1 and distorts the pressure reading.
I, uh, don't agree with that, on multiple fronts. First off, baro will always be more accurate when compared to accelerometer apogee events with our current crop of available hardware. Accelerometer based apogee detection rarely works well and more often than not incurs a sub-optimal early apogee event, especially the higher you go. The longer the flight, the more the accelerometer errors accumulate which leads to the early deployment.

For reference, I'm looking at hitting Mach 1.2 and 10k feet on my L3 cert flight. Should be well within our field's altitude limits.
And well within a baro sensor's range. From my understanding the baro sensors we fly are effective to 31km/~100k'. Above that they're not effective as the sensor readings are down in the noise floor of the sensor due to the lack of atmospheric pressure above 100k'. And unless you're flying something quite old (say, a mAWD for instance) the Mach inhibit will be inbuilt, so you shouldn't have a baro deployment event when you're trans-sonic/supersonic.

If I were you I'd investigate a StratologgerCF as your backup/secondary FC. They're affordable, reliable, and don't require any Mach transition configuration. If you're after accelerometer data then find a Raven.

If you're really keen on having an apogee deployment event that isn't baro but is accurate (unlike accelerometer apogee) then you could consider a magnetic apogee device. For mine magnetic apogee detection is the most accurate means of getting an apogee event to occur exactly at apogee. Baro always seems to be a second or two late from my experience. I fly uMADs and have for years but they're no longer available. That said the ZeptoMag seems to be available.
https://zeptobit.com/zeptomag-with-screw-terminals.html
Just be aware that's an apogee only unit so it won't help with a redundant/secondary main deployment.
 
Baro only will be fine. I have gone to Mach 1.8 with Ravens without any issue. Most of the current crop of baro alts handle Mach lockout one way or another. The end result is that they work.
 
Accelerometer based apogee detection rarely works well and more often than not incurs a sub-optimal early apogee event, especially the higher you go. The longer the flight, the more the accelerometer errors accumulate which leads to the early deployment.

This is common broad generalization that is not generally true. Attached are data from 3 flights chosen at random, I could have attached 100's more, that show almost perfect accelerometer apogee deployment on flights from 14K to 30K.The blue line in the plots is the inertial altitude and the point where the line goes vertically to zero or peaks is the acceleration based apogee detection.The red line is the barometric altitude.

I also can share onboard videos that show perfect accelerometer apogee deployment on Balls flights of 60K to 80K. These results are the rule rather than the exception with this particular set of electronics.

Of course to get good results with accelerometer based apogee you have to realize that the instrument is a seismic device and mounting is key. You can't have a sled that is sliding and bouncing in the av-bay for example with such an instrument.

And you have to have a good linear sensor.

This coming weekend at Balls we will have rocket projects over 100K feet (some well over) that will likewise show accurate accel based apogees.
 

Attachments

  • morgan.PNG
    morgan.PNG
    57 KB · Views: 118
  • Nballs.PNG
    Nballs.PNG
    63.2 KB · Views: 112
  • Oballs.PNG
    Oballs.PNG
    81.4 KB · Views: 97
Last edited:
Hi John,

Thanks for the response, it's always good to have someone more knowledgable than I am to comment on these types of things.

This is common broad generalization that is not generally true.

Is that specifically with regards to your boards, or accelerometer equipped altimeters in general? The reason I ask is that from what I've been told for the Ravens over 100k' one of the recommended methods by Adrian for getting a good apogee deployment event is to use the "detected apogee plus delay" configuration due to accelerometer drift. Also, a few weeks ago I was pinging the AltusMetrum mailing list regarding configuring the EasyMega for apogee detection over 100k' and Keith's responses were quite enlightening. Below are some snippets from his response.

The flight computer continues to estimate the state of the rocket from the accelerometer, trying to figure out when the rocket reaches zero vertical velocity. That's a matter of integrating acceleration, which if the sensors were perfect, would also be perfect. Because we integrate only the z-axis acceleration, and the airframe is tilting over during flight, that introduces error which makes the computer think the rocket reaches apogee before it actually does.

and following on from that.

I've started using the tilt angle estimation to look at vertical speed in post-flight analysis to see if that helps at all, but the reality is that we're using a 105g accelerometer for vertical acceleration with 10 bits of resolution, which means about 1/10g per bit. So, a single bit error in the acceleration measurement integrated over 10 seconds yields a 10m/s mis-estimate in speed. Over 100 seconds, you can end up with a 100m/s mis-estimate, which is 10 seconds off in apogee estimation.

Oh, one thing that is absolutely critical -- recalibrate your accelerometer before flight; they tend to drift over time.... Again, small errors in calibration yield large potential errors in apogee estimation.

So from how I read Keith's responses given the EasyMega is only integrating z-axis acceleration data unless the flight is perfectly vertical apogee will be reported earlier than actual. That's also assuming the accelerometer calibration is good, which apparently does drift over time and needs to be recalibrated to ensure it's accurate.
 
Is that specifically with regards to your boards, or accelerometer equipped altimeters in general?
If proper filtering is used (like a kalman filter) a board with baro + accelerometer will be far more accurate at detecting apogee than one without. if your talking baro only vs accel only id probably pick the board with the barometer so you dont have to worry about integration error and non vertical flight, but either would work in most cases.

From my understanding the baro sensors we fly are effective to 31km/~100k'. Above that they're not effective as the sensor readings are down in the noise floor of the sensor due to the lack of atmospheric pressure above 100k'.
The ADC will continue to spit out pressure data until it reaches 10 mbar (aprox 100k') but the actual pressure sensor is only rated down to 300 mbar, which is around 30k ft. Pressure data from the sensors used on our altimeters beyond 50k' is probably not even worth looking at, because at that point your so far into the extended range of the sensor that the error is going to be over 10k' in the sensor alone.
 
I think there's going to be a new option real soon... :)

On the baro vs accelerometer issue, the integrated accelerometer data in the z-axis gives you the distance that the rocket traveled, regardless of path. So, if your rocket corkscrews on the way up or goes significantly off-vertical then it's going to overstate the AGL altitude by a fair amount. Unless you're going over 60K, I'd personally trust the baro altitude figure over the accelerometer figure ALONE. Look at the middle graph in John's post #11, that's pretty typical of most flights. If you use a Kalman or similar fused-sensor filter, you might get a "better" reading, but it would be dependent on the trust factor of the sensors' data... you can't really trust the z-axis accelerometer's altitude data because it's not measuring the same AGL data as the baro. The accelerometer will definitely give you a better velocity figure, though, since it's not dependent on your rocket's path, and it's way better at determining boosts and burnouts.

Now, if you have a full IMU and correct for x and y axis data, the accelerometer's AGL altitude figure should be more accurate than the barometer, because you don't have external conditions such as temperature or airflow to take into effect. And of course, once you get over about 60K all bets are off with the barometer... the accuracy goes way down once the difference in your readings get close to the resolution of the sensor.
 
Hi John,

Is that specifically with regards to your boards, or accelerometer equipped altimeters in general? The reason I ask is that from what I've been told for the Ravens over 100k' one of the recommended methods by Adrian for getting a good apogee deployment event is to use the "detected apogee plus delay" configuration due to accelerometer drift. A


So from how I read Keith's responses given the EasyMega is only integrating z-axis acceleration data unless the flight is perfectly vertical apogee will be reported earlier than actual. That's also assuming the accelerometer calibration is good, which apparently does drift over time and needs to be recalibrated to ensure it's accurate.

I can't speak for other implementations of acceleration measurement and integration as there are many ways to have a non-optimum system. However my products have been developing the acceleration measurement and integration system for 10 years now with constant firmware upgrades (done by the user). But I will admit, its much harder to implement inertial apogee than barometric apogee.

I am foolishly going to give away a trade secret here (but not all of them). Designing an altimeter to determine inertial apogee assuming a perfectly vertical flight when the probability of a perfectly vertical flight is exactly zero is a poor design.

On the subject of IMU correction of the gravity vector. Yes if you are off at 25 to 35 degrees then tilt correction is useful. But for that flight profile you will have other issues more interesting than apogee detection. If the rocket is within 15 degrees of vertical tilt correction with real devices will be in the noise (especially if you do not assume perfectly vertical flight in the math of the integration).

For relatively terrestrial flights, baro is the way to go. Less things the altimeter designer has to get right. Is the pressure rising? then apogee happened, duh.

If you are going REAL high, then an accurate accelerometer system is very useful, either standalone or as an input to a Kalman Filter.

In a very extreme (Karman Line) Balls flight this weekend we will be testing a system that fuses baro, acceleration and GPS in a extended Kalman Filter. We are not worried at all about the accelerometer measurement part of this flight.
 
I can't speak for other implementations of acceleration measurement and integration as there are many ways to have a non-optimum system. However my products have been developing the acceleration measurement and integration system for 10 years now with constant firmware upgrades (done by the user). But I will admit, its much harder to implement inertial apogee than barometric apogee.

I am foolishly going to give away a trade secret here (but not all of them). Designing an altimeter to determine inertial apogee assuming a perfectly vertical flight when the probability of a perfectly vertical flight is exactly zero is a poor design.

On the subject of IMU correction of the gravity vector. Yes if you are off at 25 to 35 degrees then tilt correction is useful. But for that flight profile you will have other issues more interesting than apogee detection. If the rocket is within 15 degrees of vertical tilt correction with real devices will be in the noise (especially if you do not assume perfectly vertical flight in the math of the integration).

For relatively terrestrial flights, baro is the way to go. Less things the altimeter designer has to get right. Is the pressure rising? then apogee happened, duh.

If you are going REAL high, then an accurate accelerometer system is very useful, either standalone or as an input to a Kalman Filter.

In a very extreme (Karman Line) Balls flight this weekend we will be testing a system that fuses baro, acceleration and GPS in a extended Kalman Filter. We are not worried at all about the accelerometer measurement part of this flight.
A bit 'late', but did you solve the problem. I plan on designing a 100km (Karman line) flight computer and wonder what you concluded.
 
A bit 'late', but did you solve the problem. I plan on designing a 100km (Karman line) flight computer and wonder what you concluded.
Yes. Inertial integration was demonstrated to be very accurate with occasional corrections from GPS and baro readings.
 
Back
Top