Hello. I ask the community for help in finding the cause of the crash of the drone.
Ardupilot v3.5.4 - exactly 3.5.4.
This was the second flight that day. The flight was carried out in automatic mode.
The first flight was made at a height of 3.5 meters. The UAV uses lidar.
Then the altitude was changed to 2.5 and the mission was left the same.
Using the resource https://plot.ardupilot.org I recreated the flight.
If you choose the parameter Trajectory Source = GPS, then the flight looks exactly as it was. I attach an entry https://youtu.be/PAij8C0vMaU
If you select the parameter Trajectory Source = POS, then the flight does not correspond to reality, it is very interesting why, his entry looks like this https://youtu.be/N_pAdvuMS1Y
The problem is deeply buried. At the moment, the reason has not been found out. I decided to follow the path of exclusion.
As a working example, I cite a normal flight log half an hour before the fall.
On the example of the operation of the barometer sensor and GPS, it can be seen that the equipment was operating continuously without failures. In the event of a power outage, gaps in the graph would be visible.
Then I began to find interesting, ambiguous points.
Fall time - 7min 32.9 sec.
What worries me more is that there are significant discrepancies in the readings of the current and desired (DES) states on the roll axis (Roll) and more significantly on the pitch axis (Pitch). In the normal flight log there is a discrepancy, for example, between ATT.Roll and ATT.
DesRoll is minimal and exceeds 5 units only when cornering. Not sure how to properly interpret these readings. If we assume that the cause is mechanical damage or degradation, then as I understand it, the system would have to rebuild and respond by increasing the signals to the RCOU * motor. But there is no such reaction.
Mission Planner shows data from GPS, GPS2 and POS. I don’t know what data is used to build the POS trajectory. Can someone tell me where they come from? The UAV was flying along the GPS trajectory. The normal flight log shows that these trajectories must match …
Mechanical failure of some description compromised lack of tuning.
Just before the fall I notice yaw is being input from the RC
There is a slight yaw discrepancy right from the start of the flight with roll/pitch DES/Actual not tracking that well either.
Your parameters appear to still be at defaults.
Has this copter been autotuned?
The RC3 has a sudden input 451sec which has an effect on DES yaw but actual yaw moves in the opposite direction.
The RC3 input goes the opposite way and that when the copter loses it and falls.
If it wasn’t just the default parameters and lack of an adequate tune, my bet is an arm or a mount came loose and a motor turned.
Thanks for the answer. As far as I know from the instructions, vibrations up to 30 are considered acceptable. Fall time is approximately 7m32.9s. More precisely, it was not even a fall, but a smooth decline. CTUN.ThO grows rapidly only after the moment it touches the ground.
15/15/30.
May be, but when CTUN.ThO=1 BARO.Alt=1.8, CTUN.Alt=5.14 and CTUN.DAlt=6.6, or that it “thinks”. It is questionable and dangerous to apply acceleration with high vibrations.
The fall occurred at 7m32.9. The place where ThO began to grow sharply, I would regard as the beginning of touching the ground. The UAV uses lidar. Lidar worked correctly. According to the definition of the DAlt parameter, in this case it should not be used.
DAlt
The Desired Altitude while in AltHold, Loiter, RTL or Auto flight modes.
It is influenced by EKF origin, which in 3.5.X is corrected by GPS altitude. This is behavior is turned off in 3.6.X and can be turned on with EKF_OGN_HGT_MASK.
As for vibrations, in normal flight the level does not exceed 7 units. In flight with a drop, vibrations reached 14 units.
Double-sided silicone tape is used as a damper, this is how its analog looks like: https://aliexpress.ru/item/4000185314762.html
Thanks for the answer. Yes, the PID parameters have their default values. In test flights, I liked the behavior of the UAV very much and did not see the point in reconfiguring the parameters. There was no autotune.
I will correct you. at 451s there is an increase in the RC4 channel - this is the yaw channel. Yes, this is very similar to the truth, but I have a question.
Why didn’t the UAV correct its deflection by adding power to the motors? As you can see from the RCOU.C1-C6, the motors still had a significant power reserve.
