Extracting Cd from accelerometer data

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
DAaang! There is some serious brain trust here guys! All my rockets have the drag coefficient of a Redwood. I'm just happy they go faster than I can run and higher than I can throw them. Thank my lucky stars I'm not smart enuff to have to worry about this. Seriously interesting stuff can be learned here-thanks!
 
I'm new to this forum so my reply is probably out dated. You referenced the Apogee newsletter above. Did you see a response in newsletter #315 from Dan Moses? He was a mentor for a group of high school students from Falls Church, VA. that submitted a project for the NASA Student Launch Initiative (SLI). The kids used acceleration data and velocity data during the coast phase of their rocket's launch to arrive at a Cd. They plotted acceleration on the y-axis and velocity squared on the x-axis and this resulted in a straight line which could be easily modeled with a y=mx+b equation. They used the slope of that equation (a/v squared) and divided it by 1/2 * rho *A/m to obtain a good approximation of their rocket's Cd. Dan Moses has a Ph.D. and works for NASA so their work has some degree of credibility.
 
I'm new to this forum so my reply is probably out dated. You referenced the Apogee newsletter above. Did you see a response in newsletter #315 from Dan Moses? He was a mentor for a group of high school students from Falls Church, VA. that submitted a project for the NASA Student Launch Initiative (SLI). The kids used acceleration data and velocity data during the coast phase of their rocket's launch to arrive at a Cd. They plotted acceleration on the y-axis and velocity squared on the x-axis and this resulted in a straight line which could be easily modeled with a y=mx+b equation. They used the slope of that equation (a/v squared) and divided it by 1/2 * rho *A/m to obtain a good approximation of their rocket's Cd. Dan Moses has a Ph.D. and works for NASA so their work has some degree of credibility.

That's pretty slick. Thanks for sharing.

I haven't done much with this in many months, but I also want to compute rho as a function of altitude (non-standard day conditions) and eventually plot Cd vs Mach. The accel data from the altimeter is pretty noisy, so smoothing/fitting is needed to get started.
 
Curious about how and where you are going to get your data for plotting Cd vs. Mach It sounds interesting.
 
A very good question! Also, how accurate are the accelerometers? As previously posted, what are you trying to do with the data? Is "close" good enough?

To quote my materials professor in college, engineering is the science of good enough. I'd be pretty happy with +/- 0.05 on my Cd, but I'm not a high performance flier. I suspect that anyone that really needs precision is willing to pay for a wind tunnel and/or CFD.
 
I'd be happy with +/- 0.05 on my Cd any day too. I was just wondering how he was going to get Mach data since even HPR is sub sonic unless your into sounding rockets.
 
I'd be happy with +/- 0.05 on my Cd any day too. I was just wondering how he was going to get Mach data since even HPR is sub sonic unless your into sounding rockets.
There's plenty of MPR that can break m1; CTI's g65 is a prime example.
 
I'd be happy with +/- 0.05 on my Cd any day too. I was just wondering how he was going to get Mach data since even HPR is sub sonic unless your into sounding rockets.

Mach number means velocity in a non-dimensional form. I want to back out Cd vs. Mach number, which is the proper way to characterize rocket drag. Many HPR rockets exceed Mach=1, if that is what you mean.

I just want to prove to myself that I can crunch the numbers, account for all variables correctly, and produce a curve that "looks" correct. I have no illusions that it is the "correct" answer, as measured flight data is very squirrely and does not follow nice assumptions. The raw data (say from a Raven) is very noisy and requires data fitting/smoothing in order to perform calculations upon. This is the first hurdle and is an area of numerical methods that I am not very familiar with.
 
Last edited:
I was just wondering how he was going to get Mach data since even HPR is sub sonic unless your into sounding rockets.

"MPR means subsonic" is a common misconception, up there with "tubefins can't break mach".
This doesn't really describe a solution. It is like saying "Sunoco 97 octane gasoline goes 150 mph." :rolleyes:
As minimum drag shapes are rather robustly attested both in theory and actual practice, pointing out a single example rather does dispel the common myth.

I did not say "white propellant breaks mach" :)
 
Mach number means velocity in a non-dimensional form. I want to back out Cd vs. Mach number, which is the proper way to characterize rocket drag. Many HPR rockets exceed Mach=1, if that is what you mean.

I just want to prove to myself that I can crunch the numbers, account for all variables correctly, and produce a curve that "looks" correct. I have no illusions that it is the "correct" answer, as measured flight data is very squirrely and does not follow nice assumptions. The raw data (say from a Raven) is very noisy and requires data fitting/smoothing in order to perform calculations upon. This is the first hurdle and is an area of numerical methods that I am not very familiar with.

