Hello @ all
Today my drone ignited the parachute and stopped the motors while it was hoovering
a few meters off ground. I do not understand what is the reason for this…
In the Auto Analysis i get a warning for motor 4… Maybe that triggered the chute ?
Can please somebody have a look at LOG that i have attachted ??
Thanks in advance
Kind regards: Jan
Here are my two cents.
Altitude was not decreasing:
Roll axis was quite far from Desired Roll right before eject:
One motor were operating closer to upper limit than others:
Thank you Henri for helping me.
On channel 9 i have a switch for the video feed. I can switch between FLIR and HD camera.
Both are connected to an OSD that sometimes goes out and when i toggle the switch a few
times the OSD comes back. So i think it’s not related.
The desired roll and altitude you have mentioned is, i think, because of bad PID tuning…
I still can’t figure out why the autopilot ignited the parachute…
From the log the chute triggered after the power was switched off.It even shows the 500ms delay.There was no trigger signal sent while the FC was booted so it looks like a mid air power failure leading to the correct deployment of the parachute when the PWM value drops below 1100.Congratulations.Your parachute works as designed.You were at 36m altitude.
Now you just need to find the power failure.
Motor 4 does show a bit low at times.Maybe an accelerometer level thing or possibly the place to start looking for the power failure.
Hy Jagger,
Thank you for helping me.
I will investigate and report.
Jagger, earlier a long time (fw 3.2) ago Pixhawk stopped logging at the event of parachute. If logging ends still like before, is your analyze conclusion still power failure?
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:
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.
Thanks.
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:
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 altitudeJan.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:
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…
https://www.dropbox.com/s/g462mynunwb2g72/Electronic_BASIC.pdf?dl=0
