Yes, the missing ground connection and the noises could cause this behavior. Please put the ground back. Also, you should stop using RCPWM and switch to UAVCAN.
Greetings Pavel!
I will continue in this topic, as I’m having related to the topic name issue, but of slightly different nature now.
In last June, I solved all the problems, and continued flying, and it was all well and good. But suddenly, recently my drone started to fall, and once I saw propeller stalled in the air. I started to investigate, and found out two interesting moments:
-
Tantalum capacitors would explode if I would spin the motors on full throttle, and give rapid changes of throttle. That wasn’t the case when I just put the esc’s on the drone
-
On the power supply line, I found the voltage ripples up to 6Vp-p! I guess that’s the reason for tantalum exploding, as they don’t deal that well with AC component. But are such oscillations normal? I’ve compared to other brand ESC’s and found no such thing.
But it got me thinking, since this issue revealed itself only after half a year, my theory is that tantalum caps were slowly degrading over time. I used 25V capacitors, TR3W107K025C0100, 4S battery, and 950KV motors, with rated current 20.3A and 225.33W
Perhaps you, or someone on your team could give some advise.
Cheers
You are absolutely correct in your analysis. We have replaced the tantalum caps since then; the new recommended model is Vishay Sprague 597D107X0035F2T, which is rated for 35 V. The corresponding BOM entry now reads as follows: Tantalum capacitor. VOLTAGE RATING 35V!!! (sic!).
Okay, I see. So, can I ask, why did you choose to use tantalum capacitors here at all? The osciallations I observe on the power lines, are definetly not acceptable for tantalum. Was it soley to reduce pyisical dimensions? ESR of tantalum is still not as good as some aluminium electrolite caps. Should I try to use aluminium electrolite capacitors instead?
I also observed capacitor explosions with 35V capacitor, which makes me thinking, that it might be something else.
And lastly, I observed motor stops, where it would not write to console that it is “unexpected stop”. It would just increase zero crossing detection counter, and stop. That is very upsetting behaviour, as if it happens in mid air - the crash is imminent.
Tantalum caps seem to work adequately well for Orels, they are lighter and smaller, and the ripple current is within the limits of the model I linked above. If they don’t function well with your hardware, make sure that you don’t damage your caps during soldering, check the temperature profile.
And lastly, I observed motor stops, where it would not write to console that it is “unexpected stop”. It would just increase zero crossing detection counter, and stop. That is very upsetting behaviour, as if it happens in mid air - the crash is imminent.
If it does so after 30 seconds since last input (or is it 60? the correct number is provided in the reference manual), it is intentional, and this is done to prevent runaway when the drive loses connectivity with the controller. Otherwise, you may have some other issue with your hardware.
Pavel, hello again.
So my investigation went further, and I was finally able to observe that indeed the ESC writes “unexpected stop” to the console when motor stalls. I replecated the problem by fixing my copter on the ground and simulating highly dynamic flight conditions. I have also observed, that before shutting off, several zero crossing detection failures have occured.
This mechainsm, that shuts off the controller, after several zero crossing detection failures is meant to save the controller, from damadge? But never have I found a non-functioning controller, or somehow damadged in my crashes. Nor it became non operational after replicating the stall case on the ground. So it appears, that controller by trying to save itself, is sacrificing the whole aircraft.
Shouldn’t controller rather try to work no matter what, and under no circumstanes allow rotor to stall? Why is there such option, to shut off the motor? In most ESC’s I’ve ever used, I’ve never encoutered just “giving up”.
What can cause zero crossing detection failures? Surely it detects when the motor is jammed, but it seems that it also mistedetcs the stalls, when the load is high, even though it is still a spinning propeller.
Please read the section “2.2.6 Rotor stall detection” in the reference manual, and look at the parameter mot_zc_fails_max. The reason we have the zero crossing failure limit is that the early revisions of the firmware were prone to synchronization losses under all but ideal operating conditions and the ZC error counter was used to determine if the motor is likely still spinning or not.
The modern firmware is much more robust than its early versions (some major improvements were made in the release v2.0 in particular), so the ZC error counter settings should probably be revised. Perhaps you could try increasing mot_zc_fails_max to a higher value like 300 and raising the upper limit to 1000? If that works for you, I’d like you to submit a pull request with this change, please.
This mechainsm, that shuts off the controller, after several zero crossing detection failures is meant to save the controller, from damadge?
No, it has nothing to do with damage to the controller itself. It is merely a method of detecting whether the motor is running or not.
But wouldn’t increasing the mot_zc_fails_max be just fighting the consequences, not the root cause, which is having those zc_fails in the first place?
So analysing further, I took a closer look at the filter circuit that, that senses voltage on the phases. I wonder, what is the purpouse of it.
I simulated AC sweep, and it’s cut-off frequency is 147 khz. So why you choose such high cut-off frequency?
The cut-off frequency of the circuit pictured should be close to 19 kHz, check your simulation please. The phase voltages are sampled synchronously once per PWM period. The lowest modulation frequency intended for Orel is 40 kHz, for which the Nyquist limit is 20 kHz, hence the choice of the cut-off frequency setting. The reason we limit the lower boundary at 40 kHz is explained in the reference manual:
But wouldn’t increasing the mot_zc_fails_max be just fighting the consequences, not the root cause, which is having those zc_fails in the first place?
Tracking the rotor state during rapid accelerations and decelerations is always hairy business. There exist certain operating conditions where the floating-phase BEMF cannot be observed at all due to high flyback currents. When that happens, Sapog would skip a step in order to bring the motor back into a trackable state; this is recorded as a ZC detection failure. More on this in the section 2.
Well, here is my simulation circuit:
and here is the result of AC sweep:
What am I doing wrong here?
Also, if to use formula, that is found in TI DRV datasheets, where the use the same circuit for reading voltage on the phase
The result is the following
560 Ohm here can not be ommited, as it would discharge the capacitor very quickly.
However, If I would simulate it as a classical RC filter, the kind that can be found in every simple filter-calculator-online in following configuration:
then, indeed the result would be 19kHz.
Did you just ignore 560Ohm, parralel to the capacitor? And calculated it like this:
You are right, disregard the above.
I had to go back to the sources to find out how it actually works. Have a look at the following figure (thanks @alexander.sysoev) :
This is at the maximum supported PWM frequency of 60 kHz. Sapog requires a very high cut-off frequency in order to have the filter output stabilized before the signal is sampled. The relevant code is under /firmware/src/motor/realtime/motor_pwm.c and /firmware/src/motor/realtime/motor_adc.c.
On a related note, I have submitted a pull request that should resolve the false positive stall detection during rapid acceleration/deceleration: Fixed false positive stall detection by raising the ZC failure limit by pavel-kirienko · Pull Request #28 · PX4/sapog · GitHub