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

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Joined
Feb 25, 2020
Messages
17
Reaction score
0
I need to be able to precisely measure a high-powered rocket's velocity after motor burnout. There is an onboard altimeter, as well as an accelerometer available to me. Which would yield a more accurate result?

Also, any recommendations for implementing this with a real time system? If I were to use the altimeter, it would not be ideal to sample, and then put the system to sleep while waiting for the second sample, as there are other processes I need running as well.

If I can provide more information to enable better answers, please let me know.

Thanks,
Joshua
 
Accelerometer. Barometric sensors are almost useless to sense velocity. Accelerometer has to have enough range to not saturate with the peak acceleration.
 
@BEC
I need the vertical velocity relative to earth. I do have a gyroscope on board, and have already written the software to convert to spherical coordinates, and determine vertical velocity from the accelerometer.

That was one perceived advantage of the altimeter, is that it's readings are already with respect to vertical velocity.
 
Also, any recommendations for implementing this with a real time system?
You talk about processes. An RTOS is overkill, most systems I know of use bare metal and polling. You need a clean, accurate timebase, and you probably need to sample the accel at at least 20-50 Hz. Many chips have some kind of internal digital filter that would help. If you have to use an RTOS, you will want a low-latency interrupt handler or a device driver. Some chips may have a FIFO with timestamps.

You have to be off-vertical by a lot to have the integrated velocity be very far off, you probably don't need the gyro for any reasonable ascent angle.
 
I need to be able to precisely measure a high-powered rocket's velocity after motor burnout.

If you want airspeed a pitot-static sensor is an option, depending on peak velocity. Distance/time could also be an option with a fast GPS if you want it averaged over about 100ms (with a fast GPS) or longer.

Accelerometers have their issues too. Linearity and offset specifications can cause the integrated result to be out, especially as time progresses. I would think resolution/quantisation factor in also, so I guess the answer is "it depends". Do you seek accuracy and/or precision? What number(s) do you want? BTW, "precisely" doesn't count in engineering ;).
 
I need to be able to precisely measure a high-powered rocket's velocity after motor burnout. There is an onboard altimeter, as well as an accelerometer available to me. Which would yield a more accurate result?

Also, any recommendations for implementing this with a real time system? If I were to use the altimeter, it would not be ideal to sample, and then put the system to sleep while waiting for the second sample, as there are other processes I need running as well.

If I can provide more information to enable better answers, please let me know.

Thanks,
Joshua

It's fun to measure velocity using a barometer. Then after completing the math, throw the results in the garbage.

Seriously. It's worthless.
 
It's best to integrate the acceleration data for velocity. If barometric altimeter data is used for velocity, you need a calibrated pitot tube or other calibrated system. We had calibrated static ports and a nose tip total pressure port for a project I was involved with, the port pressure data was calibrated using CFD. But most rocketeers don't do this, so without a calibrated pitot tube or calibrated static ports/total pressure ports, I don't recommend using barometric altimeter data for measuring velocity.

So why do barometric altimeters work, and work well, for measuring apogee altitude? When the rocket goes through apogee, the velocity is very low. The static pressure you measure at a given port at apogee is the atmospheric pressure, as long as the rocket velocity is very low. There would be very little correction of the static pressure data using the pitot tube calibration, or other calibration, as long as the velocity is very low.

So barometric altimeters work well for measuring one data point, which is one very useful data point, the apogee altitude. They also work well for parachute deployment, for while the accuracy decreases as the velocity is higher both before and after apogee, the accuracy is still good enough for parachute deployment.

To make barometric altimeters even more accurate, you launch weather balloons prior to launch, and using the data from the weather balloons you correct the barometric altimeter data. Very few rocketeers do this. Barometric altimeters provide good accuracy for apogee altitude without adding weather balloon data. It's obviously a lot of effort to launch weather balloons with the atmospheric sensors required to get the balloon data.

Many of the RASAero altitude comparisons with flight data on the RASAero web site ( www.rasaero.com ) are based on barometric altitude flight data, again using just the apogee altitude from the barometric altimeter.


Charles E. (Chuck) Rogers
 
The Featherweight Raven altimeter has both a baro sensor and an accelerometer. Best of both worlds. $160. Easy to upload, download, program. Built-in USB port. No, I don't work for them. :)
 
@BEC
I need the vertical velocity relative to earth. I do have a gyroscope on board, and have already written the software to convert to spherical coordinates, and determine vertical velocity from the accelerometer.

