1. 被忽略的地基：为什么V3.0要把通信协议单拎出来讲
写这篇的时候，蓝鸟四轴飞行器V3.0已经完成了机架组装、电调选型和动力系统测试，也就是说，飞机能通电、能转桨、能在地面站里看到姿态数据了。但这时候我还不能推油门起飞，原因很简单：飞控不知道我想让它往哪儿飞。这就要靠通信协议和航模遥控通道来解决。你一定见过不少DIY四轴教程，把重点全放在PID调参和电机焊线上，结果一上控就傻了——接收机信号接对了没有？协议格式对不对？通道映射乱没乱？我觉得这些东西值得单独拿出来写一篇，因为它们在V3.0整个开发链条里，是承上启下的一环：前面所有机械和电气工作的成果，都要通过这一层才能变成飞控能看懂的控制指令；后面所有姿态算法和飞行模式的切换，也都要建立在这层数据之上。
“蓝鸟四轴飞行器初版V3.0”这个系列走到第四篇，前面已经交代过动力配置、机架结构、电源管理。第四篇起这个标题，其实是有点提醒性质的：V2时代我在这块吃过亏，那时候我用的是PPM信号加一个简易接收机，虽然也能飞，但通道数量紧张，信号抖动明显，返航模式占一个通道后几乎没剩余资源做扩展。V3.0既然想把自稳、定高、无头、返航这些模式都做出来，还加了一路可配置的辅助通道，那就必须把通信协议彻底理清楚。这篇适合谁看呢？如果你也在做自己的飞控项目，或者手里的套件总出现“解锁后又自动上锁”“某通道突然跳变”“模式切换失灵”这种毛病，那这篇能帮你省不少排查时间；如果你只是纯小白，想搞懂遥控器和飞控之间到底怎么对话，这篇文章也能给你搭一个完整框架。
通信协议的本质，说白了就是双方约好的一种“说话格式”。遥控器负责把摇杆位移变成数字信息，接收机负责把这信息转成某种标准协议，最后飞控按同一个规则去解读。这里面最容易被低估的，就是“选择哪种协议”这件事——它直接决定了你能用多少个通道、信号实时性有多好、抗干扰能力有多强、以及能不能顺手做遥测回传。所以在蓝鸟V3.0这版里，我不只把协议跑通，还把选型逻辑、帧格式拆解、通道映射、踩坑记录都一并沉淀下来，方便后续版本直接复用。
2. 为什么不能直接读接收机PWM：遥控协议选型的底层逻辑
2.1 PWM和PPM的局限：通道数量与实时性的天花板
很多刚接触航模的人第一反应是：接收机输出线不是直接插飞控吗？几个通道就几根线，每个通道一个PWM信号，这有什么好研究的？确实，最低成本的做法就是让MCU用输入捕获去读每个通道的高电平脉宽，1000到2000微秒对应舵机行程的极限位置。但这么干有几个很实际的问题。首先是通道数量的限制。接收机上每一个通道都要占用飞控一个引脚和一个定时器输入捕获资源，蓝鸟V3.0的飞控MCU引脚本身就要分给IMU、气压计、电机PWM输出、LED、蜂鸣器，如果遥控器用六个通道，光占用还不够，再想做多路的话硬件排线和接口体积也受不了。
其次是实时性问题。PWM读取要等每个周期的高电平脉宽，通常一个完整周期是20毫秒左右，读六个通道就得串行地等六个脉冲，算下来整轮扫描要超过100毫秒。对自稳模式来说，100毫秒意味着控制环已经跑了好几拍，指令变化却迟迟没进来，手感会特别“肉”。PPM信号解决了一部分问题，它把多个通道的脉宽按顺序塞进同一个20毫秒的帧里，只需要一个输入引脚，帧周期仍然是20毫秒，理论刷新率约50Hz。但它的缺点是通道值之间共享一个时间基，解码时对时间精度要求高，而且没有校验机制，一旦干扰丢失一个上升沿，整帧数据就全乱了。
2.2 SBUS、iBUS、CRSF：主流数字协议怎么选
再往上走就是真正的数字协议。SBUS是我在蓝鸟V3.0上的最终选择，它的物理层是UART串口，波特率100000，8个数据位、偶校验、2个停止位，数据帧固定25字节。为什么选它而不是iBUS或CRSF？一个是生态问题：SBUS几乎成了航模接收机的默认选项，无论是富斯、乐迪还是各家廉价接收机，基本都带SBUS输出，兼容性极好。另一个是MCU资源占用问题：SBUS只需要一个UART引脚、一个定时器做超时判断，我用的是STM32F103，串口资源足够分配。iBUS和SBUS格式类似，但它是IBUS协议特有的，需要对应自家接收机，通用性稍差。CRSF是TBS系和部分穿越机接收机用的，波特率420000，帧结构更紧凑，能做全双工遥测，但解析起来复杂一点，而且市面上入门级航模遥控器自带接收机基本不原生支持CRSF。对蓝鸟V3.0这种偏自制、追求通用性的项目来说，SBUS是最省心又不失性能的。
这里有一个容易被新手忽略的细节：SBUS的信号电平习惯是反相的。也就是说，接收机SBUS输出端在空闲时输出低电平，起始位出现时输出高电平，这和普通UART的空闲高电平正好相反。直接接到飞控的RX引脚上，大概率什么都收不到，或者收到一堆乱码。V3.0的飞控板上我专门加了一级三极管反相电路，如果你买的飞控板没做这个处理，就得自己焊一个反相器，或者找支持SBUS反向输入的接收机型号。这个坑后面实测部分我会再细讲。
2.3 从遥控器到飞控的完整数据链路
明白协议选型之后，再看整体链路就清晰多了。蓝鸟V3.0这条链路可以拆成四段：遥控器把摇杆和开关位置编码成射频数据，通过2.4G无线链路发给接收机；接收机解调后，把通道数据按SBUS协议打包，通过串口发到飞控的UART引脚；飞控串口中断服务程序按帧接收并校验数据；最后，数据解析层把各个通道的原始值映射成油门、俯仰、横滚、偏航指令以及模式切换开关量。在V3.0里，模式通道我单独划了一路，用的是三段开关，对应“自稳模式”“定高模式”“返航模式”。另外还有一个辅助通道接的是一个两位开关，用于打开或关闭LED指示灯和蜂鸣器报警。因为SBUS可以承载16个通道，我在代码里预留了CH5到CH16的数据槽位，后续想加云台俯仰控制或者起落架收放，不用改协议，只改映射表就行。
3. 蓝鸟V3.0的SBUS帧格式拆解与解码实现
3.1 25字节帧结构里到底装了什么
SBUS一帧是25个字节，按顺序是：1个起始字节（固定0x0F），然后是22个数据字节，这22个字节里以11比特为一个通道值，总共可以塞下16个通道，之后是1个标志字节，最后1个结束字节（固定0x00）。通道值的范围是0到2047，对应遥控器摇杆的整个行程。这个范围和PWM的1000到2000微秒存在一个对应关系，通常飞控会把它转换成一个float类型的百分比，或者直接在算法层用原始整数做运算。标志字节里存放着几个状态位，最常用的是Bit0和Bit1，分别表示本帧是否丢失信号、是否进入了Failsafe（失控保护）。这两个位对飞控来说很重要，因为它们能直接触发主动保护动作。
如果你拿逻辑分析仪去抓SBUS波形，会看到每一帧大约在7毫秒左右发完，帧与帧之间间隔约为7到14毫秒，也就是说刷新率大致在100Hz到150Hz之间，比PPM的50Hz实时性高了不少。对自稳飞控来说，100Hz的指令刷新率配合IMU内部姿态解算，已经能让手感非常跟手。要注意的是，SBUS一帧是连续字节流，中间没有额外的字节间隔标识，所以解码时只能依赖起始字节0x0F来判断帧头。这就是为什么接收机上电瞬间可能产生半个字节的噪声脉冲，这半个脉冲如果正好是0x0F，飞控就可能把帧边界判断错位。我以前在V2版本里就因为这个原因出现过通道乱跳，后面用“接收完整25字节后才解析，再校验通道值的合理范围”双保险来兜底。
3.2 串口接收与字节拼接的完整实现
解码的第一步是串口初始化。下面是蓝鸟V3.0里实际用的串口配置代码，用的是标准库加串口中断接收方式。波特率100000，数据位8，偶校验，停止位2，其中停止位2是SBUS协议明确要求的，这个不能省：
void SBUS_Init(void) { USART_InitTypeDef USART_InitStructure; GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1 | RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9; // TX，此项目用不到可悬空 GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10; // RX，必须外接反相后的SBUS信号 GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &GPIO_InitStructure); USART_InitStructure.USART_BaudRate = 100000; USART_InitStructure.USART_WordLength = USART_WordLength_8b; USART_InitStructure.USART_StopBits = USART_StopBits_2; USART_InitStructure.USART_Parity = USART_Parity_Even; // 偶校验，一定不能默认无校验 USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None; USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx; USART_Init(USART1, &USART_InitStructure); USART_ITConfig(USART1, USART_IT_RXNE, ENABLE); USART_Cmd(USART1, ENABLE); }串口中断里做的事情很简单：把每个字节按顺序存进缓冲区，同时记录接收到的字节数。等凑满25个字节，就把整个缓冲区的数据交给解析函数处理，然后把接收计数清零，准备下一帧。这里的关键是不要把解析逻辑放在中断里，否则串口中断被长时间占用，会直接影响其他定时器中断的实时性。我之前在一次匆忙调试中试着在中断里做了完整的通道值换算，结果一推油门，电机PWM更新就出现了微秒级的卡顿，姿态环跟着抖。后来改成中断只搬运数据、主循环或定时器任务里解析，问题立刻解决。
接下来是通道值的拼接。SBUS的22个数据字节是连续比特流，第一个字节的最高位是通道0的第7位，依此类推。为了保证可读性，常见的做法是先把25字节帧收齐，用一个64位变量分三次载入，再通过移位取出11位值。下面这段代码是蓝鸟V3.0里实际使用的解析逻辑：
int16_t sbus_channels[16]; uint8_t sbus_lost_frame = 0; uint8_t sbus_failsafe = 0; void SBUS_ParseFrame(uint8_t *buf) { if (buf[0] != 0x0F) return; if (buf[24] != 0x00) return; sbus_channels[0] = ((buf[1] | buf[2] << 8) & 0x07FF); sbus_channels[1] = ((buf[2] >> 3 | buf[3] << 5) & 0x07FF); sbus_channels[2] = ((buf[3] >> 6 | buf[4] << 2 | buf[5] << 10) & 0x07FF); sbus_channels[3] = ((buf[5] >> 1 | buf[6] << 7) & 0x07FF); sbus_channels[4] = ((buf[6] >> 4 | buf[7] << 4) & 0x07FF); sbus_channels[5] = ((buf[7] >> 7 | buf[8] << 1 | buf[9] << 9) & 0x07FF); sbus_channels[6] = ((buf[9] >> 2 | buf[10] << 6) & 0x07FF); sbus_channels[7] = ((buf[10] >> 5| buf[11] << 3) & 0x07FF); sbus_channels[8] = ((buf[12] | buf[13] << 8) & 0x07FF); sbus_channels[9] = ((buf[13] >> 3| buf[14] << 5) & 0x07FF); sbus_channels[10] = ((buf[14] >> 6| buf[15] << 2 | buf[16] << 10) & 0x07FF); sbus_channels[11] = ((buf[16] >> 1| buf[17] << 7) & 0x07FF); sbus_channels[12] = ((buf[17] >> 4| buf[18] << 4) & 0x07FF); sbus_channels[13] = ((buf[18] >> 7| buf[19] << 1 | buf[20] << 9) & 0x07FF); sbus_channels[14] = ((buf[20] >> 2| buf[21] << 6) & 0x07FF); sbus_channels[15] = ((buf[21] >> 5| buf[22] << 3) & 0x07FF); sbus_lost_frame = (buf[23] & 0x01); sbus_failsafe = (buf[23] & 0x02); }有些飞控还会在解析后将13到15通道强制设成中位或某个安全值，但我的做法是保留原始值，交给映射层处理。因为模式通道如果强制成中位，在某些接收机上表现反而像一个中间状态，容易把模式开关卡在奇怪的位置。这一点在我实际测试里出现过，后面会展开讲。
3.3 校验与数据有效性判断：不要只依赖一个起始字节
判断一帧SBUS数据是否有效，光靠起始字节是远远不够的。我见过有人写的解析代码只检查buf[0]等于0x0F就开始取通道值，结果在射频干扰下出现整帧错位。虽然最后一位0x00也能帮忙兜底，但更可靠的做法是把三把锁都加上：起始字节、结束字节、中断接收时的超时判断。超时判断的意义在于，如果SBUS线断开或者接收机掉电，串口中断就不会再产生任何新字节，缓冲区里的老数据会被反复解析。这时候飞控必须知道“已经没有新数据了”。我实现了一个简单的思路：定义一个200毫秒的看门狗定时器，在每次收到新字节时重置；如果定时器溢出说明超过200毫秒没有收到完整帧，就立刻触发失控保护流程。注意，SBUS正常帧间隔最长也就14毫秒左右，200毫秒是一个很保守的窗口，可以避免在信号短暂遮挡时太敏感，也能保证真正掉信号时快速反应。
V3.0里我还额外加了一个“通道合理范围检查”，每个通道解析完成后，如果发现某个值超出0到2047范围太多（比如大于2500），就判定这一帧数据异常，丢弃整帧。这个检查看起来很土，但它能拦住因为硬件故障导致的偶发大毛刺。这些都做完之后，原始SBUS数据才算真正可用。
4. 从原始通道值到飞控指令：通道映射与工程化处理
4.1 摇杆物理行程和飞控指令值的关系
SBUS解析出来的是0到2047的原始整数，但飞控内部使用的不一定是这个数。蓝鸟V3.0的代码里，我把原始值先减去992再除以992，得到一个大致在-1.0到+1.0之间的浮点数，这个浮点数代表摇杆偏离中位的程度。为什么是992而不是1024？因为992对应的是摇杆中位（所谓“回中”）时SBUS的典型值，而通道量的满行程是0到2047，中位应该在1023.5附近。我取992是考虑到很多遥控器可以通过微调按钮改变中位默认值，并且不同品牌接收机输出的中位值有细微差异。这个归一化值在后续PID控制器里用法很直接：横滚通道的归一化值直接乘以最大横滚角速度设定值，得到的控制目标传给姿态环。
归一化之后，还需要加一个安全限幅。比如归一化值理论范围是-1.0到1.0，但为了让飞控行为更柔和，V3.0里默认把自稳模式下的最大值限到0.8，也就是说即使你猛打满杆，横滚角速度最大也就是预设值的80%。这个设计对新手特别友好，也避免某些情况下电机瞬间满油门造成飞机猛蹿。当然在特技模式和手动模式下，限幅会放开到1.0。
4.2 死区、中位校准与滤波策略
摇杆在机械结构上很难做到绝对居中，就算你手不动，电位器或霍尔传感器也会有微小偏移。如果不加死区，飞控会认为飞机一直在缓慢自转或倾斜，姿态环就会一直输出修正量，在地面推油门时飞机就会明显“点头”。V3.0的处理方法是：归一化值绝对值小于0.03时直接置为0，0.03这个宽度就是死区。死区大小的选择要权衡手感，死区太大飞机发飘，太小地面试车时容易误动作。0.03是我在多次室外飞行后定的值，比较适合我这台飞机的轴距和电机响应速度。
滤波方面，我没有做特别复杂的算法，因为SBUS本身刷新率已经到100Hz以上，控制环用的是500Hz，多余的采样点不足以造成明显波动。我只对遥控器通道值做了一阶低通滤波，时间常数设定为5毫秒。这个滤波只作用于部分辅助通道和油门通道。横滚、俯仰通道不建议滤波太狠，否则你会感觉输入滞后。ADRC和自稳算法本身已经有一定的平滑性，输入再被深度滤波，会让飞机在猛打舵时看起来反应迟钝，手感上特别难受。
4.3 通道AETR映射与模式判定逻辑
每个飞行器厂家对通道的定义可能不一样，最常见的有两种：AETR（副翼、升降、油门、方向）和TAER（油门、副翼、升降、方向）。V3.0固件里我默认按AETR来写，也就是CH1副翼、CH2升降、CH3油门、CH4方向。代码里用一个数组做了映射表，想切换为别的顺序，改表就行，不用动控制算法代码。
模式通道我放在CH5，这个通道读出来的是一个三段开关的位置，对应不同的固定值区间。判定逻辑如下：原始值小于700判定为“自稳模式”，700到1350判定为“定高模式”，大于1350判定为“返航模式”。这里有个细节容易踩坑：不同遥控器三段开关的输出值分布并不统一，有的品牌1001-1499-1999这种间隔很大，有的则可能是800-1200-1600。直接拿两个固定阈值去切，可能会在某次机械磨损后误判。V3.0里我加了一次数值区间的滞后处理：比如当前在“定高模式”，那么只有通道值降到小于650才切回“自稳模式”，大于1400才切到“返航模式”，这样开关抖动或中间接触不良时不会反复切换模式。滞后区间的宽度约为50到100，具体看三段开关的档位距离，我在调试时有专门做了一版“模式显示页面”来实时观察。
4.4 油门缓启动与解锁判定：防止意外上电
四轴最危险的时候不是在空中，而是在地面。如果你推油门时协议稍有错乱，电机瞬间满转，桨叶能直接削到手指。V3.0里我专门写了一个“解锁”流程：接收机通电后，飞控检查遥控器油门通道是否低于阈值（一般是归一化值小于-0.85），此时飞控上的LED会快闪表示待解锁；将这个低油门状态保持3秒以上，如果同时方向通道在最左位置，才允许解锁；解锁后电机进入待机转速，然后按油门曲线控制。任何一次通道值异常、SBUS丢帧超过200毫秒，都会立刻触发电机停转保护，需要重新走解锁流程。
此外还有一个油门缓启动逻辑：解锁后如果直接大油门，油门通道值不会被立即全部生效，而是按每100毫秒最多增加5%的步伐逐步逼近目标值。这个设计在室外飞行时可能觉得略保守，但对新手和首次调试非常有用，能让任何接线错误或动力配置异常在转速升高之前暴露出来，而不是一推杆飞机就窜出去。
5. 实测阶段踩过的坑与完整排查链路
5.1 SBUS反相信号问题：插上就乱码的真相
第一次把V3.0飞控和接收机连起来时，我打开地面站的通道监视器，屏幕上一片雪花，数值乱跳。当时我的第一反应是接线没插好，于是重插、换杜邦线、接地线都试了一遍，状况依旧。后来用逻辑分析仪抓串口波形才明白：接收机的SBUS输出是反相电平，飞控的UART硬件无法直接识别。这也是很多DIY飞控板会明确标注“SBUS需反相信号”的原因。解决方法是加一级反相电路，一个NPN三极管加两个电阻就能搞定，或者直接用带有硬件反相功能的接收机。蓝鸟V3.0后续版本直接在板上集成了一颗反相缓冲芯片，输入端标了“SBUS_INV”，从此再没遇到这个问题。
排查这类问题时千万不要跳过示波器和逻辑分析仪。眼看地面站数值乱跳，只能说明信号不对，但到底是不满帧、字节错位还是电平反相，肉眼根本分辨不了。拿逻辑分析仪看波形，一眼就能看出空闲电平是低还是高、起始位位置对不对、波特率是否匹配。如果你手里没有逻辑分析仪，也可以用串口助手以100000波特率、偶校验、2停止位的参数直接抓数据，如果收到的字节大多不是0x0F开头，基本上就是反相或者配置不对。
5.2 解锁后电机微转方案：被忽略的油门中位校准
蓝鸟V3.0在第一次解锁测试时出现了一个奇怪的现象：遥控器油门已经放到最低，但解锁后四个电机都以很低的转速“嗡嗡”转，看起来像怠速。检查电调校准没问题、油门曲线也没问题，最后发现是SBUS通道的原始中位值偏了。我手里这支遥控器油门通道的中位输出不是1024，而是1010左右，按照之前的归一化逻辑，油门最低时算出的是一个略大于-1.0的值，程序判定“油门没有完全归零”，于是把电机怠速激活了。
解决方法是加一段“上电自动校准”：在飞控上电后保持遥控器油门最低状态的前两秒内，采样油门通道的原始值，把这个值作为当前遥控器的“最低油门基准点”，之后所有归一化计算都基于这个基准点而不是固定值。这个思路也被我沿用到了其他通道：方向、副翼、升降在中位时各做一次采样，记录为基准中位。这样一来，换遥控器、换接收机都不用再改代码里的固定常量。要注意的是，这个自动校准逻辑必须和“解锁流程”紧密配合，因为如果解锁前你随便拨动过油门，自动校准值就会漂移。V3.0里的处理方式是：只有在未解锁且油门通道保持低位超过1秒时，才允许刷新校准值。
5.3 模式开关抖动引发的掉模式：滞后区间怎么定
定高模式试飞的时候，又发现一个新问题：飞行中会突然从“定高模式”掉回“自稳模式”，然后再切回去。底盘监控日志显示，模式通道原始值在某些时刻从1200跳到980，时间只持续几十毫秒，然后又跳回来。这不是遥控器坏了，而是三段开关在拨到中间档时，触点接触可能出现瞬时电阻波动，导致输出值抖动。飞控如果不处理这个抖动，就会在短时间内连续切换模式，姿态控制目标突然变了，飞机就会点头或下沉。
我处理的方案是前面说的滞后判断，外加一个时间窗口。模式判定的代码里规定：通道值必须连续30毫秒保持在目标区间内，才真正进行模式切换；切换完成后，如果后续数值抖动，只有在超出另一个更宽的阈值带时才允许再切回去。这样我平时拨动开关时，模式切换的响应延迟大约在30到50毫秒之间，手感上完全无感，但可靠性提升了一个档次。如果你也遇到类似的模式飘移问题，建议先在地面站上记录一段通道原始值波形，看看抖动幅度到底有多大，再设定合理的滞后区间，不要盲目把区间设得很宽，否则模式切换会变得很迟钝。
5.4 Failsafe误触发的连锁反应：从日志定位到接收机特性差异
这个问题是我在后期做失控保护测试时偶然发现的。飞控通过SBUS状态字节的Bit1来检测Failsafe，逻辑很简单：该位为1时进入保护模式，电机停转并保存姿态数据。但实测中我发现，有一种廉价接收机在射频信号被遮挡时，状态字节的Bit0会先变成1，Bit1隔了几十毫秒才变成1；而另一种接收机则是两个位同时跳变。如果程序只关注Bit1，就会在这几十毫秒内收到若干帧“信号丢失但未触发保护”的数据，飞控如果按照这些帧里的通道值继续飞行，姿态就会小幅漂移。
蓝鸟V3.0的解决办法是：把“丢帧标志”和“Failsafe标志”都纳入触发条件，只要Bit0为1且持续超过50毫秒，或者Bit1为1，就停止使用通道数据，进入保护逻辑。同时，在保护逻辑里对已经存入的通道值做限幅，防止某些接收机在Failsafe时输出的通道值跳到最大油门方向。这个坑最值得说的不是解法本身，而是排查方式：我用地面站日志把每一帧SBUS的原始状态字节都记录下来，和实际遮挡射频信号的时刻做时间对齐，才逐渐看出两种接收机之间的行为差异。建议所有做飞控的朋友都在日志里把原始状态字节直接打出来，而不是只记录“是否触发保护”的结论，否则这种细节永远不会暴露。
6. 蓝鸟V3.0通信模块的可复用设计总结
到最后，我想把V3.0里通信协议这一整块做成什么样子说清楚。当前固件里，SBUS解析、通道归一化、模式判定、失控保护这几件事被拆成了各自独立的模块，模块之间通过几个全局结构体传递数据。这样可以做到“遥控器协议”和“飞控控制算法”完全解耦：今天用SBUS，明天想换成CRSF，只需要重写最底层的解析模块，把数据填充到同一个结构体里，控制层完全不用动。结构体定义大概是这样的：
typedef struct { float ch_roll_target; // -1.0 ~ 1.0 float ch_pitch_target; // -1.0 ~ 1.0 float ch_throttle_target; // -1.0 ~ 1.0，控制层换算成百分比 float ch_yaw_target; // -1.0 ~ 1.0 uint8_t flight_mode; // 0自稳 1定高 2返航 uint8_t aux_bits; // 辅助开关状态 uint8_t frame_lost; // 丢帧状态 uint8_t failsafe; // 失控保护状态 uint16_t raw_channels[16]; // 保留原始值，方便调试 } RC_Control_t;这套设计让我在V3.1上可以直接加遥测回传功能。SBUS虽然本身是单向协议，但接收机上常伴随一路Sport口或者共享串口输出遥测数据，我在接线时已经把飞控另一个UART预留给了遥测。到这里，这篇关于通信协议和航模遥控通道的分享就告一段落，后面如果大家有兴趣，我可以再写一篇关于V3.0定高和返航模式调参的实测记录。我自己在这个过程中最大的体会是：通信协议看起来只是一堆字节的搬运，但它决定了整个飞行系统在最坏情况下能否安全地“停下”，这比它能把航线飞得多准更重要。希望这篇能帮你少走几步弯路。
