企业官网建设流程全解析

做多传感器融合建图这段时间，我踩得最深的一个坑就是：速腾雷达和海康相机明明都标定了外参，GAC-Mapping却依然跑出重影、错位、回环不闭合的烂图。查来查去，问题根本不在算法参数，而在于两个传感器的时间戳压根不在同一个时间坐标系里。雷达觉得是10:00:00.000，相机揪着10:00:00.215不放，融合出来的点云颜色自然对不上。后来我把整套方案改成了基于STM32的硬件同步，用PPS秒脉冲加GPRMC授时去统一时间基准，再配合外部触发给相机打节拍，GAC-Mapping的地图质量才算真正稳下来。这篇内容就围绕这套硬件同步和时间戳对齐方案展开，适合正在做激光视觉融合SLAM、被多传感器数据同步问题折磨的开发者参考，尤其是打算在嵌入式层面动手解决同步问题的朋友。

1. 为什么GAC-Mapping非要硬件同步：软件时间戳的账要算清楚

1.1 GAC-Mapping对多传感器融合的要求

GAC-Mapping这类基于图优化的激光SLAM方案，和FAST-LIVO、LIO-SAM一样，核心逻辑是把不同传感器观测到的信息统一放进一个优化框架里。它既要用雷达点云做帧间匹配和回环检测，又要用图像信息做特征关联或者颜色着色。既然要做“融合”，那么前提就是各路数据描述的是同一个物理时刻下的场景状态。

打个比方，这就像两个人同时拍一张高速运动的小球照片，如果两张照片拍摄时间差了50毫秒，小球在画面里的位置就完全不同，你也没法通过两张照片判断小球的真实轨迹。传感器融合也是同理——点云描述的是激光发出到返回瞬间的环境，图像描述的是快门打开瞬间的视觉画面，这两者在时间轴上必须是严格对齐的。GAC-Mapping在优化过程中，会利用不同传感器之间的约束关系去修正位姿。如果时间戳本身就有几十毫秒的误差，这些约束会被当作有效的几何或光度约束参与优化，最后把漂移误差带进地图里。我在实测里发现，时间偏差一旦超过10毫秒，点云着色后的物体边缘就会出现明显色晕，回环闭环时也经常报出虚警。

很多人觉得时间戳对齐是算法层的事情，代码里做一下同步就好了。实际上纯软件同步在真实场景中根本不靠谱，原因不复杂：每个传感器都有自己的硬件时钟，而时钟源往往是廉价的晶振，温度一变、电压一抖，频率就跟着漂。软件层能做的只是“拿一个系统时间去换算”，但换算的前提是每个传感器的时钟都精确已知，而这恰恰不成立。

1.2 软件同步的坑：晶振漂移与时间错位

我最早用纯软件方案时，让雷达驱动和相机驱动都读取工控机的系统时间作为时间戳。工控机用NTP和局域网时间服务器同步，理论上所有传感器的时间戳都来自同一个“权威时钟”，应该没有偏差。但实际跑起来后发现三个问题。

第一个是NTP本身的误差。标准NTP在局域网内可以达到毫秒级精度，但那是平均值，单次同步的抖动可能达到几十毫秒，如果网络有负载，这个数字还会更差。第二个是传感器驱动的延迟。雷达驱动收到UDP数据包后，解析、解码、封装成ROS消息，这个过程里的每一步都有时间开销，而且这个开销不是恒定的，CPU繁忙时会从几百微秒跳到几毫秒。第三个是时钟源的频率漂移。就算你通过NTP同步了系统时间，下一次同步之前系统本地时钟依然靠晶振维持，晶振的频率误差通常在几十ppm量级，按30ppm算，一小时就能积累108毫秒的偏差。

