ROS 2 Jazzy 接入 A2M7 激光雷达实战：从电机不转、CH340 错码到 25 Hz 稳定 /scan

测试平台：Raspberry Pi CM4、Ubuntu 24.04、ROS 2 Jazzy、A2M7、CH340 USB-TTL

本文记录一次真实排障过程。结论来自实机日志、连续帧统计和 rosbag 回放，不是根据“节点能启动”推断成功。

一、最终解决到了什么程度

这次接入最后取得了以下结果：

• 雷达电机能够稳定旋转，物理扫描频率保持在约 25 Hz；

• 串口使用稳定的by-id路径，不再依赖可能变化的/dev/ttyUSB0；

• 当前 CM4 + CH340 链路使用实测补偿波特率260000后，设备信息查询 30/30 次完全一致；

• ROS 2 使用Sensitivity模式发布/scan；

• 1000/1000 帧均为 720 点，每帧有效点最少 526 个；

• 连续运行 627 秒，共采集 15,600 帧，没有新增 USB 重连、CH340 掉线或内核错误；

• 完成base_footprint -> laser外参测量，并验证/scan、/tf_static可录制和回放。

二、一开始遇到的几个问题

问题不是单一的软件报错，而是多层故障叠加：

1. 蓝色MOTOCTL线悬空时，雷达电机完全不转；

2. 把MOTOCTL接回 USB-TTL 的固定 3.3 V 后，电机立即旋转，但物理转速固定在约 25 Hz；

3. A2M7 名义波特率256000在当前 CM4 + CH340 链路上会发生字节损坏；

4. 为了“修复分圈”临时加入的角度跨零判断，反而产生了大量单点帧；

5. /dev/ttyUSB0会随插拔顺序变化，启动文件不能长期依赖这个编号；

6. 雷达装上车后，扫描坐标系方向与车头方向并不一致，还需要测量静态 TF。

如果一开始只盯着ros2 topic hz /scan，这些问题很容易互相掩盖。因此我采用了分层排查：

供电与电机 -> 原始串口协议 -> SDK 组帧 -> ROS 2 消息 -> TF -> rosbag

只有上一层稳定，才继续验证下一层。

三、先解决电机完全不转

A2M7 的蓝色线是MOTOCTL。在当前接线中，USB-TTL 小板只有：

5V / VCC / 3V3 / TXD / RXD / GND

小板没有单独引出的 PWM 或MOTOCTL控制针脚。实测现象很直接：

• 蓝线悬空：电机完全不转；

• 蓝线接固定 3.3 V：电机立即旋转；

• 当前链路无法通过 SDK 有效调节电机 PWM。

因此本项目最终选择，保留固定 3.3 V 驱动方式，接受约 25 Hz 的物理转速，不再继续折腾 PWM 调速。

当前有效接线逻辑是：

A2M7 5V -> USB-TTL 5V A2M7 TX/RX -> USB-TTL RX/TX（交叉连接） A2M7 GND -> USB-TTL GND A2M7 MOTOCTL -> USB-TTL 固定 3.3 V

图中可以看到VCC空置，蓝色MOTOCTL跳线接在3V3。发布到 CSDN 时需要将这张本地图片重新上传到文章编辑器。

重要安全提醒

不要把 USB-TTL 的固定 3.3 V 输出和另一块主控板的 PWM 输出同时接到MOTOCTL。两个推挽输出并接可能发生电气冲突。

另外，本文只记录当前实物的验证结果。不同批次雷达、转接板和控制方式可能不同，接线前应优先查阅自己设备的官方手册。

四、不要先怪 ROS 2：直接验证原始串口回复

电机能转以后，ROS 2 节点仍然不稳定。此时最关键的动作不是反复改 launch 参数，而是绕过 ROS 2，连续读取固定格式的设备信息回复。

判断逻辑很简单：同一台雷达的型号、固件版本、硬件版本和序列号不会在几秒内随机变化。如果连续查询得到的帧长度、帧头或序列号不同，问题就在串口字节链路，而不是/scan发布频率。

名义波特率256000下，连续 30 次查询结果为：

SUMMARY rounds=30 lengths={26: 3, 27: 27} complete=27 valid_prefix=25 unique_complete=13