That would be great, I've wanted to do this for some time but never worked through all the steps...
 
FWIW, You can find the formulas for CD rendering in my 2007 NARAM R&D Report, _Analyzing Accelerometer Data from Off Vertical Trajectories_. I have a VBA Excel spreadsheet somewhere that does it.
 
I am not an expert on this but have just enough knowledge to be dangerous. I would recommend that you not use altitude to derive velocity or for that matter the velocity that your Raven may record. Both can lag or lead due to Bernoulli and Ram effects as well as inadequate venting. Bear with me if you already know this. Your best source of data is from the accelerometers and on the Raven 3 they sample at a very high rate 200 Hz to 400Hz depending on lateral or axial measurements. I believe 400 Hz is 400 samples per sec. By comparison the Altimeter 3 samples at 244 samples per second (which is adequate for science fair projects and the like) You may try using the root mean square method to crunch this boat load of data. In other words square each value that you get every second, add up the squares and divide by 400 and then take the square root of that. But I am not a statistics expert and others who are may disagree or have a better strategy.The RMS method is used by EE's to calculate alternating current voltage from the sine wave. In any case the work sounds interesting and good luck.
 
I would be interested in your formulas also. Are they in the Technical Review Volume 25 (price $18 plus shipping)? Thanks for the comment
 
I am not an expert on this but have just enough knowledge to be dangerous. I would recommend that you not use altitude to derive velocity or for that matter the velocity that your Raven may record. Both can lag or lead due to Bernoulli and Ram effects as well as inadequate venting. Bear with me if you already know this. Your best source of data is from the accelerometers and on the Raven 3 they sample at a very high rate 200 Hz to 400Hz depending on lateral or axial measurements. I believe 400 Hz is 400 samples per sec. By comparison the Altimeter 3 samples at 244 samples per second (which is adequate for science fair projects and the like) You may try using the root mean square method to crunch this boat load of data. In other words square each value that you get every second, add up the squares and divide by 400 and then take the square root of that. But I am not a statistics expert and others who are may disagree or have a better strategy.The RMS method is used by EE's to calculate alternating current voltage from the sine wave. In any case the work sounds interesting and good luck.

In my experience, sampling rate is not a problem. The error in Cd from altitude mismeasurement is rather low (even though Cd, as a rule, is very sensitive to any sort measurement of error) because density misestimates from this source are typically small.

That said, I'm afraid I cannot endorse Raven accelerometer data in general for anything except... entertainment and a few qualitative applications.
 
FWIW, You can find the formulas for CD rendering in my 2007 NARAM R&D Report, _Analyzing Accelerometer Data from Off Vertical Trajectories_. I have a VBA Excel spreadsheet somewhere that does it.

Interested in how accurate you believe your derived data was.
 
That said, I'm afraid I cannot endorse Raven accelerometer data in general for anything except... entertainment and a few qualitative applications.

Wow. Well, what do you recommend? Is there a hobby accel altimeter out there suitable for flight analysis? I already tried a MARSA 54LHD and found the data export lacking. The Raven data export looks great, but the accel itself was wacked and needed replacement. So, no data yet (Hmm, maybe I am catching your drift!). What is left - AIMExtra, AltusMetrum?

I learned that accel-based deployment generally sucks, so all I need the accel to do is record data. Eh, or just give up on this folly and use simulations (models, CFD, wind tunnel) for Cd and trajectory analysis. The sims are better anyway.
 
Raven data were yielding inertial altitudes smaller than barometric altitudes on hot days. All of the normal sources of analytical error would have the opposite effect. The manufacturer attributed the problem to nonlinear response, and asserted that all hobby units would have similar problems, but I did not observe comparable problems with the old ARTS or RDAS units. (This is just my own observation and opinion. YMMV)

I'm out of the game now. I contacted Altus Metrum years ago, and they said, at that time, that their product was a package, and that it was not designed to give data for external analysis. That may have changed. (If you read my 2007 and 2011 R&D reports, you'll see that I analyze things differently.) For that reason, never tried them. Lost interest in rockets because of these issues.

-LarryC
 
Larry,
I understand your frustration with commercial electronics. But, the way I look at it my Altimeter 3 is that it is good enough for my experiments. What does it matter whether your within only 1 or 2 sigma in the grand scheme ? It's the journey to the answer that is fun. If I wanted to be 3 sigma I would have gotten my degree in aeronautical engineering instead of chemistry and worked for Space X or NASA.

Hang in there............
 
I just purchased the CD. It had better be all there. I can share the info.
 
I learned that accel-based deployment generally sucks,


It is only bad in some circumstances.

