4. 边缘AI基础

在ROS2 Nav2导航系统中引入视觉识别结果来影响路径规划，其核心挑战在于“实时性”与“资源约束”之间的平衡。传统的云端AI推理虽然算力强大，但网络延迟和带宽成本往往无法满足机器人对毫秒级响应的需求。边缘AI（Edge AI）正是为解决这一矛盾而生——它将深度学习模型的推理过程从云端下沉到靠近数据源的设备端（即机器人本体），在本地完成图像识别、目标检测等任务，再将结构化结果（如障碍物类别、位置、置信度）直接发布到ROS2话题中，供Nav2的代价地图层和规划器使用。本章将系统梳理边缘计算的核心概念、主流硬件平台（Jetson与Raspberry Pi）的选型要点，以及TensorRT和ONNX Runtime两大推理框架的工程实践方法，为后续章节中“识别结果如何影响全局路径与局部避障”打下坚实的工具链基础。

上图展示了边缘AI与ROS2 Nav2融合的完整工程链路。传感器数据（图像、点云）首先进入边缘推理单元，经过TensorRT或ONNX Runtime加速的模型推理后，输出结构化识别结果（如“前方2.3米处有行人，置信度0.92”），这些结果通过ROS2话题（如/detected_obstacles）发布。Nav2的代价地图层订阅该话题，将动态障碍物信息实时注入障碍层（Obstacle Layer）或膨胀层（Inflation Layer），从而影响全局规划器（NavFn/Smac Planner）和局部规划器（DWB/Regulated Pure Pursuit）的决策。整个链路中，边缘AI推理的延迟直接决定了导航系统对动态障碍物的反应速度——推理越慢，机器人的安全刹车距离就越长。

4.1 边缘计算核心概念与在机器人导航中的定位

4.1.1 核心原理：为什么导航必须依赖边缘AI

边缘计算（Edge Computing）是一种分布式计算范式，它将数据处理和模型推理放置在靠近数据源头的网络边缘侧，而非全部集中到云端数据中心。在ROS2导航场景中，边缘AI的价值体现在三个维度：实时性（端到端延迟通常要求小于100ms，而云端往返往往需要200-500ms）、可靠性（工厂、隧道、地下车库等场景网络信号不稳定，断网时本地推理仍可工作）、隐私与带宽（视频流无需全部上传，仅上传结构化结果，带宽占用降低90%以上）。

从系统架构角度看，边缘AI在Nav2导航中承担“感知前置处理”的角色。原始图像数据量巨大（1080p RGB图像约6MB/帧），若直接传输给云端识别，不仅占用带宽，而且网络抖动会导致识别结果到达时间不确定，破坏Nav2代价地图更新的确定性。边缘AI将识别模型部署在机器人主控板上，推理结果以极低延迟（Jetson Orin上YOLOv8s约5-8ms）发布到ROS2话题，使Nav2的规划周期（通常为10-20Hz）能够稳定运行。

4.1.2 判断方法：何时选择边缘AI而非云端AI

在实际项目选型时，可通过以下条件判断是否需要边缘AI：

• 网络条件：若工作环境存在Wi-Fi盲区、信号干扰或带宽限制（如多机器人协同场景），必须采用边缘AI。
• 实时性要求：若导航系统需要检测动态障碍物（行人、叉车）并实时避障，推理延迟必须低于50ms，边缘AI是唯一选择。
• 数据隐私：涉及生产数据、人脸信息或商业机密时，本地推理避免数据外泄。
• 长期运营成本：云端推理按调用量计费，24小时运行的机器人每月费用可能超过硬件成本，边缘AI一次性投入更划算。

4.1.3 案例拆解：AGV在弱网环境下的导航避障

某汽车工厂的AGV（自动导引车）在车间内执行零部件搬运任务，车间面积约2万平方米，部署了多个金属货架和移动式焊接机器人。初始方案采用云端AI识别障碍物，但实际运行中发现两个问题：一是车间内Wi-Fi信号受金属货架遮挡严重，图像上传经常超时，导致AGV频繁急停；二是云端识别延迟波动大（150-800ms），Nav2的局部规划器无法获得稳定的障碍物更新，出现“看到障碍物时已经太近”的危险情况。

