机器人人群导航实战：从轨迹预测到强化学习部署指南

简介这是一份面向毕业设计、课程设计与期末大作业的机器人人群导航项目基于深度学习技术解决机器人如何在密集人群中安全自主导航的问题核心代码以Python为主适合人工智能、机器人相关专业学生复现与扩展。压缩包共含146个文件包体仅8.26MB其中95个Python源码构成算法主体另有PDF与Markdown文档、Shell配置脚本、GIF演示动画及ROS消息定义文件等覆盖模型训练、仿真测试到环境配置的完整环节。目前已有41人学习下载内容组织清晰便于按模块查阅和二次开发。项目不仅提供了完整源码与说明文档还包含仿真环境演示动图与依赖清单可帮助快速理解基于深度强化学习的导航决策流程搭建运行环境并验证算法效果对课题开题、代码调试和结题报告撰写均有直接参考价值。1. 机器人人群导航为什么传统路径规划一进人群就僵住把“基于深度学习的机器人人群导航”压缩成一个 zip 包来传播本身就说明这件事不再是论文里的演示而是一套能下载、能解压、能部署的工程方案。很多人误以为这只是给导航算法加了个“行人检测”实际做进去才发现真正的难点是让机器人在密集行人里能预测、会绕行、敢通过而不是被人群逼停后原地打转。我见过不少项目在空旷走廊里跑得很好一放进食堂、地铁闸机、医院大厅这类场景就翻车问题几乎都出在同一个地方决策逻辑里根本没有“人群”这个变量。这篇笔记就沿着一条从数据到部署的完整链路把这个方向里最常见也最关键的方案选择、参数边界和血泪踩坑讲清楚。适合正在做服务机器人、巡检机器人或仓储 AGV 的工程师也适合刚入门想复现一个深度学习导航算法但不知道从哪下手的同学。2. 人群导航不是单模型感知—预测—决策的数据流分工2.1 先拆需求人群导航到底要解决哪几个子问题人群导航这个方向在机器人领域被单独拎出来是因为它和传统导航有本质区别。传统 SLAM 加路径规划的假设是“环境是静态的”顶多把行人当成临时障碍物检测到就绕开。但人群不一样行人会走会停会转向而且彼此之间有社会交互——两个人迎面走来会自动错开一群人排队时会保持间距。你如果只是把行人框出来当障碍物机器人会表现得非常神经质行人稍微动一下路径就重规划一次最后要么在原地小碎步要么猛打方向吓到人。做这类方案我一般会把整个系统拆成三条数据流感知层负责从传感器数据里检出人和障碍物预测层负责根据行人的历史轨迹推断他接下来几秒往哪走决策层负责把预测结果融合进运动规划输出机器人的线速度和角速度。很多人一上来就用一个端到端网络把传感器数据直接映射成控制指令模型确实能跑通但你去看它的失败案例会发现很难定位问题——到底是不认识人还是预测错了还是决策策略不对互相纠缠。工程上更可靠的做法是分层做每一层独立可测再在系统层面做融合。2.2 轨迹预测单看历史轨迹不够还要看行人之间的社会交互人群导航里最值得花时间的一层是轨迹预测。如果你只把每个行人的历史坐标喂给一个 LSTM 去外推未来位置在单人场景下还能用在人群里会很快失效因为行人的行为高度依赖周围人——一个人看到对面有人走来会主动偏转两个人并肩走会保持同速这些都不是单条轨迹能学出来的。我常用的结构是图注意力网络把每个行人当作图里的一个节点节点特征是他过去 n 帧的位置和速度行人之间如果距离小于某个阈值比如 1.5 米就建一条边用注意力机制聚合邻居信息再输给一个解码器回归未来位置。代码骨架大致如下import torch import torch.nn as nn import torch.nn.functional as F class SocialAttentionLayer(nn.Module): def __init__(self, feature_dim32): super().__init__() self.query_proj nn.Linear(feature_dim, feature_dim) self.key_proj nn.Linear(feature_dim, feature_dim) self.value_proj nn.Linear(feature_dim, feature_dim) def forward(self, node_features, adjacency_mask): # node_features: [num_pedestrians, feature_dim] q self.query_proj(node_features) k self.key_proj(node_features) v self.value_proj(node_features) # 注意力分数矩阵再通过邻接矩阵屏蔽远处行人 attn_scores torch.matmul(q, k.T) / (q.shape[-1] ** 0.5) attn_scores attn_scores.masked_fill(adjacency_mask 0, float(-inf)) attn_weights F.softmax(attn_scores, dim-1) # 加权聚合邻居特征 out torch.matmul(attn_weights, v) return out这个模块做的事可以拆成三步第一步把每个人的特征分别投影成 query、key、value第二步算行人两两之间的注意力分数再用邻接矩阵把距离过远的行人屏蔽掉第三步按归一化后的权重去聚合邻居信息。注意这里有两个关键参数feature_dim 决定每个行人状态用多少维向量表达太小会丢失交互信息太大容易过拟合adjacency_mask 决定了“谁算邻居”这个阈值我在实际项目里通常取 1.2 到 2.0 米比这更大模型会学到一堆无关互动比这更小又在密集人群里漏掉关键避让信息。2.3 决策层传统代价地图与深度强化学习的路线选择轨迹预测做完接下来就是“怎么用这个预测结果控制机器人”。常见方案有两类。一类是把预测位置渲染成动态障碍物叠加进代价地图然后用 DWA 或 MPC 做局部规划——这个方案实现快、可解释性强问题在于它的“避让”是被动的行人走向哪里代价地图就把那里标红机器人永远在闪避表现不出主动绕行的能力另一类是端到端的深度强化学习让策略网络直接吃进机器人自身状态和行人预测结果输出速度指令训练目标里同时写进“到达目标”和“不撞人”的奖励这种方案能学出主动绕行的行为但训练成本高、调参玄学。我倾向于做混合结构决策层用强化学习但它的输入不是原始传感器图而是已经抽象好的状态向量——机器人相对目标的方向距离、机器人当前速度、以及每个行人的相对位置和预测轨迹。这样模型输入维度很低训练稳定性比端到端好不少。后面第三章会给出一个能跑通的最小训练环境框架这一层的关键在于训练环境的仿真保真度而不是网络结构本身。2.4 数据从哪来公开数据集、仿真合成与真机采集怎么搭训练轨迹预测需要“行人历史轨迹 未来轨迹”的配对数据。公开数据集方面常见做法是用 ETH、UCY、SDD 这类行人轨迹数据集它们包含真实的行人运动坐标适合做社会交互预训练但它们大多是俯拍视角和机器人平视相机的观测差异很大直接部署会有一道鸿沟。仿真合成数据也很重要我会用人群仿真器生成大量密集交互场景作为预训练之后的补充真机采集则是最后一道关用机器人自带传感器边走边记录行人位置标注成本高但最贴近部署环境。数据分层用的时候要注意一个比例问题纯公开数据训练出来的模型在仿真里指标很好看一上真机就现原形纯真机数据又很难覆盖足够多样的密集场景。我一般按公开数据预训练、仿真数据强化、真机数据微调这样一个三段式流程做效果最稳。3. 把训练闭环跑通一个 CrowdNav 风格的 RL 环境骨架3.1 为什么选择先做仿真闭环人群导航的强化学习训练不能直接在真机上做——机器人每撞一次人就要停下来重置数据采得慢且不安全。业界通行的做法是先搭一个高仿真的二维行人环境让机器人和仿真行人在里面交互用大量 episode 把策略练出来再迁移到真机。常见做法是参考 CrowdNav 这套设定一个二维连续空间里面有若干行人朝各自目标走机器人要穿过人群到达目标点行人会避让但不会专门让机器人。这套设定虽然几何上很简单却抓住了人群导航最核心的矛盾你的模型必须在不确定中做决策。3.2 最小可跑的环境代码状态、动作、奖励三项设计下面是一个最简环境的骨架只保留 RL 训练必需的部分。我在复现这类项目时习惯先把环境写干净再去调网络和超参。import numpy as np class CrowdNavEnv: def __init__(self, num_pedestrians5, max_steps200, goal_radius0.2): self.num_pedestrians num_pedestrians # 行人数量 self.max_steps max_steps # 单回合最大步数 self.goal_radius goal_radius # 到达目标判定半径 self.robot_max_speed 1.0 # 机器人最大线速度 m/s self.pedestrian_speed 1.2 # 行人行走速度 m/s def reset(self): # 机器人从原点附近出生目标在 8 米外行人在中间区域随机分布 self.robot_pos np.array([0.0, 0.0]) self.goal np.array([8.0, 0.0]) self.pedestrians np.random.uniform( [-4.0, -2.0], [4.0, 2.0], size(self.num_pedestrians, 2) ) self.step_count 0 return self._get_observation() def step(self, action): # action 是 [线速度, 角速度]线速度限制在 [0, 1.0]角速度限制在 [-1.0, 1.0] linear_vel float(np.clip(action[0], 0.0, self.robot_max_speed)) angular_vel float(np.clip(action[1], -1.0, 1.0)) # 简单运动学模型更新机器人位姿 theta np.clip(angular_vel, -1.0, 1.0) self.robot_pos np.array( [linear_vel * np.cos(theta), linear_vel * np.sin(theta)] ) self.step_count 1 # 判断到达目标和碰撞 dist_to_goal np.linalg.norm(self.robot_pos - self.goal) reached dist_to_goal self.goal_radius collision self._check_collision() reward 1.0 if reached else -0.1 if collision else -0.01 done reached or collision or (self.step_count self.max_steps) return self._get_observation(), reward, done, {} def _check_collision(self): # 机器人半径 0.2行人半径 0.2距离小于 0.4 视为碰撞 for p in self.pedestrians: if np.linalg.norm(self.robot_pos - p) 0.4: return True return False def _get_observation(self): # 观测向量机器人相对目标的方向与距离 每个行人的相对位置 obs [self.goal - self.robot_pos] for p in self.pedestrians: obs.append(p - self.robot_pos) return np.concatenate(obs).astype(np.float32)这份代码里的动作空间和奖励设计是训练的胜负手。动作空间我故意限定了线速度只能为正不让机器人后退——实际机器人倒车避让行人很危险不如从一开始就约束它只能前进绕行。奖励系数上“到达 1.0”是稀疏主奖励“碰撞 -0.1”和“每步 -0.01”的时间惩罚是用来防止两个极端行为的如果没有碰撞惩罚模型会学会无视行人猛冲如果没有时间惩罚模型会学会停下来不动因为不动永远不会撞人。3.3 reward shaping让机器人学会“绕行”而不是“急停”直接用上面的原始奖励训练你会发现策略收敛很慢而且经常收敛到一个很怂的策略机器人远远看见人就减速停住直到行人走开才继续前进。在指标上它确实没撞人但任务完成时间爆炸这叫“freeze robot”问题是人群导航 RL 训练里最典型的失败模式。解决办法是加 shaped reward核心思想是让机器人根据行人预测位置主动避让而不是等行人到眼前再急停。我会在原始 reward 上加一个“前进进度项”机器人每一步靠近目标的距离增量乘以一个正系数同时加一个“碰撞风险项”——如果机器人与行人的预测轨迹在未来 2 秒内相交就给一个小的负惩罚这样模型会学会加速通过缝隙而不是停在原地。系数我常用的量级是前进进度 0.1、碰撞风险 -0.05具体要跟着训练曲线调一个经验是如果训练曲线显示平均步数降不下来就加大前进进度项如果碰撞率降不下来就加大碰撞风险项。3.4 观测与动作空间的边界别把网络搞得过于复杂很多初学者在复现时总想把观测维度做得越全越好加上行人朝向、加上行人速度、加上机器人自身里程计噪声。实际上观测维度翻倍训练所需样本量往往要翻好几倍而人群导航的决策本质更依赖“相对距离变化”和“未来轨迹交叉”而不是对每个行人状态的精确估计。我建议第一版观测就保持“机器人相对目标 行人相对位置 行人当前速度”三个部分拼接维度过百以后先想怎么降维而不是再加输入。另外动作空间也不要一开始就上二维连续可以先试试离散动作“左转、右转、前进、减速”策略先学稳定再换连续控制工程进度反而快。4. 从仿真到真机模型导出、推理频率分配与部署管线4.1 模型导出PyTorch 到 ONNX 要固定输入输出仿真里跑通策略网络之后下一步是把它放进机器人的计算单元里。常见流程是先把 PyTorch 模型导出成 ONNX再用 TensorRT 或 ONNX Runtime 做推理。导出时最容易翻车的地方是输入输出的动态维度。PyTorch 模型在仿真里可能接受任意数量的行人导出 ONNX 时如果设置了动态轴TensorRT 会生成多份优化内核推理变慢不说还可能出现莫名的内存报错。我一般在导出前先做一件事把行人数量固定成训练时的上限比如 8 个行人不够就用全零向量补齐同时用一个 mask 告诉网络哪些行人是无效的。这样输入形状变成 [1, 8, feature_dim]输出也是固定形状后续部署路径顺畅得多。4.2 推理频率分配检测、预测、规划各跑多少 Hz真机部署时三个模块的运行频率不能一刀切这是我从实际系统里测出来的经验。相机行人检测最吃算力YOLO 级别的检测器在边缘设备上跑到 10Hz 左右就算不错了行人轨迹预测网络输入输出都是轻量张量跑 20Hz 没压力但底层运动控制的频率必须高否则机器人会走得很顿挫。我常用的分配是检测模块: 10Hz每 100ms 刷新一次行人边界框 预测模块: 10Hz跟随检测结果预测未来 3 秒轨迹 规划决策: 30~50Hz高频采样策略网络或路径跟踪控制器检测和预测同步跑 10Hz 是为了让预测始终基于最新的行人位置规划模块 30Hz 以上是为了让机器人在两次预测之间也有平滑的速度输出。如果你发现机器人过人群时频繁急停别急着调策略网络先看看规划模块是不是被阻塞成和检测一样低了。4.3 真机推理管线串接一份可参考的最小实现串接三个模块的代码可以浓缩成下面这段逻辑。这里略去了具体的传感器驱动专注展示频率控制和数据流转import threading import time import numpy as np import onnxruntime as ort class NavigationPipeline: def __init__(self, detect_model_path, predict_model_path, policy_model_path): self.detect_sess ort.InferenceSession(detect_model_path) self.predict_sess ort.InferenceSession(predict_model_path) self.policy_sess ort.InferenceSession(policy_model_path) self.latest_pedestrians None self.latest_trajectory None def run_detection(self, camera_frame): # 假设输入是 [1, 3, H, W] 的 RGB 图像输出是行人中心点坐标列表 results self.detect_sess.run(None, {input: camera_frame})[0] self.latest_pedestrians results # shape: [N, 2] def run_prediction(self): if self.latest_pedestrians is None: return ped_input self._pad_pedestrians(self.latest_pedestrians) self.latest_trajectory self.predict_sess.run( None, {pedestrian_history: ped_input} )[0] def compute_control(self, robot_state): # 把机器人状态和预测轨迹拼成策略网络输入输出 [线速度, 角速度] obs self._build_observation(robot_state, self.latest_trajectory) action self.policy_sess.run(None, {obs: obs})[0] return action这段代码的关键在于每个 run 函数被调度线程以不同频率调用而不是在一个 while 循环里顺序执行。我在实际系统里会用三个独立线程分别跑检测、预测和控制共享变量加锁保护这样检测慢了不会拖累控制频率。_pad_pedestrians 函数就是把行人数量补齐到固定的 8超出 8 个行人时只保留距离最近的前 8 个这是人群导航真机部署里一项很重要的工程决策在极端密集场景策略网络基于 8 个行人的输入决策远好过让它处理长度不定的列表导致推理卡顿。4.4 坐标变换与传感器选型一个容易被忽略的硬门槛深度学习模型在仿真里吃的是干净的世界坐标真机上要把相机检测到的像素坐标转换成机器人坐标系下的相对坐标这一步涉及相机内参、外参和畸变矫正。很多项目在仿真里指标很高一上真机机器人就原地转圈排查到最后发现是深度估计错了——单目相机测距在 5 米以外误差超过 20%行人位置抖动传进预测网络预测轨迹自然乱跳。我的建议是如果预算允许优先用带深度信息的传感器比如深度相机或激光雷达配合行人检测如果只有单目那就在预测网络输入端加一层速度滤波行人坐标先做卡尔曼平滑再进模型能挡住大部分传感器噪声。5. 避坑人群导航实战里我翻过车的 5 个问题5.1 仿真里能穿过人群真机上却频繁急停现象策略网络在 CrowdNav 风格环境里训练得很好成功率 95% 以上部署到真机后机器人一进人群就减速甚至停住不动。原因仿真里的行人运动是平滑的、可预测的真机上行人检测框有抖动预测轨迹在时间轴上跳来跳去策略网络看到了“未来轨迹频繁交叉”的假信号触发了保守避让。解决检测结果先做时间平滑轨迹预测网络输入用平滑后的坐标另外在仿真训练时给机器人观测注入高斯噪声让策略网络对观测不确定性更鲁棒。5.2 行人数目变了模型推理直接报错现象仿真里固定了 6 个行人带到另一个场景有 15 个行人推理程序报维度不匹配。原因导出的 ONNX 模型输入维度固定没有做归一化处理。解决所有模型统一固定最大行人数为 20输入做零填充并让网络额外接收一个有效行人计数把计数和填充 mask 都作为输入的一部分。这个改动要同时改训练数据和导出配置不能只改部署端。5.3 检测频率太低预测轨迹永远滞后现象机器人在人群中走得忽快忽慢看起来像“喝醉了”。原因检测、预测、规划三个模块跑在一个线程里检测耗时 200ms整个循环被拖慢到 5Hz。解决把检测和预测拆到独立线程控制线程只读取最新的预测结果。如果计算资源实在不够可以把检测模型输入分辨率从 640 降到 416用一点精度换控制频率的稳定。5.4 训练奖励里没有避让惩罚机器人学会了贴人走现象训练曲线显示任务完成率很高但看仿真回放机器人每次都从行人身边 10 厘米处擦过去让人非常不舒服。原因奖励函数只写了“到达”和“碰撞”没有考虑安全距离裕量策略钻了评价指标的空子。解决给碰撞判定加一个软边界——距离行人小于 0.5 米时给一个连续的小负奖励距离越近奖励越负而不是等 0.4 米硬碰撞才惩罚。5.5 解压项目包后代码协议不一致复现翻车现象从网上拿到一个声称“开箱即用”的项目包解压后按 README 跑训练损失曲线诡异效果远不如论文。原因这类项目包通常只包含一份代码快照训练数据的预处理协议、行人坐标系的定义、奖励函数的版本都可能在某个版本演进中改过README 却没同步更新。解决拿到包第一件事不是跑训练而是先检查数据加载代码里坐标系是全局坐标还是机器人相对坐标、奖励函数注释里的参数和实际代码是否一致、模型权重文件的哈希值与模型定义代码是否匹配这三个地方最容易埋雷。6. 进阶验证用多智能体压力测试和轨迹回放给导航决策“算账”仿真训练和真机部署都稳定之后还需要回答一个问题这个导航方案到底值不值得投入只看“成功率”不够我一般额外跑两类验证多智能体压力测试和真实轨迹回放。多智能体压力测试是在仿真环境里逐步增加行人密度从 3 人、6 人、9 人一直到 20 人看机器人完成任务的通过时间、碰撞次数、急停次数随密度变化的曲线。这个测试能暴露模型的性能边界——大多数模型在行人密度超过某个阈值后通过时间会陡增这就是它的真实容量。真实轨迹回放则是把真机采集的行人运动数据灌进仿真器让机器人重新导航一遍这一步能区分“模型能力不够”和“传感器噪声干扰”两个因素因为传感器数据是固定的模型表现变差就纯粹是策略问题。评估指标方面我常用的表格如下指标名计算方式合格标准任务成功率到达目标次数 / 总测试次数大于 90%平均通过时间从出发到到达消耗的秒数比空旷环境慢不超过 30%安全距离侵入频率机器人距行人小于 0.5 米的次数 / 总步数低于 1%急停次数线速度从大于 0.3m/s 骤降到 0 的次数每 100 米不超过 2 次这四个指标里我最看重最后一项。急停次数是用户体验的“体温计”机器人急停越频繁周围的人越觉得它不可预测越不敢靠近它。如果你在压力测试中发现急停次数偏高先别急着加网络层数回头检查奖励函数里的时间惩罚系数通常能更快见效。我现在拿到任何一套人群导航方案第一件事永远不是看演示视频而是先问训练数据的行人密度分布长什么样——因为边界就在那里。希望这些路径和参数能帮你少走一段弯路。本文还有配套的精品资源点击获取