Jetson与ROS 2开发底座搭建：移动机器人全栈起步避坑指南

1. 动手之前先想清楚：移动机器人到底需要什么样的“大脑”

做移动机器人全栈开发，我踩过最大的坑就是一开始就埋头刷机、装 ROS 2，结果后面每个传感器都出问题。这台机器人的“大脑”选什么 Jetson、ROS 2 怎么装、开发底座怎么搭，直接决定了你后面写 SLAM、导航和底盘驱动时是顺手还是想砸电脑。尤其是一听说“全栈”就觉得要什么都会，其实真正难的不是算法本身，而是把 JetPack 系统、Ubuntu 环境、ROS 2 中间件、串口和外设驱动一层一层理顺。这篇文章就是整个系列的第一篇，先把大脑和开发底座这套组合拳打明白。

很多新手拿到 Jetson 第一件事是到官网下个镜像，插电开机，然后就开始 pip install 和 apt install，装到一半系统崩了，又从头来。问题就出在“把 Jetson 当普通电脑用”。Jetson 是一块嵌入式超级计算机，它的很多硬件驱动、电源策略、温度控制都绑在 NVIDIA 定制的 JetPack 上，不是随便装个 Ubuntu 就能跑的。所以你首先要做的不是装软件，而是确定你的硬件平台到底适合哪一档 JetPack，这直接连带决定了你后续能用哪个 ROS 2 发行版。又因为 ROS 2 的中间件、工具链、功能包体系复杂度比 ROS 1 高不少，环境搭错了，后面每一个包都会出幺蛾子。

1.1 面对 Jetson 家族，别急着下单

Jetson 家族现在常用的有 Nano、Xavier NX、Orin Nano、Orin NX 这几档，价格从几百到几千，性能差距很大。选型不能只看“越贵越好”，要结合你的机器人任务来定。如果只是做一个用激光雷达避障、能遥控移动的小车，Jetson Nano 4GB 都够用；如果要做视觉 SLAM、实时的目标检测、语义分割，Nano 会比较吃力，Xavier NX 或者 Orin Nano 8GB 是更合适的起点；如果要在车上跑大模型推理、多传感器融合加路径规划，那 Orin NX 16GB 才舒服。

除了核心板，载板质量同样重要。很多便宜载板的供电纹波大、USB 口不隔离，插上电机驱动板或者雷达之后 Jetson 会随机重启，传感器数据乱跳。我建议在选载板前先算好整个小车的功耗：主控算 15W，电机驱动峰值 30W，激光雷达和摄像头加一起 5W，那你至少需要 60W 以上的电源余量。别把一个 5V/3A 的充电头直接当供电核心，经验是“供电不稳，算法全白搭”。另外，老平台比如 Jetson TK1、TX1 这类产品，官方支持基本停止，社区资料也少，串口连接、刷固件的方式和新平台差异很大，不建议再碰，除非你纯粹为了研究硬件。

1.2 为什么是 ROS 2，而不是 ROS 1

在很久以前，移动机器人开源生态几乎是 ROS 1 的天下，但 ROS 1 已经停止维护，新项目再入坑就是给自己挖坑。ROS 2 从底层改了通信机制，默认走 DDS，支持节点发现、QoS 策略、多机通信和实时性更好的执行模型。你现在学 ROS 2，后面用 Nav2、ros2_control、MoveIt2 这些新框架才会顺手。需要注意的是，ROS 2 并不是 ROS 1 的简单升级，很多设计思路变了。比如 ROS 1 里你写一个 publisher 回调，直接 while 循环 spin 就行；ROS 2 里要理解 rclcpp 的 executor、callback group、QoS reliability 这些概念。如果还按旧教程的思维方式写，遇到“消息偶尔收不到”“程序退出不干净”会一头雾水。

ROS 2 发行版和 Ubuntu 版本是绑定的：Ubuntu 20.04 通常用 Foxy，Ubuntu 22.04 用 Humble，Ubuntu 24.04 用 Jazzy。在 Jetson 上还要看 JetPack 版本，JetPack 5.x 对应 Ubuntu 20.04，JetPack 6.x 主要对应 Ubuntu 22.04。所以你的选择顺序是：先确定 Jetson 平台，再刷对应 JetPack，然后根据系统版本来挑 ROS 2。如果条件允许，我推荐直接用 Humble，因为这是目前社区资料最丰富、第三方包兼容性最好的一个版本。