That was one perceived advantage of the altimeter, is that it's readings are already with respect to vertical velocity.

You'll need at least a 3-axis accelerometer to measure it accurately relative to Earth, plus a gyroscope so you can filter out any aliased X-Y acceleration due to spin. As long as you're going more or less straight up, a z-axis accelerometer like the one on the Eggtimer Proton is "good enough". Baro velocity is inherently in relation to Earth, but there tends to be a lot of noise in it, at least until your motor burns out. We use both the Z-axis accelerometer velocity and the baro velocity in the "Deviation" calculation on the Proton, if the two are fairly close and your motor isn't burning then it tends to give you an indication that you're going pretty much vertically. It's not as pretty as a full IMU, but it's a lot simpler.
 
The pitot tube is the sensor you are looking for. This sensor can measure the fluid's flow speed.
 
The Featherweight Raven altimeter has both a baro sensor and an accelerometer. Best of both worlds. $160. Easy to upload, download, program. Built-in USB port. No, I don't work for them. :)
Easy to program?

I think there are masters courses on the subject and many extremely intelligent people I know still get it wrong.
 
If you want airspeed a pitot-static sensor is an option, depending on peak velocity. Distance/time could also be an option with a fast GPS if you want it averaged over about 100ms (with a fast GPS) or longer.

Accelerometers have their issues too. Linearity and offset specifications can cause the integrated result to be out, especially as time progresses. I would think resolution/quantisation factor in also, so I guess the answer is "it depends". Do you seek accuracy and/or precision? What number(s) do you want? BTW, "precisely" doesn't count in engineering ;).

I actually have been considering a pitot tube. What would you see as the pro/con vs an acceleromter? Could I use both in conjunction for error checking? Perhaps the pitot tube would calculate the v0 every time, or replace v0 if the v0 from the integration of the acceleration drifts too much?

As the velocity readout will used to calculate projected altitude and fed to a PID, I assume accuracy would be more important than precision. Though lack of precision could cause some excessive "flutter", I don't think that presents any issues. I did consider a fast GPS, I plan on using a sampling rate of 100ms, though this will be adjusted based on test flights.
 
Last edited:
You talk about processes. An RTOS is overkill, most systems I know of use bare metal and polling. You need a clean, accurate timebase, and you probably need to sample the accel at at least 20-50 Hz. Many chips have some kind of internal digital filter that would help. If you have to use an RTOS, you will want a low-latency interrupt handler or a device driver. Some chips may have a FIFO with timestamps.

You have to be off-vertical by a lot to have the integrated velocity be very far off, you probably don't need the gyro for any reasonable ascent angle.
You talk about processes. An RTOS is overkill, most systems I know of use bare metal and polling. You need a clean, accurate timebase, and you probably need to sample the accel at at least 20-50 Hz. Many chips have some kind of internal digital filter that would help. If you have to use an RTOS, you will want a low-latency interrupt handler or a device driver. Some chips may have a FIFO with timestamps.

You have to be off-vertical by a lot to have the integrated velocity be very far off, you probably don't need the gyro for any reasonable ascent angle.

That is helpful, thanks. I was considering polling as well, sounds like it might be the best method since it is a synchronous application. Regarding angle, if all is well, it shouldn't be an issue. Considering I have already written a function using the gyro, what would be the biggest pro/con of using it anyway, even if it is unnecessary for a good flight?
 
It's best to integrate the acceleration data for velocity. If barometric altimeter data is used for velocity, you need a calibrated pitot tube or other calibrated system. We had calibrated static ports and a nose tip total pressure port for a project I was involved with, the port pressure data was calibrated using CFD. But most rocketeers don't do this, so without a calibrated pitot tube or calibrated static ports/total pressure ports, I don't recommend using barometric altimeter data for measuring velocity.

So why do barometric altimeters work, and work well, for measuring apogee altitude? When the rocket goes through apogee, the velocity is very low. The static pressure you measure at a given port at apogee is the atmospheric pressure, as long as the rocket velocity is very low. There would be very little correction of the static pressure data using the pitot tube calibration, or other calibration, as long as the velocity is very low.

So barometric altimeters work well for measuring one data point, which is one very useful data point, the apogee altitude. They also work well for parachute deployment, for while the accuracy decreases as the velocity is higher both before and after apogee, the accuracy is still good enough for parachute deployment.