这三个问题叠加起来，最终时间戳的不确定性可能达到几十毫秒。我测过一组数据，纯软件方案下点云和图像的时间戳差值均值在20毫秒左右，峰值能到50毫秒以上。这种偏差对GAC-Mapping的里程计约束来说几乎是致命的。因为激光里程计模块会认为点云是准确的当前时刻观测，视觉约束也会拿图像特征去投影匹配，两边对不上，优化器就会在错误的残差上反复迭代，最后要么地图分层，要么点云着色错乱。

所以说，要在源头解决时间同步问题，必须引入硬件同步。硬件同步的核心思想很简单：用一根物理信号线把“这一刻”同时告诉所有传感器，就像体育比赛中发令枪一响，所有计时员同时按下秒表。这样即使每个传感器内部的晶振有漂移，只要它们在同一个物理时刻被“对齐”一次，短时间内也就不至于错得太离谱。

2. 整套硬件同步方案的总体设计：信号链路与协作关系

2.1 核心器件与信号拓扑

我的同步方案核心器件包括速腾激光雷达（RS-LiDAR系列）、海康工业相机（支持外触发）、GPS/北斗授时模块、STM32单片机，以及一台运行Ubuntu和ROS的工控机。

信号拓扑是这样的：GPS模块输出两路信号，一路是PPS秒脉冲，另一路是串口NMEA数据（主要是GPRMC语句）。PPS是一根非常陡峭的上升沿信号，每秒跳变一次，代表着UTC整秒时刻。STM32通过一个GPIO引脚捕获这个上升沿，同时通过串口接收GPS发送的GPRMC语句，里面包含UTC时间，比如“10:00:00.000”。STM32把这两个信息组合起来，就得到了“绝对时间”。

接下来STM32做三件输出：第一，把PPS信号转发给速腾雷达，同时通过另一个串口把GPRMC语句发给雷达，雷达内部用PPS的上升沿对齐自己的毫秒计数器，用GPRMC修正UTC绝对时间；第二，STM32用定时器产生一路周期性的触发脉冲信号，输出给海康相机的外触发输入引脚，让相机以固定的频率开始曝光；第三，STM32通过串口或者USB把本地维护的同步时间戳和触发计数实时发送给工控机，工控机侧的采集程序根据这些信息为图像帧和点云包标注统一时间基准。

整套链路里STM32是核心枢纽。我把这个角色称为“时钟分发中心”，因为它同时承担了秒脉冲捕获、绝对时间解析、触发信号生成和时间戳广播四件事。GPS模块只负责提供一个绝对时间源，真正把时间“翻译”给各个传感器的是STM32。

2.2 为什么选STM32而不是用FPGA或直接绕开

有人会问，GPS模块的PPS直接接雷达不就行了吗？为什么非要加一块STM32？确实，如果只做“PPS给雷达+相机外触发”，用纯逻辑芯片甚至GPS模块自带的分频功能就能实现。但实际项目中还需要解决几个问题，而STM32在这几个问题上综合体验最好。

第一是时间戳的标定与修正。STM32可以用定时器输入捕获功能精确测量PPS上升沿之间的时间间隔，从而实时算出本地晶振的频率偏差并做补偿。这是一个需要逻辑判断和计算的任务，FPGA做起来要写大量状态机，STM32只需开一个定时器中断加一个卡尔曼滤波就行。

第二是触发信号的灵活配置。相机触发频率可能需要根据场景调整，比如室内建图用10Hz，室外高速采集可能要用20Hz。STM32通过修改定时器分频系数就能改变触发频率，如果用硬件逻辑实现，每次改频率都要改电路或者烧录逻辑。

第三是数据格式转换。GPS的GPRMC语句是NMEA协议文本，雷达需要的是特定格式的GPRMC，比如某些型号要求GPFPD或者带校验位的语句。这些格式转换在STM32里就是一段字符串处理代码，放在FPGA里做反而麻烦。

第四是成本。主流的STM32F103系列开发板几十块钱就能买到，定时器资源、串口数量都够用，开发工具链（Keil、STM32CubeMX）成熟，网上资料也极其丰富，学习门槛低。相比FPGA动辄几百上千的成本和复杂的开发流程，STM32是性价比最高的选择。

