自述创业兴衰史 | XMove动作感应系统(二)

沙漠之鹰

XMove是我研发三年的人体动作捕捉硬件创业项目。本文为中篇，上篇为《》，它讲述了笔者大四黄金时期与XMove的故事，建议阅读。

2012年的最后一天，我安静地走出科研楼的大门，那一天，我停止了对XMove所有的开发和维护。这个我曾为其痴迷，痛苦和成长的项目，正式成为了过去式。

第四代的小目标：北京一套房

我设想了这样的场景，穿上这套动作捕捉服，手机就能在任何地方实时将动作和位置传递回电脑管理端，实现运动监控和分析。更能方便地做定制：如老年人防摔倒，空中鼠标这些都简单得不在话下，甚至你可以打一套太极，之后软件就会自动对每个细节提出建议。

彼时正值移动互联网创业浪潮，这样的硬件创业思路别具一格（歪门邪道），中科院投入千万在类似的项目上，国外类似产品笨重低效却卖75万一套，智能硬件和健康一定会在未来成为风口。所以我相信我不会白做，至少能赚个北京一套房（2011年二环内三万一平），你觉得当时的我判断对么？

我刚本科毕业，刚喝完散伙酒的我，把这个一套房的小目标，分解成了一下几个部分：

• 全身动作捕捉节点增加到23个，并极致轻薄
• 解决无线通信协议和效率
• 实现3D人体动作重建
• 能与手机直接通信
• 传感器融合和流式动作识别
• 开发桌面端完善的监控软件

23个节点部署在人的头部，四肢，腰部臀部和手脚，就能完整的重建人体动作。解决这些问题，一套房就来啦！下面就挨个讲解这些工作， 你猜我最后栽在哪个问题上了？

微型节点和节点航母

在当时我们手工焊接的粗糙工艺下，实现这一目标略为困难，我们选用了超小的CPU，加速度计和陀螺仪，还需生产至少50套硬件，最终硬件只有4mm厚度，比手机常用的TF卡稍微大一些：

为了解决多个节点的无线通信和充电，我们设计了“节点航母”，它能同时与32个节点通信，同时给三个节点充电，并与手机实现蓝牙通信：

这样小的节点，充电和调试就成了大难题。最后我突发奇想，把PCB设计成了TF卡的造型，直接插到航母节点的TF卡槽里！

这是所有4代硬件的全家福，我还给XMove专门设计了一个手柄(下图最右)，包含八个按键，两个摇杆，想想真丧心病狂：

这些都不算什么，我们当时遇到了很大的困难：微型节点总是读取传感器数据失败！以为是硬件问题，重做了七八次电路，耗资惊人，电路板堆得有一米高，原本可能一小时搞定的事情，最终在实验室里拖了接近半年！ 险些要放弃的我，终于在圣诞节后的早晨，从国外的一篇文献里找到：CPU的端口上拉结构不一致，导致高电平达不到I2C阈值，通信失败。通过软件配置就能解决！当时的我，喜悦中带着泪水，冲出去就和队友打电话！如果你对这部分故事的细节感兴趣，可以后台留言给我。

如果你吐槽软件开发难，是因为不知道硬件有多苦，焊接米粒一样的芯片，省吃俭用，而一不小心就能烧掉一个月的饭钱。遇到问题得靠大量的经验去解决，硬件工程师是用钱和汗水堆出来的，此话并不为过。

复杂的无线通信协议

无线通信并不容易，电池容量太小，而当时的蓝牙2.0功耗太高，而更高级的无线方案根本用不起。我们不得不在nRF协议上做深度定制，最终平均功耗压到了2mA/节点：

当时简陋又复杂的通信协议：

管理器能自动跳频和低功耗切换，让节点能在尽可能省电的情况下正常工作：

然而，成也萧何败萧何。当23个节点同时以32帧的高速率传输数据时，信道质量变得出奇的差。这个芯片底层采用GFSK调制，而底层协议只要CRC校验错误一个字节，就会抛弃整个包。结果就是互相干扰，大量数据被抛弃，信道异常恶化。而由于发射功率很低，只要转身发生阻挡，丢包率90%以上！

这事情变得无解了，我曾想通过数据平滑来对丢失数据做补偿，然而这样高的丢失率，几乎让整个计划成为泡影。系统最大的瓶颈，居然是无线通信！

我们根本没有设计天线的经验，北邮在这个领域强手如林，我们寻遍各大实验室，大家给出了各种方案，却都卡在了功耗和成本上。他们的方案根本用不起，而且几分钟就会消耗完那可怜电池的所有电量。

此局在当时几乎无解。

实现3D人体重建

如果你看过前一篇文章，一定会记得那个茶壶。现在要重建人体，就需要3D操作一具骨骼。我当时从头学了一遍OpenGL，从一个素材库里抽出了一套骨骼系统，一点点地研究四元数绑定，各种矩阵变换把我绕得糊里糊涂。刚开始实现的效果是这样：

想想看一个在X光片里的骷髅跟着你来回乱动了，妹子们都表示太吓人了！我不得不放弃了这个OpenGL方案。

最后才用到了Unity3D，这个超强的3D引擎，配合我写的C#远程RPC(程序之间互相通信的协议)，很好地解决了这一问题，效果还不错，搬运工森林旅游即视感：

