记忆驾驶入门：不靠感知，用轨迹录制与重放实现路线跟踪

Driving on Memory直译是“靠记忆开车”。第一次看到这个项目名容易往端到端自动驾驶、高精地图、多模态感知上联想但它实际解决的是一个更朴素的问题在没有高精地图、没有稳定外部定位、甚至没有复杂感知模型的场景里让一辆车、一台机器人或者一个仿真里的移动小车按之前走过的路线自动再走一遍。它最有价值的一点是门槛不高不需要 GPU不需要大量标注数据不需要车道线模型一套坐标记录、一段轨迹重放就能讲清楚“机器如何把路线记住再根据记忆执行”。对刚接触自动驾驶控制、机器人路径规划、轨迹复现或者模仿学习数据采集的人来说这是一个很合适的入门落地点。下面我把这条“记忆驾驶”路线的完整拆解写出来包括环境准备、数据格式、录制回放流程、参数调试、内存成本以及真正从单任务走向批量时会踩的问题。1. 先把它理解成“录轨迹 放轨迹”而不是“实时感知 规划”先说结论Driving on Memory 这类项目工程上最常见的实现不是去训练一个会开车的神经网络而是把“记忆”当成数据管道的核心。第一条路线由人手动控制车辆或模型走一遍系统按固定频率记录车辆坐标、朝向、速度、时间之后进入记忆模式车辆不再依赖实时目标识别而是根据当前自身位置从已记录的轨迹中找目标点并跟踪过去。1.1 它和实时自动驾驶的主要差异传统自动驾驶或者移动机器人导航链路通常是这样传感器感知当前环境 - 识别车道线、障碍物、可通行区域 - 规划一条无碰撞路径 - 底层控制器跟踪路径。Driving on Memory 的思路更短是否知道当前位置 - 当前位置离记忆轨迹上哪个点最近 - 向记忆轨迹的某个前瞻点行驶。它不需要理解场景里有什么只需要回答“我在哪”和“我该去哪”。所以它本质上是路径跟踪任务不是环境理解任务。这里要区分一个容易混淆的点普通导航 App 也有路线记忆和路径重规划但那种记忆是地图上的静态道路路径车辆实际执行时仍然依赖实时定位、路口判断和交通规则。Driving on Memory 更接近机器人领域的“示教回放”记的不是地图而是执行过的轨迹、速度曲线和车辆姿态。两者底层逻辑不一样。1.2 它适合什么场景不适合什么场景适合的场景很明确固定路线重复作业比如园区巡检、仓库沿固定路径搬运、室内演示。教学示范场景先由人手推或者遥控一遍之后让车自己复现。采集专家轨迹数据为后续模仿学习、行为克隆提供训练样本。仿真环境里的控制算法验证先把轨迹录下来再反复测试不同控制器效果。不适合的场景一句话讲完不能用记忆对抗不确定性。如果路线上经常出现临时行人、搬动物体、车辆、施工区域单靠轨迹回放一定会出问题。因为车辆并不知道前方有没有障碍物它只记得“这个位置应该怎么走”。想要在动态环境里安全运行必须在记忆轨迹之上再加一层实时感知和安全停车逻辑。1.3 记忆里到底该放什么很多初学者会把“记忆轨迹”简化成一张坐标点列表。坐标确实是最核心的但如果只存 x、y回放时会发现车速控制不住转弯处车辆姿态也很难保持。一个可用的记忆点至少应该包含这几项位置x、y表示车辆或模型在地图坐标系中的位置。朝向yaw车辆或模型车头的方向用于转向判断。速度建议记录每个点的期望速度回放时直接复用。时间戳用于判断这段轨迹是慢速段还是快速段以及后续做时间对齐。如果后面要做视觉相关的扩展还可以在部分路点上挂一张图像或者一个特征描述子。但基础项目里先不要把图像塞进轨迹管道。图像一多内存、磁盘、处理速度都会明显变差后面会专门讲这个问题。2. 搭建最小运行环境纯软件也能起步低配机器就能跑我觉得首次尝试 Driving on Memory不需要一步到位上实车更不应该一上来就买一堆硬件。先用软件把数据记录、保存、回放的闭环跑通概念清楚了再换真实小车或者仿真器这才是最稳的顺序。2.1 环境条件和设备选型先说纯软件方案。一台普通电脑就行不需要独立显卡。常见实现会用到 Python 和几个基础库比如用于数值存储的 numpy、用于绘制轨迹的 matplotlib如果以后接入摄像头再引入 OpenCV。我没有办法替你确定具体版本因为项目依赖和操作系统不同建议落地之前先确认 Python、numpy 以及你所用仿真包的版本。再说半实物方案。一辆带编码器或惯性测量单元的小车配合一块能跑 Python 的开发板或者工控机就足够完成基础记路和回放。模型种类可以是双轮差速小车也可以是阿克曼转向小车但控制接口不同实车参数要以你的平台说明书为准。下面这个表可以帮你判断自己适合从哪个方案进入方案形态需要什么能验证什么难度纯软件坐标回放普通电脑轨迹记录、重放、控制逻辑低仿真器回放笔记本、仿真环境里程计噪声、控制器参数、状态估计中小型差速小车带编码器小车、开发板实车循迹、定位漂移、地面打滑影响中高带视觉版本小车加摄像头视觉记忆、回环识别辅助定位高2.2 用一个统一结构表达“记忆轨迹”无论最终跑在仿真还是实车我建议先把记忆点数据结构固定下来。这样录制、保存、抽稀、回放、可视化都可以复用同一套格式。一个比较简单的方式是定义成类似这样的数据点from dataclasses import dataclass dataclass class MemoryPoint: x: float # 横坐标 y: float # 纵坐标 yaw: float # 车头朝向单位弧度 speed: float # 期望速度 t: float # 录制时间戳正式跑的时候用 Python 的 dataclass 不一定是最省内存的做法但好处是字段直观、调试方便。如果要追求性能可以把多个 MemoryPoint 转成 numpy 数组只保留浮点列后面再索引。这里给的是示例结构实际字段命名和单位要以你自己的平台为准。2.3 为什么时间和频率很重要只存坐标会出现一个典型问题车辆在直道上开得很快转弯处开得很慢如果录制时每隔固定距离采一个点那么慢速弯道会堆积很多点直道反而点很少。回放时直道目标点跳变得很快控制器容易跟不上。更合理的做法是按固定时间频率采样比如 10Hz 到 30Hz。这样每个点之间的距离实际上反映了车辆当时的行驶速度直道上的点离散、弯道上的点密集天然保留真实运动状态。时间戳的另一个用处是后续做时间对齐如果回放时希望速度曲线和录制时保持一致就必须知道相邻两个记录点之间的时间间隔。3. 跑通一条“记路—回放”的完整链路这一轮目标只有一个让一套记录好的轨迹能回到最初的起点再按轨迹完整走一遍。不要追求速度更不要一次加入避障、视觉识别等功能。先把最小链路跑通。3.1 第一步手动录制轨迹录制阶段需要一个人量输入常见方式是遥控器、键盘方向键、游戏手柄或者直接用手推车同时记录编码器数据。操作上有一个原则速度尽量平稳转向不要忽大忽小。因为这一段轨迹会被当成“标准答案”如果录制时车辆都在画龙回放只会把这种不稳放大。采样代码的骨架类似这样import time memory_points [] record_hz 20 while keep_recording: x, y, yaw read_pose() # 根据你的传感器实现 speed read_speed() # 读取当前速度 memory_points.append(MemoryPoint(x, y, yaw, speed, time.time())) time.sleep(1.0 / record_hz)这里的 read_pose 和 read_speed 在纯仿真里可以是模拟器返回的真实状态在实车上是编码器里程计、惯性导航或者外部定位给出的估计。录制时要留意第一次使用里程计时起始位置和角度是否归零否则后面轨迹很难对齐。3.2 第二步把轨迹保存下来录制完以后内存里的 memory_points 只是临时数据直接关程序就丢了。保存时我建议优先使用固定列格式的数组不要直接存 Python 对象。原因有两个第一numpy 数组体积小、读取快第二后续做轨迹处理比如抽稀、坐标变换、插值都不需要先写一堆对象解析逻辑。import numpy as np arr np.array( [[p.x, p.y, p.yaw, p.speed, p.t] for p in memory_points] ) np.savez(route_01.npz, trajarr) loaded np.load(route_01.npz)[traj]如果你更习惯 JSON也可以保存但要注意浮点数精度和文件体积坐标值在小数点后六位以上JSON 文本会膨胀得很快。文件路径也值得提前规划尤其是后面会录多条路线时建议用 route_id 作为文件名前缀避免 route_1、route_2 这种含义不清的命名。3.3 第三步按记忆回放回放阶段的核心循环是不断读取当前位置在记忆轨迹中找到最近点选择一个稍远的目标点然后根据目标点计算转向和速度。这是一个典型的预瞄跟踪思路。for step in range(max_steps): x, y, yaw read_pose() nearest_idx find_nearest_index(loaded[:, :2], np.array([x, y])) target_idx min(nearest_idx lookahead_step, len(loaded) - 1) target_x loaded[target_idx, 0] target_y loaded[target_idx, 1] target_speed loaded[target_idx, 3] steer pure_pursuit_steer(x, y, yaw, target_x, target_y) set_control(target_speed, steer) time.sleep(control_period)这里 find_nearest_index、pure_pursuit_steer、set_control 要根据你的平台自己实现上面这段只是演示整个循环长什么样。不要把这几个函数当成现成可用的库函数。3.4 第一遍跑通后看什么判断第一遍是否成功不能只看车“好像走到了终点”。我会按照下面顺序确认起始点是否和录制时的起点接近。终点是否在合理误差范围内。回放过程中车有没有明显冲出轨迹又拉回来。转弯处车辆有没有原地打转、反向摆动或越过路沿。速度曲线是否和录制时接近而不是忽快忽慢。只要以上几条有问题先不要改控制器参数先回到“记忆本身”排查。很多时候不是控制不好而是轨迹记录时坐标原点没有统一或者采样频率太低把弯道细节丢了。4. 从“大概能走”到“走得稳”参数、验证和避坑很多项目能跑通 demo但距离“可以重复跑 100 次不翻车”还差很远。问题往往不是出在某一个模块而是出在参数和验收标准不清晰。4.1 定义容易判断的验收指标我建议在项目开始之前就把“成功”定义清楚否则很容易陷入“看着还行但说不出到底行不行”的状态。下面是一组比较基础的评价维度评价维度判断方式常见可接受范围终点误差回放终点与录制终点的直线距离低要求下米级精细控制下厘米级横向偏差车辆实际位置到最近记忆点的垂直距离实车通常控制在几厘米到几十厘米转向稳定性转向输出是否高频抖动不出现持续振荡速度一致性回放速度与记忆速度的差异目标速度的 10% 以内可作为参考完成率完整走完路线的次数 / 尝试次数生产场景应从低到高逐步验证需要注意的是这些“可接受范围”没有统一标准取决于车辆尺寸、路面情况、定位精度和任务要求。上面给的是经验参考真正验收要以你的环境为准。4.2 几个会影响效果的参数回放跟踪类项目调来调去通常围绕这几个参数采样频率录制频率太低弯道轨迹会被拉直太高数据量变大处理压力上升。建议从 10Hz 到 30Hz 起步。路点抽稀如果直接在原始轨迹上找最近点每帧都去遍历几万个点效率很低。可以先按距离阈值抽稀保留关键转折点。预瞄距离或预瞄点数预瞄太短车会贴着目标点来回修正容易抖动预瞄太长转弯时会明显切弯甚至压到内侧。预瞄距离一般与速度相关速度快时拉长一点。控制周期回放循环不要用一个点和另一个点无限制地空转应当有固定的控制周期通常是 20Hz 到 50Hz。转向增益增益太小车辆反应迟钝轨迹偏差难收敛增益太大系统容易振荡跑出来的曲线像锯齿。哪个参数对结果影响最大要结合你的平台看。阿克曼转向车和差速小车的手感差异很明显前者更关心预瞄距离和转向增益后者更关心左右轮速差的计算方式和底盘响应时间。4.3 调参时保持“一次只动一个变量”这条看起来像废话但我见过不少现场问题就是因为同时改了预瞄距离、PID 参数和最大速度最后出了问题根本不知道是谁造成的。更稳妥的做法是每一轮只改一个参数并且每改一次就跑同样的路线记录一次轨迹。有条件的项目可以把回放轨迹和录制轨迹画在同一张图上用肉眼或脚本计算两条线的偏移。纯文本日志只能告诉你“有没有超速”没法告诉你“是不是在第一个弯就切错了”所以可视化非常值得做。4.4 从慢速开始不要一开始就挑战极限第一版参数我建议设置一个很低的最大速度比如差速小车上限设成 0.2 到 0.5 米每秒仿真环境也类似。低速情况下的系统延迟、转向死区、里程计漂移不容易暴露但正因为不容易暴露一旦高速跑起来就很容易翻车。先把低速下偏差稳定控制在可接受范围内再逐步提高速度上限每次提速后用同一组验收指标重新评估。很多人问要不要用 PID 控制器。如果只用最近点作为目标车辆会不停修正最近点动态性能很差。给控制器加一个简单的纯跟踪或 PID 面向角度误差效果会立竿见影。具体实现不复杂思路就是计算当前车辆朝向与目标点方向之间的夹角差用比例或者比例加积分的方式输出转向。5. “Memory”的成本不只是抽象记忆真实的内存和磁盘也会被吃掉这个项目的标题里有个容易被人忽略的词Memory。在录轨迹、存轨迹、回放轨迹的过程中Memory 既指机器“记住路线”的能力也指程序运行时的真实内存开销。很多人只在功能层面跑通了没算过高频采样下数据涨得多快。5.1 高频采集会让数据快速膨胀假设以 20Hz 的采样频率记录 x、y、yaw、speed、time 五个浮点数每个浮点用 float64 存储每秒会产生 100 个浮点数。如果直接算裸数据一小时约 2.8MB这个量听起来很小。但实际项目不会只存这 5 个字段如果每个 MemoryPoint 是 Python 对象叠加对象头和列表指针一小时的数据很容易涨到几十 MB。如果额外保存摄像头画面假设一帧压缩后 100KB20Hz 采样一小时就是 7.2GB 左右。如果再保存车辆状态、控制日志、传感器原始值内存和磁盘会涨得更快。所以第一步是先明确你的 MemoryPoint 里到底放了什么东西。凡是回放时用不到的字段都不应该进入高频主轨迹。它们可以放到单独的日志文件里按需分析。5.2 把“原始录像”和“导航路点”分开我比较推荐把数据拆成两条线一条是“原始记录”给训练、回溯、调试用另一条是“导航路点”给实时回放用。两者内容相同密度不同。原始记录可以保留所有点。导航路点在加载后先做抽稀通常用距离阈值或者角度变化判断如果当前点与上一个保留点距离小于阈值同时方向变化很小就跳过。抽稀后的轨迹可能只剩原来的十分之一甚至更少但车辆跟踪效果不会变差。真正的弯道点、路口点会被保留下来。抽稀不是简单跳点。直接每隔 5 个点取一个有可能把弯道处的关键转折丢掉。更好的方式是基于几何特征保留“方向变化大”和“速度变化大”的位置。这个判断不需要很复杂几百行以内的简单算法就够了。5.3 大批量任务里内存和日志是隐藏炸弹当项目从一条轨迹变成几十条轨迹甚至形成批量回放任务时最容易出现的问题是不加控制地累积内存。常见错误有两类。第一类是在启动时把所有路线一次性读进列表以后每加一条路线常驻内存就多一份。几十条路线还好到几百条时低配设备会很吃力。更好的做法是任务队列化管理一次只加载当前要跑的一条轨迹跑完记录结果释放路径对象后再加载下一条。第二类是日志只增不减。回放循环里如果每帧都往内存 list 里追加一条调试记录又忘记定时落盘和清空几小时下来内存占用会直线上升。建议控制循环日志只保留最近 N 条需要完整记录时直接写到文件而不是全部堆在内存里等最后统一写。6. 跑歪了、卡住了怎么排查以及如何向真正常用的方向扩展最后这部分是写给真正要把项目落地的人。单条 demo 谁都能跑通但一旦涉及实车、多路线、批量任务或者二次开发问题才会成规模地出现。6.1 排查从现象到根因按顺序来我建议遇到问题不要先改 PID更不要先怀疑是算法能力不够。按下面的顺序排查多数问题能快速定位先看现象。车是跑偏、抖动、原地打转、停止不动还是速度失控不同现象指向完全不同的原因。再确认坐标系。录制和回放是否使用了同一个原点、同一个单位、同一个角度范围很多“越跑越偏”根本原因是两次坐标没有对齐。检查定位输入。实车使用里程计时轮胎打滑、编码器方向装反、轮子直径不准都会导致位置漂移。如果定位本身有误差轨迹跟踪再准也没有用。检查轨迹本身。先画出录制轨迹确认没有飞点、跳变、单位错误、方向倒置。轨迹坏了下游所有环节都会坏。检查数据管道。回放时读的是抽稀后的路点还是原始轨迹索引计算有没有边界越界找最近点时是否把目标点取到身后去了最后才是控制参数。把预瞄距离、转向增益、车速上限按顺序调整。下面这张表可以对照使用现象优先排查常见原因整体轨迹偏移坐标原点、定位漂移录制和回放坐标系不一致起步就转圈最近点索引方向目标点取到了当前位置后方抖动严重转向增益、控制频率增益过高或控制周期太慢弯道切弯预瞄距离、路点抽稀预瞄太远或弯道点丢失直道跑不直底盘机械、轮速控制左右轮响应不一致越走偏差越大里程计漂移长时间累计误差未修正6.2 多路线和批量管理的实际建议如果你要把这个项目用于固定路线重复作业建议从最开始就把每条路线当一条独立数据资产管理而不是只有一个“最后的轨迹”文件。每一条轨迹除了坐标数据最好还要记录以下几个元信息路线编号、车辆平台、录制时间、录制速度上限、定位来源、路点抽稀参数、使用算法版本。后面一旦出现某条路线结果差你可以通过元信息快速判断是不是因为录制环境和回放环境不同。批量回放时还需要考虑失败重试机制。不是每条轨迹都能一次成功尤其是实车场景。建议输出目录提前按路线 ID 区分每次回放生成独立结果文件日志里记录开始时间、结束时间、是否成功、最大偏差、异常原因。这样即使某些路线失败也可以单独重跑而不是整批推倒重来。6.3 下一步扩展从轨迹记忆走向经验累积Driving on Memory 可以是一个停留在 demo 阶段的小项目也可以是一条更复杂链路的起点。最自然的扩展方向是拿着这些轨迹去训练模仿学习模型把传感器画面、车辆状态作为输入把方向盘转角、油门踏板作为输出。此时记录阶段采集的轨迹就是最宝贵的训练数据。另一个方向是加入视觉记忆辅助定位。当里程计漂移越来越严重时可以让车辆识别已记录的关键帧然后重新校正自己当前位置。这已经超出了“纯轨迹回放”的范围但它的底层仍然依赖一个高质量的记忆数据系统。如果只是学习默认配置够跑通就行如果要长期使用我更建议先把数据格式、保存路径、日志策略、批量队列这些整理干净。踩过几次之后会发现很多问题不是工具能力不够而是前置数据和运行环境没有处理干净。把一次 demo 跑稳再考虑扩展比一上来追求“万物都能走”要可靠得多。