I have a quadcopter with KV380 motors and 1604 props. When i arm it, arbitrary props (between 1 and 2, seldom 3) refuse to spin up. You can usually see them doing a short jump, sometimes in the wrong direction, as if there was a commuting problem. There seems to be a higher probability for some props to fail than for others. One motor is extremely lazy and holds responsible for over 90% of all failures. When swapping it with another motor, the problem seems to travel with it.
We bought this drone as a RTF-kit and attached some payload. The manufacturer did test flight prior to shipping and confirmed that it was working.
Setting the arming throttle (MOT_SPIN_ARM) from 0,1 to 0,05 greatly reduces (but not eliminates) the problems.
We also tried mounting a separate compass (Holybro RM3100 DroneCAN), since the GNSS integrated compass is close to all other electrics in that setup. No change.
Here are some logs to illustrate the problem:
This log contains five armings in a row where the problem arose. The failed motors for the five tests are 3, 3 and 2, 3, 3, 3 and 2. It was done with factory settings. Note that the log is called “UnknownDate”, because I was testing inside and had no GPS reception. However, with GPS, the problems are the same.
This log is a manufacturers test log before shipping where, apparently, everything worked.
The following shows a screenshot of the AM32 settings for the ESC, which are basically in default state and have not been changed by me. I temporarily tried more startup power, which made the props spin up faster but changed nothing about my problems.
The AM32 FW is 2.16. I’m aware there is a version 2.21 now and 2.17 already introduced speed- and timing changes for G071 series controllers, which the F55 apparently uses ( Release Am32 version 2.17-rc1 · am32-firmware/AM32 · GitHub ). However, unless the manufacturer got lucky and had two seldomly working starts in a row, this setup worked as it is, and i would like to eliminate all other possibilities before messing with the factory supplied settings too much. This might make debugging even harder in the long run.
My experience with similar behaviour was usually with small 1S whoops, but yours is different in the following notable aspects:
whoops are harder to start with lower voltage, but in your case voltage was even higher (a less discharged battery probably) than with the manufacturer;
in whoops, the remedy is to increase MOT_SPIN_ARM, but in your case it seems rather counter-productive (based on your claims);
in whoops, uneven starts are often bound to ESCs not motors, but in your case motors seem to determine the outcome.
I only worked with smaller multirotors, so hardware-wise what I’m saying is to be taken with a pinch of salt. My working hypothesis is that:
it’s mostly motors in your case: between the manufacturer and you, they either got somewhat damaged, or the environmental conditions are different (e.g. lower temperature, which e.g. caused higher viscosity of oil in bearings)
what happens may be stuck rotor protection triggering - with the default MOT_SPIN_MIN, the start-up is aggressive and the motors appear “more stuck”, and if you lower it, the ESC expects less instant reaction and continues with a higher probability (somewhat consistent with viscous friction, which might be in the bearings or in the whole system together with propellers and air)
You may relatively easily verify the latter by unticking “stuck rotor protection” and seeing what happens.
Thanks, the stuck rotor protection was a good tip. I didn’t really fix the problem, but it made it more apparent. The rotors now try forever to find a working commutation sequence and eventually succeed. Here is an example video with “stuck rotor protection” disabled.
Anyway, you must know that this drone is eventually supposed to fly autonomous missions, so nobody might be standing by to make sure the props fully spin up before takeoff. This can therefore not be the final solution.
As for mechanical reasons: It’s not impossible, we had a lot of ups and downs with temperature and humidity in my area recently. However, all props spin freely and effortlessly by hand and none exhibit visible defects or dirt accumulation.
That AM32 settings does not looks default. Set:
Protocol Dshot
Complimentary PWM
Auto timing advance
Newer am32 versions have PWM Type - by RPM preferred.
Also it’s recommended to set SERVO_DSHOT_RATE to 3 (if your looprate is 400 hz) to keep it more than 1khz.
I commonly see me as the problem, the hardware is the last thing i inspect…
Anyway, I meanwhile took some measurements on the motors, and the one that caused the most problems by far was indeed defective. One phase seemed to be completely shorted and the other ones showed much higher resistances than advertised by the manufacturer.
After swapping this motor, making a few firmware changes to the ESC and changing the power source, it worked a few dozen times in a row.
These changes included upgrading the firmware to v2.21, disabling “stuck motor protection” and enabling “stall protection”. The first prevents the ESC from giving up too early when the motor has a few misfirings.
Lastly, I was testing with a bench supply, which might have contributed to the problem. It is absolutely capable of supplying enough current for running at arming speed, but I’m not sure how it reacts to sudden startup bursts of the motors.
On hindsight, point 1 and 3 might have been the main contributors.
