📚 课程目录第3章任务日志的采集与同步

3. 任务日志的采集与同步

任务日志的质量，首先取决于“采集”这一环是否可靠。无人系统上常见的日志来源至少包括四类：传感器数据（IMU、GNSS、视觉、激光雷达）、总线数据（CAN、RS-485、以太网）、遥测遥调报文（地面站与飞控/自驾仪之间的上下行帧）、以及系统事件（模式切换、告警、任务点到达）。这些数据由不同硬件、不同周期、不同接口产生，如果直接按“到达顺序”写入同一个文件，事后复盘时会出现时间错位、因果颠倒，甚至无法判断某次避障是传感器先触发还是控制指令先下发。因此，采集与同步必须作为一个整体来设计。

一、多源传感器时间同步：先统一时间基准，再谈对齐

时间同步的目标不是让所有数据“同时产生”，而是让每条记录都携带一个可比较的时间戳。工程上通常分三层处理。

第一层是时间基准统一。机载计算机应维护一个单调递增的本地时钟（如 Linux 的 CLOCK_MONOTONIC），避免系统时间被 NTP 或手动校时跳变导致日志时间倒流。所有采集线程在收到数据时，立即读取该单调时钟，得到“采集时刻”。

第二层是硬件触发与打标。对于周期严格的传感器，优先使用硬件同步信号（PPS、触发线）或传感器自带的时间戳。例如 GNSS 模块输出 PPS 秒脉冲，IMU 在每次采样时通过串口附带内部计数；若传感器不支持硬件打标，则退化为“到达时间打标”，并在日志中标记该数据的时间精度等级。

第三层是软件对齐与插值。复盘时若需要把 100 Hz 的 IMU 与 10 Hz 的 GNSS 对齐到同一时间轴，常用线性插值或最近邻匹配。示例：以 IMU 时间戳为基准，对 GNSS 位置在相邻两帧之间做线性插值，得到 t=12.345 s 处的经纬度估计。插值只适用于平滑量，对模式切换、告警等离散事件应保留原始时间戳，不做插值。

判断同步是否合格，可以看两个指标：同一物理事件在不同源中的时间戳偏差（目标通常小于一个控制周期，如 20 ms），以及日志中时间戳是否单调递增、无重复、无跳变。

二、总线数据抓取：旁路监听与主动请求

总线数据抓取有两种典型方式。一种是旁路监听，采集节点只接收不发送，适合 CAN 这类广播总线。以 500 kbps 的 CAN 为例，采集程序打开 SocketCAN 接口后，按帧读取 can_id、dlc、data 和硬件时间戳，再按 ID 过滤出飞控状态帧、电池帧、执行机构反馈帧。另一种是主动请求，采集节点按周期向目标设备发送查询帧，适合 RS-485 等主从总线；此时必须控制请求频率，避免占用总线影响实时控制。

抓取时要注意三点：一是不丢帧，接收缓冲区要足够大，必要时用独立线程或内核旁路；二是保留原始字节，不要只存解析后的物理量，否则协议变更后无法回溯；三是记录总线负载，当负载超过 70% 时，丢帧概率显著上升，应在日志中标记该时段数据可信度下降。

三、遥测遥调记录：上下行要成对留存

遥测是下行（机载到地面）的状态汇报，遥调是上行（地面到机载）的指令。复盘时最有价值的是把“指令—执行—反馈”串成一条链。因此记录时应同时保存：上行指令帧（含指令号、参数、发送时间、地面站序号）、机载接收确认、执行后的状态变化、以及下行遥测中对应字段的变化。若只记录遥测，看到的是“状态变了”，却不知道是谁在什么时候下的令；若只记录遥调，又无法确认指令是否真正生效。

建议为每一条遥调指令分配唯一 cmd_seq，并在后续遥测帧中回传该序号，形成闭环。示例日志片段：

[12:03:41.220] TX cmd_seq=1042 CMD_SET_MODE mode=AUTO
[12:03:41.238] RX ack cmd_seq=1042 result=OK
[12:03:41.260] TM mode=AUTO cmd_seq=1042
[12:03:41.520] TM wp_index=7 dist=132.4m

这样即使事后只看日志，也能确认指令在 18 ms 内被确认，并在 40 ms 内体现在遥测中。

四、边缘端缓存与回传策略：先保本地，再择优回传

无人系统常面临链路中断、带宽受限、功耗受限等问题，因此边缘端不能假设“随时能传”。合理策略是本地优先持久化，回传按优先级和链路状态动态决策。

本地缓存建议采用“环形缓冲 + 分段落盘”：高频原始数据先写入内存环形队列，由独立线程按固定大小（如 4 MB）或固定时长（如 10 s）落盘为分段文件，并同步写入索引（段号、起止时间、数据源、字节数、校验值）。这样即使断电，最多丢失当前未落盘的一段。

回传策略可按数据等级划分：

关键事件（告警、模式切换、指令确认）：立即回传，允许重传，带确认机制。
遥测摘要（1 Hz 状态、任务进度）：链路可用时按周期回传，链路差时降频。
原始传感器数据（IMU、图像、点云）：默认不回传，仅在任务结束、链路空闲或人工请求时按段补传。

回传时还要处理“断点续传”：每个分段文件有唯一段号，地面站记录已接收段号，重连后从缺失段开始补传，避免重复传输。若带宽极低，可先传索引和关键事件，原始数据留待回收后离线导出。

五、采集配置示例与结果判读

下面给出一份可参考的采集配置片段（示例参数，需按实际平台调整）：

sources:
  imu:    {iface: "serial0", baud: 921600, rate: 100, ts: "hw"}
  gnss:   {iface: "serial1", baud: 115200, rate: 10,  ts: "pps"}
  can:    {iface: "can0", bitrate: 500000, filter: [0x100,0x101,0x200]}
  telemetry: {iface: "udp:14550", rate: 5, log_tx: true, log_rx: true}

cache:
  ring_size_mb: 64
  segment_mb: 4
  segment_sec: 10
  fsync: true

uplink:
  critical: {policy: "immediate", retry: 3}
  summary:  {policy: "periodic", rate: 1}
  raw:      {policy: "deferred", trigger: "link_idle"}

采集完成后，判断日志是否可用于复盘，可以按以下顺序检查：时间戳是否单调递增；同一事件在 IMU、GNSS、遥测中的时间偏差是否在允许范围内；CAN 帧是否有丢帧标记；遥调指令是否都有对应的 ACK 和遥测回传；分段文件索引是否完整、校验是否通过。若其中任一项不满足，应在复盘报告中明确标注该时段数据可信度，而不是直接拿来做因果结论。

常见误区：把“到达时间”当作“采样时间”直接使用。对于高动态场景，两者可能相差数十毫秒，足以让避障判断的因果顺序完全颠倒。若无法获得硬件时间戳，至少应在日志中记录该数据的时延估计和不确定度。

总结来看，采集与同步的核心是：统一时间基准、保留原始数据、成对记录指令与反馈、本地优先持久化、按优先级回传。做到这五点，任务日志才具备复盘价值，后续的故障定位、性能评估和策略优化才有可靠的数据基础。