Implement Input for Spektrum SRXL2 Receivers

[teyrana]

Problem Description

Updated: 2021 Sep 2

A clear and concise description of the problem this proposed change will solve:

1. Adds support for the Spektrum SRXL2 Protocol.
2. Adds support for binding receiver through QGC
3. Adds support for RC input (uplink)
   • Calibrate r/c radio in QGC -- fixed! (20210522)
4. ported crc16 function from reference implementation:
   • https://github.com/SpektrumRC/SRXL2/tree/master/Source

Not included:

1. Telemetry Support (downlink)
   • out-of-scope; left for a future PR

Describe your solution

Best effort has been made to work with the exist architecture.

1. The most notable change is a srxl driver at src/lib/rc/srxl.*.
2. Significant changes were made to src/drivers/rc_input/RCInput.* to accommodate the addition parser case

History

This patch is inherited from Kekiefer (https://github.com/kekiefer), Much thanks for the examples, and ground-work.

Describe possible alternatives

Trade-Off 1: Custom vs Prexisting SRXL parser

1. Custom SRXL parser

Available as implemented in this patch. It is simple to comprehend and debug, but also lacks features.

2. Off-The-Shelf Parser:

Spektrum RC, the original equipment manufacturer of both the transmitter and receiver produces a reference library to parse this telemetry:
https://github.com/SpektrumRC/SRXL2

It is more complicated, but fully featured. And maintained by Spektrum themselves.
Recomend bring it in as a submodule for future development.

Trade-Off #2: Parellel SRXL parser vs Expanding DSM parser

The rational here is very simple. From the Spektrum Documentation:

Previous Spektrum serial receivers were based on the Spektrum remote receiver protocol, which is not compatible with SRXL2.

In addition, parallel parsers prevent introduction of inadvertent bugs to the legacy "dsm" parser, and also allows completely code paths for the two cases.

Documention

the list of supported receivers at:
https://docs.px4.io/master/en/getting_started/rc_transmitter_receiver.html
is just out-of-date. It needs to be updated.
Compatible: - PPM, satellite receivers, SRXL2/Serial Port

Note: DSM refers to over-the-air radio-wave modulation. DSM modulated receivers may implement analog PWM, Summed PWM, or SRXL

Development Hardware:

• FMU: Holybro Pixhawk 4 (standard)
• Receiver: Spektrum SPM 4651
• Transmitter: Spektrum DX6e
• [Debugging only] Dronecode debug port reader -- https://kb.zubax.com/display/MAINKB/Dronecode+Probe+documentation

Test Setup:

    Pixhawk 4 FMU                                  Spektrum 4651 Receiver
    "DSM/SBUS RC" Port
------------------------+
        Pin     Signal  |                         +----------------
        1       VDD_5V  |------\         /--------| 1 - Signal
        2       SBUS    |---------------/         | 2 -
        3       RSSI    |        \----------------| 3 - V+ (5VDC)
        4       VDD_3V3 |            /------------| 4 - GND
        5       GND     |-----------/             +----------------
------------------------+

• (photo): https://drive.google.com/file/d/1WEVORPKYTBK2P2txbnXX7Qj2etqOS7VA/view?usp=sharing

Procedure:

1. plug in dronecode adapter

2. connect: $ screen /dev/ttyACM1 57600
   (yes, baudrate is necessary, USB connection notwithstanding)

3. plug in mainboard (fmu) (if already plugged in, unplug, then replug -- the goal is to verify the boot sequence on the debug console.

4. Verify that we see the boot sequence through the dronecode adapter (the boot text should scroll by, and dump you at a nsh> prompt.

5. Build firmware:

make px4_fmu-v5_multicopter upload

2. ensure fmu board has power
3. wait for upload to complete.
4. start input daemon: rc_input start
5. [Optional] verify: rc_input status
6. turn on transmitter. You should see bind messages in the debug console
7. move control sticks -- you should see a difference in the control channel values output in the debug console.
8. This setup should be ready to calibrate in QGC or your ground station of choice.

Spektrum RC Specifications Sources

• Receiver Feature Matrix

• Old Spektrum Serial Protocol (RevG)

• Old Spektrum Serial Protocol (RevA)

• New Serial Protocol: SRXL2

  • Specification Document
  • Reference Implementation

Github Links

• Source Issue (Resolves #16620)
• Previous issue (#8650)

[teyrana]

note: holding as draft, until the QGC calibration issue is resolved

[teyrana]

edit: fixed formatting.

[teyrana]

re: missing include: crc16.h

Resolution ideas:

1. do not build srxl module in sitl mode?
2. Selected: port (i.e. copy) the crc16 algorithm function to srxl.cpp file from the reference implementation
3. refactor crc16.h to some always-available common directory?

Progress:

• Implemented. Will push here along with the calibration fixes.

[teyrana]

Channel Mapping chart

Note: still blocked by: QGroundControl issue

1.Mode 1 and mode 2 seem to produce identical channel data
2. No channel (re)mapping

Channel Mapping: Mode 1

Tx	SRXL	Mavlink	QGroundControl
Left / Horizontal	3	chan4_raw
Left / Vertical	0	chan1_raw
Right / Horizontal	1	chan2_raw
Right / Vertical	2	chan3_raw

Channel Mapping: Mode 2

Transmitter	SRXL	Mavlink	QGroundControl
Left / Horizontal	3	chan4_raw	Yaw
Left / Vertical	0	chan1_raw	Throttle
Right / Horizontal	1	chan2_raw	Roll? <== issue happens here
Right / Vertical	2	chan3_raw	???

[teyrana]

@dagar All known bugs fixed. Rebased on master 2021/05/22

[teyrana]

Update: this PR is now out-of-sync with 'master'. It will be squashed & rebased after resolution of the current conversations:

1. Dynamic allocation
2. copyright header
3. Stylistic replacement for ===== horizontal rule section header

Also, a new topic, since the current PR is mostly acceptable:

1. What path should I implement for out-of-the box usage on boards with a separate I/O processor?
   Currently, this code must be explicitly invoked by rc_input on pixhawk 4 boards... which is probably sufficient for the core developers to test, but not for wider testing.

[podhrmic]

@teyrana is teyrana:pr-srxl-input branch functional and can be used for a test flight? (assuming nothing was broken in master)

[teyrana]

@podharmic
By default, no. It hasn't had much testing.

However, IF you know what you're doing and are comfortable manually starting the rc_input process to kickstart the driver, ... It is functional, and would benefit from some ground testing :)

[teyrana]

(ci failed due to unrelated issues in UAVCan. Paused for a few days to let that issue resolve itself.)

[teyrana]

( pushed a rebase / update, to check CI status )

[teyrana]

CI failed due to changes outside of PR:

Scanning dependencies of target component_general_json
Traceback (most recent call last):
  File "/__w/PX4-Autopilot/PX4-Autopilot/src/lib/component_information/generate_component_general.py", line 79, in <module>
    save_compressed(filename)
  File "/__w/PX4-Autopilot/PX4-Autopilot/src/lib/component_information/generate_component_general.py", line 33, in save_compressed
    with open(filename, 'r') as content_file:
FileNotFoundError: [Errno 2] No such file or directory: '/__w/PX4-Autopilot/PX4-Autopilot/build/px4_sitl_default/component_general.json'

[teyrana]

Update: 2021/Aug/31

1. rebase on master show significant changes (and thus: conflicts)
2. conflicts have been resolved
3. changes merit another round of testing to verify functionality.

[dagar]

I've ordered some new SRXL2 equipment and I'll follow up with this soon.

[teyrana]

Update: 2021-Nov-16

• rebased onto px4:master
• @mfry90 Have confirmed you can start rc input through the "Mavlink Console"
  • 1. Open QGroundControl
  • 2. Plug in autopilot board (here: pixhawk4)
  • 3. Wait for connection to QGroundControl
  • 4. Click on "Q" icon in the upper left ("Select Tool") menu
  • 5. Select "Analyze Tools"
  • 6. Select "MAVLink Console" tab
  • 7. enter command: rc_input start, as you would from debugger
  • 8. Unfortunately, you will not see the debug output from this console.
  • 9. rc_input status will produce useful output.
• @dagar I have confirmed that rc_input start works from the main-board / MAVLink Console:
  • 1. Physical input to transmitter -> receiver -> pixhawk -> QGroundControl -> Calibration
  • 2. Debugging output is NOT VISIBLE :( on the MAVLink Console
  • 3. When last checked, debugging output was visible via DroneCode adapter

[mfry90]

@teyrana confirmed that rc_input start and rc_input status give good results

INFO  [rc_input] Max update rate: 250 Hz
INFO  [rc_input] UART device: /dev/ttyS4
INFO  [rc_input] UART RX bytes: 325405
INFO  [rc_input] RC state: found: SRXL
rc_input: cycle time: 34737 events, 609230us elapsed, 17.54us avg, min 9us max 2027us 56.952us rms
rc_input: publish interval: 5483 events, 24951.33us avg, min 3339us max 87696us 13001.321us rms
 input_rc
    timestamp: 229702446 (0.007529 seconds ago)
    timestamp_last_signal: 229702446
    rssi: 100
    rc_lost_frame_count: 512
    rc_total_frame_count: 0
    rc_ppm_frame_length: 0
    values: [1171, 1510, 1512, 1510, 1171, 1853, 1512, 1512, 1512, 1512, 1512, 1512, 0, 0, 0, 0, 0, 0]
    channel_count: 12
    rc_failsafe: False
    rc_lost: False
    input_source: 16

Pixhawk now reflects 6 channels sent from my DX6e. This is confirmed by checking rc_input status, looking at signals in the "MAVLink Inspector", and by going through the calibration routine in "Vehicle Setup".

[mfry90]

Also (partially) confirmed that when connected to servos, radio transmitter commands are actuated by servos. I say partially because there are two concerns:

• There are sometimes delays between the transmitter's throws and the servo actuation. I'm not sure if this delay is due to this feature of other pixhawk features.
• There is no actuation sent to the elevator or the throttle. I think this may be user error or a Pixhawk wiring issue, since rc_input status does indeed reflect the transmitter's elevator and throttle throws.

I can post a couple videos that show both points if it helps.

[mfry90]

Update on the two issues from my physical test:

(1) I am now getting elevator and motor responses to my commands. I'm not sure why elevator wasn't working before, but the motor was previously unresponsive because I hadn't armed it (user error). This issue is resolved.
(2) The servo's are still showing sporadically locking up (I previously called them delays but I think I'm just hitting bouts of unresponsiveness). I've attached a video on this. You can see in the first few seconds that the servo is hardly responding, and then un-freezes and starts tracking my commands.

Would (2) be an issue with this SRXL2 feature, or does this occurs with other receivers communicating through the SBUS/DSM port? @dagar Has anyone else seen this "lock up" before (even on other receiver types/connections)?

I'm certain this is not a servo hardware issue, as I don't get this freezing when directly using my AR620 without a Pixhawk.

Sporadic.Radio.Freezing.mp4

[teyrana]

@mfry90 @dagar
Is there any hardware testing that would be useful to move this forward?

I don't have a complete airframe but I do have an autopilot board and some servos & motors...

[mfry90]

@teyrana I got some data but haven't been able to sift through it all. Once I'm back from traveling I'll upload it here.

[mfry90]

log_119.zip
This file has a couple instances where the servos "lock up" like the previous video has shown. I'll try and get another set of data to upload.

In order to "locate" the failures when you're reading this data, every time I noticed the aileron servo being unresponsive to my RC commands, I would throw aileron left-right-left-right commands from extreme to extreme (like you see in the video). If there were portions when the servos were not tracking, to flag the event I would flip an RC switch on and off rapidly. Those signals and events can be seen by the following mappings:

aileron commands (received and transmitted):

• actuator_outputs_1.output[0]
• input_rc_gears.values[1]
• rc_channels.channels[1]
• manual_control_setpoint.y

RC "error flag" switch (rapidly on/off to indicate the previous aileron commands weren't tracked):

• input_rc_gears.values[4]
• rc_channels.channels[4]

I've looked through this data to try and find a disparity between the input channels (input_rc_gears, rc_channels) and the output commands (actuator_outputs_1, manual_control_setpoint.y). I haven't found that yet, so I'm thinking it has something to do with the input RC commands not being properly processed.

There's a lot more data in the .ulg file, but none that I've found helpful in finding why there are problems (for example, rc_signal_lost is false, rc_signal_found is always true, etc.). You might find something I haven't found though, I'm still looking.

Another thing to note, the two instances of this failure occurs both when the system is disarmed (the first instance) and when the system is armed (the second instance).

I'll load another set of data if I observe the failure again today.

[teyrana]

@mfry90
Could you also document here how you ran rc_input?
Was this starting it from some script? which one? and where was it?

(Apparently the pixhawk 4 has two processors, and I want to run this by the core devs, and ask it may be causing this issue.)

[mfry90]

Here's another data log that shows the same behavior. I believe that the SRXL2 protocol is not processing RC commands correctly, because the topic input_rc that RCInput.cpp publishes to is showing values inconsistent with the commands I'm sending with my DX6.
06_15_28.zip

Top-level description of my test run:

1. (time: 0 seconds to 22 seconds) Keep throttle to mid level and sweep aileron command left-right sinusoidally.
2. (time: 22 seconds to 24ish seconds) Bump throttle up to max level, thumbs off aileron (centered)
3. (time: 24ish seconds to 31 seconds) Same as step 1.
4. (time: 31 seconds to 24 seconds) Drop throttle to min level, thumbs off aileron (centered)
5. (time: 34 seconds to 46 seconds) Same as step 1.

Here is the input_rc_gears topic (a mirror of the input_rc topic), recorded on the .ulg file:

The failure can be found from 34 seconds to 43 seconds. Although I am commanding sinusoids, input_rc_gears.values[1] does not reflect that (though it starts showing that from 43 seconds to 46 seconds).

You can see the same issue in the rc_channels.channels[1]:

[teyrana]

@mfry90
Could you explain where you're starting the rc_input process from? I do want to make sure I can reproduce the issue before I try to fix it.

Update: 2022-Jan-29

Using Configuration:

• Ground Control: QGroundControl
• Telemetry: TELEM1 <=> Wifi board
• Airframe: "Standard Plane"
• Disable Arming Checks
  • COM_ARM_ARSP_EN -> 'Disable'
  • COM_PREARM_MODE -> 'Always'

[mfry90]

@teyrana
Put the files from the attached etc.zip file on the Pixhawk's SD card (see https://docs.px4.io/v1.12/en/concept/system_startup.html and https://docs.px4.io/v1.12/en/concept/sd_card_layout.html for more details).

extras.txt specifies that both rc_input and logger should run at startup. The logger_topics.txt file specifies the topics that should be logged (though I don't think all of them are being logged, it might be struggling to log all 33 topics).

etc.zip

[mfry90]

@teyrana Testing update here. I believe I've been able to rule out the remaining PX4 or Pixhawk hardware as causing the intermittent freezes. I replaced the SPM4651T (which uses the SRXL2 protocol) with another Spektrum serial remote receiver SPM9745 (which does not use SRXL2). I've collected about 15 minutes worth of data from distinct tests and have not yet seen the same intermittent freezing that I'm observing with the SRXL2 receiver.

Next steps for me are logging diagnostic messages in the modified code to determine what part of the code is causing the locking.

[teyrana]

@mfry90
While you're logging channels, are the logs showing faults in all channels, or just some of them?

(if you're wondering, I never did get my setup to output actuator signals at all :/ )

[alexzhou707]

Are there any updates to when this will be this will be resolved?

[teyrana]

@alexzhou707
Honestly, this PR is abandoned at this point.