OpenRocket 14.03 released

The Rocketry Forum

Help Support The Rocketry Forum:

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

I tried to do this initially, unfortunately all velocities are referenced to the rocket's direction so they are always positive. I suppose one could project the rocket velocity vector on unit-z, but what if the rocket is travelling horizontally? It could still be deploying at a very large velocity but the z component of that velocity is 0.

Kevin

You could have both columns: airspeed at deployment, and vertical velocity at deployment.
 
Sure, that makes sense. And you can certainly do that now but it requires you to do the work of setting up a simulation with an artificially plugged motor, then examining the graph.

However, the motor finder thing would essentially do this for you. It wouldn't tell you maximum coast but it would give you the motors which are close. Say you have an LPR and want to fly it on a C6. And it just so happens the coast time is 4 seconds. The finder would give you both the C6-3 and C6-5 as options (provided they still meet your flight envelope) and the simulations for those motors would show you a difference in altitude achieved. Obviously the C6-3 would have a shorter altitude.

This is not what I envision for Optimum Delay.

Let me restate it this way: It is the elapsed time from motor burnout to apogee, or in other words "coast time".

From that information I can nuance the actual delay for the motor.

Is that doable?

Let me know if that makes sense or not.

Greg
 
Can I make a request? Can you add a column on the simulation page for "Optimum Delay"? I'd like to see what the time between motor burnout and apogee is without having to plot each flight.

Thanks,
I second that.
 
This is weird and I'd like to experience it myself. I've sent you a PM with some steps to get some info.

Kevin

Yes the 3D works but as soon as I click on TOOLS and then PHOTO STUDIO everything disappears.
 
I'm not sure this is helpful to other but, when I'm working on finding optimum delay, I set run a sim with the motor I want and set it to the longest delay. I then export the sim data to an excel spreadsheet and find the time of apogee. Subtract the time where it has motor burn out, and now I have a pretty good idea of what delay to use. I take this number, rerun the sim and validate. YMMV.
 
OK, I found the people, "Environment", then "Frozen Lake", there's the people.
I thought for a minute you guys had imported your own image.

JP
 
Frozen Lake is Sampo's home field. The opposite extreme from Black Rock or Argonia KS!

OK, I found the people, "Environment", then "Frozen Lake", there's the people.
I thought for a minute you guys had imported your own image.

JP
 
Sure, that makes sense. And you can certainly do that now but it requires you to do the work of setting up a simulation with an artificially plugged motor, then examining the graph.

However, the motor finder thing would essentially do this for you. It wouldn't tell you maximum coast but it would give you the motors which are close. Say you have an LPR and want to fly it on a C6. And it just so happens the coast time is 4 seconds. The finder would give you both the C6-3 and C6-5 as options (provided they still meet your flight envelope) and the simulations for those motors would show you a difference in altitude achieved. Obviously the C6-3 would have a shorter altitude.

It is a computer, make it do the work. This is an essential feature, We'll be happy to wait an extra second to get the info we really want.
 
This is basically what I am doing now. I pick a motor with long delay, run the sim, check the plot and look at how long the rocket coasted before apogee and then pick the closest delay AFTER apogee. The problem is that I usually sim a bunch of motors and then decide which one to fly based on the waiver or which ones I can get from the dealer at the launch.



I'm not sure this is helpful to other but, when I'm working on finding optimum delay, I set run a sim with the motor I want and set it to the longest delay. I then export the sim data to an excel spreadsheet and find the time of apogee. Subtract the time where it has motor burn out, and now I have a pretty good idea of what delay to use. I take this number, rerun the sim and validate. YMMV.
 
OR already has the option to select ejection at apogee for all sims, right? Can we just get a column that reports the coast time? That would get us what we're looking for. Turn the option on for all sims, run all sims, look at coast time and decide if the selected delays are close enough.

Buy kruland a beer. DONE! :cheers:

Sure, that makes sense. And you can certainly do that now but it requires you to do the work of setting up a simulation with an artificially plugged motor, then examining the graph.

However, the motor finder thing would essentially do this for you. It wouldn't tell you maximum coast but it would give you the motors which are close. Say you have an LPR and want to fly it on a C6. And it just so happens the coast time is 4 seconds. The finder would give you both the C6-3 and C6-5 as options (provided they still meet your flight envelope) and the simulations for those motors would show you a difference in altitude achieved. Obviously the C6-3 would have a shorter altitude.
 
