修复了雷达扫描范围的bug，修复了里程计数据的发布者冲突的问题。目前存在问题：odom坐标系在运动过程中还是会飘
This commit is contained in:
152
调试记录.log
152
调试记录.log
@@ -16,4 +16,154 @@ Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
|
||||
|
||||
|
||||
16:48
|
||||
雷达串口问题解决，原因是type-c转接线的芯片问题，换了一条转接线后雷达串口设备正常显示为ttyACM0和ttyACM1了。
|
||||
雷达串口问题解决，原因是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处改动):
|
||||
1. ekf.yaml: base_link_frame 从 base_link 改为 base_footprint
|
||||
→ EKF 发布 odom→base_footprint，不再与 base 驱动争抢
|
||||
2. origincar_base.cpp: 新增 publish_tf 参数，默认 false
|
||||
→ base 驱动默认不再广播 TF
|
||||
3. gc_nav2_with_slam_online_real.launch.py: 移除重复的 base_footprint→base_link static TF
|
||||
→ URDF 已定义该关节 (z=-0.09)，static TF 提供 identity (z=0) 造成冲突
|
||||
4. 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 使修复生效。
|
||||
|
||||
Reference in New Issue
Block a user