I have a switch on my transmitter set to RC6 option 22. Upon a high PWM signal from throwing the switch the Cube Orange+ makes three loud beeps, displays that the chute has released on the HUD and throws the servo (Servo9, aux 1 position on the servo rail) to the release chute position value of 1100 which would release my chute. The motor does not stop when I have it in stabilize mode or FBWA mode nor any other mode I have tried.
I am also unable to trigger chute release at all while in auto mode. I followed the instructions posted and was unable to test the automatic release of the chute (which is fine for me as I only ever want it to release by activating the switch on my transmitter).
What I need:
I need the motor to disarm itself when the chute release command is sent.
I would also like the ability to make a Lua Script that would also disable the motor AND release the chute, I have only been able to find this for a Lua Script regarding chute release.
.
Quick and dirty test in SITL indicates that motor should stop in automatic throttle modes (at least if pilot throttle is down), please post a log file demonstrating the issue.
Make sure you have CHUTE_ENABLE,1 set. It’s still set to 0 in that parameter file you posted. RC6_OPTION,22 won’t work until you have the rest of the parachute configuration set.
You are all correct, I found the dev blog section showing this problem. They did do a slight rewrite but the code does not appear to be working as the instructions say it does. So I’ll just have to kill throttle manually via my transmitter as part of the chute deploy procedure
Hi, how are you? I have the same problem, the parachute works in any mode, but it does not stop the throttle. And what is the configuration? In case a problem occurs and the plane starts to fall.
Can you also add an option to have a delay BEFORE popping the chute that comes AFTER the motor kill command? I’d like the motor to reduce RPM for like, 1-2 seconds? maybe in that time frame…
You might be getting to the point where you need to customize chute behavior via Lua script. I’m not sure your last suggestion is one that we need built into the firmware itself (likely very limited use cases where we want to be disarmed in flight without a chute, even for a few seconds).
I might even suggest the opposite mentality, where we offer a check for chute deployment + deceleration before disarming (as is done on some impressively large commercial systems with which I work).
Well there ya go! We already have it. I’ll eat my words regarding the level of customization for which you’ve asked.
I do wonder if we ought to have a bit in CHUTE_OPTIONS to enable a check for decel before disarm, as well. It’s quite a bit of complexity, so I understand if no dev wants to undertake such a feature. It would allow for a “go around” type mentality (without rearming) in the event of a chute failure. It’s also likely possible to script this behavior, though we may need to add some chute bindings.
Unfortunately chute code is very not beginner friendly.
The biggest hurdle to adding chute failure detection is that detection has to be extremely reliable, otherwise you may end up with a tangled mess and validating any worthy set-up will be potentially quite expensive.
Detection also has to be quick as UAVs often operate low to the ground and by the time we are sure chute hasn’t deployed it may be safer to hit the ground with motors stopped than to risk having spun up propellers.
I can see a large scale aircraft having large and easily detectable deceleration. The weights I’m working with are around 3-4 pounds with the bodies being aerodynamic in nature. I can say this, in my case the “bitter end” fall rate without a parachute is about 50 ft/s, with parachute it is 25 ft/s. It’s the only data point I have at the moment.
I would be satisfied with this sequence:
Pilot in Charge throws a switch on hand held transmitter then
Aircraft first commands zero throttle (as opposed to any other command such as 0 PWM or any other such method) then
Time delay then
A servo is commanded to move via a selected channel (this servo would have to reliably release the parachute which is on the designer to accomplish and not the code)
I don’t think I need a way to detect that the parachute has actually deployed, at least not yet.
For automatic chute deployment that’s more tricky but here is a stab at it:
Maximum airspeed is exceed (uncommanded nose dives are often part of a need to use a parachute system and you have about 3 seconds before it is all over when you are at 400ft, I’ve seen 83mph+ on a system that cruises at 32mph)
A Geo Fence parameter is violated (typically a floor or wall) for a given period of time
Time after loss of GCS heartbeat (I would not trust this much as people can accidentally stand in front of your antenna even though you can see and operate the drone safely)
Roll limits are grotesquely exceeded (often happens when you’ve messed up a parameter setting or with some sort of mechanical failure of a flight control surface)