Ubuntu搭建PX4无人机仿真环境(5) —— 仿真环境搭建(以Ubuntu 22.04,ROS2 Humble,Micro XRCE-DDS Agent为例)

Ubuntu搭建PX4无人机仿真环境(5) —— 仿真环境搭建(以Ubuntu 22.04,ROS2 Humble,Micro XRCE-DDS Agent为例)

目录

前言

本教程基于 ROS2 ,在搭建之前,需要把 ROS2、QGC 等基础环境安装配置完成。但是这块的资料相比较于 ROS1 下的少很多,不利于快速上手和后期开发,小白慎选!

小白必看:👇👇👇👇👇👇👇
本次安装是以 px4 v1.14.0 为例,不适用之前的 px4 版本。
我的配置如下:
虚拟机 Ubuntu 22.04 (运行内存 4G、硬盘内存 80G) 、ROS2 HumbleQGC禁止无脑复制:首先大部分命令都有先后顺序,就是要上一个命令执行成下一个才能执行成功,对于不熟悉的命令可以直接复制问AI 这样还能顺带学习学习;其次在有些情况下多个命令一起执行会出现奇怪的错误,而且有些命令旁边有注释,有时候复制上去可能也会出现错误。建议使用虚拟机:虽然虚拟机得性能有限,但是对于新手入门阶段是完全够用了,后续大型仿真再用双系统也比较熟悉了。而且虚拟机有一个快照功能,可以保存当前虚拟机的状态 (相当于存档),这样如果后面出了问题要重新搭建环境,可以用快照回到上一个状态,这样就不用重头开始(我一般是安装好 ROS 拍一个、安装好 mavros 拍一个…)。关于网络:由于一些懂得都得的原因,再加上每个人的网络环境不同,我们下载 GitHub上的资源、安装 Python 包、apt 安装包等会时快时慢,所以大家会换源,比如一开始的换 apt 软件安装源等。但是下载资源一定要耐心,如果是网络问题,可以尝试多执行几次命令,而且有些我也给了相应的解决方案。

基于 ROS2 的 PX4 仿真环境搭建系列: 👇👇👇
建议安装之前可以先看看这个 👉 ubuntu搭建PX4无人机仿真环境(1) —— 概念介绍

Ubuntu安装ROS(2) —— 安装ROS2 humble(最新、超详细图文教程,包含配置rosdep)-ZEEKLOG博客

ubuntu搭建PX4无人机仿真环境(1) —— 概念介绍_Tfly__的博客-ZEEKLOG博客

ubuntu搭建PX4无人机仿真环境(3) —— ubuntu安装QGC地面站_Tfly__的博客-ZEEKLOG博客

ROS1 请看 👇👇👇

ubuntu搭建PX4无人机仿真环境(4) —— 仿真环境搭建、基于ROS1-ZEEKLOG博客

如果想要自己编译 PX4 固件可以看 Ubuntu编译PX4固件 这篇教程

1. 准备

1.1 下载 PX4 源码

方式一:

从 Github 上下载,但是比较考验个人网速

sudoaptinstallgit

下载并切换版本:

git clone https://github.com/PX4/PX4-Autopilot.git # 下载源码mv PX4-Autopilot PX4_Firmware # 更改目录名cd PX4_Firmware git checkout v1.14.0 # 切换版本

更新子模块:

git submodule update --init --recursive # 更新下载子模块

方式二:

从提供的网盘里下载,或者从QQ群(961297255)里下载

链接: https://pan.baidu.com/s/1MJWtK8XkLsdzvJKrpCMz6Q
提取码: rbrk

下载后解压,然后执行下面命令:

cd PX4_Firmware wget https://gitee.com/tyx6/mytools/raw/main/px4/set_executable.sh chmod +x set_executable.sh ./set_executable.sh 

1.2 安装仿真依赖

sudoaptinstall ros-dev-tools cd ~/PX4_Firmware/Tools/setup 
修改文件并备份 (就把 pip 安装源换成了清华源),这一步是可做可不做,如果觉得python 包下载太慢了,可以试试
chmod +x ubuntu.sh ./ubuntu.sh --no-nuttx --no-sim-tools # 这是官方提供的脚本 有两个可选参数# --no-sim-tools 不安装仿真环境# --no-nuttx 不安装交叉编译环境#(如果需要自己编译飞控固件,烧录到飞控中,那就需要交叉编译环境)# 脚本执行时间,跟个人网络有关,可能需要一段时间

安装完成后,重启 Ubuntu

1.3 安装 Gazebo

