PX4 串口输出遥控通道与第 7 通道解码复现教学

PX4 串口输出遥控通道与第 7 通道解码复现教学

1. 这篇文档解决什么问题

这篇文档讲的不是“某一次偶然能跑通的小脚本”，而是一类非常常见、具有普遍应用价值的问题：

• 飞控已经收到了遥控器输入
• 需要把遥控器通道值转发给伴飞电脑、工控机、单片机或上位机
• 需要在外部程序里读取某个特定通道
• 需要把通道值用于任务切换、模式控制、视觉使能、载荷控制、外部逻辑触发

本文最终落地的具体成果是：

但这只是示例。真正要掌握的是整套通用方法：

• 如何从 PX4 导出遥控通道
• 如何选择合适的串口
• 如何判断某个口能不能接伴飞电脑
• 如何让外部程序稳定读取遥控输入

2. 为什么这个方法有普遍价值

PX4 工程里，遥控输入不只是拿来飞行。

很多项目都需要把遥控器开关或拨杆交给外部计算设备使用，例如：

• 用某个通道切换视觉算法
• 用某个通道控制任务启动/停止
• 用某个通道控制投放、云台、灯光、机械臂
• 用某个通道作为外部程序的安全互锁
• 用某个通道在“手动控制”和“自主逻辑”之间切换

这些需求的共同点是：

这样做比直接去读接收机原始协议更稳，原因有三点：

3. 核心原理

这套方案的本质非常简单：

也就是说，外部设备读取的不是“接收机的原始电信号”，而是“飞控已经整理好的通道消息”。

这点非常关键。很多人一开始会把目标理解成：

• 直接读接收机
• 直接读 SBUS
• 直接读遥控器厂商协议

这不是本文的路线。

本文的路线是：

• 让 PX4 当中间层
• 让 PX4 输出标准 MAVLink
• 外部设备只做标准 MAVLink 解析

这样复用性高，平台适配成本低，后续扩展也简单。

4. 什么是 RC_CHANNELS

RC_CHANNELS 是 MAVLink 中的一类标准消息，用来表达飞控当前看到的遥控通道原始值。

常见字段包括：

• chan1_raw
• chan2_raw
• chan3_raw
• chan4_raw
• chan5_raw
• chan6_raw
• chan7_raw
• chan8_raw

更高通道也可能有。

这些值通常是 PWM 风格的数值，常见范围是：

• 低位约 1000
• 中位约 1500
• 高位约 2000

实际工程里往往不是严格的 1000/1500/2000，而是接近它们的数值，例如本项目实测过：

• 1044
• 1494
• 1944

这不代表出错，只是发射机、接收机、校准、映射方式的实际结果。

5. 为什么不是直接用接收机协议

这是教学里必须讲清楚的一点。

如果外部设备直接读接收机协议，通常会遇到这些问题：

使用 PX4 输出的 RC_CHANNELS 有几个直接优势：

6. PX4 串口在这个问题里的角色

理解 PX4 串口，是这类问题的基础。

PX4 常见的串口口名包括：

• TELEM1
• TELEM2
• GPS1
• GPS2
• 某些板子还有 TELEM3

这些名字很容易让人误以为：

• TELEM 只能接数传
• GPS 只能接 GPS

这种理解不准确。

更准确的说法是：

• 它们本质上都是 UART 物理口
• 口名字只表示“默认用途”
• 实际能做什么，取决于 PX4 当前给这个口挂了什么功能

例如：

• 某个口可以挂 MAVLink
• 某个口可以挂 GPS 驱动
• 某个口可以挂光流驱动
• 某个口也可以留给伴飞电脑

所以一个口能不能用，不看名字，看“当前配置”和“协议是否匹配”。

7. GPS2 改普通串口到底有什么意义

这是很多人会卡住的点。

GPS2 改成普通串口，不是为了让它“长得像 TELEM 一样”，而是为了释放一条额外可用 UART。

它最重要的用途是：

• 给伴飞电脑通信
• 给单片机通信
• 给外部程序读取 MAVLink

在很多资源紧张的飞控上，通用 TELEM 口只有 1 到 2 个，而项目里又同时要接：

• 数传
• 光流
• 伴飞电脑

这时如果不把 GPS2 释放成普通串口，串口资源就不够。

因此，GPS2 的工程意义不是“替代所有 TELEM 生态”，而是：

• 给系统多补出一条可用 UART
• 专门承担伴飞电脑或自定义通信设备的接口任务

本项目最终就是利用这个思路，把飞控输出的遥控通道数据给外部设备读取。

8. 什么设备适合接在这个串口上

只要目标设备是为了读取飞控输出的 MAVLink，基本都适合：

• RK3588
• Jetson
• 树莓派
• Windows 笔记本
• Linux 工控机
• STM32

但要注意一个边界：

• 口能接，不等于协议就自动兼容

如果你只是让对方设备读取 MAVLink RC_CHANNELS，那很好办。

如果你希望 PX4 去识别某个外设，例如某种串口光流、某种 GPS、某种厂商自定义模块，那就必须看：

9. 本文的最终示例成果

本文落地示例是：

• 从飞控读取 RC_CHANNELS
• 解码第 7 通道
• 输出为：
  • ch7_raw
  • travel
  • signed
  • pos

输出示例：

[2026-05-10 20:11:13.120] ch7_raw=1944 travel= 94.40% signed= 88.80% pos=HIGH
[2026-05-10 20:11:16.552] ch7_raw=1494 travel= 49.40% signed= -1.20% pos=MID
[2026-05-10 20:11:19.880] ch7_raw=1044 travel= 4.40% signed= -91.20% pos=LOW

这组输出本身已经足够支撑很多业务逻辑：

• 三段状态判断
• 安全开关判断
• 模式切换判断
• 外部节点逻辑分支
• 通道阈值触发

10. 从零复现前需要准备什么

复现前准备四样东西：

外部设备可以是：

• Windows 电脑
• Linux 主机
• RK3588
• Jetson

通信链路可以是：

• 飞控 USB 直连电脑
• 飞控 UART 接 USB 转串口
• 飞控 UART 直连 RK3588 / Jetson 串口

11. 复现前必须满足的条件

无论平台是什么，必须先满足这四个条件：

如果四个条件少任何一个，脚本都不可能工作。

12. 物理连接要求

如果是串口线直连，必须满足：

• TX -> RX
• RX -> TX
• GND -> GND

另外还要注意：

• 电平必须匹配，通常为 3.3V TTL
• 不要把 TTL 当 RS232
• 不要漏接地

如果是飞控 USB 直连电脑，则这一步由 USB 设备自身处理，不需要手动交叉。

13. 复现所需脚本与目录

当前交接包目录为：

D:\\VS Code\\vs ziliao\\Python项目\\PX4_RC_Channel_Handoff

关键文件：

• requirements.txt
• scripts/read_ch7_travel.py
• scripts/monitor_rc_channels.py
• scripts/detect_mavlink_port.py

它们的职责分别是：

• read_ch7_travel.py
  只读第 7 通道，适合业务使用

• monitor_rc_channels.py
  查看所有通道，适合调试

• detect_mavlink_port.py
  自动扫描串口，找飞控在哪个口

14. Windows 从零复现步骤

14.1 安装 Python

检查命令：

python –version

14.2 安装依赖

进入交接包目录后执行：

pip install -r requirements.txt

14.3 连接飞控

两种常见方式：

连上后，Windows 会生成一个或多个 COM 口。

14.4 自动找飞控串口

执行：

python .\\scripts\\detect_mavlink_port.py

正常情况下会输出类似：

FOUND MAVLink: port=COM7 baud=115200 system=1 component=0

这表示：

• 飞控口是 COM7
• 当前波特率是 115200

14.5 运行第 7 通道脚本

例如：

python .\\scripts\\read_ch7_travel.py –device COM7 –baud 115200

14.6 运行全通道调试脚本

如果你不确定是不是第 7 通道，执行：

python .\\scripts\\monitor_rc_channels.py –device COM7 –baud 115200

14.7 判断是否复现成功

成功的最小标准：

15. RK3588 / Jetson / Linux 从零复现步骤

15.1 确认设备名

先看系统里有哪些串口：

ls /dev/ttyS*
ls /dev/ttyTHS*
ls /dev/ttyUSB*

常见设备名：

• /dev/ttyS4
• /dev/ttyTHS1
• /dev/ttyUSB0

15.2 安装依赖

pip3 install -r requirements.txt

15.3 运行脚本

例如：

python3 ./scripts/read_ch7_travel.py –device /dev/ttyTHS1 –baud 115200

或：

python3 ./scripts/monitor_rc_channels.py –device /dev/ttyTHS1 –baud 115200

15.4 判断是否复现成功

标准同 Windows：

16. 主脚本到底在干什么

主脚本 read_ch7_travel.py 的逻辑如下：

这里真正最关键的代码思想只有两点：

工程意义很清晰：

• 先确认链路是飞控
• 再确认飞控真的在输出通道

17. 第 7 通道为什么要同时输出三种形式

脚本没有只输出原始值，而是同时输出三种结果，这是有工程考虑的。

17.1 原始 PWM

例如：

• 1044
• 1494
• 1944

原始值最接近底层真实数据，适合调试、校准、存档、阈值判断。

17.2 0-100% 行程

适合做：

• UI 显示
• 用户理解
• 归一化逻辑

17.3 -100~100 带方向行程

适合做：

• 对称控制
• 中位判断
• 死区控制
• 数学建模

