扫地机器人这东西前几年还属于能用就行这两年用户的耳朵都养刁了——扫地要扫得干净拖地要拖得智能更要命的是家里有楼梯、有宠物、有电线机器在沙发底下钻来钻去万一从楼梯上冲下去或者把猫尾巴卷进边刷里那可就是真事故。所以在嵌入式产品圈里智能家居厂商们这几年达成了一个共识双脑架构也就是把安全和智能彻底拆开一个交给MCU一个交给Linux。安全永远不能交给Linux这不是一句口号而是用一次次返厂维修、一笔笔售后赔款换来的经验。这篇文章就把我实际参与扫地机器人主控方案设计时的思路、选型、踩坑和调试实录掰开揉碎了讲。适合正在做嵌入式产品的工程师、想入行机器人行业的学生以及被机器人为什么会智障困扰的产品经理们。1. 双脑架构的整体设计思路为什么单一Linux方案行不通1.1 从一次真实的扫地机跳楼事故说起我最早接触扫地机器人双脑方案是在一家做智能清洁电器的公司。当时团队里有一个非常激进的同学提出过一个纯Linux单脑方案一颗全志或者瑞芯微的SoC跑Linux系统把电机驱动、传感器采集、SLAM算法、App通信全部塞进去。理论上完全可行因为现在的嵌入式Linux性能早已不是当年那个只能跑跑控制台的玩意儿四核A53、四核A55跑个轻量级SLAM绰绰有余。结果样机测试的时候出事了。机器人爬到茶几上——这是家里最常见的越障场景——然后沿着茶几边缘试探性地伸出半个机身激光雷达还在扫描结果Linux系统此时正在做一次OOM内存耗尽回收紧接着又触发了一次磁盘写日志时的IO阻塞整个系统的实时调度被打乱避障线程延迟了300毫秒。就是这300毫秒机器人一头栽了下去从1米高的茶几摔到地板上外壳裂开激光雷达的转轴直接报废。这件事当时的教训非常深刻。不是我否定Linux在机器人领域的价值而是Linux作为一个分时操作系统设计目标就是整体吞吐率高、资源利用率大它天然不承诺任何硬实时。你可以在Linux上绞尽脑汁提升实时性加RT-PREEMPT补丁、绑核、提高进程优先级、把关键线程调成SCHED_FIFO调度策略但实时性依然不是它的本色。而扫地机的物理安全性——比如前方悬空必须立刻停轮——需要的恰恰是确定性是我说停就必须在1毫秒内停住。1.2 双脑架构的职责划分安全脑与智能脑如何分工我最终采用的方案也是目前扫地机器人行业的主流方案MCULinux SoC双脑架构。MCU这颗安全脑通常选Cortex-M4或者M7核心的芯片比如STM32F4、STM32H7、GD32F4甚至一些低端方案用M0内核的芯片也够关键不在算力而在确定的实时响应。MCU单独负责轮速电机PID控制、碰撞传感器突发检测、跌落传感器悬崖传感器读取、防堵转电流检测、电池过放保护以及最重要的——紧急制动逻辑。Linux SoC这颗智能脑负责的是SLAM建图、路径规划、视觉识别AI识别袜子和电线、语音交互、App通信、OTA升级、日志存储。这些功能共同点是计算量大、逻辑复杂、实时性容忍度相对宽松。哪怕SLAM线程慢200毫秒机器人最多是多走几厘米冤枉路但电机驱动线程慢200毫秒可能就是一次坠落事故。两者的关系我用一个类比来说明MCU是本能脑或小脑负责条件反射——碰到东西了立刻缩手脚踩空了立刻收力痛了立刻停Linux是大脑皮层负责思考——规划路径、记忆地图、识别物体。如果大脑皮层宕机了人的本能反射还活着还能保命但如果把本能反射也交给大脑皮层那大脑一死人就彻底废了。双脑架构的全部精髓就是这句话。1.3 双脑之间的高速公路轻量级通信协议设计两颗芯片之间不可能各干各的它们需要实时交换数据。我们采用的通信方式主流有两种UART串口和SPI总线。UART简单可靠接线就两根波特率115200到921600之间随便选协议好调试适合低速控制指令SPI带宽大适合高频率传输传感器原始数据流比如把IMU九轴数据以1kHz频率灌给Linux做VIO视觉惯性里程计或者反向把激光雷达数据转给MCU做紧急避障判断。但无论如何数据链路必须设计成双向心跳轻量级协议。我实际用的是一套类自定义帧格式协议帧头2字节0xAA 0x55后跟1字节帧类型、1字节数据长度、N字节载荷、1字节累加和校验帧尾固定0x0D0A。最大帧长控制在64字节以内因为扫地机底盘上通信频率通常是100Hz到200Hz每帧几十字节总带宽占用很低但协议越短越不容易被中断冲散。MCU这边每收到一帧有效数据回一帧ACKLinux超过500毫秒没收到ACK就判定链路异常启动降级流程。这条通信链路还有一重身份Linux的生命线。MCU每100毫秒给Linux发一次心跳帧Linux每100毫秒回一次。如果MCU连续3个周期没有收到Linux的心跳MCU立刻接管所有电机控制权执行安全停机协议——停止前进、原地锁轮、底盘上电自锁。这是整机安全的最后一道保险。2. 安全脑MCU侧的关键实现把条件反射做扎实2.1 电机控制与PID环路为什么MCU要用硬实时中断扫地机的两个驱动轮本质上就是两个直流减速电机配上编码器做速度闭环。在Linux方案里也能做PID但是PID的采样周期一抖动电机转速就会忽快忽慢表现出来就是机器人走不直地图建出来以后路径全歪。MCU方案的做法完全不同。我在实施时把PID控制频率定在1kHz也就是每1毫秒读取一次编码器计数值、计算一次当前速度、输出一次PWM更新。这个任务放在定时器中断里执行优先级设为最高与系统其他逻辑完全隔离。MCU上跑的逻辑越简单越能保证中断响应时间这个1kHz的环路从代码上看就是一个定时器中断回调里面不允许出现任何阻塞操作。还有一个细节电机方向控制。扫地机器人转向的时候左右轮速度方向相反如果在PID输出时直接把PWM占空比改成负值电极上会产生大电流冲击轻则产生噪声重则烧驱动芯片。我的做法是用一个单独的BRUSH引脚控制H桥方向PWM只负责调速方向切换前先让占空比降到0等200微秒再翻转方向引脚避免直通短路。这个细节在出厂测试时能明显看到温升差异不加这个延时电机驱动板温度能高出15度以上。2.2 跌落、碰撞与堵转三类硬安全传感器怎么联动扫地机上最需要瞬间响应的传感器就三类跌落传感器悬崖传感器、碰撞传感器、电流堵转检测。跌落传感器是红外对射方案安装在底盘底部一般是4到6个沿前后左右分布。红外发射管斜向向下照射如果地面反射回来的红外线强度低于阈值说明前方或侧边是悬空状态。这个判断不能放在Linux里因为即使Linux经过优化进程调度的不可控性依然存在。在MCU里我用的是每5毫秒轮询一次传感器原始值一旦连续3次也就是说15毫秒内确认跌落立刻触发紧急停机左右轮同时制动并且把紧急制动标志位锁存直到用户手动复位或者Linux发送明确恢复指令。这个锁存机制很重要防止机器人在楼梯边缘反复试探时出现刚刹车又加油门的抖动。碰撞传感器通常是机械微动开关装在缓冲撞板后面撞到障碍物时开关闭合。这个信号的延迟要求比跌落传感器还高因为它直接关系到机器人和障碍物之间的物理接触是否会造成损伤。我直接在GPIO外部中断里处理中断服务函数里只做一件事给电机控制模块传一个碰撞标志位并且记录下碰撞发生的时间戳然后返回。至于机器人是倒退绕行还是原地转向那是智能脑Linux的事MCU只管反射——先停等指令。堵转检测则是另一个容易被忽视的坑。扫地机在床底下钻的时候轮子可能被地毯纤维缠住边刷可能被电线缠住如果不检测堵转轻则把电机烧了重则把电线连着插线板一起拖拽这是很危险的事故场景。我的方案是每50毫秒采样一次左右轮电机电流与正常运行的电流基准值做对比如果连续200毫秒超过基准值的2倍就判定堵转。值得注意的是堵转不是瞬间出现的所以这个200毫秒的窗口是有意为之的太灵敏会误报比如机器人穿越地毯时电流本来就会瞬态升高。堵转确认后MCU反向运转电机500毫秒尝试自动解脱如果连续三次自动解脱失败就彻底停机等待人工干预。2.3 看门狗与故障降级Linux挂了以后发生了什么这是双脑架构最核心的价值所在。Linux系统无论如何精心优化都有概率崩溃——内存泄漏、内核死锁、文件系统损坏、OTA固件升级中途断电这些我都遇见过。问题不在于Linux会不会崩而在于Linux崩了之后机器人该怎么办。MCU侧的设计必须保证Linux完全死机时机器人仍然处于安全状态。这个需求分成三层来实现。第一层是超时监控。如前所述心跳信号是Linux在跑的唯一证据。我设置的超时是500毫秒超过这个时间MCU视为Linux失联。失联状态下的行为不是立即紧急刹停——那种粗暴动作反而可能导致机器人摔倒或者把家具撞翻——而是执行渐进式降速停机先把目标速度以每秒20%的速率递减到零同时打开碰撞传感器增强模式任何碰撞信号都立即刹停。这个渐进过程大约持续3秒机器人会往前滑行一小段距离但这远比高速急停安全。第二层是位置保持。机器人停下来以后MCU进入省电模式但不会完全关断电机和传感器而是持续维持刹车抱死状态。因为如果MCU也放松警惕机器人可能在斜坡上慢慢溜车。我们用驱动电路里的H桥短路制动——把电机两相短接形成电磁阻尼机器人靠外力推都很难推动。这个状态下指示灯黄灯慢闪告诉用户机器人需要人工检查。第三层是自主恢复尝试。MCU在Linux失联后会周期性地尝试复位Linux比如拉一下SoC的复位引脚或者发送一条唤醒帧。如果Linux能在5秒内恢复正常启动并重新建立心跳MCU就认为是偶发故障继续正常工作如果连续3次复位仍然无法恢复MCU彻底停机点亮红色故障灯等待App端用户干预。这套三重降级机制在量产测试中覆盖了绝大多数异常场景也让我在用户报修的时候有底气和对方说机器人虽然傻了但它是安全的。3. 智能脑Linux侧的工程落地让复杂功能运行得更稳3.1 嵌入式Linux系统搭建与镜像定制Linux侧的核心主控我们用的是全志T113或者瑞芯微RV1126这一档的SoC四核Cortex-A7/A5主频1.2GHz左右搭配256MB DDR3——做扫地机器人完全够用。系统层面最省心的做法是直接用Buildroot定制一个精简文件系统把不需要的内核模块全部裁掉启动时间压到3秒以内。这里有一个非常现实的问题扫地机器人是消费电子产品用户按一下开机键绝不可能接受像电脑那样开机30秒才出反应。所以Linux侧的启动优化是量产质量的关键指标之一。镜像定制上我有几个实际心得。第一内核必须裁剪。默认的Sunxi或Rockchip BSP内核包含大量驱动但扫地机上根本用不到Wi-Fi 6、HDMI、USB HOST全裁剪掉能省下将近40MB的内存占用。第二根文件系统用只读分区。没错我建议把rootfs挂载为只读所有动态数据放在可写的overlay分区或者单独的/data分区。为什么这么做因为扫地机经常遭遇异常断电如果根文件系统正在写日志时断电文件系统容易损坏直接导致系统起不来。只读rootfs配合overlayfs即使断电百次系统也能正常启动。第三启动脚本必须串行化不能像服务器那样并行启动服务。嵌入式设备上内存小、IO慢并行启动看似快实际反而会因为竞争导致某些服务启动失败然后陷入重试循环最终整个启动流程反倒更慢。3.2 Linux侧应用软件的进程管理与内存守护Linux上跑的应用软件我按功能拆成了独立进程有用例驱动的SLAM进程、导航规划进程、传感器融合进程、通信与App网关进程、OTA升级进程。每个进程独立编译、独立运行、独立崩溃重启。进程间通信用共享内存信号量核心的SLAM地图数据走mmap避免大块数据频繁拷贝。进程管理这一块我用的是systemd配合自定义watchdog脚本。每个进程启动时向watchdog进程注册在共享内存里维护一个生命计数器每500毫秒加一。watchdog进程每2秒检查一次如果发现某个进程的生命计数器连续4次没有更新就判定该进程卡死或崩溃立即SIGKILL掉然后按依赖顺序重启它以及所有依赖它的下游进程。这个机制看起来粗暴但在嵌入式场景下非常有效比systemd自带的Restarton-failure更可控因为进程卡死活着但不干活时systemd不会觉得异常而共享内存心跳机制能检测到。内存泄漏是Linux侧最经典的故障源。我见过不止一次机器人连续工作72小时后SLAM进程内存从80MB慢慢涨到380MB最终触发OOM内核开始杀进程然后把导航进程也误杀了整机瘫痪。为了应对这个问题我做了两件事一是在代码层面给每个长期运行进程加了一个内部内存峰值的日志每10分钟记录一次RSSResident Set Size二是在watchdog脚本里加内存阈值如果某个进程RSS超过设定值比如SLAM进程超过200MB自动重启该进程并触发地图持久化保存。这是个治标不治本的方案但作为产品级兜底策略它把故障概率从偶尔发生降到了几乎不发生。3.3 双脑联调中的关键参数与调优方案双脑联调中最折磨人的是通信时序问题。MCU向Linux发传感器数据Linux向MCU发控制指令两者频率不一致时序稍有偏差就会出现控制跟手延迟。我的经验是先确定主时钟——以MCU的控制周期为主时钟Linux侧所有发送都通过查询-应答模式进行而不是主动推送。具体来说MCU每50毫秒通过串口向Linux发送一次数据请求帧Linux收到请求后立刻回传这一周期内的指令数据目标转速、目标转向角。这样整个系统的同步完全由MCU主导Linux侧的所有计算都变成响应式的天然规避了时钟漂移问题。此外通信波特率的选择也有讲究。9600太慢115200是起步但到了921600这个档位在长线材和强电磁干扰环境下扫地机内部电机就是个大干扰源误码率会明显升高。我在量产板上最终用的是460800波特率配合CRC16校验实测误码率在10的负7次方以下足够可靠。还有一点双脑之间最好加一个独立的硬件流控引脚。Linux侧准备发送数据时拉高RTS引脚MCU检测到高电平才启动接收。这样能有效防止MCU在忙中断处理时丢失串口数据。我开发阶段没加这个引脚经常出现Linux发指令MCU没收到的诡异问题查了三天才发现是串口FIFO溢出丢数据。4. 常见问题与排查技巧实录4.1 双脑通信异常的定位方法串口通信出问题时首先不要怀疑代码逻辑先拿示波器量物理波形。我最常用的是逻辑分析仪抓取UART电平信号看看波形上有没有毛刺、电平幅度有没有衰减、有没有误码。如果物理层正常再用回环测试——把TX和RX短接发数据看能不能收回来验证串口外设是不是正常。如果回环测试正常但双脑之间就是不通重点查GND共地问题。两颗芯片分属不同电源域如果数字地没有充分连接串口电平参考点不一致就会出现间歇性乱码。这个坑在PCB Layout阶段就要重视双脑通信的UART线路至少要共地、屏蔽、短走线。软件层面排查我建议在通信协议里固定加入一个链路质量统计项。MCU侧统计每个100毫秒周期内收到的有效帧数、校验失败的帧数、超时次数Linux侧同样统计然后双方定时交换这个统计值。哪边的计数异常就说明哪边的接收有问题半天就能把故障定位到单一侧。这个统计项在开发阶段非常有用在量产阶段也建议保留。4.2 Linux侧崩溃后的恢复与日志分析Linux侧崩溃什么是最值钱的东西日志。没有日志一切都是猜谜。我在项目初期就搭建了一套轻量日志系统日志统一写到内存tmpfs分区每满1MB或者每5分钟同步一次到Flash上的环形缓冲区块。为什么要先写内存再同步Flash因为扫地机上的Flash写入寿命有限频繁写入很快就报废了。tmpfs缓冲能有效减少Flash写入次数同时在系统崩溃后重启时Flash里的日志是完整可读的。有一次量产测试中遇到的问题是机器人每68小时准时死机。查看日志后发现崩溃前10分钟SLAM进程的RSS从180MB开始暴涨5分钟后触发OOMOOM杀进程时把Wi-Fi守护进程误杀了随后App通信中断系统进入半瘫痪状态。顺着日志往上追发现是SLAM算法里一处特征点地图缓存没有释放在地图不断扩大的情况下缓存线性增长。修复方法是在特征点缓存模块中加了一个LFU淘汰策略淘汰最久未访问的20%缓存。这个问题如果不看日志纯靠猜可能几个星期都定位不到。还有一次是内核死锁日志显示全部CPU都卡在同一个spinlock上。这个单纯看应用日志看不到必须保留内核日志。所以我在项目里特意保留了内核的CONFIG_DEBUG_SPINLOCK配置并且使用pstore/ramoops把内核崩溃前后的日志保存在内存的保留区重启后可以读出来。内核问题在嵌入式产品上虽然少但一旦出现就是灾难级这个保留机制非常有必要。4.3 看门狗误触发与避坑方案用了双脑架构之后新的问题出现了看门狗偶尔会误触发。误触发不是指Linux真挂了而是说Linux还活着但因为IO阻塞或者高负载临时超过了看门狗的超时阈值被MCU误判死亡。我踩过最惨的一次坑是扫地机在清扫过程中通过Wi-Fi往云端上传地图数据的同时还在执行全屋路径规划CPU占用率瞬间冲到100%Linux这边的 watchdog线程无法及时喂狗MCU误判Linux死亡执行了紧急停机。机器人原地锁死用户以为机器人坏了直接拔电源重启。这个问题的解决方案是双阈值看门狗。第一级阈值设500毫秒MCU检测到超时后不立即停机而是发送一条喂狗异常预警指令给LinuxLinux收到后主动降低非关键任务负载比如暂停地图上传降低SLAM分辨率。第二级阈值放宽到2秒如果2秒后MCU仍然没有收到心跳才判定失联执行降级停机流程。这个双阈值机制非常实用既保证了安全又给了Linux侧自救的机会。实际跑下来误触发停机率从每月几次降到了接近零。另一个避坑点是喂狗动作本身不能放在中断服务函数里。如果喂狗中断被设计成最高优先级那么极端情况下一旦主循环被某个死循环卡住但定时中断依然触发喂狗看门狗就永远发现不了主逻辑死了。所以喂狗必须放在业务主循环的正常调度路径上同时在喂狗前检查关键业务线程的生命计数器确保真活着才喂狗。5. 硬件设计与产品化的关键经验5.1 双脑供电与抗干扰设计MCU和Linux SoC在工作电压上有差异——MCU是3.3V域SoC核心往往是1.1V或1.2VIO可能是3.3V或1.8V。如果直接用一路LDO统一供电电机启动瞬间的大电流会拉低母线电压导致SoC复位这是非常头疼的故障。我的做法是电机驱动直接由电池母线供电MCU和SoC分别用独立的DCDC buck供电两路之间加磁珠隔离。这样即使电机突然启动MCU侧的电压也只是轻微跌落不会低于3.0V的有效工作值。更重要的是MCU和SoC的电源时序要处理好——MCU必须先上电SoC后上电。因为MCU要在SoC启动之前就具备监控能力否则SoC启动瞬间的浪涌电流可能导致MCU不稳定安全监控就出现真空期。抗干扰设计方面扫地机内部最大的干扰源就是两个驱动电机加一个滚刷电机每秒钟换向几百次瞬时电流可能达到2A以上。这些电机必须加续流二极管和RC吸收电路否则会在电源线上产生几十纳秒的尖峰脉冲直接影响MCU的ADC采样精度和UART通信稳定性。我在量产板上在电机两端并联了100nF陶瓷电容加10Ω电阻的串联组合实测UART误码率从万分之三降到了十万分之一以下。原理很简单RC吸收电路把高频振荡能量消耗在电阻上而不是让它传导到整个电源网络。5.2 量产测试与出厂检验清单等到产品进入量产阶段硬件和软件都稳定了测试流程反而变得更重要。扫地机是全年无休地在家里的地面上工作工况恶劣复杂出厂测试必须模拟真实家的环境。以下是我最终定型的出厂检验清单供参考测试项测试方法通过标准跌落保护将机器放到0.8米高测试台上向前行驶至边缘机器人必须停止且未跌落碰撞响应以0.3m/s速度撞击硬质障碍物碰停距离小于2厘米无损伤Linux崩溃模拟软件触发Linux端看门狗不喂狗MCU在2秒内接管控制并渐进停机持久运行满电电量连续运行2小时全程零异常日志无ERROR断电恢复运行中突然断电重新上电系统30秒内恢复正常地图不丢通讯可靠性在位模式连续运行48小时通信丢帧率低于0.01%这里特别要提醒的是Linux崩溃模拟测试。很多团队在开发阶段不会测这个场景因为Linux正常运行的时候看门狗根本不会触发但恰恰是这种罕见的极端情况才最需要验证。我们的做法是在Linux侧留了一个专门的测试命令可以手动暂停watchdog线程模拟Linux失联然后观察MCU的降级行为是否正确。这个测试在每次固件更新后必须跑一遍防止某次改动无意中破坏了降级逻辑。5.3 从开发板到量产板的BSP适配经验开发阶段大家用的都是厂商的开发板整个Linux环境跑得顺风顺水一画了自己的量产板就开始出各种奇奇怪怪的问题——以太网不通、USB不识别、SD卡启动失败甚至显示屏不亮。这些都是BSP适配没做全导致的。量产板BSP适配的坑总结下来有三类。第一类是DTSDevice Tree Source设备树没改全。开发板的DTS里定义了开发板上独有的外设拿去给量产板用就会出错。我的建议是在量产板画板之前先基于开发板DTS删减外设节点逐个验证不要等板子打样回来了再改那是灾难。第二类是内存参数。量产板用的DDR颗粒和开发板不一样内存参数时序、驱动强度必须按厂商提供的参数表重新配置。如果配置不当系统会随机死机、内存校验错误而且用着用着才崩一次极难定位。第三类是U-Boot环境变量。量产板上我改了默认的bootargs把console从串口移植到虚拟终端同时调整了root分区挂载参数。如果漏改了bootargs系统启动时会一直卡在串口等待输入产品就像一块砖头。至于Linux内核的编译和镜像打包我建议完整走一遍Buildroot流程把交叉编译工具链、内核源码、根文件系统统一管理起来。每次改动BSP后全量重新编译镜像然后做完整回归测试避免这次只改了一行其他应该没影响这种侥幸心态。嵌入式开发最贵的成本就是不确定的改动而流程化是唯一能降低这种不确定性的手段。6. 双脑架构的未来演进与技术展望双脑架构不是终点。随着技术演进我在实际项目中已经在尝试把这套架构往两个方向延伸。第一个方向是MCU侧算力的适度增强。以前MCU只做安全控制现在我会在MCU上跑一些轻量级的传感器数据处理比如把IMU原始数据在MCU侧做一次低通滤波和姿态解算再以更高的频率传给Linux。这样Linux侧做视觉SLAM时可以直接使用MCU解算好的姿态数据省掉一大部分计算开销。另外一些简单的AI推理也开始下沉到MCU——比如碰撞传感器的振动信号可以通过MCU上的轻量级神经网络做模式识别区分撞到墙和撞到猫这个差异化体验在高端产品上非常加分。第二个方向是Linux侧的实时性增强。我在新项目中尝试用RT-PREEMPT内核配合CPU隔离技术把Linux的实时性从之前的不可控提升到接近可控。具体做法是四核CPU中隔离出1个核心专门跑实时任务比如IMU数据采集和激光雷达驱动其余3个核心跑非实时的SLAM和业务逻辑。Linux强制把实时任务绑在独立核心上并且设置该核心不参与普通进程调度。这样既保留了Linux生态的丰富应用又把一部分准安全功能迁移到了Linux侧。注意我说的是准安全真正与人身安全强相关的功能依然留在MCU上——这个底线不能突破。第三个方向其实是OTA与容器化。现在的扫地机已经支持OTA升级固件但把整个系统固件升级一遍风险很高升级中途断电就变砖。我尝试用A/B分区双备份方案配合容器化运行App升级时先下载到备份分区校验完整后原子切换启动项。这样即使升级中出现异常系统还能回滚到上一个正常版本。Linux生态的发展速度很快新算法、新功能不断出现双脑架构下安全底座不动、智能大脑常新才是正确的产品演进姿势。我个人在实际操作中最大的体会是双脑架构看似只是硬件上多加了一颗MCU软件上多跑了一套简单循环但它在整个产品生命周期里带来的安心感是无可替代的。开发的时候多写几百行MCU代码多设计几层异常保护到了用户手里就是少坏一台机器、少打一次客服电话、少被用户拍一次视频发到网上吐槽。做消费级机器人产品安全这件事只能靠冗余和确定性来堆积没有什么捷径。最后再分享一个小经验在样机阶段记得在机器人外壳上贴一张醒目的急停开关标签调试的时候多一位同事在旁边盯着。机器人测试时突然冲向桌角、加速撞向墙壁的那一刻你才会真正理解为什么安全永远不能交给Linux。