This is basically what I am doing now. I pick a motor with long delay, run the sim, check the plot and look at how long the rocket coasted before apogee and then pick the closest delay AFTER apogee. The problem is that I usually sim a bunch of motors and then decide which one to fly based on the waiver or which ones I can get from the dealer at the launch.


Of course, for all of this, you could just use an altimeter and not worry at all about apogee timing... :)
 
I typically just make the parachute eject at apogee regardless of what the motor says, and then pick the appropriate delay based on the burntime (which I can estimate).
 
Hi,

The ideal way of implementing the optimum delay feature within OR: If apogee occurs before deployment: done. If deployment occurs before apogee, copy and store the simulation state, and continue the simulation as regular. After the simulation has ended, continue the copied simulation without deployment until it reaches apogee. (Deployment can be prevented with a simple simulation listener; the optimum delay should be computet onlyin case the 'extra' flag is true).

That said, even running a new simulation from launch wouldn't slow things down too much in most cases.

Anyone have time and enthusiasm to give it a try?

Cheers,
Sampo N.
 
This is a frequent request, however, it is not possible to include that on this screen. The reason is, in order to determine optimum delay, you have to run at least two simulations - one with the delay artificially set to "plugged" one one with the actual motor. With the information provided you can determine if the delay is not right - look for velocity at deployment. However, you cannot really tell easily if it is too short or too long.

Kevin,

The column I think people want is something like "time between motor burnout and ejection if I'd used an altimeter." As others are suggesting, you can run two simulations. I find OR runs plenty fast, but if you feel this would take unacceptable amount of runtime, you can optimize by only doing the delay-finding simulation from motor burnout to ejection. Before that both simulations are the same, and users only care about after-ejection part on the simulation they actually set up.

Ari.
 
I'm not particularly worried about the computation time - I'm more worried about my time :) I totally understand the requirements and the need. As far as features go, I think the "automagic motor finder" would be much more useful to a lot of people.

Kevin

Kevin,

The column I think people want is something like "time between motor burnout and ejection if I'd used an altimeter." As others are suggesting, you can run two simulations. I find OR runs plenty fast, but if you feel this would take unacceptable amount of runtime, you can optimize by only doing the delay-finding simulation from motor burnout to ejection. Before that both simulations are the same, and users only care about after-ejection part on the simulation they actually set up.

Ari.
 
That is a perfectly reasonable answer Kevin. Thanks again for keeping this project maintained.
 
That is a perfectly reasonable answer Kevin. Thanks again for keeping this project maintained.

You're welcome. I'm also a rocket builder & flier and have a lot of projects going on including a *BIG* project which I haven't talked about yet. Unfortunately for the greater rocket world the big project had consumed a lot of my hobby time.

One thing to keep in mind, the squeaky wheel does get the feature. Just ask CarVac!

As it is, this "time for optimal delay" need is fully understood. It would be ideal if it could be used for HPR delay-drilling too. I'm thinking about it more and Sampo's approach seems pretty clean. My preference would be to have a column which tells you how short/long your delay is from optimal - Say "-5s" means 5 seconds too short, and "3" means 3 seconds too long. This is a pretty easy concept to wrap my head around and I don't think there are a lot of edge cases - so it's certainly doable. If I get motivated during the march madness, I might take a stab at this before the motor finder.

Kevin
 
One thing to keep in mind, the squeaky wheel does get the feature. Just ask CarVac!

Alternative color backgrounds for the 3D views would be nice (thus eliminating the polar bear in blizzard issue)... squeak... squeak...
 
Now our club can finally get flight pictures of those Baby Berthas that we have been shoving H195's in!

bb in space 2.jpg
 
Ahhh, takes me back to my days in Minnesota flying in the winter. My favorite launch was on a [frozen] Round Lake in Eden Prairie with my son. We had more fun listening to the ice crack and shift.

...then "Frozen Lake", ...
 
YES, totally agree. I am always running sims to figure out what motor will send "X" rocket to about 2,000 feet based on wind conditions, etc.

I think the "automagic motor finder" would be much more useful to a lot of people.

Kevin
 
I would like to make a "universal" electronic deployment "module" that you could put into any [larger] air frame rocket.

Of course, for all of this, you could just use an altimeter and not worry at all about apogee timing... :)
 
I run my simulation and then look at the "time to apogee" then adjust my delay accordingly. Does anyone know a way of attaching external boosters? Or how about pods on the fin tips?
 
Back
Top