[sugpro] Re: Verifying Motor Performance Through Flight Tests
- From: "" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "monsieurboo@xxxxxxx" for DMARC)
- To: sugpro@xxxxxxxxxxxxx
- Date: Mon, 23 Feb 2015 14:41:19 -0500
Testify, brother!
-----Original Message-----
From: Steve Peterson <steve_peterson@xxxxxxxxxxxxx>
To: sugpro <sugpro@xxxxxxxxxxxxx>
Sent: Mon, Feb 23, 2015 2:23 pm
Subject: [sugpro] Re: Verifying Motor Performance Through Flight Tests
On 02/23/2015 09:50 AM, Michael Monteith (Redacted sender
michael_r_monteith@xxxxxxxxx for DMARC) wrote:
> I'm kind of
> anal when
it comes to accuracy.
Oh dear, madness lies in this direction... :-)
As a
test equipment guy, you know the difference between accuracy and
precision (or
resolution). And you probably also know about error
budgets. So you're going
to have to just slog through some math to
decide just how much resolution and
accuracy you're going to need in
your test instruments (altimeter) to
determine the motor thrust curve
with the accuracy and resolution you
desire.
That will help decide whether 30 ft or 1 ft resolution is required in
your altimeter. However it ignores the altimeter's *accuracy* which
probably
won't be anywhere near that. For instance if you get one
altitude measurement
of 100 feet with 1 ft resolution and when the
altitude was really 200 feet,
then you get another altitude measurement
of 500 feet with 1 ft resolution and
the altitude is really 300 feet,
your velocity data will be quite different
from what it should have been.
The best you can do is read the datasheets for
the pressure sensor and
the accelerometers that are used, then study the
atmosphere a bit, then
do some math. Then give up :-)
One of the problems
(almost always ignored by folks) is that when we
convert pressure to altitude
we assume that the air over our launch site
follows the atmospheric model of
such-and-such a year. I think the
latest was 1976 or something (it's been a
while since I looked into this
for drag calculations). The obvious problems
are local temperature and
pressure, but you can (in theory) correct for this.
However, even after
those corrections, it turns out that the atmosphere's
*rate of change*
in pressure vs. altitude even for a given location is not
constant over
time and doesn't match the "standard day" model--weather
balloons are
launched daily that measure this (among other things) and you can
get
this data if you search the net a bit. What you want is the data from a
weather balloon launched from nearby and near the time of your rocket
launch
(along with stable weather over a few days). There was a paper on
this
floating around the net that I can't quickly locate -- Adrian or
someone
mentioned it a few years ago and it explained all this.
Alternatively, you
can launch your own device (gps and barometer) in a
balloon and use that data.
It probably can't be a previously launched
*rocket* because the gps will lose
tracking on the way up. Sigh....
Then, of course, you have to consider the
response time of your pressure
sensor *system* which includes (among other
things) the air hole in your
electronics bay which you might want to consider
(at least to the point
of eliminating it as a factor) along with acoustic
resonances, etc. And
maybe factor in the effects of air temperature on the
sensor &
associated electronics.
So, why not use accelerometer data
instead? Well, that's no slam dunk,
either. Start with the accuracy/resolution
of the chip itself, then
start adding up the errors in things like the A/D
conversion, the
voltage reference, etc. However, you still need the
atmospheric
information because you need to calculate the drag which requires
air
density (which you will have to deduce from the pressure information).
Adrian (IIRC) was trying to calculate apogee from accelerometer data and
you
just want to calculate force, which won't involve the same
accumulation of
error that an apogee calc would, but you'll still have
plenty of other sources
of error to put into your error budget.
I don't mean to discourage you from
tackling this--and you'll want a
decent flight computer *anyway*--but you
should know going in that if
you expect super accuracy/resolution, it will
involve a lot more than
flying a few motors. You're going to need to create an
acceptably
accurate/precise *experimental system* in order to get really good
motor
measurements. That, of course, could be fun in and of itself.
From
the practical point of view of determining motor thrust profiles,
however,
after a while, the data from a static test starts looking
better and better
:-) At least it does to me. But, again, we do this
stuff because it's fun and
we learn a lot in the process. So carry on :-)
--Steve
Other related posts:
