初次投稿，先简单自我介绍：鄙人数码产品爱好者，少数派忠实读者，以及少数派尊贵的 π+ 会员，多年电商狗，一年多扫地机器人产品经理，最近一年的工作都在卷得要死的清洁机器人类目。
想着写这么一篇文章，可能也是真的做了产品经理后一些产品惯性引起的。Apple Watch 和扫地机器人，看起来是完全不相关的产品，有什么可以借鉴的呢？
其实不然。做过苹果平台开发的朋友知道，苹果为用户界面设计提供了细致的指引，按照这个做基本不会出问题。但是，真正的能力不会只停留在 UI 和交互，对背后的运行逻辑没有研究，而是要去理解一些表象问题背后的实现方式。
做产品经理这一年，我跟研发泡在一起比较多。我发现，研发最厉害的不在于编程能力有多强——代码对于优秀的研发来说基本是大同小异——而是他们学习新东西的速度很快。研发也是我见过使用搜索引擎最频繁的工种，很多东西他们看看开发指引、或者其他人的文章，很快就能复用上。换言之，他们学的可以说是一些「通用能力」，例如解决问题的方法，逻辑性很强。
苹果今年的秋季发布会，是我近两年来难得熬夜看的一场。苹果在这次发布会上花大篇幅介绍了「车祸检测」功能，事后被大家吐槽基本没法测试。
但作为扫地机器人从业者，这个功能让我感到非常惊叹——我们扫地机器人产品，避不开的就是算法，进入行业的门槛也是算法。我还记得苹果之前宣传过 Apple Watch 检测到心率异常，用户在报警后及时就诊，发现被救了一命的事情。这固然有广告成分，但功能背后也必然是大量算法研究作为支撑的。
下面，我就结合自己工作中的研究，谈谈 Apple Watch 的新功能对于扫地机器人有哪些借鉴意义。
这是直接触动我感到可以跟苹果学做产品的新功能。在苹果的宣传片里，一个人在荒漠里迷路了，不知道该走向何方。但打开 Apple Watch 的回溯（Backtrack）功能后，跟着表盘上的路径走就能回到起点。
我们完全可以把这里的探险者看成扫地机器人，而家就是扫地机器人在探索的「荒漠」。机器人的运动，依靠的是对感知传感器（摄像头或者雷达）、辅助传感器（陀螺仪和里程计）的数据的实时处理——我们简称为扫地机器人的「盲杖」。机器人其实无时无刻不在一个迷路的状态，只是它的盲杖比较牛逼。
但正因为机器人是通过盲杖前行的，通过固定的算法逻辑去处理盲杖传递过来的数据，所以有了这样一个经典的问题：把扫地机器人先后放在完全一样的 A 和 B 两个房间，它到底能不能区分出自己在哪个房间？
原理上来说，机器人是不能分出来的，因为「盲杖」探一圈发现数据完全一样，它就会认为两个房间是同一个。还有一个难题是长走廊问题，机器人走在上面容易发生位姿飘移。
但这两种情况在实际使用中发生的概率都还算是比较小的。真正比较常发生的是机器人被困住的问题。我们这里主要聊「非缠绕型」被困，也就是因为「盲杖」问题导致被困。
做扫地机器人的时候，我们一般会通过几个固定测试场景，来测试算法「脱困」的能力，包括四脚桌椅、巴塞罗那椅（椅脚是弧形交叉的不锈钢支架）和窄道等等。
机器人一般有被困后报警的功能，但其实很多情况下，机器人还没判断自己被困，从我们人的视角来看，它就是「不智能」地被困住了。
如何定义「被困」呢？还是以苹果视频里的探险场景作比方，如果无法有效规划路径、走进一个场景之后出不来，就可以算被困住了。那被困住了怎么办？人如果找不到路了，会往各个方向都试试；机器人最简单的操作也是这样子的（当然算法也会先思考从哪个方向开始尝试）。如果多种可能都试过后还不行，就会报警叫人去救它了。
而回溯功能给我们提供了另一种思路：一旦被困，最高效的方法或许就是原路返回，算法调用前面进来的路径，原路退回去就行。但这能否实现呢？我认为可以。
首先，扫地机器人是知道自己在哪里的、怎么过来的，这也是机器人如何判断自己是否扫完整个区域的依据。实际上在 2016 年，石头科技和小米就已经联合以可视化方式向用户呈现清洁轨迹了。此外，我拜托专利同事帮忙搜过，其实有人已经申请过反映这个思路这个专利。
然而，据我所知没有一家把回溯的思路真正用起来。（这里欢迎其他知情人士打脸哈，毕竟我只是一个做扫地机器人的新人。）
当然，假如和研发沟通，肯定会被问到一个细节，要调取多早之前的路径才够呢？如果回去得太多，会导致重复清理。对此，我站在产品经理的视角，答案一般会是接受这种不完美的场景。
顺带一提，我认为机器人如果真的要智能，需要不断地补充研究上面这种场景，让内部程序能更多的像人来处理遇到的场景问题。这就意味着需要更大的内存和算力。虽然 2022 年的主题可能更多是控制成本，但我相信未来一定会有同行做出来的。
如果是玩过《跑跑卡丁车》（一不小心暴露年纪？）的朋友肯定都有印象：在练习某个地图的时候，系统不仅会记录我们跑得最好的一次的成绩，还会记录那次的轨迹。这样下一次进入训练的时候，系统就按照那个数据生成一个「虚拟的你」，跟你竞赛。
Apple Watch 的 Race Route 功能简直跟这一模一样。我本身也跑步，对这个功能肯定就会比较喜欢了。（本文写作时，提供该功能的 watchOS 9.2 尚未发布；但本文投稿后编辑时，已经可以用上这个功能了。可惜我也跑完南山半马了，还没用上过。）
这跟扫地机器人的运动有什么关系呢？据我所知，目前的扫地机器人算法是不会记录和参考以往的轨迹的，运动轨迹都是跟着「任务」走，每次任务都是新规划运动轨迹。你或许会觉得机器人确实越用规划越准，但那只是因为它补充了更多的室内地图信息，能在规划路径的时候更合理罢了。下次执行任务时，它还是只会实时处理各个传感器传过来的数据，然后调用对应的逻辑去处理；而不会在启动这次任务的时候，对比看看上次在同样的地图下轨迹是怎么样的、这次有没有哪里可以提升的，更不会去历史数据里对比哪次的路线更合理。
我认为，这些记录和对比其实都是可以做的，而且都很有意义，哪怕因为人、宠物、可移动障碍物等因素，每次不可能控制地图完全相同。在扫地机器人系统中加入 Race Route 这样的功能，扫地机器人的智能才能更进一步。
这个功能就更有意思了。为了搞出车祸检测这个算法，苹果收集手表和手机上的传感器数据，做了很多实验。虽然大家都开玩笑说没法测呀，但在我看来正是一种那种超低频但超有用的功能。
苹果有专门一个视频讲利用了哪些传感器的数据来做这个功能。但显然，每个传感器数据、以及这些数据的关联，跟车祸场景的关系是什么样的，视频里是没有解释的，也解释不清，而这些就是算法的魅力。
这个功能对于扫地机器人的什么场景可以有所启示？那就是越障。
因为装修等历史原因，很多家庭里面有高低落差的地方，例如门槛石、滑轨门等。这都是需要越过去清扫的。在越障的时候，我们可以观察到扫地机器人上有很多传感器数据变化，比如悬崖传感器、超声波传感器、陀螺仪等的数据。通过研究这些数据，我们完全可以判断出机器人在哪里越过了什么东西。（机器前面有摄像头的朋友可以私聊告诉我，你们用摄像头传过来的数据判断门槛的事情做得咋样了？）
这里作为例子，讲几个我们遇到过因为传感器数据导致越障失败的场景。（可能是其他同行没遇到的，因为我们做这个机器之前没有做过扫地机器人，犯了一些很愚蠢的错误，当然也就是经验了。）
我们的机器「屁股」比较重，导致每次越障的时候头翘得很高。虽然底盘设计高度能越障 20mm 绰绰有余，但如果碰到一边是黑色地面的时候，悬崖传感器很可能就懵逼了，认为是「悬崖」就不过去了。高处往低处走的时候，悬崖传感器也有一定概率停在 20mm 左右的坎之前。还有一种错误情况和超声波有关。超声波传感器是用来检测地毯的，但当机器人冲上坎的时候，传感器可能以为前方产生的气流是「地毯」，不仅不过去，反而开始往后退。
参考苹果做车祸检测功能的方法，我们其实是可以通过海量的测试来将现在越障算法做得更精准。例如，在地图上把这个障碍、门槛标注出来，再适配一些对应的清扫逻辑。当然，这又回到上面说的内存和算力不够的问题：现在的硬件可能无法支撑太复杂的清扫逻辑，如果加入的变量多了，算法会变得不稳定。
还有一些替代方法。例如，每次遇到门槛误判的场合，我们可以把记录上传到 app 让用户去确认；或者让用户通过 app 主动去标注需要越过去的门槛。此外，在研发环节，如果用户允许，还可以请专职人员去看用户的清扫记录，通过运动轨迹和路径去具体判断哪里容易被困、哪里是在越障，再将据此调整的算法请用户确认是否采纳。我希望已经有上百万用户的同行们可以考虑一下，你们拥有海量的数据，做个专项，应该能提升行业水准一大步。
这篇文章其实早就写好了，一直想改改再发到少数派上面，因为拖延，苹果发布会过去这么久了也没改，看看 22 年快过去了，就干脆发出来了。被建议编辑一次之后，我发现内容还可以补充比较多，实在又不想在这一篇里面写那么多。文中观点我说得不一定对，欢迎大家拍砖。我可能还会继续更新清洁机器人系列，欢迎大家交流，我看情况再更新。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。