1.3 开发底座包含哪些东西

我理解的“开发底座”不是某一个软件，而是一条完整工具链。从底往上分别是：

• 硬件层：Jetson 核心板、载板、电机驱动、激光雷达、IMU、摄像头、电源供电系统。
• 系统层：JetPack，里面包含了定制 Linux 内核、Ubuntu 根文件系统、CUDA、cuDNN、TensorRT、多媒体驱动。
• 中间件层：ROS 2 和 DDS，负责节点通信、话题服务、参数管理。
• 工具层：SSH、VNC、VS Code Remote、Git、colcon、rosdep，以及后续需要的一键部署脚本。

这些东西单独拿出来都不复杂，但组合在一起时，任何一个环节版本不匹配都会浪费大量时间。比如 JetPack 5 上强行装 Ubuntu 22.04 的 ROS 2 包，apt 依赖就会冲突。所以我建议你把这个开发底座当成一个小型工程来管理，先列清单，再逐步搭建，每完成一步就在笔记本上记录一下。这个习惯会帮你避开很多移动机器人现场调试的灾难。

2. 把系统跑起来：Jetson 刷机与初始配置

2.1 刷机前必须确认的东西

Jetson 刷机看起来只是运行一个工具，实际上很吃环境和线材。我至少见过三次因为 USB 线不对导致刷机失败的情况：普通 USB 线只充电不过数据，插上去 lsusb 看不到设备。所以准备一根原装 Type-C 或 Micro USB 数据线，最好还带屏蔽。主机的系统尽量用 Ubuntu 18.04 或 20.04 的物理机，Windows 下虽然也有驱动方式，但折腾成本高，虚拟机容易出现 USB 抢断。

具体进入刷机模式的方法是：断电，按住板子上的 Recovery 键不松手，接上电源，然后按一下 Reset 键（部分板子没有 Reset，就直接按住 Recovery 再通电）。保持 Recovery 两秒后松开，再用 USB 线连接主机，执行 lsusb 会看到 NVIDIA Corp 的设备，说明进入正常。这时候再打开 NVIDIA SDK Manager 才能识别你的 Jetson。

开始刷机前确认三件事：一是电源是否给足，移动机器人上如果接了大量外设，最好只留核心板和网线；二是主机网络稳定，因为 JetPack 会在线下载组件；三是确认刷机会清空板载存储，如果你手里是一台别人调过的二手机器人，不要抱着“系统还能用”的侥幸，直接从干净状态重建会少很多坑。

2.2 使用 SDK Manager 烧写 JetPack 的完整流程

SDK Manager 是 NVIDIA 官方提供的图形化工具，它会自动下载 JetPack 并烧写到 Jetson 上。安装好后打开，登录 NVIDIA 账号，选择对应的开发套件和 JetPack 版本。接下来几页会让你勾选组件，我建议第一次全部勾上，尤其是 CUDA、cuDNN、TensorRT，后面跑深度学习相关功能时不用再回头补装。

在“Target Hardware”步骤，如果你是 USB 连接，选择 Jetson 设备；如果已经烧写过系统且可通过网络连接，也可以选网线刷写，但第一次尽量用 USB。SDK Manager 会要求你输入 Jetson 上新建用户的信息，也就是最终系统里的用户名和密码，顺便设置一个容易记的，比如 nvidia 和 nvidia，但后续正式使用要改。然后点击 Flash，过程大概持续十几分钟，期间不要碰 USB 线，也不要让主机休眠。

烧写完成后，SDK Manager 还会进入组件安装阶段，它会通过 SSH 连接到 Jetson 安装 CUDA 等组件。这里有一步容易踩坑：如果 Jetson 没有连网，组件安装会失败，所以最好把 Jetson 用网线接在同一个路由器下。组件装完，系统基本可用了，但我不会急着装别的，先做基础验证：打开终端，输入 nvidia-smi，能看到 Jetson 的显卡信息说明 CUDA 驱动正常；输入 jtop（如果安装了）可以看 CPU、GPU 和温度。

我特别想提醒一个高风险操作：网上有很多关于“Orin Nano 更换 QSPI 芯片”来修复 bootloader 的讨论。QSPI 里放的是引导固件，正常情况下你不应该去动它。如果刷机刷到一半变砖，优先查官方文档里的恢复流程，尝试重新进入 recovery 模式再刷，不要一上来就拆机换芯片。这种操作对工具和焊接水平要求极高，普通开发者折腾它纯粹是给自己增加风险。