The first is if it is implemented badly. It isn't difficult to do right and I still use a 1999 vintage AltAcc2. (That uses the PIC16C71 with an 8 bit ADC!) The RDAS Compact also does very well and I suspect the more recent RDAS Tiny. The Tiny has much less noise in the data as well.

Assuming that the altimeter is working well, then the only other problem is flight profiles that mess with the one big assumption at the heart of the algorithm: measured acceleration is lined up with gravity.

This doesn't happen often. Flight 3 of my PAC3 being about the only time for me.
 
then the only other problem is flight profiles that mess with the one big assumption at the heart of the algorithm: measured acceleration is lined up with gravity.

Altimeter makers are not FORCED to make that assumption, but many (but not all :wink:) do. In fact it can be shown that the probability of a flight adhering to the -1g gravity offset assumption approaches 0.
 
Is there any way someone can find out whether the accelerometer you have adheres to that assumption? That is, can you run a test to see if it adheres to the minus 1G? Would launching with 2 or 3 devices and comparing results on several flights be worth while?Has anyone in this forum tried that ?
 
For those who are interested, I found a decent source from NXP on calibrating 3 axis accelerometers. Some of the points they make are :

Three-axis accelerometers supplied for the consumer market are typically calibrated by the sensor manufacturer using a six-element linear model comprising a gain and offset in each of the three axes. This factory calibration will change slightly as a result of the thermal stresses during soldering of the accelerometer to the circuit board. Additional small errors, external to the accelerometer, including rotation of the accelerometer package relative to the circuit board and misalignment of the circuit board to the final product, will also be introduced during the soldering and final assembly process.


The original factory accelerometer calibration will still be adequate for the vast majority of consumer applications. Manufacturers of premium products looking to obtain improved accuracy from a consumer accelerometer may, however, wish to perform their own calibration either by repeating the calibration performed by the accelerometer manufacturer or by using a more sophisticated calibration mode

*
The apparent gravitational acceleration on the earth's surface varies by 0.7% from minimum to maximum. The apparent gravitational acceleration at the recalibration site is irrelevant if the product is to be used to provide orientation angle estimates from ratios of accelerometer channel readings but should be known if the product is required to provide high-accuracy acceleration or gravitational measurements.


•The original six parameter (gain and offset in each channel) factory calibration can be recomputed

to correct for thermal stresses introduced in the soldering process.


* A 12 parameter linear calibration model can correct for accelerometer package rotation on the circuit board and for cross-axis interference between the accelerometer’s x, y and z channels.

• The orientation angles used for the recalibration must be carefully selected to provide the best calibration accuracy from the limited number of measurement orientations available. Optimum orientation angles for a given number of measurements are listed.


•Linear least squares optimization is an efficient mathematical technique to compute the

recalibration parameters from the available measurements using simple matrix algebra. Worked
examples are provided throughout the text.


•These techniques can be extended to include temperature dependence by performing the recalibration at two or more temperatures and interpolating the fitted calibration parameters to the actual temperature.
​
Accelerometers are used in applications requiring either absolute or relative acceleration measurements.
Examples of absolute acceleration measurements are determining the earth's gravitational field or the acceleration forces experienced in an automobile in units of ms-2 An example of using relative accelerations is the calculation of orientation angles using ratios of the readings from the x, yand zaccelerometer channels.

Although what follows may seem an obscure point, it does need to be briefly discussed since the objective of this application note is high-precision calibration. Although the earth's gravitational field is often stated to be 9.81ms-2, in practice the apparent gravitational field measured by an accelerometer varies by 0.7% from minimum to maximum over the earth's surface as a consequence of the earth's rotation, the earth's equatorial bulge and the effects of altitude. The apparent gravitational field at sea level at the north pole is 9.832 ms-2 but is only 9.763 ms-2
at the 5895 m summit of Mount Kilimanjaro located almost on the equator.

This document assumes that the accelerometer recalibration is being undertaken for high-precision calculation of roll and pitch orientation angles from the ratios of accelerometer channel readings. In this case the precise apparent gravitational field at the recalibration site cancels in the mathematics and is simply assumed to be '1g'.


If, however, the recalibration is being performed to produce an absolute estimate of gravity or linear acceleration in units of ms-2 then the apparent gravitational field at the recalibration site must be known and stored on the product for a simple final multiplication from '1g' to the required gravity or acceleration estimate measured in m s-2


The rest of the paper explains how to recalibrate the accelerometer using trig and matrix algebra as well as using least squares to average out the results, which is beyond the scope of 99.9 % of model rocketeers including yours truly.
 
For those who are interested, I found a decent source from NXP on calibrating 3 axis accelerometers.

Completely beside the point. What is needed is a measurement of the rockets orientation. That requires a 3 axis gyro.
 
Back
Top