Simulating Jolly Logic Chute Release in OpenRocket

The Rocketry Forum

Help Support The Rocketry Forum:

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

MetricRocketeer

Member of the US Metric Association
TRF Supporter
Joined
May 31, 2018
Messages
720
Reaction score
192
Location
Maryland
Hi TRF colleagues,

I am running experiments in OR in which I simulate the use of a JLCR. I am conducting my simulations on a LOC/Precision Warlock, and I am using a streamer to model the JLCR. I am setting the JLCR to deploy at an altitute of either 100 or 200 metres.

Here is the issue. I am having great success with a number of J-impulse motors when I don't use the JLCR, but I am not succeeding when I do deploy the JLCR. In my opinion, however, I don't think that the results make good sense. The warnings all state that the recovery device deploys at high speed. Right, the main parachute deploys as the rocket rapidly descends — and we know that is going to happen, because that is the point of using the JLCR. I think that the more telling statistic is the ground-hit velocity — and all of those are quite low.

So, I think that the bottom-line message provided by OpenRocket gives a false warning — and I say this as a big fan of OR.

What do other people think?

Thank you.

Stanley
 
I believe you are correct.

I hope we can add some more direct support for a JLCR or similar (cable cutter) in a future version. It's a common enough product that it should be natively supported IMHO.

I presume you do have it set to separate at apogee, right?
 
I had the JLCR to open at "first ejection charge of this stage". Isn't that correct?

Anyway, I just reran the simulations so that the JLCR opens a apogee, and I got similar results as before.
 
OpenRocket 2022-02 features a JLCR example rocket. Try it out tomorrow and let us know what you think.

Chute_Release.png

Insofar as the high-speed deployment warning is concerned, that is commonly the result of natural terminal velocity during free-fall (a JCLR has very little drag). This is the same warning that is given when (using dual deployment parachutes) the drogue allows a decent rate higher than about 75 ft/sec. This is not a "false warning" so much as a warning that you need a higher quality main parachute (for example, a 72" Fruity Chute parachute can safely open at up to about 180 fps -- a 36" Fruity Chute can safely open at up to about 250 fps, a velocity that would shred lesser quality chutes).

The actual decent rate using a JCLR (from apogee to main deployment) can only be determined by actual flight results; OpenRocket cannot determine the extent to which one model will be more or less ballistic than another in its free-fall characteristics; OpenRocket effectively calculates when the free-fall velocity of the whole rocket is slowed by a recovery device, not by calculating the free-fall velocity of the separated upper and lower halves of the rocket (while connected with a shock cord). The user is expected to make adjustments to bring the JCLR decent rate in-line with actual flight results.
 
Last edited:
OpenRocket 2022-02 features a JLCR example rocket. Try it out tomorrow and let us know what you think.
Hi @H. Craig Miller,

I am going to work on this right now. Let me make sure that I am looking at the rocket to which you are referring.

Is it the "hybrid rocket with dual parachute deployment"?

Thank you.

Stanley
 
How to simulate a chute release using the new OpenRocket 2022.02. To experiment in OpenRocket, first open the Chute release example and familiarize yourself with its components.

01.01.Example.png02.02.Example.Config.png

Leaving the configuration window open, left-click the flight simulations tab, and hover your cursor over the first "!" to show the warning.

03.03.Example.Flight Data.png

As you increase the component Cd, the velocity at the time the main recovery device is deployed decreases.

04.01.Example.Adjusted to Flight Data.png

Adjust the component Cd so that the velocity between apogee and the time the main recovery device is deployed matches your actual flight data.

Because OpenRocket cannot simulate two halves of a rocket connected by a shock cord (OpenRocket cannot determine a tendency toward a ballistic decent after the apogee event), this adjustment is rocket specific.

Let us know what you think.
 
You can simulate a Chute Release (or a drogueless rocket) by adding a drogue with the frontal area of the rocket, and having the main deploy at your selected altitude. You'll get that "high speed deployment" warning, but you can ignore it.

The use of a drogue parachute as suggested is an alternative to the use of a streamer featured in the OpenRocket Chute release example. However, neither is a substitute for adjusting the Cd of whichever method you use to match your actual flight data.

For demonstration purposes:

05.02.Example.Compare Drogue Chute to Streamer.png

As shown above, the suggested drogue parachute hack and the streamer used in the OpenRocket Chute release example have extremely high (unsafely high) velocity estimates when the main recovery device deploys. Both methods require an adjustment to the component Cd so that the velocity between apogee and the time the main recovery device is deployed matches your actual flight data. Although the OpenRocket development team is considering how to implement a true chute release, at the moment this is the best approach.

The added benefit to using the streamer is an easier differentiation between the chute release and the main parachute (less confusion for those graphically oriented minds), each has a different appearance, both on the component tree and within the rocket.

To summarize, either method is acceptable, but both methods require the component Cd to be adjusted to match your actual flight data:

