插件化：移动机器人系统应该把什么留在核心？

一家机器人公司同时服务仓库和室外园区。

仓库里，机器人用激光雷达和 AMCL 定位；到了室外园区，光照和环境变化更大，需要视觉定位与 RTK 的组合。下一位客户可能还会要求地下停车场定位。

如果这些算法都直接写进任务调度模块，系统很快会出现大量判断：当前是什么环境、该用哪套算法、传感器异常时如何降级。每增加一种定位方式，核心代码都要修改，整套系统也要重新测试。

插件化解决的就是这类问题：把变化快、实现多的定位算法放到核心之外，核心只负责稳定的机器人能力和接入规则。

一、先看清核心和插件的边界

在这个例子里，核心负责：

• 接收和同步传感器数据
• 管理地图、坐标系和机器人位姿
• 调度任务
• 加载定位插件并处理插件状态

插件负责具体算法：

• AMCL
• 视觉定位
• 激光 SLAM
• UWB 或 RTK 定位

核心不需要知道每种算法如何计算，只需要调用统一的定位能力：输入约定好的数据，得到带状态的位姿结果。

图中最重要的不是有多少个插件，而是核心和插件之间那条公开契约。只要新的算法能遵守这份契约，就可以通过新增插件接入，而不必修改任务调度和地图管理。

插件化并不会让核心永远不变。如果新算法需要核心尚未提供的传感器数据，契约仍然需要演进。它真正减少的是变化的影响范围。

二、插件契约不是一个函数名

定位插件看起来可能只需要一个方法：

localize(sensor_data, map) -> pose

但真正运行起来，还必须约定：

• sensor_data 是否已经完成时间同步
• 地图和位姿使用什么坐标系
• 时间戳采用什么单位
• 定位结果如何表示置信度和失效状态
• 算法超时后由谁取消和清理
• 插件需要哪些资源，何时释放

这些约定才是插件契约。函数签名只是一小部分。

例如，核心把坐标系定义从 map→base_link 改成另一种含义，函数名和参数可能完全不变，但旧插件返回的位姿仍然会被系统错误使用。

所以，契约升级通常要遵循几个原则：

• 优先增加可选能力，不直接改变旧含义
• 用版本号或能力协商处理差异
• 保留适配层，给旧插件留出迁移时间
• 在移除接口前明确兼容周期

插件化的长期成本，不是写一个加载器，而是持续维护这份对外承诺。

三、可插拔不等于运行时切换

系统启动时选择一个定位插件，安装新算法后重启，已经属于插件化。

如果要求机器人运行时切换算法，问题会复杂很多：

• 当前定位任务是否能安全停止
• 新算法是否已经建立稳定位姿
• 传感器订阅和后台线程如何交接
• 切换期间任务调度器是否应该暂停
• 新旧算法的坐标系和位姿是否连续

机器人正在移动时，如果新插件还没有输出可靠位姿，调度器却继续规划路径，就可能让机器人停错位置。

因此，运行时切换是额外能力。没有明确需求时，启动加载、重启生效往往更容易验证。

四、插件需要隔离，但隔离不等于安全

如果定位插件和核心运行在同一进程，插件中的死循环、内存泄漏或非法访问都可能拖垮整个机器人系统。

可以把插件放到独立进程或受限制的执行环境中，并限制它的 CPU、内存和设备访问权限。这样能改善故障隔离，但仍然需要算法审核、超时处理和故障恢复。

对机器人来说，定位插件失效后的动作也必须提前定义：停止、降速、切换备用定位，或者进入安全状态。不能继续使用已经过期的位姿结果。

五、什么时候值得做插件化

如果系统只有一种定位算法，由同一个团队维护，也没有独立交付需求，普通模块和清晰接口通常更简单。

插件化更适合以下情况：

• 不同机器人需要不同定位算法
• 算法迭代速度明显快于任务调度和设备管理
• 客户需要按传感器组合选择定位方案
• 合作方或其他团队需要独立发布算法
• 团队能够承担版本、权限和兼容性治理

回到开头的例子：仓库使用 AMCL，室外园区使用视觉定位与 RTK。采用插件化后，核心只提供同步后的数据和地图，接收带坐标系、时间戳和状态的位姿结果，并在结果失效时执行停止或降速策略。新增地下停车场定位时，主要工作是实现同一份契约和完成插件测试，任务调度与地图管理可以保持不变。

如果每增加一种算法都必须修改任务调度器，或者不同插件返回的坐标系各不相同，那么问题不在插件数量，而在边界没有定义清楚。

可以用两个问题做最后检查：

新增一种预期中的定位算法，能否主要通过新增插件完成？

核心调整任务调度或地图管理的内部实现时，现有插件能否继续工作？

如果答案经常是否定的，先重新划分契约，再考虑热切换、沙箱或插件市场。插件化的价值，是让算法团队按约定增加能力，同时让移动机器人系统的核心保持稳定。