TVC模型火箭炸机排查：RC链路与舵机执行的时序匹配关键比值

做TVC模型火箭这几年，我炸掉或者半空中打转的样机至少有五台。每次复盘，飞控解算逻辑都没查出大问题，最后几乎都收敛到同一个地方——RC遥控链路和TVC舵机执行链路之间的时序匹配。

这不是玄学。模型火箭的TVC控制里，推力够不够、舵机扭力大不大，其实很少是失败主因；真正让箭体在天上画圈、左右抽风甚至直接翻滚的，往往是“指令到达的速度”和“舵机消化的速度”之间的比值踩了坑。RC信号一帧可能20毫秒，飞控一个控制周期可能2.5毫秒，舵机转45度可能要80毫秒——这三个数摆在一起，顶层指令、中层运算、底层执行三者的节奏天然就不一样。怎么把这些节奏对齐，就是标题里说的“时序匹配关键比值”。

这篇文章写给正在做TVC火箭、或者准备入坑火箭/无人机姿态控制的朋友，尤其适合那些已经被“推杆没反应、松杆还在转”折磨过的人。我会把链路里每一段延迟掰开，给出三个可以直接套用的比值公式，再讲一套用逻辑分析仪实测标定的方法，最后是我踩过几次坑之后总结的调优顺序和选型建议。

1. 先拆信号链路：从摇杆到发动机喷口之间有哪些延迟

1.1 五个环节的延迟账本

要聊时序匹配，第一件事是把“RC指令变成喷口偏转”这条链路拆开。我在做二号样机的时候，把每一段延迟都单独测过，后面对照故障现象特别有用。这条链路大致分五段：

1. 遥控链路。发射机摇杆数据经过2.4GHz射频发出，接收机收到并解码。这一段按协议不同，普遍在4到10毫秒之间。PPM这类老协议因为帧头检测和滤波，延迟会偏大；SBUS这类数字协议稳定在3到5毫秒左右。

2. 接收机输出。接收机解出来的通道数据要按固定周期输出。PWM是逐通道串行输出，一个周期20毫秒；PPM一帧通常22到25毫秒；SBUS一帧14毫秒。这里必须强调一下，很多人把“接收机解码延迟”和“接收机输出帧周期”混为一谈，其实是两个独立的延迟源。解码延迟只有几毫秒，但输出帧周期会直接决定顶层指令的“刷新率”。

3. 飞控采集与预处理。飞控要等一个完整帧才能拿到全部通道值，然后做滤波、限幅、映射。如果飞控主循环是400Hz，即2.5毫秒跑一次，那么从接收机输出到飞控内部拿到可用指令，通常要等0到2个主循环，最多5毫秒。

4. 伺服驱动刷新。飞控算出的舵量，最终要通过PWM信号发给舵机。舵机PWM刷新率常见的有50Hz（20毫秒周期）、100Hz、250Hz甚至更高。这个刷新率和飞控控制周期能不能形成整数关系，直接关系到后面的“拍频抖动”问题，后面细说。

5. 舵机机械动作。这是整条链路里最大的一笔延迟。普通塑料齿舵机，空载从0到45度大约要80到120毫秒；金属齿高速舵机能做到50到70毫秒；工业级线性舵机更快，但尺寸和重量就上去了。这笔延迟不是“传输延迟”而是“执行延迟”，它的特点是：无论指令发得多快，舵机物理上就是快不起来。

把这几段放在一起看，你就能理解为什么会出现“指令已经发出去一堆，但舵机还在慢慢走”的状态。顶层的RC指令可能每秒刷新50次，中层的飞控每秒计算400次，底层的舵机每秒只能完成一个完整行程的十几分之一。三者天然脱节。

1.2 一个类比：寄信很快，不等于办事很快

我用一个生活化的类比帮朋友理解过这件事。假设你指挥一个人搬砖，你的喊话速度是每秒钟喊一次“搬这块”，但对方搬一块砖要十秒。十秒之后你已经喊了十次，对方才刚搬完第一块。真正的问题不是喊话速度比搬砖手速快或慢，而是指挥系统和执行系统的固有节奏不一样，这个差距必须靠匹配来弥补，不能靠硬催。