06.01.Example.Compare Drogue Chute to Streamer.png

Last, but not least, either way, don't forget to adjust (override) the mass of the component to its actual weight. OpenRocket uses .6 oz for its Chute release mass override in the example.
 
Thanks for that excellent write-up Craig.

Note that you'll need some sort of flight recorder to obtain the descent velocity under the Chute Release, so you can subsequently make those adjustments to the model.

I feel like we should be able to make this process a bit easier, but it'll require some thought on how best to do it.
 
Hi OpenRocket developers,

I have now downloaded and experimented a bit with the very latest version of OR.

All of you have done great work in making OR a fantastic simulation program.

Of course, having to get the actual flight data can be challenging.

Note that you'll need some sort of flight recorder to obtain the descent velocity under the Chute Release, so you can subsequently make those adjustments to the model.

So, what flight recorder do people recommend to obtain the descent velocity?

Stanley
 
So, what flight recorder do people recommend to obtain the descent velocity?
I have a Jolly Logic Alt3 that'll do it. Can't speak for any others.

I would imagine that you could just make an estimate of this value and work with that. Other folks on the forum could probably give you a good idea of a range of values to expect.
 
I have a Jolly Logic Alt3 that'll do it. Can't speak for any others.

I would imagine that you could just make an estimate of this value and work with that. Other folks on the forum could probably give you a good idea of a range of values to expect.

Why is this that hard? Its exactly the same as electronic dual deploy where you set the deploy at your selected altitude on the JLCR, just like what Cris has mentioned.

Certainly when building a rocket and using it to simulate, there is no way to get actual flight data. But yes, the Alt3 can get flight data which has CSV export (or at least mail to yourself) that can be used to obtain the rough slopes of descent to figure out descent velocity before and after the JLRC deploys the main.
 
Why is this that hard?

This is why:

07.03.Example.Compare.png

So, if the Cd of the Chute release component isn't high enough to actually mimic a drogue (meaning to actually slow the decent rate), the decent velocity at the time the main is deployed isn't going to be accurate. Let me put it another way, a Chute release component must have a high enough Cd to make OpenRocket believe that it's actually slowing the rocket's decent, and the reason that is important is because shock load will soon be introduced (so you will know whether your recovery system is strong enough).

Clearly, A and B would have different decent rates, but OpenRocket doesn't know that. It can only detect when the decent rate is slowed by a device with sufficient drag, like C.

I hope this helps to understand why actual flight data is required if you want an accurate decent rate simulated; if you don't know how fast it's coming down, you don't have any idea whether it will snap your recovery system when the main opens or where it may land, near or far.
 
if you don't know how fast it's coming down, you don't have any idea whether it will snap your recovery system when the main opens or where it may land, near or far.

And yet none of that matters unless you already have a rocket built and flown. If you've built and flown your rocket and now you have some data (assuming you used an altimeter or maybe just guess) and want to try and simulate, good luck, how far it might land in different atmospheric conditions, then ok that does make sense.

"and the reason that is important is because shock load will soon be introduced (so you will know whether your recovery system is strong enough"

That's an interesting feature. But if for say DD or JLRC requires you to build, then launch the rocket, only to get Cd data to then put in to run a simulation to check and see if the shock load is acceptable, you've already done that through empirical evidence.

Still seems like cerving's suggestion is better up front in simulations prior to building, etc. Then you get a reasonable prediction before you build (and order parts or learn the hard way) since as you noted OR basically assumes ballistic without a recovery device.
 
Still seems like cerving's suggestion is better up front in simulations prior to building, etc

If you look at the other suggestion simulation results, OpenRocket believes it’s coming in ballistic too. It’s up to the users to decide their own level of safety and comfort. Enough said.
 
You can simulate a Chute Release (or a drogueless rocket) by adding a drogue with the frontal area of the rocket, and having the main deploy at your selected altitude. You'll get that "high speed deployment" warning, but you can ignore it.
This has always been the easiest approach to simulating a JLCR, with variations on making the 'drogue' a phantom with a weight overridden to zero and the size of the parachute set to the side area of the fin can. Seems to work pretty well overall with many, many mentions of the methodology pioneered in 15.03 appearing in these forums.

As always, no matter what you do, you'll have to fly it once and adjust the sim to match what real world performance you observe.
 
If the developers wanted to improve this behavior, adding a better simulation of the drag of a separated drogueless rocket would be useful. I have no idea what OR does now but doesn't seem to be physically realistic, and anything would be an improvement (something dependent on the side area, derated for tumbling and altitude-dependent density, with the caveat that it could be inaccurate or just wrong in many cases).
 
If the developers wanted to improve this behavior, adding a better simulation of the drag of a separated drogueless rocket would be useful. I have no idea what OR does now but doesn't seem to be physically realistic, and anything would be an improvement (something dependent on the side area, derated for tumbling and altitude-dependent density, with the caveat that it could be inaccurate or just wrong in many cases).

