RealSense D455 语义 SLAM：从 RGB-D 到语义八叉树地图 要在 RealSense D455 相机上实现 语义 SLAM（Semantic SLAM） 并生成 语义八叉树地图（Semantic Octree Map），通常需要将 稠密几何建图（如 OctoMap） 与 语义分割（如 Mask R-CNN、YOLO、或 Fast-SCNN） 相结合，并利用 RGB-D 数据（来自 D455 的深度 + 彩色对齐图像）进行融合。 📋 目录 整体架构概览 核心组件与技术选型 实现路径：渐进式开发 阶段 1：纯几何 OctoMap 阶段 2：2D 语义分割接入 阶段 3：3D 语义点云生成 阶段 4：语义融合到 OctoMap 性能优化技巧 参考资源 整体架构概览 RealSense D455 │ ├─▶ 配准的 RGB + Depth 图像流 │ ├─▶ 位姿估计（SLAM 系统） │ ├─ RTAB-Map（推荐，支持 OctoMap 导出） │ ├─ ORB-SLAM3 + OctoMap（需自定义融合） │ └─ OpenVINS + 外部建图 │ └─▶ 语义分割（2D） ├─ 输出每个像素的语义标签 └─ 与深度图反投影 → 3D 语义点云 │ └─▶ 融合到位姿对齐的 OctoMap → 语义八叉树 数据流详解 ┌─────────────────────────────────────────────────────────────────┐ │ RealSense D455 │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ RGB 图像 │ │ 深度图像 │ │ IMU │ │ │ │ 640×480@30 │ │ 640×480@30 │ │ 200Hz │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ └─────────┼────────────────┼────────────────┼─────────────────────┘ │ │ │ ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ ROS 2 消息传输 │ │ /camera/color /camera/aligned_depth /camera/imu │ │ /image_raw _to_color/image_raw │ └─────────┬────────────────┬────────────────┬─────────────────────┘ │ │ │ ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 处理管线 │ │ ┌─────────────┐ ┌─────────────────────────────────────┐ │ │ │ 语义分割 │ │ RTAB-Map │ │ │ │ (YOLOv8) │ │ ┌─────────┐ ┌─────────────────┐ │ │ │ │ │ │ │ 视觉里程计│ │ 闭环检测 │ │ │ │ └──────┬─────┘ │ └────┬────┘ └────────┬────────┘ │ │ │ │ │ │ │ │ │ │ ▼ │ ▼ ▼ │ │ │ ┌─────────────┐ │ ┌─────────────────────────────┐ │ │ │ │ 语义标签图 │ │ │ 位姿图优化 │ │ │ │ │ H×W labels │ │ │ /rtabmap/odom │ │ │ │ └──────┬─────┘ │ └──────────────┬──────────────┘ │ │ │ │ └─────────────────┼───────────────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌────────────────────────────────────────────────────┐ │ │ │ 语义点云生成器 │ │ │ │ RGB + Depth + Labels + Pose → Semantic PointCloud │ │ │ └────────────────────────┬───────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────────────────────────────────────────────┐ │ │ │ 语义 OctoMap 融合 │ │ │ │ ColorOcTree / SemanticOcTree │ │ │ └────────────────────────┬───────────────────────────┘ │ └───────────────────────────┼───────────────────────────────────┘ │ ▼ ┌───────────────┐ │ 语义八叉树地图 │ │ .sot / .bt │ └───────────────┘ 核心组件与技术选型 1. RealSense D455 驱动与数据流 # 安装 RealSense ROS 2 驱动 sudo apt install ros-humble-realsense2-camera # 启动相机（确保 RGB-D 对齐） ros2 launch realsense2_camera rs_launch.py \ align_depth.enable:=true \ depth_module.profile:=640x480x30 \ rgb_camera.color_profile:=640x480x30 关键话题： ...

