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.
A couple of thoughts (Bobk99 and I have also been corresponding via email, which is always the best way to reach me, since there are many threads on here I miss seeing like this until now).

1. Yeah, don't differentiate barometric data during the boost phase. That is such a noisy environment for pressure data, especially in terms of rate change. At high speed, the dynamics of air leaving the fuselage and the flow over and around the rocket are quite noisy. I have seen many setups where the altitude DIPS during boost (from ram effects) or peaks (from Bernoulli suction). Imagine differentiating that kind of data and coming up with a negative number when you expected a positive one. At slow speeds and apogee, all of that calms down.

2. I think it's very reasonable from an engineering standpoint to integrate accelerometer data at the end of boost phase to derive Cd, and I think any altimeter (including Ravens) can do a fine job of measuring that straight line acceleration. As I mentioned to Bobk99, if you want to be more rigorous you can always launch vertically and throw out obviously arcing flights. It would also help to launch on calm days and/or avoid overly-stable rocket designs to avoid cosine(flight angle) errors.

By the way, the Jolly Logic AltimeterThree in rocket mode samples at 200 S/s, and then losslessly bins it down to 20 S/s to save storage and display resources. So if you integrate the 20 S/s data, it's numerically equivalent to integrating the original 200 S/s samples (although you did lose the frequency info, but who cares about that).
 
2. if you want to be more rigorous you can always launch vertically and throw out obviously arcing flights. It would also help to launch on calm days and/or avoid overly-stable rocket designs to avoid cosine(flight angle) errors.

If you have a visual on the flight and can guestimate the off vertical orientation of the flight you can take the original acceleration data, add [1 -cos(theta)] to the data and reintegrate.
 
Okay but ...........

"MEMS gyros are imperfect devices, exhibiting sensitivity to acceleration and vibration. Since they are under a one-g force from gravity in Earth-bound applications, tilting or moving a gyro can induce errors. Some designers compensate for these using measurements from an accelerometer, but vibration can swamp out such corrections. In applications where absolute rotation information is important (as opposed to relative), calibration may be necessary."

This comes from A Designer's Guide to MEMS Sensors by Jack Gansslle

The bottom line, IMO, is that if you are not satisfied with making some concessions with precision and accuracy using commercially available accelerometers or for that matter with gyros than look for a way to get your rocket tested in a wind tunnel that provides consistent laminar flow or purchase an expensive CFD program that can model your rocket.
 
Just offering my $0.02 here, and that is all really. Last year I was working with an aircraft design that I originally did for a college
design project in the early 1980's. What I'm describing here is a zero-cost method to obtain Cd using available CFD, meshing, and
design programs that are all open source/free.

I'm attaching a screenshot from last year, showing my design (a three-surface aircraft) in a volumetric element field. The process is
complex, and I spent many hours on very steep learning curve programs. Here is a set of steps I took, and I got a good array of
numerical coefficients. Aircraft are subject to the same forces as a rocket.

1. I created an initial mesh using a variety of tools. The one most used was Blender. CFD uses an "aero shell", so the shape can
be defined by a STL type file, the same as used in most 3D printing. One must make a contiguous, seamless shell of what they
wish to put in the virtual wind tunnel. The mesh must be manifold, and without error. In general, if it is OK for 3D printing, it
will be OK for SU2 (described later) CFD analysis.

2. The contiguous, manifold aero-shell is then imported into a program called "Graphite". This splits the surface of the aero-shell
into triangular elements. In most cases on my aircraft, I used 20,000 to 30,000 elements. There are many controls for creating
this surface mesh, and I won't go into all of them here. I also used "MeshLab" to correct or manipulate certain items that Graphite
could not handle easily. Again, all these programs are free and open-source.

3. The meshed aero-shell is then imported into GMESH, where I created the fluid cell. This is the first screen shot. Basically this is
where you define the finite element field over the object you wish to analyze. The blue represents the surface mesh, and red elements
are mostly tetrahedral volume elements. This is the definition of the 3D finite element system that will eventually be imported into SU2.
There are strict rules for creating the .SU2 file for boundaries. Inlet, outlet, inviscid walls, and the like. This is the mathematical
equivalent of putting your model into a wind tunnel chamber.

