这次在 Jetson Orin NX 上同时连接普通设备和 Livox Mid-360S 时，连续遇到了两个问题：

1. 主板有两个物理网口，但系统只能看到一个网口。
2. 第二个网口修好后，两个网口仍然只能连接一个，连接第二个时第一个会断开。

最后确认并不是 Jetson 的两个网口硬件互斥，而是第二个 Realtek 网卡缺少驱动，同时两个网口错误地共用了同一个 NetworkManager 配置。由于两个网口还在同一个 192.168.1.0/24 网段，又产生了路由冲突。

本文先给出可以直接使用的一键脚本，再解释问题原因和手动排查方法。

适用边界：下面的脚本是针对本文记录的 Jetson Orin NX、Realtek RTL8125/RTL8168 网卡和同网段地址规划验证的。其他载板、内核版本、网卡芯片或 IP 规划需要先修改配置并核对驱动，不应直接照搬。

一、当前设备配置

这台 Jetson 的网络规划如下：

实际网卡控制器：

1
2

enP7p1s0 -> Realtek RTL8125      -> r8125
enP8p1s0 -> Realtek RTL8111/8168 -> r8168

执行脚本会重新连接两个有线网口。如果当前 SSH 正通过其中一个有线口连接，脚本会停止。建议通过 Wi-Fi、显示器或串口执行。

二、一键解决脚本

在 Jetson 上创建脚本：

1

nano ~/enable_jetson_dual_eth.sh

复制下面的全部内容。如果自己的网口名或 IP 不同，只修改最上方的“需要修改的配置”部分。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156

#!/usr/bin/env bash
set -Eeuo pipefail

# ============================================================
# 需要修改的配置
# ============================================================

# 普通设备网口
GENERAL_IF="enP7p1s0"
GENERAL_IP="192.168.1.123/24"
GENERAL_PROFILE="device-enP7"

# Mid-360S 专用网口
LIDAR_IF="enP8p1s0"
LIDAR_HOST_IP="192.168.1.102/24"
LIDAR_PROFILE="102"
LIDAR_IP="192.168.1.199"

# ============================================================

if [[ $EUID -ne 0 ]]; then
  echo "请使用 sudo 运行：sudo bash $0"
  exit 1
fi

for command_name in lspci ip nmcli awk grep modprobe; do
  if ! command -v "$command_name" >/dev/null 2>&1; then
    echo "缺少命令：$command_name"
    exit 1
  fi
done

if [[ "$GENERAL_IF" == "$LIDAR_IF" ]]; then
  echo "两个用途不能配置到同一个网口"
  exit 1
fi

echo "普通设备网口：$GENERAL_IF -> $GENERAL_IP"
echo "雷达专用网口：$LIDAR_IF -> $LIDAR_HOST_IP"
echo "Mid-360S：$LIDAR_IP"

# 当前 SSH 如果正经过目标有线口，直接重连可能导致脚本执行一半时断线。
if [[ -n "${SSH_CONNECTION:-}" ]]; then
  SSH_CLIENT_IP="${SSH_CONNECTION%% *}"
  SSH_ROUTE="$(ip -4 route get "$SSH_CLIENT_IP" 2>/dev/null | head -n 1 || true)"
  if [[ "$SSH_ROUTE" == *" dev $GENERAL_IF "* || "$SSH_ROUTE" == *" dev $LIDAR_IF "* ]]; then
    echo "当前 SSH 正通过待重配网口连接：$SSH_ROUTE"
    echo "请改用 Wi-Fi、显示器或串口后重新运行"
    exit 1
  fi
fi

echo "[1/5] 检查 RTL8168 驱动"

RTL8168_INFO="$(lspci -nnk -d 10ec:8168 2>/dev/null || true)"
if [[ -n "$RTL8168_INFO" ]] && ! grep -q "Kernel driver in use:" <<<"$RTL8168_INFO"; then
  echo "发现 RTL8168，但没有驱动，开始安装 r8168-dkms"

  if [[ ! -e "/lib/modules/$(uname -r)/build" ]]; then
    echo "缺少与 $(uname -r) 匹配的 Jetson 内核头文件"
    echo "请先安装当前 L4T 对应的 nvidia-l4t-kernel-headers"
    exit 1
  fi

  apt-get update
  env DEBIAN_FRONTEND=noninteractive apt-get install -y r8168-dkms
  modprobe r8168
  udevadm settle || true
else
  echo "RTL8168 已经有驱动，跳过安装"
fi

for interface_name in "$GENERAL_IF" "$LIDAR_IF"; do
  if [[ ! -d "/sys/class/net/$interface_name" ]]; then
    echo "找不到网口：$interface_name"
    echo "当前网口如下，请修改脚本顶部的网口名："
    ip -br link
    exit 1
  fi
done

echo "[2/5] 备份 NetworkManager 配置"

BACKUP_DIR="/var/backups/jetson-dual-ethernet/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"
if [[ -d /etc/NetworkManager/system-connections ]]; then
  cp -a /etc/NetworkManager/system-connections "$BACKUP_DIR/"
fi
echo "配置已备份到：$BACKUP_DIR"

configure_profile() {
  local profile_name="$1"
  local interface_name="$2"
  local address="$3"
  local route_metric="$4"
  local autoconnect_priority="$5"

  if ! nmcli connection show "$profile_name" >/dev/null 2>&1; then
    nmcli connection add \
      type ethernet \
      ifname "$interface_name" \
      con-name "$profile_name"
  fi

  nmcli connection modify "$profile_name" \
    connection.interface-name "$interface_name" \
    802-3-ethernet.mac-address "" \
    connection.autoconnect yes \
    connection.autoconnect-priority "$autoconnect_priority" \
    ipv4.method manual \
    ipv4.addresses "$address" \
    ipv4.gateway "" \
    ipv4.dns "" \
    ipv4.ignore-auto-dns yes \
    ipv4.never-default yes \
    ipv4.route-metric "$route_metric" \
    ipv4.routes "" \
    ipv6.method disabled
}

echo "[3/5] 为两个网口创建独立配置"

nmcli device set "$GENERAL_IF" managed yes
nmcli device set "$LIDAR_IF" managed yes

configure_profile "$GENERAL_PROFILE" "$GENERAL_IF" "$GENERAL_IP" 100 50
configure_profile "$LIDAR_PROFILE" "$LIDAR_IF" "$LIDAR_HOST_IP" 500 100

# 两个网口处于同一 /24 网段时，强制 Mid-360S 从雷达专用口访问。
nmcli connection modify "$LIDAR_PROFILE" \
  ipv4.routes "$LIDAR_IP/32 0.0.0.0 10"

echo "[4/5] 激活两个网口"

nmcli connection reload
nmcli connection down "$GENERAL_PROFILE" >/dev/null 2>&1 || true
nmcli connection down "$LIDAR_PROFILE" >/dev/null 2>&1 || true
nmcli connection up "$GENERAL_PROFILE" ifname "$GENERAL_IF"
nmcli connection up "$LIDAR_PROFILE" ifname "$LIDAR_IF"

echo "[5/5] 验证结果"

nmcli -f DEVICE,TYPE,STATE,CONNECTION device status
ip -4 -br address show dev "$GENERAL_IF"
ip -4 -br address show dev "$LIDAR_IF"

echo "Mid-360S 实际选路："
ip -4 route get "$LIDAR_IP"

if ping -I "$LIDAR_IF" -c 3 -W 1 "$LIDAR_IP"; then
  echo "配置成功：两个网口已独立启用，Mid-360S 可以访问"
else
  echo "两个网口配置已完成，但 Mid-360S 没有响应 ping"
  echo "请检查雷达电源、网线和 LIDAR_IP"
  exit 1
fi

保存后执行：

1
2

chmod +x ~/enable_jetson_dual_eth.sh
sudo ~/enable_jetson_dual_eth.sh

脚本成功后，最后应看到：

1
2
3
4

enP7p1s0  ethernet  connected  device-enP7
enP8p1s0  ethernet  connected  102

192.168.1.199 dev enP8p1s0 src 192.168.1.102

脚本可以重复运行。每次修改前都会将 NetworkManager 配置备份到：

1

/var/backups/jetson-dual-ethernet/

三、问题一：为什么第二个网口无法打开

先查看 PCI 网卡和驱动：

1

lspci -nnk -d 10ec:

当时可以看到两个控制器：

1
2

RTL8125 2.5GbE Controller
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

第一个控制器有：

1

Kernel driver in use: r8125

第二个 RTL8168 却没有 Kernel driver in use，并且执行下面的命令只能看到一个有线网口：

1

ip -br link

这说明 PCIe 已经识别到硬件，但内核没有为第二个控制器创建网络接口。此时执行 ip link set up 或在桌面网络设置中反复点击都没有用，必须先安装驱动：

1
2

sudo apt-get install -y r8168-dkms
sudo modprobe r8168

安装后验证：

1
2
3

dkms status | grep r8168
lspci -nnk -d 10ec:8168
ethtool -i enP8p1s0

这台 Jetson 的最终结果为：

1
2
3

r8168/8.049.02, 5.15.148-tegra, aarch64: installed
Kernel driver in use: r8168
driver: r8168

四、问题二：为什么打开一个网口，另一个就断开

驱动安装完成后，两个网口的 carrier 都是 1，说明物理连接正常：

1
2
3
4

for nic in enP7p1s0 enP8p1s0; do
  printf '%s carrier=' "$nic"
  cat "/sys/class/net/$nic/carrier"
done

继续查看 NetworkManager 配置：

1
2
3
4

nmcli -f NAME,TYPE,DEVICE,AUTOCONNECT connection show
nmcli -f \
connection.id,connection.interface-name,802-3-ethernet.mac-address,ipv4.addresses \
  connection show 102

原来的 102 配置没有绑定网口：

1
2

connection.interface-name: --
802-3-ethernet.mac-address: --

NetworkManager 会把这个配置应用到任意一个兼容的有线网口。插入另一根网线时，同一个配置就在两个接口之间迁移，因此表现为“连接一个，另一个断开”。

正确做法是让每个接口拥有独立配置，并通过接口名固定：

1
2

device-enP7 -> enP7p1s0 -> 192.168.1.123/24
102         -> enP8p1s0 -> 192.168.1.102/24

脚本中的关键配置就是：

1
2

