Measuring Engine Performance DURING Actual Flight

I have been making some test flights that I thought might be of interest to others on this forum.
I am flying a BigDaddy that I modified to allow me to place an Ardiuno Uno and a 9V battery inside
the nose cone. On some of these flights I have connected a 3-axis accelerometer and/or a barometric
altimeter. Using the data from these flights, I have been able to measure the thrust-vs-time curve
for the motor and the length of the delay charge. Here's a thread to show how I did it - perhaps
others have either been working on these same activities, or perhaps it will prompt others to try.

There are lots of great ready-made altimeters and dataloggers out there available for sale.
My goal was not to try to make a *better* one, just to see if I could make a *working* one myself.

I chose the Arduino because the boards are small and fairly inexpensive (see pricing in attached photo)
and because there is lots of online help available on how to set them up and program them.

An Arduino UNO fits easily inside the nose cone of a BigDaddy rocket.

The Arduino is just a very small computer - albeit one without a screen, keyboard or mouse.
It knows how to measure voltages and take in other types of input, such as lines of text from a GPS module.
There are lots of sensors, including accelerometers and altimeters which send out a voltage that can be read by the Arduino.
The Arduino knows how to save the information to its internal memory so that you can retrieve it later.
It can also be taught how to send the information it reads out via a small radio transmitter.
You have to write the program yourself, using a language very much like "C". The programs
are usually very short - often 10-20 lines of programming is all that is required.

An accelerometer measures, obviously, the acceleration experienced by the rocket.
I used a three axis accelerometer - which measures the acceleration in the "UP" direction
as well as in the North/South and the East/West directions. Since the motor is only pushing
in the "UP" direction, I was interested in the measurements taken in that direction.

In this flight I used an Estes E9-4 motor. Like many motors, this one has a large initial peak thurst
followed by a period of relatively constant thrust before it burns out. As many are aware, you can
go to websites such as thrustcurves.org to see a graph of the thrust curve. Usually these curves
are made by firing a motor while it is attached to a force sensor (aka a "scale") and recording the data
during the burn.

An Accelerometer is NOT the same thing as a force sensor - BUT - the equation F=m * a
(force = mass x acceleration) tells you that if you know the mass 'm' of your rocket and you measure
the acceleration 'a' of your rocket you can calculate the force that the motor was producing.
That is what I did in my tests. The attached graph shows some acceleration data that I collected
during one flight. The second figure shows the measured thrust data from thurstcurve.org for an E9-4
motor. It also shows how I used the peak acceleration that I measured in the rocket to calculate the
peak thrust of the motor. I didn't get exactly the same result as thrustcurve.org, but I did get pretty close.

The peak acceleration measured by the Arduino was 62.45 m/s^2
The telemetry data shown in the attached graph includes some averaging that my program performed
to try to "smooth" out the data. The peak in the graph is about 5.4 "G's". Since 1G = 9.81 m/s^2
the peak graph value would be around 53 m/s^2
Using the equation and measured rocket mass on the second figure I calculated a peak thrust of around 18-21 N
for the E9-4 motor. The value from thurstcurve.org was 19.47 N.


Note that I am taking a bit of a short cut in this math because the rocket mass 'm' isn't really a constant
during the flight. As the motor burns, it gets a little bit lighter. Since this mass change is small compared to
the rocket mass and because the peak thrust occurs at the beginning, before much mass has burned, this short
cut shouldn't change my results very much.

Notice that if you look at the shape of the acceleration graph that the shape looks similar to the thurst curve shown
on the second figure. The accelerometer is actually "measuring" the thurst curve as the rocket it flying through the air (!)

The other interesting thing to see is in the first figure, I show the PREDICTED vertical acceleration and PREDICTED altitude
from OpenRocket for my BigDaddy flight compared to the ACTUAL data. The agreement is amazingly (my opinion) good.
I think lots of people are used to comparing their predicted altitude data to measured altitude data, but most people don't
think to do the same with acceleration data.

I think many people are familiar with the term "bonus delay" - which is something you feel in your
stomach when you see your rocket arch over and start to head "down" for a long time before the parachute finally deploys.
Somehow that delay ALWAYS seems to be longer than you think it is going to be.

Using my Arduino I was above to directly measure the length of the delay charge - IN FLIGHT.
Here's how I did it:

In addition to the accelerometer I added a barometric pressure sensor to my Arduino.

The attached graph shows a plot of the measured data during this flight (this is a different flight than the one
earlier in this thread, but it was also on a BigDaddy and also used an Estes E9-4 motor).