Gazebo是一款强大的3D仿真软件,主要用于机器人学的研究和开发。它提供了高度逼真的物理模拟环境,包括动力学、碰撞检测、传感器模型以及与真实世界相似的物理属性如重力、摩擦力等。Gazebo可以模拟各种类型的机器人,从移动机器人、无人机到机械臂,甚至可以模拟整个城市环境。

在这里插入图片描述


根据上图说明,Gazebo 官方做了更新将之前的 Gazebo Ignition 命名为 Gazebo,以前的 Gazebo 现在叫 Gazebo Classic ,而 Ubuntu 22.04 及以后的版本就支持 Gazebo (Gazebo Ignition) 。
因为几年前官方对 Gazebo 进行了重大架构变更,然后将变更后的版本叫 Gazebo Ignition,旧的仍叫 Gazebo。后面Gazebo Ignition 逐渐成熟并经过使用验证,所以他结束了旧的 Gazebo ( Gazebo 11 是 Gazebo Classic 的最后一个版本,支持到 2025 年 ),并重新对它们命了名。而且两个应该不能共存,安装一个会卸载另一个。

cd ~/PX4_Firmware/Tools/setup ./ubuntu.sh --no-nuttx # 这一步会安装仿真环境依赖,包括 gazebo# 脚本执行时间,跟个人网络有关

再运行一下 gazebo

gz sim 
在这里插入图片描述

成功后再重启 Ubuntu

2. 安装 Micro XRCE-DDS Agent

在这里插入图片描述

在 ROS2 中 PX4 使用 uXRCE-DDS 中间件来允许在配套计算机上发布和订阅 uORB 消息,就像它们是 ROS2 话题一样。这提供了 PX4 和 ROS2 之间快速可靠的集成,并使 ROS2 应用程序更容易获取车辆信息和发送命令,如上图所示。(来自官方文档说明)

这应该跟 ROS2 将中间件改为 DDS 有关,但是官方又说明了在 ROS2 中仍可以使用 MAVROS ,可能官方觉得在 ROS2 中 Micro XRCE-DDS Agent 更好用 😂,也可能是因为 MAVLink 是外部通信协议,uORB 是内部通信协议。

注:如果想用 Mavros 请参考这篇文章 👉 ubuntu搭建PX4无人机仿真环境(2) —— MAVROS安装(适用于ROS1、ROS2)-ZEEKLOG博客
使用方法跟 ROS1 类似,这里不做描述。

Micro XRCE-DDS Agent 与 MAVROS 的对比(来自豆包AI,仅供参考)
MAVROS 是 ROS(机器人操作系统)生态中连接 MAVLink 协议设备(如 PX4、ArduPilot 飞控)的主流工具,本质是 ROS 与 MAVLink 的桥梁。二者的核心差异体现在如下方面:

维度Micro XRCE-DDS AgentMAVROS
核心定位资源受限设备与 DDS 分布式网络的通信代理,支持多设备协同ROS 与 MAVLink 设备(如飞控)的通信桥梁,专注无人机控制
生态兼容性兼容 DDS 生态(如 Fast DDS、Cyclone DDS),可与非 ROS 系统集成强依赖 ROS 生态,仅支持 ROS 节点与 MAVLink 设备交互
资源占用客户端(Client)极轻量(适合 MCU 等嵌入式设备),Agent 本身资源消耗中等依赖 ROS 节点和进程,资源占用较高(不适合极简嵌入式环境)
灵活性支持自定义数据类型,可灵活扩展消息结构,适应复杂分布式场景消息类型固定为 MAVLink 标准消息,扩展需修改协议或自定义消息
实时性原生支持实时性配置(通过 DDS QoS),适合低延迟场景实时性依赖 ROS 调度,默认配置下实时性中等
适用场景无人机集群协同、多传感器分布式融合、跨平台设备互联单无人机与 ROS 系统的通信(如地面站控制、数据日志、任务规划)
优点1. 分布式架构,支持多设备协同; 2. 轻量级客户端适合嵌入式; 3. 可自定义消息,灵活性高; 4. 强实时性与 QoS 保障1. 无缝集成 ROS 生态,开发便捷; 2. 成熟稳定,支持 MAVLink 全功能(控制、参数、日志等); 3. 社区活跃,问题易解决
缺点1. 学习成本高(需理解 DDS 概念),目前资料相比于mavros少很多; 2. 与 ROS 集成需额外适配; 3. 对单设备简单通信场景略显复杂1. 依赖 ROS,非 ROS 环境下使用不便,但非ROS环境也有其他基于mavlink的库可以使用; 2. 分布式多设备协同能力弱; 3. 资源占用较高,不适合极简嵌入式
  • 下载源码:
git clone -b v2.4.2 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git 
  • 编译:
cd Micro-XRCE-DDS-Agent mkdir build cd build cmake ..make# make 的时候还会额外下载代码,跟个人网速有有关,大概要10-20分钟
在这里插入图片描述


如果出现如下图错误:

在这里插入图片描述


build 目录下执行下面命令,改完后再重新 make:

sed -i 's/checkout 2\.12\.x --/checkout v2.12.1 --/' ./fastdds/tmp/fastdds-gitclone.cmake 

也可以用文本编辑器打开fastdds-gitclone.cmake 文件,将 2.12.x 改为 v2.12.1 就行。

  • 安装:
sudomakeinstallsudo ldconfig /usr/local/lib/ # 更新动态链接器的缓存
在这里插入图片描述

3. 编译 PX4

cd ~/PX4_Firmware make px4_sitl gz_x500 # 这步可能有点慢

出现这个表示编译成功 😄

在这里插入图片描述


错误 1️⃣:如果在虚拟机中可能遇到下面错误,这是由于在虚拟机设置中开启了 3D 图形加速,导致系统的 OpenGL 版本降低。

在这里插入图片描述

参考这个 Issue 中的解决方法,降低仿真使用的渲染引擎的版本

打开文件,修改处大概在 73 行:

gedit ~/PX4_Firmware/ROMFS/px4fmu_common/init.d-posix/px4-rc.simulator 

修改前:

if[ -z "${HEADLESS}"];then# HEADLESS not set, starting gui${gz_command}${gz_sub_command} -g &fi

修改后:

if[ -z "${HEADLESS}"];then# HEADLESS not set, starting gui${gz_command}${gz_sub_command} -g --render-engine ogre &fi

错误 2️⃣:如果编译过程中出现类似下面错误,应该是 gz_bridge 启动超时

INFO [gz_bridge] world: default, model name: x500_0, simulation model: x500 ERROR [gz_bridge] Service call timed out ERROR [gz_bridge] Task start failed (-1) ERROR [init] gz_bridge failed to start ERROR [px4] Startup script returned with return value: 256

参考下面链接中给出的解决方法 👇
make px4_sitl gz_x500出错 - 哔哩哔哩

然后,再重新编译

4. 通信测试

打开一个终端,启动 MicroXRCEAgent:

MicroXRCEAgent udp4 -p 8888

打开另一个终端,启动仿真:

cd ~/PX4_Firmware make px4_sitl gz_x500 

都启动后,可以看到通信成功

在这里插入图片描述

5. 官方 offboard 程序

  • 创建工作空间:
mkdir -p ~/ros2_ws/src 
  • 下载源码:
cd ~/ros2_ws/src # 1.14git clone https://github.com/PX4/px4_msgs.git -b release/1.14 git clone https://github.com/PX4/px4_ros_com.git -b release/v1.14 # 1.15# git clone https://github.com/PX4/px4_msgs.git -b release/1.15# git clone https://github.com/PX4/px4_ros_com.git -b release/1.15
  • 编译:
cd ~/ros2_ws colcon build 
在这里插入图片描述
  • 更新环境:
echo"source ~/ros2_ws/install/setup.bash">> ~/.bashrc source ~/.bashrc #使环境生效

6. offboard 测试

先启动 QGC,然后执行下面命令

  • 终端一,启动 MicroXRCEAgent:
MicroXRCEAgent udp4 -p 8888
  • 终端二,启动仿真:
cd ~/PX4_Firmware make px4_sitl gz_x500 
  • 终端三,启动官方 offboard 案例(上升5米):
ros2 run px4_ros_com offboard_control 
在这里插入图片描述
注:如果过了一段时间,无人机无法 offboard 起飞,程序都正常启动,这时可以尝试下面命令

然后重新编译

编译成功后,记得 source 一下,再重新offboard测试

到这 PX4 无人机基本仿真环境就搭建完成了,大家可以基于此来拓展自己的仿真。
建了个交流群QQ群(961297255),方便大家交流学习,但是关于 ROS2 下的 PX4 仿真资料不多
😁

参考

ROS 2 用户指南 | PX4 Guide (main)
PX4 ROS 2 User Guide v1.14
PX4 documentation
uXRCE-DDS
Ubuntu Development Environment
a-new-era-for-gazebo

如有其他问题,或者发现文章有错误,请在评论区留言
Keep learning!

Read more

Stable Diffusion WebUI Forge:AI绘画风格转换完全指南

