写点什么

ARKit 何以从同类技术中胜出?

  • 2017-08-23
  • 本文字数:11596 字

    阅读完需:约 38 分钟

本文最初发布于 Matt Miesnieks 的博客,经原作者授权由 InfoQ 中文站翻译并分享。阅读英文原文: Why is ARKit better than the alternatives?

Apple 今年 WWDC 上公布的 ARKit 在扩增现实(Augmented Reality)领域造成了巨大的影响。开发者们首次发现,自己的应用竟然获得了一个健壮、(在 iOS 11 配合下)广泛可用,并且“能用”的 AR SDK。终于不再需要纠结识别标签(Marker)、初始化、深度摄像头(Depth camera),或者各种专有的创作工具等概念。毫无疑问,这项技术的横空出世催生了层出不穷的演示(可通过 Twitter 关注 @madewitharkit 了解最新演示),然而大部分开发者并不知道 ARKit 的工作原理,也不知道这项技术比其他 SDK 更出色的原因所在。了解 ARKit 的技术原理有助于理解 ARKit 目前存在的局限,未来的完善方向和原因,并帮助我们预测类似的能力何时会出现在 Android 和抬头显示器(VR 或 AR)上。

我在 AR 领域的相关工作已经持续九年了,过去曾开发过与 ARKit 一模一样的技术(可惜当时的硬件无法很好地支持这种技术)。我对这类系统的构建方式,以及使用这种方式进行构建的原因有着自己的理解。

(点击放大图像)

本文试图向略懂技术的人解释这项技术,但并非面向计算机视觉工程师。文中为了简化而进行的阐述可能未必绝对完美,但希望这样的简化至少可以帮助大家获得更深入的理解。

ARKit 是基于哪些技术构建的?

(点击放大图像)