17.4 三段状态

适合做：

• 模式切换
• 业务状态机
• 外部任务开关

因此脚本不是只为了“看一个值”，而是已经把常见使用层面都准备好了。

18. 行程换算为什么会和理论值不完全一致

脚本默认用：

• 1000
• 1500
• 2000

作为标准映射点。

但实际遥控器往往输出：

• 1044
• 1494
• 1944

所以你会看到：

• 高位不是 100%，而是约 94.40%
• 中位不是正好 50%

这不代表脚本错了，而是说明：

• 理论值与实测值有偏差

如果业务要求严格按当前设备标定值处理，可以指定：

python .\\scripts\\read_ch7_travel.py –device COM7 –baud 115200 –min-pwm 1044 –mid-pwm 1494 –max-pwm 1944

Linux 下同理：

python3 ./scripts/read_ch7_travel.py –device /dev/ttyTHS1 –baud 115200 –min-pwm 1044 –mid-pwm 1494 –max-pwm 1944

这时输出就会按当前设备实测值严格归一化。

19. 如何验证到底是不是第 7 通道

不要靠猜。

最稳的验证办法是：

命令：

python .\\scripts\\monitor_rc_channels.py –device COM7 –baud 115200

这样能避免两个常见误判：

20. 这套方法可以扩展到什么程度

一旦你能稳定读取 RC_CHANNELS，很多事情都可以直接做：

例如：

• ch5 切换手动/自动视觉
• ch6 触发拍照
• ch7 触发任务开始
• ch8 作为安全停机

所以本文不是只教“读第 7 通道”，而是在教一套 PX4 外部通道接入方法。

21. 常见错误理解

21.1 误解一：必须直接读接收机

不需要。

只要飞控已经收到了遥控输入，读 PX4 的 RC_CHANNELS 往往是更合理的方案。

21.2 误解二：GPS2 不能当通信口

不对。

GPS2 只要从 GPS 驱动里释放出来，就可以当作普通 UART 使用，特别适合伴飞电脑通信。

21.3 误解三：TELEM 一定比 GPS 更高级

不对。

从物理本质上看，它们都是 UART。区别主要是：

• 默认命名
• 默认功能
• 文档习惯

21.4 误解四：串口能打开就说明方案正确

不对。

正确标准不是“串口能开”，而是：

22. 常见故障排查

22.1 没有 Heartbeat

排查顺序：

先执行：

python .\\scripts\\detect_mavlink_port.py

22.2 有 Heartbeat，但没有通道变化

排查顺序：

先执行：

python .\\scripts\\monitor_rc_channels.py –device COM7 –baud 115200

22.3 通道值变化，但三段判断不理想

原因通常是标定点和实际值不一致。

解决方法：

• 用实测值重新设置 –min-pwm
• –mid-pwm
• –max-pwm

22.4 Windows 能跑，RK3588 不能跑

优先检查：

23. 推荐的复现顺序

从零做，不要乱跳步骤。

建议严格按这个顺序：

这套顺序的目的是把问题拆开：

• 先验证链路
• 再验证通道
• 再接业务

24. 本项目的最终实测结论

本项目最终已经实测证明：

这说明方案本身已经闭环。

25. 最终命令汇总

Windows

安装依赖：

pip install -r requirements.txt

扫描飞控串口：

python .\\scripts\\detect_mavlink_port.py

查看所有通道：

python .\\scripts\\monitor_rc_channels.py –device COM7 –baud 115200

读取第 7 通道：

python .\\scripts\\read_ch7_travel.py –device COM7 –baud 115200

按实测值精确标定运行：

python .\\scripts\\read_ch7_travel.py –device COM7 –baud 115200 –min-pwm 1044 –mid-pwm 1494 –max-pwm 1944

RK3588 / Linux

安装依赖：

pip3 install -r requirements.txt

查看所有通道：

python3 ./scripts/monitor_rc_channels.py –device /dev/ttyTHS1 –baud 115200

读取第 7 通道：

python3 ./scripts/read_ch7_travel.py –device /dev/ttyTHS1 –baud 115200

按实测值精确标定运行：

python3 ./scripts/read_ch7_travel.py –device /dev/ttyTHS1 –baud 115200 –min-pwm 1044 –mid-pwm 1494 –max-pwm 1944

26. 结论

这套方案的工程本质不是“写了一个能看第 7 通道的小工具”，而是建立了一条可复用的 PX4 外部遥控通道读取链路。

掌握这套方法后，你能做的不只是：

• 读取第 7 通道

更重要的是你可以稳定地：

• 让 PX4 向外输出遥控通道
• 让外部设备理解飞控当前的输入状态
• 把飞控内的遥控逻辑延伸到伴飞电脑、工控机、单片机和业务程序

这就是这篇教学真正要解决的问题。