Stable Diffusion WebUI Forge:AI绘画风格转换完全指南 【免费下载链接】stable-diffusion-webui-forge 项目地址: https://gitcode.com/GitHub_Trending/st/stable-diffusion-webui-forge 想要将普通照片一键转换为梵高的星空笔触或赛博朋克的霓虹美学吗?Stable Diffusion WebUI Forge作为专业的AI绘画工具,通过其强大的风格转换功能,让创意工作者能够轻松实现数字绘画创作和智能风格迁移。本指南将带你掌握从基础操作到高级技巧的全流程。 理解AI绘画风格转换的核心原理 Forge的风格转换能力基于深度学习的神经网络架构,通过分析艺术风格的特征模式,智能地将这些特征应用到你的原始图像上。整个过程无需专业绘画技能,只需简单配置即可获得惊艳的艺术效果。 快速入门:3步完成风格转换 准备工作区与素材 首先打开Forge的画布系统,这是风格转换的核心操作界面: 1. 上传基础图像:点击工具栏的📂按钮上传需要转换的图片 2. 调整画布参数

我用Openclaw + Claude搭了一套自动写作系统,每天省3小时

这是我目前最重要的一套AI工作流。从信息获取到发布,几乎不用手动完成。 一、为什么我要搭建这套系统? 信息过载的困境 如果你也在持续关注AI,应该会有同样的感受: 信息太多了。 每天打开 X、公众号、GitHub、技术社区,都会冒出大量新内容。 AI模型更新、工具更新、Agent框架、自动化方案…… 想跟上这些信息,本身就已经是一项工作。 手动写作的低效循环 更别说: * 整理信息 * 找选题 * 写文章 * 配图 * 发布到各个平台 如果全部手动完成,写作就会变成一件非常消耗精力的事。 我一度也在这种状态里: 想持续输出,但写作本身占用了太多时间。 一个关键问题 后来我开始思考一个问题: 如果写作这件事可以被"系统化",会发生什么? 于是,我不再把AI当成写作工具。 而是开始搭一套完整的 AI写作工作流。 二、思路转变:从优化写作到优化流程 大多数人的AI写作方式 大多数人使用AI写作,是这样:

熟练使用 GitHub Copilot、Cursor、JetBrains AI Assistant 的实战指南

熟练使用 GitHub Copilot、Cursor、JetBrains AI Assistant 的实战指南

这三款工具都是当前最强的 AI 编程助手,能显著提升你的开发效率。掌握它们后,你可以让 AI 处理繁琐的基础工作,专注于核心业务逻辑。以下是针对你提出的 4 个核心需求 的详细操作指南,包含 具体步骤、最佳实践和注意事项。 一、让 AI 为你生成单元测试和边界测试用例 为什么需要边界测试? * 单元测试只覆盖正常场景,边界测试(如 null、极值、异常输入)能暴露隐藏 Bug。 * AI 容易遗漏边界情况,必须明确要求才会生成。 📌 操作步骤(分工具说明) 1. GitHub Copilot(适用于 VS Code、JetBrains IDE 等) 适用场景:在代码编写时实时生成测试用例。 步骤: 1. 编写被测函数(例如一个计算器函数): def

超越代码生成器:深度解析Triton-Copilot的人机协同设计哲学

超越代码生成器:深度解析Triton-Copilot的人机协同设计哲学 最近和几位负责底层性能优化的同事聊天,大家普遍有个共鸣:现在做高性能算子开发,感觉像是在走钢丝。一边是模型复杂度指数级增长带来的性能压力,另一边是手写CUDA或Triton代码那令人望而生畏的学习曲线和调试成本。资深专家忙得脚不沾地,而应用层开发者面对性能瓶颈往往束手无策,只能干等着排期。这种“专家依赖症”已经成为AI工程化落地的一个典型瓶颈。 正是在这种背景下,我第一次接触到Triton-Copilot。起初我以为它不过是又一个“智能代码补全”工具,但深入使用和剖析其架构后,我发现它的野心远不止于此。它不像ChatGPT那样,你问一句“写个矩阵乘法的Triton代码”,它给你一段可能能跑、但性能和正确性都无法保证的文本。Triton-Copilot构建的,是一套完整的、以验证和协作为核心的软件开发新范式。它试图回答一个根本性问题:如何将人类专家的领域知识(比如对硬件内存层次的理解、对数值稳定性的把握)与AI的代码生成和探索能力系统性地结合起来,而不仅仅是让AI“模仿”人类写代码? 这篇文章,我想从一个系统设