I am hoping to use SBUS to get the servo signals out from the Ardurover because of the noise on the PWM signals. From here (Sched_loop_rate and servo_sbus_rate), the SCHED_LOOP_RATE parameter controls how fast SBUS gets updated, but with a drawback of larger log file for a faster loop rate. On the other hand, SERVO_RATE also controls how fast the PWM signal gets updated. Does anyone know if the servo update rate (SERVO_RATE) is subject to the setting of SCHED_LOOP_RATE? I am able to test how often Arduopilot updates the SBUS signals; however, I am not able test how fast PWM signal actually gets calculated and updated by Ardupilot because the digital noise on the PWM signal line. Thank you.

The SBUS frame rate is set by parameter SERVO_SBUS_RATE.
It and SERVO_RATE are independent of SCHED_LOOP_RATE, but output values obviously won’t change any faster than that.

What is the source of the noise on your PWM signals?

Thank you for the response, Mark. So just to confirm, SCHED_LOOP_RATE would controls the maximum SERVO_SBUS_RATE and SERVO_RATE. Is that correct?

With regard to the PWM noise, I don’t really know the source. It could be the wire length or because PWM is an analog signal. The symptom I observed is that PWM value could jump quite a bit and could jump across 0 (where 0 = 1500 PWM). The problem for a fast response motor is that it could turn the motor forward or backward somewhat randomly because of the noise on the analog PWM signal. This could and did burn my motor controller. I also tested this by reading the PWM signal via Ardunio or ESP32.

No, SCHED_LOOP_RATE does not constrain the SBUS frame rate or the PWM frequency.

correction the IOMCU SBUS output is independent of SCHED_LOOP_RATE, but the FMU serial outputs are limited by SCHED_LOOP_RATE. It makes sense to set SBUS_FRAME_RATE to SCHED_LOOP_RATE if you are using a flight controller with an IOMCU. ***

What kind of motor controller are you using? (I assume you’re not talking about a servo)
Is the motor brushed or brushless?
Does your motor speed need to update faster than the default SCHED_LOOP_RATE for rover, and if so why?

I have been playing with this VESC – Open Source ESC | Benjamin's robotics to do a semi automous delivery platform which is set up as a skid steer rover. Previously I have been having trouble tuning it and thought the PWM frequency was a problem. Indoor testing shows that I have trouble with the analog PWM signal received from the Autopilot.

I don’t think you’ll need more than 50Hz updates to a skid-steer’s motors.
First thing I’d do is use an oscilloscope to see whether the PWM signal is clean.
Although CAN would be the best option, assuming the firmware is compatible with uavcan.

1 Like

Thanks again, Mark. Using my current setup, I can read SBUS signal. I assume CAN signal is also limited by SCHED_LOOP_RATE. Is that correct? I haven’t tried CAN but there is a CAN connection from the Matek H743 board that I am using. I supposed I can get CAN signal too.

With regard PWM noise issue, I understand PWM is an analog signal. If there is any delay on the interrupt service routine on the receiver side, the PWM signal read will also be off from what Ardupilot sends out. So the problem I have may not be the PWM signal line length alone.

PWM is absolutely not an analog signal. Ideally, it is a very clean digital signal with precise periods of digital on vs digital off (time held high and time held low). Noise can cause imprecision, but there is no analog signaling in these protocols.

1 Like

Thanks for clarifying, Yuri. I meant to say unlike SBUS, PWM signal doesn’t have a checksum like value to verify the PWM value the receiver receives or decodes. I don’t have an oscilloscope (yet) to determine whether there was issue from the flight controller, the transmission line, or something else. What I am experiencing is that the PWM signal can jump around quite a lot while SBUS signal holds steady when I am not touching anything in the indoor testing, just arming the flight controller in manual mode and not touching the remote controller.

Have you ever had to mess with SCHED_LOOP_RATE to get the impressive tuning results you have achieved?

There is no need for SCHED_LOOP_RATE or SERVO_RATE changes to solve the problems you’re experiencing.

I’ve messed with those parameters to see how vibration filtering might be affected, but most (if not all) Rovers will not benefit from such extreme measures, and they were of little consequence other than some “gee whiz” log analysis during testing.

You are more likely dealing with electrical problems than tuning issues.


I agree with @Yuri_Rage that the issues is unlikely to be the SCHED_LOOP_RATE or SERVO_RATE or even changing from PWM to SBUS.

@humble800, what problem are you seeing which is leading you to believe that there is a problem with the PWM signal?

Thanks, Randy. I agree the noise issue with PWM signal is unrelated to the SCHED_LOOP_RATE or SERVO_RATE. My questions are all started with my having trouble tuning the skid rover.

With regard to the PWM signal noise issue, I verified that issue by a bare bone testing environment with only four parts: 1) flight controller (which is connected to PC via USB), 2) RC receiver, 3) motor controller, and 4) Arduino/ESP32 (to read the servo 1 and 3 PWM signals from the flight controller through a pair of ~8”/~20cm long wires, and to translate those to the motor controller via UART). I armed the flight controller in manual mode and could see the jumpy PWM signals read by the Arduino/ESP32 (which then prints results to the PC using Serial.print()). The variations of PWM value read could be significant. I didn’t have the same issue by reading the equivalent PWM values from the SBUS output via UART from the flight controller, which eliminates any potential issue with the flight controller or the remote controller.

With regard to the SCHED_LOOP_RATE, I am able to verify that increasing SERVO_SBUS_RATE alone was not sufficient to get a faster SBUS output rate from the flight controller. I understand that SCHED_LOOP_RATE determines how often the flight controller calculates a new set of throttle and steering values. It is great to hear that @Yuri_Rage was able to achieve the great tuning results without having to mess with the SCHED_LOOP_RATE. So it is really just for my curiosity, could you confirm that the “effective” SERVO_SBUS_RATE and the SERVO_RATE are limited by SCHED_LOOP_RATE? Thank you.

ok, the vehicle has quite a unique setup then with the Arduino/ESP32 in the mix. I’d guess that this intermediate step of converting PWM to UART is where the problem is occuring but it’s not a supported setup so I can’t really provide good advice. If possible it would be better to get closer to a standard setup perhaps by replacing or re-configuring the ESC/motor driver. Almost all ESCs/motor drivers will accept PWM.

I think the SBUS rate and main loop rate investigation is a deadend because these vehicles are generally relatively slow moving so 50hz should be more than enough.

When it comes to tuning the vehicle it is best to start with the speed tuning and then the turn rate tuning.