Process radio data in RPi

[patchedByBatman]

Main Changes

1. All of the radio data processing is now shifted to Python and will be carried out on Raspberry Pi.
2. R-Pi sends processed data in the following format:

"S, Yaw rate in rad/s, Pitch in rad, Roll in rad, Throttle PWM in [1000, 2000], % Trim A, % Trim B, % Trim C, % Trim D, Encoded switches data"

The 'S' in the beginning is sent to indicate the start of the packet and is used to check for packet corruption at the ESP's end.

The "Encoded switches data" is an integer with encoded information about the position of radio switches A (Kill switch), B (Arm switch), C (Three-way switch), and D. The last 5-bits (rightmost 5-bits) of this correspond to the switch positions as follows:

• bit-4 (MSB): 1-bit info of Switch B: 1 if armed else 0.
• bit-3: 1-bit info of Switch A: 1 if the kill switch is on else 0.
• bits 2 and 1: 2-bit info of switch C: 00 for position DOWN, 01 for position MID, 10 for position UP.
• bit-0: 1-bit info of switch D: 1 if D is on else 0.

3. Some data checking code, such as whether the data is within the allowable range, might need to be adapted into the Python code from radio.cpp in #51 . This is done, but I am keeping it here for future reference.
4. New addition: using threading in R-Pi receiver program and now the data is processed and sent at (roughly) 50Hz.

The status of addressing the posted issues in #48 is

• [x] When we start to read data from the Pi, we may start to read a line midway, so we will not read all 16 numbers. A possible solution can be to put a certain character at the beginning of every message (e.g., M or something) Addressed the above by adding the character 'S' at the beginning of every packet.
• [x] It is not impossible that the Pi sends garbage data every now and then. Addressed the above by checking if the packet starts with 'S', and if the received data has the above-defined format or not on the ESP's side. But we might need to add even more checks based on requirements, such as an additional check on the EPS's side to see that the received percentages are not negative and also not above a hundred.
• [x] We can try to increase the baud rate. The Pi supports baud rates up to 2M. The ESP32 can allegedly go up to 5M, although some users have reported issues above 2M. I would try 500,000. "This is not addressed" old message. Updated message on 30th May 2023 at afternoon 12:30 BST "The suggested baud 500,000 has been implemented and tested, it is working perfectly."
• [x] We can decrease the size of the message. We can encode the state of the switches as 0/1. This is addressed as well.

Associated Issues

• Closes #28
• Closes #48

Note

As of now we do not know which of these fixed issue #28, but using this code along with a proper USB cable for serial data transfer instead of the physical pins fixed it. Might want to investigate in the future for the sake of making replicas.

[alphaville]

@gunturiCM ping us to review this after you test it

[patchedByBatman]

@gunturiCM ping us to review this after you test it

The testing is done. Please review the code. Might need peers to test as well.

[jamie-54]

Looks good @gunturiCM, I think @alphaville has covered everything. When reviewing this it made realise we have an issue with RADIO_STICK_MIN RADIO_STICK_MAX but I made a new issue for it (#54)

[patchedByBatman]

The suggested changes have been done. Please have a look.

[jamie-54]

Happy to merge

[patchedByBatman]

Merging into dev.