OpenRocket Optimization

[abuchanan]

I am a high school teacher. In my high school Aerospace Engineering class, I have the kids design and build an A engine powered streamer rocket optimized for maximum flight time. We are having issues with OpenRocket simulations. Attached is an example OpenRocket file.

This design uses an Estes A3-4T or A10-3T engine, a BT20 Airframe and a 6" wide folded tracing paper streamer. The expectation is that the kids will use OR to select the streamer length that will maximize flight time. Too short and it goes high but comes down fast. Too long and it comes down slow but does not go very high. There should be an optimal length. When we use the Rocket Optimization tool in OR, the results are very erratic and don't make sense. Some streamer lengths have zero flight time. When we do multiple simulations where we manually change the length of the streamer from 40" to 220" in 10" increments, the results are better but still have some peculiarities. See the attached “streamer size evaluation” pdf file. It is a pdf of an Excel file where we have graphed flight time as a function of streamer length using multiple manual simulations.

One observation is that if you look at the velocity and acceleration data for any given simulation, there is a significant “saw tooth” on the velocity and acceleration during the descent. To me this indicates that somewhere in the simulation numbers are being truncated to too few digits. This is a small rocket so the values involved are small. I am not software smart enough to dig into how OR does the calculations. I suspect that somewhere in there something is not using floating point variables and it is getting truncated. Would any of your software people be willing to look into the implementation of the numerical integration equations? The Runga-Kutta algorithm should be very precise even with small values if implemented well.

One last note. We have tried setting the time step to as small as 0.00001 s and it does affect the results but it does not fix them.

Thank you to everyone who has contributed to OpenRocket! :smile: It is a great program overall. I use it in my Aerospace Engineering class and my after school Rocket Club uses it too. All together that’s about 100 high school kids a year. We could never afford to buy RockSim. - Andy Buchanan

View attachment 2016 Bludger II T20 6.ork

View attachment Streamer Size Evaluations A.pdf

 

[Handeman]

I understand using the A motors for a high school class if they are expected to build and fly the rocket. If this is just an engineering/science exercise, why limit them to A size motors. Why not specify a certain 29mm motor, diameter and weight range for the rocket. You could specify which variables they could adjust and in what ranges. That should get you away from the small size issue with Open Rocket, if there really is one, and get you more into the experiment stage. Then ask them to write a design paper that details what variable they changed in which way and why that works to maximize flight time.

Just a thought.

 

[Cabernut]

Paging kruland... He's the member here who maintains OR. I haven't seen him on since March but I know they are busy preparing the next release.

As far as I know, it's all floating point/double calculations however there may be a long data type in there somewhere.

I've run a couple examples from your .ork file, and I'm getting some slightly different results. I'll see if I can run another series like in the pdf file and see if/how it differs

 

[dhbarr]

Possibly irrelevant anecdote: I had some sims that went a bit mad due to excessive tumbling.

Have you tried a chute in your sim to see if it evens out at a significantly lower rate?

 

[Cabernut]

This is an interesting analysis. I ran the complete set with your .ork file one at a time, my results are below. The time step was set to 0.001. There is still some sort of anomaly that appears with certain weight/length/altitude combinations.

 

[Buckeye]

You may be on to something with the management of small values and numerical precision. 4th order Runge Kutta is extremely precise, with numerical errors around 1.0E-14, even with large time steps.

I suspect the problem may lie in the drag and/or terminal velocity of the streamer with small numbers. As you noticed, the terminal velocity bounces around. The mean value does seem correct when compared to hand calculation. In OR, plot drag force, and you will see that it bounces up and down with large amplitude, similar to your velocity. All this fluctuation does not seem correct and is not seen with larger rockets with greater mass and higher drag values when simulated in OR.

Suggestion: The OR simulated altitude and flight time from launch to ejection deployment is probably pretty good. Use that. Then, replace the streamer descent terminal velocity with simple hand calculation and use that to get descent time.

 

[abuchanan]

I would like to thank everyone who took the time to read my post. I am especially appreciative to everyone who took the time to respond. Below I will try to respond to each of you.

Hamdeman,
The kids do build and fly these rockets. Many of them will build and fly 4 or 5 times over the course of the school year. Using A engines keep my cost within budget and allows us to launch on school grounds in limited space. Now, my after school club kids do design and build larger rockets. Going upto F engines for the TARC competition.

Cabernut,
It would be great to touch base with Kruland. I do have some kids who are programmers. If I could get them working with the people who code OR, they may be able to contribute to the overall program.

dhbarr,
Parachutes behave pretty much the same.

Cabernut,
Thanks for taking the time to explore this. You are right in that we need to look at the altitude and mass of the simulations too. I still think the decent velocity is key. My kids have not tried to graph that yet because of the saw-tooth we are seeing.

Buckeye,
I took a look at the drag force and you are right. It is bouncing up and down. The question is, is the force bouncing because the velocity is bouncing or is the velocity bouncing because the drag is bouncing?

I can see the same bouncing in the Reynolds number. That concerns me because I know OR will change the coefficient of drag as Reynolds number changes, but at these speeds (6 or 7 ft per second) the coefficient of drag should not be changing appreciably. I would be interested in seeing the algorithm used to adjust the coefficient of drag as Reynolds number changes. It could be over adjusting a these low descent velocities causing this oscillation in force and velocity.

Your idea to do the decent time with hand calculations is a great suggestion. I get the decent time is equal to the height x square root [(Cd x A)/(m x g)]. Is that your equation?

Thanks to all!
Andy B

 

[kruland]

Hi,

Simulation of descent - especially with streamers - is really inaccurate. OR automatically switches to a much bigger time step and utilizes some very general and inaccurate computations for Cd. Streamers are particularly troublesome because their performance depends on lots of things especially pleating, curling, folding, etc. (Check out some of the Streamer Duration discussions in NAR competitions.) I would suggest you modify your class experiment to instead focus on maximizing altitude since that is really a strong proxy for maximizing flight duration.

Kevin

 

[Buckeye]

I would like to thank everyone who took the time to read my post. I am especially appreciative to everyone who took the time to respond. Below I will try to respond to each of you.

Buckeye,
I took a look at the drag force and you are right. It is bouncing up and down. The question is, is the force bouncing because the velocity is bouncing or is the velocity bouncing because the drag is bouncing?

I can see the same bouncing in the Reynolds number. That concerns me because I know OR will change the coefficient of drag as Reynolds number changes, but at these speeds (6 or 7 ft per second) the coefficient of drag should not be changing appreciably. I would be interested in seeing the algorithm used to adjust the coefficient of drag as Reynolds number changes. It could be over adjusting a these low descent velocities causing this oscillation in force and velocity.

Your idea to do the decent time with hand calculations is a great suggestion. I get the decent time is equal to the height x square root [(Cd x A)/(m x g)]. Is that your equation?

Thanks to all!
Andy B

Right, you can assume terminal velocity occurs immediately at streamer deployment (good enough). Time = altitude/velocity.

https://www.grc.nasa.gov/www/k-12/airplane/termv.html

Plot drag coefficient in OR and you will see the dynamic Cd of the rocket (vs. Re or Mach usually) up to parachute deployment. Then, nothing during descent. OR must simply use the constant Cd as shown on the streamer part editor. As Kruland mentioned, the time step increases dramatically during descent so that the simulation doesn't take excessive time to complete. Rocksim does the same. This probably leads to the noisy velocity and drag of the small rocket.

Also as mentioned, streamers behave strangely and are hard to simulate, so your field experiments may be difficult to correlate. Use a parachute, instead. Or, change the optimization objective to something else, like altitude.