机器人交付以后，软件还会持续更新：修复问题、调整算法、增加功能。机器人分散在各个现场，每次升级都派人到场不现实，远程升级是迟早要做的事。但远程升级一旦失败，机器人可能无法启动，现场又没有工程师，处理起来很麻烦。所以升级方案的重点不在怎么把新版本传过去，而在失败了怎么办。下面是远程升级的通用设计思路，未经实机验证，具体实现要结合系统和部署方式。
【先分清升级什么】 机器人上的软件大致可以分为几层：操作系统和驱动，运行环境和依赖库，应用程序，配置和模型文件，地图和点位数据。不同层的更新频率和风险差别很大。 操作系统和驱动更新频率低，风险高，适合在现场或受控条件下进行。应用程序和模型更新频率高，适合远程升级。地图和点位属于现场数据，一般不随软件版本覆盖，而是单独管理。
【应用层用容器】 应用层使用容器部署，升级相当于拉取新镜像、替换旧容器。好处是新旧版本可以并存：新版本启动失败，直接切回旧镜像即可。 镜像要有明确的版本号，不要只用 latest。机器人本地保留上一版本的镜像，在网络不好时也能回滚。
【系统层用 A/B 分区】 如果需要远程更新系统镜像，可以采用 A/B 分区：当前系统运行在 A 分区，新系统写入 B 分区，写完校验无误后，设置下次从 B 启动。新系统启动后通过健康检查，才标记为成功；若启动失败或健康检查不通过，自动切回 A。 这种方式的代价是存储空间翻倍，但能有效避免升级失败导致机器人无法启动。
【健康检查要具体】 升级后的健康检查不能只看程序是否启动，要检查机器人能否正常工作：关键节点在线，传感器数据正常，定位能初始化，与平台本体的通信正常。检查项可以复用日常自检的内容。 健康检查通过之前，不要删除旧版本。
【断电和断网】 升级过程中可能遇到断电或断网。下载阶段要支持断点续传，下载完成后校验文件完整性；写入阶段要保证原子性，避免写了一半的文件被当作有效版本使用。 升级时机也要选择：机器人在充电、不在执行任务、电量充足时再进行。
【配置和数据迁移】 新版本可能修改配置文件格式。升级程序要能识别旧格式并自动迁移，迁移前先备份。地图和点位数据尤其要小心，它们是现场花时间做出来的，升级时不应被覆盖或丢失。
【记录和灰度】 每台机器人的当前版本、升级时间、升级结果都要记录下来。多台机器人时，先在少数几台上升级，运行一段时间确认无误后再推广。升级记录本身也是运维资料的一部分，出现问题时可以快速定位是哪个版本引入的。
【升级前的准备】 远程升级之前，先在和现场相同配置的测试机上完整走一遍升级流程，包括从当前现场版本升级、升级失败后回滚。测试机的硬件、系统版本和配置要尽量和现场一致，否则测试结果参考意义有限。升级包要附带版本说明，写清修改内容、影响范围和回滚方法。机器狗上装的硬件如果有差异，比如传感器型号不同，升级包要能识别并加载对应的配置。
【小结】 远程升级要先想清楚失败了怎么办：应用层用容器保留旧版本，系统层用 A/B 分区，升级后做实际的健康检查，下载和写入要防断电，现场数据单独保护。机器狗上装的软件能平稳升级，机器人才能长期稳定运行。
机器人智能化改造与系统集成：www.yuanzhirobot.com/zh/service/… 本文部分内容由 AI 辅助生成。