RealSense D455 相机-IMU 标定：Kalibr 之外的替代方案 Kalibr 确实是视觉–惯性传感器（如 D455 的相机 + IMU）外参标定的 经典、高精度方案，但它对硬件操作、数据采集和计算要求较高。如果你希望 更简单、更快上手、或适配 ROS 2 / RealSense 特性，本文介绍多种替代路线供你选择。 📋 目录 标定基础知识 方案 1：使用 RealSense 出厂外参（最简单） 方案 2：rs-imu-calibration（IMU 内参校准） 方案 3：imu_utils + 手动外参估计 方案 4：Basalt 在线标定（进阶替代） 方案 5：从 TF 树读取外参 路线选择建议 附录：Kalibr Docker 快速上手 标定基础知识 什么需要标定？ 参数类型 内容 影响 相机内参 fx, fy, cx, cy, 畸变系数 像素坐标 ↔ 相机坐标转换精度 IMU 内参 bias, scale, misalignment IMU 测量值校正 IMU-Camera 外参 旋转 R + 平移 t（T_imu_cam） 传感器融合的坐标对齐 时间偏移 IMU 与相机的时间戳差 时空同步精度 标定精度对 VIO 的影响 外参误差 → 轨迹漂移 ↓ 旋转误差 1° → 100m 处约 1.7m 横向偏移 平移误差 1cm → 直接传递到位置估计 时间偏移 10ms → 高速运动时严重错位 💡 好消息：OpenVINS 的 MSCKF 框架对初始外参误差有一定容忍度，只要不太离谱（< 5°旋转、< 5cm 平移）。 ...