改造方案：在AGV上安装Jetson Orin NX（16GB版本），部署TensorRT加速的YOLOv8s模型，输入分辨率640×480，FP16精度。推理延迟稳定在7ms左右，识别结果通过ROS2话题以20Hz频率发布。Nav2的代价地图层订阅该话题，将识别到的“工人”、“叉车”、“料架”分别以不同半径（0.3m/0.5m/0.4m）膨胀为障碍物。改造后，AGV在弱网环境下仍能保持0.8m/s的正常行驶速度，急停次数从每天平均15次降至0次，且未发生碰撞事故。

4.2 常见边缘设备：Jetson与Raspberry Pi的选型与适配

4.2.1 核心原理：不同算力层级的设备定位

边缘AI设备的选择需根据模型复杂度、功耗预算、接口需求和成本综合决定。当前ROS2机器人领域最常用的两类平台是NVIDIA Jetson系列和Raspberry Pi系列，它们的定位截然不同：

4.2.2 判断方法：根据模型与功耗需求选型

选型时建议遵循以下决策流程：

1. 确定模型复杂度：若需检测多类目标（>10类）且输入分辨率≥640×640，优先选择Jetson Orin系列；若仅检测3-5类简单目标（如“人”、“车”），Raspberry Pi + Hailo-8足够。
2. 评估功耗预算：Jetson Orin NX在25W模式下性能最佳，但需要主动散热；若机器人电池容量有限（如小型巡检机器人），Raspberry Pi 5的5W功耗更具优势。
3. 检查接口兼容性：Jetson自带CSI相机接口、CAN总线、多路USB 3.0，适合直接连接工业相机；Raspberry Pi的CSI接口支持官方Camera Module 3，但工业相机需通过USB转接。
4. 考虑开发效率：Jetson的JetPack SDK预装了CUDA、cuDNN、TensorRT，开箱即用；Raspberry Pi需要手动配置ONNX Runtime的ARM版本，且Hailo加速棒需要额外安装驱动和编译器。

4.2.3 实战场景：Jetson与Raspberry Pi在Nav2中的分工

在一个典型的室内服务机器人项目中，我们采用了“双芯片”架构：Jetson Orin NX负责视觉AI推理（YOLOv8s行人检测 + 深度估计），Raspberry Pi 5负责ROS2主控（运行Nav2导航栈、电机驱动、传感器数据采集）。两者通过千兆以太网连接，使用ROS2 DDS（FastDDS）通信。这种分工的优势在于：

• Jetson的GPU资源完全用于推理，不会被Nav2的CPU密集计算（代价地图更新、规划器）干扰，保证推理延迟稳定。
• Raspberry Pi 5的4核Cortex-A76运行Nav2时CPU占用约60%，仍有足够余量处理激光雷达驱动和电机控制。
• 若Jetson故障，Raspberry Pi可降级运行简单的激光避障模式，保证机器人安全停车。

4.3 推理框架：TensorRT与ONNX Runtime的工程实践

4.3.1 核心原理：两种框架的优化哲学

TensorRT是NVIDIA推出的高性能深度学习推理优化器，它通过层融合（Layer Fusion）、精度校准（FP16/INT8量化）、内核自动调优（Kernel Auto-tuning）和显存池管理，将训练好的模型（如ONNX、PyTorch）编译为针对特定GPU架构的优化引擎。在Jetson平台上，TensorRT能利用Tensor Cores实现数倍于原始框架的推理加速。例如，YOLOv8s在Jetson Orin NX上使用PyTorch CPU推理约需120ms，而TensorRT FP16引擎仅需7ms，加速比超过17倍。

ONNX Runtime是微软主导的跨平台推理引擎，支持CPU、GPU、NPU等多种执行提供程序（Execution Providers）。它的优势在于框架无关性和部署灵活性——模型从PyTorch/TensorFlow导出为ONNX格式后，可在不同硬件上无缝切换执行提供程序。在Raspberry Pi上，ONNX Runtime的CPU执行提供程序通过ARM NEON指令集优化，对MobileNetV3等轻量模型可实现30-50ms的推理延迟；若搭配Hailo-8，则使用HailoRT执行提供程序，延迟可降至5-10ms。

4.3.2 操作流程：从PyTorch模型到TensorRT引擎

在Jetson上部署TensorRT引擎的标准流程如下：

# 1. 导出ONNX模型（在训练服务器上）
import torch
model = torch.load('yolov8s.pt')
dummy_input = torch.randn(1, 3, 640, 640).cuda()
torch.onnx.export(model, dummy_input, 'yolov8s.onnx',
                  opset_version=17, dynamic_axes={'input': {0: 'batch'}})

# 2. 在Jetson上构建TensorRT引擎（使用trtexec工具）
/usr/src/tensorrt/bin/trtexec --onnx=yolov8s.onnx \
  --saveEngine=yolov8s_fp16.engine \
  --fp16 --workspace=4096 \
  --minShapes=input:1x3x640x640 \
  --optShapes=input:1x3x640x640 \
  --maxShapes=input:4x3x640x640

# 3. 在ROS2节点中加载引擎并推理
import tensorrt as trt
import pycuda.driver as cuda
# 使用trt.Runtime反序列化引擎，绑定输入输出缓冲区
# 推理时通过cuda.Stream异步执行，避免阻塞ROS2回调

对于ONNX Runtime，在Raspberry Pi上的部署更为简洁：

# 安装ARM版ONNX Runtime
pip install onnxruntime==1.17.0

# 推理代码示例
import onnxruntime as ort
sess = ort.InferenceSession('yolov8n.onnx', providers=['CPUExecutionProvider'])
# 若使用Hailo-8，则改为 providers=['HailoExecutionProvider']
input_name = sess.get_inputs()[0].name
output = sess.run(None, {input_name: preprocessed_image})

4.3.3 案例拆解：TensorRT INT8量化在室内导航中的精度-速度权衡

在某仓储机器人项目中，需要在Jetson Orin NX上同时运行两个模型：一个用于检测货架上的商品（YOLOv8m，80类），另一个用于分割地面可通行区域（DeepLabV3）。两个模型串联推理导致总延迟达到35ms，加上代价地图更新和规划，闭环延迟接近180ms，超出安全阈值。

优化方案：对YOLOv8m采用TensorRT INT8量化。首先使用500张代表性图像（包含不同光照、遮挡、商品类别分布）作为校准数据集，运行trtexec --calib生成校准缓存。量化后模型大小从120MB降至32MB，推理延迟从18ms降至9ms。同时，将DeepLabV3的输入分辨率从512×512降至384×384（精度损失mIoU仅0.8%），延迟从17ms降至11ms。最终总推理延迟降至20ms，闭环延迟控制在120ms以内。

4.3.4 常见误区与总结复盘

误区一：认为TensorRT只适用于Jetson。实际上TensorRT也支持x86_64架构的NVIDIA GPU（如RTX系列），但部署在Jetson上能发挥最大能效比。若使用非NVIDIA硬件（如Intel、RK3588），应选择ONNX Runtime或RKNN。

误区二：忽略模型输入尺寸对延迟的影响。在边缘设备上，输入分辨率每增加一倍，推理延迟约增加3-4倍。建议根据实际检测距离需求选择分辨率——对于2-5米内的障碍物检测，448×448分辨率已足够，无需盲目追求640×640。

误区三：将推理结果直接用于代价地图而不做时间戳同步。ROS2的代价地图层需要知道障碍物数据的“时间有效性”。若推理延迟波动大，应使用message_filters的近似时间同步策略，将图像时间戳与推理结果绑定，避免使用过期的障碍物信息。