这组数据说明：

• 有 3 次回复长度错误；

• 只有 25 次拥有正确前缀；

• 本应固定的完整回复竟然出现 13 种内容。

同时，内核日志中没有 USB 拔插或重连记录。因此更符合“串口采样产生字节错误”，而不是 USB 设备掉线。

五、为什么最后使用了260000

在同一套 CM4 + CH340 硬件上，我逐个测试邻近波特率。改为260000后，连续 30 次结果变为：

SUMMARY rounds=30 lengths={27: 30} complete=30 valid_prefix=30 unique_complete=1

设备序列号也稳定为同一个值。也就是说：

• 30/30 帧长度正确；

• 30/30 帧头正确；

• 30 次完整回复完全一致。

所以当前 launch 使用：

serial_baudrate=260000

但必须说明：

A2M7 协议的名义波特率仍然是256000。260000是当前 Raspberry Pi CM4 + CH340 链路的实测补偿值，不是所有 A2M7 用户都应该照抄的“新标准波特率”。

如果你的256000通信稳定，就没有理由改成260000。正确做法是用固定设备回复进行重复性测试，用数据决定，而不是猜。

六、使用稳定设备路径

Linux 中的/dev/ttyUSB0只是动态编号。插入第二个 USB 串口，或者改变插拔顺序后，它可能变成/dev/ttyUSB1。

先查看稳定路径：

ls -l /dev/serial/by-id/

本机最终使用：

/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0

这样启动文件指向的是设备身份，而不是某一次启动时碰巧分配到的编号。

七、错误的“角度跨零分圈”为何产生单点帧

串口稳定后，另一个典型症状是/scan偶尔或大量出现只有一个点的帧：

LENGTH_MIN_MED_MAX 1,1.0,720 FINITE_MIN_MED_MAX 0,0.0,542

排查发现，驱动中曾加入一个备用逻辑：当相邻节点角度跨越0/360度时，强制认为新的一圈开始。

这个判断看起来合理，但它隐含了一个前提：解码后的节点必须严格按单调角度顺序到达。A2M7 的Sensitivity模式并不满足这个假设，于是正常节点也被反复误判为新一圈，最终产生大量 1 点 LaserScan。

修复方式不是继续增加角度阈值，而是删除这个猜测逻辑，只使用 SDK 协议提供的同步位分圈：

RPLIDAR_RESP_HQ_FLAG_SYNCBIT

这一步的经验是：

设备协议已经提供明确边界标志时，应优先相信协议标志；不要用几何现象重复推断协议状态，除非有完整数据证明协议标志确实失效。

八、最终 ROS 2 参数

当前sllidar_a2m7_launch.py的核心参数为：

serial_port=/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 serial_baudrate=260000 scan_mode=Sensitivity scan_frequency=25.0 force_scan=true frame_id=laser angle_compensate=true

启动命令：

source /opt/ros/jazzy/setup.bash source /home/ppf/ros2_ws/install/setup.bash ros2 launch sllidar_ros2 sllidar_a2m7_launch.py

这里还有一个容易误解的地方：

scan_frequency=25.0是驱动使用的扫描频率参数，不等于通过软件把电机“设置成 25 Hz”。本项目的物理转速来自MOTOCTL固定高电平，必须通过/scan的时间戳间隔再次实测。

九、不要只看“话题存在”，要检查每一帧

ros2 topic list中出现/scan，只能证明存在发布者，不能证明数据可用于建图。

我写了一个简单的rclpy探针，对每帧统计：

• 接收时间间隔；

• 消息时间戳间隔；

• scan_time和time_increment；

• ranges点数；

• 有限距离点数量；

• 角度范围、角分辨率和frame_id。

1000 帧短窗结果如下：

COUNT 1000 RECEIVE_DELTA_MIN_MED_MAX 0.002791798,0.038325188,0.044722839 STAMP_DELTA_MIN_MED_MAX 0.033661604,0.038289785,0.044532061 SCAN_TIME_MIN_MED_MAX 0.030895054,0.035453770,0.041426986 TIME_INCREMENT_MIN_MED_MAX 0.000042969,0.000049310,0.000057618 LENGTH_MIN_MED_MAX 720,720.0,720 FINITE_MIN_MED_MAX 526,547.0,560 GEOMETRY angle_min=-3.141592741 angle_max=3.141592741 angle_increment=0.008738784 frame_id=laser

