Tuning a sim to flight data

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Charles_McG

Ciderwright
Joined
Sep 12, 2013
Messages
3,796
Reaction score
2,573
Location
SE Wisconsin
So just what do you folks do with the data from a logging flight computer, like an eggtimer Quantum or Proton?

I compare it to the sim, and see how I can improve the sim.

Now, I know that my sims aren't perfect to begin with. I enter the major components, with the shapes and profiles reasonably close. Some things are hard - the fins on my Malemute are single side wedges, for instance - sharp top, fat bottom - I don't know how to sim that. And I measure the final weight and Cg, and use the overrides. And I set the appropriate launch conditions, rail length, ignition and deployment delays.

But after the first flight, i still end up with something like this.
1598922697909.png
1598922766816.png
1598922871831.png

Yes, I'm using non-standard tools to graph. I'm using JMP from SAS. It handles data sets with non-matching x axis values (different time increments in this case) handily.

You can see that the apogee was way lower than predicted. Velocity was lower and Gs were slightly low. In fact, I think there's a clue there - it looks like the difference in real v sim G might be increasing with velocity. and the coasting deceleration starts a little higher than sim. Sounds like my drag might be off.

Normally, I would tweak the surface finish and mass a bit to make the apogee match - but I'd got a lot of datapoints here, and besides, the mass change to tune the apogee is unreasonable - it makes a big mismatch during the burn and staging portions.

This rocket has a decent amount of fine surface detail, pretending to be a NASA sounding rocket payload, but done as bas relief to be better visible. So a drag issue doesn't surprise me.

I've had limited success playing with surface finish to change Cd. I can find an old Crazy Jim post talking about a Cd tab - but I think that's Rocksim.

My approach is to add a 'drag plate'. I insert a transition in the body of zero length and mass. It doesn't affect the Cp (at least the static one), but does make an element that I can tune by adjusting the diameter.

So I adjust the diameter of the drag plate to match the measured apogee.

1598923967844.png

The drag plate is just above the fins.

This time I'm plotting Alt, V and Gs together:
1598924117524.png

Very close. But there's a notable different in approach to apogee, and a slight difference in V and Gs. Since the sim is high, I do one more tweak, adding 10% mass (I didn't have the dog barf in the measured weight) and trimming the drag plate to rematch apogee. The final drag plate was 3.6" on a 3" body.

And the result:
1598924461061.png

The green line is the second tuning. It's a little under for Gs, but spot on for V, especially in the sustainer coast. And a somewhat better fit for approach to apogee.

The proof will be the next flight, of course. Got to have a second datapoint. The sustainer will get an H53 instead of a G126.

And the booster? Well, it didn't have a logging altimeter on board, so I can't do the same coasting analysis. But I did look at the ground based video a lot, and as far as I can tell, it's matching it's sim close enough. Much simpler surface and fins.
 
I usually play with the drag too. Add fin thickness, square edges, etc. Also make sure your launch conditions match- elevation, wind speed, so forth. That usually gets me pretty darn close. I tend to focus on altitude rather than the curves. Also the barometric sensor is geared mostly to detecting apogee, there is going to be more error at higher velocity due to flow over the vents, apparent hysteresis due to leakage into the AV bay from the airframe, etc.

Saw the flight video by the way, very nice.
 
The problem with tuning drag is that it is a catch-all fudge factor for everything that may be wrong in your comparison. Your tuning factor may work on this one case, but not future flights or with different motors. So, it is hard to tell with just one flight.

Motor thrust variation is the biggest culprit, and you have two of them in this two-stager. How well did the two stages separate and maintain a constant trajectory? OR assumes perfection.

Also, altimeters are not "real world." They try to measure stuff with assumptions. Yes, the baro measurements may be wonky at speed due to hysteresis, and the actual atmosphere may be a lot different than the Standard Atmosphere model programmed in the firmware. Temp and pressure extremes can cause 10% or more errors in baro readings. OR's ground elevation and atmospheric models are messed up as well.

