Jetson 实践—Robotics与Physical AI

一、本周学习内容本周从“单独运行 AI 模型”进一步走向“让 AI 影响真实世界”。主要任务包括理解机器人系统和具身智能的基本概念。掌握 ROS/ROS 2 的基本架构与通信方式。理解 Physical AI 的感知、决策、执行和反馈闭环。了解视觉模型在 Jetson 上的优化与部署方式。完成了一个综合 AI Demo并用文档、截图和视频展示最终项目。二、Robotics 与 Physical AI 基础2.1 什么是机器人系统机器人不是单一的机械结构而是计算、传感器、控制器、执行器和软件共同组成的系统。Seeed 课程将实体 ROS 机器人划分为两部分上层感知与决策在 Jetson 等高性能计算设备上运行负责读取摄像头、雷达和 IMU 等数据执行视觉识别、定位、规划和决策。下层运动控制通常运行在微控制器上实时接收上层命令驱动电机或舵机并向上层反馈状态。这种分层架构的优点是Jetson 的视觉推理负载不会直接干扰执行器时序。ESP32 固件可以独立测试不依赖 YOLO。视觉模型、决策规则、串口协议和硬件驱动可以分层排错。后续可将 LED/舵机替换为机械臂、底盘或其他真实执行机构。2.2 什么是 Physical AIPhysical AI 可以概括为AI 不仅分析数字内容还能感知物理环境、做出决策并触发真实动作。一个最小闭环如下Physical AI 并不等于机械臂。机械臂只是执行器的一种小灯、舵机、电机、蜂鸣器、屏幕或移动底盘都可以构成物理执行部分。只要项目形成“感知—决策—动作—反馈”闭环就具备完整的 Physical AI 特征。三、ROS 2 基础知识3.1 ROS 2 的作用ROS 2 不是传统意义上的操作系统而是一套机器人软件中间件、工具和软件包。它解决的核心问题是摄像头、AI 模型、决策程序、执行器驱动和显示程序如何彼此通信并能够被独立调试和替换。当前 Jetson 使用 Ubuntu 22.04因此优先学习ROS 2 Humble。ROS 官方将 Ubuntu 22.04 的arm64列为 Humble 的 Tier 1 平台适合 Jetson Orin NX。3.2 ROS 2 核心概念概念含义本项目中的例子Node 节点完成单一职责的进程摄像头节点、YOLO 节点、决策节点Topic 话题持续发布/订阅的数据流图像、检测结果、执行器命令Message 消息话题上传输的数据结构图像、字符串、速度命令Service 服务一问一答式请求查询执行器当前状态Action 动作可取消、可反馈的长任务舵机移动到指定位置Parameter 参数节点的运行配置置信度阈值、目标类别TF/TF2坐标系之间的关系相机、机器人底座、目标位置Launch一次启动多个节点同时启动检测、决策和执行节点rosbag记录并回放 ROS 数据保存摄像头和检测结果用于复现3.3 ROS 2 通信示例假设系统使用/physical_command话题发布执行命令可以先不连接硬件在终端模拟一条消息source /opt/ros/humble/setup.bash ​ ros2 topic pub --once /physical_command std_msgs/msg/String \ {data: LED_GREEN}另一个终端观察消息source /opt/ros/humble/setup.bash ros2 topic echo /physical_command基础检查命令command -v ros2 printenv ROS_DISTRO ros2 node list ros2 topic list如果command -v ros2没有输出说明 ROS 2 尚未安装。此时应按照 ROS 2 Humble 官方 Ubuntu deb 安装说明配置软件源不要直接混装 ROS 1 Noetic 和 ROS 2 Humble。四、运动控制的基本认识Seeed 的“基础运动控制方法”课程展示了通过手机 App、PS2 手柄或键盘控制机器人底盘。不同输入方式最终完成的是同一件事用户给出向前、后退、转向或停止命令。命令通过蓝牙或 ROS 传给控制器。控制器计算左右电机目标速度。电机驱动器向电机供电。编码器把实际速度反馈给系统。4.1 差速底盘常见两轮机器人通过左右轮速度差实现运动左轮右轮结果同速向前同速向前直行停止/较慢向前/较快左转向前向后原地旋转停止停止停车在 ROS 中通常使用geometry_msgs/msg/Twist表达线速度和角速度。即使没有底盘也可以通过turtlesim或 Gazebo 学习同样的控制逻辑。4.2 没有机械臂时如何理解“运动控制”控制舵机角度对应机械臂的单个关节控制。控制直流电机启停和方向对应底盘运动控制。控制 LED 和蜂鸣器对应离散执行器控制。控制屏幕内容对应人机交互反馈。小型舵机尤其适合作为机械臂替代实验角度可以被明确控制动作容易拍摄也比直流电机更容易验收。五、深度相机与机器人感知5.1 RGB 相机与深度相机的区别普通 USB 摄像头只提供二维彩色图像深度相机还能为像素提供距离信息因此可以判断目标距离、生成点云、避障或完成三维定位。课程示例使用 Orbbec Gemini 2。资料介绍该设备采用双目结构光方案提供多种深度模式测量范围约为 0.1510 米。课程给出的基本 SDK 流程为git clone https://github.com/orbbec/OrbbecSDK.git cd OrbbecSDK/misc/scripts sudo chmod x ./install_udev_rules.sh sudo ./install_udev_rules.sh sudo udevadm control --reload sudo udevadm triggercd ../../ mkdir build cd build cmake .. cmake --build . --config Release cd bin ./OBMultiStream只有在实际拥有兼容 Orbbec 相机时才执行上述步骤。5.2 本项目不用再购买深度相机当前已有 USB 摄像头可以先使用 YOLO 完成类别与位置检测。对于桌面演示二维视觉已经足以根据“是否检测到人、杯子或手机”控制 LED 和舵机。深度相机属于可选升级加入距离后可以实现“目标进入 1 米范围才报警”“目标越近舵机转角越大”等功能使项目更接近机器人避障和空间交互。六、AI 模型优化与 Jetson 部署6.1 为什么需要优化机器人需要持续处理摄像头数据并及时动作。模型太慢会导致画面延迟动作也会滞后。因此需要关注模型尺寸优先使用 YOLOv8n 等轻量模型。输入分辨率先以 640×480 或更低分辨率验证。推理后端从 PyTorch/ONNX 逐步转为 TensorRT。精度模式FP16 通常适合作为速度与精度的平衡点INT8 需要校准数据。流水线避免重复复制图像限制队列长度过期帧直接丢弃。资源监控使用jtop观察 GPU、CPU、内存、温度和功耗。6.2 推荐优化顺序先跑通功能→ 记录原始 FPS 和延迟 → 使用小模型 → 导出 ONNX → TensorRT FP16 → 再考虑 INT8、DeepStream 或 Isaac ROS不要在系统尚未形成闭环前追求最高 FPS。Final Project 的第一优先级是动作正确、流程完整、结果可复现。七、Physical AI 项目实验机械臂项目通常包含相机感知、策略决策、关节执行和反馈。把机械臂替换成 LED、舵机或电机后系统的关键结构没有改变机械臂项目替代项目相机观察桌面USB 摄像头观察桌面模型识别物体/估计姿态YOLO 识别人、杯子、手机等策略生成抓取动作规则节点决定亮灯和舵机角度多关节电机执行单舵机、直流电机或 LED 执行关节状态反馈串口确认、屏幕状态或摄像头复核没有机械臂时不能声称完成了 SO-ARM 的真实抓取或 ACT/Diffusion Policy 实机训练但仍可以完成 Robotics、ROS 和 Physical AI 综合 Demo。7.1 各种替代组件的适用性组件是否推荐可以展示的能力难度HDMI 屏幕推荐检测框、类别、系统状态低单个 LED推荐AI 决策触发物理输出低红黄绿 LED强烈推荐安全/警告/正常三种状态低蜂鸣器可选声音报警低SG90舵机强烈推荐角度动作、挡板或指针中直流电机可选风扇、轮子或转盘中高OLED 小屏可选类别、置信度和状态中深度相机后续升级目标距离、避障、三维感知中高八、基于Jetson 智能桌面安全与分类指示器实验8.1 项目目标USB摄像头持续采集桌面画面Jetson Orin NX使用YOLO进行实时目标检测并通过ROS 2发布检测类别、置信度和目标框等信息。决策节点根据检测类别、置信度以及连续检测状态将系统划分为IDLE、TARGET和ALERT三种状态并通过/dev/ttyUSB0串口向ESP32发送对应命令。ESP32接收Jetson发送的串口命令后控制红、黄、绿三色LED以及360°连续旋转MG90S舵机实现视觉感知、状态决策和物理执行的完整闭环。显示器同步显示摄像头画面、YOLO检测框、类别、置信度、当前决策状态及串口执行结果。示例规则状态LED反馈舵机动作ESP32命令正常/待机绿灯亮停止IDLE发现关注目标黄灯亮顺时针旋转约700ms后停止TARGET发现危险或系统异常红灯亮逆时针旋转约700ms后停止ALERT8.2 系统架构8.3 实验硬件与环境8.3.1 硬件清单硬件用途NVIDIA Jetson Orin NX 16GBYOLO 推理、决策、ROS 2 与 Web 页面1080P USB Camera环境感知ESP32-WROOM-32LED 与舵机控制红、黄、绿 LED三种状态反馈220Ω 电阻 × 3LED 限流360° 连续旋转舵机物理动作外部 5V/3A 电源舵机独立供电面包板与杜邦线电路连接当前项目连接示意图如下8.3.2 Jetson 软件环境项目实际环境JetsonNVIDIA Jetson Orin NX Engineering Reference Developer KitUbuntu22.04.5 LTSL4T36.4.4架构aarch64CUDA12.6.68TensorRT10.3.0.30Python3.10.12YOLO 镜像yaohui1998/ultralytics-jetpack61:v1.0ROS 2 镜像ros:humble-ros-base-jammyYOLO 模型/home/hcx/yolo_models/Yolov8/yolov8n.pt实验全过程没有执行apt upgrade、dist-upgrade或full-upgrade也没有升级 Jetson 内核。8.3.3 GPIO 分配部件ESP32 引脚红色 LEDGPIO25黄色 LEDGPIO26绿色 LEDGPIO27连续旋转舵机信号GPIO138.3.4 供电与安全三个 LED 必须分别串联 220Ω 电阻。ESP32 通过 Jetson 或 Windows USB 供电。舵机使用独立 5V/3A 电源。舵机外部电源 GND 必须和 ESP32 GND 共地。舵机外部 5V 不接入 Jetson GPIO。接线或改变供电前先断电。烧录固件时建议暂时关闭舵机外部电源。8.4. 系统设计与控制规则8.4.1 状态决策状态视觉条件LED 状态舵机动作用途IDLE没有 person、bottle、cup绿灯亮红黄灯灭停止正常/空闲状态TARGET检测到 bottle 或 cup且没有 person黄灯亮红绿灯灭顺时针约 700 ms 后停止发现目标ALERT检测到 person红灯亮黄绿灯灭逆时针约 700 ms 后停止告警状态决策优先级为person bottle/cup 其他类别因此只识别到 chair 或 refrigerator 时仍为 IDLE。同时识别到 person 和 bottle 时为 ALERT。TARGET 测试时必须放好瓶子或杯子后让人员离开摄像头画面。8.4.2 串口协议Jetson 和 ESP32 使用115200波特率每条命令以换行符结尾IDLE\n TARGET\n ALERT\nESP32 执行后返回ACK:IDLE ACK:TARGET ACK:ALERT固件不会去重。即使连续发送两次相同 TARGET 或 ALERT也会逐次重新执行。视觉应用为了避免目标持续存在时舵机不断转动只在稳定状态变化时发送一次手动串口和 ROS 2 重复发送仍会重复执行。8.5. 实验执行过程与结果8.5.1 阶段一ESP32 固件固件文件为esp32_continuous_servo.ino。主要功能包括初始化 GPIO25、GPIO26、GPIO27 和 GPIO13。上电默认进入 IDLE。接收并转换大写串口命令。对每一条有效命令执行 LED 和舵机动作。TARGET/ALERT 动作完成后返回 ACK。重复命令不会被忽略。当前固件行为已经通过 Jetson 串口 ACK 和动作时间验证说明 ESP32 中已有可工作的控制程序。8.5.2 阶段二Jetson 识别摄像头和 ESP32最初识别到的节点为/dev/video0和/dev/ttyUSB0。USB 设备重新插拔后节点变成了/dev/video1和/dev/ttyUSB1。这说明不能长期依赖编号路径。当前使用的稳定路径为Camera:/dev/v4l/by-id/usb-SN0002_1080P_USB_Camera_44434000_P030C01_SN0002-video-index0ESP32:/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0启动脚本已经自动解析 by-id 路径并把真实设备映射为容器内的/dev/video0和/dev/ttyESP32。摄像头验证结果如图所示设备SN0002 1080P USB Camera驱动uvcvideo采集格式640 × 480帧格式BGR 读取结果为 (480, 640, 3)帧率30 FPS摄像头能力8.5.3 原始串口验证实际发送序列IDLE → TARGET → TARGET → ALERT → ALERT → IDLE实际结果命令ACK实测延迟IDLEACK:IDLE约 0.019 sTARGETACK:TARGET0.700 s重复 TARGETACK:TARGET0.725 sALERTACK:ALERT0.719 s重复 ALERTACK:ALERT0.719 s结论ESP32 串口协议正常。三种状态均可执行。重复命令会重新执行。TARGET/ALERT 的固件动作窗口约为 700 ms。8.5.4 阶段三ROS 2 基础验证宿主机没有现成 ROS 2 环境非交互会话又不能输入 sudo 密码因此本次使用官方 ARM64 ROS 2 Humble 容器不修改 Jetson 系统包。基础 Publisher/Listener 结果publisher: std_msgs.msg.String(dataHello Week4 ROS 2) listener: data: Hello Week4 ROS 2ROS 串口桥文件为ros_serial_bridge.py启动脚本为run_ros_bridge.sh。节点功能包括订阅/physical_ai/command。只接受 IDLE、TARGET、ALERT。向 ESP32 发送串口命令。等待 ESP32 ACK。将 ACK 发布到/physical_ai/ack。实际 ROS 2 测试序列IDLE → TARGET → TARGET → ALERT → IDLE桥接日志Sent IDLE; received ACK:IDLE Sent TARGET; received ACK:TARGET Sent TARGET; received ACK:TARGET Sent ALERT; received ACK:ALERT Sent IDLE; received ACK:IDLE结论ROS 2 Topic → 串口桥 → ESP32 → ACK 闭环已经通过重复 TARGET 也能再次执行。8.5.5 阶段四YOLO 与 ESP32 集成完整应用为physical_ai_demo.py启动脚本为run_physical_ai_demo.sh。应用实现了V4L2 摄像头采集。YOLOv8n 实时推理。person、bottle、cup 决策映射。连续稳定帧过滤。只在稳定状态变化时发送命令。独立串口工作线程避免 700 ms 动作阻塞视频推理。ESP32 ACK 显示。MJPEG 浏览器实时画面。启动失败检测和摄像头释放。当前启动参数为model/models/yolov8n.pt imgsz416 conf0.50 stable_frames5 host127.0.0.1 port8000已完成的实时视觉验证IDLE 已通过STATEIDLE CLASSES[] SERIAL commandIDLE responseACK:IDLE实验现象当前绿灯亮起舵机不转动TARGET已通过STATETARGET CLASSES[Cup] ​​​​​​​SERIAL commandTARGET responseACK:TARGET实验现象识别到cup当前黄灯亮起舵机顺时针约 700 ms 后停止这说明以下完整链路已经实际运行摄像头 → YOLO 检测 cup → TARGET → USB 串口 → ESP32 → ACK:TARGETALERT 已通过STATEALERT CLASSES[chair, person] SERIAL commandALERT responseACK:ALERT实验现象识别到person当前红灯亮起舵机逆时针约 700 ms 后停止这说明以下完整链路已经实际运行摄像头 → YOLO 检测 person → ALERT → USB 串口 → ESP32 → ACK:ALERT8.5.6 Web 前端访问Web 服务只绑定 Jetson 本机http://127.0.0.1:8000这样可以避免把实时摄像头画面直接暴露给整个局域网。Windows 使用 SSH 隧道访问ssh -N -o ExitOnForwardFailureyes -L 18000:127.0.0.1:8000 hcx192.168.31.157浏览器打开http://127.0.0.1:18000Windows 本地 8000 端口曾出现Permission denied因此改用本地 18000 端口。Jetson 端仍为 8000。九. 实验中遇到的问题与解决方法9.1 原指南使用位置舵机角度问题原始方案将舵机写成 0°、90°、180°位置控制但实际硬件是 360°连续旋转舵机。解决改为停止、顺时针 700 ms 和逆时针 700 ms并明确控制值不是实际目标角度。9.2 重复命令被忽略问题原固件通过command ! currentState去重导致连续两次相同命令不会重新动作。解决删除固件去重条件每条有效命令都执行并返回 ACK。9.3 YOLO 周期性重发造成舵机重复动作问题旧视觉逻辑每隔 3 秒重发同一状态。连续旋转舵机固件会逐条执行因此目标不动时舵机会不断重复旋转。解决视觉应用只在稳定状态变化时发送一次。移除目标回到 IDLE 后再次放入目标才会重新执行 TARGET。9.4 USB 设备编号变化问题摄像头由/dev/video0变为/dev/video1ESP32 由/dev/ttyUSB0变为/dev/ttyUSB1固定路径导致 Docker 报no such file or directory。解决启动脚本优先使用/dev/v4l/by-id和/dev/serial/by-id自动映射当前真实节点。9.5 宿主机 ROS 2 与串口权限问题宿主机未安装 ROS 2hcx当时不在dialout组非交互环境不能输入 sudo 密码。解决使用官方 ROS 2 Humble ARM64 Docker 镜像并用--device映射 ESP32pyserial安装在项目本地vendor目录。9.6 Docker 默认 bridge 网络失败问题默认 bridge 网络触发 Jetson 内核iptables raw表错误。解决ROS 与 Web 使用--network host纯离线设备检查使用--network none不升级内核。9.7 Docker 下载代理错误问题Docker daemon 配置为127.0.0.1:17890但有效代理监听在 7897导致拉取镜像失败。解决已有 YOLO 镜像继续复用ROS 镜像下载时使用临时本地转发完成后立即停止没有永久修改系统代理。9.8 MJPEG 输出过快问题旧生成器反复发送同一帧3 秒产生约 2.06 GB 临时数据。解决增加帧序号只在出现新推理帧时输出。修复后 3 秒约 8.4 MB。9.9 Demo 退出后摄像头被占用问题早期容器 CtrlC 后推理线程没有完整清理导致/dev/video0显示 busy。解决增加 shutdown event、启动错误传递、线程等待、摄像头 release 和串口 close。最终验证容器退出后设备可再次读取。9.10 Windows 无法访问 127.0.0.1:8000问题Windows 浏览器中的127.0.0.1指向 Windows 自己不是 JetsonWindows 本地 8000 端口还发生绑定权限错误。解决使用 SSH 隧道把 Windows 18000 转发到 Jetson 127.0.0.1:8000。9.11 黄灯没有被实时视觉触发问题当前 person 能稳定触发红灯其余未识别为 bottle/cup 的物体都属于 IDLE因此显示绿灯。解决方法TARGET 只接受 COCO 类别bottle和cup使用清晰目标、充足光线、让人员离开画面必要时降低置信度或提高输入尺寸。十. 当前完成情况学习 Robotics 上层感知与下层控制的分层架构。学习 ROS 2 Node、Topic、Message 和发布/订阅。理解 Physical AI 感知—决策—执行—反馈闭环。完成 ESP32 三色 LED 与连续旋转舵机固件。完成 IDLE、TARGET、重复 TARGET、ALERT、重复 ALERT 串口 ACK 验证。测得 TARGET/ALERT ACK 延迟约 700 ms。Jetson 成功识别 USB 摄像头和 CP2102 ESP32 串口。启动脚本改为稳定 by-id 设备路径。ROS 2 Publisher/Listener 验证通过。ROS 2 Topic → ESP32 → ACK 闭环通过。YOLO 摄像头实时推理通过。实时 IDLE → 绿灯/停止链路通过。实时 cup → TARGET → ACK:TARGET 链路通过实时 person → ALERT → ACK:ALERT 链路通过。Windows 通过 SSH 隧道访问 Web 前端的方法已验证。​​​​​​十一. 学习收获通过本章实验我理解了机器人系统不是单一模型或单一控制板而是由感知、决策、通信、执行和反馈组成的系统工程。Jetson 适合承担视觉推理与上层决策ESP32 适合承担稳定、可预测的硬件控制。本周的关键不是必须拥有一台完整机器人而是理解并实现机器人软件的闭环。Jetson 负责从摄像头获得环境信息运行 YOLO 等 AI 模型并做出决策ROS 2 将不同功能拆分为节点通过话题传递检测与控制消息微控制器和驱动电路负责安全、稳定地执行动作屏幕与状态消息让结果可以被观察和验证。在没有 SO-ARM 机械臂的情况下使用 USB 摄像头、红黄绿 LED、SG90 舵机和显示器同样能够完成一个结构完整、易展示、可扩展的 Physical AI Final Project。后续如果增加深度相机、移动底盘或机械臂现有的检测、决策和 ROS 通信节点仍然可以继续复用。感谢seeedstudio提供的硬件支持