4. 采集系统架构

机器人触觉阵列采集系统并不是“传感器接上电脑就能读数”这么简单。一个可用的采集系统,必须在采样时序、数据吞吐、时间对齐和标定可追溯性之间取得平衡。典型架构采用上下位机分工:下位机负责硬实时采集与预处理,上位机负责可视化、存储、标定计算与算法运行。理解这条数据链路,是后续做标定和触觉重建的基础。

一、上下位机分工:谁负责“快”,谁负责“算”

下位机通常由 MCU(如 STM32、ESP32)或 FPGA 承担,直接连接触觉阵列的行列扫描电路、模拟前端(AFE)和多路复用器。它的核心职责是:按固定周期驱动扫描、完成 ADC 采样、做零点扣除与简单滤波、打包成帧并通过通信接口上传。下位机的关键指标是确定性——每个采样周期必须准时,不能因为操作系统调度而抖动。

上位机通常是 PC 或工控机,运行 Python/C++ 程序,负责接收数据帧、时间戳对齐、实时显示热力图、保存原始数据、执行标定矩阵计算和触觉图像重建。上位机的关键指标是吞吐与可追溯——能持续接收高速数据流,并把每一帧与时间、标定参数绑定。

分工原则:下位机保证“采样不丢、时序不乱”;上位机保证“数据可存、结果可算、过程可复现”。把复杂计算放在下位机,会挤占实时采样资源;把实时扫描放在上位机,则会被操作系统抖动破坏。

二、实时数据流:从行列扫描到触觉帧

触觉阵列的数据流可以概括为:扫描激励 → 模拟信号 → ADC 采样 → 帧组装 → 通信传输 → 上位机解析 → 标定映射 → 可视化/存储。以 16×16 阵列为例,若每个通道 12 bit,一帧原始数据约 3 KB;在 1 kHz 帧率下,数据率约 3 MB/s,这对通信接口和上位机缓冲都提出了要求。

下位机通常采用“行扫描、列读取”的方式:每次选通一行,并行读取该行所有列,再切换到下一行。这样一帧需要 N 次行切换。为了降低噪声,还会在每行做多次采样取平均。数据流中必须包含帧头、帧序号、通道数据、校验和,便于上位机判断丢帧和错帧。

触觉阵列采集系统:上下位机分工与实时数据流 触觉传感器阵列 16×16 行列扫描 压阻 / 电容 / 压电 模拟电压输出 下位机(MCU / FPGA) 行列扫描驱动 多路复用 + AFE ADC 采样与滤波 帧组装 + 帧序号 硬件触发输出 通信链路 USB / 以太网 SPI / CAN / 串口 帧头 + 校验和 上位机(PC / 工控机) 数据接收与缓冲 时间戳对齐 标定矩阵计算 热力图 / 存储 算法与可视化 同步触发信号 硬件触发 / 软件触发 时间戳管理 帧序号 + 本地时钟 多源数据对齐 触觉 + 视觉 + 力控 数据流:扫描激励 → 模拟信号 → ADC 采样 → 帧组装 → 通信传输 → 上位机解析 → 标定映射 → 可视化/存储 关键约束:采样周期确定性、帧不丢不重、时间戳可追溯、标定参数与原始帧绑定

三、通信协议:帧结构决定可靠性

通信协议是上下位机之间的“合同”。一个实用的触觉采集协议通常包含:帧头、帧序号、时间戳、通道数据区、校验和。帧头用于字节对齐,帧序号用于检测丢帧,时间戳用于多源对齐,校验和用于拒绝错帧。下面是一个简化的帧结构示例:

帧格式(小端):
[0xAA 0x55]        帧头 2 Byte
[frame_id]         帧序号 4 Byte,循环递增
[timestamp_us]     下位机时间戳 8 Byte
[rows][cols]       阵列尺寸 2 Byte
[data...]          通道数据 N×2 Byte(12 bit 左对齐)
[crc16]            校验和 2 Byte

上位机解析伪代码:
if buf[0]==0xAA and buf[1]==0x55:
    frame_id = read_u32(buf, 2)
    ts = read_u64(buf, 6)
    payload = buf[14:14+N*2]
    if crc16(buf[:-2]) == read_u16(buf, -2):
        publish(frame_id, ts, payload)
    else:
        drop_bad_frame()

选择通信接口时,要综合考虑带宽、延迟和布线。USB 2.0 适合中小阵列,以太网适合高帧率大阵列,SPI 适合板内短距离高速传输,CAN 适合多节点分布式触觉皮肤。协议设计上,建议采用“定长帧 + 序号 + 校验”,避免变长帧带来的解析复杂度。

四、同步触发与时间戳管理:多源数据对齐的关键

当触觉阵列与相机、力传感器、机械臂控制器同时工作时,时间对齐决定了后续标定和融合的精度。同步触发分为硬件触发和软件触发:硬件触发由下位机输出周期性脉冲,同时触发触觉采样和相机曝光,抖动在微秒级;软件触发由上位机发送命令,受操作系统调度影响,抖动可达毫秒级。

时间戳管理通常采用“双时间戳”策略:下位机在采样完成瞬间记录本地时间戳,上位机在收到帧时记录主机时间戳。通过线性回归可以估计两者之间的时钟偏移和漂移,从而把触觉帧映射到统一时间轴。对于 1 kHz 采样,时间戳分辨率应优于 100 μs,否则多源对齐误差会直接影响标定结果。

实践建议:优先使用硬件触发同步;若只能软件触发,应在协议中保留帧序号,并在上位机做丢帧插值或标记。时间戳不要只依赖上位机接收时刻,否则通信抖动会被误认为采样抖动。

五、案例与常见误区

以一个 16×16 压阻阵列、1 kHz 采样、USB 2.0 传输的系统为例:下位机每 1 ms 完成一次全阵列扫描,打包 530 Byte 的帧,通过 USB 批量端点上传;上位机用双缓冲队列接收,主线程做热力图显示,后台线程做标定矩阵计算和 HDF5 存储。若发现热力图偶发卡顿,优先检查上位机是否在 UI 线程中做了耗时计算,而不是怀疑传感器本身。

常见误区 现象 正确做法
用上位机软件定时器控制采样 采样间隔抖动大,标定重复性差 下位机硬件定时器驱动扫描,上位机只接收
只存处理后的触觉图像 无法回溯原始数据,标定参数无法复算 原始帧 + 时间戳 + 标定版本一并存储
忽略帧序号和校验 丢帧、错帧被当成真实触觉变化 协议中加入帧序号与 CRC,上位机做丢帧统计
多源数据各用各的时钟 触觉与视觉对齐误差大,融合失败 硬件触发 + 双时间戳 + 时钟偏移估计

复盘时可以用三个指标判断采集系统是否健康:丢帧率(应低于 0.1%)、时间戳抖动(应小于采样周期的 10%)、端到端延迟(从采样到上位机可用的时间,通常要求小于 10 ms)。这三个指标稳定后,后续的标定和触觉重建才有可靠的数据基础。