不过因为丢包的问题，突然胳膊肘就拐到身后，大腿就撇到了头上：搬运工哥哥各种丧病的动作，把参观者笑个半死，哈哈哈哈哈。苦中作乐，苦中作乐！

动作融合和流式动作识别

加速度计，磁力计和陀螺仪提供了九轴的运动数据，但如果要映射到真实空间中，就需要做传感器融合。几年之后无人机如此流行，AHRS(全姿态解算系统)已经非常平民化，而在当时根本找不到什么资料，我不得不自己研究，这是当时演算的一部分手稿：

实验时，大叔的手插进了腰，看着都疼。我在四元数和欧拉角各种折腾，推导公式，做了无数的实验，终于完美地解决了这一问题。

上一篇提到，之前的动作识别无法处理流式数据，也就是必须指定动作的起点和终点，这显然要求太高了。

我们希望能实现通用的流式动作判断，比如奔跑跳跃，摔倒，或是手臂的某个特定动作。这样一旦监控到这样的事件，就能通知应用层，还能分析它与标准动作的相似度。

我看了不少书籍，也询问了很多专业的朋友，他们告诉我使用HMM(隐马尔科夫链)，不过现在想起来，一阶HMM根本无法解决问题，而能解决该问题的LSTM模型，在三年后才正式出现（哭）。

不过我还是用了各种野路子，把HMM和SVM配合使用，抽取每个节点的九轴数据作为特征，训练出了一个还算能用的动作识别器。对步态识别能搞个八九不离十，更复杂的就搞不定了。不过对流式数据的处理，直到现在都没有较好地解决。

Android版本的XMove

由于手机要作为信号中继，也是重要的传感器之一，XMove就肯定要涉及手机端。

2011年暑假，我就开发了这个安卓版本的XMove组件。下面是手机无线多点触摸板，支持双指缩放和三指拖拽，能与电脑通过蓝牙，WIFI和3G信号连接：

通过手机旋转和倾斜实现的飞行游戏手柄。那是著名的飞行战斗游戏HAWX2(鹰击长空)。

我通过XMove学会了安卓开发，却在之后没有继续学习进步。在那个年头，开发安卓的人还是凤毛菱角，移动互联网创业，安卓开发者的收益极高，我却基本都错过了，不过这是后话。

最大耗时：桌面管理端

曾经的我对GUI开发充满兴趣，桌面管理端也竟然是我花费最长，改动次数最多的部分，它经历了6个版本变更。相比之下，无线通信，硬件和姿态解算都不算什么。

下图是第四代里，最后一版用WinForm技术实现的管理端（其实是专门为安卓版本定制的）：

之后，我便花了超多的时间，用于开发这套基于WPF的管理端，功能超级强大，你能对任意节点进行路由组网，远程配置，还能支持多人应用。是不是和爬虫Hawk很像？Bingo！这是Hawk的祖奶奶，最初原型：

管理端能用3D形式展示数据流是如何从传感器传入到不同应用，并能监控各节点的信号强度，电量等关键信息。

也许你看出来了，这套系统明显有过度设计的嫌疑。插件，自动拖拽，无线路由配置，不少功能根本不需要，却浪费了过多时间，而最核心的算法部分，却没有分配足够的精力。

从激情到放弃

XMove第四代，消耗的精力是前三代总和的接近两倍。研发资金基本自掏腰包，获得了学校老师给予的诸多资金和技术上的帮助。它最后开发出两套原型机，在无干扰的环境下，能实现基本的动作捕捉，而一旦无线环境恶劣，通信问题就让整个系统乱套了。

正值研一的我，要维护实验室繁杂的研发任务，信道仿真和数据挖掘，还要在XMove上投入足够多的时间和金钱。身边的同学们都外出实习了，曾经充满美好幻想的我，终于在2012年的最后一天，出现了本文第一段的场景，我决定及时止损，因为我看不到未来。

关于失败的原因，如果有机会一定要单独一篇文章。不过原因也很简单： 严重的过度设计，一股脑地把所有的需求塞进去，追求高大全；没有在动作捕捉算法上下功夫，却将大量的精力投入到桌面管理端的开发； 事先调研不足，对无线信道效率估计过高，不过适合我们的无线解决方案，到了2015年才出现。

因为XMove，我开始怀疑JAVA/C#为代表的面向对象编程，这种思维方式不是世界抽象的最合适方法。如果我现在写Python版本的XMove驱动和管理端，函数式风格，代码还是不会超过1000行，功能和效率肯定会远高于之前的设计。

我依然记得2012年的正月初一到初七，我拒绝了大部分的走亲访友，一个人在家憋着写代码；记得和队友一起，钻在实验室的焊接台下，检查着每一个焊点，之后只敢去食堂吃最便宜的菜；也记得因为无线通信不论如何都无法解决，气愤地在操场上大喊大叫。

我也记得它给我带来的兴奋和成绩。XMove在我大学和研究生阶段，写下了浓墨重彩的一笔。它驱使我解决一个个实际的问题，对架构有了嗅觉，能够随时警惕过度设计，知道简洁的方案，远比沉重复杂的方案好得多。也知道如何做合理的商业决策，避免因为自己的幻想，一条道走到黑。

XMove寿终正寝，但它依然以文章的形式出现在我的博客中。我给它装了一个精心设计的塑料盒，放在书房里，那是青春最美好的回忆。