OpenRocket 22 - How to model parachute ejection with motors in pods

[vncnt]

My son and I have build several model rocket kits and several rockets from Mike Westerfield's book and now he wants to build a 3-motor cluster rocket. We are learning how to use OpenRocket, but are having trouble setting the parachute ejection.

I attached the current design that has the parachute in the main body tube and it will be deployed when the center motor ejection charge fires.

However, there are two additional motors friction fit into smaller "booster" tubes that are permanently attached to the main body tube. We used the new OpenRocket 22 Beta pod feature for the side tubes and the side tube nose cones are permanently attached. The idea was for the side motors to eject themselves at burn out (like in the Nicomachus helicopter recovery rocket from Mike's book) and the center motor has a retaining clip to stay in place and eject the parachute.

We can't figure out how to simulate this in OpenRocket. We can't figure out how to model ejecting spent motor casing. But even if we add a retainer clip and vent the slide boosters, the simulation shows two separate Recovery Device Deployments, one I'm assuming from the side motors and one from the center motor.

• Is there a way to decouple the side motors from the Recovery Device Deployment?
• Is there a way to model ejecting spent motor casings?
• Any advice on improving this design?

 

[BigMacDaddy]

Never mind -- re-read post...

 

[Charles_McG]

To my knowledge, there’s no way to simulate ejecting the case. OpenRocket isn’t a full physics sandbox - it’s running specific simplified calculations and has a certain built in paradigm of what rocket parts do.

For recovery, look at the motor configuration tab - there’s a recovery sub tab. You should be able to control which motors tie to deployment, or override it all together.

 

[vncnt]

To my knowledge, there’s no way to simulate ejecting the case. OpenRocket isn’t a full physics sandbox - it’s running specific simplified calculations and has a certain built in paradigm of what rocket parts do.

For recovery, look at the motor configuration tab - there’s a recovery sub tab. You should be able to control which motors tie to deployment, or override it all together.

Thanks @Charles_McG for replying. On the recovery sub tab, the "Select Deployment" seems to apply to all motors in the configuration. @BigMacDaddy originally suggested using stages to separate the recovery, but changed his mind.

Having Deployment tied to specific motors would enable us to model the case where we use clips to hold the side motors in and vent the burn-through. Will keep experimenting to see if there is a way to set it up in OpenRocket.

 

[neil_w]

I don't see a way to do it. I will query the dev team.

If there is no way to do it, I'll submit a feature request. If it's possible but incredibly unobvious, I'll submit a bug.

 

[Charles_McG]

Come to think of it - other than getting the deployment time correct, what’s wrong with how OpenRocket sims it? The weight change when the casings are ejected won’t be accounted for - but are they ejected before the main burnout? Difference in coast due to less momentum? Difference in descent rate under chute?

 

[neil_w]

Come to think of it - other than getting the deployment time correct, what’s wrong with how OpenRocket sims it? The weight change when the casings are ejected won’t be accounted for - but are they ejected before the main burnout? Difference in coast due to less momentum? Difference in descent rate under chute?

I think the motor casing ejection is really a minor issue, although it would probably be a nice-to-have option in OR.

Getting proper deployment timing is the big question here.

 

[Charles_McG]

I think the motor casing ejection is really a minor issue, although it would probably be a nice-to-have option in OR.

Getting proper deployment timing is the big question here.

I had to go and look at the options IRL. I have all my sims set to 'apogee' and then use recommended/optimum delay to adjust the delay, using the motor for backup.

For the OP's case, I'd manually calculate the delay for the launch+n secs as burn time + delay. I kinda thought there was a 'last ejection charge of stage' along with 'first ejection charge of stage' - but there isn't.

 

[neil_w]

I had to go and look at the options IRL. I have all my sims set to 'apogee' and then use recommended/optimum delay to adjust the delay, using the motor for backup.

For the OP's case, I'd manually calculate the delay for the launch+n secs as burn time + delay. I kinda thought there was a 'last ejection charge of stage' along with 'first ejection charge of stage' - but there isn't.

There are certainly ways to hack it to work, but it would certainly be preferable (always) for the program to allow you to directly specify the way the actual rocket would work... in this case, with deployment attached to a specific motor. Admittedly there are a very large number of different ways deployment can be set up, and maybe it's not practical (yet) to try to cover them all, but we should be able to do better with this particular configuration, since it is a fairly straightforward way to use motors in pods.

 

[lakeroadster]

My son and I have build several model rocket kits and several rockets from Mike Westerfield's book and now he wants to build a 3-motor cluster rocket. We are learning how to use OpenRocket, but are having trouble setting the parachute ejection.

I attached the current design that has the parachute in the main body tube and it will be deployed when the center motor ejection charge fires.

However, there are two additional motors friction fit into smaller "booster" tubes that are permanently attached to the main body tube. We used the new OpenRocket 22 Beta pod feature for the side tubes and the side tube nose cones are permanently attached. The idea was for the side motors to eject themselves at burn out (like in the Nicomachus helicopter recovery rocket from Mike's book) and the center motor has a retaining clip to stay in place and eject the parachute.

We can't figure out how to simulate this in OpenRocket. We can't figure out how to model ejecting spent motor casing. But even if we add a retainer clip and vent the slide boosters, the simulation shows two separate Recovery Device Deployments, one I'm assuming from the side motors and one from the center motor.

• Is there a way to decouple the side motors from the Recovery Device Deployment?
• Is there a way to model ejecting spent motor casings?
• Any advice on improving this design?

Run the Open Rocket simulation, as is, for apogee. Close enough.

Use this calc for simulating the chute recovery. Delete the ejected motor casings weight when you input the rocket weight.

 

[JoePfeiffer]

• Is there a way to decouple the side motors from the Recovery Device Deployment?

When you are selecting your motor in the motor selection dialog, type the word "None" (without the quotes) in the ejection delay box. When you press "OK", the motor should appear with a "-P" (for Plugged) in the configuration. An extremely clunky bit of user interface, but it works.

• Is there a way to model ejecting spent motor casings?

Not exactly. If you create another configuration with no motors in the pods, it'll model the descent rate with motors ejected.

This is stuff we need to work on.... though actually simulating the motor ejection itself would be messy. We'd have to get some idea of how forcefully the motor is ejected to model the impulse the rocket gets from it -- of course, we don't model the messy details of ejection charges at all, either. The rocket is together, and then instantaneously it's floating under an inflated parachute. All the forces involved in separation, shock cords, etc aren't considered.

I'll mention one other thing before somebody else does: there is a commonly held belief that motor ejection is against the safety code. This is not true. It's not allowed in competition, but there's nothing about it in the safety codes.

 

[Charles_McG]

I'll mention one other thing before somebody else does: there is a commonly held belief that motor ejection is against the safety code. This is not true. It's not allowed in competition, but there's nothing about it in the safety codes.

It can also be disallowed by a club/landowner. Sometimes just by current fire conditions, as with sparky motors.

 

[vncnt]

There are certainly ways to hack it to work, but it would certainly be preferable (always) for the program to allow you to directly specify the way the actual rocket would work... in this case, with deployment attached to a specific motor. Admittedly there are a very large number of different ways deployment can be set up, and maybe it's not practical (yet) to try to cover them all, but we should be able to do better with this particular configuration, since it is a fairly straightforward way to use motors in pods.

I'm much better at developing software than modeling rockets! You've got me thinking about how there are many events throughout a flight and for ultimate flexibility it would be great to allow users to create a DAG (directed acyclic graph) of events. For example here, I would link "ignition" to all three motors, but only link the center motor "ejection" event to the parachute. You could have timer events, altitude events, apogee events, and others.

 

[vncnt]

When you are selecting your motor in the motor selection dialog, type the word "None" (without the quotes) in the ejection delay box. When you press "OK", the motor should appear with a "-P" (for Plugged) in the configuration. An extremely clunky bit of user interface, but it works.

Not exactly. If you create another configuration with no motors in the pods, it'll model the descent rate with motors ejected.

This is stuff we need to work on.... though actually simulating the motor ejection itself would be messy. We'd have to get some idea of how forcefully the motor is ejected to model the impulse the rocket gets from it -- of course, we don't model the messy details of ejection charges at all, either. The rocket is together, and then instantaneously it's floating under an inflated parachute. All the forces involved in separation, shock cords, etc aren't considered.

I'll mention one other thing before somebody else does: there is a commonly held belief that motor ejection is against the safety code. This is not true. It's not allowed in competition, but there's nothing about it in the safety codes.

Thanks @JoePfeiffer! Plugging the pod motors did the trick - only one parachute deployment.