Drone ignites Parachute and stops motors while hoovering?

Yes.The log ends at 36m altitude.

I don’t fully understand this power failure conclusion and see a change to learn something. I’m still learning how to read logs and form causal connections.

What I found today is:

  • Line 0 First logged record
  • Line 37055 Baro has last record 35.73m
  • Line 37059 Vcc has last record
  • Line 37066 Parachute is released
  • Line 37070 Disarm
  • Line 37071 Last record of log

So, copter flew (logged) 85.386 seconds until logging ended after parachute eject. I still don’t find where you see power issue occurred.

I’d not rely on the minutae of the last lines of the log written for accurate portrayal of the facts in a power loss event but in the graphical interface it clearly shows a slight delay after the logging has stopped and then the parachute deploys.I have no idea how it normally deploys nor how it triggers in the event of a power failure.I just went on the graphical representation in Mission Planner.

However.When a log simply stops at altitude it’s a sign that the power has failed.It can be what’s termed a brown out,where the flight controller loses power,or it can be a total failure of the battery to get any power to any systems.I can’t tell which one happened here but from the description of it stopping motors and descending on the parachute is borne out in the graph I posted.Which means that the parachute did it’s job perfectly.

If it were my copter I’d first be looking at the power train very closely and maybe even aggressively.Could be tricky to find.

This was my last failure.A factory error on a buck regulator.

Before with 3.2 firmware logging did end after parachute release. Randy confirmed this when we made parachute testing on time when this parachute release function was developed for Arducopter. It looks this is the case still.

In this particular case I don’t know what did eject parachute but my interpretation of logs is that autopilot did controlled shut down of logging after parachute release. All other values of log I looked seems ok for me and do not indicate any fatal problem.

End of log is weird because Data_Land_Complete and Data_Land_Complete_Maybe are right after “Released”. It’s kind of impossible to land that quickly.

Typically parachute mechanics hold their position when power is lost. Exception is when parachute controller or servo etc. is connected to RC - receiver directly and RC - receiver does eject on FailSafe state assuming receiver has still power to make FailSafe procedures.

Ah see I didn’t know that.And I don’t dig that deep yet.It puts a different light on it I guess.It’s how we learn to interpret logs.Slowly and by trial and error.

So we really need a lot more details about the parachute release mechanisms on this copter then ? And I’ll have to stop making assumptions based on pretty pictures.:grinning:


1 Like

Yeah assumptions are not correct way to proceed. Ruling out possible causes (which did not cause the problem) is common approach on failure research and is systematic method.

Jan, did you have manual eject in use? If yes, which channel?

Manual eject is wired to the rc receiver directly ( But it is also cannel 7 on the pixhawk so that the motors stop spinning when the parachute is fired manualy )
But then you would not se parachute in the LOG… and channel 7 would be nearly 2000 on the graph…
It’s also connected to RC9 ( AUX 1 output ) on the pixhawk.

Did I understand correctly:

  • CH7 is connected directly to parachute from receiver pins?
  • CH7 is also connected to pixhawk from SBUS and selected as manual eject on Mission Planner?
  • You have also AUX 1 connected to parachute?

If all answers are YES and you did use manual eject, we’d see it on logs. Now CH7 shows straight line 980. Which kind of parachute system you have?

Thanks Henri,

But the signal is below 1000.
For a manual eject i would need 2000 ( signal high )
It is a tree way switch on the remote and it’s not changing it’s value
during flight…
Parachute system is a Galaxy GBS 10/50

This is what is writen in the docs…
I have checked the values and for me it makes no sence to fire the parachute…

The motors are armed
The vehicle is not “landed” (the vehicle will consider itself landed if the output throttle is less than 25%, the motors have hit their lower limit, the vehicle is not rotating by more than 20deg/sec and the pilot is not requesting a climb. All this must be true for 1 second for the vehicle to consider itself landed)
The vehicle is not in FLIP or ACRO flight mode
the roll and/or pitch angle of the vehicle is 20 degrees off from the target lean angle
the barometer shows the vehicle is not climbing
the vehicle is above the CHUTE_ALT_MIN altitude

