嵌入式OS的现状、智能的物联网与未来的机器人
嵌入式开发是一个低调的领域。相比Web开发和企业级开发，嵌入式开发这一领域似乎很少在互联网上发出声音。随着智能设备的兴起，智能手环、手表、眼镜、灯泡等产品成为互联网企业的下一个目标，而物联网这一概念再次复苏，嵌入式开发开始引起很多互联网工程师的关注。
那么，现在的嵌入式开发是怎样的？相比十年前、二十年前有什么发展？“物联网”这一大概念下，应用开发者应从何切入？本次访谈，我们邀请到一位不那么低调的嵌入式开发者，来跟我们分享他对这些问题的看法。
嘉宾简介
罗未（Noel），豌豆机器小组（WRTnode machine team）发起人，致力于整合机械设计、嵌入式Linux开发、计算机视觉、机器学习方向，以开源的理念制造智能交互机器，希望为开源社区和大众市场带来各种伴随人类却又独立于人类的机器。个人出身于行业软件领域，3年前转入硬件方向，经历过智能家居和路由器行业，现希望做一些让未来更近的事情。
罗未是2014年全球架构师峰会（ArchSummit）的联***之一。有关他的更多介绍可参考技术人攻略对他的访谈：开放制造的机器之心。
以下内容根据InfoQ中文站编辑跟罗未的沟通整理而成。
嵌入式操作系统现状
目前嵌入式设备主要分为两大类：MCU设备和带MMU的CPU设备。
MCU（Micro Computing Unit），也就是我们常说的单片机，其特点是Micro：主频大概在几十MHz，内存在几KB，Flash非易失存储也是几十KB，资源小，价格便宜。单片机这个领域从80年代、90年代开始就一直有人玩，像是玩具、闹钟、计算器、电子表、工业控制等很多领域都有用到，应用广泛。单片机程序的特点是逻辑简单、实时性强没有等待，不像Linux那样会存在资源被其他程序占用的情况。
早期单片机程序一般都是裸写C代码的方式，用一个大循环把所有事情搞定，所有的底层功能——如资源分配、进程调度、DNS查询、域名转换等，都要手写实现。前几年开始有一些基于MCU的操作系统，比如μC/OS、RT-Thread等，单片机有了操作系统就相当于资源分配、进程调度等工作不用手写了，可以交给系统去管理，程序员不用去管任务间协调的问题。这可以看作是第二代单片机开发环境。
近几年有一些新的单片机操作系统，比如Contiki，这套系统的特点是把互联网特征作为基础的构建。这套系统很牛，用10KB以内的内核就提供了对HTTP、TCP/IP等协议的支持，让单片机上来就可以联网，让单片机开发者绕过了每次都要裸写这些基本功能的痛苦。
现在的单片机有些很神奇的应用，比如图像识别、语音识别，可以做到在视频上识别色块的程度。但是，单片机如果又要做图像识别又要上网，就会非常吃力，毕竟资源十分有限，需要有很高的开发能力把它们协调好，这种情况下就不能用操作系统了。
以上是单片机的情况。另外一种是更大一些的，就是自带MMU（Memory Management Unit，内存管理单元）的设备。这种设备的主频一般在几百MHz以上，内存在几十MB以上，早些年的智能手机就差不多是这个配置，跟十几年前的PC机配置差不多，所以安装运行Linux系统是没有问题的。这类设备其实也做了十多年了，现在用的比较多的架构有两个：ARM和MIPS，都是商业的，现在新的硬件基本上都是这两种架构。
有很多发行版都专门为ARM做过安装包，比如流行的Ubuntu和Debian。无论是ARM还是MIPS，因为有了系统，开发起来要比在单片机上舒服多了，但也仍然有一个很麻烦的地方，那就是要做交叉编译。开发者一般都是在自己电脑上——大部分是x86架构——完成开发的，因此要用x86上的ARM编译器交叉编译出ARM的二进制文件，用MIPS编译器交叉编译出MIPS的二进制文件，才能在设备上运行，这为调试带来了不小的麻烦。为什么我们这个圈子门槛比较高，就是因为一般都是掌握了交叉编译的开发者才会进来玩。不过好在有一个叫做GDB（GNU Debugger）的工具可以做远程调试，减少一些麻烦。
物联网终端需要完成的工作
现在在有一种M2M（Machine to Machine）的思路，在终端用可以联网的单片机做最简单的事情，比如开关一个灯泡；终端直接跟家庭网络的网关（路由器）连接，或直接跟公网的云端连接，由云端做更复杂的计算和处理。
这种思路可以解决一部分问题，但是我觉得还不够。终端需要做更多的事情。
我认为终端需要是智能的，它们需要达到“机器人”的层面。现在我们说的机器人跟以前大家理解的那种人型机器人不同，现在所说的机器人是一种复杂控制系统，是软件，可以跑在各种各样不同姿态的设备上。机器人需要完成三项工作：
- 感知：从传感器采集数据
- 交互：网络传输（如HTTP、TCP/IP）和物理控制
- 智能：如图像识别、语音语义的理解、智能规划，需要抽象成智能的算法
现在的机器还处于太过依附于人类的状态，需要人告诉他要做什么。我觉得未来的机器应该自己知道要做什么事情。现在的人工智能、知识图谱的建立就是奔着这个方向去的，比如Google工程师训练机器，让机器在Youtube的视频里认识猫，这个涉及到一个很大的知识库和训练过程，需要云端的协助。但最终训练出来之后，其实猫的图像识别特征数据是很小的，可以放在终端的机器人里，他们自己就会认识猫了。这就好像婴儿的学习过程一样。
但是跟婴儿不同的是，机器天生是执行器。所以结合认知能力，让机器认识猫了之后，加上执行，是不是可以让机器自动的去抓猫或者逗猫玩？机器认识电梯之后，是不是能够自己去按电梯？机器认识无线充电站后，是不是能够自己跑到无线充电站上面蹲着充电？随着知识图谱的建模完善，事物和事物之间的联系能够被机器理解，机器人会变得越来越强大，越来越重要。
其实现在语音语义的知识图谱建设已经相对完善了，机器已经能够理解一些上下文之间的关系，比如你说到吃苹果，他就知道你说的是什么意思。我们现在在语音语义+网络这块直接使用了讯飞的服务，我们把工具链给他，他们帮我们生成了一个二进制包给我们，就很方便了。
技术上的挑战
上述这些工作当中，有些单片机可以完成的很好，有些不能。单片机可以采集一些简单的数据如位置、高度、重力加速度、四轴姿态、温度、湿度等，进来都是数字，只需要做AD转换。比较复杂的数据如声音、图像，单片机处理起来就比较困难，一般我们通过Linux的USB驱动来跑，需要MMU的芯片。但是单片机有一个特征是Linux无法满足的，就是实时性。很多物理控制对实时性的要求很高，比如四轴飞机的控制，严格要求50Hz的控制频率，即一秒进行50次计算来决定下一帧的动作，如果稍微有点资源抢占造成延迟，飞机就掉下来了。
为了同时达成实时计算+复杂性这两个目的，我们只好把两个芯片加在一起。但是两个芯片在一起，就成了一个分布式系统，有芯片级的通信问题，同时开发者还需要写两套代码，又要写单片机的交叉编译，又要做Linux开发，各种调试和测试的困难。Arduino现在已经有一套挺完善的思路：首先它的传感器、控制器的库都很全，然后它做了一个ArduinoYUN的板子，就是一个OpenWRT（一个超级精简的Linux发行版）+单片机的双芯片板子，然后它有一个万用固件——一个支持firmata协议的库，算是一个翻译，只要符合这个协议就可以从Linux控制Arduino，算是一种思路。但是我觉得这个思路有两个问题：第一，ArduinoYUN的思路是以MCU开发为主，把OpenWRT当做单片机的透传模块，为单片机提供网络服务。放着强大的芯片在一边，用小小的单片机跑主程序，感觉未免太浪费。第二，firmata协议虽然简化了控制，但是又影响了实时性，在实时性要求较高的时候（比如四轴飞机），这种思路又无法满足需求了。
现在一些芯片公司已经开始意识到这个问题，开始考虑如何把两者封装成一个芯片，来满足实时性+复杂性的结合。我认为封装后应该要以Linux为主要的开发平台和软件运行平台，以MCU作为辅助以满足实时性需求。
所以，实时性+复杂性的结合是第一个挑战。第二个挑战是复杂运算的加速，比如H.264/H.265的视频压缩、图像识别的硬件加速，要不要放在机器人的芯片里？我觉得是需要的，但是不需要手机那么强的GPU，有一个视频压缩的芯片放在里面就可以。终端如果能做视频压缩，多半也能做图像识别，那么终端机器人可以做的事情就更多。
第三个挑战是针对Linux内核本身的，就是在这种级别的计算平台上如何进行更合理的裁剪、做更合理的算法策略、执行策略。OpenWRT的开发版现在我们做到64MB的运行时内存占用，而一般的路由器芯片都是16MB、32MB。其实内存的空间占用倒不是大问题，因为现在内存很便宜，就算用到128MB、256MB也没什么，但是关键在于时间片的占用。所谓省资源其实就是两个意思：少占地儿+少占时间，这样才能低延迟。所以Linux内核如何解决这个问题，也是一个比较大的挑战。
这三个点可能是未来几年这个产业很多人的努力方向。
总结
相比十年前裸写C代码的场景，现在我们有图形化的界面，有RESTful API，嵌入式开发的难度可以说已经大大降低了。虽然有上面提到的基础设施与开发工具的挑战，但我认为用不了几年时间也都能解决。网络连接现在已经基本不是问题，3G、4G、Wifi已经足以支撑大部分智能设备的应用场景。
但是，仅仅有这些，到“智能的物联网”有很大的距离。机器需要学习更多、建立更多的知识图谱，才能变得更加强大。现在云端还没有太多现成可用的知识图谱，但我们仍然可以先从简单的事情做起，比如让机器人扫地，让机器人把空瓶子扔进垃圾桶，一点一点的改进它们。也希望有更多的开发者能够加入这一进程，让我们的世界变得更加完整。
