如果你打算从零攒一台能自己跑起来的移动机器人第一时间涌上来的问题大概率不是“用哪个激光雷达”而是“用什么当它的脑子”。这个选择直接影响后续的算法部署、传感器接线、甚至整车的电源设计。第一篇我就想聊这一步从 Jetson 到 ROS 2把机器人的“大脑”和开发底座搭起来。这套内容适合两类人——一类是从没碰过机器人但会写代码、想快速入门的开发者另一类是已经在折腾底盘和传感器、被驱动问题和环境冲突劝退的硬件党。看完你会明白为什么绝大多数移动机器人项目会选 Jetson 当主控以及从刷机到 ROS 2 环境再到远程开发、硬件预留这条底座链路到底该怎么一步步落地。我见过太多机器人项目死在“入手第三周”板子买回来了系统刷好了WiFi 连不上ROS 2 装到一半依赖冲突最后连个话题都没跑通就搁置了。这些坑其实都能提前避开关键是把底座当成一个正经工程来对待而不是“反正确认系统能开机就算完”。1. 先想清楚机器人“大脑”在整机里到底负责什么1.1 移动机器人对主控的真实需求长什么样移动机器人不是一台普通电脑装上轮子就能跑。它的主控要同时处理几路完全不同的数据流激光雷达每秒数万点的扫描数据、相机每一帧图像、IMU 的六轴姿态数据、底盘发回的里程计和编码器值。这些数据到了主控之后还要被 SLAM 算法、路径规划、避障逻辑轮流消化最终生成一个转向或调速指令发回底盘。也就是说主控的定位是“感知 决策”而电机的电流环、速度环这类毫秒级实时控制通常不应该由它直接干。这背后有一个很实际的物理原因Linux 系统本身不是硬实时系统进程调度、网络中断、GPU 运算都会带来不确定的延迟。如果你让主控直接通过 GPIO/PWM 去驱动电机一旦系统被某个视觉算法占满轮子转速就会抖动甚至是灾难性的失控。所以理性拆解下来一台移动机器人对主控的需求其实是四层算力层能跑得动 SLAM、路径规划、目标检测这类算法尤其是相机或点云处理最好有 GPU 或 NPU 加速。生态层能跑 Linux、能方便装驱动、能兼容 ROS/ROS 2 的通信框架。外设层自带或容易扩展串口、USB、I2C、SPI、CAN 等接口方便接激光雷达、轮式编码器、IMU。功耗与体积机器人是电池供电的移动设备动辄 100W 的桌面主机显然不合适板子体积也要能塞进底盘或上层支架。这四个条件同时满足可选范围就窄很多了。1.2 Jetson 为什么能站在那个“平衡点”上把候选平台摊开对比结论很直观。树莓派生态成熟、功耗低但 GPU 算力非常有限跑轻量视觉算法都费劲更别说实时处理深度相机的点云Intel NUC 算力强、x86 软件兼容好但体积和功耗都不友好机器人本体还得再配一个大容量电池STM32 这类单片机负责底层的电机控制没问题但当“大脑”算力完全不够连浮点矩阵运算都吃力。Jetson 恰好站在平衡点上——它有 NVIDIA GPU 提供并行算力跑 CUDA 加速的视觉和深度学习框架是天然优势同时它本身是一台完整的 Linux 电脑USB、GPIO、串口、SPI、I2C 全都具备接激光雷达、摄像头、IMU 都很顺手。再往深一层说Jetson 还有一个很隐蔽的优势它的 JetPack 软件栈是 NVIDIA 官方维护的从内核到 CUDA 库、TensorRT、OpenCV 的预编译版本都打包在一个镜像里。做机器人开发时最痛苦的不是写算法而是“装环境”而 JetPack 至少把最底层那一层帮你对齐了。这也是我后来坚持用 Jetson 而不是“任意一台 x86 笔记本放车上”的原因——桌面系统的驱动分散、内核版本和 CUDA 版本经常打架在移动机器人这个场景里纯属自找麻烦。当然Jetson 不是万能药。它不适合直接驱动大功率电机不适合硬实时任务也不适合连续高负载推理而不加散热模块。但这些短板可以通过“分层架构”补掉Jetson 负责大脑底层用单片机做执行两层之间用串口或 CAN 通信。这种架构在工业机器人、AGV、自动驾驶测试车里都是标配也是全栈开发最值得先建立的整体认知。2. 具体选型Nano、Xavier NX、Orin Nano 按什么逻辑挑2.1 主流 Jetson 模组的一页纸对比Jetson 家族隔两年更新一次很多新手上来就懵Nano、Xavier NX、Orin Nano、Orin NX到底买哪个我的建议是先把参数表压成一页纸看模组算力参考FP16/密集型内存典型功耗适合场景Jetson Nano 4GB约 472 GFLOPS4GB LPDDR45W~10W入门学习、简单视觉、串口/IO 调试Jetson Xavier NX 8GB约 21 TOPS8GB LPDDR4x10W~20W激光 SLAM、深度相机、移动机器人导航Jetson Orin Nano 8GB约 20 TOPS密集8GB LPDDR57W~25W入门到中级、轻量视觉、边缘 AIJetson Orin NX 16GB约 50 TOPS密集16GB LPDDR510W~25W多传感器融合、端侧大模型部署、复杂导航需要说明的是表中数据是官方公开资料的参考值NVIDIA 在不同 JetPack 版本下对算力的标注方式不一样有密集算力和稀疏算力两种口径所以不要拿这个表去跑分 PK重点看量级和定位。更关键的其实是第二条内存和功耗决定了你能同时跑多少个节点。2.2 按“你要做哪类项目”来倒推配置选型号不要从预算出发要从“项目最重的那个算法”往回推。如果你只是想学习 ROS 2 通信、写写底层驱动、跑跑 turtle 模拟器那 Jetson Nano 的算力其实都够用它最大的问题是内存小开个 RViz2 再跑个点云可视化就容易卡。想做激光雷达 视觉融合至少得 Xavier NX 或 Orin Nano 8GB这两个模组能流畅跑 Cartographer、Nav2也能在本地部署 YOLO 类检测模型。想上多线激光雷达、双相机、端侧跑大模型或检测网络那就直接考虑 Orin NX 16GB留给以后扩展的余地大得多。还有一个经常被忽略的维度开发调试时的“主观体验”。算力刚好够用的板子编译一个 workspace 可能要好几分钟跑起来风扇狂转热得烫手。全栈开发本来就是一个反复修改、编译、重启的过程机器性能多吃紧人的耐心就多受罪。我实际用下来Orin Nano 8GB 做车规级以外的中小型机器人项目已经属于“舒服”的起点预算允许直接上 Orin NX也不会后悔。2.3 二手板、QSPI 固件与渠道安全的提醒因为 Jetson 模块价格不低市场上会有二手、拆机、改装过的开发套件流通。新人很容易被“便宜两百块”吸引结果买回来遇到两个经典问题一是系统引导彻底坏了开机黑屏、连 Recovery 模式都没反应二是某些商家因为搞坏了引导芯片试图通过更换板载 QSPI Flash 芯片来修复普通用户拿到这种板子几乎没法自检。QSPI 芯片在 Jetson 开发套件里存放的是最底层的 bootloader 固件正常使用完全不需要用户折腾它。所以这里给出一个非常实际的建议新手阶段尽量买正规渠道的全新开发套件或官方整机系统选择官方 Jetson 镜像。省下来的那几百块大概率会在后续“刷机刷不进去”“开机无显示”的排查中被加倍浪费掉。如果确实想玩二手至少问清楚能否进 Recovery 模式能否显示 JetPack 版本号烧录时的串口日志是否完整这些问题比成色和价格重要得多。3. 从刷机到点亮JetPack 的两种路线与两个经典坑3.1 第一次刷机SDK Manager 和 SD 卡镜像怎么选Jetson 刷系统有两条主流路线。第一条是用 NVIDIA SDK Manager在另一台 x86 Ubuntu 主机上安装通过 USB-C 线连接 Jetson把板子切换到 Recovery 模式然后把 JetPack 整套刷进去。这条路线适合你想定制组件、或者需要安装 CUDA/ cuDNN / TensorRT 的精确版本时使用缺点是需要额外一台 Ubuntu 主机过程也相对繁琐新手在“进入 Recovery 模式”这一步就可能卡住要在开发套件上按住 Recovery 按键再插电不同型号按键位置不同稍不留神就刷了个寂寞。第二条路线对新手友好得多直接下载官方 SD 卡镜像比如 JetPack 5.1.x 或 6.x 对应的 SD Card Image用 balenaEtcher 或者 dd 命令把镜像写入一张 64GB 以上的 microSD 卡插入开发套件直接开机。这个流程不需要额外电脑不需要进 Recovery 模式第一次点亮系统的成功率最高。系统起来之后再把根文件系统迁移到 NVMe SSD 上如果板子支持启动速度和读写性能会比 SD 卡舒服不少。我个人的建议是第一周先用 SD 卡镜像把系统跑起来把 WiFi、ROS 2、SSH 都验证一遍然后再考虑要不要折腾 NVMe 启动。很多新手一步到位想用 SDK Manager 定制刷机结果卡在组件选择和参数配置上反而把“底座”阶段拉长到好几周完全没必要。3.2 开机没有 WiFi硬件、网络管理器与临时联网手段“Jetson 开机没有 WiFi”这个关键词几乎伴随每一个新手阶段我自己第一次开机也撞上了。先别急着重刷系统按顺序排查。第一步看硬件。Jetson 开发套件的 WiFi 天线接口非常小出厂时如果天线没有牢固拧紧或者金属触点没有完全接触信号强度会低到系统显示“找不到无线网络”。我见过一个案例用户折腾了一个下午最后发现只是天线没装好。用手机开热点靠近板子如果热点可见但信号弱大概率是天线问题。第二步看系统网络管理器。JetPack 默认的 Ubuntu 桌面在某些版本里不会自动弹出 WiFi 面板此时可以用nmcli命令手动连接nmcli device status nmcli dev wifi list nmcli dev wifi connect 你的WiFi名 password 你的密码如果nmcli提示找不到无线设备再检查是不是 NetworkManager 服务没起来或者系统里压根没装对应的无线网卡固件。这一步其实比前面更常见JetPack 精简镜像默认不启用 NetworkManager 的 WiFi 管理桌面右上角自然就没有 WiFi 图标。第三步如果以上都正常但你就是急需联网可以先插一根 USB 网线转接器或者直接用手机 USB 共享网络。手机通过数据线接到 Jetson在手机设置里打开“USB 网络共享”Linux 会直接出一个 usb0 网卡至少能保证立刻上网装包。这个方法在前期调试里非常管用完全不需要依赖无线网络的稳定性。3.3 没有屏幕时的串口调试兜底方案开发套件不一定随时接着显示器尤其机器人装起来之后主控可能被塞在底盘里。这时候一条 USB-TTL 串口线就是你的“最后一道眼睛”。Jetson 的 40-pin 排针上通常引出了 UART0其中 TX 接转接板的 RXRX 接 TXGND 必须共地。系统起来后设备节点一般是/dev/ttyTHS0或/dev/ttyS0在另一台电脑上用一个串口工具连上去就行sudo apt install screen ls /dev/ttyUSB* sudo screen /dev/ttyUSB0 115200看到L4T Console和登录提示说明串口通了。这套思路哪怕是十年前的老 Jetson TK1 也一样适用嵌入式 Linux 的调试逻辑从来没大变过GUI 会崩、网络会断、SSH 可能连不上但串口只要线接对了总能给你吐日志。平时我把串口当作“备用诊断口”常年插着只有等系统稳定到不需要看内核日志了才会拔掉。4. 把 ROS 2 装成底座版本、DDS 与第一轮通信验证4.1 先看 JetPack 再选 ROS 2 版本ROS 2 的版本和 Ubuntu 版本绑定得很死而 JetPack 又直接决定 Ubuntu 版本所以这条对应链必须记牢Jetson 上 JetPack 5.x 对应 Ubuntu 20.04适合安装 ROS 2 FoxyLTSJetPack 6.x 对应 Ubuntu 22.04适合安装 ROS 2 HumbleLTS。不要跨版本硬装跨版本要么没有预编译包要么会遇到一堆 ABI 冲突。这里我遇到过一个很现实的问题很多教学视频还在讲 ROS 1 时代的老流程告诉你apt install ros-melodic-desktop但 ROS 1 已经停止维护新项目完全没有理由再入坑。ROS 2 的节点通信模型一开始可能不习惯但它解决的是 ROS 1 单机主节点的痛点多机通信、DDS 动态发现、生命周期管理都更适合移动机器人这种“设备在动”的场景。如果你所在团队没有历史 ROS 1 包袱直接 Humble 起步是最优解。4.2 安装与初始化不要跳过 source 和 bashrcROS 2 官方给的是 apt 安装方式在 Jetson 的 Ubuntu 上同样适用。先加 ROS 2 软件源和密钥然后安装桌面版或基础版。桌面版ros-humble-desktop包含 RViz、Gazebo、demo 节点适合开发调试如果做纯机器人部署装ros-humble-ros-base就够。sudo apt update sudo apt install curl gnupg lsb-release 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 $(source /etc/os-release echo $UBUNTU_CODENAME) main | sudo tee /etc/apt/sources.list.d/ros2.list /dev/null sudo apt update sudo apt install ros-humble-desktop装完第一件事把环境变量写进~/.bashrcecho source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc这个步骤看着简单但很多人漏了导致每次打开终端都要手动source一遍还总怀疑“是不是没装成功”。ROS 2 的环境变量和系统环境变量是两套体系setup.bash负责把ros2、colcon这些命令路径以及共享库路径加载进来不写进 bashrc 的话新建终端就找不着命令。验证安装是否正常最快的方式是跑一对 talker 和 listenerros2 run demo_nodes_py talker ros2 run demo_nodes_py listener终端 A 在发 Hello World 计数终端 B 在收数据说明通信管道已经通了。这一步跑通了“ROS 2 底座”才算真正成立。4.3 DDS 切换无线环境下最容易踩的发现延隔ROS 2 底层默认使用基于 DDS 的实时通信协议。JetPack 上默认的 DDS 实现是 Eclipse Fast DDS之前叫 Fast RTPS功能完整但有一个实际体验问题在 WiFi 网络环境里节点之间的自动发现经常出现延迟一个节点启动后另一个节点需要等几十秒才能在ros2 topic list里看到甚至偶尔直接发现不了。这个问题在移动机器人场景特别明显因为车上的 Jetson 通常通过 WiFi 和上位机、其他传感器通信网络广播和组播在无线环境下不像有线那么可靠。我的处理方法是切换到 Cyclone DDS它默认的发现机制更简洁节点启动速度在弱网环境下有明显改善。sudo apt install ros-humble-rmw-cyclonedds-cpp echo export RMW_IMPLEMENTATIONrmw_cyclonedds_cpp ~/.bashrc source ~/.bashrc切换完成后重复跑一次talker / listener你会发现节点发现的响应变快了。需要提醒的是同一个机器人系统里所有节点必须使用同一种 DDS 实现否则通信会直接失败官方给的RMW_IMPLEMENTATION环境变量必须所有机器统一设置。5. 远程开发组合SSH 为主VNC 为辅IP 固定是底线5.1 SSH 免密与基础操作机器人装起来之后你不可能每次调试都搬个显示器跟着车跑SSH 是远程开发的第一件工具。登录终端ssh 用户名机器人IP第一次连接会提示确认主机指纹回车输入密码即可。但天天输密码太烦配置一把 SSH 公钥一劳永逸# 在开发机上执行 ssh-keygen -t ed25519 ssh-copy-id 用户名机器人IP之后登录就不需要密码了。这一步对后续全栈开发非常关键因为你后续大概率会写脚本自动同步代码、自动colcon build免密是这些自动化流程的前提。5.2 固定 IP 和主机名多设备协作的隐形效率移动机器人调试时经常遇到一个问题开发机的 DHCP 给车上的 Jetson 分了一个 IP第二天重启变成另一个 IP你所有脚本里的 IP 白瞎了。所以固定 IP 不是“可选项”而是开发效率底线。最简单的方式是在路由器后台给 Jetson 开 DHCP 静态绑定让 MAC 地址始终拿到同一个 IP。如果没有路由器管理权限就直接改 netplan# /etc/netplan/01-netcfg.yaml network: version: 2 renderer: NetworkManager ethernets: eth0: dhcp4: no addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 192.168.1.1IP 地址、网关、DNS 要按你实际路由器网段改改完执行sudo netplan apply。同时建议给板子起一个独立主机名sudo hostnamectl set-hostname mobile-robot有了主机名和固定 IP你在 SSH、VNC、后续多机 ROS 2 通信里就不容易点错设备。多台机器人同时调试的时候这一步能救命的。5.3 VNC 桌面什么时候装、怎么装、性能注意SSH 适合命令操作但机器人开发经常需要看图形界面RViz2 里的点云、RQT 的节点图、摄像头的实时画面。这些都是 GUI 程序光靠 SSH 看不到。这时可以给 Jetson 装一个 VNC 服务最简单的是 x11vncsudo apt install x11vnc x11vnc -forever -shared -passwd 你的密码 -display :0然后在开发机上用任意 VNC 客户端连接机器人IP:5900。这样你在没有显示器的情况下也能看到 JetPack 桌面上正在跑的 RViz2 窗口摄像头调试、URDF 可视化都会方便很多。但注意一点VNC 是通过网络传图形帧带宽占用高操作延迟明显。不要依赖 VNC 去跑实时导航或者大算力任务它只适合“偶尔瞄一眼界面”和“短时图形调试”。机器人正式跑任务时建议关掉 VNC 服务把系统资源留给算法和传感器驱动。如果你觉得 VNC 延迟太大、画面撕裂严重可以试试 NoMachine它用 NVIDIA 的编码加速在 Jetson 上能流畅不少但本质还是“远程看屏幕”不是“远程高性能计算”。6. 把底座接到硬件电气链路上的几个关键理解6.1 底盘控制并不该由 Jetson 直接负责很多第一次做机器人的朋友会问我能不能直接用 Jetson 的 GPIO 发 PWM 给电机驱动板省掉单片机答案是能但非常不推荐。Linux 非实时、GPIO 抖动大、一旦主控死机电机就失去控制这在移动机器人上是不可接受的。成熟的架构是三层Jetson 负责感知决策通过串口或 CAN 下发期望速度中间的单片机负责 PID 闭环和电机驱动电机编码器数据再通过单片机回传到 Jetson 供里程计使用。实际操作中Jetson 与底层单片机之间最常见的通信方式有两种。串口简单数据结构自己定义开发快适合原型验证CAN 总线抗干扰、支持多节点、传输距离远适合正式产品。不管用哪种通信协议里一定要包含期望速度、转向角、使能/急停指令、底盘状态回传、编码器原始值这五类信息基本覆盖了移动机器人底盘的通信需求。6.2 读电气原理图时的四类必查信息市面上很多移动机器人开发套件会随箱附赠底盘电气原理图或者你从网上搜“移动机器人电气原理图”也能找到大量开源图纸。拿到一张图先不要从头读按四个方向去找关键信息。第一是供电链路电池电压进来到哪个 DC-DC 降压分出多少路电源轨Jetson 的供电是先经过稳压模块还是直接接电源板这个决定了你加传感器时会不会拉垮主控。第二是通信链路哪些串口连了哪些设备CAN 总线上挂了几片控制板有没有共地问题。第三是电平转换单片机侧是 3.3V 还是 5VJetson 的 GPIO 是 3.3V互相连接时是否经过电平转换接错就可能烧 IO。第四是保护电路有没有反接保护、限流、EMI 滤波移动机器人电机一启动电源上的毛刺经常导致单片机重启原理图里如果是“裸连”后期就得自己加滤波电容。读图的目的是建立“故障排查路线图”机器人某个传感器不工作你应该能根据原理图判断这条信号链路经过了哪些器件而不是拿万用表到处乱戳。6.3 给后续全栈功能预留的接口习惯底座搭得好的标准不是今天能跑起来而是接下来加功能时不返工。基于我的经验有三件事值得在初期预留好一是传感器和底盘的数据接口用 ROS 2 标准消息格式比如底盘回调用nav_msgs/Odometry、激光雷达用sensor_msgs/LaserScan或PointCloud2这样后面接 Nav2、Cartographer 就是改参数而不是改代码二是建立一个明确的 workspace 结构至少区分src、build、install、log四个目录用colcon build统一管理所有功能包三是在一开始就把“传感器热插拔”视为常态每个传感器用独立串口或 USB 设备节点并在启动脚本里做好设备节点丢失的容错因为移动机器人运行中最常见的故障就是某个 USB 摄像头掉线、某个雷达没插紧。最后分享一点我的个人体会如果你第一次搭 Jetson 上的 ROS 2 环境我劝你克制住“把能装的库都装一遍、把能配的软件都配上”的冲动。我踩过最深的坑就是一开始把 VNC、SSH、SDK Manager、多套 CUDA 版本、无敌的网络代理配置全挤在一块结果任何一个组件更新都可能把另一个环境搞坏。全栈开发讲究的是一个“可用基线”JetPack 版本固定ROS 2 版本固定机器人在局域网里的 IP 固定远程开发方式固定剩下的功能模块再往这条基线上加。每次加完新东西先从 talker/listener 通信验证开始再跑真实硬件。底座搭起来之后移动机器人真正的“体力活”才刚开始——底盘驱动、传感器标定、SLAM 建图、导航避障这些都是后续系列要拆开细聊的内容。下一篇我打算接着写“底盘驱动与 ROS 2 控制”把单片机、编码器、串口协议和ros2_control之间的那层关系说透。如果你也正在搭自己的机器人底座欢迎把你在刷机、WiFi、ROS 2 安装上遇到的问题留在评论区这些问题也是系列后续内容的最佳选题。 
长河君 · 2026/10/30 1:02:23 · 阅读 1.2k 从Jetson到ROS 2：搭建移动机器人开发底座的完整指南
如果你打算从零攒一台能自己跑起来的移动机器人第一时间涌上来的问题大概率不是“用哪个激光雷达”而是“用什么当它的脑子”。这个选择直接影响后续的算法部署、传感器接线、甚至整车的电源设计。第一篇我就想聊这一步从 Jetson 到 ROS 2把机器人的“大脑”和开发底座搭起来。这套内容适合两类人——一类是从没碰过机器人但会写代码、想快速入门的开发者另一类是已经在折腾底盘和传感器、被驱动问题和环境冲突劝退的硬件党。看完你会明白为什么绝大多数移动机器人项目会选 Jetson 当主控以及从刷机到 ROS 2 环境再到远程开发、硬件预留这条底座链路到底该怎么一步步落地。我见过太多机器人项目死在“入手第三周”板子买回来了系统刷好了WiFi 连不上ROS 2 装到一半依赖冲突最后连个话题都没跑通就搁置了。这些坑其实都能提前避开关键是把底座当成一个正经工程来对待而不是“反正确认系统能开机就算完”。1. 先想清楚机器人“大脑”在整机里到底负责什么1.1 移动机器人对主控的真实需求长什么样移动机器人不是一台普通电脑装上轮子就能跑。它的主控要同时处理几路完全不同的数据流激光雷达每秒数万点的扫描数据、相机每一帧图像、IMU 的六轴姿态数据、底盘发回的里程计和编码器值。这些数据到了主控之后还要被 SLAM 算法、路径规划、避障逻辑轮流消化最终生成一个转向或调速指令发回底盘。也就是说主控的定位是“感知 决策”而电机的电流环、速度环这类毫秒级实时控制通常不应该由它直接干。这背后有一个很实际的物理原因Linux 系统本身不是硬实时系统进程调度、网络中断、GPU 运算都会带来不确定的延迟。如果你让主控直接通过 GPIO/PWM 去驱动电机一旦系统被某个视觉算法占满轮子转速就会抖动甚至是灾难性的失控。所以理性拆解下来一台移动机器人对主控的需求其实是四层算力层能跑得动 SLAM、路径规划、目标检测这类算法尤其是相机或点云处理最好有 GPU 或 NPU 加速。生态层能跑 Linux、能方便装驱动、能兼容 ROS/ROS 2 的通信框架。外设层自带或容易扩展串口、USB、I2C、SPI、CAN 等接口方便接激光雷达、轮式编码器、IMU。功耗与体积机器人是电池供电的移动设备动辄 100W 的桌面主机显然不合适板子体积也要能塞进底盘或上层支架。这四个条件同时满足可选范围就窄很多了。1.2 Jetson 为什么能站在那个“平衡点”上把候选平台摊开对比结论很直观。树莓派生态成熟、功耗低但 GPU 算力非常有限跑轻量视觉算法都费劲更别说实时处理深度相机的点云Intel NUC 算力强、x86 软件兼容好但体积和功耗都不友好机器人本体还得再配一个大容量电池STM32 这类单片机负责底层的电机控制没问题但当“大脑”算力完全不够连浮点矩阵运算都吃力。Jetson 恰好站在平衡点上——它有 NVIDIA GPU 提供并行算力跑 CUDA 加速的视觉和深度学习框架是天然优势同时它本身是一台完整的 Linux 电脑USB、GPIO、串口、SPI、I2C 全都具备接激光雷达、摄像头、IMU 都很顺手。再往深一层说Jetson 还有一个很隐蔽的优势它的 JetPack 软件栈是 NVIDIA 官方维护的从内核到 CUDA 库、TensorRT、OpenCV 的预编译版本都打包在一个镜像里。做机器人开发时最痛苦的不是写算法而是“装环境”而 JetPack 至少把最底层那一层帮你对齐了。这也是我后来坚持用 Jetson 而不是“任意一台 x86 笔记本放车上”的原因——桌面系统的驱动分散、内核版本和 CUDA 版本经常打架在移动机器人这个场景里纯属自找麻烦。当然Jetson 不是万能药。它不适合直接驱动大功率电机不适合硬实时任务也不适合连续高负载推理而不加散热模块。但这些短板可以通过“分层架构”补掉Jetson 负责大脑底层用单片机做执行两层之间用串口或 CAN 通信。这种架构在工业机器人、AGV、自动驾驶测试车里都是标配也是全栈开发最值得先建立的整体认知。2. 具体选型Nano、Xavier NX、Orin Nano 按什么逻辑挑2.1 主流 Jetson 模组的一页纸对比Jetson 家族隔两年更新一次很多新手上来就懵Nano、Xavier NX、Orin Nano、Orin NX到底买哪个我的建议是先把参数表压成一页纸看模组算力参考FP16/密集型内存典型功耗适合场景Jetson Nano 4GB约 472 GFLOPS4GB LPDDR45W~10W入门学习、简单视觉、串口/IO 调试Jetson Xavier NX 8GB约 21 TOPS8GB LPDDR4x10W~20W激光 SLAM、深度相机、移动机器人导航Jetson Orin Nano 8GB约 20 TOPS密集8GB LPDDR57W~25W入门到中级、轻量视觉、边缘 AIJetson Orin NX 16GB约 50 TOPS密集16GB LPDDR510W~25W多传感器融合、端侧大模型部署、复杂导航需要说明的是表中数据是官方公开资料的参考值NVIDIA 在不同 JetPack 版本下对算力的标注方式不一样有密集算力和稀疏算力两种口径所以不要拿这个表去跑分 PK重点看量级和定位。更关键的其实是第二条内存和功耗决定了你能同时跑多少个节点。2.2 按“你要做哪类项目”来倒推配置选型号不要从预算出发要从“项目最重的那个算法”往回推。如果你只是想学习 ROS 2 通信、写写底层驱动、跑跑 turtle 模拟器那 Jetson Nano 的算力其实都够用它最大的问题是内存小开个 RViz2 再跑个点云可视化就容易卡。想做激光雷达 视觉融合至少得 Xavier NX 或 Orin Nano 8GB这两个模组能流畅跑 Cartographer、Nav2也能在本地部署 YOLO 类检测模型。想上多线激光雷达、双相机、端侧跑大模型或检测网络那就直接考虑 Orin NX 16GB留给以后扩展的余地大得多。还有一个经常被忽略的维度开发调试时的“主观体验”。算力刚好够用的板子编译一个 workspace 可能要好几分钟跑起来风扇狂转热得烫手。全栈开发本来就是一个反复修改、编译、重启的过程机器性能多吃紧人的耐心就多受罪。我实际用下来Orin Nano 8GB 做车规级以外的中小型机器人项目已经属于“舒服”的起点预算允许直接上 Orin NX也不会后悔。2.3 二手板、QSPI 固件与渠道安全的提醒因为 Jetson 模块价格不低市场上会有二手、拆机、改装过的开发套件流通。新人很容易被“便宜两百块”吸引结果买回来遇到两个经典问题一是系统引导彻底坏了开机黑屏、连 Recovery 模式都没反应二是某些商家因为搞坏了引导芯片试图通过更换板载 QSPI Flash 芯片来修复普通用户拿到这种板子几乎没法自检。QSPI 芯片在 Jetson 开发套件里存放的是最底层的 bootloader 固件正常使用完全不需要用户折腾它。所以这里给出一个非常实际的建议新手阶段尽量买正规渠道的全新开发套件或官方整机系统选择官方 Jetson 镜像。省下来的那几百块大概率会在后续“刷机刷不进去”“开机无显示”的排查中被加倍浪费掉。如果确实想玩二手至少问清楚能否进 Recovery 模式能否显示 JetPack 版本号烧录时的串口日志是否完整这些问题比成色和价格重要得多。3. 从刷机到点亮JetPack 的两种路线与两个经典坑3.1 第一次刷机SDK Manager 和 SD 卡镜像怎么选Jetson 刷系统有两条主流路线。第一条是用 NVIDIA SDK Manager在另一台 x86 Ubuntu 主机上安装通过 USB-C 线连接 Jetson把板子切换到 Recovery 模式然后把 JetPack 整套刷进去。这条路线适合你想定制组件、或者需要安装 CUDA/ cuDNN / TensorRT 的精确版本时使用缺点是需要额外一台 Ubuntu 主机过程也相对繁琐新手在“进入 Recovery 模式”这一步就可能卡住要在开发套件上按住 Recovery 按键再插电不同型号按键位置不同稍不留神就刷了个寂寞。第二条路线对新手友好得多直接下载官方 SD 卡镜像比如 JetPack 5.1.x 或 6.x 对应的 SD Card Image用 balenaEtcher 或者 dd 命令把镜像写入一张 64GB 以上的 microSD 卡插入开发套件直接开机。这个流程不需要额外电脑不需要进 Recovery 模式第一次点亮系统的成功率最高。系统起来之后再把根文件系统迁移到 NVMe SSD 上如果板子支持启动速度和读写性能会比 SD 卡舒服不少。我个人的建议是第一周先用 SD 卡镜像把系统跑起来把 WiFi、ROS 2、SSH 都验证一遍然后再考虑要不要折腾 NVMe 启动。很多新手一步到位想用 SDK Manager 定制刷机结果卡在组件选择和参数配置上反而把“底座”阶段拉长到好几周完全没必要。3.2 开机没有 WiFi硬件、网络管理器与临时联网手段“Jetson 开机没有 WiFi”这个关键词几乎伴随每一个新手阶段我自己第一次开机也撞上了。先别急着重刷系统按顺序排查。第一步看硬件。Jetson 开发套件的 WiFi 天线接口非常小出厂时如果天线没有牢固拧紧或者金属触点没有完全接触信号强度会低到系统显示“找不到无线网络”。我见过一个案例用户折腾了一个下午最后发现只是天线没装好。用手机开热点靠近板子如果热点可见但信号弱大概率是天线问题。第二步看系统网络管理器。JetPack 默认的 Ubuntu 桌面在某些版本里不会自动弹出 WiFi 面板此时可以用nmcli命令手动连接nmcli device status nmcli dev wifi list nmcli dev wifi connect 你的WiFi名 password 你的密码如果nmcli提示找不到无线设备再检查是不是 NetworkManager 服务没起来或者系统里压根没装对应的无线网卡固件。这一步其实比前面更常见JetPack 精简镜像默认不启用 NetworkManager 的 WiFi 管理桌面右上角自然就没有 WiFi 图标。第三步如果以上都正常但你就是急需联网可以先插一根 USB 网线转接器或者直接用手机 USB 共享网络。手机通过数据线接到 Jetson在手机设置里打开“USB 网络共享”Linux 会直接出一个 usb0 网卡至少能保证立刻上网装包。这个方法在前期调试里非常管用完全不需要依赖无线网络的稳定性。3.3 没有屏幕时的串口调试兜底方案开发套件不一定随时接着显示器尤其机器人装起来之后主控可能被塞在底盘里。这时候一条 USB-TTL 串口线就是你的“最后一道眼睛”。Jetson 的 40-pin 排针上通常引出了 UART0其中 TX 接转接板的 RXRX 接 TXGND 必须共地。系统起来后设备节点一般是/dev/ttyTHS0或/dev/ttyS0在另一台电脑上用一个串口工具连上去就行sudo apt install screen ls /dev/ttyUSB* sudo screen /dev/ttyUSB0 115200看到L4T Console和登录提示说明串口通了。这套思路哪怕是十年前的老 Jetson TK1 也一样适用嵌入式 Linux 的调试逻辑从来没大变过GUI 会崩、网络会断、SSH 可能连不上但串口只要线接对了总能给你吐日志。平时我把串口当作“备用诊断口”常年插着只有等系统稳定到不需要看内核日志了才会拔掉。4. 把 ROS 2 装成底座版本、DDS 与第一轮通信验证4.1 先看 JetPack 再选 ROS 2 版本ROS 2 的版本和 Ubuntu 版本绑定得很死而 JetPack 又直接决定 Ubuntu 版本所以这条对应链必须记牢Jetson 上 JetPack 5.x 对应 Ubuntu 20.04适合安装 ROS 2 FoxyLTSJetPack 6.x 对应 Ubuntu 22.04适合安装 ROS 2 HumbleLTS。不要跨版本硬装跨版本要么没有预编译包要么会遇到一堆 ABI 冲突。这里我遇到过一个很现实的问题很多教学视频还在讲 ROS 1 时代的老流程告诉你apt install ros-melodic-desktop但 ROS 1 已经停止维护新项目完全没有理由再入坑。ROS 2 的节点通信模型一开始可能不习惯但它解决的是 ROS 1 单机主节点的痛点多机通信、DDS 动态发现、生命周期管理都更适合移动机器人这种“设备在动”的场景。如果你所在团队没有历史 ROS 1 包袱直接 Humble 起步是最优解。4.2 安装与初始化不要跳过 source 和 bashrcROS 2 官方给的是 apt 安装方式在 Jetson 的 Ubuntu 上同样适用。先加 ROS 2 软件源和密钥然后安装桌面版或基础版。桌面版ros-humble-desktop包含 RViz、Gazebo、demo 节点适合开发调试如果做纯机器人部署装ros-humble-ros-base就够。sudo apt update sudo apt install curl gnupg lsb-release 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 $(source /etc/os-release echo $UBUNTU_CODENAME) main | sudo tee /etc/apt/sources.list.d/ros2.list /dev/null sudo apt update sudo apt install ros-humble-desktop装完第一件事把环境变量写进~/.bashrcecho source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc这个步骤看着简单但很多人漏了导致每次打开终端都要手动source一遍还总怀疑“是不是没装成功”。ROS 2 的环境变量和系统环境变量是两套体系setup.bash负责把ros2、colcon这些命令路径以及共享库路径加载进来不写进 bashrc 的话新建终端就找不着命令。验证安装是否正常最快的方式是跑一对 talker 和 listenerros2 run demo_nodes_py talker ros2 run demo_nodes_py listener终端 A 在发 Hello World 计数终端 B 在收数据说明通信管道已经通了。这一步跑通了“ROS 2 底座”才算真正成立。4.3 DDS 切换无线环境下最容易踩的发现延隔ROS 2 底层默认使用基于 DDS 的实时通信协议。JetPack 上默认的 DDS 实现是 Eclipse Fast DDS之前叫 Fast RTPS功能完整但有一个实际体验问题在 WiFi 网络环境里节点之间的自动发现经常出现延迟一个节点启动后另一个节点需要等几十秒才能在ros2 topic list里看到甚至偶尔直接发现不了。这个问题在移动机器人场景特别明显因为车上的 Jetson 通常通过 WiFi 和上位机、其他传感器通信网络广播和组播在无线环境下不像有线那么可靠。我的处理方法是切换到 Cyclone DDS它默认的发现机制更简洁节点启动速度在弱网环境下有明显改善。sudo apt install ros-humble-rmw-cyclonedds-cpp echo export RMW_IMPLEMENTATIONrmw_cyclonedds_cpp ~/.bashrc source ~/.bashrc切换完成后重复跑一次talker / listener你会发现节点发现的响应变快了。需要提醒的是同一个机器人系统里所有节点必须使用同一种 DDS 实现否则通信会直接失败官方给的RMW_IMPLEMENTATION环境变量必须所有机器统一设置。5. 远程开发组合SSH 为主VNC 为辅IP 固定是底线5.1 SSH 免密与基础操作机器人装起来之后你不可能每次调试都搬个显示器跟着车跑SSH 是远程开发的第一件工具。登录终端ssh 用户名机器人IP第一次连接会提示确认主机指纹回车输入密码即可。但天天输密码太烦配置一把 SSH 公钥一劳永逸# 在开发机上执行 ssh-keygen -t ed25519 ssh-copy-id 用户名机器人IP之后登录就不需要密码了。这一步对后续全栈开发非常关键因为你后续大概率会写脚本自动同步代码、自动colcon build免密是这些自动化流程的前提。5.2 固定 IP 和主机名多设备协作的隐形效率移动机器人调试时经常遇到一个问题开发机的 DHCP 给车上的 Jetson 分了一个 IP第二天重启变成另一个 IP你所有脚本里的 IP 白瞎了。所以固定 IP 不是“可选项”而是开发效率底线。最简单的方式是在路由器后台给 Jetson 开 DHCP 静态绑定让 MAC 地址始终拿到同一个 IP。如果没有路由器管理权限就直接改 netplan# /etc/netplan/01-netcfg.yaml network: version: 2 renderer: NetworkManager ethernets: eth0: dhcp4: no addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 192.168.1.1IP 地址、网关、DNS 要按你实际路由器网段改改完执行sudo netplan apply。同时建议给板子起一个独立主机名sudo hostnamectl set-hostname mobile-robot有了主机名和固定 IP你在 SSH、VNC、后续多机 ROS 2 通信里就不容易点错设备。多台机器人同时调试的时候这一步能救命的。5.3 VNC 桌面什么时候装、怎么装、性能注意SSH 适合命令操作但机器人开发经常需要看图形界面RViz2 里的点云、RQT 的节点图、摄像头的实时画面。这些都是 GUI 程序光靠 SSH 看不到。这时可以给 Jetson 装一个 VNC 服务最简单的是 x11vncsudo apt install x11vnc x11vnc -forever -shared -passwd 你的密码 -display :0然后在开发机上用任意 VNC 客户端连接机器人IP:5900。这样你在没有显示器的情况下也能看到 JetPack 桌面上正在跑的 RViz2 窗口摄像头调试、URDF 可视化都会方便很多。但注意一点VNC 是通过网络传图形帧带宽占用高操作延迟明显。不要依赖 VNC 去跑实时导航或者大算力任务它只适合“偶尔瞄一眼界面”和“短时图形调试”。机器人正式跑任务时建议关掉 VNC 服务把系统资源留给算法和传感器驱动。如果你觉得 VNC 延迟太大、画面撕裂严重可以试试 NoMachine它用 NVIDIA 的编码加速在 Jetson 上能流畅不少但本质还是“远程看屏幕”不是“远程高性能计算”。6. 把底座接到硬件电气链路上的几个关键理解6.1 底盘控制并不该由 Jetson 直接负责很多第一次做机器人的朋友会问我能不能直接用 Jetson 的 GPIO 发 PWM 给电机驱动板省掉单片机答案是能但非常不推荐。Linux 非实时、GPIO 抖动大、一旦主控死机电机就失去控制这在移动机器人上是不可接受的。成熟的架构是三层Jetson 负责感知决策通过串口或 CAN 下发期望速度中间的单片机负责 PID 闭环和电机驱动电机编码器数据再通过单片机回传到 Jetson 供里程计使用。实际操作中Jetson 与底层单片机之间最常见的通信方式有两种。串口简单数据结构自己定义开发快适合原型验证CAN 总线抗干扰、支持多节点、传输距离远适合正式产品。不管用哪种通信协议里一定要包含期望速度、转向角、使能/急停指令、底盘状态回传、编码器原始值这五类信息基本覆盖了移动机器人底盘的通信需求。6.2 读电气原理图时的四类必查信息市面上很多移动机器人开发套件会随箱附赠底盘电气原理图或者你从网上搜“移动机器人电气原理图”也能找到大量开源图纸。拿到一张图先不要从头读按四个方向去找关键信息。第一是供电链路电池电压进来到哪个 DC-DC 降压分出多少路电源轨Jetson 的供电是先经过稳压模块还是直接接电源板这个决定了你加传感器时会不会拉垮主控。第二是通信链路哪些串口连了哪些设备CAN 总线上挂了几片控制板有没有共地问题。第三是电平转换单片机侧是 3.3V 还是 5VJetson 的 GPIO 是 3.3V互相连接时是否经过电平转换接错就可能烧 IO。第四是保护电路有没有反接保护、限流、EMI 滤波移动机器人电机一启动电源上的毛刺经常导致单片机重启原理图里如果是“裸连”后期就得自己加滤波电容。读图的目的是建立“故障排查路线图”机器人某个传感器不工作你应该能根据原理图判断这条信号链路经过了哪些器件而不是拿万用表到处乱戳。6.3 给后续全栈功能预留的接口习惯底座搭得好的标准不是今天能跑起来而是接下来加功能时不返工。基于我的经验有三件事值得在初期预留好一是传感器和底盘的数据接口用 ROS 2 标准消息格式比如底盘回调用nav_msgs/Odometry、激光雷达用sensor_msgs/LaserScan或PointCloud2这样后面接 Nav2、Cartographer 就是改参数而不是改代码二是建立一个明确的 workspace 结构至少区分src、build、install、log四个目录用colcon build统一管理所有功能包三是在一开始就把“传感器热插拔”视为常态每个传感器用独立串口或 USB 设备节点并在启动脚本里做好设备节点丢失的容错因为移动机器人运行中最常见的故障就是某个 USB 摄像头掉线、某个雷达没插紧。最后分享一点我的个人体会如果你第一次搭 Jetson 上的 ROS 2 环境我劝你克制住“把能装的库都装一遍、把能配的软件都配上”的冲动。我踩过最深的坑就是一开始把 VNC、SSH、SDK Manager、多套 CUDA 版本、无敌的网络代理配置全挤在一块结果任何一个组件更新都可能把另一个环境搞坏。全栈开发讲究的是一个“可用基线”JetPack 版本固定ROS 2 版本固定机器人在局域网里的 IP 固定远程开发方式固定剩下的功能模块再往这条基线上加。每次加完新东西先从 talker/listener 通信验证开始再跑真实硬件。底座搭起来之后移动机器人真正的“体力活”才刚开始——底盘驱动、传感器标定、SLAM 建图、导航避障这些都是后续系列要拆开细聊的内容。下一篇我打算接着写“底盘驱动与 ROS 2 控制”把单片机、编码器、串口协议和ros2_control之间的那层关系说透。如果你也正在搭自己的机器人底座欢迎把你在刷机、WiFi、ROS 2 安装上遇到的问题留在评论区这些问题也是系列后续内容的最佳选题。