企业官网建设流程全解析

从阿木实验室的Prometheus项目一发布，就有不少朋友私信问我同一个问题：这个Prometheus到底是不是那个监控告警用的Prometheus？怎么下载下来的代码跟想象中完全不一样？其实我刚接触的时候也犯过同样的糊涂。今天这篇就把阿木实验室Prometheus开源项目的下载、编译和仿真跑通从头到尾捋一遍，重点记录那些新手最容易栽进去的坑，以及我是怎么一步步爬出来的。

先说清楚，本文聊的是阿木实验室（AMOVLAB）开源的无人机集群开发平台Prometheus，这是一套基于PX4和ROS的无人机二次开发项目，包含Gazebo仿真、目标检测、集群控制等模块。不是那套用Golang写的监控系统Prometheus。虽然名字一模一样，但两个项目八竿子打不着，搜索的时候务必加上“阿木实验室”或者“无人机”做限定词。

1. 先把名字拆清楚：此Prometheus非彼Prometheus

1.1 阿木实验室Prometheus到底是干什么的

阿木实验室的Prometheus项目，本质上是一套面向无人机开发者的一站式二次开发平台。它把PX4固件、MAVROS通信链路、Gazebo仿真环境、视觉感知算法、集群控制逻辑揉合在一起，提供了一个可以直接跑起来的无人机软件开发基线。

我之前用原生PX4开发的时候，最痛苦的就是所有东西都要自己拼：机载电脑和飞控之间怎么通信、仿真环境怎么配置、视觉数据怎么接入控制环。Prometheus把这些统一封装了，开发者只需要把精力放在算法层，不用每次从零开始搭架子。

这个项目适合的人非常明确：想学无人机SLAM、目标跟踪、集群编队，但不想被底层通信和仿真配置折磨的研究生、算法工程师和极客爱好者。

1.2 与监控Prometheus的恩怨情仇

这里必须多说一嘴，因为我在实际搜索资料时发现大量新手被名字带偏。监控领域那个Prometheus是CNCF旗下的开源监控系统，主要做指标采集、时序存储和告警，前端经常搭配Grafana看板使用。而阿木实验室的Prometheus项目托管在Gitee上，仓库名就叫Prometheus，整个项目的文档和issue里讨论的全是无人机仿真、px4_command控制接口、目标检测这些内容。

判断方法很简单：打开项目主页，如果一进去看到的是无人机效果图和Gazebo仿真截图，那你就来对地方了；如果满屏幕都是YAML配置和监控指标，那说明你搜到了隔壁项目。

1.3 这个项目的整体架构一览

先给一个整体认知，Prometheus项目在代码层面大致可以分为几块：

• 仿真环境模块：基于Gazebo搭建的无人机模型和世界场景，支持多种机型的动力学仿真。
• 控制模块：上层提供统一控制接口，屏蔽PX4原生消息的复杂度，让算法层只需要发布期望位置、速度或姿态。
• 感知模块：包括目标检测、激光雷达数据处理、视觉定位等，用于完成自主导航和目标追踪任务。
• 集群模块：面向多无人机协同，提供编队控制的基本框架。

一句话总结：如果你在做一个需要自主飞行、目标识别或者多机协同的项目，Prometheus能帮你节省至少一两个月的底层搭建时间。

2. 下载前的准备：版本匹配是第一道门槛

2.1 操作系统与ROS版本别选错

这是我见过最多人卡住的地方。Prometheus对系统的要求非常明确：Ubuntu 16.04配ROS Kinetic，或者Ubuntu 18.04配ROS Melodic。到了Ubuntu 20.04和ROS Noetic的时候，因为PX4和Gazebo的版本兼容问题，跑通难度会大很多。

我当时用的的是Ubuntu 18.04 + ROS Melodic，这个组合官方文档支持得最完整，网上踩坑帖子也最多，遇到问题百度一下基本都有答案。如果你用20.04，不是不行，但需要自己处理一堆依赖冲突，新手不推荐。

另外一个容易忽略的点：系统必须是64位。虽然现在很少有人用32位系统了，但我在论坛里确实见过有人在老电脑上折腾32位，最后连Gazebo都启动不起来。

2.2 源码获取的正确渠道

阿木实验室的Prometheus代码主要托管在Gitee上，官方仓库地址是gitee.com/amovlab/prometheus，直接git clone或者下载zip包都行。