You can see in the graph that the acceleration drops off to zero at 3.60 seconds after launch.
In fact, what you see is that the "acceleration" of the rocket actually goes slightly negative at that point...
what you are seeing is actually a direct measurement of the drag on the rocket - the air is slowing down
ie de-accelerating the rocket. [I am currently using that data from the de-acceleration and comparing it to the
predicted de-acceleration of the rocket in the OpenRocket simulation and using that comparison to study
what the best Cd (drag coefficients) to use in the simulation]

Anyway, you can see from the barometric altimeter data a small blip just after apogee, at 7.66 seconds into the flight.
That blip, as many people are aware, is the ejection charge deploying the parachute.

The engine delay is the time from engine burnout until ejection charge, or in my case 7.66 - 3.60 = 4.06 seconds.
Which is pretty darn close to the "4" seconds you should get from an Estes E9-4. Seems like I really am not getting
much "bonus" after all.

I think there are two other interesting things to observe in the graph from the previous post - but both of those things are NOT related to measuring the engine performance during flight.

1) The graphs shows the reported altitude coming from my GPS module during flight. The data roughly tracks the altitude reported by the barometric altimeter for most of the "up" part of the flight.
Interestingly, however, the GPS altitude then reports that the rocket mysteriously remains way up there for the entire remainder of the flight (even after the rocket hits the ground). I am still investigating this
phenomenon. GPS altitude data is known to be much less accurate than "horizontal" GPS data, but I have not previously seen this type of error before (has anyone else?)

2) The graph also shows a calculated altitude vs time of my rocket based only on the accelerometer data. This is pretty interesting (at least to me). Here's a description of how I did that....

It you have a table of measured acceleration vs time, for example:

TIME ACCELERATION
0 sec 0 m/s^2
1 sec 2 m/s^2
2 sec 5 m/s^2
3 sec 6 m/s^2

You know that at time=0, the velocity and the height of the rocket are 0 m/s and 0 m
At time = 1 second, you are now at 2 m/s^2 and your average acceleration during that first second was (0+2)/2 = 1 m/s^2
So for 1 second, you accelerated at 1 m/s^2 which means that v=a x t so at 1 second, you are now traveling 1 m/s and your average velocity during that second was (0+1)/2 = 0.5 m/s
So for 1 second you travelled at 0.5 m/s which means that h = v x t so at 1 second, you are now 0.5 meter in the air.

During the next second, your average acceleration is 3.5 m/s^2 and your new velocity is 1 m/s + 3.5 m/s^2 x 1s = 4.5 m/s and you are now at a height of 0.5 m/s + (1 m/s + 4.5m/s)/2 x 1s = 3.25 meter

I did these steps using the accelerometer data (which was in MUCH smaller time increments than 1 second, but the math works the same way)

The cool result is that you can calculate your altitude from the acceleration data - AND it matches the measured altimeter data reasonably closely. This measurement does
not depend on knowing the sea level static pressure, or getting the correct pressure port size and location in your rocket. It does NOT, however, work for computing
altitude on the way down because after ejection, the accelerations in all three axes are all over the map as shown by the graph.

Very nice start Kerry!

One fine tune to your model is to incorporate the Cd which you can calculate from the deceleration after motor burnout to calculate the drag force on rocket during the motor burn. Then you can get a better thrust curve estimation by applying {T - Drag} = ma, where T is the motor thrust. The peak thrust of the motor may be when the peak acceleration occurs, especially with a motor that may have a little progressivity during its burn.

Neat analysis. I've been looking at some of the same ideas albeit without thinking about it as deeply and without GPS by looking at data from the AltimeterThree. Here are screen caps of data from a flight of my beater Estes Eliminator (modded so that the top few inches are payload section) flown on an E12-6. The first is the whole graph showing barometric altitude and acceleration in the axis of the rocket and the second is turned the other way and zoomed up on the salient part of the acceleration curve. No bonus delay here either. In fact it was just about dead on.




added: Hmmmmm.....those graphs shouldn't say "total acceleration" on the right Y axis. Time for another application bug report to Jolly Logic I guess.

As another interesting question, could you use your data to also compute the proper Cd of different parachute sizes and forms, and thereby adjust the inputs to RockSim/OpenRocket?

I've often wondered about the assumption of .75 for a flat sheet and 1.5 for a hemisphere/elliptical and if it meets with real world test data.

I'm gonna have to invest in logging electronics!

KerryQuinn said:

The attached graph shows a plot of the measured data during this flight (this is a different flight than the one earlier in this thread, but it was also on a BigDaddy and also used an Estes E9-4 motor).

Click to expand...

Hi Kerry,

