2 weeks ago, we crashed our quad while flying our annual mission in our notional parc.
We were in our second day of working and so far, the drone flew really well without any alert.
It was the third flight on the same battery pack with plenty of mah to complete the last flight. All flights are autonomous and the same as last year so we can monitor consumption and time flight between last year and this year.
The drone stopped fell in the middle of the flight and we had no time to try anything. We managed to get it back the day after.
The log file is 900MB, the drone stayed connected all night after the crash.
Try to look at ATT.roll and ATT.DesRoll etc to see if the copter was flying as how it should.
Have a look at the mag and imu to see if all sensors are consistent.
Have a look at RCIN to check whether there was strange input.
Compare CTUN.ThI and CTUN.ThO for the throttle.
This pretty much summarize the common problem checks.
In your picture, I notice that the BAT.Curr suddenly dropped. Maybe something turned off or malfunctioned?
So far, i can’t explain any failure in the pixhawk. We think, as you noticed, that we had a malfunction somewhere. We suspect our engine cutter from “galaxy” to have trigger during flight.
Our engine cutter is linked to a futaba T14sg with a 3 position switch programmed to switch on and off. I don’t know how but maybe we had an interference here.
I can provide more graph if you think to something that could identify the cause.
This drone wasn’t a perfect flyer but was flying very well for what we used it for. I never felt insecure with it.Now that it is destroyed, we cannot do any better tuning
The magnetic interference is more our concern as we were worried about the 50V configuration. The cable managment was made to protect the controler and its cable from the PDB. I’ll post a picture of the set up so you can give your opinion.
RCOUT are close to the power distribution board and has no shielding (not sure it needs some).
The black and yellow engine cutter is powered by a 3s external lipo (not on the picture). I tested it after the crash and it works as it should except that i could not test it properly as the motors are broken. But the signal from the T14 opens and shut the circuit well).
Our MAUCH systems doen’t warn us of anything weird in the batteries either.
I have only a small bit of experience with the HereLink, but we have noticed an interference issue when on the same platform as a futaba RX.
To provide a bit of context, we wanted to use the HereLink on an existing kit-build platform that was using futaba RX for manual control and RFD868 for telemetry (we are UK-based). Our initial step plan was to keep the control and telemetry the same and only use the HereLink for payload (gimbal + camera) control - to test the video link and sbus signals.
However, on ground-based range testing we notice the Fubata system go failsafe (in low power mode) less than 30 m away. This was also accompanied with the LED on the Fubata RX showing red occasionally - indicating a brief period of interference/no signal reception. Therefore, to avoid risk of interference, we bit the bullet and transferred everything to HereLink and performed as much ground-based testing as possible to build up commication link confidence before flying.
Evidence
This theory of the engine cutter triggering seems to be backed up in the log files (from what I can piece together based on the timestamps):
The spike in the throttle output suggests a loss of thrust (noted by @Alvin)
The drop in current (and recovery of voltage) suggests something stopped working and no continuous short (also noted by @Alvin)
The fact that the system stayed alive post crash suggests no major electrical failures (shorts, etc.)
Suggestions / Questions
My suggestion is to ground-test your HereLink and Futaba-controlled engine cutter to check for interference (look out for a red LED on the RX module). Try to keep the antennas in the same posisiton relative to each other for this test as they were in flight. Also check what the F/S settings of the Futaba were (and therefore if a F/S would cut the motors).
In the picture you supplied, it appears there are no antennas plugged into the HereLink (I understand this might be due to post crash conditions):
But it does make me question how your command and control links were set up, i.e. why HereLink and RFD900?
I hope this is of some help and might lead to a conclusion of the cause.
First of all, thank you for your feedback and time to help us in the understanding of that crash.
We worked on that FUTABA / HERELINK / RFDdesign configuration. With what you explained, there is for sure a link between those transmitters and somehow a way they interfere together.
The PWM signal from futaba must have been modified or disturbed by the signal of other transmitters or another signal somewhere. The Futaba failsafe was inactivated on all channels.
To answer your suggestions and questions:
We planned to set up the drone in the same configuration during the crash and analyse in a lab the different frequencies. We’ll let the configuration running for a long period of time to find if the engine cutter switches on.
The herelink antenna have been removed on the recovery in the forest. We had to dismantle the drone completly to be able to climb back to the base camp.
We have so many transmitters because we thought it was comfort to monitor the flight with the RFD900 on a laptop while we managed flights with the herelink. We are two operators to conduct thoses type of missions.
The futaba was dedicated to the engine cutter which is a mandatory feature to comply with national law.
We have a last transmitters which is a remote identification beacon, here also to comply with law.
It’s too much emissions and we certainly made mistakes here.
Mistakes help us build our experience, we are already working on the next platform
We’ll wait to confirm the reasons of that crash before we start flying thought !!
Thanks, i’ll come back here to give feedback on transmissions analysis.
)