You mean like this?

https://www.apogeerockets.com/education/downloads/Newsletter460.pdf
1675972655907.png

Granted, CdA was derived from flight data, but at least it shows the ball park we are working in for future modeling.

And... all work done in SI units!
 
It's really hard to simulate an ejected, tumbling rocket. Nobody really pays attention to the aero-balance of two sections of rocket connected by a shock cord, and even if it was properly characterized, it can change by speeding up and slowing down as it tumbles.

I had one rocket once—I think an Estes Executioner—that would tumble completely flat and descend at 20 fps. It was effectively able to do tumble recovery. But every now and then it would suddenly streamline and fall inline much more rapidly before Chute Release would open. Interestingly, by making the "stack" vertical, a small drogue would have SPED IT UP on descent rather than slowing it down.

But in general, flying once without a drogue but with a recording altimeter like AltimeterThree (don't ask me when it will be back) and noting the average tumble rate will enable you to sim it with a zero-weight drogue that produces that average descent rate.
 
It's really hard to simulate an ejected, tumbling rocket.
Agreed, and experienced users just don't ask OR to ever do that by adding a zero-mass drogue to get the descent rate to some nominal value around 75 fps (sorry, 23 m/s :) ), in advance of real flight data. But if the end goal is to make OR friendly to new users who don't know to do this and get concerned when they see warning messages, unrealistic descent rates, etc, then some change is required.

But don't do it for me, I still use 15.04.
 
Agreed, and experienced users just don't ask OR to ever do that by adding a zero-mass drogue to get the descent rate to some nominal value around 75 fps (sorry, 23 m/s :) ), in advance of real flight data. But if the end goal is to make OR friendly to new users who don't know to do this and get concerned when they see warning messages, unrealistic descent rates, etc, then some change is required.

But don't do it for me, I still use 15.04.

I'll write the "TIP" into the documentation if I am ever able to get an account on the wiki. :)
But it's gonna be a while before there is any real "science" behind descent rate modeling sans flight data. Maybe today's TARC folks will see it before they pack it in for "the" final launch.

And entirely unnecessary. When ALL of the necessary things are done and all the unnecessary stuff on the "unnecessary but cool to do" list AHEAD of it are done..... then, the devs should get right on it. 😂
 
Last edited:
I never got too scientific about how to simulate a JLCR in Rocksim (don't know about OR). I add a dummy streamer of minimal width, length and weight to deploy at apogee (electronic) or at the ejection charge event (non-electronic) and then set the parachute to deploy at the JLCR deployment altitude. The dummy streamer ensures the software knows the rocket breaks apart at apogee (so it does not come in ballistic). It's no different than what you would need to do for a dual deploy where you let the rocket go drogue-less (assuming roughly equal halves) and having the main deploy as usual. The descent rates in Rocksim for the drogue-less deployment are reasonable for every sim of every rocket I've flown with a JLCR, so it is clear Rocksim takes into account the basic dimensions of the nose cone, airframe and fin profile in calculating the descent rate under drogue-less conditions. I started with rockets I had previously flown and knew their flight characteristics and moved to new builds once I was confident in the prior results.

I have never had any rocket, regardless of the relative masses of the two sections, fail to successfully deploy with a JLCR. No chute damage, no zippers, no crashes (36 flights in 9 different rockets; tall & skinny, short & fat, evenly sized halves & only the nose cone vs. the airframe). Yes, it would be better to know the descent rate in advance, but it's not calculable and not really necessary.
 
Trying to set the the size of a fictitious streamer or chute to get the descent rate you want is probably not a good idea, but trying to make a reasonable guess makes sense. I'd guess that doing something like a streamer with the same area as the planform area of the rocket wouldn't be unreasonable.
 
Trying to set the the size of a fictitious streamer or chute to get the descent rate you want is probably not a good idea, but trying to make a reasonable guess makes sense. I'd guess that doing something like a streamer with the same area as the planform area of the rocket wouldn't be unreasonable.
I agree that makes sense. So, I just did that for one of my rockets and the descent rate on that fictitious streamer was 15 MPH, much lower than what I have experienced in actual flights flying drogue-less. If you leave a streamer off entirely, the sim says the main deploys at 193 MPH, which is also way wrong in the other direction. Descent rates from my Altimeter 2 on certain flights says the descent rate is around 30 MPH, which fits the visuals on the field. Bottom line, using a JLCR is pretty much like flying drogue-less, which the sims don't handle. It just works.
 
Trying to set the the size of a fictitious streamer or chute to get the descent rate you want is probably not a good idea, but trying to make a reasonable guess makes sense. I'd guess that doing something like a streamer with the same area as the planform area of the rocket wouldn't be unreasonable.

Well its pretty much the only thing one can do until you've built and flown the rocket.
 
Back
Top