了解 C 板：把它当作黑盒 API

引言：把 C 板当作一个“黑盒 API”

视觉算法运行在 PC 上；C 板负责读取传感器、驱动电机，并把机器人当前状态反馈回来。对视觉组而言，可以先把 C 板理解成带有明确输入、输出和约束的黑盒 API：

• 视觉组向它发送“目标在哪里、是否有效、现在处于什么模式”等指令；
• 它向视觉组返回“云台现在朝向哪里、是否在线、是否到达限位”等状态；
• 它在更底层完成电机控制、CAN 通信、传感器读取等工作。

flowchart LR
    vision[视觉程序 / PC] -->|目标与模式指令| board[C 板：黑盒 API]
    board -->|姿态、状态与故障信息| vision
    board -->|电机命令| actuator[电机与执行机构]
    sensor[编码器、IMU 等传感器] -->|测量值| board

阅读本文不需要掌握 C 语言或单片机编程；但视觉组需要介入电控下位机的上层控制算法，以及坐标系变换部分的设计。

你需要掌握的是：怎样安全地连线，串口和通信协议在约定什么，以及视觉和电控各自应当提供什么信息。即使不修改下位机代码，也能正确使用、测试和定位这条通信链路。

1. 认识 C 板：供电、接口与连线常识

1.1 C 板负责什么

C 板通常以 STM32 为核心。它不是 PC 的“外设扩展板”，而是一台实时控制器：在固定频率下读取传感器、计算控制量并驱动执行机构。开发板上的接口很多，但视觉新人最常接触的是供电、串口和调试接口。

通过 C 板用户手册可以先建立接口地图。不同批次或工程的实际接法可能不同，接线前始终同时核对三件事：用户手册、板上丝印、当前机器人的接线约定。

接口或区域	常见用途	视觉组需要知道的事
电源输入（如 XT30）	为控制板和相关模块供电	输入电压必须符合用户手册；接反或超过额定电压可能损坏设备。
Micro USB、BOOT	固件下载、恢复或供电辅助	USB 与串口不是一回事；不要把 USB 信号线直接接到 UART 引脚。
UART / 串口接口	与 PC、无线模块或其他控制器交换数据	通常至少使用 TX、RX、GND 三根线。
CAN 接口	与电机、底盘或其他控制模块通信	这是另一种总线，不能当作 UART 直接接入。
SWD 接口	程序下载与在线调试	一般由电控使用；视觉组知道它的用途即可。
PWM、GPIO、I²C、SPI、DBUS 等	舵机、传感器、遥控器及扩展功能	插头形状相同不代表接口功能、引脚顺序或电平相同。

1.2 供电：先确认电源，再接通信线

C 板常通过 XT30 等电源接口接入机器人电源。以用户手册为准确认输入电压范围、正负极和额定电流；不要凭“插头能插上”判断可以使用。

PC 与 C 板通信时，二者各自有供电来源是正常的，但通信双方需要有共同的电压参考。因此串口连接中通常还要连接 GND（地）。GND 不是可有可无的“第三根线”。

不要用 USB 转 TTL 模块的 VCC 引脚给 C 板供电，也不要在不清楚电源设计时同时从多个来源给同一块板供电。这类错误可能导致供电不足、反向灌电或损坏接口。

1.3 什么是串口与 USB 转 TTL

串口（UART）是一种常见的异步、逐位传输方式。双方事先约定波特率、数据位、校验位和停止位，发送端沿着发送线依次输出比特，接收端按同样的约定还原数据。

USB 是 PC 常用的接口，而 C 板的 UART 引脚输出的是 TTL 电平串口信号。USB 转 TTL 模块的作用，就是把 PC 的 USB 设备转换成可接到 UART 的 TX、RX、GND 信号。它不是一根普通 USB 线的替代品，也不是通用电源模块。