nmcli connection modify device-enP7 connection.interface-name enP7p1s0
nmcli connection modify 102 connection.interface-name enP8p1s0

五、两个网口在同一网段时的路由问题

两个有线口都使用 192.168.1.0/24，系统会产生两条相同网段的路由：

1
2

192.168.1.0/24 dev enP7p1s0 src 192.168.1.123 metric 100
192.168.1.0/24 dev enP8p1s0 src 192.168.1.102 metric 500

Linux 默认会选择 metric 更小的 enP7p1s0。这样即使 Mid-360S 接在 enP8p1s0，发往 192.168.1.199 的数据仍可能走错网口。

解决方法是添加一条更精确的 /32 路由：

1
2

sudo nmcli connection modify 102 \
  ipv4.routes "192.168.1.199/32 0.0.0.0 10"

检查实际选路：

1

ip route get 192.168.1.199

必须看到：

1

192.168.1.199 dev enP8p1s0 src 192.168.1.102

如果可以修改设备网段，更推荐让两个网口使用不同网段，例如：

1
2

普通设备网：192.168.1.0/24
雷达设备网：192.168.2.0/24

不同网段不会产生这种路由歧义。

六、Mid-360S 配置同步

网络修好后，还要把 MID360s_config.json 中的 host_ip 改成雷达专用网口地址：

1

"host_ip": "192.168.1.102"

雷达地址保持：

1

"ip": "192.168.1.199"

如果这里仍然写成另一个网口的 192.168.1.123，可能出现能够 ping 通雷达，但 ROS 驱动收不到点云的情况。

启动驱动后验证：

1

ros2 launch livox_ros_driver2 msg_MID360s_launch.py

在另一个终端检查频率：

1
2

ros2 topic hz /livox/lidar --window 20
ros2 topic hz /livox/imu --window 100

这次实际测试结果为：

1
2

/livox/lidar  约 10 Hz
/livox/imu    约 200 Hz

七、快速排查命令

以后遇到类似问题，按照下面的顺序检查即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 1. PCIe 是否识别到两个控制器，驱动是否已经绑定
lspci -nnk -d 10ec:

# 2. 内核是否创建了两个网口
ip -br link

# 3. 两个接口分别使用什么驱动
ethtool -i enP7p1s0
ethtool -i enP8p1s0

# 4. 网线是否真正连接
cat /sys/class/net/enP7p1s0/carrier
cat /sys/class/net/enP8p1s0/carrier

# 5. 两个接口是否分别连接到独立 profile
nmcli -f DEVICE,TYPE,STATE,CONNECTION device status

# 6. 查看地址和路由
ip -4 -br address
ip -4 route

# 7. 确认 Mid-360S 最终走哪个网口
ip route get 192.168.1.199

# 8. 强制从雷达口测试
ping -I enP8p1s0 192.168.1.199

八、常见问题

1. 安装 r8168-dkms 时报找不到内核头文件

检查：

1

ls -ld "/lib/modules/$(uname -r)/build"

需要安装与当前 Jetson Linux/L4T 版本匹配的 nvidia-l4t-kernel-headers。不要使用与当前 *-tegra 内核不匹配的 generic 头文件。

2. 设置 MAC 后提示没有合适的设备

运行时 MAC、克隆 MAC 和永久 MAC 可能不同：

1
2

nmcli -f GENERAL.HWADDR,GENERAL.PERM-HWADDR device show enP7p1s0
ethtool -P enP7p1s0

如果接口名稳定，直接使用 connection.interface-name 绑定即可。本文脚本会清空 profile 中的 MAC 限制，避免当前 MAC 和永久 MAC 不一致导致连接失败。

3. 两个网口都显示 connected，但雷达仍然不通

重点检查实际路由，而不是只看网口状态：

1

ip route get 192.168.1.199

如果没有走 enP8p1s0，重新添加 /32 路由并激活配置：

1
2
3

sudo nmcli connection modify 102 \
  ipv4.routes "192.168.1.199/32 0.0.0.0 10"
sudo nmcli connection up 102 ifname enP8p1s0

4. 重启后又恢复原状

检查两个 profile 是否开启自动连接并绑定正确接口：

1
2
3
4
5
6
7

nmcli -f \
connection.id,connection.interface-name,connection.autoconnect,ipv4.addresses,ipv4.routes \
  connection show device-enP7

nmcli -f \
connection.id,connection.interface-name,connection.autoconnect,ipv4.addresses,ipv4.routes \
  connection show 102

总结

本次问题由三个环节共同造成：

1
2
3
4
5
6
7
8

RTL8168 没有驱动
  -> 第二个网口没有出现在系统中

两个网口共用一个未绑定接口的 NetworkManager profile
  -> 连接一个时另一个断开

两个网口处于相同的 192.168.1.0/24 网段
  -> 发往 Mid-360S 的数据可能走错网口

对应的解决方法是：

1. 安装并加载 r8168-dkms。
2. 为两个网口创建独立 profile，并通过接口名绑定。
3. 不给设备专用网口配置默认网关。
4. 使用 /32 路由将 192.168.1.199 固定到 enP8p1s0。
5. 将 Livox 配置中的 host_ip 修改为 192.168.1.102。

完成后，两个网口可以同时连接各自设备，并在 Jetson 重启后自动恢复。

为了解决这些问题，我开发了 UAV Autonomy All-in-One。这是一个基于 ROS1 Noetic、PX4 和 Gazebo Classic 的无人机自主飞行框架，希望用同一套工程结构连接仿真与真机，并让不同规划器能够以相对独立、平等的方式接入。

项目定位

这个项目并不是新的路径规划算法，而是一个面向无人机自主飞行的工程框架。它主要关注：

• 统一仿真与真机的定位、任务、规划和控制链路；
• 隔离不同开源算法的依赖，减少相互影响；
• 使用一致的方式选择和运行不同规划器；
• 保留必要的状态检查、故障处理、日志和飞行数据；
• 为后续接入新的规划器和传感器预留清晰边界。

仿真侧由 PX4 SITL、Gazebo、模拟 MID-360、规划器和控制器组成；真机侧使用 PX4、MID-360、FAST-LIO、规划器和控制器。两套环境在底层传感器上有所不同，但上层任务和自主飞行逻辑尽量保持一致。

当前支持的规划器

main 分支目前支持四个规划器：

这些规划器分别保留自己的地图、搜索和轨迹生成方式，但通过公共框架接入任务、控制与可视化链路。不同算法在启动前选择，当前不支持飞行过程中切换或多个规划器同时控制飞机。

仿真场景

项目内置室内和森林场景。下面是 forest 测试环境：

以下演示来自项目仓库，均为原录像的 4 倍速。视频会静音循环播放，并在进入可视区域后按需加载：

项目特点

相比单独维护多个算法仓库，这个项目更关注完整系统的一致性：

• 各规划器使用隔离的构建环境，避免同名依赖相互覆盖；
• 仿真与真机复用任务执行和安全检查逻辑；
• 统一展示环境、目标、规划轨迹和实际飞行路径；
• 自动保存运行日志和 rosbag，方便回放与排查；
• 人工接管、定位异常和规划故障具有明确的处理边界。

当前边界

框架已经覆盖仿真和真机的软件链路，但“能够构建和启动”不等于已经完成真实飞行验证。真机使用前仍需要针对具体机体完成传感器外参、定位、控制器、PX4 failsafe 和遥控接管测试。

当前项目面向单机、单规划器执行，暂不提供空中切换、自动规划器回退、多规划器并行控制、地图共享或统一的动态障碍预测接口。

更详细的环境说明、使用方法、参数配置和安全注意事项请查看项目仓库：

dreamer198/UAV-Autonomy-All-in-One

本文是《Docker使用教程》的后续，默认已经按照其中的步骤创建了以下环境：

• 容器名：ros_noetic
• 基础镜像：osrf/ros:noetic-desktop-full
• 宿主机 ~/docker/ros_root 已挂载到容器 /root
• X11 目录和认证文件已经挂载，容器可以运行 RViz

这里的“全新容器”是指容器已经创建，但还没有下载 Fast-Planner，也没有安装项目依赖。本文不再重复安装 Docker、拉取 ROS 镜像或创建容器，只介绍如何在这个容器中下载、编译和测试 dreamer198/Fast-Planner。

本文默认容器内使用 root 用户，因此 ~ 就是 /root，安装命令不需要 sudo。没有特别说明时，命令都在容器内执行；需要在宿主机执行的命令会单独标出。

Fast-Planner 官方验证过 Ubuntu 20.04 + ROS Noetic。本文只运行项目自带的轻量仿真，不包含 PX4、Gazebo 或真机控制。

一、进入已经创建的容器

如果创建容器后已经停在 root@... 提示符，可以直接进入下一节。

如果容器已经退出，在宿主机执行：

1

docker start -ai ros_noetic

如果容器已经在后台运行，则执行：

1

docker exec -it ros_noetic bash

进入后确认 ROS 版本：

1
2

source /opt/ros/noetic/setup.bash
rosversion -d

输出应为：

1

noetic

二、安装编译依赖

ROS Noetic Desktop Full 已经包含 ROS 和 RViz，不需要再次安装。只补充源码编译需要的工具和库：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

apt update
apt install -y \
  git \
  build-essential \
  cmake \
  libarmadillo-dev \
  libeigen3-dev \
  libpcl-dev \
  qtbase5-dev \
  ros-noetic-cmake-modules \
  ros-noetic-cv-bridge \
  ros-noetic-dynamic-reconfigure \
  ros-noetic-image-transport \
  ros-noetic-pcl-ros

安装 NLopt 2.7.1

Fast-Planner 的 bspline_opt 会从 /usr/local/include 和 /usr/local/lib/libnlopt.so 查找 NLopt。按照项目 README 指定的 v2.7.1 编译安装：

1
2
3
4
5
6
7
8
9
10
11

mkdir -p /root/deps
cd /root/deps
git clone --branch v2.7.1 --depth 1 https://github.com/stevengj/nlopt.git

cmake -S nlopt -B nlopt/build \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_INSTALL_PREFIX=/usr/local \
  -DCMAKE_INSTALL_LIBDIR=lib
cmake --build nlopt/build -j"$(nproc)"
cmake --install nlopt/build
ldconfig

检查头文件和动态库：

1
2