2.3 开机后第一时间做的系统配置

刚刷完机的 Jetson 是一张“白纸”，我一般是按这个顺序配置：换软件源、装基础工具、开 SSH、设静态 IP、调整电源模式。

Jetson 上的 Ubuntu 是 arm64 架构，软件源地址用的是 ports.ubuntu.com，国内访问不快。我把 apt 源改成清华镜像：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i 's@//ports.ubuntu.com@//mirrors.tuna.tsinghua.edu.cn@g' /etc/apt/sources.list sudo apt update

改完源以后安装这些工具基本够用：

sudo apt install -y vim curl htop net-tools openssh-server terminator git

然后开启 sshd 服务，设置开机自启：

sudo systemctl enable ssh sudo systemctl start ssh

远程开发要用 SSH，但更好用的是密钥登录。本地生成密钥后，把公钥拷贝过去：

ssh-copy-id 用户名@Jetson的IP地址

这样以后不用每次输密码，开发体验会舒服很多。接着设置静态 IP。如果你用有线网，可以通过 nmcli 操作：

nmcli connection show sudo nmcli connection modify "Wired connection 1" ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.method manual sudo nmcli connection up "Wired connection 1"

静态 IP 的重要程度在移动机器人开发里被严重低估。你不可能每次调试都爬到路由器后台查板子的 IP，固定下来之后，SSH、VNC、ROS 2 多机通信都会顺畅很多。Jetson 的默认 swap 通常比较小，需要加大一点，不然编译 ROS 2 功能包时内存很容易爆：

sudo systemctl disable nvzramconfig sudo apt install -y dphys-swapfile sudo nano /etc/dphys-swapfile

把 CONF_SWAPSIZE 改成 2048 或 4096，然后重启服务。最后是电源模式，Jetson 默认可能在低功耗模式，CPU 频率上不去。用 nvpmodel -q 查看当前模式，再改成最大性能模式，配合 jetson_clocks 提升 GPU 频率。但要记住，性能拉满之后发热明显，如果没有主动散热，小车在太阳底下跑一会儿就会降频保护。

3. 安装 ROS 2：从 apt 源到第一个节点

3.1 ROS 2 发行版与 Ubuntu 版本的对应关系

在 Jetson 上装 ROS 2，最关键的是先确认你的 Ubuntu 版本。执行 cat /etc/os-release 看一下系统版本，然后按对应关系选 ROS 2。Ubuntu 20.04 对应 ROS 2 Foxy，Ubuntu 22.04 对应 Humble，Ubuntu 24.04 对应 Jazzy。如果你的 JetPack 是 5.x，系统大概率是 20.04，那就别尝试装 Humble，因为很多依赖包要求更高版本的 glibc 和 Python，会直接劝退。

我见过有人为了装 Humble 强行把系统组件升级，结果底层驱动崩了，最后重刷。这完全是没必要的折腾。ROS 2 发行版的选择并不需要追求最新，Humble 目前是社区支持最好的长期版本，Nav2、ros2_control 等官方框架都能直接安装。Jazzy 是较新的版本，虽然功能更丰富，但部分第三方传感器驱动还没跟上，新手没必要拿自己的小车做实验。

3.2 换源、安装与 rosdep 初始化

安装 ROS 2 的官方流程并不复杂，但如果你走官方源，在 Jetson 上下载可能很慢。我一般先添加 ROS 2 apt 源，再根据网络情况切换到国内镜像。以 Humble 为例，先安装基础依赖：

sudo apt install -y curl gnupg2 software-properties-common sudo add-apt-repository universe

然后导入 ROS 2 的 GPG key：

sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null

如果你的网络拉取 key 超时，可以把 key 文件先从其他机器下载好，再拷贝到 Jetson 上，不建议关闭证书验证。接下来安装 ROS 2：

sudo apt update sudo apt install -y ros-humble-desktop python3-colcon-common-extensions python3-rosdep

ros-humble-desktop 包含了常用的可视化工具和演示包，体积较大，如果你的存储空间紧张，可以先装 ros-humble-ros-base，但后续跑仿真还是得补装。安装完成后，把环境变量写到 bashrc：

echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc source ~/.bashrc

然后初始化 rosdep，这是后面编译第三方包时解决依赖的工具：