RC和TVC的关系本质上就是这样。RC是“喊话系统”，提供的是意图；TVC舵机是“搬砖系统”，提供的是执行力。两者的节奏比值如果不在合理区间，要么指令积压导致系统持续滞后，要么舵机被“命令追赶”导致反复过冲。这就是“关键比值”四个字的来由——它不是某一个具体数值，而是一组描述节奏差的比值。

2. 三个关键比值：刷新比、执行比、响应比到底在算什么

2.1 刷新比CR：RC命令帧间隔与控制周期的关系

第一个要看的比值为刷新比（CRatio），公式是：

CR = T_cmd / T_ctrl

其中T_cmd是RC接收机的输出帧周期，T_ctrl是飞控控制周期。

举几组真实组合：

• PPM输出，T_cmd=22ms，飞控400Hz，T_ctrl=2.5ms，CR = 22 / 2.5 = 8.8
• SBUS输出，T_cmd=14ms，飞控400Hz，T_ctrl=2.5ms，CR = 14 / 2.5 = 5.6
• PWM逐通道输出，T_cmd=20ms，飞控200Hz，T_ctrl=5ms，CR = 20 / 5 = 4

这里的关键点：CR如果不是整数，就会出现“拍频效应”。打个比方，8.8倍的关系意味着每8到9个控制周期里，RC帧的到达时间会相对飞控主循环“滑动”0.2个周期。于是舵机指令每隔一段时间就会多等一拍或者提前一拍，表现出来的现象就是：摇杆不动时舵机也轻轻抖，摇杆微微推一点，舵机会“喘”。

我实测过，CR的小数部分在0.2到0.8之间时，舵机上能看到明显的低频抽动。换算成角度，在10度满偏的TVC系统里，大约有0.3到0.5度的随机摆动。对姿态控制来说，这个量级的舵面抖动会直接转化为箭体的轻微震动，高速相机里看非常明显。

所以第一个调优动作通常是让CR尽量接近整数。具体办法是调整飞控主循环频率，或者改用帧周期能被整数整除的配置。比如主流飞控跑400Hz时，配帧周期20ms的PPM就是CR=8，很干净；配帧周期14ms的SBUS是5.6，反而更差。很多人的直觉是“SBUS快所以好”，但从时序匹配角度看，整数倍关系比单纯快更重要。

2.2 执行比AR：舵机到位时间与控制周期的比值

第二个比值是执行比（ARatio），回答的问题是：飞控的决策节奏能不能被舵机及时落实。

AR = T_servo / T_ctrl

T_servo取舵机完成一次典型满偏行程的实际时间，不是商家标称速度，而是负载条件下实测的到位时间。为什么这个比值特别关键？因为它直接决定控制回路的稳定性边界。飞控每T_ctrl毫秒算一次误差并输出一个新舵量，但舵机要T_servo毫秒才能真正到位。

如果AR太小，比如小于3，说明舵机比飞控还快，指令更新相对稀疏，系统的控制权力得不到充分利用，但一般不会失稳。如果AR太大，比如大于30，说明舵机严重跟不上飞控节奏，飞控看到的永远是“旧状态”，这时候增益稍高一点，系统就会进入经典的自激振荡。

我攒出来的经验窗口是AR在8到20之间。举一个算例：飞控400Hz，T_ctrl=2.5ms，舵机实测45度行程耗时60ms，AR = 60 / 2.5 = 24，偏高。这时候把控制周期降到200Hz，T_ctrl变成5ms，AR就是12，落在舒适区。

这里有个反直觉的点要提醒：控制频率不是越高越好。很多人觉得飞控跑400Hz比200Hz“高级”，但在TVC这种执行环节响应慢的系统里，高控制频率只是让飞控反复对“还没变化的误差”做积分，反而容易积累积分项、引发超调。把控制频率降下来，让运算节奏和执行节奏形成合理比值，才是正路。