To make barometric altimeters even more accurate, you launch weather balloons prior to launch, and using the data from the weather balloons you correct the barometric altimeter data. Very few rocketeers do this. Barometric altimeters provide good accuracy for apogee altitude without adding weather balloon data. It's obviously a lot of effort to launch weather balloons with the atmospheric sensors required to get the balloon data.

Many of the RASAero altitude comparisons with flight data on the RASAero web site ( www.rasaero.com ) are based on barometric altitude flight data, again using just the apogee altitude from the barometric altimeter.


Charles E. (Chuck) Rogers

That is a great explanation, thanks. That makes sense why they are still OK for apogee. Seems like accelerometer is the way to go.
 
You'll need at least a 3-axis accelerometer to measure it accurately relative to Earth, plus a gyroscope so you can filter out any aliased X-Y acceleration due to spin. As long as you're going more or less straight up, a z-axis accelerometer like the one on the Eggtimer Proton is "good enough". Baro velocity is inherently in relation to Earth, but there tends to be a lot of noise in it, at least until your motor burns out. We use both the Z-axis accelerometer velocity and the baro velocity in the "Deviation" calculation on the Proton, if the two are fairly close and your motor isn't burning then it tends to give you an indication that you're going pretty much vertically. It's not as pretty as a full IMU, but it's a lot simpler.

Good thoughts. I am using a three-way accelerometer with a gyro, and have written a function to calculate with spherical coordinates to filter out spin. The flight should be basically vertical, so that might not be necessary. Interesting idea to use both barometric and and accelerometer in conjunction. Would you recommend using the altimeter to try to adjust drift from the accelerometer calculation?
 
Good thoughts. I am using a three-way accelerometer with a gyro, and have written a function to calculate with spherical coordinates to filter out spin.
The horizontal axes of the accelerometer are useless once the rocket is flying because there is no longer a gravity reference. Only a gyro possibly corrected by a magnetometer can be use to determine attitude.
 
The horizontal axes of the accelerometer are useless once the rocket is flying because there is no longer a gravity reference. Only a gyro possibly corrected by a magnetometer can be use to determine attitude.
I hadn't thought of that. The sensor I am using does have a magnetometer, which may be used internally in the sensor library to give accurate information.
 
It's a good idea to understand the basic physics of how you sense velocity with a one-axis accelerometer alone before trying to do everything three-axis, use sensor fusion, etc.

There are off-the-shelf solutions if you just want to get the measurement, but it's not my impression that's what you're trying to do.
 
It's a good idea to understand the basic physics of how you sense velocity with a one-axis accelerometer alone before trying to do everything three-axis, use sensor fusion, etc.

There are off-the-shelf solutions if you just want to get the measurement, but it's not my impression that's what you're trying to do.

I think I have a decent understanding of the physics of getting velocity from a one-axis accelerometer vi = (vi-1 + ((a2+a1)/2)(t2-t1)). I am seeking to employ the simplest method that is sufficiently accurate. If a one-axis accelerometer would be good enough, I would be happy to use that. The velocity will be used in a calculation for a PID for airbrakes (trying to hit a specific apogee very precisely +-20m). I am open to an off-the-shelf solution, provided I can feed the output easily into my PID computer.
 
Thanks for sharing that data, looks great!

I am trying to understand the data, are there two different accelerometers measuring altitude? What conclusions did you draw from the results?

The Proton has barometer filtered altitude (FAlt) and filtered velocity F(dAlt/dt). It has a single axis accelerometer, and report Accel and integrated velocity (VAccel) and double integrated altitude (AltAccel).

The dataset graphed also has the altitude, vertical velocity, and vertical acceleration data from OpenRocket. Blue/green == flight data. Red == openrocket data. As noted above, integrating accelerometer data is fraught with peril, but this happened to be a very straight up flight on a very calm day.

In the first graph, the two green lines are altitude by baro (top) and accelerometer (bottom). You can see the disturbances during boost in the upper line that Chuck Rogers is talking about - suboptimal, uncalibrated ports. And you can see how the accelerometer A and V data in blue overlay the red.

Lastly, you can see how the simmed altitude data is closer to the accelerometer data during high speed boost, diverges during coast, and approaches the baro altitude at apogee.

The second graph is a repeat, but I put in the baro-derived vertical velocity data for direct comparison to the accelerometer and sim. It's way high during boost, then converges during coast.
 
I think I have a decent understanding of the physics of getting velocity from a one-axis accelerometer... I am seeking to employ the simplest method that is sufficiently accurate.
Since you seem to have fallen into the trap of thinking you could sense off-vertical ascent with a 3-axis accel during boost, it was hard to be sure.

