Hi.
I have created the BLDC driver board with 2 motor channels on it, acordingly to the sapog V2.0 guide documentation.
Microcontrollers were flashed with the prebuild firmware, Version 2.3
Board is operational under the RCPWM interface control (separate for each channel), it performs well.
But attempt to guide it via the UAVCAN is failing:
Both controllers connected to a single CAN bus via separate transsivers.
Flight controller with Ardu Plane V4.4.4
After the motor start it remains rotation during 20 sec, then controller is rebooting.
Via the UART interface I got some report about stall detection.
I have tryed different CAN bus bitrates - useless.
Incresed the number of stall detection threshould - no effect, just get exact same number in the UART error report.
My gueses:
Old prebuild firmware is outdated (in a UAV CAN segment) and can not interact with CAN bus without issues.
Processing of the CAN transmissions is spoiling the zerro crossing measurements it leads to the time delayed stall report.
Am I right about old firmware and the only way is build fresh version of it?
Or there are some trivial parameters tuning should be done to get things work properly?
The issue is highly unlikely to be DroneCAN-related. From what you said it sounds more like you have a ground loop somewhere when the CAN interface is connected that is affecting the performance of the analog circuits; this may be exacerbated by possible PCB design issues.
Hi, Pavel.
I have improved the board - capacitance near the main IC been increased. So now i have no 20sec limit for the motor rotation.
However, I have faced the new issue - during the smooth throttle increasing I can reach only 40%. (value 1400)
Further increasing of the trottle is supported with the “Setpoint TTL Expired” mesages in the UART debugger.
And motor i getting into the start-stop mode: spin-up, stop, spin-up, stop etc.
I can decrease the throttle above the 40% and everything is getting back under the control.
I was observing the RX TX signals of the CAN interface, power rail of the chip - no signigicant distortions there
Tracking the CAN trafic with logic analyzer - no frames with the NACK flag
Seems like BLDC driver can read this, starting to perform once after receiving and then rejecting.
Attemt to increase the lifetime of the TTL setpoint leads me to the “stucking” of the control for that lifetime - I can reach some great throttle but not reduce it at once, need to wait until setpoints lifetime expires.
Still using the old prebuild firmare for sapog.
My hardware is Pixhawk6C
And firmware version is ArduPlane V4.5.6
Can it be some odd behavior of the safety threshould feature that is equal 40?
My guess about DroneCAN versions incompatibility can take place here?
May be you have any idea what it can be?
Important update: using the Comand Line Interface command “uavcan” provided next information:
Before the throttle reaches the value 1400 - number of RX overflows was stable from time to time.
But after increasing of the throttle over 1400 and start-stop sequences this number has greatly increased.
My guess:
Looks like time slot for the CAN data processing is getting to small when RPM is growing, more zero croses should be processed then. So main program BLDC control cycle does not get the valid information in time and stoping the rotation. Then CAN data is processing, start poerforming and after the spin up cycle fail apears once again.
As the conclusion of all atempts to get it to work:
There is dependency between stable CAN transmissions processing and RPM of the motor.
When speed is exceeding some threshold - CAN RX overflows are starting to occur.
After some time running in this mode driver is rebooting by the watch dog timer - panic case take place.
My initial case was with the highest PWM frequency - 75000Hz so I have faced the complete stuck of the CAN receiving.
Reducing of the PWM frequency gave me a chance to look for more stable configuration, where CAN RX owerflows does not occure on the highest throttle values. In my case it is 47000Hz.
Message rate in the CAN bus is aprox. 360 Hz
ESC is only one device connected to bus, bitmask set to invlove only ESC13
This value (360Hz) is from the logic analyzer graph where gap between regular packets is 2.8ms
Not a CAN dump but a few seconds autopilot LOG of the ESC run in manual mode: 1 1-1-1970 2-00-00 AM.bin (2.1 MB)
My intention for now is to decrease the message rate via CAN bus. I found how to do this for the Servos but not for the ESC’s. If you know how to do this, or where it was mentioned - share this info please.
Status report:
To optimize the CAN bus usage I have changed the ESC from 13 to 0. (less empty data should be populated)
It has the effect - message rate is now a little bit smaller 300-310 vs 360 before.
ESC does not get into the start-stop sequence. But going down in panic mode after some time.
There is parameter CAN_D1_PC_ESC_RT that is responsible for the data rate on CAN bus.
It is available for the PiccoloCAN protocol but not for the DroneCAN (at least via the mission planer UI).
Searching for the way to calm down the CAN data rate…
For now the solution is: decrease the value of the main control loop frequency from 300 to 50Hz (parameter name SCHED_LOOP_RATE).
In this condition no CAN RX overflow appears even on maximum value of the throttle.
But for me it is a question: how stable will be UAV with this new setting?
Indeed, the problem is caused by exceeding the service curve of the ESC with the high message rate. 50 Hz is probably an overkill, I recommend ~200 Hz.