sudo rosdep init rosdep update

rosdep 首次 update 需要拉取 rosdistro 数据，如果很慢，可以使用 rosdepc 这类替代命令，或者手动配一个国内镜像源。配置好之后，输入 ros2 --help 能看到 ROS 2 的 CLI 工具，说明环境就位了。

3.3 让你的第一个节点在 Jetson 上跑起来

ROS 2 装好以后，不要急着跑什么高级算法，先写一个发布订阅例程，验证通信链路。我的习惯是创建一个工作空间：

mkdir -p ~/robot_ws/src && cd ~/robot_ws/src ros2 pkg create --build-type ament_python py_pubsub --node-name talker

这会自动生成一个发布者节点框架。打开 src/py_pubsub/py_pubsub/talker.py，改成最简单的循环发布：

import rclpy from rclpy.node import Node from std_msgs.msg import String class Talker(Node): def __init__(self): super().__init__('talker') self.publisher = self.create_publisher(String, 'chatter', 10) self.timer = self.create_timer(1.0, self.timer_callback) self.count = 0 def timer_callback(self): msg = String() msg.data = f'Hello from Jetson: {self.count}' self.publisher.publish(msg) self.get_logger().info(f'Publishing: {msg.data}') self.count += 1 def main(args=None): rclpy.init(args=args) node = Talker() rclpy.spin(node) node.destroy_node() rclpy.shutdown()

再创建一个订阅者包，或者直接手写一个 listener.py 放在同一个包里。编译时用 symlink-install 模式，这样后面改 Python 代码不用反复 build：

cd ~/robot_ws colcon build --symlink-install source install/setup.bash

开两个终端，一个运行 ros2 run py_pubsub talker，另一个运行 ros2 run py_pubsub listener，你会看到话题消息每秒刷一次。然后用 ros2 topic echo /chatter 查看原始数据。

这个过程看起来小儿科，但它确认了 DDS 通信正常、Python 环境正常、colcon 工具链正常。很多机器人在现场不出数据的最终原因，其实是这个最底层环节没打通，后面所有模块都是空中楼阁。

4. 机器人的手脚与感知：串口、摄像头与远程调试

4.1 串口通信与权限处理

移动机器人离不开底盘和传感器，而底盘大多数情况下都用串口、CAN 或者 USB 转串口来控制。Jetson 上查串口设备很简单：

ls -l /dev/ttyUSB* dmesg | tail

插上 USB 转串口模块后，系统会生成 ttyUSB0 或 ttyUSB1。第一次打开经常会遇到 Permission denied，这是因为当前用户不在 dialout 组。把用户加进去，然后重新登录：

sudo usermod -aG dialout $USER

测试串口最简单的方式是用 minicom：

sudo apt install -y minicom minicom -D /dev/ttyUSB0 -b 115200

如果你的底盘是轮式差速，协议通常包含帧头、地址、控制字、左右轮速度、校验和等字段。我建议先用 Python 的 pyserial 写一个简单的发送函数，养成“先读返回帧再发下一条”的习惯：

import serial ser = serial.Serial('/dev/ttyUSB0', 115200, timeout=0.5) cmd = bytes.fromhex('AA 55 01 03 00 64 00 00 00 64 00 00 00 00') ser.write(cmd) resp = ser.read(64) print(resp.hex())

串口接线看起来简单，但最容易载跟头的是电气问题：TTL 电平不能直接接 RS232，需要电平转换芯片；VGA 那种旧接口更不用提，跟机器人串口完全不是一回事。接线时要保证传感器和 Jetson 共地，否则偶尔能收到乱码；插拔线材时最好断电，不然容易烧坏串口芯片。

更实用的技巧是给串口写 udev 规则，固定设备名。这个真的太重要了。你的底盘模块可能时而被识别成 ttyUSB0，时而又变成 ttyUSB1，代码里如果写死就会找不到设备。先查看设备信息：

udevadm info -a -n /dev/ttyUSB0

找到 idVendor 和 idProduct 后，新建 /etc/udev/rules.d/99-robot.rules，内容类似：

SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="chassis"

然后执行 sudo udevadm control --reload-rules，重新插拔设备，之后 /dev/chassis 就稳定指向底盘了。如果你有多个传感器，也建议分别建立射频头、雷达、IMU 的固定符号链接，这会让后续的驱动代码清爽很多。

4.2 摄像头接入与图像可视化