2.3 响应比TR：箭体姿态响应与舵机速度的匹配

第三个比值是响应比（TRatio），刚上手的朋友往往想不到这个维度。

TR = T_att / T_servo

T_att是箭体对舵量阶跃输入的姿态响应时间常数。说白了就是：你把舵机猛地偏到一个角度，陀螺仪检测到姿态开始明显变化需要多少毫秒。这个值和箭体质量、转动惯量、推力大小、喷口力臂都有关系，没法从舵机选型单上查到，只能实测。

TR的物理意义是“舵机工作量”和“箭体反应速度”之间的平衡。TR偏大，说明箭体反应很慢，舵机又转得快，飞控会倾向于打过量——舵机到位后箭体半天没反应，误差积分越积越猛，最后箭体突然加速，直接过冲。TR偏小，说明箭体反应很快但舵机跟不上，飞控算出的修正量还没执行完箭体已经开始响应，双重滞后叠在一起，很容易发散。

我做的几型样机里，小推力验证箭T_att大约在80到120ms，舵机60ms，TR约1.3到2；中型样机T_att约150到200ms，舵机70ms，TR约2到2.8。整体来看TR在2到4之间比较平衡。

2.4 三个比值的联动逻辑

单独看每个比值可能还觉得抽象，放在一起就能看出联动关系：

• CR决定意图更新的粒度。动作要细腻，CR要够大，也就是控制周期相对RC帧足够密。
• AR决定飞控节奏和执行节奏的匹配。要稳定，AR不能太小也不能太大。
• TR决定执行速度和箭体物理响应的匹配。要平顺，TR落在2到4。

三者不是各自独立的。比如你把飞控控制频率从200Hz提到400Hz，CR翻倍，但AR也翻倍，可能滚出舒适区，TR不变。所以每次调控制频率，都要同时重算三个比值，只看其中一个很容易把另一个调坏。这也是为什么我建议把三个比值写成一个电子表格，每次改参数自动刷新。出厂调参时这个表格能省掉一半的返工时间。

3. 实测标定：五个基础延迟量怎么测、怎么算比值

3.1 需要的工具和接线

比值这东西只靠纸面估算不够，因为舵机到位时间受负载、电压、温度影响很大。建议至少准备：

• 四通道逻辑分析仪或者双通道示波器
• 两个采样点：接收机通道输出端（测T_cmd）和舵机PWM输入端（测舵机指令刷新周期）
• 一个带PWM输出的信号模拟器，或者直接用遥控器加接收机

接线很简单：逻辑分析仪的CH1夹在接收机的通道输出引脚上，CH2夹在飞控到舵机的PWM输出引脚上。两个探头同时抓，顶层RC帧和底层舵机指令的时间关系就能一次性记录下来。

要测T_servo，最好在舵机转轴上加一个轻质拨杆和反光标记，用光栅或者高速摄像头记录位移。没有这些设备的话，用手机240帧慢动作视频也勉强凑合。关键点是别只信舵机标称速度，负载下的真实到位时间和标称值可能差出50%。

3.2 T_cmd和T_ctrl的测量步骤

1. 上电，保持摇杆中位，让接收机和飞控正常工作。
2. 逻辑分析仪采样率设到1MHz以上，抓5秒数据。
3. 在接收机输出通道上数相邻两个上升沿的间隔，取平均值，这就是T_cmd。
4. 在舵机PWM输入端数相邻两个脉冲周期的间隔，取平均值，这就是飞控实际输出周期T_srv。注意，T_srv不一定等于T_ctrl，因为飞控可能做了输出降频或插值。

这里有一个常见误区：很多人以为飞控主循环是多少Hz，舵机PWM就是多少Hz。实际上很多飞控为了兼容不同舵机，会在主循环之外单独设置PWM输出频率。我遇到过主循环400Hz、PWM输出却默认50Hz的情况，两个周期差了8倍，等于飞控算完8次才更新一次舵机指令。所以T_srv必须实测，不要只看配置界面里的数字。

拿到这些数据后，可以用一小段脚本计算比值。以下是我常用的参考脚本：