This is great stuff. I too have been playing with arduino-based data logging for a couple of years now, but I've never thought to look at validating the thrust curve of the motor or refine the Cd figure in OR with the data.

I notice the sample rate in your graph runs at 8.8 samples per sec - it that by design or is it a case of "that's just what it came to be"? When I did my logger (using in a Pro Micro, inspired by Leo) I found a way to use one of the internal timers to gate my loop time at exactly 10Hz. There's two schools of thought here, the one being that "I want as much data as I can get, let the loop run as fast as it can", or "a consistent predictable sample rate is more important to me then an extra data point here and there". The down-side to the second is obvious - you're not getting quite as much data as you could get. The down side to the first is every time you change your programme the loop time will change and depending on the nature of your sensors you could also see minor variations in timing from loop to loop. I opted for the second school of thought with my logger so I'd always know precisely what the sample rate was, which is really important when you start integrating data. (Okay, I admit it, the OCD-part of me also likes a nice round sample rate. )

If you see value in gating your code to tweak the sample rate I'd be happy to dig out what I did. Either way, good show!

jderimig said:

One fine tune to your model is to incorporate the Cd which you can calculate from the deceleration after motor burnout to calculate the drag force on rocket during the motor burn. Then you can get a better thrust curve estimation by applying {T - Drag} = ma

Click to expand...

Good point. I will work on doing that.

I think I can already place an estimate on the magnitude of the error correction this will make:
If I assume that the largest factor influencing the drag is the velocity (and not the effect of changing air density with altitude),
then you know that the highest velocity is going to happen at the point where the engine cuts out. If you look at the plot, you see at that point that the acceleration
drops from +2G to about -0.4G. That means that, without the drag, the acceleration would have been +2.4G just before the engine cut out.
Right at launch at right at apogee the velocity is 0, so the draq would be zero. That means that the error in the force value from not including drag in my calculation goes from 0% at launch,
to about 20% at engine cut out and back to 0% at apogee.

BEC -
If I estimate that your Eliminator was around 250g, and I observe from your plot that the peak acceleration was around 12G as measured by your accelerometer,
I get the following....

peak acceleration = 12 x 9.81 m/s^2 = 118 m/s^2

mass = 250g = 0.250 kg

F = m a

so, peak force from engine = 0.25 kg x 118 m/s^2 = 29.5 N

Thrust curve.org says the peak force for the E12-6 is around 32 N .... not too far off and, as mentioned by John above, if the drag force
was around 2.5N at the time of peak motor force, then you would have...

Net Force on Rocket = 32N - 2.5N = 29.5N which is exactly what you measured.....

Physics rocks!

Banzai88 said:

As another interesting question, could you use your data to also compute the proper Cd of different parachute sizes and forms, and thereby adjust the inputs to RockSim/OpenRocket?

I've often wondered about the assumption of .75 for a flat sheet and 1.5 for a hemisphere/elliptical and if it meets with real world test data.

Click to expand...

Tom,
I think that calculating the Cd for the chute is actually much easier to do than calculating the Cd of the rocket during the "UP" portion of flight - and you don't need to invest in anything other than a stop-watch and your good old barometric based standard altimeter, even just an altimeter that records the peak altitude like those with "blinky light output". In fact, I don't see how to calculate the Cd WITH my accelerometer. Here's why:

If you look at my accelerometer data during the descent portion, you will see that it measures -1.0G during the entire descent. That is (I think) because the rocket is descending at a constant rate - which is also why the barometric altimeter data during descent is a straight line with a constant negative slope. That's because the chute has reached its terminal velocity. Since the descent rate is constant, that means that it is not accelerating or decelerating, so
the acceleration is zero and the only thing acting on the rocket is the force of gravity, which is.... 1.0G In my case, the -1.0G comes from the fact that the parachute was tied to the base of my nose cone, and the accelerometer was inside the nose cone, so, during descent, the accelerometer was "upside down" so it is measuring just gravity that whole time.

If you want to measure the Cd, I think all you need is to know the descent velocity. An easy way to get that is to know the peak altitude and the time it takes to get from apogee back to the ground.
To get that all you'd need at a peak-recording altimeter and a stop watch.

If I look at Bernard's data for his Eliminator, I see that his rocket came down from 1347ft in 150 seconds...

1347 ft / 150 sec = 410 m / 150 sec = 2.73 m/s

The drag coefficient for a parachute is in this equation...

D = Cd x A x r x V^2 / 2
which came from here.... https://www.grc.nasa.gov/WWW/k-12/VirtualAero/BottleRocket/airplane/rktvrecv.html

D=drag force
r = air density = 1.229 kg/m^3
V = descent velocity = 2.73 m/s
A = parachute area