Windows 与 Linux 启动过程对比 总体对比 (Overview) 目的: 比较 Windows 与 Linux 从上电/重启到用户空间可用的启动（boot）流程的异同。 范围: 包含固件（BIOS/UEFI）、引导加载器（Bootloader/Windows Boot Manager）、内核加载与初始化、用户空间初始化（服务/守护进程）、以及常见故障排查点和常用命令。 关键差异 (Key Differences) 可定制性: Linux 启动链条更模块化、可替换（如 GRUB、systemd-boot、LILO），调试与定制更方便；Windows 的引导流程相对封闭，主要由固件 + Windows Boot Manager + Boot Loader (winload.exe) 驱动。 初始化系统: Windows 使用 Service Control Manager 启动服务；现代 Linux 普遍使用 systemd（或 SysV/init、OpenRC 等）做为 init 系统。 日志与可视化: Linux 在早期可通过 dmesg、journalctl 查看内核与 init 日志；Windows 有事件查看器（Event Viewer），但早期内核启动日志不如 Linux 直观。 Windows 启动流程 (Windows Boot Process) 1. 固件初始化（BIOS/UEFI）: BIOS: 执行 POST（电源自检），寻找 MBR（主引导记录）。 UEFI: 初始化设备并读取 EFI 可执行文件（如 \\EFI\\Microsoft\\Boot\\bootmgfw.efi）。 2. Windows Boot Manager (Bootmgr): 在 BIOS/UEFI 找到引导项后，加载 Windows Boot Manager。 负责选择启动项（多重引导场景），并加载 Windows 引导加载器 winload.exe 或 winload.efi。 3. Windows 引导加载器 (winload): 加载内核（ntoskrnl.exe）和必要的驱动（如存储、文件系统驱动）。 初始化硬件抽象层（HAL）、将控制权交给内核。 4. 内核初始化: 内核启动并初始化内核线程、驱动程序、内存管理等。 启动 Session Manager 子系统（smss.exe），它会创建用户会话并启动 csrss.exe、wininit.exe 等。 5. 服务与登录: wininit.exe 启动 services.exe（Service Control Manager）和 lsass.exe（登录服务）。 Service Control Manager 启动系统服务，最终显示登录界面（winlogon）。 graph TD PowerOn[上电 / POST] Firmware[BIOS / UEFI] BootMgr[Windows Boot Manager\n(bootmgr / bootmgfw.efi)] Winload[Windows Loader\n(winload.exe / winload.efi)] Kernel[内核\n(ntoskrnl.exe) & HAL] SMSS[Session Manager\n(smss.exe)] Wininit[wininit.exe] --> Services[services.exe / lsass.exe] Winlogon[登录 (winlogon) / 用户会话] PowerOn --> Firmware --> BootMgr --> Winload --> Kernel --> SMSS --> Wininit --> Winlogon Linux 启动流程 (Linux Boot Process) 1. 固件初始化（BIOS/UEFI）: BIOS: 执行 POST，读取 MBR 并跳转到引导加载器（如 GRUB stage1）。 UEFI: 直接加载 EFI 可执行文件（常见为 \\EFI\\GRUB\\grubx64.efi 或 \\EFI\\systemd\\systemd-bootx64.efi）。 2. 引导加载器（GRUB / systemd-boot / LILO）: 加载并解析配置文件（例如 grub.cfg），提供多内核/多系统选择菜单。 将内核映像（vmlinuz）和初始内存盘（initramfs/initrd）加载到内存。 3. 内核启动 (Kernel): 解压并启动内核，内核初始化硬件、设备驱动、挂载根文件系统（若使用 initramfs，则由其帮助挂载真正的根分区）。 内核启动完成后，启动用户空间的第一个进程（PID 1）：传统上为 /sbin/init 或 systemd。 4. Init 系统（如 systemd）: systemd 会读取单元(unit)文件并并行启动服务、挂载点、网络、登录管理器（如 gdm、lightdm）等。 旧式系统使用 SysV init 脚本（/etc/init.d）或 Upstart。 5. 用户会话与图形环境: 登录管理器处理用户认证，启动桌面环境（如 GNOME、KDE）。 graph TD PowerOnL[上电 / POST] FirmwareL[BIOS / UEFI] Bootloader[GRUB / systemd-boot / LILO] KernelL[vmlinuz + initramfs] Initramfs[initramfs / initrd (救援环境)] Init[PID 1\n(systemd / init)] ServicesL[systemd 单元 / init 脚本] LoginL[登录管理器 / 用户会话] PowerOnL --> FirmwareL --> Bootloader --> KernelL --> Initramfs --> Init --> ServicesL --> LoginL 对比要点 (Comparison Points) 引导器可见性与交互: GRUB 提供交互式菜单并易于编辑启动参数；Windows Boot Manager 也有界面，但手工编辑启动参数相对不便。 开源 vs 封闭: Linux 启动链多为开源，便于追踪与自定义；Windows 启动流程中间环节为闭源二进制。 故障诊断: Linux 的早期用户态（initramfs）可通过 busybox 的 shell 进入救援模式；Windows 在早期阶段通常进入自动修复或需要使用 Windows 安装介质进行修复。 启动速度优化: Windows 通过快速启动（Hybrid Boot）利用 hibernation 优化冷启动；Linux 可通过并行服务启动、内核定制和 systemd 的 socket/parallel 启动优化。 常见故障点与排查命令 (Troubleshooting & Commands) Windows: 引导修复: 使用 Windows 安装介质并运行 bootrec /fixmbr、bootrec /fixboot、bootrec /rebuildbcd。 查看事件日志: 打开 事件查看器（Event Viewer），检查 System 与 Application 日志。 Linux: 查看内核环形缓冲区: dmesg | less 查看 systemd 日志: journalctl -b（当前启动）或 journalctl -k（内核消息）。 进入 initramfs 救援 shell: 在 GRUB 编辑内核行，添加 break=mount 或 init=/bin/sh，查看挂载与驱动问题。 修复 GRUB: 在 Live 环境下 chroot 到系统并运行 grub-install / update-grub（不同发行版命令可能不同）。 示例：查看启动日志 Linux（当前启动的 systemd 日志）： journalctl -b -u sshd.service journalctl -b --no-pager | less Windows（查看启动相关事件）： 在 事件查看器 中查看 Windows Logs -> System，筛选关键字 Boot 或 Kernel-Power。 参考与延伸阅读 (References & Next Steps) Microsoft Docs: Windows Boot Process - https://learn.microsoft.com/windows-hardware/drivers/gettingstarted/windows-boot-process kernel.org: Linux Boot Process - https://www.kernel.org/doc/html/latest/admin-guide/booting.html GNU GRUB Manual - https://www.gnu.org/software/grub/manual/ systemd 官方文档 - https://www.freedesktop.org/wiki/Software/systemd/ ArchWiki: Boot process - https://wiki.archlinux.org/title/Boot_process Ubuntu Community Docs: Boot-Repair and recovery tips - https://help.ubuntu.com/community/Boot-Repair 文档已作为初稿写入 posts/windows-vs-linux-启动过程对比.md，需要我继续添加图表或更深入的发行版示例吗？