test -f /usr/local/include/nlopt.hpp && echo "nlopt.hpp: OK"
test -f /usr/local/lib/libnlopt.so && echo "libnlopt.so: OK"

两行都显示 OK 后再继续。

三、下载 Fast-Planner

新建独立的 catkin 工作空间，并将代码克隆到 src 中：

1
2
3

mkdir -p /root/fast_planner_ws/src
cd /root/fast_planner_ws/src
git clone https://github.com/dreamer198/Fast-Planner.git

确认下载地址并记录当前版本：

1
2
3

cd /root/fast_planner_ws/src/Fast-Planner
git remote get-url origin
git rev-parse --short HEAD

第一条命令应输出：

1

https://github.com/dreamer198/Fast-Planner.git

记录第二条命令输出的 commit，后续遇到问题时可以确认使用的是不是同一版代码。

四、编译工作空间

1
2
3

source /opt/ros/noetic/setup.bash
cd /root/fast_planner_ws
catkin_make -DCMAKE_BUILD_TYPE=Release -j"$(nproc)"

如果容器可用内存较少，编译进程可能被系统终止。此时降低并行数重新编译：

1

catkin_make -DCMAKE_BUILD_TYPE=Release -j2

编译完成后加载工作空间，并确认 ROS 能找到核心包：

1
2

source /root/fast_planner_ws/devel/setup.bash
rospack find plan_manage

正常情况下会输出：

1

/root/fast_planner_ws/src/Fast-Planner/fast_planner/plan_manage

项目没有提供覆盖这些规划流程的自动化单元测试，因此下面通过仓库自带的仿真 Demo 完成功能测试。

五、运行 Kinodynamic 规划测试

该测试需要两个终端，它们都进入同一个 ros_noetic 容器。第一个终端运行 RViz，第二个终端运行规划器和轻量仿真器。

1. 终端 1：启动 RViz

如果 RViz 还没有图形显示权限，先在宿主机执行：

1

xhost +SI:localuser:root

然后在宿主机进入正在运行的容器：

1
2
3
4

docker exec -it \
  -e DISPLAY="$DISPLAY" \
  -e QT_X11_NO_MITSHM=1 \
  ros_noetic bash

在容器内启动 RViz：

1
2
3

source /opt/ros/noetic/setup.bash
source /root/fast_planner_ws/devel/setup.bash
roslaunch plan_manage rviz.launch

2. 终端 2：启动规划器

在宿主机新开一个终端：

1

docker exec -it ros_noetic bash

进入容器后执行：

1
2
3

source /opt/ros/noetic/setup.bash
source /root/fast_planner_ws/devel/setup.bash
roslaunch plan_manage kino_replan.launch

3. 在 RViz 中发送目标

等待 RViz 中出现随机障碍物和无人机模型，然后：

1. 确认 RViz 的 Fixed Frame 为 world。
2. 点击工具栏中的 2D Nav Goal。
3. 在地图内没有障碍物的位置点击并拖动，发送一个目标点。

当前仓库的 Kinodynamic Demo 默认使用手动目标模式。目标的 X、Y 坐标来自点击位置，飞行高度默认为 1 m。正常情况下会立即生成 B-spline 轨迹，无人机随后沿轨迹飞向目标。

六、检查测试结果

在宿主机再开一个终端并进入同一容器：

1

docker exec -it ros_noetic bash

加载环境：

1
2

source /opt/ros/noetic/setup.bash
source /root/fast_planner_ws/devel/setup.bash

先确认节点已经启动：

1

rosnode list

列表中应能看到规划器、轨迹服务器、仿真器和点云渲染等节点。再检查里程计是否持续发布：

1

rostopic hz /state_ukf/odom

看到稳定频率后按 Ctrl+C 退出，再检查仿真点云：

1

rostopic hz /pcl_render_node/cloud

点云同样应持续更新，看到频率后按 Ctrl+C 退出。接着检查规划输出：

1

rostopic echo -n 1 /planning/bspline

这条命令会等待下一条轨迹消息。保持命令运行，回到 RViz 再发送一次目标；终端打印出 B-spline 消息并自动退出，说明规划器已经生成轨迹。

在无人机执行轨迹期间，还可以检查控制指令：

1

rostopic hz /planning/pos_cmd

如果能看到持续更新的频率，说明“目标输入 -> 路径规划 -> 轨迹下发”链路已经跑通。

七、运行 Topological 规划测试

先在运行 kino_replan.launch 的终端按 Ctrl+C 停止 Kinodynamic Demo，RViz 可以继续运行。不要同时启动两个 Demo，因为它们会创建同名节点并使用相同话题。

然后在规划器终端执行：

1
2
3

source /opt/ros/noetic/setup.bash
source /root/fast_planner_ws/devel/setup.bash
roslaunch plan_manage topo_replan.launch

这个仓库的 topo_replan.launch 已经默认使用 flight_type=1，可以直接在 RViz 中通过 2D Nav Goal 发送目标，不需要修改 launch 文件。看到多条拓扑候选路径和最终轨迹，并且无人机开始执行轨迹，即表示 Topological Demo 测试通过。

八、后续重新运行

代码和编译结果都位于 /root。按照《Docker使用教程》的挂载方式，它们会同步保存在宿主机 ~/docker/ros_root 中。apt 安装的软件和 /usr/local 下的 NLopt 属于容器文件系统；停止再启动同一个容器时仍然存在，但删除容器后不会由 /root 挂载保留。

下次启动同一个容器后不需要重新下载和编译，只需在每个新终端加载环境：

1
2

source /opt/ros/noetic/setup.bash
source /root/fast_planner_ws/devel/setup.bash

然后分别启动：

1

roslaunch plan_manage rviz.launch

以及二选一：

1

roslaunch plan_manage kino_replan.launch

1

roslaunch plan_manage topo_replan.launch

如果本次测试结束后不再运行容器中的图形程序，可以在宿主机撤销临时的 X11 授权：

1

xhost -SI:localuser:root

九、常见问题

1. roslaunch 找不到 plan_manage

说明当前终端没有加载工作空间，或者编译没有成功：

1
2
3
4
5

source /opt/ros/noetic/setup.bash
cd /root/fast_planner_ws
catkin_make -DCMAKE_BUILD_TYPE=Release -j2
source devel/setup.bash
rospack find plan_manage

2. 链接时找不到 libnlopt.so

检查 NLopt 的安装位置并刷新缓存：

1
2
3
4

ls -l /usr/local/include/nlopt.hpp
ls -l /usr/local/lib/libnlopt.so
ldconfig
ldconfig -p | grep nlopt

项目明确查找 /usr/local/lib/libnlopt.so。如果动态库被安装到了 /usr/local/lib64，重新执行第二节的 CMake 命令，并保留 -DCMAKE_INSTALL_LIBDIR=lib。

3. RViz 无法打开或提示 X11 权限错误

先退出到宿主机，确认容器仍然按照《Docker使用教程》挂载了 /tmp/.X11-unix 和 .Xauthority，然后执行：

1

xhost +SI:localuser:root

再使用第五节中带 DISPLAY 的 docker exec 命令进入容器并启动 RViz。

4. RViz 中有地图，但点击目标后没有轨迹

依次检查输入和输出：

1
2
3

rostopic echo -n 1 /move_base_simple/goal
rostopic echo -n 1 /waypoint_generator/waypoints
rostopic echo -n 1 /planning/bspline

每条命令都应先运行，再回到 RViz 发送一次新目标。同时确认目标位于地图范围内、没有落在障碍物中，并且当前只运行了一个规划 Demo。

参考资料

• dreamer198/Fast-Planner
• Fast-Planner 上游仓库
• NLopt v2.7.1

在学习无人机轨迹规划时，经常会看到一句话：四旋翼无人机是微分平坦系统。

这句话听起来很理论，但它对工程实现非常关键。因为很多规划器并不会直接优化四个电机转速，也不会直接优化滚转角、俯仰角和力矩，而是优先优化三维空间中的位置轨迹。这样做背后的原因，就是四旋翼的状态和控制输入可以由位置、偏航角及其有限阶导数恢复出来。

这篇文章先整理微分平坦性的判断标准，再通过质点、小车和四旋翼三个例子说明它到底是什么意思，最后结合 EGO-Planner、MINCO、minimum-snap 这类轨迹规划方法理解它的实际意义。

一、微分平坦性到底在判断什么？

考虑一个一般的动力系统：

$$\dot{x}=f(x,u)$$

其中：

• $x$ 是系统状态，例如位置、速度、姿态和角速度；
• $u$ 是控制输入，例如推力、力矩或加速度指令。

如果系统有 $m$ 个独立控制输入，要证明它具有微分平坦性，通常需要找到 $m$ 个相互独立的输出：

$$y =\begin{bmatrix}y_1 & y_2 & \cdots & y_m\end{bmatrix}^{T}$$

使得系统的所有状态和控制输入都能表示成：

$$x=\Phi(y,\dot{y},\ddot{y},\cdots,y^{(r)})$$

$$u=\Psi(y,\dot{y},\ddot{y},\cdots,y^{(s)})$$

其中 $r$ 和 $s$ 是有限整数。

这组输出 $y$ 就叫做平坦输出。微分平坦理论的核心可以概括成一句话：

如果能用一组平坦输出及其有限阶导数参数化系统的全部状态和控制输入，那么这个系统就是微分平坦系统。

注意这里的关键不是“系统是不是线性的”，也不是“系统是不是完全驱动的”，而是能不能找到这样一组平坦输出。

二、什么叫由平坦输出直接恢复？

所谓“直接恢复”，指的是只需要做有限次：

• 代数运算；
• 三角函数运算；
• 求导；
• 代入动力学方程。

不应该再需要：

• 对未知变量积分；
• 求解新的微分方程；
• 依赖系统过去的完整运动历史。

举个反例，如果选择某个变量 $y(t)$ 作为候选平坦输出，但恢复状态时出现：

$$x(t)=x(0)+\int_0^t y(\tau)\,d\tau$$

那么仅靠当前时刻的 $y,\dot{y},\ddot{y}$ 等有限阶导数，并不能确定 $x(t)$。还必须知道初始值和历史积分。因此，这样的 $y$ 通常不能作为平坦输出。

