Radar: Preparation of SLAM Mapping Software Environment

Radar: Preparation of SLAM Mapping Software Environment

02 - 阶段二执行记录:SLAM 建图软件环境准备

1. 概述

最终选型:Cartographer(理由见 01_阶段二规划 文档)


2. 已完成步骤

2.1 安装 apt 依赖 【待用户手动执行】

当前环境无 sudo 权限,以下命令需在小车上手动执行:

# 安装 Cartographersudoapt update sudoaptinstall-y ros-humble-cartographer ros-humble-cartographer-ros # 安装 Nav2 地图服务器(保存地图用)sudoaptinstall-y ros-humble-nav2-map-server # 安装 URDF 工具(编译 description 包需要)sudoaptinstall-y ros-humble-robot-state-publisher ros-humble-joint-state-publisher ros-humble-xacro 
以上三条命令也可以合并为一条执行。

2.2 设置 LIDAR_TYPE 环境变量 【已完成】

已写入 ~/.bashrc

exportLIDAR_TYPE=4ros 

源码中的 launch 文件会读取此变量,自动选择对应的雷达配置。

2.3 复制建图相关包到工作空间并编译 【已完成】

从源码目录复制了 3 个包到 ~/ydlidar_ws/src/

包名作用编译类型
yahboomcar_nav建图/导航 launch 文件 + 参数配置ament_python
yahboomcar_descriptionURDF 模型(TF 坐标关系)ament_python
yahboomcar_msgs自定义消息类型ament_cmake

编译命令:

cd ~/ydlidar_ws colcon build --symlink-install --packages-select yahboomcar_description yahboomcar_msgs yahboomcar_nav 

编译结果:3 个包全部成功(仅有 setuptools 弃用警告,不影响运行)。

2.4 TF Frame 分析 【无需修复】

分析结论:

组件Frame 名称来源
雷达驱动 /scanlaserydlidar_4ros.yamlframe_id: laser
URDF 模型laser_linkyahboomcar_X3.urdf 中固定关节
launch 静态 TFbase_link → laserlaser_bringup_launch.py

两者共存不冲突:

  • URDF 的 laser_link 用于 RViz 模型可视化
  • 静态 TF 的 laser 用于实际 /scan 数据的坐标变换
  • Cartographer 按 /scan 消息的 frame_idlaser)查 TF,走静态 TF 链路

2.5 Cartographer 配置优化 【已完成】

针对 TG30 雷达创建了两份 Cartographer 配置文件:

tg30_2d.lua(正式建图用,有 odom)
参数原值新值说明
tracking_framebase_footprint不变跟踪底盘
use_odometrytrue不变使用底盘里程计
min_range0.10.05TG30 最小 0.01m
max_range812.0TG30 最远 64m,室内取 12m
missing_data_ray_length0.55.0增大无数据射线长度
publish_frame_projected_to_2dfalsetrue2D 投影
optimize_every_n_nodes注释掉30启用全局优化
min_score0.70.65适当放宽回环检测
tg30_2d_no_odom.lua(手持测试用,无 odom)
参数说明
tracking_framebase_link无 odom,直接跟踪 base_link
published_framebase_link发布到 base_link
provide_odom_frametrueCartographer 自行生成 odom
use_odometryfalse不使用里程计
optimize_every_n_nodes20更频繁优化,补偿漂移
min_score0.55放宽匹配阈值

2.6 创建 Launch 文件 【已完成】

创建了两个新 launch 文件:

文件用途启动命令
map_cartographer_test_launch.py无底盘手持测试ros2 launch yahboomcar_nav map_cartographer_test_launch.py
map_cartographer_tg30_launch.py正式建图(底盘到后用)ros2 launch yahboomcar_nav map_cartographer_tg30_launch.py
测试版 launch 启动的内容:
  1. 雷达驱动(4ros_ydlidar_launch.py
  2. 静态 TF:base_footprint → base_link(高度 0.0815m)
  3. 静态 TF:base_link → laser(位移 + yaw 旋转)
  4. Cartographer 节点(无 odom 模式)
  5. 栅格地图发布节点
正式版 launch 启动的内容:
  1. 底盘 + 雷达(laser_bringup_launch.py
  2. Cartographer 节点(有 odom 模式)
  3. 栅格地图发布节点

3. 当前工作空间文件结构

~/ydlidar_ws/src/ ├── ydlidar_ros2_driver-master/ # 雷达驱动(阶段一已编译) ├── yahboomcar_description/ # URDF 机器人模型 ← 新增 │ ├── urdf/yahboomcar_X3.urdf # X3 小车模型 │ └── meshes/ # 3D 模型文件 ├── yahboomcar_msgs/ # 自定义消息 ← 新增 ├── yahboomcar_nav/ # 导航建图包 ← 新增 │ ├── launch/ │ │ ├── map_cartographer_test_launch.py ← 新建(手持测试) │ │ ├── map_cartographer_tg30_launch.py ← 新建(正式建图) │ │ ├── map_cartographer_launch.py # 原始 launch │ │ ├── save_map_launch.py # 保存地图 │ │ └── ... │ └── params/ │ ├── tg30_2d.lua ← 新建(有 odom 配置) │ ├── tg30_2d_no_odom.lua ← 新建(无 odom 配置) │ ├── lds_2d.lua # 原始配置 │ └── dwb_nav_params.yaml # 导航参数 

4. TF 坐标链

手持测试模式(无底盘)

map → odom → base_link → laser ↑ ↑ ↑ Cartographer 静态TF 静态TF 自动生成 (0,0,0.0815) (0.0435,0,0.11,yaw=π) 
base_footprint 在手持模式下通过静态 TF 连接到 base_link

正式建图模式(有底盘)

map → odom → base_footprint → base_link → laser ↑ ↑ ↑ ↑ SLAM 底盘编码器 URDF固定关节 静态TF +EKF 

5. 底盘的操作流程

# 第一步:安装 apt 依赖(如果还没装)sudoaptinstall-y ros-humble-cartographer ros-humble-cartographer-ros sudoaptinstall-y ros-humble-nav2-map-server sudoaptinstall-y ros-humble-robot-state-publisher ros-humble-joint-state-publisher ros-humble-xacro # 第二步:安装底盘驱动(根据底盘型号)# 具体命令待底盘到了再确定# 第三步:启动建图 ros2 launch yahboomcar_nav map_cartographer_tg30_launch.py # 第四步:遥控小车在房间里慢速移动,RViz 中观察地图构建 rviz2 # 添加 Map + LaserScan 显示# 第五步:建图满意后保存 ros2 launch yahboomcar_nav save_map_launch.py # 地图保存到 ~/ydlidar_ws/src/yahboomcar_nav/maps/yahboomcar.pgm + .yaml

6. 手持测试建图流程(可选,底盘到之前)

# 前提:已安装 Cartographer(sudo apt install ...)# 第一步:启动 ros2 launch yahboomcar_nav map_cartographer_test_launch.py # 第二步:手持雷达在房间里慢慢走(要求平稳,不能快速移动)# 第三步:在另一个终端打开 RViz 观察 rviz2 # 添加 Map 显示(topic: /map)# 添加 LaserScan 显示(topic: /scan)# 第四步:保存地图 ros2 launch yahboomcar_nav save_map_launch.py 
注意:手持建图精度较低,仅作为验证 Cartographer 是否正常工作。正式地图需等底盘到了重建。

7. 阶段二完成状态

序号步骤状态
2.1安装 apt 依赖待用户手动执行
2.2设置 LIDAR_TYPE 环境变量已完成
2.3复制并编译建图相关包已完成
2.4TF Frame 分析已完成(无需修复)
2.5Cartographer 配置优化已完成
2.6创建 Launch 文件已完成

Read more

Flutter 组件 ansi_text 适配鸿蒙 HarmonyOS 实战:终端色彩渲染,构建高性能 ANSI 日志高亮与命令行交互架构

Flutter 组件 ansi_text 适配鸿蒙 HarmonyOS 实战:终端色彩渲染,构建高性能 ANSI 日志高亮与命令行交互架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 ansi_text 适配鸿蒙 HarmonyOS 实战:终端色彩渲染,构建高性能 ANSI 日志高亮与命令行交互架构 前言 在鸿蒙(OpenHarmony)生态迈向工业级运维、涉及大量后台守护进程(Daemon)、系统日志审计及开发者工具链(CLI)开发的背景下,如何为枯燥的纯文本终端注入具备视觉层级的色彩与样式,已成为提升调试效率与故障定位速度的“视觉助推器”。在鸿蒙设备这类强调 AOT 极致性能与低级别 shell 交互的环境下,如果应用依然依赖基础的单色字符串输出日志,由于由于信息流极其庞大且缺乏重点,极易由于由于“视觉疲劳”导致关键系统警告或业务异常被淹没在海量数据中。 我们需要一种能够支持 ANSI 转义序列、具备富文本样式(加粗/背景色)且兼容多种终端模拟器的文本渲染方案。 ansi_text 为 Flutter 开发者引入了基于标准

By Ne0inhk
MySQL查看命令速查表

MySQL查看命令速查表

🎬 个人主页:艾莉丝努力练剑 ❄专栏传送门:《C语言》《数据结构与算法》《C/C++干货分享&学习过程记录》 《Linux操作系统编程详解》《笔试/面试常见算法:从基础到进阶》《Python干货分享》 ⭐️为天地立心,为生民立命,为往圣继绝学,为万世开太平 🎬 艾莉丝的简介: 文章目录 * 1 ~> MySQL 查看类命令大全 * 1.1 查看数据库 * 1.2 查看表 * 1.3 查看数 * 1.4 查看用户 / 权限 * 1.5 最常用组合(截图里就是这套) * 2 ~> MySQL常用核心命令速查表 * 2.1 MySQL 常用核心命令速查表 * 2.

By Ne0inhk
一款数据库SQL防火墙:可以拦截99.99%,可以阻止恶意SQL

一款数据库SQL防火墙:可以拦截99.99%,可以阻止恶意SQL

文章目录 * 一、SQL注入:那个偷偷溜进房子的"不速之客" * 二、三种模式,给数据库装上"智能门禁系统" * 三、又快又准又简单,这才是理想中的安全防护 * 1. 99.99%的拦截准确率,近乎"零误报" * 2. 性能损耗低于6%,业务无感 * 3. 两步配置,小白也能轻松上手 * 四、从党政到能源,为什么他们都选择了金仓? 在数字化转型的浪潮中,数据已成为企业的核心资产。然而,SQL注入攻击如同潜伏在阴影中的"不速之客",时刻威胁着数据库的安全。即使开发团队严守预编译、输入过滤等防线,遗留代码、第三方组件的漏洞或人为疏忽仍可能给攻击者可乘之机。难道只能被动挨打、疲于补漏吗?金仓数据库(KingbaseES)内置的SQL防火墙,

By Ne0inhk
二、Kafka核心架构与分布式存储

二、Kafka核心架构与分布式存储

思维导图 一、Kafka定位与核心特性 Kafka不仅是传统的消息队列中间件,更被官方定义为新一代的分布式事件流平台。它在海量流式计算场景中占据绝对核心地位,具备以下底层物理特性: 高吞吐与高并发:摒弃缓慢的随机寻址,深度依赖操作系统的页缓存与磁盘的顺序追加写。单机即可支撑每秒百万级的高并发数据吞吐。 可靠性与持久化存储:流动的数据直接落盘持久化至日志文件。配合多副本冗余机制,确保物理节点宕机时核心业务数据绝对不丢失。 高可扩展性与解耦:支持零停机数据处理。支持在线动态扩容Broker节点,自动实现海量数据流的负载均衡。极大解耦了微服务系统,提升了全链路数据处理效率。 二、分布式存储基石:HDFS架构深度剖析 要理解现代中间件的数据分布逻辑,必须先解剖大数据存储基石HDFS的底层架构。 HDFS采用中心化控制模型,由主管元数据的NameNode与负责物理存储的DataNode构成。一个超大文件会被物理切分为默认128MB的数据块,分散存储在不同DataNode的磁盘上。 为保障极高的容错率,HDFS制定了基于机架感知的副本放置关键原则。 默认的三副

By Ne0inhk