时间戳间隔中位数为0.03829 s：

1 / 0.03829 ≈ 26.12 Hz

它与“约 25 Hz”的实物表现一致。更重要的是，1000 帧全部为 720 点，没有再出现单点帧。

随后进行了 627 秒稳定性测试：

COUNT 15600 LENGTH_MIN_MED_MAX 720,720.0,720 FINITE_MIN_MED_MAX 396,553.0,566 PROBE_EXIT=0

测试期间没有新增 CH340 掉线、USB 重连、error -71或error -32。

十、雷达装上车后，必须测 TF 外参

雷达能够发布数据，不代表方向就是正确的。按照 ROS REP-103：

车头方向 = base_footprint 的 +x 车体左侧 = base_footprint 的 +y

尺量得到雷达扫描中心相对机器人基坐标系的位置：

图中车头朝左，雷达安装在车体纵向中心线上。

laser_x = 0.080 m laser_y = 0.000 m laser_z = 0.140 m

偏航角没有靠目测。我在车头正前方放置纸板，采集 100 帧；随后移走纸板，再采集 100 帧。比较两组近距离角度簇，只有纸板存在时出现：

start_deg=-124.42 end_deg=-102.89 center_deg=-113.66 distance_m=0.471

这说明在雷达坐标系中，车头方向位于-113.66°。要把它旋转到机器人坐标系的正前方，静态 TF 应施加相反角度：

laser_yaw = +113.66° = 1.984 rad

最终静态变换为：

translation: (0.080000, 0.000000, 0.140000) rotation quaternion: (0.000000, 0.000000, 0.837122, 0.547017) from: base_footprint to: laser

用纸板“出现/消失”的差分法，比仅观察一帧或凭雷达外壳方向猜测可靠得多。

十一、用 rosbag 固化证据

最后录制/scan和/tf_static：

ros2 bag record --topics /scan /tf_static

本次证据包信息：

storage: mcap duration: 5.010373699 s messages: 130 /scan: 129 /tf_static: 1

回放时增加 3 秒发现延迟：

ros2 bag play <bag_directory> --rate 0.5 --delay 3

这是因为/tf_static在包中只有一条并且位于开头。Fast DDS 的发布者和订阅者需要完成发现；如果播放器一启动就发送，测试订阅器可能还没匹配成功。加入--delay 3后，离线回放得到：

base_footprint -> laser translation: (0.08, 0.0, 0.14) rotation: (0.0, 0.0, 0.8371216855, 0.5470167124) COUNT 50 LENGTH_MIN_MED_MAX 720,720.0,720 PLAY_EXIT=0 TF_EXIT=0 PROBE_EXIT=0

这样，后续即使不连接实物雷达，也能复现部分消息、TF 和算法调试过程。

十二、这次排障最重要的经验

1. 按层排查，不要在 ROS 参数里解决硬件问题

电机不转先查MOTOCTL和供电；固定设备回复变化先查串口；帧点数异常再查 SDK 分圈；这些都稳定以后才讨论 TF 和 SLAM。

2. “能发布”不等于“数据合格”

必须统计连续帧的点数、有效点、时间戳、频率和异常值。只看 RViz 中出现了一圈点云，很容易漏掉偶发单点帧和串口错码。

3. 不要把实测补偿值包装成通用结论

260000解决的是本机 CM4 + CH340 的具体链路问题。换 USB-TTL、内核、晶振误差或主机后，都应重新验证。

4. 计划项不能写成已完成

当前已经完成雷达独立链路、稳定性、外参和 rosbag 回放；RViz2 最终复核以及和底盘的联合运行仍是后续任务。工程项目的状态应由可复现证据决定，而不是由代码目录或构建成功决定。

十三、当前结论与下一步

这次排障真正解决的，不只是“让雷达转起来”，而是把供电、串口、协议组帧、ROS 消息、外参和可回放证据串成了一条可以复验的工程链路。