这一区别很重要。微分平坦性强调的是当前轨迹点附近的有限阶导数信息足够恢复系统状态和输入，而不是“只要知道整条历史轨迹就能算出来”。

三、最简单的例子：一维质点

考虑一个一维质点模型：

$$\dot{x}=v$$

$$\dot{v}=u$$

其中：

• $x$ 是位置；
• $v$ 是速度；
• $u$ 是加速度控制输入。

选择位置作为平坦输出：

$$y=x$$

那么：

$$x=y$$

$$v=\dot{y}$$

$$u=\ddot{y}$$

只要规划一条足够光滑的位置曲线 $y(t)$，就能直接得到速度和控制输入。因此，这个系统是微分平坦的。

这也解释了为什么很多轨迹规划算法喜欢用多项式、B 样条或 MINCO 这类参数化曲线描述位置轨迹：位置曲线一旦确定，速度、加速度以及更高阶导数都可以直接算出来。

四、非完整约束系统也可能微分平坦

微分平坦性并不要求系统能够直接向任意方向运动。

例如一辆非完整约束小车只能前进、后退和转向，不能像全向轮机器人一样横向平移。它的简化模型可以写成：

$$\dot{x}=v\cos\theta$$

$$\dot{y}=v\sin\theta$$

$$\dot{\theta}=\omega$$

其中：

• $x,y$ 是车辆位置；
• $\theta$ 是车头朝向；
• $v$ 是前进速度；
• $\omega$ 是转向角速度。

虽然车辆不能直接横移，但可以选择平面位置作为平坦输出：

$$y_f =\begin{bmatrix}x & y\end{bmatrix}^{T}$$

由位置轨迹的一阶导数可以恢复车头朝向：

$$\theta=\mathrm{atan2}(\dot{y},\dot{x})$$

速度为：

$$v=\sqrt{\dot{x}^2+\dot{y}^2}$$

角速度可以由轨迹的一阶、二阶导数恢复：

$$\omega=\frac{\dot{x}\ddot{y}-\dot{y}\ddot{x}}{\dot{x}^2+\dot{y}^2}$$

所以，只要给出车辆在平面内的运动轨迹，就可以反推出车头方向和控制输入。

这个例子说明：系统有运动约束，甚至是欠驱动系统，并不代表它一定不是微分平坦系统。

五、四旋翼为什么是微分平坦系统？

理想四旋翼模型通常可以选择：

$$y_f =\begin{bmatrix}x & y & z & \psi\end{bmatrix}^{T}$$

作为平坦输出，其中：

• $x,y,z$ 是无人机质心位置；
• $\psi$ 是偏航角，也可以理解为机头朝向。

四旋翼看起来很复杂，因为它包含位置、速度、姿态、角速度、总推力、力矩和四个电机转速。但在常见模型下，这些量都可以通过位置、偏航角及其有限阶导数恢复出来。

1. 四旋翼只有四个独立控制输入

四旋翼有四个电机。通过调节四个旋翼转速，可以形成：

$$u=\begin{bmatrix}f & \tau_x & \tau_y & \tau_z\end{bmatrix}^{T}$$

其中：

• $f$ 是总推力；
• $\tau_x$ 是滚转力矩；
• $\tau_y$ 是俯仰力矩；
• $\tau_z$ 是偏航力矩。

也就是说，虽然四旋翼在三维空间中具有六个自由度：

$$x,y,z,\phi,\theta,\psi$$

但它只有四个独立控制输入，是典型的欠驱动系统。

微分平坦性的特殊之处就在于：即使四旋翼是欠驱动系统，仍然可以用四个平坦输出描述完整运动。

2. 由位置轨迹恢复推力方向

为了简化表达，假设：

• 世界坐标系的竖直向上方向为 $e_3=[0,0,1]^T$；
• 重力方向向下；
• 无人机总推力沿机体坐标系的 $z$ 轴方向；
• 暂时忽略空气阻力和电机动态。

四旋翼的平移动力学方程可以写成：

$$m\ddot{p}=-mg e_3+f b_3$$

其中：

• $p=[x,y,z]^T$ 是无人机位置；
• $m$ 是无人机质量；
• $f$ 是总推力；
• $b_3$ 是机体 $z$ 轴在世界坐标系下的方向。

整理后得到：

$$f b_3=m(\ddot{p}+g e_3)$$

这条公式非常关键。只要给定位置轨迹 $p(t)$，就可以计算加速度 $\ddot{p}(t)$，进而得到总推力大小：

$$f=m\left\|\ddot{p}+g e_3\right\|$$

以及无人机机体 $z$ 轴方向：

$$b_3=\frac{\ddot{p}+g e_3}{\left\|\ddot{p}+g e_3\right\|}$$

因此，位置轨迹的二阶导数决定了无人机需要朝哪个方向倾斜，以及需要产生多大的总推力。

几个直观例子：

• 如果无人机悬停，则 $\ddot{p}=0$，机体 $z$ 轴竖直向上；
• 如果无人机需要向前加速，就必须向前倾斜；
• 如果无人机需要快速爬升，总推力必须大于重力。

3. 为什么还需要偏航角？

由位置加速度只能确定机体 $z$ 轴方向 $b_3$，也就是确定无人机应该怎样倾斜。但是，无人机仍然可以绕自身 $z$ 轴旋转。

可以想象一架正在悬停的无人机：它保持高度不变，但机头仍然可以朝东、朝西或缓慢转圈。

因此，仅使用 $x(t),y(t),z(t)$ 还不足以唯一确定完整姿态，还需要补充偏航角 $\psi(t)$。

先根据偏航角定义一个期望水平朝向：

$$b_{1c}=\begin{bmatrix}\cos\psi \\\sin\psi \\0\end{bmatrix}$$

再结合 $b_3$ 构造机体坐标系的另外两个轴：

$$b_2=\frac{b_3\times b_{1c}}{\left\|b_3\times b_{1c}\right\|}$$

$$b_1=b_2\times b_3$$

于是姿态矩阵可以写成：

$$R=\begin{bmatrix}b_1 & b_2 & b_3\end{bmatrix}$$

也就是说：

位置加速度决定无人机如何倾斜，偏航角决定机头朝向。二者结合后，可以恢复完整姿态。

4. 更高阶导数恢复角速度和力矩

到目前为止，根据平坦输出 $[x,y,z,\psi]$ 以及位置的二阶导数，已经得到了：

• 位置 $p$；
• 速度 $\dot{p}$；
• 姿态 $R$；
• 总推力 $f$。

但无人机控制还需要角速度和力矩。

姿态矩阵与角速度之间满足：

$$\dot{R}=R\hat{\omega}$$

因此：

$$\hat{\omega}=R^T\dot{R}$$

其中 $\omega$ 是机体角速度，$\hat{\omega}$ 是对应的反对称矩阵。

由于姿态 $R$ 是由 $\ddot{p}$ 和 $\psi$ 构造出来的，所以对姿态继续求导后，角速度可以由位置三阶导数和偏航角一阶导数恢复：

$$p^{(3)},\dot{\psi}$$

位置的三阶导数称为 jerk。

继续求导可以得到角加速度 $\dot{\omega}$，它与位置四阶导数和偏航角二阶导数有关：

$$p^{(4)},\ddot{\psi}$$

位置的四阶导数称为 snap。

最后，根据转动动力学方程：

$$\tau=J\dot{\omega}+\omega\times(J\omega)$$

就可以计算出控制力矩：

$$\tau=\begin{bmatrix}\tau_x & \tau_y & \tau_z\end{bmatrix}^{T}$$

其中 $J$ 是无人机的转动惯量矩阵。

六、四旋翼平坦输出的恢复链条

从四个平坦输出出发，恢复关系可以概括为：

再通过四旋翼的混控矩阵，可以把总推力和三个力矩转换成四个电机的目标推力：

$$\begin{aligned}\begin{bmatrix}f \\\tau_x \\\tau_y \\\tau_z\end{bmatrix}&=A\begin{bmatrix}f_1 \\f_2 \\f_3 \\f_4\end{bmatrix}\end{aligned}$$

只要混控矩阵 $A$ 可逆，就可以计算每个旋翼的推力。

完整链条可以写成：

1
2
3
4

[x, y, z, psi]
    -> 位置、速度、姿态、角速度
    -> 总推力、力矩
    -> 四个旋翼的推力

整个过程中只涉及有限次求导和代数运算，不需要重新求解一组微分方程。这正是微分平坦性的定义。

七、为什么轨迹规划常常优化 snap？

这也解释了为什么经典四旋翼轨迹生成方法经常使用 minimum-snap trajectory，也就是最小化位置轨迹四阶导数的平方积分：

$$J=\int_0^T \left\|p^{(4)}(t)\right\|^2 dt$$

因为 snap 与无人机的角加速度和控制力矩密切相关。限制 snap 可以让：

• 姿态变化更加平滑；
• 控制力矩变化更加平缓；
• 电机指令变化更加连续；
• 轨迹更容易被真实无人机跟踪。

Mellinger 和 Kumar 的经典四旋翼轨迹规划工作，就是利用这一性质，在三维位置和偏航角空间中生成可跟踪轨迹。

八、微分平坦不等于任意轨迹都能飞

理论上，只要给定足够光滑的：

$$[x(t),y(t),z(t),\psi(t)]$$

就可以计算出对应的状态和控制输入。

但这并不意味着任意轨迹都能被真实无人机执行。因为计算出来的控制量可能超过硬件能力，例如：

• 总推力超过电机上限；
• 需要过大的倾斜角；
• 角速度过高；
• 控制力矩过大；
• 电机转速变化过快；
• 轨迹本身穿过障碍物。

因此，轨迹规划仍然需要加入动力学约束和环境约束，例如：

$$\left\|\dot{p}\right\|\le v_{\max}$$

$$\left\|\ddot{p}\right\|\le a_{\max}$$

以及推力、姿态角、角速度、走廊安全距离等限制。

微分平坦性解决的是：

如何从容易规划的位置轨迹恢复完整动力学状态和控制指令。

它并不会自动保证轨迹一定满足硬件约束、控制约束和避障约束。

九、工程上如何判断一个系统是否微分平坦？

对于一个具体系统，可以按下面的思路判断。

1. 写出明确的动力学模型

首先需要明确系统模型到底包含哪些状态和输入。例如四旋翼模型中，要说明是否考虑：