I don't know Bernard's parachute size,but I'll guess that it was around 24" diameter. If that's right, then
A = 12^2 x 3.14159 = 0.3 m^2

I don't know the drag force of his chute, but I know that it was equal and opposite to the weight of his rocket which I previously
estimated was 250g x 9.81 m/s^2 = 2.45 N

so, D=2.45 N

If I solve the equation for Cd


Cd = 2 x D / [A x r x V^2 ]

Cd = 2 x 2.45 / [ 0.3 x 1.229 x 2.73 x 2.73 ] = 1.76

Which is "in the ballpark"...

-Kerry

KerryQuinn said:

Good point. I will work on doing that.
Right at launch at right at apogee the velocity is 0, so the draq would be zero. That means that the error in the force value from not including drag in my calculation goes from 0% at launch,
to about 20% at engine cut out and back to 0% at apogee.

Click to expand...

Correct. Once you have the Cd value you can calculate the Drag force through out the motor burn by intergrating the acceleration to obtain the speed of the rocket at anypoint in time and then calcuate the drag. Now you can calculate the thrust at any point in time.

KerryQuinn said:

BEC -
If I estimate that your Eliminator was around 250g, and I observe from your plot that the peak acceleration was around 12G as measured by your accelerometer,
I get the following....

peak acceleration = 12 x 9.81 m/s^2 = 118 m/s^2

mass = 250g = 0.250 kg

F = m a

so, peak force from engine = 0.25 kg x 118 m/s^2 = 29.5 N

Thrust curve.org says the peak force for the E12-6 is around 32 N .... not too far off and, as mentioned by John above, if the drag force
was around 2.5N at the time of peak motor force, then you would have...

Net Force on Rocket = 32N - 2.5N = 29.5N which is exactly what you measured.....

Physics rocks!

Click to expand...

Great analysis. I just put the Eliminator, an E12-6 and the AltimeterThree on one of my gram scales. 199.2g. Need to add a couple of grams for wadding to get the liftoff mass. From the Excel spreadsheet for that flight the AltimeterThree app produces when asked, the peak acceleration is 11.82gs recorded at 0.20 seconds after T0 - at an altitude of 5 feet (!!).

Not bad at all......

Kevin -
Great question. As you mention, sampling rate can be very important in helping to collect and successfully analyze data.
The Arduino and most microcontrollers out there can sample data amazingly fast - far far above the measly 8-9 samples/second I am using.
The problem as I know you are aware, comes down to "what can I do with / where am I going to put all this lovely data?"

While they are fast, the amount of memory available on Arduinos is very small - and you could easily collect enough data in 1 second to completely fill the memory of the entire Arduino if wanted to.

In my flying, I have come up with 4 solutions...
a) save the data to the Arduino's memory and put up with only collected a tiny bit and/or collecting the data very slowly.
b) use a radio to send all the data to a PC on the ground as soon as you collect it so you don't have to worry about storing it.
c) add a storage device, in my case a micro-SD card (same as used in electronic cameras) to the Arduino so you can save multiple gigabytes of data in a flight
d) add a flash memory chip to the ardiuno to expand it's internal memory

I gave up on using method 'a' early on since I could only collect a tiny amount, about 2-3 kb of data in the Arduino Uno.
I used method 'b' to collect data for the plot in my post #2 of this thread. In that case, the sample rate was set by how fast I could send the data via the radio, not by how fast I could collect the data.
I used method 'c' to collect data for the plot in my post #3 of this thread. Here the sample rate was limited by how fast I could write the data to the SD-card.

I am pretty sure I could speed up my code for methods 'b' and 'c' if I needed to, by compressing it a bit and sending in "blocks" instead of single pieces.
So far though, I think that 8 samples/second is probably good enough for the types of things I am monitoring. In fact, devices like my GPS can't give me new
data any faster than 1 time per second.
If I needed to go really fast, I'd use method 'd'.

I have noticed that the processing speed of the Arduino is not entirely constat - I am sure there are reasons for that, and using a clock-driven trigger, such as you suggest, would be a way to get around that.
My approach was simpler (I think). Each time I take a measurement, I ask the microprocessor "how many milliseconds has it been since you started running the program?" and then I save that "timestamp"
with each value I collect. That way, after the flight, I can compute the exact time interval between data points. They are not exactly even, but that's ok, as long as you know the exact time between them.
I correct for the varying intervals in the math.

John-

Its probably an even smaller contributor, but I think I can even improve the calc a bit more, but I'd be making an assumption about motor propellant and how it burns during the flight - something that I know next to nothing about.
The issue I am thinking of is the change in rocket mass as the motor burns. I would then have an equation like:

Thrust - Drag = m(t) x a

The problem is that I do not know the rate of change of mass of the propellant during the burn.

My simple-minded approach is this:
1) I can measure the mass of the motor before flight and after flight to get the total mass lost.
2) I make some sort of wild-guess that the mass of the ejection charge plus ejection "cap" is only 5% of the total mass lost (for a D or E sized motor. It's probably a larger percent for an A motor)
3) Since thrust is related to accelerating mass out the back end of the rocket, I could assume that the "area under the thrust curve" between ignition and a time 't' is proportional to the amount of propellant that has been
lost up to that point.

Using that approach I could predict the decaying mass of the rocket m(t) over time.

I think that would at least be approximately correct.

Oh - I didn't scroll up to the bit about the parachutes - its an 18-incher with a 5 inch spill hole. I also usually fly it reefed so that it can only open to about 12-14 inches in diameter. I don't recall if I had it reefed that much on the day of that particular flight, but I probably did.

Kerry, simply use a linearly decreasing mass for you model. The changing mass effect is small compared to the other assumptions like constant cd, so use a simple modelb for the mass effect.

KerryQuinn said:

John-

Its probably an even smaller contributor, but I think I can even improve the calc a bit more, but I'd be making an assumption about motor propellant and how it burns during the flight - something that I know next to nothing about.
The issue I am thinking of is the change in rocket mass as the motor burns. I would then have an equation like:

Thrust - Drag = m(t) x a

Click to expand...

Are you forgetting weight?

T - D - mg = ma


Also, I think many of the simulations expend propellant weight proportional to impulse burned.

Kerry,

Could you please post a complete bill of materials? Thanks!

Buckeye said:

Are you forgetting weight?

T - D - mg = ma


Also, I think many of the simulations expend propellant weight proportional to impulse burned.

Click to expand...

Good point - it is something you definitely need to be careful with when using accelerometers. Some accelerometers, such as solid state acclerometer-in-a-chip type (aka "MEMS accelerometers) measure and report steady state accelerations, such as gravity and others, such as piezo based accelerometers only report transient accelerations. If you are using a solid-state type, which includes the accelerometers that I am using (and by the way the ones in your iPad and smart phone that rotate the screen based on where they think gravity is) then you will note that there is either a +1G or -1G acceleration when the device is sitting on the launch pad and not moving. (The sign depends upon which orientation you used when you placed it into your rocket). If the measurements you use in the calculation include that 1G then you either need to account for it mathematically as you suggest, or simply subtract the 1G from your measured value before you perform the math.

By the way, here is an interesting phenomenon you may not have noticed. For safety you shoud do this in the passenger seat yourself while someone else is driving...

There is an accelerometer in many smart phones that is used to orient the screen so that the "bottom" of the screen is on the side of the screen that is pointing towards the ground as measured by the accelerometer. You can fake out this logic quite easily. If you drive on a clover-leaf type exit or entrance ramp on or off a highway, and you are at a reasonable speed, say 30 mph, you notice that there is a force pushing you away from the center of the circular path you are traveling on. That force can be used to incorrectly re-orient your smart phone screen. Before you enter the turn position the smart phone in your lap so that the bottom of the screen is pointing toward your belly and the top of the screen is pointing towards your knees. Keep the top of the screen elevated above your lap by about 1" more than the bottom of the screen. The phone should orient the screen in the position that you would normally read it in. The bottom of the screen in this case isn't pointing straight down towards earth, so the acceleration wouldn't be measuring a full 1G, but the force is higher in that direction than any of the other 3 sides of the screen, so it decides to orient the phone in that direction.
If you keep the phone in this position as you travel through the curve, the centrifugal (apparent) force created by going around the curve will be larger toward the side of the phone than the portion of the gravitational force pointed towards your belly and as a result the smart phone will turn the screen orientation 90 degrees as long as you stay in the curve at a reasonable speed. If you stop on the curve or reach the end of the curve, the centrifugal force goes away and the screen orientation will return to the "correct" direction.

sooner.boomer said:

Kerry,

Could you please post a complete bill of materials? Thanks!

Click to expand...

Since I am officially a DIY Hacker, I don't have a true Bill of Materials, but the important parts I used to create the data in the plots above are listed below along with the website where I purchased the items

1) Arduino UNO product code 50 adafruit.com
2) Barometric Altimeter BMP183 adafruit.com
3) Accelerometer ADXL345 adafruit.com
4) GPS: Product ID 746 adafruit.com
5) Radio adapter board: Xbee Shield v2.0 seeedstudio.com **
6) Radio module: Xbee 900Mhz Pro Wire 3SB WRL-09097 ROHS sparkfun.com
7) 9v battery, 9v battery clip, small toggle switch installed into the battery lead to provide power on/off
8) Micro SD adapter Product ID 254 adafruit.com
9) Micro SD 4GB card Product ID 102 adafruit.com *


