8.8 KiB
2026/6/1 16:12 关闭了雷达的自启动服务。
\TODO lsusb无法识别雷达usb设备，原本属于lslidar的 QinHeng Electronics USB Single Serial被赋予给了下位机的IMU设备。下面是lsusb的输出：
Bus 002 Device 002: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 2ce3:0010 Alcorlink Corp. USB 2.0 Camera Bus 001 Device 003: ID 1a86:55d4 QinHeng Electronics USB Single Serial Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
拔插之后lslidar后无改变 串口设备仅有ttyACM0，无ttyACM1.
16:48 雷达串口问题解决，原因是type-c转接线的芯片问题，换了一条转接线后雷达串口设备正常显示为ttyACM0和ttyACM1了。
2026/6/11 — TF树修复 & base驱动稳定性修复
问题1: SLAM Toolbox Message Filter 丢帧
现象: Message Filter dropping message: frame laser_link ... reason discarding message because the queue is full
原因: slam_toolbox_mapping.yaml 中 scan_queue_size 偏小，激光雷达 10Hz、minimum_time_interval 0.5s，队列缓冲不足
修复: 将 scan_queue_size 适当调大即可（属配置调优项，未做硬编码修改）
问题2: SLAM Toolbox Message Filter 时间戳过期
现象: Message Filter dropping message: frame laser_link ... reason the timestamp on the message is earlier than all the data in the transform cache
原因: 激光帧时间戳早于 TF 缓存最早数据，通常刚启动时 TF 尚未就绪或处理积压
修复: 随问题3 TF树修复后缓解
问题3: TF 树断连 — bt_navigator 找不到 map→base_footprint (核心问题)
现象: Could not find a connection between map and base_footprint because they are not part of the same tree. Tf has two or more unconnected trees.
根因: 两个节点同时发布 odom→base_link TF:
- base 驱动 (origincar_base.cpp:228) — 原始轮式里程计
- EKF (ekf.yaml: base_link_frame=base_link, publish_tf=true) — 融合 odom+IMU 两节点争夺同一条 TF，导致树撕裂 修复 (4处改动):
- ekf.yaml: base_link_frame 从 base_link 改为 base_footprint → EKF 发布 odom→base_footprint，不再与 base 驱动争抢
- origincar_base.cpp: 新增 publish_tf 参数，默认 false → base 驱动默认不再广播 TF
- gc_nav2_with_slam_online_real.launch.py: 移除重复的 base_footprint→base_link static TF → URDF 已定义该关节 (z=-0.09)，static TF 提供 identity (z=0) 造成冲突
- origincar_bringup.launch.py: 移除 base_to_link static TF（同上） 修复后 TF 树: map → odom → base_footprint → base_link → chassis_link → borad_link → laser_link ↑ ↑ ↑ ↑ SLAM EKF融合 URDF URDF
问题4: cmd_vel_to_ackermann_drive.py 找不到
现象: executable cmd_vel_to_ackermann_drive.py not found on the libexec directory
原因: 源文件缺执行权限 (644)，--symlink-install 时安装路径继承源文件权限
修复: chmod +x scripts/cmd_vel_to_ackermann_drive.py
问题5: base 驱动串口异常崩溃
现象: terminate called after throwing serial::SerialException: device reports readiness to read but returned no data
原因: Get_Sensor_Data() 中 Stm32_Serial.read() 抛异常未捕获
修复: origincar_base.cpp 中 Stm32_Serial.read() 包裹 try-catch，捕获 SerialException 后 return false
问题6: URDF 文件 git 冲突未解决
现象: xacro 解析失败 — XML parsing error: not well-formed (invalid token) 原因: origincar.urdf 存在 8 处 git merge 冲突标记 (HEAD vs mo_new)，涉及轮距参数 (0.0841 vs 0.0715) 修复: 清除所有冲突标记，采用 mo_new 分支轮距值
问题7: joint_state_publisher 找不到 robot_description
现象: Waiting for robot_description to be published on the robot_description topic...
原因: robot_mode_description.launch.py 使用旧式命令行参数传 URDF，未发布到 topic
修复: 改为参数方式传递 robot_description，同时传给 joint_state_publisher
编译记录
- 命令: colcon build --packages-select origincar_base --symlink-install
- 结果: 通过
================================================================================ 日期: 2026-06-13 问题: LSLiDAR /scan 可视化中出现空扇形面
【现象】 在 rviz/foxglove 中查看 /scan 话题时，显示中凭空出现一个约60°的扇形区域 没有任何点（inf），物体轮廓在该边界处像是被"切断"一般。但实际雷达能够检测 到360°所有方向的物体。
【根因分析】 驱动代码 lslidar_driver.cc 中，N10 雷达走的是 else 分支（Path 2）。 第1137行被硬编码为: int scan_num = fixed_array_length; // 450
而原始正确公式（被注释掉）为: //int scan_num = ceil((angle_able_max - angle_able_min) / 360 * count_num) + 1;
问题机制:
- LiDAR 硬件每圈输出约374个数据点 (分辨率 ~0.96°/点)，完整覆盖360°
- 但 fixed_array_length=450 强制分配了450个bin (分辨率 0.80°/点)
- 索引映射 point_idx = round((360-degree) * count_num / 360) 最大只能到373
- 所以 indices 374-449 (78个bin, ~60°) 永远是 inf
- 所有真实数据被"压缩"到 0-299° 范围内显示
同时 angle_increment 和 time_increment 也使用了 fixed_array_length 导致与实际数据不匹配。
【修复内容】 文件: src/lslidar_driver/src/lslidar_driver.cc
修改1 (line 1137):
- 修复前: int scan_num = fixed_array_length;//cyy_addcyy_add
- 修复后: int scan_num = ceil((angle_able_max - angle_able_min) / 360 * count_num) + 1;
修改2 (line 1163):
- 修复前: scan->angle_increment = 2 * M_PI / (double)(fixed_array_length - 1);
- 修复后: scan->angle_increment = 2 * M_PI / (double)(scan_num - 1);
修改3 (line 1172):
- 修复前: scan->time_increment = 0.1 / (double)(fixed_array_length - 1);
- 修复后: scan->time_increment = 0.1 / (double)(scan_num - 1);
【验证】 编译通过。需要重启 lslidar_driver_node 使修复生效: ros2 lifecycle set lslidar_driver_node shutdown 然后重新启动 launch 文件。
================================================================================ 日期: 2026-06-13 问题: LSLiDAR /scan 可视化中出现空扇形面
【现象】 在 rviz/foxglove 中查看 /scan 话题时，显示中凭空出现一个约60°的扇形区域 没有任何点（inf），物体轮廓在该边界处像是被切断一般。但实际雷达能够检测 到360°所有方向的物体。
【根因分析】 驱动代码 lslidar_driver.cc 中，N10 雷达走的是 else 分支（Path 2）。 第1137行被硬编码为: int scan_num = fixed_array_length; // 450
而原始正确公式（被注释掉）为: //int scan_num = ceil((angle_able_max - angle_able_min) / 360 * count_num) + 1;
问题机制:
- LiDAR 硬件每圈输出约374个数据点 (分辨率 ~0.96°/点)，完整覆盖360°
- 但 fixed_array_length=450 强制分配了450个bin (分辨率 0.80°/点)
- 索引映射 point_idx = round((360-degree) * count_num / 360) 最大只能到373
- 所以 indices 374-449 (78个bin, ~60°) 永远是 inf
- 所有真实数据被压缩到 0-299° 范围内显示
同时 angle_increment 和 time_increment 也使用了 fixed_array_length 导致与实际数据不匹配。
【修复内容】 文件: src/lslidar_driver/src/lslidar_driver.cc
修改1 (line 1137):
- 修复前: int scan_num = fixed_array_length;
- 修复后: int scan_num = ceil((angle_able_max - angle_able_min) / 360 * count_num) + 1;
修改2 (line 1163):
- 修复前: scan->angle_increment = 2 * M_PI / (double)(fixed_array_length - 1);
- 修复后: scan->angle_increment = 2 * M_PI / (double)(scan_num - 1);
修改3 (line 1172):
- 修复前: scan->time_increment = 0.1 / (double)(fixed_array_length - 1);
- 修复后: scan->time_increment = 0.1 / (double)(scan_num - 1);
【验证】 编译通过。需要重启 lslidar_driver_node 使修复生效。
6/16 调试记录
记录了深度相机的RGB图像最远能够识别的大小（目前A4）
6/18 调试记录
创建了电脑遥控的脚本，测试了不同速度下小车转弯半径的大小 修改了雷达驱动脚本，从软件上修复了重复掉线重连的情况
6/20 调试记录
所有工具/辅助类脚本全部放在tools文件夹下
7/20 调试记录
启动qr_detect的方式：
ros2 launch car_usb_cam hobot_usb_cam.launch.py # 终端1
ros2 launch qr_detection qr_detect.launch.py # 终端2