• 空气阻力；
• 电机动态；
• 桨叶模型；
• 负载；
• 机械臂；
• 柔性绳索；
• 执行器饱和。

微分平坦性是针对特定数学模型而言的。同一架无人机，如果采用不同复杂程度的动力学模型，结论可能不同。

2. 寻找少量候选输出

通常优先考虑能直接反映运动目标的变量，例如：

平坦输出的数量通常与独立控制输入数量相同。

3. 逐层求导并代入动力学方程

观察能否从候选输出的导数逐步恢复：

• 位置；
• 速度；
• 姿态；
• 角速度；
• 推力；
• 力矩；
• 其他状态和输入。

4. 检查是否引入积分或额外微分方程

如果所有变量都能通过有限次求导和代数计算得到，则系统在该模型下是微分平坦的。

如果必须依赖积分、初始条件或完整历史轨迹，说明当前候选输出不满足要求。此时可能需要：

• 换一组候选平坦输出；
• 引入输入的动态扩展；
• 或者接受该系统在当前模型下不是微分平坦系统。

十、需要注意奇异状态

很多系统只在一定范围内具有良好的平坦参数化。

例如小车模型中：

$$\theta=\mathrm{atan2}(\dot{y},\dot{x})$$

当车辆速度为零时：

$$\dot{x}=\dot{y}=0$$

车头朝向无法根据位置轨迹的一阶导数确定，此时就会出现奇异性。

四旋翼也有类似问题。例如当：

$$\ddot{p}+g e_3=0$$

时，推力方向 $b_3$ 无法正常定义；当 $b_3$ 与期望水平朝向 $b_{1c}$ 发生退化关系时，姿态构造也可能失效。

所以，更准确的说法通常是：

系统在避开某些奇异状态的局部区域内具有微分平坦性。

十一、对 EGO-Planner 等无人机规划器的意义

在 EGO-Planner、Fast-Planner、GCOPTER、MINCO 等无人机轨迹规划框架中，规划器通常不会直接优化：

• 四个电机转速；
• 每个时刻的控制力矩；
• 完整姿态曲线；
• 飞控底层的混控输入。

它们更常见的做法，是优化三维空间中的位置曲线 $p(t)$，并约束速度、加速度、光滑性和障碍物距离。

原因就在于四旋翼的微分平坦性。规划器只需要生成一条足够光滑、满足约束的位置轨迹，轨迹跟踪控制器就可以根据期望位置、速度和加速度计算期望推力与姿态。更高性能的控制器还会使用 jerk 和 snap 构造前馈项，从而改善高速飞行时的跟踪效果。

可以把微分平坦性理解成一座桥：

1
2
3

容易规划的位置轨迹
    -> 平坦输出及其有限阶导数
    -> 复杂的无人机动力学状态和控制输入

这就是为什么在无人机轨迹规划里，很多方法都重点研究“如何生成一条光滑、无碰撞、满足动力学约束的位置轨迹”，而不是从电机转速层面直接做全量优化。

总结

一个系统具有微分平坦性的本质条件是：

存在一组平坦输出，使系统的全部状态和控制输入都能够由这些输出及其有限阶导数直接恢复，并且不需要积分或额外求解微分方程。

对于四旋翼无人机，常见平坦输出是：

$$\begin{bmatrix}x & y & z & \psi\end{bmatrix}^{T}$$

其中最关键的物理关系是：

$$f b_3=m(\ddot{p}+g e_3)$$

位置加速度决定推力方向和大小，偏航角补足机头朝向，更高阶导数进一步恢复角速度和力矩。

因此，四旋翼虽然是欠驱动系统，但在常用模型下仍然是微分平坦系统。这一性质正是四旋翼轨迹规划能够主要围绕位置曲线展开的理论基础。

论文：NavRL: Learning Safe Flight in Dynamic Environments
期刊：IEEE RA-L 2025
作者：Zhefan Xu, Xinming Han, Haoyu Shen, Hanyu Jin, Kenji Shimada
代码：https://github.com/Zhefan-Xu/NavRL

这篇论文最值得看的地方，不是“用了 PPO”这件事，而是作者把一个能落到真机上的动态环境局部导航系统拆成了三层：可迁移的状态表示、可学习的局部速度策略、可解释的安全屏蔽层。它不是那种纯 end-to-end 的“图像进、动作出”工作，而是明显更偏工程部署导向。

对于面向动态未知环境的无人机强化学习局部导航与真实部署这一研究方向，这篇论文的相关性非常直接：它已经把“动态障碍感知 + RL 决策 + 安全兜底 + Jetson 真机部署”这条链路走通了一遍。它的长处和短板，也基本对应了后续最容易继续往前推进的切入点。

一页速览

一句话判断： NavRL 不是最花哨的学习导航论文，但很像一个真正能上机的动态局部导航基线。

0. 先说结论：这篇论文和相关研究方向有什么关系？

这篇论文和上述研究方向是强相关的，原因有四个：

1. 它研究的就是局部导航，不是全局路径规划，也不是纯控制跟踪。
2. 它明确处理了动态障碍，而不是只在静态障碍里做强化学习。
3. 它非常强调真实部署，包括 Jetson Orin NX、RealSense D435i、真实行人干扰和零样本 sim-to-real。
4. 它已经意识到“纯神经网络不够安全”，所以加入了一个 VO-inspired safety shield。

但它也没有把这个方向彻底做完。更准确地说，它提供了一个很好的可复现基线和问题清单：

• 怎样设计状态表示，才能减少 sim-to-real gap；
• 怎样在动态障碍下让 RL 真的学到反应式避障；
• 怎样给黑盒策略加一个足够轻量、又能上机跑的安全层；
• 真机部署时，瓶颈到底在策略网络，还是在前端感知和安全约束。

因此，如果后续要围绕这一方向继续做论文创新，这篇文章更像是一个很实用的起点，而不是终点。

1. 这篇论文解决什么问题？

这篇论文关注的场景，是无人机在未知或部分未知的动态环境中进行局部自主导航：一边向目标点前进，一边避开静态障碍和移动障碍。现有方法里，传统优化/规划方法往往要把系统拆成预测、建图、轨迹优化等多个模块，参数多、调参重，对环境变化也比较敏感；而一些学习方法虽然有更强的适应性，但要么依赖图像直接输入导致 sim-to-real 很难，要么缺少安全机制，不适合直接上真机。作者想解决的核心痛点，其实就一句话：能不能训练一个强化学习局部导航策略，让它既能躲静态障碍，也能躲动态障碍，还能比较稳地迁移到真实无人机上，并且在策略失误时有一个轻量安全兜底。

2. 方法的核心思路是什么？

整体思路

NavRL 的整体方法并不复杂，但工程组合很有针对性。它先不用原始 RGB 图像直接喂给策略网络，而是把环境整理成两类中间表示：静态障碍的射线距离表示和动态障碍的目标级状态表示。然后用 PPO 学一个目标导向的局部速度策略，输出目标坐标系下的三维速度指令。最后在部署时，不直接相信网络输出，而是用一个基于 Velocity Obstacle 思想的安全屏蔽层，对不安全动作做一次线性规划投影。

换句话说，这篇论文的核心不是“更强的网络”，而是：先把状态表示做对，再让 RL 学反应式避障，最后用几何安全层兜底。

流程梳理

输入 -> 关键模块 -> 输出

RGB-D + 自身状态 + 目标点
-> 静态障碍建图与射线表示
-> 动态障碍检测/跟踪/测速
-> 状态编码 + PPO 策略网络
-> VO-inspired safety shield
-> 无人机速度指令

每个关键模块的作用

1. 静态障碍表示

作者先用深度图在线构建 3D occupancy voxel map，然后不把整张体素地图直接送进网络，而是从无人机位置做 3D ray casting，把各个方向上“离障碍有多远”编码成一个二维矩阵。

这个模块的作用是：把复杂的三维静态环境压缩成一个适合策略学习、又比较容易 sim-to-real 的几何表示。

这部分是有价值的设计，因为它避免了直接依赖图像纹理，也避免了整张体素地图过大、过稀疏的问题。

2. 动态障碍表示

动态障碍不进 occupancy map，而是单独检测和跟踪。作者用 U-depth detector、DBSCAN detector、YOLO 分类器和 Kalman filter，最终得到每个动态障碍的相对位置、距离、速度、尺寸。

这个模块的作用是：把“会动的东西”显式建模成目标级对象状态，而不是混进静态地图里。

这里要注意一个细节：这部分动态检测与跟踪主要继承自作者前一篇工作，并不是 NavRL 这篇 paper 的核心算法创新，但它对真实部署非常重要。

3. 状态编码与策略学习

静态障碍矩阵和动态障碍矩阵分别经过 CNN 提取特征，再和无人机内部状态拼接，送入 actor-critic 结构，用 PPO 训练。

这个模块的作用是：让网络学会在目标驱动下输出局部反应速度，而不是显式解轨迹优化问题。

真正值得注意的创新，不是 PPO 本身，而是：

• 状态分成静态/动态两条支路；
• 全部都转到 goal coordinate frame；
• 动作空间是有边界的速度命令，不是姿态、电机或离散动作。

4. 安全屏蔽层

网络输出一个候选速度 V_rl。如果这个速度不会落入任何 velocity obstacle 区域，就直接执行；如果会引发潜在碰撞，就求解一个小规模线性约束优化，把动作投影到最近的安全区域。

这个模块的作用是：在不重做完整规划的前提下，给黑盒 RL 策略加一个可解释、可实时运行的安全补丁。

这一块是全文最有“部署味”的部分，也是最贴近上述研究方向的地方。

哪些部分是作者真正的创新？

如果说得严格一点，这篇论文的创新更像系统创新而不是理论创新：

• 创新 1：面向 sim-to-real 的状态表示设计
  不用原始图像，改用静态射线图 + 动态目标状态。

• 创新 2：面向局部导航的动作设计
  直接输出目标坐标系下的三维速度，并用 Beta 分布处理有界连续动作。

• 创新 3：VO-inspired safety shield
  在 RL 输出之后做几何安全投影，降低黑盒策略失误带来的碰撞风险。

• 创新 4：大规模并行训练 + 真机验证链路
  用 Isaac Sim 同时训练上千架四旋翼，并完成 zero-shot real deployment。