4. Now, onto the main analysis. SU2 (Stanford University 2) is a CFD program, again free and open-source, that is tailored more for
aerodynamics rather than liquids. I gave up on trying to use this program in Windows, and dedicated a 4-core i5 system running Linux
Ubuntu to doing these runs. SU2 can be configured to use multiple cores to speed the processing. One defines the airspeed, angle-of-attack,
temperature, air pressure, density, and about 20 to 50 more variables. You can choose Euler analysis and Reynolds Averaged Navier-Stokes (RANS)
from a few different methods. I mostly used Euler in the early stages, and then went to RANS to get skin friction more accurately modeled.
This program is quite complex, and took me weeks to get even to the simplest run. But it works. Iterations with 30,000 skin elements and
about a million volume elements took about 3 to 5 seconds per iteration on my i5 system using all 4 cores. Most of the time solutions of the equations would converge in 200 to 300 iterations, if I used a low angle of attack. A lot of this depends on how well you do your work in the previous steps. Cd
is among the coefficients output, along with normal forces on all axes. Moments on all axes are output as well.

5. Once the program has completed one run solution, you can visualize it using a program called Paraview. I will attach another screenshot from
that program. Again, this program took me weeks to get even a basic output from. You can map temperature, pressure, velocity or a host of
other parameters from your SU2 output files. This particular example was using element outputs to map streamlines around the aircraft, which is
quite impressive.

There is a online forum group called CFD online if you wish to explore these possibilities further. There is a special section just for SU2 users.
The cost of all the above from a software standpoint was zero. I just post all this to describe what I did. My ultimate goal was to create an
aircraft model for a flight simulator, that was somewhat accurate. The CFD analysis was just one aspect of that project. I have put all
that on hold, while I pursue my Level 1 certification.

Please refrain from questions about the details of the above process. If one wants to learn CFD, then it is best to start with online searches
regarding that subject. I only wanted to show what is possible using freely available software.

20KR Screen (Large).jpgStream1 (Medium).jpg
 
Thank you ecarson for sharing your work with us. I can't speak for the other model rocket enthusiasts but I am impressed with your work! I agree that aircraft share some of the same forces but I believe there are also some differences. The Cd on rockets is governed by shock waves (supersonic),body pressure drag, skin friction drag,parasitic drag due to launch lugs, fin to body interference drag,,and base drag( low pressure created at base of rocket due to rapid diminishing of body's radius) But the creation of the mesh would,I believe, be the same or even easier with rockets. Thanks again for your "two cents"
 
Thank you ecarson for sharing your work with us. I can't speak for the other model rocket enthusiasts but I am impressed with your work! I agree that aircraft share some of the same forces but I believe there are also some differences. The Cd on rockets is governed by shock waves (supersonic),body pressure drag, skin friction drag,parasitic drag due to launch lugs, fin to body interference drag,,and base drag( low pressure created at base of rocket due to rapid diminishing of body's radius) But the creation of the mesh would,I believe, be the same or even easier with rockets. Thanks again for your "two cents"
+1, I'm going to attempt this for a simple 3fnc next time I have some bandwidth. Been wanting to take another stab.
 
VulcaniteSmooth.jpg

FWIW, this is Cd from a subsonic flight of a LOC Vulcanite along with the DATCOM prediction. The instrument as an ARTSII. These results are pretty typical: Poor correspondence at low speeds and good correspondence in the plateau. It's fair to say that both measurement and prediction are poorest at low speeds.

Measurement is poor there because the low speeds are encountered near the top of the trajectory, where the rocket veers most from vertical. Therefore, the rendered speeds are apt to be lower than the actual speeds - making the rendered Cd artificially high.

DATCOM Cd is empirically low at low speeds - because simulations of low-speed flights with DATCOM Cd's tend to over-predict altitude.
 
Thanks Larry, interesting graph.There is lots of pertinent information in this report.

Bob
 
Back
Top