import statistics # 实测时间序列，单位均为毫秒 T_cmd_list = [22.1, 22.0, 22.2, 21.9, 22.1] # 接收机输出帧间隔 T_ctrl_list = [2.50, 2.51, 2.49, 2.50, 2.50] # 飞控控制周期 T_servo = 62.0 # 舵机负载下90%到位时间 T_att = 110.0 # 箭体姿态响应时间常数 T_cmd = statistics.mean(T_cmd_list) T_ctrl = statistics.mean(T_ctrl_list) CR = T_cmd / T_ctrl AR = T_servo / T_ctrl TR = T_att / T_servo print(f"CR={CR:.2f} AR={AR:.1f} TR={TR:.1f}")

把每次实测的数据填进去，自动输出三个比值，对照判定表就能快速定位问题出在哪一环。

3.3 T_servo的测量步骤

1. 给舵机接上真实负载，最好是装在箭体上、连好喷口联动机构的状态。
2. 通过遥控器给一个满偏阶跃指令，从0度推到最大偏角。
3. 用慢动作视频或者编码器记录角度变化曲线。
4. 读取从指令发出到角度到达目标值90%位置的时间，作为T_servo。

多测几次取平均。舵机在不同起始位置的响应速度不一样，负载下的非线性很明显。我一般会分别测0到45度、-45到45度、0到最大三个工况，用最差工况的数值参与AR计算。宁可保守一点，也别把系统设计在实测边界上。

3.4 T_att的测量方案

T_att最靠谱的做法是地面台架试验。把箭体固定在万向节台架上，让TVC舵机能真实偏转并施加推力（或者用压缩空气替代发动机，推力输出更平稳）。给一个阶跃舵量，记录陀螺仪角速度数据，从阶跃开始到角速度稳定到最终值63%左右的时间就是T_att。

没有台架条件的话，可以用一次短时间系留点火试验凑合。具体做法是把箭体用细绳系在杆上限制运动范围，点火后给阶跃舵量，读取飞控记录的陀螺仪日志。数据稍微糙一点，但量级是准的，做比值估算足够。

3.5 一张判定表：测得比值后怎么给结论

把实测值带入三个比值公式后，按下面这张表快速定位问题。这张表是我根据几轮样机的数据和一些理论分析总结的，不一定放之四海皆准，但作为起点很实用。

每一条结论我都在实际项目里见过。比如AR偏大的典型表现，是箭体在爬升段出现越来越猛烈的横向摆动，摆幅从0.5度逐渐增大到5度以上，最后直接翻滚。把AR从30多降到15左右，同样的参数增益下，摆动立刻收敛。

4. 调优实战：抖动、振荡、滞后三类故障的排查链路

4.1 故障一：摇杆不动舵机却在喘，先查CR的整数性

现象：遥控器摇杆完全中位，舵机每隔一两秒轻轻抖一下，或者持续高频微颤。飞控日志里舵量输出在±0.3度范围内来回跳。

这类故障十有八九是CR不是整数。排查链路如下：

1. 用逻辑分析仪抓T_cmd，确认接收机的实际帧周期。PPM协议在不同接收机上的帧周期差别很大，有的标称22ms，实测可能是22.6ms。
2. 确认飞控主循环频率，算出CR的小数部分。
3. 如果CR小数部分在0.2到0.8之间，优先调整飞控主循环频率，调到能让CR接近整数的数值。
4. 如果调主循环频率不方便，退而求其次：在飞控里对RC指令做保持加限幅处理。检测到相邻两帧指令变化小于阈值时，把舵量锁存在最后一次有效值，不随RC帧的到达节奏抖动。这个办法能消除大部分拍频抖动，代价是响应会稍微钝一点。

我在一次实测里对比过：调主循环频率让CR从8.8变成8.0之后，舵机抖动幅度从0.4度降到0.05度以下。后来那台样机的飞行日志里，横向角速度噪声也明显降低。

4.2 故障二：爬升段摆幅越来越大，先查AR是否滚出舒适区