反过来说，PPO、CNN 编码器、Kalman 跟踪本身都不是新东西。

3. 需要重点理解哪些公式？

这篇论文的公式不算多，但有几组必须抓住。重点不是会不会推导，而是要明白这些公式在系统里各自干什么。

3.1 强化学习目标

论文把问题写成一个标准 MDP，目标是最大化累计折扣回报：

1

π* = arg max E[ Σ γ^t R(s_t, a_t) ]

这没有太多新意，但它说明作者把这个问题当成反应式局部决策来学，而不是轨迹优化问题。也就是说，网络不负责生成整条轨迹，而是每个时刻都根据当前感知状态输出一个速度动作。

3.2 输入状态如何定义

作者设计的状态由三部分组成。

1. 无人机内部状态

1

S_int = [目标方向单位向量, 到目标距离, 当前速度]

更具体地说，是把“机器人到目标点的相对位置”拆成方向 + 距离，再加上当前速度。这样做的实际意义是：网络不用自己从大坐标差值里再去学“方向归一化”这件事，优化会更稳定一些。

而且这些量都放在 goal coordinate frame 下。这个设计很关键，因为它弱化了绝对世界坐标的影响，让策略更像“朝目标前进时如何避障”的通用技能，更利于迁移。

2. 动态障碍状态

1
2

D_i = [相对方向单位向量, 相对距离, 障碍速度, 障碍尺寸]
S_dyn = [D_1, D_2, ..., D_Nd]

这意味着动态障碍不是一堆像素，而是一组带运动属性的对象。实际含义很直接：策略不仅知道前面有东西，还知道它往哪儿动、动多快、占多大。

对这一研究方向来说，这个设计很值得借鉴，因为动态局部导航的关键往往不是“看到障碍”，而是“知道它在怎么动”。

3. 静态障碍状态

1

S_stat = [R_θ0, R_θ1, ..., R_θNv]

这里每个 R_θi 都是一组射线长度，表示不同方向上与静态障碍的距离。它本质上是一个稠密的局部几何可通行性描述。

这个表示的实际意义是：网络拿到的不是地图本身，而是“周围哪些方向更空旷”。这对局部反应式策略很友好。

3.3 输出动作是什么

作者不是直接让网络输出真实速度，而是先输出一个归一化速度，再映射到最大速度范围内：

1

V_ctrl^G = v_lim * (2 * V_hat_ctrl^G - 1),    V_hat_ctrl^G ∈ [0, 1]

这里最关键的不是这个线性映射，而是背后的动作设计思想：

• 输出的是速度，不是低层控制量；
• 速度有明确边界；
• 策略是在目标坐标系下输出速度；
• 网络参数化的是 Beta distribution，适合有界连续动作空间。

实际含义就是：作者希望动作既好学，又容易跨平台迁移，也方便人理解和监督。

3.4 奖励函数在鼓励什么

总奖励写成：

1

r = λ1 r_vel + λ2 r_ss + λ3 r_ds + λ4 r_smooth + λ5 r_height

看起来简单，但每一项都对应一个很现实的飞行偏好。

1. 速度奖励 r_vel

1

r_vel = goal方向单位向量 · 当前速度

它鼓励无人机沿着目标方向高速前进。通俗讲，就是“别磨蹭，往目标方向走”。

2. 静态安全奖励 r_ss

1

r_ss = 平均 log(射线距离)

离静态障碍越远，奖励越大。这里用 log 而不是线性距离，意味着作者希望“离得很近时惩罚更敏感，离得已经够远时边际收益变小”。

3. 动态安全奖励 r_ds

1

r_ds = 平均 log(与动态障碍的距离)

它和静态安全奖励类似，但针对会动的障碍。实际含义是：策略会倾向于和动态目标保持间距。

4. 平滑奖励 r_smooth

1

r_smooth = - ||v_t - v_(t-1)||

这在真实无人机上很重要。没有这项，RL 很容易学出抖动控制，看起来会“能躲，但飞得很难受”。

5. 高度奖励 r_height

作者额外惩罚无人机过度上升，防止它通过“往高处飞”来投机避障。这个设计虽然简单，但很实用，因为很多 RL 策略确实会钻这种空子。

3.5 安全约束在做什么

部署阶段最重要的是下面这个投影问题：

1
2
3

min ||V_safe - V_rl||
s.t.  V_safe 落在各个 velocity obstacle 外侧
      V_min <= V_safe <= V_max

它的实际含义很清楚：尽量少改网络动作，但如果网络动作会撞，就把它推到最近的安全速度上。

这里最值得理解的不是公式本身，而是它代表的安全哲学：

• RL 负责“好用”；
• safety shield 负责“别出大事”；
• 两者不是互斥，而是串联。

这很适合真实部署，因为真机系统里往往不敢把最后控制权完全交给神经网络。

4. 实验说明了什么？

使用了哪些场景、平台和硬件？

作者的实验分三层：

1. 训练：NVIDIA Isaac Sim
   使用 RTX 4090，约训练 10 小时，同时并行训练 1024 架四旋翼。

2. 仿真测试：Gazebo
   包括走廊类场景，以及高密度静态/动态/混合障碍环境。

3. 真实飞行测试：自定义四旋翼平台
   机载计算为 Jetson Orin NX，传感器使用 Intel RealSense D435i，状态估计使用 LIO。

与哪些方法进行了对比？

主要对比了三类对象：

• EGO-Planner：经典静态局部规划器；
• ViGO：作者之前做的 vision-aided dynamic planner；
• NavRL without safety shield：看安全屏蔽层是否真的有用。

这个对比组合有意义，但也有明显不足：缺少更强的 RL baseline，所以它更像“证明自己能部署且比这两个工程基线更抗动态障碍”，而不是证明自己在 RL 领域绝对最强。

使用了哪些指标？

作者主要看了四类指标：

1. 训练成功率
   定义为从起点安全到达目标点且无碰撞。

2. 训练回报曲线

3. 平均碰撞次数
   在 20 次运行上统计。

4. 各模块运行时延

最重要的实验结果是什么？

下面这些数字最值得记住。

1. Curriculum learning 确实有效

训练环境大小为 50m x 50m，动态障碍数量从 60 -> 80 -> 100 -> 120 逐步提升。
在固定训练时间下：

• dynamic=80 时，成功率从 74.51% 提升到 82.71%
• dynamic=100 时，从 62.30% 提升到 80.96%
• dynamic=120 时，从 54.98% 提升到 68.65%

这说明对于动态障碍局部导航，课程学习不是装饰项，而是训练能不能稳定起来的重要条件。

2. 大规模并行训练有用

作者比较了不同机器人数量下的训练回报，结论是：机器人越多，收敛越快，最终回报也越高。

这个结果很有参考价值，因为如果后续也做 Isaac Sim 或 Omnidrones 一类的大规模并行训练，训练吞吐量很可能决定能不能把“动态交互策略”真正学出来。

3. 真正的优势体现在动态和混合环境

在 20m x 40m 的高密度测试图上，平均碰撞次数如下：

• 静态环境

  • EGO: 0.45
  • ViGO: 0.80
  • NavRL w/o shield: 0.95
  • NavRL: 0.65

• 纯动态环境

  • ViGO: 3.15
  • NavRL w/o shield: 2.70
  • NavRL: 0.85

• 混合环境

  • ViGO: 4.40
  • NavRL w/o shield: 4.60
  • NavRL: 2.10

这个结果非常说明问题：NavRL 的主要价值不是把静态环境做到极致，而是在动态和混合场景里显著降低碰撞。

4. Safety shield 不是可有可无

从上面的数字也能看出来，去掉 safety shield 后：

• 纯动态环境碰撞从 0.85 上升到 2.70
• 混合环境碰撞从 2.10 上升到 4.60

这说明仅靠 RL 策略本身还不够稳，安全屏蔽层在动态环境里几乎是决定性组件。

5. 真机运行时延是可以接受的

Jetson Orin NX 上的运行时间：

• Static perception: 15 ms
• Dynamic perception: 27 ms
• RL policy: 7 ms
• Safety shield: 16 ms

总和大约 65 ms，对应约 15 Hz。这说明它确实可以上机实时跑，但也说明一个事实：瓶颈并不在策略网络，而在前端感知和安全层。

是否有真实无人机实验？

有。作者做了真实室内飞行实验，设置静态障碍，并让行人朝无人机运动，测试其避障与到达目标能力。论文给出的结论是：无人机能够零样本从仿真迁移到真实平台，并在有行人扰动的场景中安全到达目标。

实验是否足以支持作者的结论？

本文认为，它足以支持“这是一个可部署、在动态环境中有效的 RL 局部导航系统”这个结论，但还不足以支持“这是动态无人机导航的通用最优方案”。

原因是：

• baseline 不够丰富，特别缺少更强的 RL 和 hybrid 方法；
• 真实实验展示了可行性，但规模仍然有限；
• 主要指标是碰撞次数，缺少更细的效率、舒适性、死锁率、TTC 裕度等分析；
• 最大速度只有 2.0 m/s，更偏安全导航，不是高速敏捷飞行。

5. 这个方法有哪些局限性？

最关键的一条： 这篇论文最大的风险不是“策略学不会”，而是“真实部署时前端感知和安全层一起决定了上限”。

6. 可以如何在此基础上创新？

如果后续想围绕这篇论文做研究，优先考虑那些真的能解决部署问题、而且能靠实验验证的方向，而不是只换个 backbone。

更推荐的组合

感知不确定性建模 + 安全屏蔽层升级 + 真实部署鲁棒训练

这条线最能击中 NavRL 的真实薄弱处，而且最容易形成“动态未知环境 + 真机部署”的清晰论文故事。

7. 最后给出一份简短笔记

总体评价

如果只从算法新颖性看，NavRL 不是那种会让人惊呼“方法太新了”的论文；但如果从真实系统能不能落地这个角度看，它是很有价值的。它真正回答的问题不是“RL 能不能在论文里跑通”，而是“RL 能不能和感知、安全机制、机载计算一起组成一个能飞的动态导航系统”。

对这一研究方向来说，这篇论文最大的价值有两个：

1. 它给出一个能对标、能复现、能上机的动态局部导航基线。
2. 它把后续最值得创新的痛点暴露得很清楚：感知不确定性、动态交互建模、shield 的保守性、以及复杂真实场景下的鲁棒性。