flowchart LR
    pc[PC] -->|USB| bridge[USB 转 TTL 模块]
    bridge_tx[转换器 TX] -->|发送给 C 板| board_rx[C 板 RX]
    board_tx[C 板 TX] -->|发送给 PC| bridge_rx[转换器 RX]
    bridge_gnd[转换器 GND] --- board_gnd[C 板 GND]

其中 TX 是发送（Transmit），RX 是接收（Receive）。两端的命名都站在各自设备的视角，所以必须交叉接线：

• 转换器 TX 接 C 板 RX；
• 转换器 RX 接 C 板 TX；
• 转换器 GND 接 C 板 GND。

记住一点即可：一端发出的数据，必须进入另一端的接收脚。TX 接 TX、RX 接 RX 会让双方要么都在发送、要么都在等待，自然收不到数据。

还应确认电平是否兼容。UART 常见为 3.3 V TTL，也有设备支持 5 V TTL；RS-232 与 TTL 的电平规范不同，不能直接相连。实际接线以板卡手册和电控约定为准，不能只根据 USB 转 TTL 模块的外观猜测。

1.4 线序、杜邦线与接口头

接线故障往往不是代码问题，而是“线插对了孔、却没有接到正确的信号”。下面这些概念值得在第一次接线前分清：

名称	含义与检查方法
引脚（Pin）	接口中的一个电气触点，例如 TX、RX、GND。先看板上丝印或手册，再接线。
排针 / 排母	常见的针状或孔状连接器；2.54 mm 是常见间距，但不是所有接口都使用它。
杜邦线	常用于原型连接的单芯跳线，可分为公头、母头和两端不同的组合。它描述的是连接形式，不保证信号定义。
线序	多芯线中每根线对应哪个引脚的排列顺序。线的颜色只是辅助标记，不能代替确认。
极性	电源的正负极，或差分信号的正负端。极性接反可能直接造成损坏。

对带多根线的连接器，先找到 Pin 1 的标记、缺口或丝印，再按照手册逐针确认。不要从线束另一端的颜色推断这一端的顺序；线束可能在中途交叉，转接板也可能重新排列引脚。

首次上电或更换线束时，建议按以下顺序操作：断电检查线序与接口 → 确认 TX/RX/GND 与电平 → 确认无短路和松动 → 接通主电源 → 再插入 USB 转 TTL 并观察通信。发现异味、异常发热或反复掉线时立即断电并请电控同学协助。

2. 协议层

串口只负责把一串字节从 A 送到 B；它并不知道这些字节代表“目标角度”还是“故障代码”。通信协议是双方对这些字节作出的完整约定，至少包括：消息从哪里开始、每个字段是什么、字段占几个字节、单位和坐标方向是什么、出错时怎样判断和处理。

2.1 数据类型与长度

协议中常见字段可写成固定宽度的整数或浮点数。固定宽度比“一个 int”更清楚，因为不同平台上普通 int 的长度不一定相同。

类型示例	长度	常见含义
uint8_t	1 字节	标志位、模式、枚举值、校验值
int16_t / uint16_t	2 字节	较小范围的计数、角度缩放值、状态码
int32_t / uint32_t	4 字节	时间戳、序号、较大范围的计数值
float（通常为 IEEE 754 单精度）	4 字节	角度、速度、坐标等连续量
字节数组	约定长度	多个数据、保留字段或可变内容

“字节”是协议长度的基本单位，1 字节等于 8 个比特。字段的类型、长度和顺序都属于协议的一部分，发送端和接收端必须完全一致；不能因为两个字段“看起来都像数字”就互换位置。

2.2 大小端：多字节数据如何排放

一个多字节数值要拆成若干字节在线上传输。以 0x1234 为例：

字节序	在线路上的先后顺序
小端序（little-endian）	0x34，再 0x12
大端序（big-endian）	0x12，再 0x34

双方若对字节序理解不同，数值就会被读错。协议文档应明确写出字节序；实现时不要直接假设 PC 和控制板的内存表示一定相同。对于 float 也同样如此：除了长度，还要约定表示格式和字节序。

