早在一年多前，我们就在筹划着将 Leap Motion 应用到可穿戴设备上，例如，一个可以戴在身上的计算机输入设备？

虽然把 Leap Motion 作为计算机输入设备听起来不是一个多么新颖的点子，或者说,其实 Leap Motion 发布后大家的焦点也一直是在这上面。Leap Motion 官方也是这么定位的，从一开始各种强调能实现鼠标的绝大部分功能并保持可靠的精度和刷新率，到后来为了作为VR设备 Oculus Rift 的输入设备专门做了适配等等可以看出。当然随着SDK的完善以及与各领域的深入合作，现在已经有许多领域的解决方案了，包括教育、医疗等，但设备本身的定位并没有改变。

Leap Motion 作为计算机输入设备刚开始是惊艳了不少人，但是普罗大众试用一段时间后发现累而且憋得慌：你的手需要一直举着，还只能在设备摄像头前方1m内的可视区域内活动，本应该是很有趣的东西却让人有点放不开。前者是个体验问题，后者就涉及使用场景了 —— 我有张桌子能好好摆台 Leap Motion 并在这还算比较小的区域内进行操控，为何不用键鼠？

手举着累这个问题还是可以通过减少操作量和单个操作的持续时间来缓和，而使用局限性的问题，要么就是瞄准 Leap Motion 的优势领域 ——各种不方便使用键鼠的使用环境，例如：浏览电子信息板，用于公共的信息查询，等等；要么，就是做成一个可穿戴设备（Wearable device），让设备跟着人跑，而不是人被绑到设备前面。

HP的解决方案思路蛮好的，将 Leap Motion 的控制器直接集成设备里去，虽然在这里是集成到笔记本上 —— 笔记本的便携性已经很好了，而且还有触摸板，有了 Leap Motion 算是锦上添花。这个方案换做任何设备，其实也是通用的，只要把下图的微型控制器集成上去就行了。

Wearable LEAP

好了，其实这才是这次的重点，前面都是背景介绍。（其实这也是背景介绍，具体方案会在后续的文章中详细说明）

我们来想想，可穿戴的 Leap Motion ，应该怎么来实现？
既然是个输入设备，那我们就从计算机输入的角度来看：数据通过输入设备录入到计算机中。

可穿戴一般采用的就是将输入设备到计算机之间的数据传输由有线改为无线：

具体怎么改，我们看看 Leap Motion 的数据处理流程：

Leap Motion 控制器（Leap Motion Controller）将两个摄像头采集到的图像先做简单的初步处理（灰度，大小），然后通过USB传输将数据发送给运行在主机系统上 Leap Motion 的后台服务程序（Leap Service，Windows上是Service，Linux和OSX上是Daemon），由这个后台服务进行主要的数据处理，获得手部坐标和向量等数据（核心算法部分），运行在前台的应用程序（Leap Application）从后台服务获取处理好的数据，并进行相关应用。

接下来，就要讨论我们应该从那个流程节点入手进行我们的可穿戴方案。HP的方案，其实就是把上图的第一个箭头后面的部分打包到一起了，很明显我们是不能这样的。我们分别从第二个（方案1）和第三个箭头（方案2）进行讨论。

方案1.将Controller与Service的连接由有线改为无线

这其实是我们最先考虑的方案，因为听起来似乎“不难”，甚至有“就是把有线改无线而已，搞个蓝牙模块就可以搞定”的想法。但是仔细一想，我们不知道Service和Controller之间的通信细节是怎样的？PID/VID呢？主动接收数据还是被动接收的呢？并不是简简单单的把Controller出来的数据直接用蓝牙“灌”到主机的USB口就可以的。
官方似乎不会太乐意把这些细节告诉我们，所以方案1很快就被我们搁置了。

方案2.将数据的采集和处理整合到一起

这个方案是将数据的采集和处理一并做了，然后主机再通过无线（蓝牙/WIFI）接收这些处理后的数据。很明显我们需要一块开发板，来从Controller中读取数据并通过运行来Service处理，然后再发送给我们的计算机设备。这块板是Bridge，更是Host。
听起来似乎很好办，毕竟现在集成化这么高了，开发板也是越做越小，但是要处理得来 Leap Motion 的数据不是件容易的事。因为不可避免的会遇到这些问题：

a.Leap Motion 支持 Windows、Linux 和 Mac OS X 全平台，提供了各个平台可用的 Service/Daemon ，但是这里单指x86架构。Leap Motion 现在还没有ARM架构上可用的 Service/Daemon，虽然官方在2014年不只一次提到过“releasing a ARM SDK”，虽然强调了“it will only support the architectures present in modern smartphone era devices.”但至今遥遥无期。（还因为拖延太久在论坛上被吐槽：”Justice too long delayed is justice denied.” – MLK）这以为着跑在ARM板上是没戏的了。

b.除了没有ARM板可用的Service/Daemon外，开发板的性能能否处理得来Controller采集到的大量数据，即使勉强处理得了但是精度和刷新率大大降低，就没有用Leap Motion的意义了。

所以我们需要的是一块x86架构，且性能不错的开发板。

最后，我们选用的方案选用的是 Intel Edison + ubilinux + Leap Motion 的组合。

//待续

如果本文对您生活或工作产生了积极影响，那我非常高兴。
如果您愿意为文章的内容或想法提供支持，欢迎点击下边的捐赠按钮，资助作者创作更多高价值高品质的内容。