当然，如果项目对时间同步精度要求到了亚微秒级别，比如同步多线激光雷达和高速相机，STM32的定时器分辨率可能不够用，那时候可以考虑FPGA。但就GAC-Mapping这个场景来说，通常的点云和图像帧率都在10Hz到30Hz，STM32的微秒级处理能力完全够用。

2.3 同步信号时序规划与频率搭配

我实际采用的同步频率是：PPS每秒一个脉冲，雷达以10Hz的频率旋转扫描一圈输出一帧点云，相机以10Hz的频率触发曝光。雷达的10Hz输出和PPS之间是什么关系呢？速腾雷达在内部收到PPS上升沿后，会把毫秒计数器清零。雷达按固定频率工作时，每100毫秒产生一帧点云，点云时间戳由雷达驱动根据内部毫秒计数器换算。所以只要PPS被正确接入，雷达的每一帧点云时间戳都是基于UTC整秒计算的。

相机的触发则通过STM32的定时器产生。我在STM32里配置了一个定时器输出PWM，频率设为10Hz，占空比设为1%（即脉宽1毫秒）。这个脉冲信号接入海康相机的Line0输入引脚，配置成上升沿外触发模式。这样相机每秒曝光10次，每次曝光的起始时刻由STM32的定时器决定，而这个定时器的计数值又和PPS秒脉冲做了对齐。说白了，STM32把自己内部的定时器当作一个“以PPS为基准的数字时钟”，用这个时钟去触发相机，就保证了相机曝光时刻和雷达点云帧时刻处于同一个时间节拍下。

一个容易忽视的细节是曝光时间的设置。相机触发频率是10Hz，曝光时间理论上不能超过100毫秒，否则会侵占下一帧的触发间隔。我实战里一般把曝光时间设在2到5毫秒之间，这样既能保证图像亮度，又不会因为曝光时间过长让时间戳失去意义。对于室外强光场景，还需要调小曝光或者加ND滤镜，让相机尽量工作在快门较快、运动模糊可控的状态。

3. STM32侧实现：从PPS捕获到时间戳生成

3.1 用定时器输入捕获测量PPS并驯服本地时钟

STM32侧的代码我基于标准外设库写，核心思路是“用PPS校准本地时钟”。具体做法是：把STM32的一个高级定时器（比如TIM1）配置为输入捕获模式，通道1捕获PPS信号的上升沿。每当PPS到达，定时器就把当前计数值CCR1记录下来，同时产生捕获中断。我在中断里计算本次捕获值和上一次捕获值的差值，这个差值就是STM32内部时钟在1秒内的计数值。比如定时器时钟频率为72MHz，理论上1秒内应该计数72000000次，实测差值如果接近这个数字，说明本地时钟正常；如果偏差较大，比如只有71995000，说明STM32的晶振频率偏低了约0.7‰。

这个测量过程在嵌入式里其实就是“测频法”的应用：用PPS这个标准频率去测本地晶振的实际频率。得到偏差后，我会在后续的时间戳计算中做补偿。具体做法是，维护一个变量SYNC_CLOCK_PERIOD_NS，初始值是1秒除以定时器频率得到的纳秒数，实际运行中每隔一段时间（比如60秒）修正一次。这样即使在户外温度变化导致晶振频率波动的情况下，STM32维护的本地时间也能保持较高的精度。

在代码实现上，我用的是输入捕获中断加主循环标志位的结构。中断服务函数里只做两件事：更新捕获值、置位一个标志位。主循环检测到标志位后，再执行时间戳更新和触发计数累加。这样做的目的是尽量缩短中断服务函数的执行时间，避免在中断里做耗时的运算，防止影响下一次捕获。实测下来，这种架构下STM32的时间维护抖动可以控制在几十微秒以内，完全满足雷达和相机的同步需求。