因此，本文的结论是：这篇论文很值得读，也值得复现，但更值得在它暴露出来的问题上继续往前推。

Vim 是 Linux 终端里非常常用的文本编辑器。平时修改配置文件、写脚本、在服务器或 Docker 容器里临时改代码，经常都会用到它。

刚开始接触 Vim 时，最容易卡住的地方不是“怎么高效编辑”，而是“怎么进入编辑、怎么保存、怎么退出”。所以这篇文章先从最基本的生存命令开始，再逐步整理移动、复制粘贴、查找替换、多文件编辑和常用配置。

一、安装 Vim

在 Ubuntu / Debian 系统中安装：

1
2

sudo apt update
sudo apt install -y vim

查看版本：

1

vim --version

如果只是临时使用，系统里也可能已经有 vi：

1

vi 文件名

不过日常更推荐安装并使用 vim。

二、打开和创建文件

打开一个已有文件：

1

vim test.txt

如果 test.txt 不存在，Vim 会在保存时创建这个文件。

打开某个系统配置文件：

1

sudo vim /etc/hosts

打开后，默认处于普通模式，此时直接敲键盘不会像普通编辑器一样输入文字。

三、理解 Vim 的几种模式

Vim 最重要的特点是“模式编辑”。常用模式有下面几种：

最常用的流程可以记成：

1

普通模式 -> 按 i -> 插入模式 -> 输入内容 -> 按 Esc -> 普通模式 -> 输入 :wq 保存退出

四、最重要的保存和退出

这些命令都需要先按 Esc 回到普通模式，再输入 : 进入命令模式。

刚开始最常用的是：

1

:wq

如果改乱了，不想保存：

1

:q!

五、进入插入模式

在普通模式下，可以通过下面这些按键进入插入模式：

最开始只记两个就够：

• i：开始编辑当前内容。
• o：新开一行继续写。

六、移动光标

Vim 中可以用方向键移动，也可以用 h、j、k、l 移动：

常用移动命令：

翻页操作：

七、删除、修改和撤销

常用删除命令：

常用修改命令：

撤销和重做：

如果误删了一行，可以按：

1

u

八、复制、剪切和粘贴

在 Vim 里，删除操作很多时候也可以理解成“剪切”。

例如复制当前行并粘贴到下一行：

1
2

yy
p

剪切当前行并粘贴到其他位置：

1
2
3

dd
移动光标
p

九、可视模式选择文本

普通模式下按 v 进入字符选择，按 V 进入整行选择。

如果想复制一整段内容：

1. 按 V 进入整行选择。
2. 使用 j / k 选择多行。
3. 按 y 复制。
4. 移动到目标位置后按 p 粘贴。

十、查找和替换

1. 查找文本

向下查找：

1

/关键词

向上查找：

1

?关键词

查找后继续跳转：

2. 替换文本

替换当前行第一个匹配：

1

:s/旧内容/新内容/

替换当前行所有匹配：

1

:s/旧内容/新内容/g

替换全文所有匹配：

1

:%s/旧内容/新内容/g

替换全文并逐个确认：

1

:%s/旧内容/新内容/gc

其中：

• % 表示全文。
• s 表示 substitute，也就是替换。
• g 表示当前行内所有匹配项。
• c 表示 confirm，每次替换前确认。

十一、显示行号和常用临时设置

在 Vim 中可以临时开启行号：

1

:set number

关闭行号：

1

:set nonumber

开启搜索高亮：

1

:set hlsearch

关闭搜索高亮：

1

:nohlsearch

开启自动缩进：

1

:set autoindent

显示当前文件名和状态：

1

:f

十二、编辑多个文件

一次打开多个文件：

1

vim file1.txt file2.txt

查看缓冲区列表：

1

:ls

切换到下一个文件：

1

:bn

切换到上一个文件：

1

:bp

打开另一个文件：

1

:e another.txt

保存全部文件：

1

:wa

退出全部文件：

1

:qa

保存并退出全部文件：

1

:wqa

十三、分屏编辑

横向分屏打开文件：

1

:split file.txt

也可以简写：

1

:sp file.txt

纵向分屏打开文件：

1

:vsplit file.txt

也可以简写：

1

:vsp file.txt

分屏后常用快捷键：

十四、没有权限保存怎么办

有时打开系统文件时忘了加 sudo：

1

vim /etc/hosts

编辑完保存时可能提示没有权限。可以在 Vim 中执行：

1

:w !sudo tee %

执行后输入当前用户密码，文件就会通过 sudo tee 写回去。

这个命令的含义是：

• :w：把当前缓冲区内容写出。
• !sudo tee %：把内容交给外部命令 sudo tee。
• %：表示当前文件名。

保存成功后，如果 Vim 提示文件已改变，可以输入：

1

:e!

重新加载当前文件。

十五、配置 vimrc

如果希望每次打开 Vim 都自动显示行号、开启语法高亮，可以编辑用户配置文件：

1

vim ~/.vimrc

一个简单的配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

" 显示行号
set number

" 开启语法高亮
syntax on

" 开启文件类型检测
filetype plugin indent on

" 搜索时忽略大小写，输入大写字母时自动区分大小写
set ignorecase
set smartcase

" 搜索时边输入边高亮
set incsearch
set hlsearch

" Tab 显示为 4 个空格宽度
set tabstop=4
set shiftwidth=4
set softtabstop=4

" 按 Tab 输入空格
set expandtab

" 自动缩进
set autoindent
set smartindent

" 显示当前光标所在行
set cursorline

" 底部显示命令
set showcmd

" 显示模式
set showmode

" 支持鼠标
set mouse=a

保存后重新打开 Vim 即可生效。

如果不想使用鼠标，可以删除：

1

set mouse=a

十六、常用命令速查

十七、推荐练习顺序

刚开始不要一口气背太多命令，可以按下面顺序练：

1. 用 vim test.txt 打开文件。
2. 按 i 输入几行文字。
3. 按 Esc 回到普通模式。
4. 用 :w 保存。
5. 用 dd 删除一行，再用 u 撤销。
6. 用 yy 复制一行，再用 p 粘贴。
7. 用 /关键词 查找内容。
8. 用 :%s/旧内容/新内容/gc 练习确认替换。
9. 最后用 :wq 保存退出。

熟悉这些以后，日常修改配置文件、编辑脚本、在服务器里处理文本基本就够用了。

总结

Vim 的学习重点不是一次记住所有快捷键，而是先建立“模式”的概念：

1

普通模式负责操作，插入模式负责输入，命令模式负责保存退出和高级命令。

新手最先需要掌握的是：

• i：进入编辑。
• Esc：回到普通模式。
• :wq：保存退出。
• :q!：放弃修改退出。
• dd、yy、p、u：完成基础编辑。

等这些命令用熟之后，再逐渐学习查找替换、分屏、多文件和 .vimrc 配置，Vim 就会从“容易退出不了的编辑器”变成一个非常顺手的终端工具。

本文记录在 Jetson 上通过 Docker 跑通 ROS1 真机链路：

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

Mid-360S
  -> livox_ros_driver2
  -> FAST-LIO
  -> /Odometry + /cloud_registered
  -> odom_to_base.py
  -> /Odometry_base
  -> odom_to_pose.py
  -> /mavros/vision_pose/pose
  -> PX4 EKF2

/Odometry_base + /cloud_registered
  -> Diff-Planner
  -> /drone_0_planning/pos_cmd
  -> trajectory_msg_converter.py
  -> /command/trajectory
  -> se3_controller
  -> /mavros/setpoint_raw/attitude
  -> PX4 Offboard

环境：

1
2
3
4
5
6

机载电脑：Jetson Orin NX
宿主系统：Ubuntu 22.04
容器镜像：ros:noetic-ros-base-focal
飞控：PX4
雷达：Livox Mid-360S
算法：FAST-LIO + Diff-Planner

• 宿主机只负责 Docker、雷达网口、PX4 串口。
• ROS1 全部放进容器。
• 真机默认不自动切 Offboard，不自动解锁，始终保留遥控器接管能力。
• 第一次建议先不装桨；装桨后先在 0.3 ~ 0.5 m 高度测试。
• 最新 Dockerfile 部署仓库：https://github.com/dreamer198/diff-planner-px4-deployment

代码链路总览

这套真机方案分成三部分：Jetson 宿主机负责启动和硬件访问，ROS1 节点跑在容器内，本机负责 RViz 可视化和发目标点。

目前推荐直接使用整理好的 Dockerfile 部署仓库：

1

https://github.com/dreamer198/diff-planner-px4-deployment

• Jetson 推荐路径：/home/jetson2/diff-planner-px4-deployment
• Jetson 宿主机启动入口：scripts/start_real_px4_mid360_fastlio.sh
• 本机 RViz 启动入口：scripts/start_jetson_ros1_rviz.sh
• ROS1 容器名：ros_noetic_realflight
• 容器内工作区：~/livox_ws（Livox 驱动）、~/catkin_ws（FAST-LIO、Diff-Planner、控制相关代码）

启动脚本运行在 Jetson 宿主机，不在容器内执行。它通过 tmux + docker exec 依次拉起下面这条链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

Jetson 宿主机
  -> scripts/start_real_px4_mid360_fastlio.sh
  -> docker exec 进入 ros_noetic_realflight 容器

容器内感知链路：
  livox_ros_driver2
    -> /livox/lidar + /livox/imu
  FAST-LIO
    -> /Odometry + /cloud_registered
  odom_to_base.py
    -> /Odometry_base
  odom_to_pose.py
    -> /mavros/vision_pose/pose
  MAVROS
    -> PX4 EKF2

容器内规划控制链路：
  /Odometry_base + 点云/地图
    -> Diff-Planner
    -> /drone_0_planning/pos_cmd
    -> trajectory_msg_converter.py
    -> /command/trajectory
    -> se3_controller
    -> /mavros/setpoint_raw/attitude
    -> PX4 Offboard

本机可视化链路：
  scripts/start_jetson_ros1_rviz.sh
    -> 本机容器内 RViz + /root/jetson_real_stack.rviz + rviz_goal_to_diff_planner.py
    -> /move_base_simple/goal 或 /clicked_point
    -> /goal
    -> Diff-Planner

各层对应代码如下：