ROS2 Humble + OpenVINS 源码编译：混合安装最佳实践 在 Ubuntu 22.04 + ROS2 Humble 环境下，你可以： ✅ 用 apt 安装 ros-humble-desktop（提供核心通信、rviz2、工具链等） ✅ 同时从源码编译 OpenVINS（获取最新功能、便于调试、支持自定义修改） 这是非常推荐的开发模式：底层依赖用系统包（稳定），上层算法用源码（灵活）。 📋 目录 为什么可以混合使用？ 从源码编译 OpenVINS OpenVINS 是否用于"显示 SLAM"？ 推荐工作流：D455 + OpenVINS + rviz2 D455 专用配置文件模板 常见问题排查 为什么可以混合使用？ 组件 来源 说明 ROS2 核心（rclcpp, sensor_msgs, tf2, rviz2） apt install ros-humble-desktop 系统级依赖，稳定、免编译 OpenVINS GitHub 源码编译 算法层应用，常需调试、改参数、加日志 🔗 OpenVINS 源码编译时，会自动链接 /opt/ros/humble 中的头文件和库，无缝配合。 混合安装的优势 ┌─────────────────────────────────────────────────────────┐ │ 你的算法层 │ │ ┌─────────────────────────────────────────────────┐ │ │ │ OpenVINS (源码编译) │ │ │ │ - 可调试、可修改、可加日志 │ │ │ │ - 获取最新功能和 Bug 修复 │ │ │ └─────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────┤ │ ROS2 底层依赖 │ │ ┌─────────────────────────────────────────────────┐ │ │ │ ros-humble-desktop (apt 安装) │ │ │ │ - rclcpp, sensor_msgs, tf2, rviz2 │ │ │ │ - 稳定、经过测试、自动更新 │ │ │ └─────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────┘ 从源码编译 OpenVINS 前置条件 确保已安装 ROS2 Humble Desktop： ...

