【嵌入式】传感器到执行器：一条控制信号在硬件中经历了什么

上一节我们把连续的机械臂运动切成了 MCU 能处理的离散节拍：在时刻 $k{T}_s$ 读取一次状态，计算一次 $u[k]$，再由保持器让这条指令作用到下一拍。
但“读取状态”和“输出指令”并不是两句代码就能完成的事。编码器不会直接说出 $\theta [k]$，电机也不会直接接收 $u[k]$；它们之间隔着传感器、供电、调理电路、外设寄存器、PWM、驱动器和功率器件。真正的闭环，正是在这些硬件环节中一站一站地走完。

文章摘要

本文沿着单关节机械臂控制周期，追踪状态信息从编码器、电流传感器出发，经过信号调理、ADC 或计数器、寄存器和控制任务，如何成为可计算的状态；再说明控制量如何变成 PWM、栅极驱动、电桥电流与电机力矩，最终推动关节运动。文章重点区分信息链与能量链，解释采样精度、噪声、单位换算、同步、死区、保护和时延在何一环进入闭环，并给出调试顺序与工程检查清单。读者将理解：控制算法输出的并非直接作用于机械臂的力，而是需要被硬件翻译、放大、约束和验证的指令；每一级器件的误差、延迟和故障，都会重新塑造闭环看到的对象。

写在前面

还是回到单关节机械臂。

假设上一拍控制器已经算出新的目标：为了让关节回到期望角度，应当增大一点正向力矩。写在程序里，它可能只是一行 pwm_duty = …；写在控制公式里，它可能只是一个 $u[k]$。

可在真实硬件里，这个数要先被写入定时器寄存器，再变成一串高低电平脉冲；脉冲经过栅极驱动，控制功率 MOSFET 以合适的方式开关；电源才会向电机绕组提供电流；最后，电机产生电磁力矩，经减速器和连杆带动关节转动。与此同时，编码器又把新的角度变成脉冲或电压信号，送回 MCU，成为下一拍计算的依据。

一条控制闭环里同时存在两种“流动”：从传感器到 MCU 的是信息，从电源经驱动器到电机的是能量。控制器负责把信息变成决策，硬件负责把决策安全地变成物理作用。

因此，不能把“MCU 读到一个数、PWM 输出一个数”看成黑箱。控制器能否认识真实状态、驱动器能否按时给出真实力矩，都取决于这条链路上的细节。

软件里的状态与控制量，只是硬件世界中信号的抽象；抽象要成立，必须有一条可测量、可同步、可保护的物理通路。

本文只聚焦一个问题：一条状态信息如何从机械臂走进控制器，一条控制量又如何从控制器走回机械臂？

一、先分清两条链：信息链负责“知道”，能量链负责“改变”

观察一次完整控制周期，可以把硬件链路粗略分成六步：

这里最值得记住的区分是：

两条链不能相互替代。编码器读数再精准，也不能弥补驱动器电流不足；功率级再强，也不能修复一个带有零偏的角度测量。闭环性能不是其中某一个器件的性能，而是两条链在同一时间轴上共同决定的结果。

二、传感器并不输出“角度”和“力矩”：它先把物理量翻译成电信号

以角度测量为例，关节本身只有一个旋转位置。安装在轴端的增量式编码器会输出 A、B 两路相位错开的脉冲；绝对值编码器可能通过 SPI、SSI 或 CAN 报告一个数字位置；电位器则把转角映射成连续电压。它们描述的是同一个物理量，却要求 MCU 使用完全不同的采集方式。

电流也是如此。电机绕组里的电流不能直接连到 ADC 引脚，通常要先经过采样电阻或霍尔传感器，再由运算放大器调到合适量程，必要时还要做隔离和低通滤波。若这一段模拟前端的增益、零点或带宽设计不当，后面再精密的卡尔曼滤波，也只是在处理一份起点已经失真的数据。

采集不是“把线接到 MCU 上”。传感器输出、模拟前端、ADC/定时器和软件换算共同决定控制器看见的状态。

可以把传感器接口分成两类：

