Orange
779b32362a
with '#' will be ignored, and an empty message aborts the commit. On branch master Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) Changes to be committed: modified: .gitignore modified: README.md new file: bashes/auto-wifi-connect.service new file: bashes/auto-wifi-connect.sh deleted: keyboard_control.py new file: my_model/image.png new file: path_follower_demo.py new file: scripts/PIDtracking.py new file: scripts/__pycache__/publish_sine_path.cpython-310.pyc new file: scripts/publish_sine_path.py modified: src/gc_navigation2_slamtoolbox/params/gc_navigation_slam.yaml modified: src/gc_navigation2_slamtoolbox/params/gc_navigation_slam.yaml.bak new file: src/gc_navigation2_slamtoolbox/params/gc_navigation_slam.yaml.bak2 modified: src/origincar_base/config/ekf.yaml new file: src/origincar_base/config/ekf.yaml.bak modified: src/origincar_base/launch/base_serial.launch.py new file: src/origincar_base/launch/base_serial.launch.py.bak modified: src/origincar_base/launch/origincar_bringup.launch.py new file: src/past_control/CMakeLists.txt new file: src/past_control/config/past_control.yaml new file: src/past_control/include/past_control/tools.h new file: src/past_control/launch/past_control.launch.py new file: src/past_control/msg/Obstacle.msg new file: src/past_control/msg/ObstacleArray.msg new file: src/past_control/package.xml new file: src/past_control/src/lane_follower_node.cpp new file: src/past_control/src/obstacle_detector_node.cpp new file: src/past_control/src/racing_orchestrator.cpp new file: src/planner/CMakeLists.txt new file: src/planner/config/planner.yaml new file: src/planner/launch/planner.launch.py new file: src/planner/package.xml new file: src/planner/src/planner_version.cpp modified: src/qr_detection/src/qr_dete_depth.cpp new file: src/racing_control/CMakeLists.txt new file: src/racing_control/include/racing_control/racing_control.hpp new file: src/racing_control/package.xml new file: src/racing_control/src/racing_control.cpp modified: src/vlm_detect/setup.py new file: src/vlm_detect/vlm_detect/__pycache__/__init__.cpython-310.pyc new file: src/vlm_detect/vlm_detect/__pycache__/tts_node.cpython-310.pyc new file: src/vlm_detect/vlm_detect/test_publisher.py new file: src/vlm_detect/vlm_detect/tts_node.py modified: src/vlm_detect/vlm_detect/vlm_node.py new file: tools/measure_turning_radius.py new file: tools/set_volume.py new file: tools/udp_to_cmdvel.py new file: tools/windows_keyboard_control.py new file: vlm_server.py new file: "\350\260\203\350\257\225\350\256\260\345\275\225.Assets/1.png" renamed: "\350\260\203\350\257\225\350\256\260\345\275\225.log" -> "\350\260\203\350\257\225\350\256\260\345\275\225.md"
183 lines
8.7 KiB
Markdown
183 lines
8.7 KiB
Markdown
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处改动):
|
||
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 使修复生效。
|
||
|
||
|
||
## 6/16 调试记录
|
||
记录了深度相机的RGB图像最远能够识别的大小（目前A4）
|
||
|
||
|
||
|
||
## 6/18 调试记录
|
||
创建了电脑遥控的脚本，测试了不同速度下小车转弯半径的大小
|
||
修改了雷达驱动脚本，从软件上修复了重复掉线重连的情况
|
||
|
||
## 6/20 调试记录
|
||
所有工具/辅助类脚本全部放在tools文件夹下
|