The copter took off without losing control and flew directly to a height of over 30 meters before crashing. Please help investigate the cause of the crash. It caught fire after the crash, inexplicably. Thank you~~
00000091.zip (478.6 KB)
Comes with compressed log files
It looks like you didn’t follow the ArduPilot guidelines correctly (no calibration, no tuning) and even disabled ARMING_CHECK.
1 Like
This plane has just been repaired, and yes, I also noticed that the warning prompt has been turned off. However, can you confirm that it was the compass that caused the plane to fly uncontrollably to a height of 30 meters before falling off? I think posture control is completely wrong.
I now need to find out why even if I haven’t recalibrated the compass, it’s causing it to go completely out of control. Or it could be caused by other reasons.
Use this guide: TUNING_GUIDE_ArduCopter. Everything you need is in there.
2 Likes
I have encountered compass interference before, where the plane would sway or spin, but without experiencing altitude collapse, it flew directly to a height of over 30 meters. So I need to know if the altitude issue is caused by the compass, and I am also trying to turn off the compass. I have found that the compass is the least safe factor here.
I have encountered compass interference before, where the plane would sway or spin, but without experiencing altitude collapse, it flew directly to a height of over 30 meters. So I need to know if the altitude issue is caused by the compass, and I am also trying to turn off the compass. I have found that the compass is the least safe factor here.
This has nothing to do with a compass. You followed no configuration or tuning procedure(s), forced it to arm, and got a fairly predicable result.
1 Like
This drone was previously able to fly safely, but after maintenance, only one motor was replaced without any changes. After replacing the motor, it flew again and became what it is now.
This drone was previously able to fly safely, but after maintenance, only one motor was replaced without any changes. After replacing the motor, it flew again and became what it is now.
So now I need to find out the reason to avoid such a tragic incident from happening again
You could have mentioned that is was spinning around as it was flying. Due to a huge Yaw imbalance as seen here on the motor outputs. Perhaps you should have changed 2 motors.
Did that CUAX-X7 burn up in the crash too?
Yes, I also noticed the data issue with YAW, but I don’t know what caused it. Perhaps the motor damage is the most critical reason, please help me confirm, because I am sure that this drone was flying normally before, and then one of the arms was damaged, so we replaced the parts without making any changes to the flight control. So even if there is interference with the compass, it will not cause the current problem.
Because I often encounter compass interference and know his situation, it’s just like getting drunk or spinning.
Yes, I also noticed the data issue with YAW, but I don’t know what caused it. Perhaps the motor damage is the most critical reason, please help me confirm, because I am sure that this drone was flying normally before, and then one of the arms was damaged, so we replaced the parts without making any changes to the flight control. So even if there is interference with the compass, it will not cause the current problem.
Because I often encounter compass interference and know his situation, it’s just like getting drunk or spinning.
Yes, the entire plane is smoking and on fire, there are no complete parts left, and the X7PRO must also be damaged. It is a tragic event, and I need to find the root cause to prevent it from happening in the future.
Perhaps so. Or when the arm was replaced it was way out of level.
Well maybe, but we have heard this so many times before only to review a log and find it was not.
Different people have different opinions on “flying normally”.
@longzhixing post a .bin log of “flying normally” previous to the crash.
It is always better to correctly configure the vehicle, than trying to find out what was the issue that caused the fireball.
2 Likes
I have over 10 drones here that use this type of flight control, and our engineers have reference to the correct configuration plan you wrote. If there are problems with the installation configuration from the beginning, the failure rate will be higher. So far, there has been a minor issue with setting the minimum rotation speed. We have been using ArduPilot for over 3 years without any serious accidents. This is the most serious one, and of course it was not caused by the flight control settings that led to the fire. The fire was due to another hardware issue that we have identified.
So the cause of the malfunction is more important to me. As for how to configure the drone, even if we strictly configure it from scratch, it is still meaningless if we cannot avoid the same accident from happening.
For example, as mentioned by a friend above, if there is a mechanical problem with the motor. We found during our inspection that the drone caught fire was caused by the flight control power module rather than the battery. It is also possible that the power module did not work properly from the beginning, leading to control issues. These are all possible occurrences.
On the contrary, it is not important to us whether the drone is configured correctly, as we still have many aircraft of the same model in operation. Almost all use the same configuration method. If it was wrong from the beginning, which drones were still working should have malfunctioned earlier.
Based on the summary of our engineers, there are several possible causes of malfunctions (which can be supplemented if discovered):
The first warning prompt has been turned off
The second compass was interfered with or not recalibrated after repair, but the warning has been turned off.
The third RTK lock heading is in an abnormal state during takeoff, and the number of satellites is insufficient.
The fourth and most serious and likely problem is that the third or fourth motor may be stuck by a hard object, causing it to malfunction. (This may be the ultimate cause of the malfunction)
The fifth aircraft caught fire due to the power module catching fire, which involves whether the power module would cause the controller to crash if it did not work properly at the beginning. We are ready to replace all power modules with industrial grade modules to avoid any incidents.
We have experienced the first, second, and third faults before and know how to deal with them.
If it was just a motor replacement as described above, did you previously take off with ACC/Mag uncalibrated and ARM disabled?
I think you have to get all vehicles grounded and check first for the sake of safety.
I’m not blaming anything because when I fly, ARM is disabled, and I don’t check anything. However, this is obviously not a good habit. But I am very clear about my copter’s status, and I fly manually. If it’s in auto or navigation mode, then it’s still necessary to complete the automatic checklist before arming.
1 Like
Yes, thank you for the reminder. The warning for this aircraft was disabled separately because it was forcibly prohibited by the user during a takeoff on a ship due to the need to ignore and not find its return home point, and then it was not opened. Thank you.
Indeed, it was because the warning was turned off without any error prompts, and the maintenance colleagues took off for testing. But none of this is 100% the cause of the crash and fire.
@lida2003 lida2003
It’s NOT “arm disable” cause the issue.
I think you have to check C2/C1 motor and ESC.
UPDATE: Don’t use AltHold for untested drones. Just use stabilize mode, which will give your much more benifit when something is wrong.
Thank you for your reply. We are unable to check now as the plane has crashed and caught fire, and we can determine if it is a motor issue. From my understanding, as long as I do not use RPM feedback, the flight control system cannot detect the motor speed. Therefore, it is not necessarily true whether the RC output of the flight control system is the actual motor condition. For example, if the motor is really stuck, the C1 and C2 outputs in the flight control log may not be the actual motor condition, right. But it can be confirmed that there is already a problem with the flight control when outputting to motors C1 and C2.
C1/C2 motor or ESC is worth checking first. If you want to find the root cause, you need to inspect the components. If they are functional, testing can be conducted. If they are not working, you can examine other units from the same batch. You can refer to air crash investigation to determine whether it’s necessary to invest resources in this analysis.
Apparently, it’s NOT the correct data if the copter takes off vertically.