这也是“读取一个传感器”背后隐藏的第一层工程含义：同样叫读数，ADC 的一次转换、编码器的一次计数、总线收到的一帧数据，代表的真实时间并不天然相同。

三、数据进入 MCU 后，先别急着控制：要让码值重新拥有物理单位与时间

无论来自 ADC 还是外设寄存器，刚进入程序的数据都只是整数。比如增量编码器的计数值 $N[k]$，只有结合每圈计数 $N_{\text{CPR}}$、减速比 $G$ 和零位偏置，才能还原为关节角度：
$$\theta [k]=\frac{2\pi }{G{N}_{\text{CPR}}}(N[k]-N_0)$$

这条式子并不复杂，但它提醒我们：数据正确不等于物理意义正确。 编码器转一圈对应的是电机轴，还是关节轴？正方向与数学模型是否一致？开机时的零位在哪里？这些问题若没有在接口层统一，控制器会用完全自洽的计算去控制一个方向或尺度都错了的对象。

速度的情况更能说明“时间”的重要性。软件常用相邻样本差分：
$$\omega [k]\approx \frac{\theta [k]-\theta [k-1]}{T_s}$$

但它隐含了两个前提：相邻两次位置数据对应相同的采样间隔，且位置分辨率足够细。低速时，编码器可能连续几个周期没有新增计数；高频振动时，通信帧又可能比控制周期更旧。此时速度估计的抖动，不一定来自控制算法，而可能只是采集时标和分辨率的自然结果。

因此，状态在真正交给控制律之前，至少要回答四个问题：

前一节讨论“采样周期”时，重点是多久看一次现实；这一节补上的是：每次看见的到底是什么、又是在哪一刻看见的。

四、从 $u[k]$ 到 PWM：控制器输出的是意图，不是电机端的真实电压

假设位置环、速度环或 MPC 最后给出了一个命令 $u[k]$。它可能代表目标电压、目标电流、目标力矩，也可能只是归一化后的占空比。无论哪一种，MCU 的 GPIO 引脚都没有能力直接驱动电机；它通常只输出幅度很小、驱动能力有限的逻辑电平。

定时器把这个数字命令转成 PWM（Pulse Width Modulation）脉冲。例如，若一个周期内高电平所占比例为 $D$，在理想情况下，电机端看到的平均电压可近似理解为：
$$\bar{v}\approx D{V}_{\text{bus}}$$

这里的 $V_{\text{bus}}$ 是功率母线电压，而不是 MCU 的 3.3 V 逻辑电平。驱动器的任务，正是根据 PWM 的时序去开关 MOSFET，使电源的能量以受控方式送入电机绕组。

PWM 是命令的载体，不是能量本身。真正推动机械臂的是功率桥从直流母线调度出的绕组电流，而电流又决定了可获得的电磁力矩。

对直流电机或永磁同步电机而言，力矩与电流密切相关。于是，较完整的驱动链路往往不只是一层“PWM 控电压”，还包含电流检测、过流比较、驱动使能、欠压锁定和温度保护。

这会带来一个很现实的结论：控制器要求的 $u[k]$ 未必能原样到达机械臂。

• 母线电压下降时，同样占空比得到的平均电压会变小；
• 负载过大或保护触发时，驱动器可能主动限流；
• 上下桥臂切换时必须留出死区时间，否则可能直通短路；
• 电机反电动势、绕组电感和摩擦，会让实际电流与理想电压响应并不一致；
• 驱动器若没有被正确使能，PWM 波形即使完美，也不会产生任何力矩。

因此，把控制器输出理解为“希望系统施加怎样的作用”更准确。硬件功率级负责在电气安全、热限制和供电边界内，尽可能把这个希望兑现为真实力矩。

五、同一条闭环上，哪些器件在负责什么？

把从传感器到执行器的职责展开，会发现每一环都在替控制系统回答一个不同的问题：

这张表也解释了为什么现场调试时，不应一上来就怀疑控制参数。若角度单位被放大十倍，调再多次 PID 都没有意义；若功率电源压降明显，控制器看见的“响应迟缓”也未必是增益太小。