Basically, once you are in flight you have to subtract 1g from your sensed acceleration since you can't see the effect of gravity.

For a reasonably vertical flight, I think you'll find that a sensitivity analysis shows that doing everything one-axis is sufficient. Once you are more than say 10 or 20 degrees off-vertical that won't be true.

I don't know what the right answer is for your problem. Once you have slowed enough to reliably sense altitude barometrically your airbrakes won't be very effective. So I would try doing everything with a one-axis accel to start.

You can get the datastream out of a Raven as TTL serial data, but I've never tried that. Perhaps you can for the Proton as well.
 
I believe the Proton only reports baro altitude as a serial stream. I posted my pictures as an example of what you might see from a single axis accelerometer on a custom ATMega based flight computer. Just meant to be illustrative.

A flight lasts only a few seconds. That's an awfully short time for a PI loop to work. I'd be tempted to work out a time-brake curve based on sim, correctable for the actual boost (accelerometer measured), load it in to the flight computer and have it run the preloaded program, corrected for the boost once it's done and known.
 
Since you seem to have fallen into the trap of thinking you could sense off-vertical ascent with a 3-axis accel during boost, it was hard to be sure.

Basically, once you are in flight you have to subtract 1g from your sensed acceleration since you can't see the effect of gravity.

For a reasonably vertical flight, I think you'll find that a sensitivity analysis shows that doing everything one-axis is sufficient. Once you are more than say 10 or 20 degrees off-vertical that won't be true.

I don't know what the right answer is for your problem. Once you have slowed enough to reliably sense altitude barometrically your airbrakes won't be very effective. So I would try doing everything with a one-axis accel to start.

You can get the datastream out of a Raven as TTL serial data, but I've never tried that. Perhaps you can for the Proton as well.

Gotcha, I definitely don't claim to have a great understanding of sensing off-vertical ascent, and I don't think I stated very clearly what my approach was. The implementation I wrote relies on the gyro to sense orientation and one-axis of the accelerometer, using basic trig to get the actual vertical acceleration. It sounds like this thinking is flawed, due to inability to trust orientation measurments from gyro? I would appreciate being corrected.

I will go ahead and run the first test using a one-axis accel. Sounds like I shouldn't bother calculating "true" vertical acceleration then?

Another thought: it seems the error in the vertical velocity calculation will sum over time, how significant should I expect this to be?

Would using a pitot tube on the nose be simpler/more accurate?
 
The Proton has barometer filtered altitude (FAlt) and filtered velocity F(dAlt/dt). It has a single axis accelerometer, and report Accel and integrated velocity (VAccel) and double integrated altitude (AltAccel).

The dataset graphed also has the altitude, vertical velocity, and vertical acceleration data from OpenRocket. Blue/green == flight data. Red == openrocket data. As noted above, integrating accelerometer data is fraught with peril, but this happened to be a very straight up flight on a very calm day.

In the first graph, the two green lines are altitude by baro (top) and accelerometer (bottom). You can see the disturbances during boost in the upper line that Chuck Rogers is talking about - suboptimal, uncalibrated ports. And you can see how the accelerometer A and V data in blue overlay the red.

Lastly, you can see how the simmed altitude data is closer to the accelerometer data during high speed boost, diverges during coast, and approaches the baro altitude at apogee.

The second graph is a repeat, but I put in the baro-derived vertical velocity data for direct comparison to the accelerometer and sim. It's way high during boost, then converges during coast.

That is super helpful, thanks for the analysis. Definitely confirms that getting altitude from a baro-alt is very untrustworthy during boost.
 
I believe the Proton only reports baro altitude as a serial stream. I posted my pictures as an example of what you might see from a single axis accelerometer on a custom ATMega based flight computer. Just meant to be illustrative.

A flight lasts only a few seconds. That's an awfully short time for a PI loop to work. I'd be tempted to work out a time-brake curve based on sim, correctable for the actual boost (accelerometer measured), load it in to the flight computer and have it run the preloaded program, corrected for the boost once it's done and known.

I have worried the same thing about the PID.

That is a really interesting alternative, not sure how I would sim the brakes though. Also I wonder if the sim could produce realistic enough results to be accurate? An advantage of the PID is it is based completely off of real time variables, and the quadratic drag equation (where drag is actually measured empirically in real-time).
 
Back
Top