自动驾驶轮椅实战：车规级底盘、舵轮控制与自主避障解析

1. 为什么是“车规级底盘”而不是普通AGV底盘1.1 载人设备的失效语义和载货完全不一样先抛一个观点智能轮椅的技术难度很多时候比同一价位段的物流机器人更高。原因不在于算法多复杂、算力多强而在于“失效的后果”完全不同。一台AGV叉车或者送餐机器人失控了最多撞到一个货架、磕到一面墙损失是货物破损、无人伤亡。但轮椅上面坐着的是一位老人或者行动不便的人他可能反应慢、无法自行跳离整个设备还贴着他的身体。一旦底盘在坡道、电梯口或者马路边沿出现不可控的溜车、转向失控那就是人身安全事件。所以这个项目从一开始就没有考虑“消费级AGV底盘改造”这条路而是在设计约束上直接向车规逻辑靠拢关键控制器要有安全监控机制转向和驱动信号要有失效检测刹车除了软件逻辑之外还要有物理兜底。说白了我们可以接受一辆扫地机器人在墙角原地打转但绝不能接受一台轮椅在坡道上自己往下溜。车规级底盘在这里代表的是“冗余思维”和“失效安全”不是简单地把某个车规级电机或者通过AEC-Q100认证的芯片堆上去。真正车规级的整机设计会让你从第一行需求文档开始就去回答一个灵魂拷问如果这个部件突然失效系统会退化成什么状态是安全停住还是彻底失控这个问题贯穿了从底盘选型到避障策略的全过程。1.2 为什么选舵轮底盘而且是四舵轮传统电动轮椅基本都是差速驱动方案就是左右两个大电机轮加上前面两个万向脚轮。它的优点是便宜、结构简单、控制也容易理解通过左右轮速差就能实现转向。但差速方案在自动驾驶场景里有一个硬伤没有“转向角”这个自由度。你不能让轮椅横着平移进电梯也不能在很窄的走廊里精确地原地转向后保持车体姿态不变稍微遇到一点斜坡或者地面湿滑驱动轮的滑移就会让里程计产生明显漂移。我在这套系统里采用的是“舵轮底盘”。舵轮的本质是“自带转向电机的驱动轮”一个舵轮模组里既有轮毂电机负责行进又有独立的转向电机负责控制轮子的朝向轮子本身还带着绝对编码器。它可以向前走也可以横着走还可以原地旋转。设备在狭窄的室内环境里灵活度非常高。这个项目用的是四舵轮布局四个轮子全部具备独立转向和独立驱动能力。四舵轮方案相比双舵轮不只是灵活度更高更重要的是冗余。当一个舵轮模组发生故障时系统可以切换到对角双轮驱动模式以较低速度把用户安全送回去这种容错能力是载人设备必须考虑的。成本确实比普通差速方案贵了将近一倍多但回头想这套东西承载的不是货物是一个行动不便的人这笔钱不能省。1.3 车规级器件的落地取舍做工程的人都知道“全车规”是理想“合理分配车规和工业级”才是现实。把整台轮椅的所有部件全部做成车规级成本会非常夸张而且完全没有必要。我的做法是按下表来划分器件/模块等级理由底盘主控MCUAEC-Q100车规级控制链核心直接影响转向/驱动安全电子驻车执行器车规级涉及坡道停车和急停兜底电源管理与线束车规级耐温/耐弯折轮椅长期震动电源失效意味着全部失控轮毂电机与驱动器工业级驱动力学参数成熟车规和工业级差距不大激光雷达/深度相机工业级传感器迭代太快车规级选型反而限制升级车规级边缘服务网关按车规冗余设计承担远程监控和数据链路需断网重连、过温保护这里重点聊一下“车规级边缘服务网关”。它其实不是一个新概念在智能汽车里很常见作用是把车端控制网络与云端服务桥接起来。在轮椅上我把它定位成“通信与运维中枢”负责通过4G/5G和Wi-Fi与手机App、云平台保持连接接收远程指令比如家属的远程急停、上传电池电压和电机温度、跑OTA固件升级。它不参与实时底盘控制但一旦它死机远程监控链路就断了所以它本身要有看门狗、过压保护、断网自恢复这些车规级特性。一句话总结真正决定安全的是主控和刹车这些必须车规级感知和通信则看实际场景选型留出灵活迭代的空间。2. 底盘拿到速度指令之后舵轮的运动控制细节2.1 一个舵轮模块内部到底有什么从导航算法输出的“cmd_vel”即车体的目标速度包括前后速度vx、横向速度vy、旋转角速度ωz到车轮实际转起来、转到正确的角度这中间隔着一整个运动控制链路。每个舵轮模组内部包含这样几个部分轮毂电机负责轮子的前进/后退一般用无刷直流电机配FOC矢量控制低速扭矩大噪音也小转向电机负责把轮子转到目标角度我这里用的是伺服电机因为需要快速、精确的角度定位绝对编码器装在转向轴上断电重启后依然知道轮子当前朝向这一点非常重要。如果用了增量编码器上电后还得想办法找零点在载人设备上会非常麻烦驱动器/控制器可以是舵轮模组自带的也可以由底盘主控统一控制通信接口通常走CAN总线。底盘主控接收来自上层计算单元通常是一台运行导航与感知算法的人工智能计算盒子的速度指令然后调用舵轮运动学模型算出四个舵轮各自的目标转向角和轮速以CAN消息的形式发出去。2.2 四舵轮运动学怎么从速度指令算出每个轮子四舵轮的运动学模型理解起来不难核心是“把每个舵轮看作一个独立的速度矢量生成器”。给定轮椅车体的目标速度vx, vy, ωz现在要算出四个轮子的速度。每个舵轮安装位置不同它在车体坐标系下有一个固定坐标xi, yi所以当车体旋转时这个轮子除了要提供平动速度外还要提供一个由旋转引起的切向速度。轮子的总速度矢量就等于平动速度矢量 旋转速度矢量。得到了总速度矢量之后速度大小就是轮子的目标轮速速度方向就是转向电机的目标角度。理论公式大致是轮心位置 (xi, yi) 旋转贡献速度: V_rot_x -ωz * yi V_rot_y ωz * xi 轮子总速度: Vx vx V_rot_x Vy vy V_rot_y 轮速 sqrt(Vx^2 Vy^2) 转向角 atan2(Vy, Vx)这里比较容易被忽略的是“转向角度范围”。舵轮不能像差速轮那样无限制地转圈因为有线束和机械限位转向角通常被限制在±180度以内。当目标角度超出这个范围时控制器需要做一个非常关键的处理把转向角反向调整180度同时把轮速取反。这样的目的是保证转向电机走最短路径不至于“绕远路”而延迟响应。还有一点很实际在整车刚开始运动的时候转向电机和轮毂电机最好做“先转向后启动”的处理。如果轮子还没转到目标角度轮毂电机就以全速转起来轮胎和地面之间会产生巨大的侧向摩擦力不仅磨损轮胎还会让整台轮椅猛地晃动那个感觉非常吓人。我的做法是在转向完成之前轮速以斜坡函数缓慢爬升等到转向偏差缩小到5度以内再逐步给满。2.3 速度环、转向环、加速度限制的配合底盘控制的另一个关键问题是“平滑性”。智能轮椅的使用者是坐在上面的人不是搬运的货物加速度突变带来的推背感或急停感老人是承受不了的尤其是颈椎和腰椎本身就不好的用户。我在运动控制里做了两级限制速度级联控制舵轮模块内部是电流环、速度环、位置环转向用的级联结构。底盘主控下发的是“目标速度”舵轮内部根据当前速度做PID闭环调节保证轮速平滑过渡到目标值。整车加速度限制在底盘主控里设置了默认的加速度上限。比如直线加速不超过0.5m/s²转弯时的向心加速度不超过0.3m/s²任何上层算法下发的速度变化都要经过这个“斜坡限制器”过滤。如果导航算法突然下发一个从0到1.2m/s的大阶跃速度底盘主控会把它变成一段平滑的加速斜坡。这个设计在实际测试里很重要。曾经有一次我把加速度限制设得比较激进轮椅在检测到前方障碍物急停的瞬间坐在上面的人身体明显前倾差点从座椅上滑出去。从那以后加速度限制就直接和“用户舒适度”挂钩了。2.4 里程计标定定位精度的隐形杀手SLAM建图、自主避障、目标点导航全部依赖底盘里程计。但舵轮底盘有一个特性四个舵轮在转向、负载不均时会出现不同程度的滑移直接导致里程计漂移。我踩过的坑是前几版里程计参数用的是舵轮模组出厂标称值结果在建图测试时走的是一条直线建出来的地图却明显向一侧偏移大约走了20米就偏了0.3米左右。单看数据可能觉得还好但对于轮椅这种要在室内窄通道里运行的小型设备二三十厘米的偏差就足以让它撞上门框。解决办法是专门的里程计标定流程先让轮椅直线行驶一段距离用激光雷达和墙面对齐作为外部真值标定轮子直径的比例因子再让轮椅原地旋转一整圈用雷达的角点特征来标定轮距。标定完之后轮径误差率要控制在0.5%以内轮距误差控制在1%以内这样20米直线行驶的横摆误差才能控制在几厘米级别。话题跑远一点说这也是为什么很多做过机器人导航的人都知道一个不准确的里程计会让上层所有算法都白搭。底盘的运动学和控制是自动驾驶轮椅的物理基础基础不稳上面全是空中楼阁。3. 自主避障不是加个雷达那么简单传感器与算法是怎么配合的3.1 传感器布局的实测教训自主避障系统的第一个坑不在算法在传感器安装位置。我最初的方案是只在轮椅前方装一个单线激光雷达安装高度大约在40厘米想着能扫到椅子、桌腿这些常见障碍就行。结果一测就发现问题这个高度刚好和轮椅的扶手齐平扶手反射的激光点会形成两条“假墙”导致障碍物检测完全没法用。后来把雷达降低到离地面约25厘米才避开了扶手干扰。但紧接着又发现另一个问题25厘米能扫到低矮障碍却扫不到桌面、柜子边缘这些稍微高一点的障碍物。所以最终的传感器布置方案变成了多传感器融合前向激光雷达2D离地面约25cm负责导航和避障的主要障碍物感知车顶深度相机3D前倾角度约15度负责检测桌沿、座椅靠背、人体上半身等雷达扫不到的上方障碍前后超声波传感器组负责贴脸级近距探测特别是0.3米内的紧贴障碍以及激光雷达盲区。这里最容易被新手忽略的是超声波传感器的作用。激光雷达在近距离是有盲区的而且容易被吸光材料、黑色物体“吃掉”反射信号。超声波恰恰适合1米以内的近距离粗测把它装在保险杠前后作为最后的物理触碰预防层非常管用。另一个实测中非常抓狂的问题是玻璃门和玻璃幕墙。激光雷达打上去基本直接穿透或者只产生零散的点云轮椅很可能一头朝透明玻璃墙撞上去。我的处理是导航地图中提前标注玻璃区域并且在下发全局路径时把玻璃位置当作硬障碍。至于感知层解决玻璃检测代价有点高不如地图先验来得直接。3.2 代价地图与膨胀半径窄通道 vs 安全距离自主避障算法的核心环节之一是代价地图costmap。简单理解就是在地图上把障碍物周围的区域按“危险程度”涂上一层渐变颜色越靠近障碍物代价越高导航算法规划路径时会主动避开高代价区域。展开来说costmap由三层组成静态层来自离线建图、障碍物层来自实时传感器、膨胀层。这个项目里最有讲究的是膨胀半径怎么设。轮椅宽度约0.65米安全外扩至少要留10到15厘米这样膨胀半径基本要设到0.4米以上。可是如果项目要在宽度不到1米的窄门/窄道里通行0.4米的膨胀半径会把通道完全封死导航算法直接判定“不可通行”。我的做法是把膨胀半径做成动态可调的常规运行膨胀半径设为0.45米优先保证安全距离不与行人和障碍物贴得太近检测到窄道例如门宽小于1米且目标点在门另一侧时把膨胀半径临时降到0.38米同时把局部规划器的最大速度降到0.3m/s以内重心从“舒适安全”切换到“缓慢通过”。这个“窄道模式”看起来是一个很简单的逻辑但在实际使用中很关键。没有它轮椅会被自己设置的“安全距离”锁死在门口一步也进不去。有了它之后窄门通行率从不到30%提升到了90%以上剩下的失败场景主要发生在极端狭窄的洗手间门口。3.3 全局规划与局部规划为什么需要两套算法导航避障通常会同时运行两个层次的规划器全局规划器在建好的静态地图上用A*算法或Dijkstra算法找出一条从当前位置到目标点的全局最优路径。它只管“宏观怎么走”不考虑移动中的行人、临时出现的椅子。局部规划器在全局路径的引导下结合实时传感器数据做出短距离的避障决策。局部规划器我优先选了TEB算法Timed Elastic Band时间弹性带。TEB的思路挺有意思它把机器人未来一段时间内的位姿序列当成一条“橡皮筋”然后用图优化框架让这条带子同时满足多个约束——跟随全局路径、避开障碍物、运动学可行不能横着漂移、时间最短等最终求出每一步的速度和角速度。TEB的好处是它天然可以应对动态障碍。当传感器检测到行人走到路径前方时TEB会实时把相应位置的路径“拱”到旁边绕过。但TEB也有一堆参数需要调踩坑最多的是这几个weight_obstacle避障权重设太小会贴着障碍物走设太大会为了躲避一个很远的障碍物而大范围绕路。我实测下来的经验值是2到3之间weight_kinematics_forward_drive前行约束权重如果设得太高TEB会尽量避免后退结果在狭窄空间里经常“进退两难”。载人轮椅场景里我把它降了一些允许必要时小幅后退调整dt_ref轨迹时间步长默认0.3秒的话控制频率可能不够细腻我设成了0.2秒轨迹点的“分辨率”更高局部避障会更流畅但算力消耗也会涨一点。3.4 多传感器时间同步从“近似同步”到“硬件同步”做自动驾驶的人都知道一句话传感器数据不对齐融合就是“张冠李戴”。在轮椅上激光雷达、深度相机、超声波、底盘里程计的数据必须统一到同一时间基准下否则一个高速运动的行人在激光雷达里出现在位置A在深度相机里已经跑到位置B融合算法就会认为“这里有俩障碍”或者干脆做不了融合。工程上有两种做法第一种是软件近似时间同步。所有传感器数据都带上时间戳数据融合模块从消息队列里取“时间戳差值最小”的那几帧数据配对。这种方式实现简单适合低速场景。因为轮椅速度低设计最高速度约6km/h也就是1.67m/s即使时间戳偏差50毫秒空间误差也只有8厘米左右在可接受范围内。第二种是硬件级PTP时间同步IEEE 802.1AS也称gPTP。通过网口交换机让激光雷达、深度相机和主控同步到同一个主时钟时间戳精确到微秒级。这种方案的同步精度远高于软件方案但需要硬件支持也会增加调试成本。受限于轮椅的算力和硬件配置这个项目前期先用近似同步把功能跑通后续如果要做更多视觉与雷达的底层融合比如实时3D语义建图再切到PTP。4. ISO 34505:2025 的落地玩法把测试从“场景故事”变成“用例工厂”4.1 这套标准到底解决了什么问题2025年发布的ISO 34505:2025标题直译过来大约就是“智能驾驶测试场景——测试场景评价与测试用例生成”。它在整个ISO 3450x系列里属于非常务实的一环。理解这套标准要先知道它背后的行业痛点过去大家做自动驾驶测试很大程度靠“编故事”。测试工程师坐在会议室里照着经验想几个场景——前车切出、行人鬼探头、大雨天气——然后写成测试用例。但这种方式有两个问题第一场景覆盖完全看测试人员的个人经验覆盖率没有保证第二不同团队之间对同一个场景的理解不一致你的“前车急刹”和我的“前车急刹”可能完全不是一个速度、一个距离测试结果没法横向比较。ISO 34505:2025的核心思路是用结构化的方法描述场景在抽象程度不同的层级之间转换再通过参数化、变异、组合等方式大批量生成测试用例同时定义覆盖率和场景质量的评价方法。它给测试这件事建立了一套工业流程而不是依赖一堆“民间故事”。4.2 怎么把它用在自动驾驶轮椅的项目里有人可能会说这种标准都是给自动驾驶汽车用的和轮椅有什么关系我的实践是完全可以借鉴甚至比汽车场景更好落地因为轮椅的运行域ODD更受控。轮椅的ODD很清晰室内、低速、有地图、范围通常是一栋楼或一个小区。ODD边界清楚了场景空间的参数化就变得容易。具体落地的时候我是按下面这条链跑的列出轮椅的ODD要素运行区域室内走廊、电梯、门厅、速度范围01.2m/s、光照条件室内照明、逆光、夜间、地面类型瓷砖、水泥、地毯、天气室内基本无雨半室外要考虑小雨、人流量低密度到中密度。建立“场景模板”。比如“行人在走廊中横向穿行”“前方地面出现低矮障碍物”“电梯门正在关闭”“门帘遮挡住激光雷达”等每一类都对应到感知和规划的具体输入特征。参数化变异给每个模板的参数行人速度、出现距离、障碍物高度、光照强度设置取值范围然后按边界值和正交组合生成几十上百个具体场景。这一步看起来工作量大但一旦参数表设置好场景生成脚本一天就能跑出好几百个用例。先用仿真跑批把生成的具体场景灌进仿真环境批量跑导航和避障算法找出失败用例。失败的用例再分两类一类是测试场景本身就超出设计能力比如轮椅在暴雨天室外行驶这类用例可以作为“ODD边界”标记出来不纳入验收另一类是算法确实处理失败的比如“静态轮椅在窄通道中无法通过”这类进入实车复现名单。实车回归验证从筛选后的失败用例里挑出风险等级高的在实验场地复现验证修复效果。这套流程走下来我对ISO 34505一个很深的感触是它不一定能直接给你一个开箱即用的测试工具但它的方法论能逼着你把“感觉上应该没问题”变成“数据上确实没问题”。4.3 公开自动驾驶数据集为什么不能直接拿过来用聊数据集之前先看一个事实公开的自动驾驶数据集nuScenes、Waymo Open Dataset、KITTI这类都是给车跑在城市道路场景采集的里面的数据全部是行车视角、高速相对运动、机动车/行人混合交通场景。放到智能轮椅上会遇到很多根本对不上的地方轮椅运行高度只有1米左右传感器的视角和轿车完全不同同一个行人在汽车数据集里的bounding box和轮椅视角下的box差异非常大轮椅周围最常见的障碍物不是汽车而是座椅、茶几、门框、轮椅本身、导盲杖、垃圾桶之类这些在公开数据集的类别体系里压根没有专门定义公开数据集里几乎没有“轮椅上坡道”“电梯进出”“雨天室内地面反光”“半透明玻璃门”这类场景数据。所以这个项目的数据集最终是自己采集、自己标注的。我们的方式是这样的把激光雷达、深度相机、IMU、底盘里程计数据全部录制下来时间戳统一然后用标注工具做半自动标注。标注类别一开始只定了8类行人、助行器/轮椅、静物障碍、家具、门、墙面/隔断、坡道/路缘、其他。数据规模前几版大概只采集了几千帧但已经足够把底层的感知模型跑起来关键点是数据采集时的场景覆盖要比数量更重要——每个房间类型、每种光照、每个人流量等级都要有样本。顺便说一句自己采集数据时的第一个坑就是时间同步。如果激光雷达的时间戳和相机的时间戳差了半秒标注工具里看到的目标位置就对不上标注出来的标签全是噪声模型练出来也是歪的。5. 实测踩坑实录老人周边、窄门电梯、电子驻车与远程接管5.1 最难检测的目标坐在轮椅里的人这个坑是真实测试中才暴露的。用户坐在轮椅上下半身和轮椅骨架高度重合激光雷达从25厘米高度扫描过去扫到的点云把人和轮椅当成一个整体。一开始我用的聚类算法阈值比较大结果这个人目标偶尔和旁边的沙发腿贴在一起就被聚成了一个大障碍物轮椅在接近沙发时会绕一个大圈。更麻烦的是用户自己不动的时候。在动态障碍物检测里如果一个人长时间静止在一个位置聚类算法会把他的点云从“动态障碍”降级为“静态障碍”。这时候如果用户侧身喊家人帮忙局部规划器会把他周围的区域当作静态障碍物来绕行而绕行的路径在窄房间里可能根本没地方去于是轮椅原地“卡死”——这在产品体验上是一个不可接受的失败。解决思路分两层来看感知层对特定目标的长期点云进行“身份保持”通过深度相机的人体骨架检测对“人”类别持续跟踪即使他静止不动也不允许降到静态障碍物规划层引入“上下客模式”检测到用户坐回轮椅且准备移动时先下发一段“缓行脱离”指令把轮椅向前移动30到50厘米并与周围的静态障碍物重新拉出安全距离再交给自主导航。这个问题的教训是感知模块不能只按点云几何聚类必须和人的语义信息结合否则系统永远无法区分“沙发”和“坐在沙发边上的一个人”。5.2 窄门、电梯口、充电桩三个高频“疑难场景”在长时间的实车测试里有三类场景最容易让自动驾驶轮椅“社死”窄门、电梯口、充电桩。窄门的麻烦在膨胀半径这个前面已经详细说了。动态切膨胀半径、低速通过、必要时允许车辆做一次窄幅后退调整这三招合在一起基本能把室内常见的0.85米净宽门型跑通。电梯口则完全是另一类问题。电梯轿厢与楼层之间的缝隙在激光雷达里经常表现为一个“断崖”。轮椅是典型的非悬挂底盘如果轮子卡进电梯缝隙整个设备会彻底失去动力转向能力。另外电梯厢壁是金属反光面雷达点云会出现大量乱反射。我的处理方法包括进入电梯前先切换到“电梯模式”这个模式下轮椅会先停车利用摄像头识别电梯门是否完全打开然后用极低速度0.15m/s缓慢进入同时在进入过程中持续监测轮子下方的支撑点回传的力/编码器信号。如果检测到两个轮子之间的轮速差或倾角异常突变立即刹车并退出电梯。电梯按钮的物理操控则交给外设的机械臂或者简化成“用户在平板上点击呼叫电梯”的半自动模式不强行追求全自动。充电桩找充电口这件事其实和无人车泊车很像。底盘搭载的毫米波级高精度定位在地下车库环境经常失效我更倾向于在充电桩附近布置UWB信标做局部定位增强用传感器引导QR码对准充电口。比较务实的做法是最后0.3米用人工遥控或者用户手动插入充电枪全自动插拔充电枪的安全风险在当前阶段还是有点大。5.3 三级安全兜底机制设计聊完避障再来说一个容易被省略但对载人设备至关重要的部分安全兜底。我把它设计成三个递进层级第一层是整车急停按钮。装在用户右手边机械结构直接断开动力继电器无需经过任何软件判断。这一层是最低级的物理保护相当于传统工业设备的“拍停”。第二层是电子驻车制动。斜坡溜车是轮椅最危险的事故形态之一。底盘主控实时监测倾角传感器和轮端速度一旦检测到“车体在无速度指令的情况下发生位移”即非预期溜车立刻触发电子驻车软件控制正常失效时独立于主控的安全监控芯片也可以根据轮速信号异常变化直接拉紧驻车电机。这套机制在坡道上反复测试过最极端情况是模拟断电加溜车同时发生驻车机构仍然能在几十毫秒内锁死车轮。第三层是远程接管。边缘服务网关提供一条独立的无线链路手机App可以一键把轮椅切换成“远程遥控模式”。这个遥控不是给自动驾驶用的更多是紧急情况下的备用手段。比如用户在某个狭窄路段被卡住且无法操作轮椅家属或护理人员可以通过手机App的虚拟摇杆控制轮椅低速退出。这套三级兜底设计完成之后整个系统的安全信心才算真正建立起来。5.4 车规级边缘服务网关在整机里的角色最后再展开说一下边缘服务网关。前面提到它是“通信和运维中枢”这里补充它在实测中的具体价值。网关硬件上是一个固定在轮椅后端的小型计算板卡带4G/5G模组、Wi-Fi/BLE、CAN接口和RS485接口。它干的事情可以拆成四块远程状态监控每秒钟把整车的电池电压、单体电芯温度、电机温度、当前车速、故障码打包推送云端家属或护理人员可以在手机App里看到这些数据OTA差分升级导航、感知、底盘控制算法都在跑在Linux控制盒里网关负责从云端下载固件包校验通过后交给控制盒执行升级。OTA链路里最容易翻车的点是不能直接断点续传就结束还得做“升级失败自动回滚旧版本”的保险边缘数据处理传感器高频原始数据全部上传云端不现实网关承担一部分本地预处理比如截取异常事件前后30秒的关键数据片段再上传供开发人员离线分析远程指令透传手机App下发的远程急停、远程遥控指令经由网关转成CAN指令进入底盘主控。这里的安全设计是不管网关死活本地安全链路急停、驻车都正常独立工作网关只是多一层冗余保障。整台轮椅的完整数据链路大致是传感器 → 控制盒感知导航避障算法→ 底盘主控运动学安全逻辑→ 舵轮模组驱动执行与此同时边缘服务网关从控制盒和底盘主控抓取状态数据负责与云端和手机App交互。链路看起来不复杂但在实际的电磁环境、震动环境、网络抖动环境下每一环都需要反复测试才能稳定运行。我个人的体会是这类项目往往不是某一个算法有多难而是整个系统要把“安全可靠”和“体验可用”同时做到位。方向盘还没有整车的自主避障和车规级底盘已经先一步进入了轮椅这个细分赛道。这个项目做完之后再回看当初的选择四舵轮底盘、ISO 34505的场景化测试方法、三级安全兜底机制这三个决定都算是在最关键的位置上做对了。后续要考虑的扩展方向一个是多车协同下的楼宇级调度另一个是把坡道、雨雪天气这些边界场景进一步纳入ODD让轮椅真正能走出家门去到社区、公园这些更大范围的场景里。