摄像头是移动机器人感知的主力。USB 摄像头最省事，基本免驱，插上就能在 /dev/video0 看到。CSI 摄像头或者 GMSL 车载摄像头则需要 Jetson 专用的驱动和线材，不是所有载板都支持。我的原则是第一步先用 USB 摄像头打通整条链路，再去折腾高带宽的 GMSL。

检查摄像头设备：

sudo apt install -y v4l-utils v4l2-ctl --list-devices

使用 ROS 2 的 v4l2 驱动包直接拉起图像：

sudo apt install -y ros-humble-v4l2-camera ros2 run v4l2_camera v4l2_camera_node --ros-args -p video_device:=/dev/video0

在另一个终端运行 rqt_image_view，选择 /image_raw 话题就能看到画面。如果画面很卡或者报错，多半是摄像头输出的分辨率和帧率太高，可以在参数里改成 640x480 和 15 帧。不要一开始就追求 4K 图像，那是后续标定和算法阶段才考虑的事。

对于 GMSL 摄像头，驱动的安装顺序通常要看厂商手册。GMSL 走的是同轴电缆，传输距离远，适合装在车体四周，但它不是标准 UVC 设备，Jetson 上需要加载特定的内核驱动。遇到这种摄像头，先跑厂商给的测试工具，确认出图以后再接 ROS 2，不要跳过这一步。

4.3 远程开发：SSH / VNC / 代码同步

Jetson 板子放到机器人上之后，不可能每次都接显示器和键盘。远程开发必要的三件套是 SSH、VNC、代码同步工具。SSH 是最基本的，装好 openssh-server 之后，局域网内就能连：

ssh 用户名@192.168.1.100

为了调试方便，我推荐 VS Code 的 Remote-SSH 插件，直接在本地 IDE 里打开 Jetson 的文件夹，能实时编辑代码和运行终端命令。这样做的好处是代码保留在板子上，不需要同步，修改后立刻能编译。如果觉得 VS Code 远程对板子内存压力大，也可以继续用终端加 rsync：

rsync -avz --delete ./ 用户名@192.168.1.100:~/robot_ws/

图形界面用 VNC 也很常见，Ubuntu 桌面版可以直接安装 x11vnc 或 TigerVNC。VNC 适合偶尔看一眼桌面，不适合跑重负载程序。因为 VNC 传输的是压缩后的屏幕帧，一旦启动 RViz 这种大型图形程序，画面会非常卡，这时候用 SSH 命令行反而更有效。ROS 2 的日志和话题数据都可以在终端看，不需要频繁开图形界面。

4.4 工作空间与软件包组织

当你的 robot_ws 里开始出现一堆自定义功能包时，合理的组织方式就很重要了。ROS 2 的标准结构是 src 放源码，build 放编译中间文件，install 放安装产物，log 放日志。src 下每个功能包要职责单一，比如 chassis_driver、lidar_node、camera_node、slam_nav，不要把所有代码堆在一个 package 里。移动机器人涉及多个传感器，包之间通过 ROS 2 话题解耦最好。

用 Git 做版本管理，并且把 build、install、log 目录加到 .gitignore，避免把编译产物传到仓库。每次改动前先 commit，出问题方便回滚。我还会在工程根目录放一个 setup.sh，把配置环境变量、编译、source install 这些步骤集中起来。这样即使板子系统重装，也能快速恢复。

如果你熟悉 Docker，可以在 Jetson 上用 NVIDIA 提供的容器镜像统一开发环境，但对于移动机器人，我不建议新手一开始就容器化，因为多个传感器设备映射、通信网络、GPU 使用权限都会增加理解负担。先把裸机环境跑通，再考虑用 Docker 固化环境。

5. 常见问题与排查技巧实录

5.1 JetPack 刷机卡死与存储芯片风险

刷机最让人崩溃的，莫过于烧到一半进度条不动。我遇到过的原因有 USB 线质量差、主机系统休眠、电源供电不稳。排查时可以拔掉 Jetson 上除了电源和 USB 之外的所有外设，换一个主机背后的 USB 口，重新进入 recovery 模式再试。如果 SDK Manager 反复识别不到，检查 lsusb，没有 NVIDIA 设备就说明没进入刷机模式。