现象：点火后箭体姿态正常几秒，然后开始左右小幅摆动，摆幅随时间增大，最终失去控制。这是TVC火箭最经典的失败模式。

这类故障的核心嫌疑是AR偏大。排查链路：

1. 回放飞控日志，看舵量输出频率。如果舵量在控制周期内变化很快，但箭体角速度响应明显滞后，说明执行端没能跟上决策端。
2. 实测T_servo，确认舵机在负载下的真实到位时间。注意检查舵机供电电压，电压不足时到位时间可能翻倍。
3. 计算AR，如果大于30，优先降低飞控主循环频率，或者降低舵量输出更新率，让AR回到20以内。
4. 同时检查控制增益。很多人遇到振荡时第一反应是降P增益，确实有效，但如果不解决AR问题，增益降到一定程度后系统虽然不振荡了，反应也麻木了，起飞段扛不住风扰。正确顺序是先解决时序匹配，再回到增益上做微调。

我还遇到过一个隐蔽原因：舵机PWM刷新率太低。主循环400Hz、PWM输出50Hz时，每8个控制周期才更新一次舵机指令，而且更新时刻可能集中在某个相位，等效于给控制系统注入一个20毫秒周期的大延迟。把PWM刷新率提到200Hz以上之后，AR不变，但等效延迟大幅下降，振荡明显减弱。这个参数极容易被忽略，实际影响却极大。

4.3 故障三：推杆没反应、松杆还在转，先查链路累计延迟

现象：遥控输入后箭体响应明显迟钝，像喝醉了酒。推杆一两秒后才看到姿态变化，松杆后姿态还会继续偏一会儿。这时候CR、AR单独看可能都正常，但整条链路的累计延迟超过了箭体姿态响应的容忍范围。

排查链路：

1. 把链路各阶段延迟相加，得到总延迟：RF解码延迟、接收机输出帧周期、飞控处理延迟、舵机指令刷新延迟、舵机到位时间。
2. 把总延迟和T_att比较。如果总延迟超过T_att的一半，系统响应就会明显变肉。
3. 优先干掉最大头的延迟，绝大多数情况下是舵机到位时间。换更快的舵机，或者用机械臂比合理降低最大偏角，都能直接缩小T_servo。
4. 其次考虑接收机协议升级。如果还在用PPM、PWM，换成SBUS这类数字协议，帧周期从20多毫秒降到3到5毫秒，总延迟立刻小一截。

我在某个实验里对比过：PPM链路加普通舵机，总延迟大约130ms；换成数字协议加高速舵机，总延迟降到75ms左右。同样的控制增益下，前者起飞后摆动1.8度，后者全程稳定在0.4度以内。这个差距不是某一个参数决定的，而是整条链路每一段都在抠。

4.4 调优顺序总结：先匹配时序，再调增益

把几轮迭代的经验浓缩成一句话：调时序匹配永远是调增益的前置步骤。具体顺序建议这样走：

1. 先测T_cmd、T_ctrl、T_srv、T_servo、T_att五个基础量。
2. 算CR、AR、TR三个比值，对照判定表。
3. 优先解决CR整数性问题，消除抖动源头。
4. 再调整控制频率和PWM刷新率，让AR进入8到20舒适区。
5. 最后在AR满足的前提下微调PID增益，追求灵敏度和稳定性的平衡。

这个顺序反过来操作，就会陷入“降增益→没力度→加增益→振荡”的死循环。我在二号样机上整整浪费了两周调参时间，才意识到问题不在PID，而在时序。先搞定时序，后面所有的增益调整才有意义。

5. 选型与配置：不同箭体怎么定参数，以及我踩过的三个坑

5.1 不同规格箭体的推荐参数区间

以下是我根据几型样机和身边同好的数据整理出来的参考区间，供选型时快速定位。注意这些参数要配合前面的比值逻辑使用，不要死记数值。

大推力箭体的T_att通常更大，因为转动惯量大，所以TR反而容易满足，此时重点是别让AR滚出边界。控制频率往往不需要太高，100到150Hz就够用，这和很多新手的直觉相反。

