2814 字
7 分钟
CTU-MRS 双无人机灾后巡检项目复现记录
2026-09-23

2026/9/23#

这周开始复现 CTU-MRS Summer School 2026 项目。它并不是一个下载后直接运行的 Python 程序,而是一套完整的双无人机任务规划环境,里面包含 ROS 节点、三维场景、路径规划代码、无人机控制系统和 RViz 可视化。

目前已经完成源码准备、Apptainer 安装、容器镜像下载和 catkin 编译。ROS 工作区中的 4 个项目包都能被正常识别,最终编译结果为 All 5 packages succeeded。离线任务和完整动力学仿真还没有正式测试,因此这篇主要记录项目是做什么的,以及从 Windows 环境走到“能够编译”的过程。

项目中的灾后场景与双机轨迹

这个项目在做什么#

项目模拟的是灾后建筑中的无人机搜索任务。场景里有红、蓝两架无人机,它们需要在废墟和建筑障碍之间飞行,用机载相机检查一组目标点。这些点可以代表幸存者、危险物品,或者需要确认状态的关键位置。

目标点分为三类:红色点只能由红色无人机检查,蓝色点只能由蓝色无人机检查,紫色点可以交给任意一架。无人机也不是简单地“飞到坐标附近”就算完成,它需要到达合适的观察位置,同时让相机方向满足要求。位置误差需要控制在 0.3 m 以内,航向和俯仰误差不能超过 0.2 rad。

换成更直白的说法,这个项目需要回答四个问题:

  1. 紫色目标应该分给哪架无人机?
  2. 每架无人机应该按什么顺序访问目标?
  3. 怎样绕开废墟和建筑,从一个目标安全飞到下一个目标?
  4. 两架无人机怎样同时飞行,又不会互相碰撞?

这四个问题分别对应任务分配、旅行商问题(TSP)、三维路径规划和多机轨迹避碰。规划结果还要满足速度、加速度、障碍物距离和返航位置等要求。虚拟任务要求无人机与障碍物至少保持 1.5 m,与另一架无人机至少保持 2.5 m;如果违反关键约束,整次任务可能直接记为零分。

项目的基本流程#

程序首先读取问题文件,其中包括两架无人机的起点、检查目标、障碍点云和场景边界。每个检查点会被换算成一个适合相机观察的 Viewpoint,随后分配给两架无人机。

分配完成后,程序估算不同 Viewpoint 之间的距离,求出访问顺序,再使用 A*、RRT 或 RRT* 连接相邻目标。最后还要进行航向插值、路径平滑、时间参数化和轨迹采样,生成可以交给 ROS 控制系统执行的轨迹。

问题文件与障碍点云
检查点转换为观察位姿
目标分配与 TSP 访问顺序
A* / RRT / RRT* 三维路径规划
路径平滑、时间参数化与轨迹采样
双机碰撞检查
发布 ROS 轨迹并在 RViz 或模拟器中运行

官方给出的只是一个能够展示完整流程的基线方案,性能并不好。默认实现会随机分配紫色目标,TSP 使用欧氏距离估算,RRT 参数也比较保守;无人机在每一段路径末端都会停车,而且双机避碰默认关闭。代码中保留了不少 STUDENTS TODO,让参与者自己完成航向插值、KMeans 分配、A* 启发函数、RRT*、TOPPRA 时间参数化和冲突处理。

官方示例中的 RViz 运行效果

主要代码在哪里#

项目目录看起来比较多,但真正需要重点阅读的是 mrim_task/mrim_planner。竞赛评测也主要采用这个包中的代码。

文件用途
scripts/planner.py整个规划流程的入口,读取配置并发布两架无人机的轨迹
scripts/solvers/tsp_solvers.py目标分配、距离矩阵和 TSP 顺序
scripts/path_planners/grid_based/astar.py三维栅格 A* 路径规划
scripts/path_planners/sampling_based/rrt.pyRRT、RRT* 和路径拉直
scripts/trajectory.py航向插值、轨迹采样、TOPPRA 和双机避碰
config/virtual.yaml虚拟任务使用的算法参数
config/real_world.yaml真机任务使用的算法参数