I do like your graphing software. I will check it out!
 
The problem with tuning drag is that it is a catch-all fudge factor for everything that may be wrong in your comparison. Your tuning factor may work on this one case, but not future flights or with different motors. So, it is hard to tell with just one flight.

Motor thrust variation is the biggest culprit, and you have two of them in this two-stager. How well did the two stages separate and maintain a constant trajectory? OR assumes perfection.

Also, altimeters are not "real world." They try to measure stuff with assumptions. Yes, the baro measurements may be wonky at speed due to hysteresis, and the actual atmosphere may be a lot different than the Standard Atmosphere model programmed in the firmware. Temp and pressure extremes can cause 10% or more errors in baro readings. OR's ground elevation and atmospheric models are messed up as well.

I do like your graphing software. I will check it out!

Well, by mid-October I should have a second flight to see how well my sim tuning did or didn't work.

I don't expect perfection - I'm exploring how the variables can be manipulated and how the shapes of the curves vary. I was a little surprised that I could get it to match as well as I did with relatively simple mass and drag adjustments.

And I'm all to aware of alt error that an f(v). On the prior sounding rocket I was flying I tried to be fancy and used payload bay pins with central holes as the vent ports. That rounded protruding surface would make the baro read several hundred feet higher than the accelerometer during boost. This flight shows only a little error during the sustainer burn.

This flight was a picture perfect boost on a day when the KBUU metar was reading calm. There were perceivable 'gusts' on site.

The motor burns appear to be very close to the expected. Within 10%. On other flights, I have seen non-sim burns - one looked like a different propellant. I did tweak the sim for the measured second stage delay. It looks like it took a quarter of a second to light.

Flight video is here:


Build thread is here:
https://www.rocketryforum.com/threads/terrier-malemute-1-5-2-scale-build-and-info.155945/
JMP is much more than graphing software. Prepare thyself for sticker shock.
 
Update - got in a second flight with different sustainer motor, This time it was an H399WY-H53MY.
Sky conditions weren't great for iPhone video.
Also, I completely lucked out on recovery. I think an over-energetic drogue charge, which broke the 3D printed bottom avbay lid, popped the main at apogee.
<insert eggtimer promo>



But this thread is about sim tuning. Here's the overlay of the sim data, adjusted only to make the sustainer ignition timing match.
Filtered_Altitude/OR Alt, then Accelerometer Velocity/OR Vert V., then Accelerometer G/OR Vert Accel.

Flight 2.png

Look at that burn profile. It was a -pretty- straight flight. I'm pretty pleased with how the tuned sim held up, and wouldn't adjust it further with out more flights. It's against my religion to take the average of 2 points.

@cerving , the new code (This is 1.03L) seems to be working great. The burnout detection for the second stage triggered (no event - just the recorded burn length) about halfway through the burn. A 'feature' of the low thrust.
 
Nice data, and great flight! Also, that's a good idea to take a picture of the GPS coordinates.

@cerving , the new code (This is 1.03L) seems to be working great. The burnout detection for the second stage triggered (no event - just the recorded burn length) about halfway through the burn. A 'feature' of the low thrust.

Good to hear, I just updated my Protons to 1.03L. Did you use burnout detection for sustainer ignition? Was the second stage trigger just for the purposes of SW testing?
 
Yes, I’ve been using the burnout detection for sustainer ignition since it was introduced. MUCH easier to configure than counting from launch or LDA. And you can see that I can (now, after practice and fixes) set events with sub-second timing with confidence. I find the motors I use take 0.2-0.5 sec to come up to pressure.
I didn’t have an event that used BO#2. I just noted that in the flight summary report, it lists the time and burn duration- and it isn’t correct for that motor. The regressive burn thrust dips below the 1G detection threshold about halfway through the burn.
 
Back
Top