PX4-Simulink联合环境配置与跨系统编译排雷记录

最近升级了控制器，从老的Pixhawk 2.4.8换到了Pixhawk6c控制器，所以重新配置了Simulink测试实验环境，用了新的MATLAB2025A版本，PX4版本用的1.14.3。但是遇到了以下很多的问题，大都是这套环境自身的坑（毕竟开发维护人员少之又少），特此记录如下，希望能帮到别人：

在日常的控制算法研究与台架验证中，利用 MATLAB/Simulink 结合 PX4 硬件支持包（UAV Toolbox Support Package for PX4 Autopilots）进行代码自动生成与硬件在环（Connected I/O）测试，是极大地提升开发效率的手段。

然而，在 Windows 11 + WSL2 (Ubuntu 22.04) + MATLAB 2025A 的架构下配置 Pixhawk 6C 的联合开发环境时，跨文件系统与工具链缓存往往会引发一些极为顽固的编译错误。本文详细记录了在此次环境搭建中遇到的核心难题及最终的“降维打击”解决方案。

踩坑一：PX4 Firmware build not done 错误与跨系统句柄警告

在尝试使用 Simulink 编译处于 WSL 网络路径下的 PX4 源码时，通常会遇到第一个警告，紧接着编译彻底失败：

警告: 无法获得 \\wsl.localhost\ubuntu-22.04\home\...\PX4-Autopilot\build\px4_fmu-v6c_default 的更改通知句柄。 错误：PX4 Firmware build not done for the selected cmake config, perform setup screens

现象描述： 在 MATLAB 的 Hardware Setup 中可以正常走完验证，在 WSL 终端中敲 make 也可以正常编译出固件，但一旦回到 Simulink 程序中点击编译或部署，就会直接报上述错误，导致全部功能受阻。

问题根源与排雷： 很多时候我们会以为是 \\wsl.localhost 的跨文件系统监控权限问题，试图通过**映射网络驱动器（如映射为 Z: 盘）**来解决。但实际上改映射驱动器根本没用！ 这个错误的最根本原因在于：WSL 中的 PX4 交叉编译工具链（Toolchain）版本过旧或缺失。 导致 Simulink 底层的脚本在第一步检查固件环境时，无法与当前的 CMake 配置正确匹配。

解决方案： 必须在 WSL 环境中彻底更新 PX4 的 Toolchain（例如安装较新的 gcc-arm-none-eabi）。只要系统底层的编译器版本满足当前 PX4 固件（如 v6c）的 CMake 要求，Simulink 才能顺利识别固件。

踩坑二：CMD不支持UNC路径的致命拦截

在部署编译时，Windows 底层调用命令行往往会直接报错并中断：

用作为当前目录的以上路径启动了 CMD.EXE。 UNC 路径不受支持。默认值设为 Windows 目录。

问题根源： MATLAB 底层使用 Windows 的 cmd.exe 执行编译脚本，但 CMD 原生不支持在网络共享路径（即 \\wsl.localhost\... 这样的 UNC 路径）下执行命令。一旦遇到，会自动掉线回退到 C:\Windows 目录，导致后续的所有 CMake 和 Make 命令彻底迷失方向。

解决方案：修改注册表 为 CMD 强行开启 UNC 路径支持：

1. 打开 Windows 注册表编辑器，定位到 HKEY_CURRENT_USER\Software\Microsoft\Command Processor。
2. （如果没有 Command Processor 项，则右键新建该项）。
3. 在其中新建一个 DWORD (32位) 值，命名为 DisableUNCCheck。
4. 将其数值数据设置为 1（十六进制），保存后即可解决。

(参考来源：CSDN博主 lisayh 的文章 / CC 4.0 BY-SA版权)

踩坑三：极其顽固的 GCC Toolchain 路径缓存 Bug（核心难点）

在清理完上述网络路径问题，并成功更新了 WSL 内部的交叉编译工具链（换用了新版的 arm-none-eabi-gcc 10.3.1，真实路径位于 /usr/bin）后，Simulink 依然会报出极其离谱的版本路径错误：

Compilation failure for command /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-g++ ... bash: line 1: /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-g++: No such file or directory 后面跟一大堆。。。核心错误点就是上述内容。

问题根源： 我在 WSL 终端里自己敲 make 都能成功调用新编译器，但 MATLAB 只要一介入，就非要去抓 /opt/ 下的旧版编译器。 这是因为 MATLAB/Simulink 的 PX4 支持包底层配置缓存极其顽固。哪怕通过 Toolbox 的设置重新走向导、删除 slbuild 缓存、甚至是 make clean 清理源码目录，MATLAB 生成的底层 CMake 配置文件依然会“死记硬背”着第一次安装时的旧工具链路径。

终极解决方案：软链接“降维打击”

既然 MATLAB 内部的代码生成器是个“老顽固”，死活揪着旧路径不放，最高效的解决逻辑是：不与 MATLAB 的缓存较劲，直接在 Linux 系统层面给它造一个“替身”。

利用 Linux 的软链接（Symbolic Link）功能，我们在 /opt/ 下创建一个与旧路径完全一致的空壳目录，并将内部指令重定向到系统真实的新版编译器上。

打开 WSL 终端，直接执行以下脚本代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#!/bin/bash
# fix_px4_compiler.sh

# 1. 创建 MATLAB 死活要找的那个旧目录
sudo mkdir -p /opt/gcc-arm-none-eabi-9-2020-q2-update/bin

# 2. 把真实的新编译器(即你当前生效的 /usr/bin 下的编译器)链接过去
sudo ln -sf /usr/bin/arm-none-eabi-g++ /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/
sudo ln -sf /usr/bin/arm-none-eabi-gcc /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/

# 3. 顺便把其他工具链核心工具（链接器、汇编器等）也一并链接过去
for tool in ar as ld objcopy objdump strip nm ranlib readelf size strings; do
    if [ -f "/usr/bin/arm-none-eabi-$tool" ]; then
        sudo ln -sf "/usr/bin/arm-none-eabi-$tool" /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/
    fi
done

# 4. 验证符号链接是否生效
echo "验证编译器版本："
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-g++ --version

(参考来源：CSDN博主 hahaha12139 的文章 / CC 4.0 BY-SA版权)