控制算法位于闭环中央，却不是闭环的全部。它依赖前端把现实说清楚，也依赖后端把命令做到。

六、硬件会怎样悄悄改写控制效果？四类问题最值得优先防范

1. 噪声与接地：控制器可能在纠正电磁干扰

电机 PWM 的大电流开关会在供电与地线上制造扰动。若模拟采样地、数字地和功率回流路径没有被认真规划，这些扰动可能叠加到电流采样或角度电压上。控制器看见的是波动，于是努力去修正；真实机械臂却未必存在同等幅度的运动误差。

所以，滤波、电源去耦、屏蔽线、差分传输和合理接地并不是纯硬件的“布线美观”，而是在保护控制器对现实的判断。

2. 饱和与保护：执行器并不总能完成命令

功率桥的电流上限、电源的供电能力、电机的热容量都构成了控制输入的边界。当控制器长期要求超出能力的力矩时，积分项可能继续累积，MPC 的预测也可能落空。硬件保护触发后，软件若仍假设命令已经执行，就会形成新的模型误差。

这正是前面约束控制思想在硬件层的对应物：可用控制量不是抽象的无限区间，而是一张会随电压、温度、速度和保护状态变化的边界。

3. 时延与不同步：状态与命令可能不属于同一个“现在”

一次 ADC 触发、一次 DMA 搬运、一次控制任务唤醒、一次 PWM 更新，都要花时间。更麻烦的是，编码器、电流采样和 IMU 也许以不同速率刷新。若控制器把 2 ms 前的电流与刚刚读取的角度当成同一时刻的状态，就相当于在拼接一张并不存在的系统快照。

对高速系统，应尽量把关键采样与 PWM 事件绑定到同一套定时器节拍，并在软件中记录时间戳。只有知道“这条数据来自何时”，延迟补偿、观测器与同步才有依据。

4. 单位、方向与标定：最朴素的问题往往最顽固

编码器正方向、减速比、ADC 参考电压、电流零点和力矩常数，都是从硬件走向算法的接口约定。任何一项没有校准，都可能让系统呈现出“参数怎么调都奇怪”的症状。

实际工程中，先打印原始码值并手动转动关节、再核对物理单位和符号，往往比立刻运行完整控制器更能节省时间。

七、遇到“机械臂不按预期动”时，怎样沿着信号链排查？

调试顺序最好从两端同时向中间收敛，而不是只盯着控制代码：

这个顺序背后的逻辑很简单：每往前一步，都把一个更底层的假设变成可验证事实。这样即使最终问题出在算法，也能明确知道算法面对的是一条可信的硬件链路。

八、把这一节放回整个专栏里看

上一节的采样与离散化，解释了连续对象怎样按固定节拍进入数字控制器；这一节则把那个抽象的“输入”和“输出”拆开，落到真实的器件与能量通路上。

• 控制理论提供了状态、反馈和稳定性的语言；
• 控制算法根据状态、代价与约束给出 $u[k]$；
• 采样与离散化规定了控制器何时观察、何时更新；
• 传感器—MCU—驱动器链路决定了观察到的状态是否可信、输出的命令能否兑现；
• 接下来的实时系统设计，还要回答多个中断、通信和控制任务怎样在同一块 MCU 上按时完成。

这也让“反馈”这条主线更具体了一些：反馈从不是屏幕上两根曲线的对比，而是编码器的边沿、ADC 的采样时刻、寄存器的更新事件与绕组电流共同组成的一次物理循环。

In the end：下一步该看什么？

到这里，我们已经顺着一条控制信号穿过了传感器、采集外设、控制程序、PWM、功率驱动和执行器。每个环节都知道自己该做什么还不够：它们还必须在正确的时刻完成。

如果控制任务偶尔晚到，ADC 与 PWM 没有同步，或者通信中断抢走了关键时刻，原本设计为固定 $T_s$ 的闭环就会出现抖动和不确定延迟。

下一节，我们将继续追问： 实时性不是“跑得快”：为什么错过一次截止时间，就可能改变整个控制系统。