* You might be able to get other SD cards to work, but I *know* this one worked and others I had around the house did NOT work correctly.

** if you use this adapter board, or many others on the market, with the 900MHz pro XBEE boards, you will have to surgically remove the RSSI LED from the carrier board in order for it to work correctly. This is not at all obvious nor documented well on the internet. You can get some help from digi.com or PM me for details.
Note that you can use many other XBEE radios in the same adapter board, such as any of the 2.4GHz radios and you will not need to modify your carrier board - but you will have a radio range that is less than 500 ft. the sparkfun.com website has an excellent selection of xbee cards to choose from.

-Kerry

Thanks!

Buckeye said:

Are you forgetting weight?

T - D - mg = ma

.

Click to expand...

No, and depends. If you are calculating thrust and Cd from the raw readings then NO you do not add the mg term. That is because gravity is not measured by the accelerometer in flight.

If you are adding a -1g offset to the accelerometer reading to get an earth reference framed acceleration reading (instead of a rocket reference framed) reading, then you need to add the mg term.

Also when the rocket is sitting on the pad the 1g reading would be the same reading you would get if the motor thrust was exactly equal the rocket weight. So in this case the raw accelerometer reading (not gravity compensated) would exactly measure the motor thrust. (the mg term is already baked in, you do not add it again).

jderimig said:

No, and depends. If you are calculating thrust and Cd from the raw readings then NO you do not add the mg term. That is because gravity is not measured by the accelerometer in flight.

If you are adding a -1g offset to the accelerometer reading to get an earth reference framed acceleration reading (instead of a rocket reference framed) reading, then you need to add the mg term.

Also when the rocket is sitting on the pad the 1g reading would be the same reading you would get if the motor thrust was exactly equal the rocket weight. So in this case the raw accelerometer reading (not gravity compensated) would exactly measure the motor thrust. (the mg term is already baked in, you do not add it again).

Click to expand...

KerryQuinn said:

Good point - it is something you definitely need to be careful with when using accelerometers. Some accelerometers, such as solid state acclerometer-in-a-chip type (aka "MEMS accelerometers) measure and report steady state accelerations, such as gravity and others, such as piezo based accelerometers only report transient accelerations. If you are using a solid-state type, which includes the accelerometers that I am using (and by the way the ones in your iPad and smart phone that rotate the screen based on where they think gravity is) then you will note that there is either a +1G or -1G acceleration when the device is sitting on the launch pad and not moving. (The sign depends upon which orientation you used when you placed it into your rocket). If the measurements you use in the calculation include that 1G then you either need to account for it mathematically as you suggest, or simply subtract the 1G from your measured value before you perform the math.

By the way, here is an interesting phenomenon you may not have noticed. For safety you shoud do this in the passenger seat yourself while someone else is driving...

There is an accelerometer in many smart phones that is used to orient the screen so that the "bottom" of the screen is on the side of the screen that is pointing towards the ground as measured by the accelerometer. You can fake out this logic quite easily. If you drive on a clover-leaf type exit or entrance ramp on or off a highway, and you are at a reasonable speed, say 30 mph, you notice that there is a force pushing you away from the center of the circular path you are traveling on. That force can be used to incorrectly re-orient your smart phone screen. Before you enter the turn position the smart phone in your lap so that the bottom of the screen is pointing toward your belly and the top of the screen is pointing towards your knees. Keep the top of the screen elevated above your lap by about 1" more than the bottom of the screen. The phone should orient the screen in the position that you would normally read it in. The bottom of the screen in this case isn't pointing straight down towards earth, so the acceleration wouldn't be measuring a full 1G, but the force is higher in that direction than any of the other 3 sides of the screen, so it decides to orient the phone in that direction.
If you keep the phone in this position as you travel through the curve, the centrifugal (apparent) force created by going around the curve will be larger toward the side of the phone than the portion of the gravitational force pointed towards your belly and as a result the smart phone will turn the screen orientation 90 degrees as long as you stay in the curve at a reasonable speed. If you stop on the curve or reach the end of the curve, the centrifugal force goes away and the screen orientation will return to the "correct" direction.

Click to expand...

Good info. Thanks.

Some accelerometers have a function which filters out the steady state value and only shows shorter-term accelerations. These read 0 at rest, which is useful for some consumer input devices, but which you should turn off if it's present, because you want the unfiltered readings, not high-pass-filtered ones.

You should expect your accelerometer to read 1g (or -1g, it it's turned the other end up) on the pad.

Inertial accelerometers are always affected by gravity, whether on the ground or in flight. They can't NOT be when in the earth's gravity well.

The only time an unfiltered accelerometer might "appear" not to measure gravity (and thus give 0 as a reading) is when it is accelerating downward (or decelerating upward) relative to the earth at 1g to balance out the gravitational effect.

Accelerometers are affected by and measure gravity in flight. If they didn't, they'd read -1g as they started free fall and were accelerating downward at 1g. Which they don't. They read 0, even though the rocket is accelerating at 1g towards the earth. When you "subtract back out 1g" from the reading of 0, you get the true -1g of earth-referenced acceleration.

One thing to keep in mind is that rockets don't fly exactly straight up and straight down. The more they curve, the more trigonometric error you'll get when you try to subtract a "straight up and down" 1g from your "somewhat angled to the side" accelerometer reading. Not always a huge discrepancy if the rocket is mostly pointed straight up or you have a gyroscope and a well-calculated orientation to use for the math, but it's something to keep in mind.

John Beans said:

Accelerometers are affected by and measure gravity in flight. If they didn't, they'd read -1g as they started free fall and were accelerating downward at 1g. Which they don't. They read 0, even though the rocket is accelerating at 1g towards the earth. When you "subtract back out 1g" from the reading of 0, you get the true -1g of earth-referenced acceleration.

Click to expand...

John here is my take on my "Accelerometers don't measure gravity" statement.

An accelerometer can only respond to the gravity force ONLY when the accelerometer's frame is constrained. Otherwise the force due to gravity is equally applied on the MEMS frame and the spring-mass sensing element providing no net deflection or reading. On the pad this constraint is the rail or lug stop.

Once the rocket leaves the stop and the frame is unconstrained relative to the spring-mass sensing element, the accelerometer ONLY responds to net force on the rocket excluding the gravity force (thrust - drag). In flight if there is no thrust nor drag the accelerometer reads 0 in the axis of motion regardless of orientation with respect to the earth.

If the rocket motor thrust was exactly equal to the weight of the rocket at launch z then the accelerometer would still read 1g even though another mg of force was added to the rocket. Where did the first mg go? Its gone, zip, vanished when the gravity constraint was removed from the rocket and replaced with motor thrust.

Edit: Once the rocket leaves the pad you cannot tell from just the accelerometer data alone what the value of "g" is or even what planet you are flying from.

So the purposes of motor thrust and drag force characterization you can use the raw accelerometer reading without considering the mg term. You only need to consider mg is you applied the 1g offset to get the acceleration value in the earth reference frame.

jderimig said:

John here is my take on my "Accelerometers don't measure gravity" statement.

An accelerometer can only respond to the gravity force ONLY when the accelerometer's frame is constrained. Otherwise the force due to gravity is equally applied on the MEMS frame and the spring-mass sensing element providing no net deflection or reading. On the pad this constraint is the rail or lug stop.

Once the rocket leaves the stop and the frame is unconstrained relative to the spring-mass sensing element, the accelerometer ONLY responds to net force on the rocket excluding the gravity force (thrust - drag). In flight if there is no thrust nor drag the accelerometer reads 0 in the axis of motion regardless of orientation with respect to the earth.

If the rocket motor thrust was exactly equal to the weight of the rocket at launch z then the accelerometer would still read 1g even though another mg of force was added to the rocket. Where did the first mg go? Its gone, zip, vanished when the gravity constraint was removed from the rocket and replaced with motor thrust.

So the purposes of motor thrust and drag force characterization you can use the raw accelerometer reading without considering the mg term. You only need to consider mg is you applied the 1g offset to get the acceleration value in the earth reference frame.

Click to expand...

Much of what you say I agree with (especially that accelerometers measure the acceleration caused by net forces), but then you generalize and say, "accelerometers can't measure gravity during flight."

I think you say this because of the fact that two parts of the analysis numerically equal each other, and you conclude the third isn't involved. But you're comparing two things which shouldn't be compared (thrust and the accelerometer reading). Rather, you should think thrust -> acceleration, then acceleration + effect of gravity -> accelerometer reading.

Let's see if I can explain what I mean.
Here's what happens.

On the Ground

When the motor ignites, you note that "the accelerometer would still read 1g even though another mg of force was added to the rocket." But all that happened is that the rocket is being held up by the motor, instead of by the launch pad. The force on the motor mount went to mg, the force on the pad when to 0. One force replaced another. The acceleration of the rocket is still 0g. The accelerometer still reads 1g. There's no conclusion here to be drawn: the net forces on the rocket are still zero (weight of rocket balanced by support force), the acceleration is zero, the accelerometer reads 1g.

Flying

If you accelerate upwards relative to the earth at 1g, the accelerometer will read 2g.
The way engineers analyze problems like this is using a "free body diagram." You sketch out all of the forces acting on a body, and then use F=ma to figure out how the net forces cause net accelerations.
Ignoring air resistance for a moment, the forces on the rocket are:
1. -mg (gravity, down)
2. 2mg (thrust, up)

It takes 2mg of thrust to:
1. Counterbalance the weight of the rocket (take its weight off of the pad, even though it's not yet moving)
2. Accelerate the rocket at 1g

The sum of forces is thus 2mg(thrust, up) - mg(gravity, down) = 1mg (up). This unbalanced force of mg causes the motion of 1g upward. The rocket is accelerating at 1g, and the accelerometer says 2g. It says 2g because of 1g of acceleration and 1g of gravity which unfortunately always "pollutes" the reading. It does NOT say 2g because of 2mg of thrust. Accelerometers don't/can't sense thrust. They sense gravity (unfortunately) and acceleration, which is caused by unbalanced forces acting on the rocket. It says 2g because of 1g of acceleration and 1g of gravity effect.

It would be nice to invent an inertial accelerometer whose acceleration readings weren't "polluted" by gravity, but it's impossible for any mass, even the tiny mass in an inertial accelerometer, not to be affected by gravity in a gravity field. And if you could get the mass of the sensing element to be zero, it wouldn't work as an inertial accelerometer any more.

Why It Matters

You'll come to some funny conclusions and you'll forget to subtract the 1g that is always caused by gravity if you're not careful.
For instance, what does an accelerometer say:

1. Right after the rocket starts to fall after a straight up apogee? 0g, even though the rocket is accelerating at -1g (-1g acceleration + 1g gravity)
2. 5-15 seconds later as it reaches max downward falling speed? 1g, even though the acceleration is 0g (0g acceleration + 1g gravity)
3. If the rocket is accelerating 1g sideways 1.414g, even though acceleration is 1g (1g acceleration to the side + 1g gravity vertical)

These explain why you only feel the "stomach dropping" effect at the beginning of a skydive, and why it diminishes as you fall. The force of air resistance builds up until it counterbalances the force of gravity and the skydiver stops accelerating (though she keeps falling at a constant rate). The skydiver feels perfectly normal (less all the wind buffeting) stomach-wise at terminal velocity. In this case there's a lot of "thrust" against the skydiver, but it can't be measured by the accelerometer, because accelerometers measure acceleration (and gravity!).

Hey, if anything, you should say that "accelerometers don't measure thrust."

THAT I could totally agree with. ;-)

John,

If the accelerometer can measure gravity during flight, then we would be able to determine the attitude of the rocket from the accelerometer data alone. But we can't.

jderimig said:

John,

If the accelerometer can measure gravity during flight, then we would be able to determine the attitude of the rocket from the accelerometer data alone. But we can't.

Click to expand...

Accelerometers can DEFINITELY measure gravity during a flight.

There are altimeters which show graphs of altitude based on accelerometer data and do deployment based on it. (For instance, that's one way to use a Raven.) They come pretty close, with most of the variation due to trajectory (they don't so far have gyroscopes to completely model the angle of flight and subtract out the gravity vector very accurately as the rocket rotates before apogee). But in a straight up flight they come very close and you see pretty close agreement between the barometric altitude and inertially-calculated altitude. It really helps that, unlike other sports like RC flying, that the rocket starts from rest and finishes "the interesting bit" in just a few seconds. Accelerometers are okay at short term stuff like that with fixed initial conditions.

You'll hear a fair amount of grousing about dual deployment altimeters having issues judging apogee when they rely on accelerometers alone. Modern altimeters have good accerometers and firmware, but the curving trajectory and 1g gravity subtraction math is hard to perfectly account for when you can't measure rotation as well.

Using your example, if I have a motor that produces a thrust that 2x the weight of the rocket, the accelerometer will read 2g as you say. Assuming drag is negliable this will be a direct calculation of motor thrust , T=ma, where m=mass of the rocket, a=acceleration recorded by the accelerometer with the 1g offset applied.

In this case, thrust = 2x weight of rocket, you will get this same 2g accelerometer reading if the rocket is going vertically up, totally horizontal (perpendicular to the gravity vector) or straight down. Gravity is not affecting the raw accelerometer reading in each of these three cases because the readings will all be identical.