其余几个 ROS 包也有各自职责。mrim_resources 保存消息定义、问题集、障碍点云和三维场景;mrim_manager 负责轨迹检查、计分和 RViz 信息;mrim_state_machine 用于协调在线仿真或真机任务。

复现需要什么#

官方推荐的运行环境是 Linux。Windows 11 可以使用 WSL 2,但不能直接在 PowerShell 中运行项目。本次使用的宿主环境是 WSL 2 + Ubuntu 22.04,真正的 ROS Noetic 和 MRS UAV System 则位于官方提供的 Apptainer 镜像中。

需要准备的内容如下:

  • Windows 11 和 WSL 2,或者原生 Linux;
  • Ubuntu 发行版;
  • Apptainer;
  • 官方 MRS UAV System 镜像,大小约 3.4 GB;
  • 至少 6 GB 可用空间,实际建议预留 10 GB 以上;
  • 运行 RViz 时还需要可用的图形环境,Windows 11 通常由 WSLg 提供。

使用容器的好处是宿主机不需要自己安装整套 ROS Noetic、Gazebo 和 MRS UAV System。项目脚本会把源码目录挂载进容器,再在容器中完成 catkin 编译和运行。

本次部署过程#

1. 准备 WSL 和 Ubuntu#

在 Windows 中启用 WSL 2,并安装 Ubuntu 22.04。进入 Ubuntu 后,把项目放到 Linux 文件系统中的 ~/git,而不是直接在 /mnt/c 下面编译。Linux 文件系统的权限和符号链接行为更加可靠,编译速度通常也更好。

mkdir -p ~/git
cd ~/git
git clone https://github.com/ctu-mrs/summer-school-2026.git
cd summer-school-2026

本次 GitHub 连接不稳定,所以源码先在 Windows 侧下载,再复制到 WSL。这个做法虽然能拿到全部文件,但后来也带来了一个不太明显的符号链接问题。

2. 安装 Apptainer#

项目根目录的 install.sh 会调用三个脚本:安装 Apptainer、下载镜像、编译工作区。Apptainer 安装正常完成,说明 WSL 2 可以作为这个项目的宿主环境。

cd ~/git/summer-school-2026
./install.sh

安装过程中出现了 /dev/dri.Xauthority 不存在的提示。前者与 GPU 图形设备有关,后者与 X11 认证有关。这两项在当前 WSLg 环境中没有阻止容器编译,暂时作为图形运行阶段需要继续观察的问题。

3. 手动下载容器镜像#

自动下载镜像时,服务器速度只有十几 KB/s,终端预计需要两天才能完成。镜像本身约 3.4 GB,继续等待并不实际,所以改用 Windows 浏览器下载,再复制到 WSL:

cp "/mnt/c/Users/minikou/Downloads/mrs_uav_system.sif" \
~/git/summer-school-2026/simulation/images/

复制后先检查大小:

ls -lh ~/git/summer-school-2026/simulation/images/mrs_uav_system.sif

这里需要特别注意:不要在镜像准备好后重新运行完整的 install.sh,因为上游的下载脚本开头会删除 simulation/images 中已有的 .sif 文件。

4. 修复复制源码造成的符号链接问题#

第一次执行编译时,catkin 提示工作区中没有 ROS 包:

Cannot compile, probably not in a workspace,
or, your workspace lacks ROS packages.

检查后发现:

simulation/user_ros_workspace/src/mrim_task

在官方 Git 仓库中本应是指向 ../../../mrim_task 的符号链接,但通过 Windows 下载和复制后,它变成了一个内容仅为 ../../../mrim_task 的普通文本文件。catkin 因此看不到真正的 ROS package。

