从阿木实验室的Prometheus项目一发布就有不少朋友私信问我同一个问题这个Prometheus到底是不是那个监控告警用的Prometheus怎么下载下来的代码跟想象中完全不一样其实我刚接触的时候也犯过同样的糊涂。今天这篇就把阿木实验室Prometheus开源项目的下载、编译和仿真跑通从头到尾捋一遍重点记录那些新手最容易栽进去的坑以及我是怎么一步步爬出来的。先说清楚本文聊的是阿木实验室AMOVLAB开源的无人机集群开发平台Prometheus这是一套基于PX4和ROS的无人机二次开发项目包含Gazebo仿真、目标检测、集群控制等模块。不是那套用Golang写的监控系统Prometheus。虽然名字一模一样但两个项目八竿子打不着搜索的时候务必加上“阿木实验室”或者“无人机”做限定词。1. 先把名字拆清楚此Prometheus非彼Prometheus1.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可以直接pullzip就得重新下载覆盖。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 常见报错速查表结合我自己和群里朋友的经验我把出现频率最高的几个报错整理成了速查表方便遇到问题时快速定位现象可能原因解决办法Gazebo启动后没有无人机模型路径未正确设置检查PROMETHEUS_ROOT环境变量确保指向项目根目录MAVROS一直显示waiting for heartbeat与PX4 SITL通信未建立检查px4.launch中的fcu_url参数确认UDP端口号匹配飞机解锁后立即显示Failsafe activated遥控器信号丢失保护触发在QGC中关闭遥控器失效保护或设置虚拟遥控器无人机起飞后不断上升无法控制高度传感器数据异常检查Gazebo中是否加载了正确的测距传感器模型编译时报Glog相关错误glog版本冲突重装libgoogle-glog-dev并清理编译缓存目标检测节点启动即崩溃CUDA或opencv版本不匹配确认opencv编译时启用了CUDA支持或改用CPU推理版本这里特别提一下遥控器失效保护这个问题在纯仿真环境里极其坑人。因为仿真环境中没有连接真实的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的文件有问题或者有多个工作空间叠加导致旧版本覆盖了新版本。折腾这套环境确实会让人觉得繁琐尤其是第一次编译时看着满屏的告警信息很容易产生“是不是哪里装错了”的错觉。但只要你熬过编译和仿真启动这两关后面的开发体验会非常顺畅。毕竟能在一晚上从零跑通一个带视觉感知和控制闭环的无人机仿真系统而且开源免费这套平台的价值就已经值回票价了。
从阿木实验室的Prometheus项目一发布就有不少朋友私信问我同一个问题这个Prometheus到底是不是那个监控告警用的Prometheus怎么下载下来的代码跟想象中完全不一样其实我刚接触的时候也犯过同样的糊涂。今天这篇就把阿木实验室Prometheus开源项目的下载、编译和仿真跑通从头到尾捋一遍重点记录那些新手最容易栽进去的坑以及我是怎么一步步爬出来的。先说清楚本文聊的是阿木实验室AMOVLAB开源的无人机集群开发平台Prometheus这是一套基于PX4和ROS的无人机二次开发项目包含Gazebo仿真、目标检测、集群控制等模块。不是那套用Golang写的监控系统Prometheus。虽然名字一模一样但两个项目八竿子打不着搜索的时候务必加上“阿木实验室”或者“无人机”做限定词。1. 先把名字拆清楚此Prometheus非彼Prometheus1.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可以直接pullzip就得重新下载覆盖。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 常见报错速查表结合我自己和群里朋友的经验我把出现频率最高的几个报错整理成了速查表方便遇到问题时快速定位现象可能原因解决办法Gazebo启动后没有无人机模型路径未正确设置检查PROMETHEUS_ROOT环境变量确保指向项目根目录MAVROS一直显示waiting for heartbeat与PX4 SITL通信未建立检查px4.launch中的fcu_url参数确认UDP端口号匹配飞机解锁后立即显示Failsafe activated遥控器信号丢失保护触发在QGC中关闭遥控器失效保护或设置虚拟遥控器无人机起飞后不断上升无法控制高度传感器数据异常检查Gazebo中是否加载了正确的测距传感器模型编译时报Glog相关错误glog版本冲突重装libgoogle-glog-dev并清理编译缓存目标检测节点启动即崩溃CUDA或opencv版本不匹配确认opencv编译时启用了CUDA支持或改用CPU推理版本这里特别提一下遥控器失效保护这个问题在纯仿真环境里极其坑人。因为仿真环境中没有连接真实的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的文件有问题或者有多个工作空间叠加导致旧版本覆盖了新版本。折腾这套环境确实会让人觉得繁琐尤其是第一次编译时看着满屏的告警信息很容易产生“是不是哪里装错了”的错觉。但只要你熬过编译和仿真启动这两关后面的开发体验会非常顺畅。毕竟能在一晚上从零跑通一个带视觉感知和控制闭环的无人机仿真系统而且开源免费这套平台的价值就已经值回票价了。