这里强烈建议用git clone而不是下载zip压缩包。原因有两个：第一，项目体积不小，zip在传输过程中容易损坏，我碰到过一次解压报错的情况；第二，后续你要跟踪官方更新，git可以直接pull，zip就得重新下载覆盖。

git clone https://gitee.com/amovlab/prometheus.git

注意clone下来的目录结构，项目根目录下会有Modules、Simulator、Utils、px4_firmware等几个核心文件夹。很多人一看到px4_firmware就以为固件已经在里面了，实际上PX4的子模块是通过git submodule方式引用的，需要额外初始化。

2.3 磁盘空间与硬件性能要求

Prometheus整个工程克隆下来大约几个GB，编译之后还会产生大量中间文件，建议预留至少30GB磁盘空间。我最初在虚拟机里折腾，分配的磁盘只有20GB，编到一半磁盘满了，Gazebo模型和编译缓存全堆在系统盘里，清理起来非常痛苦。

内存方面，16GB是舒适区，8GB也能跑但编译时会明显吃力。如果内存不够，后面我会讲到swap的配置方法，能救急但不能完全替代物理内存。

CPU的话，四核以上基本够用，编译慢一点但能跑完。Gazebo仿真本身对CPU要求不高，但如果你同时跑YOLO目标检测，GPU就很重要了，否则帧率感人。

3. 编译环节的典型雷区：从告警刷屏到能用的距离

3.1 子模块初始化是第一步，漏了必炸

clone完仓库后，第一件事不是catkin_make，而是初始化子模块。Prometheus引用了多个外部仓库，最核心的就是PX4固件。如果跳过这一步直接编译，你会发现一堆找不到的头文件，比如px4_msgs相关的消息定义全是空的。

cd prometheus git submodule update --init --recursive

这个过程会拉取PX4固件以及依赖的一些第三方库，速度取决于网络环境。我拉的时候断断续续跑了快二十分钟，中间失败了好几次，解决办法是反复执行上面的命令，git会自动续传已下载的部分。

如果你用的是国内网络，建议把Gitee的镜像地址替换掉子模块中的GitHub地址。操作方法是在.gitmodules文件里把url更换为gitee上的镜像仓库，否则部分子模块可能会因为访问问题反复失败。

3.2 编译前必须装的依赖，一个都别省

Prometheus依赖的东西远比预想的多。除了基础的ROS Melodic和Gazebo，还需要装一堆Python依赖和系统库。官方文档列了一个install.sh脚本，但我的经验是这个脚本并不完美，在某些干净系统上会漏装东西。

我建议在跑官方脚本之前，先把下面这些基础组件装好：

sudo apt-get update sudo apt-get install python3-pip python3-dev python3-tk sudo apt-get install libeigen3-dev libopencv-dev sudo apt-get install protobuf-compiler libprotobuf-dev sudo apt-get install ros-melodic-mavros ros-melodic-mavros-msgs pip3 install numpy scipy matplotlib pyyaml

特别提醒一下，protobuf这个依赖非常关键，版本必须和ROS自带的protobuf保持兼容。如果系统里装了高版本的pip protobuf，编译Prometheus的感知模块时会报一堆类似undefined reference to google::protobuf的链接错误，这种错误极其难查。

3.3 catkin_make的坑与解决方式

Prometheus官方推荐用catkin_make编译，不要用catkin build。因为项目里有些模块的CMakeLists.txt是为catkin_make设计的，换成catkin build可能会因为工作空间叠加问题出现奇怪错误。

我的操作步骤是这样的：

mkdir -p ~/prometheus_ws/src cd ~/prometheus_ws/src ln -s ~/prometheus/src/* . cd ~/prometheus_ws catkin_make

这里用软链接的方式把Prometheus的src目录下的所有module链接到工作空间的src下，而不是直接复制文件，这样以后git pull更新后工作空间自动同步，不需要重复拷贝。

第一次编译时间比较长，以我的机器（i5-8400 + 16GB内存）大概跑了三十分钟左右。期间会看到大量红色告警，别慌，很多只是warning不是error。判断是否成功的关键是最后的输出有没有显示[100%] Built target xxx以及Process package xxx: SUCCESS。

如果编译到中途自动退出，最常见的两个原因就是内存不够被系统杀掉（Killed）或者某个依赖包缺失。内存被杀这种情况没有任何报错信息，就是进程直接消失，解决办法看下一小节。

3.4 swap空间不足问题：谷歌搜不到的隐性杀手

编译Prometheus的时候，链接器需要占用大量内存，尤其是编译px4控制模块和感知模块时。8GB内存的机器如果不配swap，几乎必死；16GB的机器也出现过被系统OOM杀掉的情况。

检查方法是在编译过程中另开一个终端，用htop或者free -h观察内存占用。如果发现内存趋近100%，但free -h里swap显示为0，那就是没配swap。

配swap的方法不复杂：

sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

配置完可以用free -h验证，Swap一栏应该显示8G。把swap启用后重新编译，之前到90%左右就Killed的项目，这次顺利通过。

需要注意的是，swap只能救急，不能治本。Gazebo仿真跑起来后如果内存持续吃紧，该加物理内存还是得加。

3.5 蓝屏重启后最容易被忽略的问题

有一次我编译到一半电脑重启了，重新开机后直接编译，结果报了一堆莫名其妙的错误，比如找不到某个库的so文件、Gazebo启动瞬间崩溃。折腾了半天才发现是没有source环境变量。

每次开新终端执行仿真之前，务必先执行：

source ~/prometheus_ws/devel/setup.bash

更稳妥的做法是直接写进~/.bashrc，一劳永逸：

echo "source ~/prometheus_ws/devel/setup.bash" >> ~/.bashrc source ~/.bashrc

这个细节看起来微不足道，但很多人跑不通仿真就是因为少了这一步，Gazebo打开后却找不到机器人和无人机模型。

4. 仿真跑通的关键动作：launch文件的启动逻辑

4.1 先理解仿真启动链路，别上来就乱敲命令

Prometheus的仿真启动非常讲究顺序，如果你没搞清背后的链路，就会陷入“启动了但飞机没反应”的尴尬局面。

整个仿真链路的逻辑是：先启动Gazebo仿真环境，在虚拟世界里创建一架无人机模型；接着启动PX4的软件在环仿真（SITL），让飞控固件跑在宿主机上；然后启动MAVROS，作为机载电脑和飞控之间的通信桥梁；最后启动Prometheus的自研控制模块，将上层的控制指令转换成MAVROS消息发给PX4。

官方为了方便，把这些环节打包成了一个个launch文件，一键启动。但理解这个链路对排查问题至关重要——比如无人机在Gazebo里出现但没反应，你至少能判断是MAVROS没连上还是控制模块没起来，而不是瞎试。

4.2 常见启动命令的差异与选择

Prometheus提供了多种launch文件，对应不同类型的任务。我实际用过的有下面几个：

roslaunch prometheus_gazebo sitl_gazebo_P450.launch

这条命令启动的是单机P450无人机的仿真环境，包含Gazebo场景和PX4 SITL，以及MAVROS通信。我把它当作日常测试的基本环境，启动后Gazebo界面出现一架多旋翼无人机，控制台会滚动输出PX4的启动日志。

如果要做目标检测实验，还需要额外加载视觉传感器模型，官方提供了带camera的launch文件。命令类似：

roslaunch prometheus_gazebo sitl_gazebo_P450_camera.launch

需要注意，launch文件的名字在不同版本里可能略有变化，最好到prometheus_gazebo/launch目录下ls一下，看有哪些可用的文件，再根据名字判断用途。

4.3 如何判断系统是真的“跑起来”了

对新手来说，最难的一件事是分辨“程序启动了”和“系统真的跑通了”的区别。很多时候窗口都弹出来了，但内部通信没建立，飞机根本无法控制。

我个人的判断标准有三条。第一条，执行rostopic list，看有没有/mavros/state这个话题。MAVROS连接PX4成功后，这个话题会以10Hz左右频率发布数据，用rostopic echo /mavros/state -n1能看到connected: True。

第二条，执行rostopic echo /mavros/state，输出里armed和mode字段要能正常变化。如果你尝试解锁（arm）后，armed还是False，说明飞控没收到解锁指令或存在安全隐患。

第三条，看MAVROS的日志输出，正常连接后会有类似FCU: detected的提示，说明PX4与MAVROS的串口/UDP通道已经打通。

这三条都满足，才说明仿真环境真正跑通了，可以开始控制飞机。

4.4 手动起飞与航线任务两种路径

Prometheus提供了两种控制飞机的路径：一种是直接使用QGroundControl地面站，像操作真实无人机一样在图形界面里解锁和起飞；另一种是通过Prometheus的控制接口，在终端里发命令或者写脚本控制。

我日常调代码时更喜欢第二种，因为逻辑清晰，方便调试。Prometheus的控制接口叫prometheus_control，发布到/prometheus/control话题上的消息格式包含你想要飞行器执行的动作类型（位置控制、速度控制、姿态控制等）。

一个典型的起飞操作可以这样：

rostopic pub /prometheus/control prometheus_msgs/ControlCommand "{header: auto, command_id: 0, source: 0, Mode: 0, position: [0,0,2]}" --once

这条命令的含义是让无人机以位置控制模式飞到当前位置上方两米的高度。执行后观察终端输出，如果是[INFO] Control command received，并且Gazebo里的无人机缓慢上升，说明底层链路完全正常。

另外一个很实用的操作是在终端里用键盘控制飞机，官方在prometheus_control包里提供了键盘控制节点keyboard_control，起一个终端节点后就能用键盘控制飞机前后左右上下飞行。调试PID参数时这个功能极其顺手。

5. 跑通后的自检清单与下一步玩法

5.1 什么才算“真正跑通”

很多人以为Gazebo里飞机出现了就算跑通，其实还差得远。我总结了一份自检清单，按顺序逐项打勾，全部通过才说明系统真正常了。

• 机器人在Gazebo中创建成功，模型没有穿模或抖动。
• 执行rostopic echo /mavros/state，看到connected: True。
• 通过QGC或命令行能够成功解锁（Arm）。
• 发送位置控制命令后，无人机能够起飞并稳定悬停。
• 切换任务模式后，无人机能够按预期执行航线任务。
• 关闭仿真环境时，所有ROS节点正常退出，无大量报错。

如果哪一项过不了，先回到对应的层级去查。飞机不动先查控制指令是否发出；控制指令发了飞机乱飞先查消息频率和坐标系定义；消息正常但飞机起飞后漂移严重，基本就是模型参数或者固件问题。

5.2 常见报错速查表

结合我自己和群里朋友的经验，我把出现频率最高的几个报错整理成了速查表，方便遇到问题时快速定位：

这里特别提一下遥控器失效保护，这个问题在纯仿真环境里极其坑人。因为仿真环境中没有连接真实的RC遥控器，PX4默认状态是“无遥控器输入”，如果你在解锁之前没有把遥控器保护关掉，飞机即使解锁了也会在起飞瞬间触发Failsafe，表现就是电机转了一下立刻停。解决办法是在QGC的参数设置里把COM_RC_IN_MODE改为“无遥控器”模式。

5.3 从单机仿真到复杂任务的进阶路线

单机跑通只是起点，Prometheus真正的价值在于它帮你把底层的活都干完了，你可以直接在上面做更复杂的事情。

我最推荐进阶方向是从目标检测开始做起。Prometheus内置了目标检测模块，支持对特定颜色物体的识别和跟踪。启动带camera的仿真环境后，再启动目标检测节点，无人机就能锁定视野中的目标并自动跟随，这个过程不需要你了解任何PX4底层细节，但需要对ROS话题通信和图像处理有基本概念。

另一个方向是集群仿真。Prometheus的集群模式支持多机协同控制，可以在Gazebo中同时创建多架无人机，验证编队算法。这个方向最考验机器性能，建议内存不低于32GB，否则同时跑三架飞机的仿真就会卡成PPT。

5.4 最后分享一个我的查错习惯

跑通这套环境之后，日常开发中还是免不了要和各种报错打交道。我自己养成的一个习惯是，遇到问题先看~/.ros/log目录下的日志文件，而不是只看终端输出。终端输出会因为滚动而丢失大量早期日志，而ROS的日志文件按时间和topic分类保存，信息更完整。

另一个习惯是善用rqt_graph这个可视化工具。启动仿真后开一个终端执行rqt_graph，能看到当前所有ROS节点的通信关系图。哪个节点之间没有连线，或者连线显示异常，问题基本就能定位到七七八八了。

还有一个很实用的小技巧：当你改了代码重新编译时，如果发现改动没生效，先检查是不是编译到了错误的工作空间。echo $ROS_PACKAGE_PATH可以查看当前生效的包路径，如果和你的工作空间不一致，说明source的文件有问题，或者有多个工作空间叠加导致旧版本覆盖了新版本。

折腾这套环境确实会让人觉得繁琐，尤其是第一次编译时看着满屏的告警信息，很容易产生“是不是哪里装错了”的错觉。但只要你熬过编译和仿真启动这两关，后面的开发体验会非常顺畅。毕竟，能在一晚上从零跑通一个带视觉感知和控制闭环的无人机仿真系统，而且开源免费，这套平台的价值就已经值回票价了。