2.3 一帧数据通常长什么样

串口是连续字节流，不天然区分“一条消息”的开始和结束。因此常把一条消息封装成一帧：

flowchart LR
    header[帧头<br/>用于同步] --> length[长度<br/>说明后续大小]
    length --> type[消息类型<br/>说明如何解释]
    type --> payload[数据载荷<br/>目标、状态等字段]
    payload --> check[校验<br/>检测传输出错]

• 帧头帮助接收端在连续字节中重新找到一帧的起点；
• 长度帮助接收端知道还要等多少字节，也能限制异常数据的大小；
• 消息类型让同一条链路可以承载不同含义的数据；
• 数据载荷才是实际业务字段；
• 校验（如校验和、CRC）用于发现传输过程中发生的错误。

校验的作用是检测意外损坏，不是加密或安全认证。接收端通常会依次检查帧头、长度和校验；任一项不通过就丢弃这帧并继续寻找下一帧。实际通信还可能遇到半帧、两帧粘在一起、丢字节和重复帧，因此不能把“每次串口读取”直接等同于“恰好得到一帧”。

3. 逻辑层：视觉与电控各自传什么

在黑盒边界上，最重要的不是某个字段的代码名，而是它的语义。每一个量都应能回答：单位是什么？坐标系或正方向是什么？什么时候有效？超时或无目标时应当怎样处理？

3.1 视觉发给电控的信息

视觉侧通常输出的是“我要让机器人如何响应”的目标信息，例如：

信息类别	典型内容	必须说清的语义
目标有效性	是否检测到可信目标	无目标时电控应保持、搜索还是停止跟随。
目标指令	目标方向、偏差、角度或坐标	单位、参考坐标系、正方向、是否已经预测。
目标运动信息	速度、角速度、预测时间等	时间基准和是否允许缺省。
工作模式	自瞄开关、测试模式、行为状态	切换条件与默认安全行为。
序号或时间信息	帧序号、时间戳	用于判断数据是否过期、乱序或重复。

视觉侧不应假设“发送成功”就等于机器人已经执行。指令是否被接受、当前模式是否允许执行、云台是否处于限位，仍需要从电控反馈中确认。

3.2 电控发给视觉的信息

电控侧通常返回的是“机器人实际处于什么状态”，让视觉的计算有正确的参考，例如：

信息类别	典型内容	视觉侧如何使用
当前姿态	云台 yaw / pitch 角度、角速度	将目标与机器人当前朝向关联，完成坐标变换或误差计算。
设备健康状态	在线状态、故障标志、限位状态	判断数据能否信任，并在异常时停止输出危险指令。
控制状态	当前工作模式、是否使能、是否跟随	避免视觉在未启用的模式下误判为算法失效。
时间与序号	反馈时刻、帧号	评估反馈延迟与数据新鲜度。
其他系统状态	由电控统一管理的机器人状态	仅在协议明确约定时使用，避免猜测字段含义。

sequenceDiagram
    participant V as 视觉程序
    participant C as C 板
    participant M as 云台与传感器
    V->>C: 目标指令（含有效性、单位与时间信息）
    C->>M: 控制执行机构
    M-->>C: 实际角度、速度与状态
    C-->>V: 姿态反馈、模式与健康状态
    V->>V: 根据反馈更新下一次计算

当通信或控制效果不符合预期时，先把问题描述成接口问题，而不是笼统地说“自瞄不对”。例如：记录发送的目标值和单位、收到的姿态值、工作模式、帧号或时间戳，以及接线和波特率配置。这样电控同学可以迅速判断问题位于视觉算法、协议解析、串口链路还是底层执行机构。

读完本文，你应能做到：看懂一张串口接线图并安全检查 TX/RX/GND；读懂一份协议字段表中的长度、字节序和校验要求；明确视觉命令与电控反馈的边界。至于 C 板内部怎样生成工程、下载和调试，将在后续的开发环境文章中继续介绍。