Hello,
I am still waiting for my Orange Cube+ but finally after 3 weeks it should arrive tomorrow.
So I am an absolute beginner in this topic - I hope that you do not mind
That is my plan:
RC - Receiver â> Orange Cube (normal carrier board) â CAN BUS â CAN Transceiver â ESP 32 â (PWN) to motor controller (skid steering of 4 x 250W for my UGV - UGV - large mower, modular design)
I am using Holybro H-RTK Unicore UM982 (Dual Antenna) for autonomous mode and a standard PWM RC receiver (HotRC F-06A) with individual PWM outputs for each channel.
I learned so far that the standard way to connect RC receivers to modern ArduPilot boards like the CubeOrange is via the dedicated RCIN port, which expects serial protocols like SBUS or PPM-Sum. While converters exist to translate individual PWM to SBUS, I found the adapter I have to be too small and cumbersome to reliably connect.
To address this, Iâve been working on a firmware modification to allow reading multiple individual PWM signals directly on the CubeOrange+'s AUX ports . This avoids the need for an external converter or a receiver with serial output.
Implemented Modification Details:
This modification involves adding support for a new RC input protocol within ArduPilot Rover firmware.
- New RC Protocol Driver:
-
Created a new AP_RCProtocol_PWM class.
-
Implemented low-level pulse width measurement using the STM32 timers in Input Capture mode on the dedicated AUX pins. This is critical for accurate and reliable timing.
-
Uses interrupts to capture pulse timings without blocking other firmware tasks.
- Hardware Integration:
-
Modified the hardware-specific definition for the CubeOrange+ to properly configure the AUX ports (AUX1-AUX6) as timer inputs specifically for this purpose.
-
Ensured the necessary timer channels are set up to listen for the incoming PWM signals on these pins.
- ArduPilot Framework Integration:
-
Registered the new PWM protocol within ArduPilotâs RC input system (AP_RCInput).
-
Added a corresponding bit (needs to be a specific, unassigned bit, e.g., bit 17 or similar - this needs to be defined in the code) to the RC_PROTOCOLS parameter to enable the feature.
-
Integrated the driver output with the existing RC channel processing framework.
- Flexible Usage:
-
The implementation supports using any number of the configurable AUX ports (from 1 up to 6 channels).
-
The driver automatically detects which of the configured AUX ports are receiving a valid PWM signal.
-
This allows users to connect only the required channels (e.g., AUX1-AUX3 for basic control) and potentially use the remaining AUX ports for other purposes if not needed for RC.
How to Use (with the modified firmware):
-
Hardware Connection: Connect the Signal pins from the desired individual PWM outputs of your RC receiver (e.g., CH1, CH2, CH3) directly to the Signal pins of the chosen AUX ports on your CubeOrange carrier board (e.g., AUX1, AUX2, AUX3). Ensure the receiver is powered (e.g., from a 5V output on the Cubeâs servo rail) and grounded.
-
Firmware: Load the modified ArduPilot Rover firmware onto your CubeOrange+.
-
Parameter Setting: In ground station (Mission Planner) setting the RC_PROTOCOLS parameter to include the bit corresponding to the new PWM protocol (e.g., set RC_PROTOCOLS to (Current Value) | (1 << 17) if bit 17 is used).
-
Calibration: Perform the standard Radio Calibration procedure via the ground station. The system should now detect the signals on the configured AUX ports as RC channels.
Benefits:
-
Allows using standard RC receivers with individual PWM outputs without needing an external converter.
-
Direct connection simplifies wiring for this type of receiver.
-
Offers flexibility in the number of channels used (1-6) on the AUX ports.
-
Leaves the dedicated RCIN port free for potential alternative uses (though its primary function is RC input).
Current Status & Feedback:
This is a working proof-of-concept / early implementation. It is not yet part of the main ArduPilot codebase. I still have no Cube here to test it.
Iâm sharing this to get feedback from the community. Has anyone attempted something similar? Are there potential pitfalls I should be aware of? Would there be interest in potentially contributing this feature to the main ArduPilot project once itâs fully tested and robust?
I plan to test this implementation thoroughly on my UGV in the coming days.
Thanks for any input or advice!