5.2 RC协议和飞控配置的搭配建议

PWM协议帧周期20毫秒起步，多通道串行输出时实际帧周期可能更长。优点是兼容性最好，缺点是CR很难做到整数倍且延迟偏大，建议只在小推力慢速验证箭上使用。

PPM协议一帧22到25毫秒，所有通道共用一帧，比PWM略好，但同样存在周期偏长、容易拍频的问题。

SBUS协议延迟低、抗干扰好，但帧周期不能只信标称的14毫秒，不同接收机实际在11到16毫秒之间漂移。拿400Hz主循环算，CR=14/2.5=5.6，非整数；拿200Hz算，CR=14/5=2.8，也非整数。所以单靠选协议解决不了CR整数性问题，正确思路是接受SBUS的低延迟优势，同时在飞控端做指令插值来平滑拍频。

指令插值的做法不复杂：飞控每收到一个新RC帧，不直接替换当前控制目标，而是把目标值分摊到后续若干个控制周期里线性逼近。这样无论RC帧周期是14毫秒还是22毫秒，飞控都能平滑过渡，拍频抖动被天然过滤掉。这个手法在飞行器控制里很常见，做TVC一样适用。

5.3 舵机选型时被低估的两个指标

大多数人选舵机只看扭力和速度标称，我建议再加两个指标。

第一是满行程时间的一致性。舵机从0到满偏和从满偏回0的耗时如果差30%以上，会导致控制不对称，箭体表现为左右修正力度不一致，轨迹画弧。实测确认过差异超过20%就换货。

第二是负载下的到位时间。这是老生常谈但必须重复：空载速度和负载速度完全两回事，尤其是TVC这种需要克服气动力矩和惯性力矩的场景。务必在真实负载下测一遍T_servo再参与比值计算。

5.4 我踩过的几个具体坑

第一个坑是发射机摇杆回中死区。有些遥控器摇杆中位的电位器信号存在死区，飞控看到的指令在±2%范围内抖动，这个抖动经过TVC放大后会变成箭体的蠕变。解决办法是在飞控里设一个较小的指令死区，只对遥控器原始值做处理，不要对舵量输出做死区。输出死区会让姿态产生静差，得不偿失。

第二个坑是舵机供电瞬态跌落。TVC满偏瞬间电流很大，供电线过细或者稳压裕量不足时，电压瞬间跌落会让舵机到位时间翻倍，AR直接从舒适区滚出边界。我后来统一用较粗的硅胶线专门给舵机供电，并且在舵机供电端加了大容量电容做局部储能，这个坑才彻底堵住。

第三个坑是飞控初始化阶段的RC帧丢失。某些接收机在上电初期的前几百毫秒会输出不完整帧，飞控如果把这些帧当正常指令解析，可能输出一个异常大舵量。做法是飞控加一个有效帧门限：连续收到N个合法帧后才开始使用RC指令，之前保持零舵量输出。这个N我习惯取10到20，按当前帧率就是零点几秒，成本极低但能避免很多莫名其妙的起飞段异常。

说了这么多，其实核心就一句话：RC和TVC之间不是谁快谁慢的问题，而是节奏比值合不合理的问题。每次改动任何一个参数——换舵机、换接收机协议、调控制频率——都值得把三个比值重新算一遍。花十分钟算账，省下来的可能是又一次炸机和一整周的重建时间。

这套时序匹配思想不只在火箭TVC上有用。凡是“远程指令加本地执行”的结构，多旋翼的遥控链路与姿态环、地面机器人的RC指令与关节伺服、甚至工业机械臂的示教盒与电机驱动，都遵循同样的节奏逻辑。你在这台火箭上练出来的“先测延迟、再算比值、最后调参”的思路，换个项目照样能用。

我个人现在做新样机的第一件事，就是先把五个基础延迟量挂到测试台上测一遍，哪怕花掉一个下午。这个习惯是从二号样机炸掉之后养成的，几年下来回报极高。希望这篇东西能让你少走同样的弯路。