This is my first time setting up Ardupilot, and my servos are moving erratically, i.e., anywhere from slightly unsmooth to stuttering, such that there can be about 1/3 second delay during movement.
Please watch the video below which is in 3 parts… 1) Ardupilot servo stuttering when USB is plugged in, 2) Ardupilot servo stuttering USB unplugged, and 3) INAV butter smooth servos…
Firmware on my F765-WSE is the only _bl.hex currently available, which is in the “latest” folder.
It seems like it must be Ardupilot causing the issue, because as shown in the video, the servo movement is butter smooth in INAV.
It makes no noticeable difference being in manual flight mode compared to any other flight mode.
Even the servo output bars in the GUI look to be moving slowly and unsmooth. It’s as if something is causing a delay in processing the PWM inputs from my TX16S.
I’ve attached a photo showing where it’s connected, i.e., Tx6, Rx6, 4v5, G.
I haven’t configured anything in Ardupilot for the Crossfire-RX, because I read that Ardupilot automatically detects the protocol being used, which it does.
In my TX16S, I’ve done the same as for my 2 quads and 1 plane which also use a Crossfire Diversity Nano RX, i.e., enable crossfire for the external protocol in the model menu, and bound as usual in the system menu.
Please take note that in INAV the servos are perfectly smooth.
I’ve also tried analogue servos and they stutter almost as much as my Savox SH-0263MG in the video. I’ve also experimented with the SERVO_RATE parameter, changing it to as low as 1 for which it’s quite amusing to watch it step so slowly, but also up to 333 for which it seems no better than the default 50Hz.
I loaded the official “Plane” firmware version 4.1 via Mission Planner, connected the Crossfire receiver to pads Rx1 and Tx1, and set “SERIAL2_PROTOCOL” to 23.
Servos now move butter smooth
EDIT: I’ll try the BRD_ALT_CONFIG = 1 suggestion out of curiosity, but how does that compare with the solution I’ve tried?.. very curious to learn a little more that’s all, in layman’s terms if possible please.
Are you testing an F765-WSE, and firmware ArduPlane V4.2.0 dev?
I’ve connected my Crossfire back to pads Rx6 and Tx6, loaded ArduPlane V4.2.0 dev (which it was using initially when it had the stuttering), and set BRD_ALT_CONFIG = 1, but my radio output isn’t being acknowledged at all, not in the radio calibration tab or servo output tab.
When I change it back, i.e., BRD_ALT_CONFIG = 0, it works, but with the stuttering again as expected.
When I load firmware 4.1 official whilst connected to Rx6 and Tx6, my radio output is only acknowledged when BRD_ALT_CONFIG = 0.
I can revert back to using the previous method I stated of course, no problem, but I’m curious if your setup is exactly the same as mine?
You can save yourself the trouble of asking Matek. This has to do with the programming of ArduPilot. SERIAL7 is the RC input on the board. Originally intended for PPM and SBUS and extended over time to CRSF etc. For CRSF it needs a complete UART. Therefore the BRD_ALT_CONFIG.
However, it is recommended by @andyp1per for example to take a DMA capable UART for CRSF. That would be SERIAL2. Which works for you without any problems.
I already emailed them, so will post any additional info here if/when they reply.
Matek already suggested to use stable 4.1 and to “connect CRSF to USART1, set serial2_protocol = 23”, which works for me like you say, but nothing I try makes the servos operate smoothly for Rx6 and Tx6.
Matek F405-STD
I have the same problem with erratic servo movements using CRSF protocol with different firmware versions from 4.1.0 stable and on. Servos are digital. I have tried TX3 and TX4 (serial1 and serial2) with same results. I cannot check if those are DMA enabled.
Any help would be appreciated.
