自述創業史 | XMove動做感應系統(二)

XMove是沙漠君和幾個死黨從2010年開始開發的一套人體動做捕捉系統，軟硬件所有自行開發，投入了大量的精力，歷經三年，發展四個版本。文章分上下篇，本文爲下篇，前三代的故事在《光榮與夢想| XMove動做感應系統(一)》，建議閱讀。

2012年的最後一天，我安靜地走出科研樓的大門，那一天，我中止了對XMove全部的開發和維護。這個我曾爲其癡迷，痛苦和成長的項目，正式成爲了過去式。

然而2011年暑假，本科畢業剛喝完散夥酒的我纔不這麼想，制定了一大堆目標，興沖沖的上路了：

第四代的小目標：賺它一套學區房

若是咱們想捕捉人體完整的動做，至少須要23個節點。但前三代由於條件所限，只有手腳四個節點。第四代傳感器覆蓋了從頭到腳的每一個關鍵位置，最終效果是這樣的：

穿上這套服裝，而後在廣場打一套太極拳，傳感器就會經過無線傳遞給手機，手機利用無線網絡傳回電腦，系統會記錄和分析每個動做細節，而後給出動做類似度和建議，一旦用戶摔倒，立刻就會檢測到。

彼時正值移動互聯網創業，這樣的「人體物聯網」思路別具一格：中科院投入千萬在相似的項目上，國外相似產品笨重低效卻賣75萬一套，智能硬件和健康必定會在將來成爲風口。雖然有基於攝像頭的相似設備Kinect，但它在陽光下徹底不能工做，可XMove毫無壓力。

若是能知足健身愛好者和舞蹈家的要求，我相信這套系統至少能賺個北京一套房（2011年二環內三萬一平）。

超輕薄的動做傳感器

由於要貼在人身上，因此傳感器必須很是輕薄，咱們選用了超小的CPU，加速度計和陀螺儀，用手工焊接出了50套微型節點（這樣纔夠兩我的嘛），成品只有4mm厚度，比手機經常使用的TF卡稍微大一些：

調試微型節點遇到了很大的困難：傳感器數據老是讀取失敗！剛開始覺得是硬件問題，重作了七八次電路，多花了幾萬塊錢，電路板堆得有一米高，項目延期了接近半年！險些要放棄的我，最後在國外某篇文獻裏查到了答案。當時我瘋了，衝出去大喊大叫！

若是你吐槽軟件開發難，是由於不知道作硬件有多苦，焊接米粒同樣的芯片，省吃儉用，而一不當心就能燒掉一個月的飯錢。遇到問題得靠大量的經驗去解決，硬件工程師是用錢和汗水堆出來的，此話並不爲過。

爲了解決多個節點的無線通訊和充電，咱們設計了「節點航母」，它能最多同時與32個節點通訊，把節點插在航母上就能充電，還能經過藍牙把數據傳給手機：

我還給XMove專門設計了一個手柄(下圖最右)，包含八個按鍵，兩個搖桿，想一想真喪心病狂。這是全部4代硬件的全家福：

然而，咱們仍是遇到了幾乎沒法解決的問題：無線通訊。電池容量過小，當時的藍牙2.0功耗過高，更高級的無線方案根本用不起。

咱們自行設計了支持自動跳頻，時隙劃分，支持自動組網和路由，功耗低於2mA的通訊協議：

管理端可以方便的監控每一個節點的狀態：

然而，成也蕭何敗蕭何。當23個節點同時以32幀的速率傳輸數據時，信道質量變得出奇的差。無線芯片底層採用GFSK調製，而底層CRC校驗錯誤一個字節，就會拋棄整個包。節點間干擾很是嚴重，發射功率過低，只要轉身發生阻擋，丟包率90%以上！

我曾想經過數據平滑來對丟失數據作補償，然而這麼高的丟包率讓一切方案變得一籌莫展。咱們沒有設計天線的經驗，北郵在這個領域強手如林，咱們尋遍各大實驗室，大神給的方案都敗在了功耗和成本上：那些方案几分鐘內就會消耗完那可憐電池的全部電量。

Android版本的XMove

因爲手機要做爲信號中繼，也是重要的傳感器之一，XMove就確定要涉及手機端。

2011年暑假，我就開發了這個安卓版本的XMove組件。下面是手機無線多點觸摸板，支持雙指縮放和三指拖拽，能與電腦經過WIFI和3G信號鏈接，這是使用截圖：

安卓手機端的界面截圖：

還有經過手機旋轉和傾斜實現的飛行遊戲手柄(著名的飛行戰鬥遊戲HAWX)：

我還專門針對安卓版本開發了一版PC管理器：

我經過XMove學會了安卓開發，那時安卓程序員仍是鳳毛菱角，賺錢超多，好後悔沒有對安卓投入更多的精力。不過如今看來，安卓開發已經沒落了，數據算法工程師反而獨佔鰲頭。哈哈哈。

強大的監控端

