[sugpro] Re: Verifying Motor Performance Through Flight Tests

  • From: Richard Nakka <richard.rocketry@xxxxxxxxx>
  • To: sugpro@xxxxxxxxxxxxx
  • Date: Wed, 18 Feb 2015 13:35:20 -0600

You've described the process and challenges nicely, Steve.

It's been a while since I last harvested motor performance from flight
computer data, but it can be done with, I expect, reasonable
"engineering" accuracy. Timely discussion, as I plan to do this soon
with my latest batch of flight test data.

I recommend using the barometric, rather than accelerometer data,
integrations (and all the other calcs) can be done relatively easily
using a spreadsheet software. Adrian seems to have greater faith in
the barometric data compared to accelerometer ( I fly the Raven3).

Propellant mass as a function of time can be extracted from SRM.xls.

With regard to drag coefficient (Cd), I use AeroLab to obtain this.
AeroLab gives Cd as a function of mach number, which can be handy for
higher velocity flights.

Richard





On Sun, Feb 15, 2015 at 6:11 PM, Steve Peterson
<steve_peterson@xxxxxxxxxxxxx> wrote:
> Michael,
>
> The basics: if you have position (altitude) with respect to time, then the
> change in position over time is the velocity. The change in velocity with
> respect to time is acceleration. If you have the mass (at the same moment in
> time that you've calculated the acceleration for, then rearrange Mr.
> Newton's formula (F=ma) to get the net force. Any decent altimeter will give
> you altitude (to some precision/accuracy) vs. elapsed time (to some
> precision/accuracy). After that is when the gremlins get you....
>
> Altitude: change in altitude may not represent a true change in position
> (that is, distance) because the rocket may be headed off at an angle. You
> will have to either assume a certain angle of flight and calculate the true
> distance, or assume that it flew vertically (in which case the change in
> altitude is the change in distance).
>
> Mass: it isn't constant, so you'll have to calculate it based on the grain
> geometry and your static tests, etc. I don't know if any of Richard's
> spreadsheets list mass burned vs. time, but if they do, that would give you
> a good start, assuming your manufacturing is under tight enough control.
>
> OK, so you've calculated F--but hang on, because that's *net* F. That is,
> thrust minus the force of gravity and minus the force of drag. The force due
> to gravity is just g*mass and we've already dealt with mass.
> However, the force due to drag is more problematic. As you know, it consists
> of the Cd of the rocket (which will vary with velocity), the angle of
> attack, atmospheric conditions (launch pad altitude, altitude of the rocket
> at any instant in time, temperature, barometric pressure at launch, etc.)
> and, of course, the square of the velocity.
>
> Your question then becomes, will you know all that stuff with sufficient
> accuracy to give you a meaningful result? And will your altitude be
> accurate/precise enough to allow you to do all the math on it to get the
> acceleration with any kind of accuracy/precision?
>
> From what I recall, the Featherweight altimeters are about the most
> accurate/precise out there (although I would also check with the altus
> metrum guys because I've read that their stuff is pretty darned good, too).
> Both will record fast enough to get you data with short enough time
> intervals. I know Adrian Adamson (Featherweight) has done a lot of study on
> this--you might check the Featherweight forum and also over on TRF.
>
> I should also mention that the Featherweight altimeters (or at least the
> Raven), and possibly the altus metrum products, will also provide
> acceleration data so that you don't have to do the double differentiation to
> calculate acceleration from altitude. I haven't looked into how
> accurate/precise it is, however. But you still have to know the atmospheric
> info and the aerodynamics of your rocket--and those two are usually the
> killers.
>
> A lot of people have looked into doing this and, as I recall, very few have
> managed to come up with anything that was very persuasive (and they were
> using commercial motors), although I am certainly no expert on this stuff.
> It's pretty easy (especially if you can program) to simulate a few data
> points and do the calcs to see what you come up with. Munge the altitude
> data a bit to simulate inaccuracies and see how much it throws off your
> answer. Vary the Cd by .1, .2, .3 or so and see what happens. Etc etc.
> You'll soon get a feel for just how hard this is.
>
> --Steve
>
> On 02/15/2015 10:17 AM, Michael Monteith (Redacted sender
> michael_r_monteith@xxxxxxxxx for DMARC) wrote:
>>
>>   I hope this isn't off topic as it has to do with verifying motor
>> performance really.  I was thinking on what I would need to verify rocket
>> motor performance during a flight test.  So I was thinking of what would be
>> the requirements to gather the data in flight.  There is so many altimeters
>> and ranges of price.  Some show they output thrust time.  But not sure
>> exactly if it's what I'm thinking it is or I'd be better off getting one
>> cheaper and calculating it.
>> http://data.rocketsetc.com/altimeter_data.html
>>
>>   So to my question.  What data is required and how fast?   I see all the
>> thrust curves for static testing but trying to figure out how you backtrack
>> and figure from a flight test what the thrust curve is for comparison?  This
>> is what I want to arrive at, a thrust curve for flight test vs thrust curve
>> on static testing.
>>
>> My initial guess is at least having time and altitude and having rocket
>> mass etc.  From there you can calculate acceleration etc and arrive at
>> thrust.  I don't want to think of the formula right now for this.  It might
>> be in my pile of books but those are boxed up in Missouri and won't see them
>> for about a month now.  But don't recall anything like that.
>>
>>   I figured I might as well buy the right recording altimeter to begin
>> with.  I don't mind spending the money but only if I do it preferably once
>> and right.  Specifically the right data, accurate, and the right speed.  I
>> think the more time I spent on it the more confused I was with all the
>> options on them all.  At least until I know the bare minimum.   I don't know
>> if anyone has gone down this road or not. I saw Richard made mention on one
>> of his pages that it was something for a future page.
>>
>> If we need to take it offline feel free to email me.
>>
>> Michael Monteith
>>
>>
>
>

Other related posts: