机器守门员-系统设计

一、主传感器方案的选定

刚刚决定要做这个守门员的时候， 基本上的算法思路如下框图所示：

第一个环节， 获取球的三维坐标， 是整个系统最核心最关键的部分， 之后所有的环节都依赖三维坐标作为基本输入。 所以， 如何获取三维坐标， 是系统设计阶段最先要考虑到的问题。

在网上搜索robot goal keeper， 机器守门员这种关键词， 很快找到了一些视频和解决方案， 其中那个挑战梅西的日本视频流传最广。 这些方案无一例外， 基本都是使用高速双目摄像头进行的三维坐标获取。

像这个图片里面， 第一眼很难找到摄像头的位置。 我猜想摄像头应该摆放在左右顶棚的位置， 以固定的角度拍摄场地， 通过双目定位的方式， 计算球的三维坐标。 双目的方案很稳定， 受光线影响比较小， 且帧数较高（普遍在90fps以上）， 能够看清极其快速的射门。 但是双目的问题在于， 很依赖场地的搭建。 比如这个图中， 假如没有搭建外圈的支架场地的话， 摄像头如何安装呢？ 如何保证摄像头的固定呢？

我的第一反应也是使用双目摄像头作为我们此次的方案， 但是有两个原因让我放弃了：

1. 安装的麻烦： 我们开发门将和供应商提供防护网是分开进行的， 也就是说在活动开始前一天， 我们的设备才会放到活动场地中进行调试。 而我们的测试场地是在室内， 室内也不允许我们随意在墙上打眼固定摄像头， 所以使用双目有很多阻碍。
2. 方案的同质化： 这么多的方案全都使用了双目， 如果方案从头到尾都照抄他人的， 我们的开发就显得毫无价值了， 还不如就买一台来做活动， 还多快好省。 因此， 不用双目也是对我们自己的挑战。

那么不用双目真的就没办法获取三维定位信息么？ 其实不然， 方法还有很多。 其中有一个比较适合我们这个场景的， 就是RGBD相机。

如上图所示， 我们的方案是将RGBD摄像头固定在球门正上方。 这应该是第一次有人用这个方案制作机器人门将。  这个方案的优势和缺陷同样明显， 下面我来详细介绍一下。

从事机器人行业的朋友应该比较熟悉RGBD相机。 RGBD相机有个特别日常生活化的使用场景， 就是体感游戏机。 玩过xbox360的朋友们是否还记得有个体感控制器， 叫做kinect。 有了这个kinect， 就可以在家和朋友一起打网球， 做运动， 切水果等等。 这个kinect就是RGBD相机。

那为什么不叫体感摄像头， 叫RGBD？ 这就和他的成像有关系了。 稍微了解一些摄像机成像原理的朋友就知道， 数字相机拍摄的照片中的每个像素都有RGB三个分量， 分别是红色绿色蓝色的强度， 这三原色可以合成各种不同的颜色。 数字照片的数据中， 每个像素都包含RGB三个通道的分量。 所谓RGBD的相机， 就是除了RGB三个分量， 还有深度这一项信息。 也就是每个像素点离成像空间的物理距离。

上图就是RGBD相机拍摄出来的图像。 左图是深度图（D）， 右图是普通的RGB图像。 根据深度图的深度信息和rgb图像， 我们就可以获取可视范围内所有点的颜色和空间位置了。

如果你没明白这两段， 没关系， 只需要知道RGBD相机能感知物体的空间信息就好了。

这样的RGBD方案有什么优略吗？ 当然， 对比双目方案来说， 劣势有：

1. 帧率低： 目前最新的realsense相机（RGBD的一种）只能达到60fps的帧率， 速度极快的球有可能看不清， 影响计算和扑救。
2. 受光线影响较大： RGBD的深度信息目前还是主要依赖主动投射的方式获取深度信息的， 因此如果暴露在自然强光下效果会变差甚至失灵。 如果光线太弱也会影响， 对光线的鲁棒性比双目较差。

同样的， 他的优势也很明显：

1. 安装调试极其方便： 只需安装在门框上， 标定出一个俯视角度即可使用。 而双目需要分别标定两个摄像头的外参， 在经常换场地的情况下非常麻烦。 而RGBD的方案只要确定俯仰角就可以了。
2. 三维计算容易：算法上由于有了RGBD信息， 计算球的位置的算法相对双目运算量更小， 更简单。

最终我们选用了intel今年最新的RGBD相机， realsense D415。 于是， 带着优势与劣势， 与广大方案不同的新方案也在犹疑中诞生了。

二、结构的设计

软件的开发， 就像球场上的战术制定， 穿插跑位， 节奏调度， 软件让整个系统有机顺畅的运转起来。 硬件的开发， 就像每个队员的身体训练， 力量、速度、耐力、爆发， 硬件让球员有了执行战术的基础。  这个机器守门员也是一样， 有软件和硬件设计两部分的内容。 而且硬件应该先于软件设计完成， 才能给软件算法提供基本的测试环境和条件。

硬件设计不像软件， 可以快速迭代重构， 硬件的修改周期较长， 这就决定了硬件设计需要慎重， 要深思熟虑， 充分考虑需求。 设计不能过度， 远超实际需求的话会提高成本； 设计也不能不够， 达不到指标或刚好卡在指标处的话， 就会给软件留下噩梦般的调试体验。

一句话， 合理制定需求， 设计上给需求留一定裕量。

所以， 需求到底是什么， 我们得把“机器守门员”这样一句抽象的语言， 变成非常具体的设计指标， 才能变成我们的需求， 作为设计的输入。 从以下四个方面去考虑：

1. 球门的大小： 有人会觉得奇怪， 球门的大小为什么会成为障碍？  一开始我也没get到，直到发现了问题才为时晚矣。 球门越大， 意味着守门员越高， 转动惯量越大， 重力下坠力臂越大， 对电机的功率要求越大。 本次使用的球门尺寸为3m*2m， 就是宽为3m高2m， 守门员高度也就是1.95m左右。

2. 可防的球速： 我们的感知系统最远能感知的距离也就是7-8m左右。 普通人的球速大概可以达到72km/h， 也就是20m/s， 在7-8m的距离射门， 球的飞行时间大约在0.35s-0.4s。 那么我们设计为了够防守住普通人的射门， 从球飞起开始算起， 0.35s之内守门员必须扑救到位， 0.35s包含了感知和预测落点的时间和扑救动作的执行时间， 如果给两边各留一半时间的话， 那么扑救时间就是0.175s。 这就是一个设计输入了。 因此在电机和减速机的选择上， 有了这一数值作为参考需求。

3. 成本控制：不考虑成本的话， 很多指标都可以达到。 比如说用巨大功率的电机啦， 使用一体设计啦， 使用定制舵机啦， 都是非常耗费成本的方案，  因此电机使用， 结构设计都得经济实用才行。

4. 可搬运性： 这是成本之外最麻烦的一个点了， 由于设备放在调试间开发， 活动时要拿出去放在活动场所供使用， 使用完毕还要再拉回来， 这就要求设计上得考虑容易拆装， 得模块化， 不然搬运起来头疼。

如图所示， 转轴前后各有一个轴承座， 能够防止电机轴受力， 提高系统的使用寿命。 同样， 使用箍管的方式， 也能够有效减轻守门员的重量， 减轻电机的负担。

三、架构详细设计