Jan.I’m trying to figure it out after my jumped gun and the line above struck me as it’s channel 9 in that bounces when you switch your OSD.It moves between 1000 and 1500 quickly.Admittedly ch9 out doesn’t respond.And in the parameters I noticed this

PARM, 227131220, CHUTE_SERVO_ON, 1300
PARM, 227131244, CHUTE_SERVO_OFF, 1100

It wasn’t triggered by the crash check for sure.I just wondered if this was anything to do with it.

Now these things doesn’t make sense. I list facts below. Some questions are there listed too and perhaps someone has change to find solid answers.

What we know for sure:

  • Chute enabled = 1 (in use)

  • Chute type = 10 (servo)

  • Chute_servo_ON = 1300

  • Chute_servo_off = 1100

  • Chute_alt_min = 10

  • Chute_delay_ms = 500

  • CH 7 setting on Mission Planner WHAT WAS THIS

  • CH 8 setting on Mission Planner WHAT WAS THIS

  • Copter was armed

  • Copter was not landed

  • Copter was above 10m

  • Copter was not FLIP or ACRO

  • Vehicle was not climbing

  • How about this, (does someone find SOLID info from LOG), The roll and/or pitch angle of the vehicle is 20 degrees off from the target lean angle

In general parachute should have not fired in first place ever from Pixhawk command, ever. 1300us is not enough based on info we received from Jan. Do you Jan have user manual and connection instructions for this recovery system? It would help to understand better what happened.

CH9 “clatter” is timely interestingly right before eject. What connection from CH9 to AUX 1 can be, I don’t know if any.

Again thank you guys for helping me.
Regarding you questions Henri:

  • CH 8 setting on Mission Planner WHAT WAS THIS ( Motor Emergency Stop / Switch on remote for emergencys )
  • CH 7 setting on Mission Planner WHAT WAS THIS ( Motor Emergency Stop / to stop motors when the parachute
    is fired manualy. )
    I have a little test divice ( Training Pyro ) from Galaxy GBS and i tested all the inputs a few times.
    I tested manual firing and and automatic release.

The ‘‘clatter’’ on channel 9 was me, switching the switch fast to recover the OSD…

I have attachted the manual from Galaxy that i have followed…


But Jan what about this bit.The PWM for channel 9 in moved rapidly between 1000 and 1500 as you tried to get the OSD back and if the parachute is physically hooked up to that channel ? The on and off values for the chute servo fall in that range. It doesn’t explain that channel 9 out had no value change but it’s the closest I’ve come to seeing something that may relate to the deployment.Maybe worth a bench test to try to replicate the action.

I have allready tried this on the bench yesterdy evening.
The switching is not affecting the parachute and when
i manualy deploy the parachute i have no MAV link message ‘‘Parachute’’.

I didn’t see HUD message “parachute” everytime either last time I tried. 3.5.3 if I remember correctly, last FW two weeks ago anyway.
I tried manual and automatic eject.

I’m out of ideas in this.Hopefully someone brings new steam and we sort this out eventually. Where my research ended for now is:

  • copter didn’t have anything wrong what it comes to flight
  • Pixhawk parameters (1300us High) was not enough to eject in first place
  • CH9 clatter is bugging me but from outside of code it is not possible to say if it can affect AUX1 somehow
  • This particular parachute seems quite special what it comes to connections and functions which means it is complex / special in code too. I would research if there is any change that parachute itself commands Pixhawk to shut motors down when parachute controller decides or is commanded to ignite what ever reason

I noticed there is a parameter which allows logging after disarm. However logfiles will be large which is not normally needed and wanted. After parachute release and crash it might help investigations if logged only then after disarm:

That may be worth doing for testing.But I agree,this is a tricky one.