修复方法是保留原文件作为备份,然后重建链接:

cd ~/git/summer-school-2026/simulation/user_ros_workspace/src
mv mrim_task mrim_task.link-placeholder
ln -s ../../../mrim_task mrim_task
ls -l mrim_task

正确结果应类似:

mrim_task -> ../../../mrim_task

修复后,catkin 能识别 mrim_plannermrim_managermrim_resourcesmrim_state_machine 四个 ROS 包。

5. 编译工作区#

镜像和符号链接都准备好后,单独运行编译脚本:

cd ~/git/summer-school-2026
./simulation/03_compile.sh

本次编译耗时约 23 秒,结果如下:

[build] Summary: All 5 packages succeeded!
[build] Failed: No packages failed.
[build] Runtime: 23.4 seconds total.

日志中还出现 Gazebo Classic 已停止维护、部分 CMake 文件写法过时等警告。这些警告来自 ROS Noetic 和镜像中的旧版本依赖,没有导致当前项目编译失败,不需要为了消除警告贸然升级依赖。

接下来怎么运行#

项目提供离线和在线两种模式。第一次应先运行离线模式,它不会模拟真实飞行动力学,启动快,更适合检查目标分配、路径规划和轨迹是否正常。

cd ~/git/summer-school-2026
./simulation/run_offline.sh

如果图形界面暂时有问题,可以先使用无界面模式查看规划器日志:

./simulation/run_offline.sh --nogui

完整双机仿真使用:

./simulation/run_simulation.sh

它会通过 tmux 启动 ROS master、两架 x500、多旋翼模拟器、控制器、状态机和 RViz。结束时不要直接关闭一堆终端,而应使用:

./simulation/kill_simulation.sh

项目准备了 small、moderate 和 large 三组问题。后续调试会先从 apocalypse_small.problem 开始,确认基本功能后再扩大场景,避免一开始就在大型问题上等待很久,却难以判断错误到底来自算法还是环境。

这次复现中比较重要的经验#

这次最耗时间的部分并不是代码编译,而是镜像下载和文件形式。一个只有 18 字节的普通文件,看上去很不起眼,却会让整个 ROS 工作区显示“没有包”。这也说明复制 Git 项目时不能只检查文件数量和大小,还要注意符号链接、可执行权限和换行符。

另外,容器解决了依赖版本问题,却没有完全消除宿主环境差异。/dev/dri、X11、WSLg 和 .Xauthority 都位于容器与桌面图形之间。编译成功只能说明代码和依赖基本就绪,不能直接等同于 RViz 和完整仿真已经跑通。

目前比较准确的进度是:源码完整、镜像可用、ROS 包可发现、catkin 编译成功;离线规划和完整仿真仍待验证。

下一步计划#

下一步先跑通 apocalypse_small 的离线模式,记录基线方案的规划时间、轨迹时长、得分和碰撞情况。环境稳定后,再从以下几个位置开始改进:

  1. 完成航向插值,保证无人机到达目标时相机方向正确;
  2. 比较 A* 和 RRT 的路径质量及计算时间;
  3. 将紫色目标的随机分配改成更均衡的分配方法;
  4. 尝试路径拉直和 TOPPRA 连续时间参数化,减少中途停车;
  5. 最后处理两架无人机之间的轨迹冲突。

对我而言,这个项目的价值不只是“跑起来一个无人机仿真”,而是把任务分配、组合优化、三维路径规划、轨迹生成和多机安全约束放进了同一条工程链路。后续每次修改都可以在同一个场景中比较覆盖率、规划耗时、任务时间和安全距离,比只在单独的算法示例上测试更接近实际问题。

分享

如果这篇文章对你有帮助,欢迎分享给更多人!

CTU-MRS 双无人机灾后巡检项目复现记录
https://minikou.cloud/posts/weekly_summary/
作者
minikou
发布于
2026-09-23
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

目录