背景
通过前期在家庭拖地机器人方面的工程实践，我们发现处理这种类似场景（封闭场所，环境相对静态，低速行动，需要机器人主体在2D平面上自主导航）的应用，有太多相似的地方，可以模块化，提供硬件平台+软件平台的打包方式，帮助工程应用迅速完成导航，感知，决策，运动控制方面比较专业和困难的任务，快速应用和市场化。我们把这个可复用，通过简单配置的即插即用的硬件+软件平台，统称为运动控制平台。 目前除了家庭扫地，拖地机器人应用外，我们还在 下一代智能AGV小车(自动导引车），进行工程导引，解决传统的AGV小车需要为某个特定路线预设磁条，修改路线非常困难的痛点。
目前人工智能领域普遍被认为是移动互联之后，下一个风口，但是看到能够落地的工程应用不多，其中自动驾驶是其中最炙手可热的可落地领域。互联网巨擎（谷歌，uber,百度为首），传统汽车大厂， tier1供应商，学术明星和领域知名专家的初创公司，纷纷进入该领域，投入到这场轰轰烈烈的全新的交通运输生态的创建中。截止2017年6月18日以来，共有34家公司获得美国加州路测资格，其中中国背景的公司就有9家，见下图（来自公开互联网）：
通过对自动驾驶技术的了解，发现自动驾驶与我们的运动控制平台无论从技术框架构成，还是到硬件平台应用理解，软件核心算法上都基本契合。本文通过比较自动驾驶和运动控制平台的技术栈，具体实现算法，普及自动驾驶技术，分析自动驾驶技术发展给我们留下的切入点和机会，及运动控制平台未来的扩展点。
下文的比较，自动驾驶主要拿百度的Apollo技术作为描述比较主体，因为目前自动驾驶技术，百度公开的最为彻底，它所用的思想，代表了目前做自动驾驶的主流路线。
技术框架（运动控制平台vs自动驾驶）
下图是我们运动控制平台的技术栈分层：
上图中，橙色部分是我们运动控制平台的主体，其中运算单板是运动控制平台提供的硬件模块部分，由ARM CPU，NEON， Mali GPU, FPGA 组成的嵌入式异构并行计算平台。其中感知，定位，避障，地图，路径规划，导航，跟踪是封装的软件算法模块，工程应用通过配置就可即插即用。蓝色模块，是配套，硬件部分根据工程实践的需要进行选取，软件操作系统层和仿真层是目前开源的软件栈。
运动底座是工程方进行设计提供，在我们的家庭拖地车实践中，我们自己设计了结合拖地要求的底座。在AGV小车的工程实践中，传统的AGV小车轮式结构可以直接拿来用。 一般来说，对于低速移动的场景应用，差分轮式运动底座是应用比较普遍的选择。 有两个主动轮，可以分别控制转速和转的方向， 前面有一个被动万向轮。运动底座向上提供的基本接口包括：线形速度，角速度或者曲率控制， 查询当前里程计信息（运动底座通过轮半径，转动数目进行统计），完成上层对于运动底座的底层控制和信息查询，通过低速的串行接口通讯就基本满足要求。做对机器人做算法学术研究，或者前期对运动控制算法做验证阶段，会选择商用的运动底盘提供商的产品，如比较有名的kobuki运动平台，从图中可以看到，它的提供了丰富的接口，非常方便对于传感器和计算单元的扩展。
在与运算单板同层的其他模块，都是感知单元。按照工程实践的实际要求，进行选取。这些感知单元涵盖了目前主流的环境感知技术，传感单元中 没有包含gps。 这跟我们目前运动控制平台主要的应用场景和要求有关。 我们的工程应用目前在室内的比较多， gps 在室内环境是没有信号的，对于定位没有帮助。 传感单元中提供了碰撞传感的选项，在室内扫地拖地场景中，低速机器人是要求尽量全覆盖，尤其是墙角边缘，这样是需要碰撞传感结合满足要求的。 在其他场景如AGV小车，则不能碰撞，不需要与障碍物无限靠近。激光雷达的选择，结合成本和当前应用场景的要求，单线雷达就满足要求。 传感器的作用相当于，机器人的眼睛，跟上层软件功能栈配合，完成定位算法，物体识别，物体跟踪，建图，避障，动作规划功能。
操作系统层面，我们的软件建立在目前主流的机器人操作系统ROS（Robot operation system)。ROS是Willow Garage公司在2010年发布的开源机器人操作系统，由于其具有点对点设计，不依赖于编程语言，分布式架构，强大的硬件抽象，广泛的社区参与贡献，丰富的可复用，知名的开源库资源，已经成为机器人设计的不二选择。对于低速运动场景，原生的ROS环境完全满足设计要求。
Gazebo 仿真平台是机器人设计人员的主流选择。在算法验证阶段，我们不可能缺省认为运动底座，传感器，单板，驱动都准备就绪的机器人，立在那里等我们上板调试。也不可能有户型各异，障碍物摆放各异的室内环境让我们去尝试。仿真平台对于机器人设计至关重要。 Gazebo 仿真平台是一个开源的仿真工具，通过Gazebo，我们可以在pc上设计我们的机器人外观，各种传感方式，机器人各部分相对移动方式（如机械手臂6个自由度的移动）。我们可以设计任何三维环境，根据设计师三维建模水平而定，可以设计无限逼真的三维仿真环境。当然，简单的环境仿真，直接通过所见即所得的方式，拖拽一些缺省模块，可以快速建立一个室内仿真环境。 我们曾经为商场扫地车工程实践， 设计过一比一的扫地车，和商场模型，玻璃窗和地面的光反射，激光透射玻璃都相当逼真。我们可以在pc 的Gazebo平台上，使用我们预先建立的机器人模型和环境模型，验证算法。Gazebo 仿真平台目前是商用自主移动机器人，无人机设计的主流选择。
下图是自动驾驶Apollo技术框架（来自于互联网）:
百度的自动驾驶分为四层技术栈：
1. 参考汽车平台： 一辆汽车， 必须可以实现电子化的控制，也就是线控。百度目前的参考设计使用的是Lincoln MKZ, enhanced by Autonomous Stuff, 为用户提供了一个无障碍的自动车辆平台。该平台为用户提供了一整套硬件和软件解决方案。用户可以直接获得车辆某些模块控制权限，如档位，速度和指示灯。见下图：
2. 参考硬件平台： 为了实现高性能稳定的计算，百度采用的是工业级PC Neousys宸曜科技 Nuvo-5095GC作为运算单元， 配置6th-Gen Intel® Core™ i7/i5 LGA1151 CPU 和NVIDIA® GeForce® GTX 1050* GPU，可以工作在-25度到60度的工作范围。
GPS/IMU采用的是NovAtel SPAN-IGM-A1，理论上 rtk-gps加IMU的融合方案出来的精度能达到厘米级别。在apollo 1.0 没有公开摄像头，Lidar(雷达)，Radar(毫米波雷达)信息，不过根据百度以前无人驾驶车的信息，有一个Velodyn 64线HDL64E雷达，配套一个长距毫米波雷达和中距毫米波雷达，一个鱼眼摄像头和一个摄像机镜头。
3. 操作系统： Apollo 采用 ubuntu 14.04+ ROS indigo。 其中ROS是做了定制化修改的，使得更适合自动驾驶的要求，后面章节会详细介绍。
4. 上层算法：算法模块的构成与运动模块基本类似。多了端对端和HMI。HMI是百度自动驾驶提供的人机交互界面，方便操作者统计，调试。 端对端算法是一种所见即行动的一种思想，通过深度学习，将感知直接转化为控制，这是一种实验性质的算法，目前的状况不应该是主流应用。
5. 云： 主要有三个作用, 训练模型， 自动驾驶仿真， 高精地图提供。
从上面关于运动导航模块和自动驾驶技术栈的描述，我们可以看到两者之间有颇多相似的地方。
1. 运动底盘 vs 参考汽车平台：都是运动的控制主体，为上层算法提供控制接口进行驱动，提供查询接口进行反馈。 运动底盘和汽车控制的时候都是要满足非完整约束，就是不在作出向前移动的情况下，无法单独完成横向位移。 相比于运动底盘，汽车平台的动力学模型会更加复杂，除了速度不是一个量级的 ，惯性因素会使得控制更加复杂。 汽车的横向位移（转弯）靠前轮的朝向与前轮后轮形成直线的夹角的变化，属于自行车模型。 运动控制模块多采用差分轮运动底盘，横向位移靠两个轮子相互反方向旋转，靠不同的旋转速度比，来满足不同曲率的要求。在控制算法的选取中，会有不同。
2. 硬件平台： 运算单元和感知单元部分。 运算单元， 运动控制平台采用的是嵌入式异构计算单板， 满足低速简单运动场景的感知算法，决策，控制算法的计算要求。 汽车应对的高速，绝对可靠安全的场景，运算量不是一个量级，目前多采用工业级PC的方案，里面多采用英伟达的GPU，来满足感知对于运算量的要求。芯片厂商， 英伟达，德州仪器，赛灵克斯，intel， 也纷纷推出自己的芯片方案，中国的寒武纪，中星微也有自己的芯片方案，后续运算单元平台将是百花争妍的局面。感知单元， 运动控制平台和自动驾驶采用的传感器大多重叠。有几个不同地方。 深度摄像头可以在运动控制平台应用场景中的室内场景中使用，深度主要靠结构光技术，抗干扰能力差，目前的技术上，在室外场景不可靠。 自动驾驶多采用双目摄像头来完成深度识别。 运动控制平台采用超声和红外完成被动障碍感知， 自动驾驶采用汽车电子方面非常成熟的毫米波雷达方案。
3. 操作系统， 两者都使用 ubuntu 14.04+ ROS indigo。汽车对于实时性， 带宽， 分布式要求会更加严苛。 原生的ROS 对于这三方面都无法达到自动驾驶的要求，虽然 ROS 2.0 会在这三个方面有很大的提升，但是仍然处于实验阶段。 大部分自动驾驶厂商，包括百度，都是在ROS基础上作深度定制。
4. 上层算法：模块分类基本类似，所采用的算法实现有很多借鉴的地方， 在后面的章节详细描述。
5. 仿真： 运动控制平台的场景相对简单，采用开源的gazebo 仿真技术，在一些相对高配置的pc上基本满足要求。 自动驾驶一般要自动驾驶厂商自己搭建仿真平台， 汽车要仿真的环境非常复杂，计算量消耗很大，一般要采用云技术分布式平台。
6. 地图： 运动控制平台的地图创建所描绘的场景比较简单， 一般2d 场景地图大概满足要求，在运算单元上可以完成创建和使用。 自动驾驶需要高精地图， 3维点云，精确到厘米级别，全国地图。 特点是需要提前采集，需要花费巨大成本用采集车去采集，生成的高精地图要随时去更新，消耗大量的存储，一般要放在云端，自动驾驶车通过高速无线网络下载当时位置的高精地图满足实时决策要求。
7. 训练： 运动控制平台会对地垫，椅子，人有简单识别要求，实际情况根据工程需要。模型提前可以在服务器端训练，训练数据相对不多。 汽车有海量的数据要进行训练，满足高可靠性的物体识别任务，要在云端进行训练。
8. 运动控制平台的多机协作要求 vs 车联网方案： 目前运动控制平台的设计没有过多考虑多机协作的要求，不过会在以后扩展，应用场景如 多个AGV小车互联互通共同完成调度任务，是车车通信的一种方式。 车联网方案是自动驾驶的一条路径，在百度Apollo框架中并没有提及。 包含V2V(车车通信），V2I( 车路通信）， V2P（车人通信），完成信息共享后的汽车决策，控制算法。目前通信标准主要是欧美主推的DSRC(专用短程通信）和中国主推的5G标准LTE-V。
后面的章节，会对具体的一些算法和模块进行一些详细比较和描述。