从技术角度说,ARKit 是一种具备简单2D 平面检测(Plane detection)能力的视觉惯性里程计(Visual Inertial Odometry,VIO)系统。VIO 意味着可以通过软件实时追踪用户在空间中的位置(用户的6dof 姿态),例如在屏幕每刷新一帧的过程中重新计算用户姿态,这种操作每秒钟大约进行30 次或更高频率。这种计算工作会并行进行两次。用户姿态可通过视觉(摄像头)系统进行追踪,为此需要将现实世界中的点与相机传感器拍摄的每一帧画面上的一个像素进行匹配。此外还需要通过惯性系统(加速计和陀螺仪,统称为惯性测量装置[Inertial Measurement Unit],即IMU)追踪用户姿态。随后这些系统的输出结果会通过Kalman Filter 合并,进而确定其中哪个系统能对用户的“实际”位置(也叫做地表实况[Ground Truth])提供最佳估测,并通过ARKit SDK 发布位置更新。与汽车中统计行驶距离的里程表类似,VIO 系统会追踪iPhone 在6D 空间中的移动距离,6D 代表3D 世界中的xyz 移动(转换),外加俯仰(Pitch)/ 偏航(Yaw)/ 翻滚(Roll)的3D 移动(旋转)。(译注:关于后者的形象说明与演示,可参阅: http://blog.csdn.net/yuzhongchun/article/details/22749521

VIO 最大的优势在于,IMU 的读数每秒可更新大约 1000 次,其数值完全基于加速度(用户的移动)。以往主要使用航位推算(Dead Reckoning)技术测量设备在两个 IMU 读数之间的移动,但这种技术只能进行猜测(!),就比如我让你迈出一步,随后猜测你的一步有多长距离一样,此时只能用航位推算技术来估测距离。下文将介绍这种技术提高精确度的具体做法。惯性系统的误差会逐渐累积,因此两个 IMU 帧之间的时间间隔越长,或者惯性系统不通过视觉系统进行“重置”一直使用的时间越长,追踪结果与地表实况之间的误差就越大。

视觉 / 光学测量的频率可与摄像头的帧率保持一致,通常为 30fps,并且完全基于距离(两个帧之间的场景变化)。光学系统的误差通常会随着距离而累积(时间的影响反而比较小),因此移动的距离越长,误差就会越大。

好在两种系统固有的优势结合在一起可以相互弥补劣势。

视觉和惯性追踪系统基于截然不同的测量系统,相互之间不存在依赖性。这意味着就算摄像头被遮挡或只能看到光学特征极为有限的场景(例如白色墙壁),惯性系统依然可以在少数几帧的范围内继续测量。或者设备可能处于静止状态,此时视觉系统可以提供比惯性系统更稳定的姿态检测。Kalman 过滤器始终会选择最佳质量的姿态,进而实现最稳定的追踪。

看起来挺不错的,而有趣的地方在于,VIO 系统已诞生多年,整个业界对此已经极为了解,市面上已经有不少具体的实现。因此 Apple 选择 VIO 也不足为奇,但我们更好奇的是为何他们的系统会更为健壮。

ARKit 的第二个主要功能是平面检测。正是因为有了这个功能,我们才有了用于放置内容的“表面”,否则所有内容只能悬浮在空间里,挺可怕的。平面是由光学系统检测到的特征计算而来的(也就是演示里看到的那些小点),算法通过取平均值,即可用任意三个点定义一个平面,如果将这个操作执行多次,即可估算出现实中的平面到底在哪里。另外,这些点通常也被称之为“点云(Point cloud)”,这个概念也经常会被人混淆。所有这些点结合在一起可以形成一个稀疏点云,进而可用于光学追踪。通过稀疏点云进行追踪需要的内存和 CPU 运算量都比较少,同时辅以惯性系统的支持,光学系统即可在只需要很少量追踪点的情况下有效运作。这种点云与类似于照相写实主义(Photorealism)那样的密集点云是截然不同的类型(一些正在研究中的追踪系统可以使用密集点云进行追踪……更困惑了吧)。

一些误解

补充说明一下,我看到很多人将 ARKit 理解为 SLAM(Simultaneous Localization and Mapping,即时定位与地图构建),或使用 SLAM 这个词来称呼追踪技术。需要澄清的是,SLAM 是一个很宽泛的术语,类似我们说的“多媒体”。追踪这个词本身也是一个宽泛的称呼,如果使用“量距(Odometry)”就具体多了,但在 AR 方面这两个词实际上意思比较接近。这一点可能会让人混淆。SLAM 的实现方法有很多,追踪仅仅是整个 SLAM 系统所包含的组件之一。我觉得 ARKit 可以看作一种轻量级的简单 SLAM 系统。Tango 或 Hololens 的 SLAM 系统可提供量距之外的更多功能。

关于 ARKit,最大的两个“误解”是:“如何通过一个镜头获得 3D 场景?”,以及“如何确定计量尺度(例如量尺的演示)?”。此处的秘诀在于以真正足够好的方式消除 IMU 误差(例如提高航位推算的猜测精确度)。做到这一点后,就可以:

若要获得 3D 场景,只需从两个不同位置获得同一场景的两个视图,并对位置进行立体计算即可。我们的眼睛也是通过这种方式看到 3D 场景的,而这也是某些追踪系统需要使用双摄像头的原因。如果有两个摄像头,因为摄像头间距离已知,并且两帧画面是同时捕获的,此时计算工作将非常容易。如果只有一个摄像头,只需捕获一帧,移动少许位置,再捕获第二帧就行了。通过使用 IMU 航位推算,我们可以计算两帧画面移动的距离,随后照常进行立体计算(实际可以通过更多帧来计算,获得更精确的结果)。如果 IMU 足够精确,那么两帧之间哪怕为了保持手部固定产生的轻微肌肉活动导致的“移动”也可以顺利检测出来!这简直就是魔法。

为了确定计量尺度,系统也需要依赖 IMU 提供精确的航位推算。通过 IMU 提供的加速度和时间测量值,我们可以后向合并以计算速率,并再次合并回来以获得 IMU 帧之间的位移。计算过程并不难,难点在于消除 IMU 的误差以得到近乎完美的加速度测量值。任何微小的错误,如果每秒钟出现 1000 次,在移动手机的过程中持续数秒钟,最终都会累积造成 30% 甚至更高的尺度误差。Apple 能将这个误差降低到个位数百分率,这真是让人佩服。

Tango、Hololens、Vuforia 等产品又如何呢?

(点击放大图像)

Tango 其实是一个品牌,并不是某个具体的产品。其中包含了硬件参考设计(RGB、鱼眼、深度摄像头,以及某些 CPU/GPU 规格)和软件栈,可提供 VIO(动作追踪)、Sparse Mapping(区域学习),以及 Dense 3D 重建(深度感知)等功能。

Hololens 具备完全相同的软件栈,但还包含一些 ASIC(被称之为 Holographic Processing Unit,全息处理单元),借此分摊 CPU/GPU 的处理任务以降低能耗。

Vuforia 几乎也是相同的,但不依赖特定的硬件。

上述三种技术使用了相同的 VIO 系统(Tango 和 ARKit 甚至使用了同一套最初由 FlyBy 开发的代码!)。Hololens 和 Tango 都没有使用深度摄像头进行追踪(但我觉得为了解决某些边缘案例,他们正在着手这样做)。那么为何 ARKit 的表现会这么好?

答案在于,ARKit 其实并不比 Hololens 好到哪里去(甚至可以说 Hololens 的追踪系统是市面上最棒的),但 Hololens 硬件的普及率太低了。微软本应将 Hololens 的追踪系统包含在 Windows 智能手机中,但我想他们是出于商业方面的考虑并未这样做(例如可能导致成本增高,需要花时间对手机传感器进行校准,设备销量太小,而微软提供类似 ARKit 的方案并不足以将开发者从 iOS/Android 平台策反过来)。

过去一年多的时间里,Google 本来也可以很轻松地将 Tango 的 VIO 系统包含在出货量巨大的 Android 手机中,但他们也没有这样做。如果当时真这么做了,反而会让 ARKit 成为“跟风者”,而非“引领者”。我觉得(没什么真凭实据)这是因为每家 OEM 厂商不想自己分别进行繁琐的传感器校准,进而导致每个 OEM 版本的 Tango 实际使用效果各异,而对于设备出货量足够大,值得这么做的少数 OEM 厂商(三星、华为等),Google 也并不希望过于讨好他们。因而他们等于在告诉 OEM 厂商:“硬件参考设计是这样的,用不用随意”。(当然实情绝不会这么简单,不过 OEM 给我的反馈就是如此)。随着 Android 智能手机硬件逐渐变得商品化,摄像头和传感器已成为不同厂商差异性最主要的来源之一,OEM 厂商们怎么可能为 Google 做嫁衣!Google 还强制要求必须使用深度摄像头,这会导致厂商的手机物料成本(以及耗电量)大幅增加,这也成了 OEM 厂商拒绝的另一个原因。但随着 ARKit 的发布,情况截然不同了…… 我倒是很想看看:(a) OEM 厂商能否找到取代 Tango 的系统(他们正在努力寻觅中);以及 (b) 他们是否会向 Google 让步使用这套硬件参考设计(以及相应的控制平台)。

因此最终来说,使得 ARKit 如此出色的主要原因依然在于,Apple 可以承担这样做的成本,将 VIO 算法与传感器紧密集成,并投入大量时间进行校准以消除姿态计算过程中的误差 / 不确定性。

此外需要注意,对于 OEM 系统来说,其实还有不少备选方案。学术领域有一些追踪系统(例如 ORB Slam 就很不错,OpenCV 也提供了不同的选项),但这些系统基本都是纯光学的(基于一个或两个 RGB 摄像头,和 / 或深度摄像头,有些使用稀疏地图,有些使用密集地图,一些使用深度地图,也有一些会使用来自传感器的半直接数据。具体实现方式五花八门)。此外在追踪系统领域还有很多初创公司,例如 Augmented Pixels 就是其中之一,他们的成果还不错。但到最后,任何 VIO 系统都需要配套的硬件模块和校准工作。

作为开发者,我该选哪个?为什么?

(点击放大图像)

AR 项目的开发可以从 ARKit 着手。这项技术已经实用,并且你可能已经有了兼容的手机。但是对于围绕现实世界,无法控制具体场景的应用,以及可控制每个像素的智能手机 /VR 应用,这两者之间存在巨大的差异,在设计和开发应用的过程中必须重视这个问题。

随后可以转为 Tango 或 Hololens 开发,借此了解当你的内容能够与不受控场景中包含的 3D 结构进行交互时会发生些什么。

这一过程的学习曲线极为陡峭,甚至远远超过从 Web 到移动,或从移动到 VR 开发。你需要彻底重新思考应用的工作方式,以及合理的用户体验或用例。我已经看过了不少 ARKit 演示,而类似的演示 4 年前就有人用 Vuforia 创建过了,甚至 8 年前也有人使用 Layar 创建过。开发者正在重新学习相同的内容,只不过这次的规模更大一些。多年来,几乎每种类型的 AR 应用我都见过,我很愿意提供自己的反馈和帮助,欢迎随时联系。

我会鼓励开发者大胆开发各类新颖的应用,毕竟以往很多试水的应用都是首先针对智能手机开发的…… 同时若要针对掌上设备这样的硬件展示 AR 的效果,也很难找到合适的用例。

这个圈子不大,很少有人能构建出足够好的系统

(点击放大图像)

在这种追踪系统的实际效果方面,最令人痴迷同时也未得到普遍认可的一点在于:全世界能构建这种系统的人真的是少之又少。该领域内工程师之间的相互联系和交流使得单镜头VIO 成为移动设备追踪的最佳解决方案。(至少目前来说)其他任何方法都无法获得同等的体验。

VIO 系统最早由波士顿的军事 / 工业供应商 Intersense 在 2000 年代中期开发而来。作为该技术的一位共同发明者,Leonid Naimark 曾在 2011 年担任我成立的初创公司 Dekko 的首席科学家。在 Dekko 发现由于传感器本身的局限,VIO 无法在 iPad 2 上运行后,Leonid 重新投身军工行业,但 Dekko 当时的 CTO Pierre Georgel 现已成为 Google Daydream 团队的资深工程师。后来,我在 Super Ventures 的合作伙伴 Ori Inbar 成立了 Ogmento,很快这家公司更名为 FlyBy,他们的团队成功开发出一套基于 iOS 平台,使用外接式鱼眼摄像头的 VIO 系统。这套代码随后许可给 Google,并演变为 Tango 的 VIO 系统。随后 Apple 收购了 FlyBy,使得这套代码现在成为 ARKit VIO 的核心。FlyBy 公司 CTO Chris Broaddus 还在继续为 Daqri 开发追踪系统,但他现在已加入一家生产自主机器人的公司,Zoox 的原首席科学家也在这家公司,此人在牛津读完了博士后学位(另外我成立 6D.ai 时的共同创始人目前正在领导 Active Vision Lab 的开发工作)。第一个移动 SLAM 系统是在 2007 年前后由 Oxford Active Computing lab (PTAM) 的 George Klein 开发的,随后他还负责了 HoloLens 的 VIO 系统开发,当时与他合作的 David Nister 后来转为开发特斯拉的自主系统。George 的同事,当时正在读博的 Gerhard Reitmayr 后来开发了 Vuforia 的 VIO 系统。Vuforia 的工程主管 Eitan Pilipski 现在正负责 Snap 的 AR 软件工程工作。当年在牛津大学、剑桥大学和帝国理工学院参与 Kinect 追踪系统开发工作的研究团队重要成员,现在正在负责 Oculus 和 Magic Leap 的追踪系统开发任务。

有趣的是,我不知道目前哪家 AR 初创公司有关 AR 追踪系统的开发工作是由当初那帮天才人员带领的。在机器人或其他类型的计算机视觉领域有相关背景的创始人,并不能证明他们的系统可以在如此广泛的环境中健壮地工作。

下文还将简要介绍目前新一代研发科学家们正在从事的项目。小剧透:并不是 VIO。

具体效果,实际是一种统计学问题

(点击放大图像)

AR 系统从不会“完全可用”或“绝对不可用”,好用与否只取决于在尽可能广泛的情况下,是否可以提供足够好的效果。不断的“完善”最终都是为了在统计学意义上逐渐趋近用户的喜好。

因此绝对不能偏信某一个 AR 应用的演示,尤其是 YouTube 上那些看起来炫酷无比的演示。在精心控制安排的环境中所实现的效果,与现实生活中普通用户所能获得的效果之间,往往存在天差地别的差距。但是智能手机或 VR 应用的演示通常并不存在这种问题(设想一下,取决于手机摄像头所拍摄的位置,或用户活动手腕的方式,Slack 有可能正常工作,或无法使用,这是什么鬼!),因此观众其实都被愚弄了。

系统效果好坏最终将由统计学结果决定,下面来说一个非常具体的技术范例。

上图中使用网格代表摄像头中的数字化图像传感器,每个方框代表一个像素。为了实现稳定的追踪,每个像素需要对应现实世界中的一个点(假设设备本身可以保持绝对静止)。然而…… 第二张图片告诉我们,光子其实并不是那么“听话”,强度各异的光线会四处乱跑,因此每个像素实际上对应了抵达像素的大量光子的总和。场景中光线的任何变化(例如云朵从太阳前飘过,荧光灯的闪烁等)都会改变抵达传感器的光子的实际构成,进而导致现实世界中的每个点与不同的像素相对应。在视觉追踪系统看来,用户的位置其实已经变了!因此你会在各种 ARKit 的演示中看到,那些点在不停闪烁,因为系统正在决定哪些点是“可靠的”哪些不是。随后需要通过这些点,借助三角定位的方式计算姿态,对计算结果取平均值实现对实际姿态的最佳猜测。因此只要能通过任何方式确保尽可能消除上述过程中的统计学误差,即可打造更健壮的系统。但这需要对摄像头硬件栈(多镜头和镜头镀膜、快门和图像传感器规格等),以及 IMU 硬件和软件算法进行非常紧密的集成和校准。

软硬件的集成

(点击放大图像)

有趣的是,VIO 并不是那么难以开发,这方面目前有很多公开的算法,以及一些现成的实现。但要获得比较好的效果就难了。这么说是指,通过惯性和光学系统的聚合(Converged)就可以立刻创建出立体地图,至于计量尺度,只要有个位数级别的精确度即可轻松判断。例如我们在Dekko 开发的系统要求用户首先按照指令移动,随后将手机前后移动大约30 秒就可以实现聚合。要开发足够好的惯性追踪系统,必须有娴熟的工程师,然而目前全世界只有大概20 名工程师具备必要的经验和技能,他们中大部分人主要负责为巡航导弹、火星漫游车导航系统等应用开发追踪系统,并没有过多涉足移动消费者市场。

因此就算你能招募到这样的人,为了尽可能降低误差,依然需要具备能够紧密配合的软硬件。这也意味着必须能在软件中对IMU 进行足够精确的建模,可以全面访问整个摄像头栈并了解整个栈中每个组件的详细技术规范,更重要的是,IMU 和摄像头之间必须实现极为精确的时钟同步。系统需要能知道每个IMU 读数到底对应了哪个帧的开头位置,哪个读数对应了帧的结尾位置。这是将两个系统结合在一起的关键,但这一点直到最近才顺利实现,因为硬件OEM 厂商之前并不认为有必要在这方面进行任何投入。也正是因为这个原因,Dekko 基于iPad 2 的系统所需的聚合时间十分长。首款Tango Peanut 手机是第一个能将一切组件的时钟准确同步的设备,同时也是能提供优秀追踪能力的首款面向消费者的手机。目前,来自高通以及其他厂商的片上系统已经可以为所有组件提供可同步的传感器中枢,这也意味着VIO 在大部分新设备上已经变得可行,可以更好地对传感器进行校准。

由于软硬件之间极高的依赖性,以前,软件开发者如果无法获得OEM 厂商的大力支持构建所需的硬件,几乎无法开发出足够好的系统。Google 通过大量投入使得一些OEM 厂商开始支持Tango 的硬件规范。微软、Magic Leap 等厂商则在开发自有硬件。而Apple 的ARKit 如此成功,主要在于Apple 可以同时搞定软件和硬件问题。

光学校准

(点击放大图像)

为了让软件精确地将摄像头传感器像素与现实世界中的一点关联在一起,摄像头系统必须进行精确的校准。校准主要可分为两种类型:

几何校准(Geometric Calibration):使用相机的小孔成像(Pinhole model)模式矫正镜头视野以及镜头圆筒效应(Barrel effect)等参数。由于镜头形状的影响,基本上所有图像都会存在一定的扭曲变形。大部分软件开发者无需求助OEM 厂商,即可通过失真测试卡(Checkerboard)以及公开的摄像头参数进行这种校准。

光学校准(Photometric Calibration):这种校准麻烦得多,由于会涉及图像传感器本身的规范以及镜头内部使用的涂层,通常离不开OEM 厂商的参与。这种校准主要是为了解决颜色和亮度的映射问题。例如安装在望远镜上用于拍摄星空的照相机,必须能知道传感器上一个像素捕获的光照亮度轻微的变化是否代表一颗星,还是只是传感器或镜头本身造成的像差(Aberation)。对于AR 追踪系统来说,这种校准的结果可以让传感器像素与现实世界中的点更精确地映射在一起,塑造更健壮,误差更低的光学追踪系统。

上图中,组成图片的多个RGB 光子进入图片传感器的一个“像素桶”,这个过程就很好地展示了这个问题。来自现实世界中一点的光线通常会落在多个像素的边界上,每个像素会对命中的所有光子取平均值。用户的轻微移动或场景中的阴影,甚至荧光灯的闪烁,都会造成与像素最匹配的现实世界点产生变化。所有光学校准机制的目的都是尽可能消除这种误差。

惯性校准

(点击放大图像)

对于IMU,重点在于它所测量的是加速度,而非距离或速率。IMU 读数的误差会逐渐累积,累积速度极快!校准和建模的目的在于确保每秒钟的X 等分时间段内,对于距离的测量(对加速度进行二重积分)是足够精确的。理想情况下,这段时间已经足够长,可以抵消由于镜头被遮挡或场景中其他情况导致追踪过程漏掉几帧画面所造成的影响。

使用IMU 测量距离的方法也叫航位推算。基本上这就是一种猜测,但只要对IMU 行为建模,确定误差的所有累积方式,随后编写可以缓解这些误差的筛选器,即可获得准确的猜测结果。假设你要迈出一步并猜测这一步的长度,只迈一步并猜一次的误差肯定会很高。但如果重复迈出上千步,每一步都进行测量,同时确定迈出的到底是左脚还是右脚、地板材质、穿的鞋子、移动的速度、疲倦程度等因素,那么最终的猜测结果将变得非常准确。IMU 校准和建模实际上就是做这种事情的。

误差的来源有很多。厂商通常会使用机器臂以相同方式反复移动设备,持续捕获并筛选IMU 输出结果,直到IMU 的输出能与机器臂移动过程的地表实况精确匹配。为了进一步消除误差,Google 和微软甚至在国际空间站以及“零重力飞机”的微重力环境下进行过设备校准。

(点击放大图像)

追踪结果需要处理的误差种类各异,此处列举了几个例子,显示为图中的RGB 线

为了提高准确度,实际需要采取的措施远比听起来困难。对于OEM 厂商而言,更麻烦的地方在于需要对自己生产的所有设备进行这种操作,而很多设备甚至使用了不同IMU(例如Galaxy 7 的IMU 可能来自Invensense 或Bosch,Bosch 的模型肯定不能用于Invensense)。相比Android OEM 厂商,这也是Apple 的另一个优势所在。

追踪技术的未来

(点击放大图像)

那么对于目前已经可行的VIO,未来将如何发展,是否会让ARKit 显得多余?也许会让很多人感到吃惊,但VIO 依然是在长达数百米范围内进行追踪的最佳方式(对于更长的距离,系统需要配合使用内置GPS 和某种类型的地标识别技术进行重新本地化[relocalize])。这是因为哪怕其他纯光学的系统可以获得与VIO 一致的精确度,但这种系统需要更多(CPU 或摄像头)处理能力,对于头盔显示器(HMD)等设备来说这会造成一些问题。单镜头VIO 是目前精确度最高,能耗最低,成本最低的解决方案。

深度学习技术在追踪系统的研究者社区中产生了巨大影响力。目前,基于深度学习的系统误差约为10% 左右,顶尖的VIO 系统可实现个位数的误差率,但前者正在快速完善,进而改善室外的重新本地化过程。

深度摄像头可以在多个方面进一步完善VIO 系统,例如可以精确测量地表实况和测量尺度,改善细节不足场景中的边缘追踪能力。但这种方式的耗电量非常大,因此通常只能以较低帧率运行,并在不同帧之间使用VIO。同时这种方式也不适合室外使用,因为阳光造成的背景红外散射会干扰深度摄像头的红外线。这种方式的工作范围也取决于能耗,这也就意味着对于手机这样的设备,工作范围将极为狭窄(通常仅几米)。同时这种技术的物料成本很高,OEM 厂商可能不会愿意在畅销机型中使用。

双镜头RGB(Stereo RGB)或鱼眼镜头可以帮助系统看到更大范围的场景(因此有可捕获更多光学特征,例如普通镜头只能看到白色墙壁,但鱼眼镜头也许可以同时看到包含一定图案模式的天花板或地毯,?Tango 和Hololens 就使用了这种方法),并且可能用低于VIO 的计算成本获得深度信息,不过VIO 可以用更低物料和能耗成本足够精确地做到这一切。由于手机(甚至头盔显示器)的双镜头摄像头两个镜头距离非常近,因此可以准确计算的深度范围较为有限(距离数厘米的两个摄像头即可精确计算数米范围内的深度)。

接下来还有一个事情比较有趣:如何对更大范围的区域进行追踪,尤其是室外数公里范围内的追踪。目前AR 和无人驾驶汽车在追踪这方面几乎没有任何区别,只不过AR 系统所用传感器和计算能力都较少。由于最终来说,几乎任何设备都需要在室外更大范围内使用,因此还需要云服务的支撑,Google 最近公布的Tango Visual Positioning Service 就是用来做这些事情的。未来几个月里相关的进展还会更多,而这也是几乎每个人都那么关注3D 地图的原因所在。

AR 计算机视觉技术的未来

(点击放大图像)

6dof 位置追踪将在未来 12-18 个月里彻底实现商品化和跨设备使用。但依然有些问题有待解决,例如:

3D 重建(Hololens 将其称之为 Spatial Mapping[空间映射],Tango 将其称之为 Depth Perception[深度感知])。这类系统可以区分场景中现实物体的外形或结构。通过这种技术,虚拟内容可以融入或隐藏(结合)于现实世界中。其实正是这种特性让一些人产生了混淆,认为 AR 就是“混合”现实(Magic Leap,谢你全家!)。AR 只是 AR,只不过人们看到的大部分 AR 演示并不支持 3D 重建,因此感觉上虚拟内容只是在现实世界中所有物体前“跑来跑去”。3D 重建技术可以从场景中捕获密集点云(目前主要使用深度摄像头来进行),随后将其转换为网格,并将“不可见”的网格放入 Unity(并与现实世界的坐标系相匹配),随后将现实世界网格叠加在摄像头拍摄的现实场景上。这意味着虚拟内容将可以与现实世界交互。这里需要注意,目前 ARKit 会通过检测 2D 平面实现 2D 版本的重建,这是进行重建的最低要求。如果缺少地平面,Unity 内容将没有“立足之地”,只能漂浮在空间中。

(点击放大图像)

Magic Leap 的演示展示了将机器人隐藏在桌腿后面的场景。但不确定桌腿是否是实时重建并放入 Unity 中的,还是仅仅只是针对这个演示预先建模,并以手工方式将虚拟桌腿放置在真实桌腿前面。

上文提到的有关深度摄像头的所有问题在这里依然存在,因此深度摄像头的使用率至今依然不太高。目前业内正在积极研究如何使用一个 RGB 摄像头实时进行足够逼真的 3D 重建,不过距离最终实用可能还要等大概 12–18 个月。也正是因此,我觉得“真正”的消费级 AR HDM 离我们还有这么远的距离。

(点击放大图像)

我在2012 年成立的初创公司Dekko 通过iPad 2 提供了3D 重建系统,但当时必须显示出网格,否则用户根本不敢相信自己看到的内容(这个系统可以全面理解真实世界)。在这个场景中,玩具小车在上下跳动,但部分区域隐藏在纸巾盒后面。

3D 重建之后,业界对 3D 场景的语义化理解进行了大量有趣研究。目前你能看到的几乎所有炫酷的计算机视觉深度学习技术都使用了 2D 图像(普通照片),但对 AR(以及汽车、无人机等设备),我们需要以 3D 的方式对世界获得语义化理解。正如 ImageNet 曾为 2D 语义提供了莫大的帮助,目前也有很多新方案,如 ScanNet 可提供一定的帮助。

(点击放大图像)

场景3D 语义分割范例。最底部为原图,中间为3D 模型(可能通过双镜摄像头或LIDAR 构建),最上面是通过深度学习进行的分割,借此我们可以看到机动车道和人行道之间的界限。Pokemon Go 也用了类似技术确保宠物小精灵们不会出现在车辆飞驰的道路中央……

随后我们还需要了解如何在更大范围内运用这些令人惊艳的技术,以便实时为更多用户提供并发支持。这才是终极的多人线上角色扮演游戏。

(点击放大图像)

随着3D 重建的范围越来越大,我们需要确定如何将其托管在云中,让多个用户共享(并完善)同一个模型。

AR 领域其他方面的未来发展

其他方面的进展已经超出了本文范围(也许以后可以单独撰文?),但整个技术栈还有很多方面有待进一步完善:

  • 光学:视野、适眼区(Eye box)大小、分辨率、亮度、景深、视觉辐辏调节(Vergence accommodation),都有问题有待解决。我觉得我们会看到很多只能提供有限功能的“不完整”HMD 设计,这类设计主要是为了“解决”特定的某个问题(例如社交信号或追踪,或企业应用,或其他什么需求),在这之后才会迎来终极的消费级解决方案。
  • 渲染:让虚拟内容与现实世界共存。确定真实世界中的光源并与其进行匹配,让阴影和材质看起来更逼真。多年来 Hollywood SFX 一直在做这些事(这样才能让复仇者联盟的成员看起来更逼真),但对 AR 来说,要在不能控制现实世界中光照和背景的前提下,在手机上实时做到这一切!这绝对会是一项意义深远的成果。
  • 输入:这方面的路还很长。研究发现多模式输入系统目前可以提供最佳结果,同时也有谣言称,Apple 即将发布这项技术。多模式其实就是指将多种输入“模式”(手势、语音、计算机视觉、触摸、眼动追踪等)同时集合在一起由人工智能技术来处理,借此更好地理解用户意图。
  • GUI 和应用:对 AR 来说,其实并不存在“应用”这样的概念,我们想要做到的实际是:看一眼 Sonos 音箱,控制界面就跃然而出显示在设备上方了。没人愿意专门选择一个方块状的 Sonos 按钮然后来操作对吧!我们希望自己需要的控制功能可以始终显示在视野中(类似飞行员的抬头显示器),或者要能与现实世界中的物体紧密联系在一起。虽然最理想的设计方式到底是什么,这个目前还没有定论,但绝对不会是 4x6 网格排列的图标。
  • 还需要解决社交方面的问题。在我看来,只有 Apple 和 Snap 懂得如何销售时尚,而时尚无疑会成为 AR HMD 最主要的购买推动力。尽管在技术上存在各种难题,但这个问题恐怕更难解决。

感谢你阅读本文!如果对本文有任何问题或意见,或希望以后看到其他题材的内容,欢迎随时联系。


感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2017-08-23 17:492935
用户头像

发布了 283 篇内容, 共 107.7 次阅读, 收获喜欢 62 次。

关注

评论

发布
暂无评论
发现更多内容

Android面试:一个进程有多少个-Context-对象?看似初级的问题,答的好的人确不多

android 程序员 移动开发

Android题集四大组件之Service

android 程序员 移动开发

Android高频网络面试专题必知必会

android 程序员 移动开发

Android:AsyncTask使用

android 程序员 移动开发

Android:帧动画和补间动画看这篇就足够了!

android 程序员 移动开发

App基于手机壳颜色换肤?先尝试一下用 KMeans 来提取图像中的主色

android 程序员 移动开发

Android面试官:“来给我讲讲View绘制?

android 程序员 移动开发

Android面试:IntentService源码分析

android 程序员 移动开发

ARouter系列3:继续学习(手写一个Arouter框架)

android 程序员 移动开发

Bmob后端云+ImageLoader框架实现图文列表

android 程序员 移动开发

Android面试题(window、进程、线程篇

android 程序员 移动开发

APP 热修复都懂了,你会 SDK 热修复吗?最全方案在这里!

android 程序员 移动开发

App 金刚区导航菜单,类似淘宝、QQ 音乐等 APP 导航,方格布局横向滑动翻页带滚动条

android 程序员 移动开发

Android高级架构师整理面试经历发现?(大厂面经+学习笔记

android 程序员 移动开发

Android高级面试题:面试十几家公司入职外企后,掌握这几个关键点面试通过率很大

android 程序员 移动开发

ClassLoader在热修复中的应用

android 程序员 移动开发

Android面试大全基础篇(校招+社招)含答案

android 程序员 移动开发

Android面试必备!爆火超全的《Android性能优化全方面解析》

android 程序员 移动开发

Android:彻底消灭OOM的实战经验分享(千分之1-5----万分之0-2)

android 程序员 移动开发

Angular-集成-Typescript-版本-Echarts-(附代码)

android 程序员 移动开发

App怎么做才能永不崩溃

android 程序员 移动开发

BAT资深面试官-带你破解Android高级面试

android 程序员 移动开发

Android面试必问:Handler、Bitmap、线程

android 程序员 移动开发

Android面试老生常谈的 View 事件分发机制,看这一篇就够了!

android 程序员 移动开发

AOP 最后一块拼图 _ AST 抽象语法树 —— 最轻量级的AOP方法

android 程序员 移动开发

Android面试官必问的事件分发,你答得上来吗?

android 程序员 移动开发

Android面试题之性能优化篇

android 程序员 移动开发

APP终极瘦身方案

android 程序员 移动开发

AsyncTask相关知识

android 程序员 移动开发

Android面经分享:快手、字节跳动、百度

android 程序员 移动开发

Android面试主题整理合集(三)

android 程序员 移动开发

ARKit何以从同类技术中胜出?_Apple_Matt Miesnieks_InfoQ精选文章