MadsR
commented
2 years ago Problem - Single Core CPU Due to the Arduino's single core processor timing issues can result in the RF (SBUS) communication to get out of sync, which results in the SBUS timeout error. When this error occurs, all motors are halted until SBUS is resynced (for safety reasons). The software will automatically power off and power on the RF communication, which in previous testing fixed the desync.
Solution 1 - Additional CPUs Adding additional processors (arduino) to handle individual components, motor communication, rf communication, more(?), would remove these timeout errors halting the primary system.
Primary drawbacks are increased power consumption (~100mA per arduino).
Solution 2 - Lower Timeouts Reducing timeout thresholds further will reduce system halts, potentially lowering the risk of desyncing SBUS communication.
Solution 3 - Analog PWM reads Changing RF circuit to measure the RF PWM outputs instead of SBUS channels would completely neglect timeout issues.
Primary drawbacks are no way of detecting RF communication status/connection.
Solution 4 - Rework SBUS circuit The current circuit uses a simple inverter circuit to read SBUS as a standard serial communication. Potentially reworking this can result in more stable communication.
ArcticRover firmware version
No response
Area(s) with issue?
Remote Control
Steps to reproduce
RF losses are very frequent. It is not practical to drive the rover more than ~20m away because you know you have to go press the select button.
✔️ Expected Behavior
I would like the rover to keep the RF connection even if there are errors. I would like that the rover attempts to re-establish the connection even if the connection is lost.
❌ Actual Behavior
Lots of RF losses. This could possibly be because whenever other errors occur (e.g. motor error), then the rover disconnects from RF. I am not sure.