• Dockerfile 部署层：docker/Dockerfile、docker/docker_run_real.sh，负责构建镜像、创建 ros_noetic_realflight 容器并挂载真机配置。
• 启动调度层：scripts/start_real_px4_mid360_fastlio.sh，负责 start / stop / restart / status / attach，并在宿主机顺序拉起整条链路。
• 雷达驱动层：~/livox_ws/src/livox_ros_driver2，入口 msg_MID360s.launch，配置 config/MID360s_config.json，发布 /livox/lidar、/livox/imu。
• 里程计层：~/catkin_ws/src/FAST_LIO，入口 launch/mapping_mid360.launch，发布 /Odometry、`/cloud_registered``；Mid-360S 倾斜安装时常改 IMU 初始化逻辑。
• 机体外参补偿层：/root/catkin_ws/src/px4_realflight_tools/scripts/odom_to_base.py，把 /Odometry 转成 /Odometry_base。
• PX4 视觉桥接层：/root/catkin_ws/src/px4_realflight_tools/scripts/odom_to_pose.py，把 /Odometry_base 转成 /mavros/vision_pose/pose。
• 规划层：~/catkin_ws/src/Diff-Planner-PX4/src/diff_planner，真机入口通常是 run_real_mid360_lio.launch，输出 /drone_0_planning/pos_cmd。
• 轨迹格式转换层：~/catkin_ws/src/Diff-Planner-PX4/src/diff_planner/plan_manage/scripts/trajectory_msg_converter.py，把 /drone_0_planning/pos_cmd 转成 /command/trajectory。
• 控制层：~/catkin_ws/src/Diff-Planner-PX4/src/se3_controller，核心节点 src/se3_controller_node.cpp，把 /command/trajectory 转成 /mavros/setpoint_raw/attitude。
• 本机 RViz 层：scripts/start_jetson_ros1_rviz.sh、config/rviz/jetson_real_stack.rviz、scripts/rviz_goal_to_diff_planner.py，负责显示点云、里程计、占据地图、规划轨迹，并把 2D Nav Goal 或 Publish Point 转成 /goal。

如果后面要排错，可以按这个顺序看：/livox/lidar -> /Odometry -> /Odometry_base -> /mavros/vision_pose/pose -> /drone_0_planning/pos_cmd -> /command/trajectory -> /mavros/setpoint_raw/attitude。

推荐：使用 Dockerfile 部署仓库

新 Jetson 迁移时，优先使用这个仓库，而不是手动一步步复制代码：

1
2
3
4
5

cd /home/jetson2
git clone https://github.com/dreamer198/diff-planner-px4-deployment.git
cd diff-planner-px4-deployment
./docker/docker_run_real.sh build
FCU_DEVICE=/dev/ttyACM0 ./docker/docker_run_real.sh restart

然后启动真机链路：

1
2
3
4
5
6
7
8
9
10

cd diff-planner-px4-deployment \
FCU_URL='serial:///dev/ttyACM0:57600' \
GCS_URL='udp://:14550@10.0.30.196:14550' \
SE3_HOVER_PERCENT=0.60 \
SE3_MAX_HOVER_PERCENT=0.95 \
SE3_MAX_OUTPUT_THRUST=1.00 \
SE3_ENABLE_THRUST_ESTIMATION=false \
SE3_MAX_FEEDFORWARD_ACC=1.2 \
DIFF_PLANNER_INFLATION_SIZE=0.2 \
./scripts/start_real_px4_mid360_fastlio.sh start

后面的手动安装步骤主要用于理解链路和排错；实际迁移建议直接用这个 Dockerfile 仓库。

一、宿主机准备

下面命令都在 Jetson 宿主机执行。

1. Docker

1
2

sudo systemctl status docker
docker info

如当前用户没有 Docker 权限：

1

sudo usermod -aG docker $USER

2. Mid-360S 网口

查看网卡：

1

ip addr

假设雷达网卡为 eth0：

1
2
3

sudo ip addr add 192.168.1.101/24 dev eth0
sudo ip link set eth0 up
ping 192.168.1.199

把上面 IP 改成你的实际值。

3. PX4 串口

1
2

ls -l /dev/ttyACM*
sudo chmod 666 /dev/ttyACM0

本文默认使用 /dev/ttyACM0。

二、创建 ROS1 容器

如果你已经有 ros_noetic 容器，可以跳过。

1
2

mkdir -p ~/docker/ros_root
xhost +SI:localuser:root

创建容器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

docker run -it \
  --name ros_noetic \
  --network host \
  --ipc host \
  --privileged \
  --device=/dev/ttyACM0 \
  -e DISPLAY=$DISPLAY \
  -e XAUTHORITY=/root/.Xauthority \
  -e QT_X11_NO_MITSHM=1 \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -v $HOME/.Xauthority:/root/.Xauthority:ro \
  -v /dev/bus/usb:/dev/bus/usb \
  -v ~/docker/ros_root:/root \
  ros:noetic-ros-base-focal \
  bash

重新进入：

1
2

docker start -ai ros_noetic
docker exec -it ros_noetic bash

三、容器内基础环境

下面命令都在容器内执行。

安装依赖：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

apt update
apt install -y \
  git wget curl vim nano \
  net-tools iproute2 iputils-ping \
  build-essential cmake python3-pip \
  python3-catkin-tools python3-rosdep python3-osrf-pycommon \
  libeigen3-dev libpcl-dev pcl-tools libopencv-dev \
  libgoogle-glog-dev libgflags-dev libarmadillo-dev \
  ros-noetic-cv-bridge ros-noetic-eigen-conversions \
  ros-noetic-mavros ros-noetic-mavros-extras \
  ros-noetic-pcl-ros ros-noetic-roslint \
  ros-noetic-tf ros-noetic-tf2-ros \
  ros-noetic-tf2-sensor-msgs ros-noetic-tf2-geometry-msgs \
  ros-noetic-ddynamic-reconfigure ros-noetic-rviz

初始化 rosdep：

1
2

rosdep init || true
rosdep update

安装 GeographicLib 数据：

1
2
3
4

cd ~
wget https://gitee.com/tyx6/mytools/raw/main/mavros/install_geographiclib_datasets.sh
chmod +x install_geographiclib_datasets.sh
./install_geographiclib_datasets.sh

在 ~/.bashrc 末尾添加：

1
2
3
4
5
6
7

[ -f /opt/ros/noetic/setup.bash ] && source /opt/ros/noetic/setup.bash
[ -f ~/livox_ws/devel/setup.bash ] && source ~/livox_ws/devel/setup.bash
[ -f ~/catkin_ws/devel/setup.bash ] && source ~/catkin_ws/devel/setup.bash

export FCU_URL="serial:///dev/ttyACM0:57600"
export GCS_URL="udp://:14550@10.0.30.196:14550"
export DRONE_ID=0

生效：

1

source ~/.bashrc

四、安装 Livox 驱动

安装 Livox-SDK2：

1
2
3
4
5
6
7
8
9
10

cd ~
mkdir -p ~/code
cd ~/code
git clone https://github.com/Livox-SDK/Livox-SDK2.git
cd Livox-SDK2
mkdir -p build && cd build
cmake ..
make -j4
make install
ldconfig

编译 livox_ros_driver2：

1
2
3
4
5
6
7

mkdir -p ~/livox_ws/src
cd ~/livox_ws/src
git clone https://github.com/Livox-SDK/livox_ros_driver2.git
cd ~/livox_ws/src/livox_ros_driver2
source /opt/ros/noetic/setup.bash
./build.sh ROS1
source ~/livox_ws/devel/setup.bash

配置 Mid-360S：

1
2

cd ~/livox_ws/src/livox_ros_driver2/config
nano MID360s_config.json

重点确认：

• host_ip：Jetson 雷达网卡 IP
• lidar_configs[].ip：Mid-360S IP

五、编译 FAST-LIO、Diff-Planner 和工具节点

拉源码：

1
2
3
4

mkdir -p ~/catkin_ws/src
cd ~/catkin_ws/src
git clone --recursive https://github.com/hku-mars/FAST_LIO.git
git clone -b px4_sitl https://github.com/dreamer198/Diff-Planner-PX4.git

更新 FAST-LIO 子模块：

1
2

cd ~/catkin_ws/src/FAST_LIO
git submodule update --init --recursive

适配 livox_ros_driver2：

1
2
3
4
5
6
7

cd ~/catkin_ws/src/FAST_LIO
sed -i -E 's/livox_ros_driver([^2]|$)/livox_ros_driver2\1/g' \
  CMakeLists.txt \
  package.xml \
  src/laserMapping.cpp \
  src/preprocess.cpp \
  src/preprocess.h

补消息依赖：

1
2

grep -q 'add_dependencies(fastlio_mapping' CMakeLists.txt || \
  sed -i '/add_executable(fastlio_mapping/a add_dependencies(fastlio_mapping ${${PROJECT_NAME}_EXPORTED_TARGETS} ${catkin_EXPORTED_TARGETS})' CMakeLists.txt

如果 Mid-360S 相对机体不是水平安装，建议把 FAST_LIO/src/IMU_Processing.hpp 初始化逻辑改成重力对齐版本：

1
2
3
4
5
6
7

state_ikfom init_state = kf_state.get_x();
init_state.grav = S2(V3D(0, 0, -G_m_s2));
Eigen::Quaterniond q_init = Eigen::Quaterniond::FromTwoVectors(mean_acc, V3D(0, 0, 1));
init_state.rot = SO3(q_init.w(), q_init.x(), q_init.y(), q_init.z());
init_state.bg  = mean_gyr;
init_state.offset_T_L_I = Lidar_T_wrt_IMU;
init_state.offset_R_L_I = Lidar_R_wrt_IMU;

当前环境使用两个已调通脚本：

1
2

/root/catkin_ws/src/px4_realflight_tools/scripts/odom_to_base.py
/root/catkin_ws/src/px4_realflight_tools/scripts/odom_to_pose.py

默认安装外参：

1
2
3
4
5
6

MOUNT_X=0.0
MOUNT_Y=0.0
MOUNT_Z=0.10
MOUNT_ROLL_DEG=0.0
MOUNT_PITCH_DEG=30.0
MOUNT_YAW_DEG=0.0

含义：Mid-360S 相对机体前倾约 30 度，高于飞控约 10 cm。

编译：

1
2
3
4
5
6
7
8