自动驾驶传感器融合参数详解 自动驾驶系统依赖多种传感器（摄像头、激光雷达、毫米波雷达、超声波、IMU、GPS 等）协同工作，而传感器融合（Sensor Fusion）是将这些异构数据整合为统一环境感知的关键技术。本文系统性地介绍融合参数的配置、调优方法及最佳实践。 📋 目录 传感器融合概述 时空同步参数 融合算法核心参数 传感器权重与置信度 目标关联参数 融合层级与架构参数 参数调优实践 常见问题与解决方案 传感器融合概述 为什么需要传感器融合？ 传感器 优势 劣势 摄像头 丰富的语义信息、车道线/交通标志识别 受光照影响大、无直接深度信息 激光雷达 (LiDAR) 高精度 3D 点云、不受光照影响 成本高、雨雪天气性能下降 毫米波雷达 测速准确、全天候工作、成本低 角分辨率低、无法识别静止物体 超声波 近距离精确、成本极低 探测距离短、易受干扰 IMU + GPS 高频率定位、惯性导航 GPS 在隧道/城市峡谷失效 💡 核心思想：通过融合互补的传感器数据，实现 1 + 1 > 2 的感知效果，提升系统的鲁棒性和冗余性。 时空同步参数 时空同步是融合的基础，确保不同传感器的数据对齐到同一时间点和坐标系。 时间同步参数 time_sync: # 硬件触发同步（推荐） hardware_trigger: enabled: true master_clock: "gps_pps" # 主时钟源：GPS PPS 信号 trigger_frequency_hz: 10 # 触发频率 # 软件时间戳对齐 software_sync: max_time_diff_ms: 50 # 最大允许时间差（毫秒） interpolation_method: "linear" # 插值方法：linear / spline / nearest timestamp_source: "sensor" # 时间戳来源：sensor / host / gps # 延迟补偿 latency_compensation: camera_delay_ms: 30 # 摄像头处理延迟 lidar_delay_ms: 10 # 激光雷达延迟 radar_delay_ms: 5 # 毫米波雷达延迟 空间标定参数（外参） spatial_calibration: # 激光雷达到车体坐标系的变换 lidar_to_vehicle: translation: [1.5, 0.0, 1.8] # [x, y, z] 单位：米 rotation_euler: [0.0, 0.0, 0.0] # [roll, pitch, yaw] 单位：度 rotation_quaternion: [1.0, 0.0, 0.0, 0.0] # [w, x, y, z] # 摄像头到激光雷达的变换 camera_to_lidar: translation: [0.05, -0.02, -0.1] rotation_euler: [-1.5, 0.5, -0.3] # 标定误差容忍度 calibration_tolerance: translation_error_m: 0.02 # 平移误差容忍（米） rotation_error_deg: 0.5 # 旋转误差容忍（度） 关键参数说明 参数 典型值 影响 max_time_diff_ms 30-100ms 过小导致数据丢弃，过大导致时序错乱 translation_error_m 0.01-0.05m 影响目标位置准确度 rotation_error_deg 0.1-1.0° 远距离目标误差放大 融合算法核心参数 卡尔曼滤波（KF）参数 适用于线性系统的状态估计： ...

测试目的 测试修复后的双模式自动部署架构： ✅ 模式1：从 obsidian-notes 推送内容触发部署 ✅ 模式2：从 hugo-server 推送主题/配置触发部署 修复内容 修复了 obsidian-notes/.github/workflows/deploy.yml 中的错误： 问题 尝试在 jesse-blog/public 执行 git 操作 但 public 目录被 .gitignore 忽略 解决方案 使用 peaceiris/actions-gh-pages@v3 替代手动 git 操作 测试时间 2025-11-22 08:52:33 UTC

远程推送测试 此文档用于测试从远程主机推送内容是否会触发自动构建流程。 预期结果 推送此文档后，obsidian-notes 的 GitHub Actions 应该被触发 工作流程应该触发 hugo-server 的构建 工作流程应该自动更新 hugo-server 中的子模块引用 测试结果 在 GitHub Actions 日志中验证流程是否按预期工作。 测试时间: 2025-11-20

GitHub Actions 自动更新测试 这个文档用于测试新的 GitHub Actions 功能，该功能将自动更新主仓库（hugo-server）中的子模块引用。 预期行为 当这个文档被推送时： obsidian-notes 仓库的 GitHub Actions 应该被触发 工作流程将： 触发 hugo-server 的构建 自动更新 hugo-server 中 jesse-blog/content 的子模块引用 最终 hugo-server 仓库将指向最新的内容提交 测试内容 这将验证我们设置的自动化功能是否正常工作！ 测试时间: 2025-11-20

日常写作工作流程测试 这用于测试仅推送子模块的场景。 在日常写作中，我只在 obsidian-notes 仓库中进行操作： 编写和编辑内容 提交更改 推送到远程 然后 GitHub Actions 会自动触发主仓库的构建流程。