爲了可以監控不一樣節點，重建人體動做，我花了大量時間，開發了爬蟲Hawk的祖奶奶，功能強大的監控軟件XMove Studio:

你能對任意節點進行路由組網，遠程配置，經過拖拽支持複雜的應用。它是Hawk的最初原型！

管理端能用3D形式展現數據流是如何從傳感器傳入到不一樣應用，並能監控各節點的信號強度，電量等關鍵信息:

也許你發現了，這套系統有過分設計的嫌疑。不少功能不重要，卻浪費了過多時間，而最核心的算法部分，卻沒有分配足夠的精力。

實現3D人體重建

可能你對上一篇文章中展現節點姿態的茶壺有印象。爲了重建人體，就須要操控人體3D骨骼。我從頭學了一遍OpenGL，一點點地研究四元數綁定，和矩陣變換，剛開始實現的效果是這樣：

想一想看一個在X光片裏的骷髏跟着你來回亂動了，妹子們都表示太嚇人了！我不得不放棄了這個OpenGL方案。

最後纔用到了Unity3D，這個超強的3D引擎，配合我寫的C#遠程RPC(程序之間互相通訊的協議)，很好地解決了這一問題，效果還不錯，搬運工森林旅遊即視感：

不過由於丟包的問題，忽然胳膊肘就拐到身後，大腿就撇到了頭上：搬運工哥哥各類喪病的動做，把參觀者笑個半死，哈哈哈哈哈。苦中做樂，苦中做樂！

加速度計，磁力計和陀螺儀的原始數據是不能直接給3D引擎用的，須要作傳感器融合和姿態解算。當時AHRS(全姿態解算)找不到像樣的資料，我不得不花了好多精力研究，這是當時演算的一部分手稿：

以前用SVM解決動做判別，但沒法處理流式數據。所以我嘗試用HMM(隱馬爾科夫鏈)去監測奔跑跳躍，摔倒或揮手，還能分析它與標準動做的類似度，但效果老是很差。當時對步態識別能搞個八九不離十，更復雜的就搞不定了。如今想起來，低階HMM沒法根本解決它，而三年後纔出現解決這類問題的算法LSTM（哭）...

從激情到放棄

XMove第四代，消耗的精力是前三代總和的接近兩倍。雖得到了學校老師的幫助，不過經費基本自掏腰包。開發出兩套原型機，在無干擾的環境下，能實現基本的動做捕捉，而一旦無線環境惡劣，通訊問題就讓整個系統亂套了。

當朋友們出門旅遊玩耍，我卻低頭檢查硬件問題；當同窗們在各大名企實習，我在調動做識別算法。在實驗室繁重的項目壓力下，我還要在XMove上投入足夠多的精力和資金。直到最後，它都沒有商業化應用，雷聲大雨點小，由於它太不穩定了。

曾經充滿美好幻想的我，卻看不到將來，終於在2012年的最後一天，我決定及時止損，出現了開頭出現的那一幕。

究其失敗緣由：

• 嚴重的過分設計，一股腦地把全部的本身想到的需求塞進去，根本沒有調研目標用戶怎麼想。

• 大量的精力投入到根本不是核心的監控端開發，卻沒有在動做捕捉算法上下足夠功夫。

• 缺少硬件經驗：事先調研不足，對無線信道效率估計太高，適合咱們的無線方案，直到2015年纔出現。

這還僅僅是研發層面的困難，更不用說交付給用戶後，電池老化，軟件穩定性的問題：咱們的硬件根本不可靠，滲進汗水可能就短路燒壞了。

由於XMove，我甚至開始懷疑面向對象編程。若是我如今寫Python版本的XMove驅動和管理端，代碼仍是不會超過1000行，函數式風格，結構確定會遠好高於以前的設計。

我依然記得2012年的正月初一到初七，我拒絕了大部分的走親訪友，一我的在家憋着寫代碼；記得和隊友一塊兒，鑽在實驗室的焊接臺下，檢查着每個焊點，以後只敢去食堂吃最便宜的菜；也記得由於無線通訊不論如何都沒法解決，氣憤地在操場上大喊大叫。

不過，我不後悔。

我也記得它給我帶來的興奮和成績。XMove在我大學和研究生階段，寫下了濃墨重彩的一筆。它驅使我解決一個個實際的問題，對架構有了嗅覺，可以隨時警戒過分設計，知道了簡潔遠優於複雜的道理。也知道如何作合理的商業決策，避免由於本身的幻想，一條道走到黑。

XMove壽終正寢，但它依然以文章的形式出如今個人博客中。在Git Hub裏也開源了它的部分代碼。我給它裝了一個精心設計的塑料盒，放在書房裏。

這就是我和XMove的故事。

後記

1. 據不徹底統計，XMove在兩年內佔據了我50%以上的工做時間。
2. XMove能同時兼容2012年上市的Kinect，並提供統一的API
3. 筆者在以後金盆洗手，不接觸任何硬件開發項目
4. 2013年開始，智能硬件成爲風口，大量相似產品出現，但以後浪潮退淨，倖存者所剩無幾