The only component that seems to make a difference is the Herelink RC, which is the common element to all crashes. However, there seems not to be any problem between the channels and the motors.
We have looked into the logs as best as we can. But we haven’t reached any conclusion with the setup that caused the crash. If anyone could have a look at the logs and share your ideas it would be incredibly useful.
All RCs were calibrated before flights. In the specific case of the Herelink (in the native app and in the QGC app).
Regarding the log analyzes, the yaw input seems to be only on the takeoff action, and in some cases (for example log1) it started to have yaw rotation before the RC input. Also, please note that it kept incrementally increasing the spin speed, even after the yaw effect. To reduce some piloting bias, the last crash test (log7) was done by a different pilot, and the outcomes was the same
Flight 4 looked like a controlled descent to me, I could not find a crash there.
Flight 6 looked reasonable, considering you still need to do a bit of tuning and defaults are still in place.
Compass 2 and 3 are showing significant interference from throttle/current draw, but Compass 1 is good. Set these:
COMPASS_USE2,0
COMPASS_USE3,0
Flight 7 looked like motor mounts or arms radically twisted - clockwise motors 1, 3 and 6 are working almost to maximum to counteract a physical yaw issue caused by at least one of the 2, 4 or 5 motors.
Flight 1, 2 and 3 all have the same issue as flight 7.
If you arms are removable or folding then there’s an issue with the mechanism, or you are putting the wrong arms in the wrong positions. Possibly even one or more of the motors are spinning in the wrong direction - but I’d expect that to show in every flight equally.
Once you fix the physical yaw bias, set some initial parameters correctly and then move on to Autotune.
While connected to MissionPlanner, press Alt A on the keyboard and step through that dialog about prop size and battery cells. Accept all that it offers.
If you’ve got anything bigger than a race quad I highly recommend you set these too:
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
FENCE_ENABLE,1
FENCE_TYPE,3
Here’s a spreadsheet of the initial parameters (same as provided by the MP plug-in) if you prefer to see how they change or are calculated
In this case I don’t think Herelink make your UAV spin. It could be your FrSky flights were lucky enough to have avoided the problem every time. You may try to fly more with your FrSky setup.
When the “actual” leads the “desired” that means it’s a physical issue not caused by “commanded” RC Inputs or inputs from another source.
The Ardupilot software keeps the “desired” values within a range of the “actual” to avoid PID terms building up to undesirable levels.
I think you’d be better off settling on the most desirable configuration and sorting it out. I understand the reason to swap parts to identify the faults and causes.
Best to stick to one configuration and the .bin logs will tell the story.
We backed to using FrSky because we have over 500 flights with that RC. However, when looking at the logs, we don’t understand what the RC might be causing such issues.
Thanks alot for your thorough analyzes. The UAV in question is a Hexacopter X with 18’ props. However, it’s a certified aircraft with those default params. Bellow you can find some pics of the UAV.
We’ve pursued with further testing, and we had additional spin crash. However we now believe that it might be correlated with the Herelink RC controller calibration. When swapping the air unit from UAV without re-calibration, it always crashes the UAV.
I’d like to point out Certified doesn’t always mean Correct
In the same way that following laws doesn’t always mean safe, and being safe doesn’t always mean you are following the laws.
I would still highly recommend setting these for safety, and testing them to observe the behaviour and become familiar with it:
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
FENCE_ENABLE,1
FENCE_TYPE,3
