Motor not shutting off when parachute deployment is commanded

Running 4.5.3 arduplane.

Used setup instructions posted here.

Parameter file is here:
SH 6-3-2024.param (20.6 KB)

Current behavior:

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:

  1. I need the motor to disarm itself when the chute release command is sent.
  2. 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.

1 Like

https://ardupilot.org/plane/docs/common-parachute.html#setup-through-the-mission-planner

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.

In my experience the chute switch manipulates the CHUTE_ENABLE, it is 0 if chute is disabled or locked out.

Yes, that’s right, there is some silliness there. Now you say that I remember running into that when using the 3-pos switch on a quad.

IMHO the chute code deserves a rewrite.

1 Like

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 :frowning:

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.

for 4.6 disarm is optional on chute release, in CHUTE_OPTIONS

1 Like

TY!!

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).

1 Like

IIRC it is how CHUTE_DELAY_MS should work. I would recommend reviewing all CHUTE_* parameters in the documentation

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:

  1. Pilot in Charge throws a switch on hand held transmitter then
  2. Aircraft first commands zero throttle (as opposed to any other command such as 0 PWM or any other such method) then
  3. Time delay then
  4. 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:

  1. 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)
  2. A Geo Fence parameter is violated (typically a floor or wall) for a given period of time
  3. 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)
  4. 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)