企业官网建设流程全解析

1. 为什么是“车规级底盘”，而不是普通AGV底盘

1.1 载人设备的失效语义，和载货完全不一样

先抛一个观点：智能轮椅的技术难度，很多时候比同一价位段的物流机器人更高。原因不在于算法多复杂、算力多强，而在于“失效的后果”完全不同。

一台AGV叉车或者送餐机器人失控了，最多撞到一个货架、磕到一面墙，损失是货物破损、无人伤亡。但轮椅上面坐着的是一位老人或者行动不便的人，他可能反应慢、无法自行跳离，整个设备还贴着他的身体。一旦底盘在坡道、电梯口或者马路边沿出现不可控的溜车、转向失控，那就是人身安全事件。

所以这个项目从一开始就没有考虑“消费级AGV底盘改造”这条路，而是在设计约束上直接向车规逻辑靠拢：关键控制器要有安全监控机制，转向和驱动信号要有失效检测，刹车除了软件逻辑之外还要有物理兜底。说白了，我们可以接受一辆扫地机器人在墙角原地打转，但绝不能接受一台轮椅在坡道上自己往下溜。

车规级底盘在这里代表的是“冗余思维”和“失效安全”，不是简单地把某个车规级电机或者通过AEC-Q100认证的芯片堆上去。真正车规级的整机设计，会让你从第一行需求文档开始就去回答一个灵魂拷问：如果这个部件突然失效，系统会退化成什么状态？是安全停住，还是彻底失控？这个问题贯穿了从底盘选型到避障策略的全过程。

1.2 为什么选舵轮底盘，而且是四舵轮

传统电动轮椅基本都是差速驱动方案，就是左右两个大电机轮，加上前面两个万向脚轮。它的优点是便宜、结构简单、控制也容易理解，通过左右轮速差就能实现转向。但差速方案在自动驾驶场景里有一个硬伤：没有“转向角”这个自由度。你不能让轮椅横着平移进电梯，也不能在很窄的走廊里精确地原地转向后保持车体姿态不变，稍微遇到一点斜坡或者地面湿滑，驱动轮的滑移就会让里程计产生明显漂移。

我在这套系统里采用的是“舵轮底盘”。舵轮的本质是“自带转向电机的驱动轮”，一个舵轮模组里既有轮毂电机负责行进，又有独立的转向电机负责控制轮子的朝向，轮子本身还带着绝对编码器。它可以向前走，也可以横着走，还可以原地旋转。设备在狭窄的室内环境里灵活度非常高。

这个项目用的是四舵轮布局，四个轮子全部具备独立转向和独立驱动能力。四舵轮方案相比双舵轮，不只是灵活度更高，更重要的是冗余。当一个舵轮模组发生故障时，系统可以切换到对角双轮驱动模式，以较低速度把用户安全送回去，这种容错能力是载人设备必须考虑的。成本确实比普通差速方案贵了将近一倍多，但回头想，这套东西承载的不是货物，是一个行动不便的人，这笔钱不能省。

1.3 车规级器件的落地取舍

做工程的人都知道，“全车规”是理想，“合理分配车规和工业级”才是现实。把整台轮椅的所有部件全部做成车规级，成本会非常夸张，而且完全没有必要。

我的做法是按下表来划分：

这里重点聊一下“车规级边缘服务网关”。它其实不是一个新概念，在智能汽车里很常见，作用是把车端控制网络与云端服务桥接起来。在轮椅上，我把它定位成“通信与运维中枢”：负责通过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边界清楚了，场景空间的参数化就变得容易。

具体落地的时候，我是按下面这条链跑的：

1. 列出轮椅的ODD要素：运行区域（室内走廊、电梯、门厅）、速度范围（0～1.2m/s）、光照条件（室内照明、逆光、夜间）、地面类型（瓷砖、水泥、地毯）、天气（室内基本无雨，半室外要考虑小雨）、人流量（低密度到中密度）。

2. 建立“场景模板”。比如“行人在走廊中横向穿行”“前方地面出现低矮障碍物”“电梯门正在关闭”“门帘遮挡住激光雷达”等，每一类都对应到感知和规划的具体输入特征。

3. 参数化变异：给每个模板的参数（行人速度、出现距离、障碍物高度、光照强度）设置取值范围，然后按边界值和正交组合生成几十上百个具体场景。这一步看起来工作量大，但一旦参数表设置好，场景生成脚本一天就能跑出好几百个用例。

4. 先用仿真跑批：把生成的具体场景灌进仿真环境，批量跑导航和避障算法，找出失败用例。失败的用例再分两类：一类是测试场景本身就超出设计能力（比如轮椅在暴雨天室外行驶），这类用例可以作为“ODD边界”标记出来，不纳入验收；另一类是算法确实处理失败的，比如“静态轮椅在窄通道中无法通过”，这类进入实车复现名单。

5. 实车回归验证：从筛选后的失败用例里挑出风险等级高的，在实验场地复现，验证修复效果。

这套流程走下来，我对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，让轮椅真正能走出家门，去到社区、公园这些更大范围的场景里。