刷完以后无法开机的常见原因是电源功率不够。Jetson 启动瞬间电流很大，移动机器人上如果同时接了电机驱动板、显示器、多个 USB 扩展坞，很容易把电压拉垮。先把一切外设拔掉，只留原装电源和网线，如果能开机再逐步加外设。

网上一些关于“更换 QSPI 芯片恢复引导”的操作，我不建议普通开发者尝试。QSPI 存储固件的损坏通常由错误的刷机操作引起，恢复路径应该是重新进入 recovery 模式，用官方工具烧写完整的 bootloader，而不是焊芯片。等你真正需要换芯片时，那已经不是软件问题，而是硬件返修级别的工作了。与其冒险，不如做一次系统备份。SDK Manager 支持生成系统镜像，也可以自己 dd 一块好的 eMMC/NVMe 到移动硬盘，后面出问题直接恢复。

5.2 开机没有 WiFi 的几种可能

Jetson 开机后发现没有 WiFi，有几种常见可能：天线没有接好、驱动没加载、NetworkManager 没启用、国家码不对、所在位置 5G 频段不支持。排查从最底层开始：

nmcli dev status nmcli radio wifi rfkill list

如果 rfkill 显示 blocked，用 rfkill unblock all 解开；看到网络设备状态 ok，但还是扫不到热点，就检查天线。有些核心板的天线接口很小，只有指甲盖大，接触不良或者扣反了都会导致无信号。迫不得已时可以先用网线联网，再安装或重装无线驱动。国家码也会影响部分频段，特别是在国内使用 5G WiFi 时，把国家码设置成 CN：

sudo nmcli con mod "你的WiFi连接名" wifi.country CN sudo nmcli con up "你的WiFi连接名"

如果你在 Jeston 上同时插着 USB 无线网卡和板载 WiFi，注意系统默认会选哪个设备。我通常直接把板载 WiFi 禁用，用一个外置双频网卡，驱动稳定，信号也好一些。

5.3 VNC 黑屏与画面卡顿

配置完 VNC 一连接就是黑屏，这种问题十有八九是桌面会话启动脚本的问题。在使用 startx 方式启动 VNC 时，~/.vnc/xstartup 里要正确启动桌面环境。对于 JetPack 的 Ubuntu，配置大概是：

#!/bin/sh unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources startxfce4 &

保存后重启 VNC 服务。卡顿的问题则多为编码方式不对，调低分辨率，关闭桌面特效，或者直接用 NoMachine 这类基于 NX 协议的远程工具，画面流畅度会好很多。但不管怎样，远程跑 RViz 这类 OpenGL 应用，VNC 都不是好选择。真正的图像数据应该通过 ROS 2 话题传输，再用本地主机上的 RViz 订阅，这也是我调试时最常用的方案。

5.4 ROS 2 节点互相看不到

在单机环境下，话题通信一般不会出错。但如果你有一台 Jetson 和一台 PC，想通过 ROS 2 多机通信，最常出现的问题就是节点互相发现不了。先确认两边 ROS 2 版本一致，再看环境变量：

echo $ROS_DOMAIN_ID echo $RMW_IMPLEMENTATION

ROS_DOMAIN_ID 不一致，节点就属于两个“世界”，肯定看不到。RMW 实现也必须一样，一个用默认的 Fast DDS，一个用 Cyclone DDS，发现机制都变了。如果这些都正常，检查两台机器是否在同一网段。DDS 默认走 UDP 多播发现，跨网段或者交换机禁用了多播就会失败。简单做法是把 Docker 网段限制去掉，或者用有线直连同一个路由器。更稳定的方案是安装 Cyclone DDS，并配置指定网络接口：

sudo apt install -y ros-humble-rmw-cyclonedds-cpp export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

在 /etc/cyclonedds/cyclonedds.xml 里设置一个确定性网络接口和 peer 地址，多机通信会可靠很多。最后一个小习惯：当节点状态异常时，重启 ROS 2 daemon：

ros2 daemon stop ros2 daemon start

这个操作能解决很多“明明节点在跑但 list 看不到”的灵异问题。

走到这里，你已经有了一个能刷机、能跑 ROS 2、能连串口和摄像头的 Jetson 开发底座。我个人仍会建议拿个笔记本把所有命令和参数记录下来，尤其是串口设备名、网络配置和 ROS 源。真到了现场调试，这些记录比什么都管用。下一篇我会继续写底盘驱动和里程计，欢迎把它搭建底座时踩过的坑发在评论区，我尽量帮你看。