Hi everyone,
hope I am in the right category. I would like to collect your assessment if this crash might relate to a spurious roll motor output or a valid reaction of the controller software due to an external event, e.g., mechanical or electrical issue with the ESCs or roll motors, etc.
The frame class is a custom variant F35B, based on Eric Maglios work, the HW is a MatekF765-Wing controller and it features a 3BSM nozzle. The test frame is without real wings and should proof stability in the QLOITER, QHOVER and QSTABILZE modes first. The frame consists of a front (fixed) and rear 90mm EDF (rear is tiltable) and two fixed roll motors at the end of an extension bar to the right and left of the frame.
The fatal crash last Friday which shattered the complete test frame was test run #5. Earlier trials showed strong oscillations along the roll axis and a weak yaw control, landings were hard but did only break a bit of the chassis. I reduced roll PID values by 50% and modified a few yaw values. Flight #4 showed some improvement on yaw authority but the frame started to roll again and I did a quick landing.
I reduced the roll PID values again by 50% and decided to load an automated tuning method, the Quicktune LUA script (https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Scripting/applets/VTOL-quicktune.lua) and prepared my transmitter accordingly. For the fatal flight winds were calm and I raised the throttle, the frame took off in QLOITER and I did not touch yaw, roll or elevator sticks during the entire flight. Then I switched the 3-way to middle position after a few seconds and reduced throttle since the frame climbed some meters. I could read “Tuning: starting tune” in MP. The frame also started to wiggle a bit as I expected, but all of a sudden, the frame rolled sidewards violently and did not level back. The frame felt out of the sky and shattered completely on the street.
A few things I can observe on the attached logs:
- Based on the DF log and the text message in MP (see attached 00000008.txt) the script probably never run, tuning any PID parameters.
- DF log 00000008.bin shows the output to the roll motors RCOU C5 (right) and RCOU C6 (left). At 18:10:35 I assume the violent roll movement occurred and at 18:10:37 the impact. When I add the IMU graphs to C5 and C6 this gives me evidence at least for the impact.
- Comparing 00000008.txt with 00000008.bin and assuming the time stamps are identical there is message “06.10.2023 18:10:35 : EKF3 lane switch 0” in 00000008.txt.
00000008.BIN (944 KB)
00000008.txt (44.0 KB)
So, the questions I have are (before considering to rebuild the frame):
- Is the roll output at 18:10:35 a reaction to an external event or the root cause? I cannot tell for sure when looking on other parameters (IMU, etc.).
- Why does the roll output not remain for a longer time to compensate the roll, since the frame did not level back? I would assume a longer pulse of C5 and C6.
- Is the text message “06.10.2023 18:10:35 : EKF3 lane switch 0” an indication for a control failure leading to an invalid roll output?