Screenshot above shows that the motors started with no oscillations or no motor vibration. Although it shows that the right motor (M1) maxed out (saturated) right before the hex crashed, I didn’t get any Thrust Loss error. This caused the hex to make a right roll and crash to the ground due to unbalanced propulsion. Any thoughts or advice?
Your vibration levels went suddenly very high - about 3 times more than recommended max. levels on the x-axis. This was also in line with sudden increase in current and as a consequence a drop in voltage.
Loose motor mount, damaged / cracked prop, loose arm?
I can only give you rough idea others on here are much better in analysing logs.
But those high vibration levels almost certainly impacted on FC and as such no surprise it couldn’t recover as it would do if it was just a motor or ESC failure.
Do you mean that the high vibration levels impacted the FC, which prevented it from recovering the hex? I don’t believe there were any loose motor mounts, damaged/loose props, or loose arms since these were all checked for before the flight. Though, the RCOU graph above shows that Motor1 (right motor) got saturated, which could mean loose props, but the corresponding props weren’t loose when checked after the crash. Could there be any other reasons such as untuned system or taking-off on AltHold?
I can see in the data that pitch and roll only diverged after the RCOUT.C6 Motor1 lost thrust (possibly desync) and it looks like RCOUT.C1 Motor5 was also starting to suffer the same fate.
If it was desync it wont show as a physical issue like loose or broken prop.
It might be that you need to add more capacitance right at the ESC power input, as close to the ESC circuit board as possible or on the ESC circuit board. More is better!
It wont hurt to add a couple of capacitors to your power distribution too, if you think they might be needed.
Use only Low ESR caps.
Also see this about long wiring runs, you might need to so some additional work with the power wires (twisting them) and the signal wires too.
I see you’ve got motors plugged into non-standard servo outputs - which is fine and that’s a good way to keep wiring tidy. Use the MissionPlanner motor test and do “All in sequence” to observe each motor is activated in turn from front/right all the way around the circumference to front/left - in the A/B/C/D/E/F order ignoring the servo main-out connector numbering.
Also observe the correct spin of each motor.
Just so you are aware, the GPS positions and IMU positions all differ a lot
Best to set FENCE_ENABLE,1 and wait for Home to be set, then you can arm. You did the correct thing by staying in Stabilise and AltHold for testing. If you tried Loiter it might have been denied (and some people miss the “denied” message and assume they are in Loiter) or Loiter would have tried to follow the wandering GPS position.
Also set INS_LOG_BAT_MASK,7
Once you get to a successful takeoff and can hover and test pitch and roll, send that .bin log.
Thanks, @xfacta, for your suggestions. The long wiring runs are super helpful.
The ESCs were calibrated and set up several times via ESC calibration under the Mandatory Setup tool with the default PWM min and max, 1000 and 2000, respectively. Thinking about your analysis, I somewhat agree that the problem could be due to desync. I just learned that DJI fixes their PWM range between 1120 us – 1920 us for their motors including the 4114 Pro (confirmed).
Each S900 ESC already comes with an ECS circuit that has two ultra-low ESR caps: Rubycon 50V 220uf ZLH. However, the S900 power distribution board doesn’t have one. I might add one at the power input if required.
Regarding the wire twisting, the power and ESCs wires from the ECS/Motor module to the power distribution board are already enclosed by shrinkable tubes, so I don’t see if they are twisted. I believe they are since the wires come out spiral look. I will need to twist my signal wires then.
I will let you know how my next test goes, but it might take longer to replace the damaged parts.