volatile uint64_t sync_timestamp_us = 0; volatile uint32_t last_capture = 0; volatile uint8_t pps_flag = 0; void TIM1_CC_IRQHandler(void) { if (TIM_GetITStatus(TIM1, TIM_IT_CC1) != RESET) { uint32_t capture = TIM_GetCapture1(TIM1); uint32_t diff = capture - last_capture; last_capture = capture; // diff 约为定时器时钟1秒内的计数值, 可用来修正本地时钟 // 这里仅记录PPS到达事件, 具体时间处理放到主循环 pps_flag = 1; TIM_ClearITPendingBit(TIM1, TIM_IT_CC1); } }

3.2 串口解析GPRMC，给雷达喂绝对时间

PPS能告诉传感器“整秒时刻到了”，但具体是哪一秒的整秒，还需要GPRMC语句来提供。GPS模块通过一个串口持续输出NMEA语句，其中GPRMC的格式类似这样：$GPRMC,100000.000,A,3959.3245,N,11617.5234,E,0.0,0.0,010124,,,D*68。这里面“100000.000”代表UTC时间10点00分00秒000毫秒，“A”代表定位有效，“D”代表定位类型。STM32每收到一帧GPRMC，就提取出UTC时间并缓存在结构体里。

需要注意的是，PPS上升沿对应的就是GPRMC中“秒”的整数部分。也就是说，PPS到达的那一刻，UTC时间恰好是GPRMC时间里的整秒。因此STM32在PPS中断里更新本地时间戳时，只需要用缓存的GPRMC时间作为基准，毫秒和微秒部分从零开始计数即可。这样，本地时间戳的公式为：UTC秒 = GPRMC解析出的时间；UTC毫秒/微秒 = 从上次PPS上升沿到当前时刻的累积计数。

我踩过一个坑：GPS模块刚上电或者信号不好的时候，GPRMC语句中的状态位是“V”（无效），时间数据是上一次有效定位的旧值。如果这时候把时间戳发给雷达，会导致雷达的绝对时间错乱。解决办法是在解析代码里增加一个状态判断，只有“A”状态才更新本地时间，同时在日志里打印“GPS NOT FIXED”的警告信息。首次定位成功后，时间戳才真正可用。

把GPRMC转发给雷达也有讲究。速腾雷达的数据手册要求，GPRMC语句通过串口发送给雷达，波特率一般是115200，语句末尾要带回车换行。有的型号还要求特定字段填充，比如航向、速度必须为有效值，否则雷达可能会拒绝接收。我的做法是，不直接转发GPS模块原始的GPRMC语句，而是根据解析结果重新组包，确保字段格式完全符合雷达手册的要求，再通过另一个串口发送给雷达。

3.3 相机外触发引脚与快门时间戳记录

海康工业相机的外触发配置我是在相机SDK里完成的。先把相机的TriggerMode设为“Off”，TriggerSource设为“Line0”，TriggerActivation设为“RisingEdge”，然后把TriggerDelay设为一个固定值（比如0或5微秒，视相机型号而定）。这样相机的每一帧图像都由STM32发出的上升沿触发。因为触发脉冲的频率是10Hz，所以相机图像的帧率也被锁死在10Hz，和雷达完全一致。

相机端还有一个不能忽略的配置——曝光时间。曝光时间直接影响图像亮度，也影响时间戳的语义。在滚动快门相机上，每行像素的曝光起始时刻不同；在全局快门相机上，所有像素同时曝光。我优先选择全局快门相机来做同步融合，因为它更符合时间戳对齐的假设。如果手头只有滚动快门相机，时间戳就应该取曝光开始到曝光结束的中间时刻作为整幅图像的物理时刻，而不是快门开始时刻。

STM32在发出触发脉冲的时刻，同时记录一次“帧号”和“时间戳”，把这两个数据通过串口发送给工控机。工控机上的相机采集程序接收到图像后，根据图像数据里的帧号（Frame ID）去和STM32上报的触发计数对表，从而给图像打上精确的时间戳。这个方法的好处是，图像时间戳完全由硬件决定，不受上位机操作系统调度延迟的影响。

我实测过一种替代方案：让相机驱动直接使用ROS的TimeSynchronizer去同步点云和图像话题，时间戳由相机SDK自动生成。这种方式在低负载下效果尚可，但一旦上位机CPU占用率升高，图像时间戳会叠加调度延迟，导致与点云时间戳的偏差明显变大。所以只要条件允许，我都推荐用触发计数对表的方式。

3.4 时间戳数据上传上位机的帧格式设计

STM32需要把维护的同步时间信息传给工控机，我的做法是设计一个简单的串口数据帧，每10毫秒发送一次。帧格式如下：

typedef struct { uint8_t header; // 0xAA uint8_t type; // 0x01 表示同步时间戳 uint32_t frame_id; // 触发计数 uint32_t second; // UTC秒 uint32_t nanosecond; // 纳秒 uint16_t checksum; // CRC16 } sync_frame_t;

这个帧体大小只有16字节，115200波特率下传输耗时不到1.5毫秒，不会对系统造成负担。工控机上的采集程序用一个单独的线程读取串口，每收到一帧就更新全局变量。相机采集线程和雷达采集线程在发布消息时，都去读取这个全局时间值来决定自己的时间戳。

这里有个细节：串口时间戳传上来之后，上位机还需要补偿传输延迟。因为STM32发出数据到上位机解析出数据之间存在固定的线路延迟和接收缓冲延迟。实测下来，115200波特率下这一延迟大约1到2毫秒。如果需要亚毫秒级精度，可以在STM32发送帧时打上一个“发送时间戳”，上位机收到后再加上线路固定延迟来补偿。不过在GAC-Mapping的10Hz同步场景里，这个补偿可有可无。

4. 上位机侧的时间戳对齐：从毫秒偏差到毫秒内闭环

4.1 将点云、图像和IMU数据统一到同一时间基准

STM32把同步基础搭好后，上位机的工作就相对简单了。以ROS为例，我通常这样组织时间戳：

雷达点云发布时，PointCloud2.header.stamp由驱动根据雷达内部的毫秒计数器和GPRMC绝对时间换算得来。因为雷达被PPS对齐过，所以这个时间戳是稳定的UTC时间。相机图像发布时，Image.header.stamp不再使用相机驱动自生成的时钟，而是根据STM32上报的触发计数对表得出。IMU数据在GAC-Mapping中通常也参与优化，IMU驱动会用数据包里的时间戳字段或结合PTP（IEEE 1588）进行同步，让IMU时间也统一到UTC时间轴上。

这样所有传感器话题的时间戳就都基于同一个时钟源了。即使某个传感器因为驱动原因出现几毫秒的固定偏移，也可以通过校准量去修正。我一般会在采集前跑一次静态校准：让雷达和相机同时观察一个闪烁的LED或者旋转的标定板，统计点云时间戳和图像时间戳的固定偏移，把这个偏移作为一个常量写进上位机程序里。

统一时间基准的过程，本质上是为GAC-Mapping提供“时间对齐”的输入。GAC-Mapping的回环检测模块会同时检查几何回环和视觉回环，如果点云和图像描述的物理时刻不一致，视觉特征投影的位置就会和点云几何位置产生偏差，回环约束的质量就会被拉低。硬件同步完成后，这些约束就建立在可靠的输入之上。

4.2 最近邻与线性插值：两种时间配准方式

虽然硬件同步让所有传感器的时间戳都对齐到同一基准，但各传感器消息到达融合模块的时刻依然是异步的。GAC-Mapping在融合时，通常需要拿一帧点云去对应一帧图像，或者拿两帧点云之间的IMU数据去做运动补偿。

最常用的方法是最近邻匹配。对每帧点云，在图像时间戳列表中寻找时间戳最接近的一张图像，并设置一个时间差阈值，比如5毫秒。如果超过阈值就丢弃该帧图像。这种方法实现简单，在同步频率一致（都是10Hz）且时间戳抖动较小的情况下效果很好。我在实测中把阈值设为5毫秒时，系统依然能稳定运行。

如果传感器频率不一致，比如雷达是10Hz、相机是30Hz，最近邻匹配就变得浪费。这时候可以对高频图像做时间选择，或者对雷达点云做时间插值处理。不过我建议在硬件层面尽量保证雷达和相机的帧率一致，这样能大幅降低上位机对齐逻辑的复杂度。

还有一种是针对IMU插值。GAC-Mapping在做点云畸变校正时，需要知道点云扫描起始到结束这段时间内IMU的位姿变化。IMU频率通常是200Hz以上，比雷达高很多，所以可以对IMU数据进行时间戳查找，然后用Slerp（球面线性插值）或者旋转矢量积分得到任意时刻的姿态。

4.3 对接GAC-Mapping时的关键配置与验证手段

将同步好的话题接入GAC-Mapping时，有几个配置项值得留意。第一，雷达话题和图像话题的消息队列大小建议设置成5到10，避免突发延迟导致丢帧。第二，如果GAC-Mapping的节点订阅多个传感器话题，消息过滤器（message_filters）的syncPolicy可以设为ApproximateTime，并用setMaxIntervalDuration设置合适的时间间隔上限，我一般设为10毫秒。第三，在GAC-Mapping的配置文件中，如果要使用图像信息优化，需要确认对应的视觉特征话题已经正确发布，并且时间戳和图像话题一致。

验证时间戳对齐做得好不好，我有一个快速办法：把点云发布成OD（欧式距离）形式，叠加相机图像做着色显示。如果对齐正常，物体边缘的颜色过渡是锐利的，墙面纹理清晰；如果时间有偏差，物体会出现颜色“拖影”，比如移动的人身上会拖出一条彩色的尾巴。另外还可以绘制点云时间和图像时间的差值曲线，观察其均值和方差，理想情况下是一条在0附近的直线，波动不超过几毫秒。

我用这种验证方法做过多组实验。硬件同步前，时间差值均值在20毫秒左右，方差很大；同步后，差值均值降到了1毫秒以内，方差也控制在2毫秒以内。这个结果对GAC-Mapping来说完全是可接受的。

5. 实战中的坑与排查记录：这些坑我替你踩过了

5.1 PPS毛刺导致时间戳跳变

GPS的PPS信号理论上每秒一个干净利落的上升沿，但实际环境中PPS信号线如果太长、没有屏蔽或者接地不良，很容易耦合进去高频噪声，导致STM32误触发多路捕获中断。表现就是时间戳突然跳变几百毫秒，雷达点云时间戳和相机时间戳对不上。

排查思路是这样的：先用示波器观察STM32引脚上的PPS波形，看是否存在振铃或者毛刺；然后在STM32的GPIO配置中使能内部上拉，并增加一个简单的中断消抖逻辑，比如连续捕获到两个间隔小于1毫秒的上升沿，就认为是毛刺，丢弃第二次触发。更好的办法是在PPS输入和STM32之间加一个74HC14施密特触发器或者光耦隔离，从硬件层面滤除噪声。

我在车载场景下遇到过非常严重的PPS干扰，原因是PPS信号线走在了大电流线缆旁边。后来把信号线改为双绞屏蔽线，并让屏蔽层单端接地，问题就消失了。所以PPS信号线的布线也需要当作高频信号来对待。

5.2 相机触发到曝光开始之间的延迟补偿

海康相机在外触发模式下，从触发上升沿到真正开始曝光并不是零延迟，而是有一个固定的触发延迟（TriggerDelay），它由相机的内部电路和配置决定。如果相机是滚动快门，不同行的曝光开始时间还不一样。这个延迟如果不补偿，图像时间戳会整体偏移一个固定值。

我实测过一款海康相机，外触发上升沿到全局快门曝光开始的延迟大约是15微秒。这个量级在10Hz融合里几乎可以忽略，但如果和PPS对齐精度要求到微秒级，就必须补偿。方法很简单：在STM32触发脉冲输出的同时记录时间戳T0，相机采集程序为图像打时间戳时使用T0加上触发延迟，而不是使用图像实际到达上位机的时间。

还有一点容易被忽略：相机曝光结束后，数据从相机传到上位机还需要时间，这部分传输延迟与图像数据量、接口速率有关，而且不稳定。所以最可靠的做法是，让相机驱动的时间戳直接依赖触发信息，而不是依赖“接收到完整图像数据”的时刻。

5.3 晶振温漂与长时间建图的时钟漂移

STM32内部时钟的精度取决于外部晶振。普通有源晶振的频率稳定度在10到30ppm之间，温漂系数约±5ppm/°C。如果建图时长超过半小时，环境温度变化又明显，STM32本地时间戳可能出现累计漂移。这个漂移对短时融合影响不大，但对长时间建图、回环闭合会产生可见影响。

解决思路是对本地时钟做“驯服”。我在STM32里实现了一个简单的PPS测量模块，每个PPS上升沿都计算一次1秒内的计数值，然后通过滑动平均滤波得到一个更稳定的时钟周期估计值。每次生成时间戳时，用这个估计值来计算纳秒部分，相当于软件层面的温补晶振（TCXO）。实测下，这个方案可以把长时间运行的时间漂移控制在每秒1微秒以内。

如果项目预算允许，直接把STM32的外部晶振换成一个高精度TCXO或者OCXO，漂移会进一步降低。不过对大多数建图场景来说，软件驯服已经够用。

5.4 STM32调试时时间戳“卡住”的经典问题

用STM32开发时经常遇到一个现象：通过ST-Link接上调试器单步调试，程序运行一切正常，但拔掉调试器后时间戳又开始跳动。这个问题听起来奇怪，其实是调试模式下定时器默认暂停导致的。

默认情况下，STM32内核Halt时，定时器时钟也会被暂停。你在调试器里单步执行时，PPS中断和定时器捕获都不会正常触发，时间戳自然“卡住”。解决办法是在初始化代码里配置DBGMCU寄存器，让定时器在调试模式下继续运行。STM32标准库提供的函数是DBGMCU_APB1PeriphConfig(DBGMCU_TIM1_STOP, DISABLE)，意思是TIM1在调试停止时不被停止。加上这句配置后，调试过程中时间戳依然能正常更新。

我在这个坑上浪费过一整个下午，当时怎么都想不通为什么程序跑起来时间戳会跳变，后来翻参考手册才发现DBGMCU寄存器有这一层逻辑。如果你也遇到类似问题，先检查是不是调试模式导致的定时器停摆。

5.5 常见问题速查表

为了方便后来者排查，我把实战中遇到的典型问题整理成了表格，基本涵盖了从信号到软件的整体链路。

这张表里的每个问题，我都至少踩过一次。做硬件同步这件事，调试手段和耐心缺一不可。很多时候一个细节没注意到，就要排查好几天，但一旦把链路捋顺，后面跑采集和建图都会非常省心。

在我实际做了几套不同平台的同步方案之后，最大的体会是：硬件同步不是一道可选的加分题，而是多传感器融合的必答题。软件层再努力调节，也只是在时钟不确定性之上做修补，不如在物理层把时间基准统一来得干净利落。这套基于STM32的方案，成本不高、代码量适中、精度够用，尤其适合刚接触GAC-Mapping或者其他激光视觉融合框架的开发者。如果你正在为点云着色重影、回环闭合质量差这类问题发愁，不妨先别急着调算法参数，回头检查一下你的时间戳是不是真的齐了。