詳解iOS之ARkit爲什麼碾壓對手（二）

在這篇文章中，咱們能瞭解到

1,ARKit、Tango、Hololens技術對比

2,開發人員如何使用ARKit

明天小編會更新第三篇

1，AR以及其餘技術的將來,

2，追蹤技術的將來

,這是小編的一個iOS交流羣 659170228，歡迎你們的入駐，一塊兒交流學習！

Tango 、 HoloLens、 Vuforia 等 SDK 怎麼樣?

Tango 只是一個品牌名，而不是真正的產品。Tango 包括硬件參考設計（RGB，魚眼鏡頭，深度相機和CPU / GPU規格），還參與 VIO（運動跟蹤），稀疏映射（區域學習）和密集 3D 重建（深度感知）等軟件。

HoloLens 具備徹底相同的軟件棧，另外包括一些 ASIC（微軟稱之爲全息處理單元）優化 CPU / GPU 卸載處理並減少電耗。

Vuforia 與 ARKit 幾乎是同樣的，只是 Vuforia 的硬件是獨立的。

上述 SDK 均使用相同的 VIO 系統，並且，Tango 和 ARKit 使用的均爲 FlyBy 最初發布的代碼庫！HoloLens 和 Tango 都不使用深度相機進行追蹤，那麼究竟是什麼技術設備讓 ARKit 大放異彩呢？

答案是 ARKit 並不比 HoloLens 好，我甚至認爲 HoloLens 的跟蹤系統是市場上最好的，但 HoLolens 的硬件普及並不廣。微軟可能會在 Windows 系統的智能手機中安裝 HoloLens 跟蹤系統，但我相信出於商業緣由，微軟不會這樣作：

由於這樣可能會增長生產和時間成本，爲一款銷量或許不多的手機校準傳感器。並且，微軟版本的 ARKit 也可能沒法說服開發者放棄使用 iOS 或 Android 系統。12 個月前，Google 本就能夠輕鬆交付可以在 Android 系統上運行的 Tango 手機，但 Google 沒有這樣作。若是 Google 早早將 Tango 發貨 ，那麼 ARKit 的問世也只是緊跟趨勢，而非重大突破。

我認爲，Google 公司不想爲每家 OEM 都進行特定的傳感器校準過程，並且每家 OEM 廠商生產的 Tango 版本都不同，Google 也不想在一些較大的 OEM 廠商（三星、華爲等）中選擇。因此，Google 爲 OEM 廠商提供了硬件的參考設計，OEM 廠商能夠自行選擇「使用，或者不使用」。（固然，事情並不是這麼簡單，這是 OEM 廠商反饋給個人關鍵點。）

隨着 Android 智能手機硬件商品化，相機和傳感器堆棧是 Android 手機最後實現差別化的地方，因此 OEM 廠商沒法知足 Google 的要求。Google 認爲，深度相機是手機的一部分，可是深度相機增長了手機成本，這也是 OEM 廠商拒絕 Google 的另外一個緣由！

自從 ARKit 發佈以來，市場已經發生了變化。OEM 廠商要麼尋找 Tango 的替代系統，要麼接受 Google 的硬件參考設計，而後實現平臺控制。這也是有意思的變化。

總的來講，ARKit 更好的緣由在於：

蘋果公司能夠負擔得起將 VIO 算法緊密耦合到傳感器上，並花費不少時間來校準 VIO 系統，以減小計算空間位置時產生的偏差。值得注意的是，大型 OEM 廠商有一些替代方案。能夠選擇其餘的追蹤方案，像 ORB Slam、OpenCV 等，但幾乎都是光學追蹤器，都配有單個 RGB、立體聲、深度相機，有些使用稀疏點雲，有些使用密集點雲。有許多創業公司正在研發追蹤系統，研究加強像素也是一個很好的方向，但任何 VIO 系統最終的競爭都會集中到硬件模型和校準上。

接下來咱們來談談，ARkit中的幾個重要技術以及幾個注意事項

這其中的學習難度較大，比從網絡到移動或從移動到 VR 更有難度。你須要完全從新思考應用程序的如何運行以及用戶體驗（UX）的意義是什麼。我如今看到不少 ARKit 的 demo，四年前看到它們是基於 Vuforia 建立，再往前四年就是 Layar （2010 年荷蘭公司 SPRXmobile 推出的全球第一款 AR 手機瀏覽器）。這幾年來，我 看過了幾乎全部類型的 AR APPs 的例子，我很樂意爲你們提供支持和反饋。

我經常鼓勵開發人員敢於構建新奇的 APP。一些蠢蠢的 APP 一上線便大獲成功，但經過 AR 硬件開發讓用戶是滿意的案例也十分具備挑戰。

固然，受限於iOS設備的硬件，當前的ARkit還不能作到完美。無論怎麼樣，當前的iOS設備還只能實現單母SLM。所以在實際的開發和使用中要注意一下事項：

1，在設計AR產品體驗時，必定要保證現場的光照條件

ARkit的Worldtracking涉及到圖像分析，其前提是攝像頭能夠捕捉到清晰的圖像。所以，若是現場的光照條件很差而致使攝像頭沒法捕捉到圖像的細節，那麼最終的用戶體驗確定是糟糕的。

2，使用跟蹤質量信息向用戶提供反饋

ARkit世界跟蹤功能的另外一大前提是實時監測設備的運動信息。過量或過於劇烈的運動將致使圖像模糊，從而沒法追蹤不一樣視頻幀的特徵點，致使跟蹤質量降低。ARCamera能夠提供跟蹤狀態信息，所以建議開發者設計相應的UI，向用戶反饋此類信息，避免過量或過於劇烈的運動。

3，容許ARkit得到足夠的時間來檢測平面，而在檢測完成後最好禁用平面檢測功能

在實際體檢的時候，平面檢測可能會耗費比較長的時間。並且當某個平面首次被檢測時，其位置和範圍信息每每是不許確的。隨着平面在場景中出現的時間足夠長，ARkit將會優化相關的位置和範圍信息。可是一旦咱們獲取到了使人滿意的信息，就應該關閉平面檢測功能，不然ARkit將持續變動平面描點的位置，範圍和座標信息。

世界追蹤系統是如何工做的？

蘋果文檔中對世界追蹤過程是這麼解釋的：ARKit 使用視覺慣性測距技術，對攝像頭採集到的圖像序列進行計算機視覺分析，而且與設備的運動傳感器信息相結合。ARKit 會識別出每一幀圖像中的特徵點，而且根據特徵點在連續的圖像幀之間的位置變化，而後與運動傳感器提供的信息進行比較，最終獲得高精度的設備位置和偏轉信息。

咱們經過一個 gif 圖來理解上面這段話：

追蹤質量：

世界追蹤須要必定的條件才能達到較好的效果，若是達不到所需的條件要求，那麼世界追蹤的質量會下降，甚至會沒法追蹤。較好的世界追蹤質量主要有如下三個依賴條件：

運動傳感器不能中止工做。若是運動傳感器中止了工做，那麼就沒法拿到設備的運動信息。根據咱們以前提到的世界追蹤的工做原理，毫無疑問，追蹤質量會降低甚至沒法工做。

真實世界的場景須要有必定特徵點可追蹤。世界追蹤須要不斷分析和追蹤捕捉到的圖像序列中特徵點，若是圖像是一面白牆，那麼特徵點很是少，那麼追蹤質量就會降低。

設備移動速度不能過快。若是設備移動太快，那麼 ARKit 沒法分析出不一樣圖像幀之中的特徵點的對應關係，也會致使追蹤質量降低。

追蹤狀態

世界追蹤有三種狀態，咱們能夠經過 camera.trackingState 獲取當前的追蹤狀態。

Not Available：世界追蹤正在初始化，還未開始工做。

Normal： 正常工做狀態。

Limited：限制狀態，當追蹤質量受到影響時，追蹤狀態可能會變爲 Limited 狀態。

與 TrackingState 關聯的一個信息是 ARCamera.TrackingState.Reason，這是一個枚舉類型：

case excessiveMotion：設備移動過快，沒法正常追蹤。

case initializing：正在初始化。

case insufficientFeatures：特徵過少，沒法正常追蹤。

case none：正常工做。

咱們能夠經過 ARSessionObserver 協議去獲取追蹤狀態的變化，比較簡單，能夠直接查看接口文檔，這裏不作深刻介紹。到這裏，ARKit 中有關於世界追蹤的知識基本介紹完了，世界追蹤算是 ARKit 中核心功能了

歸根究竟是統計學問題

AR 系統沒有「可行」或者「不可行」一說。 大部分狀況下，AR 系統能夠很好的完成工做。AR 系統力求變得「更好」，也是推進統計學發展的事情。

故而，不要徹底相信 AR APP 的演示，特別是發佈於 YouTube 上，顯示出驚人的效果的 AR APP。在精心安排的環境中所表現的效果與現實生活中普通用戶所能得到的效果之間，每每存在很大差距。可是智能手機或 VR 應用的演示一般並不存在這種問題。因此，觀衆經常被愚弄。

在上面的圖像中，有一個網格，表示相機中的數字圖像傳感器。每一個格子都是一個像素點。爲了穩定追蹤，在假設設備徹底靜止的狀況下，每一個像素應該在現實世界中的有一個相匹配的對應點。然而，右側圖像顯示光子不是那麼的聽話，各類光子會隨意落到任何地方，每一個像素點是光子的總數。場景中的光線變化（太陽光穿透雲層，熒光燈閃爍等）也會改變傳感器中的光子組成，如今傳感器要對應現實世界的不一樣像素點。那麼，這樣的狀況下視覺追蹤系統就認爲用戶移動了！

因此，各類 ARKit demo 中光點閃爍時，系統必須肯定哪些點是「可靠」的。系統對這些點進行三角測量來計算用戶的空間位置，求平均數後獲得對實際位置的最佳估計數。所以，爲確保錯誤的統計徹底被移除，便須要研發更精確的系統。這就須要相機硬件堆棧（多個鏡片和塗層、快門和圖像傳感器等）、IMU 硬件和軟件算法之間的嚴密集成和校準。

下面是兩個校準方法

光學校準

上圖中，一個虛擬物體茶杯被放在了現實世界的桌子上。

當週圍環境光線較好時，攝像機捕捉到的圖像光照強度也較好，此時，咱們放在桌子上的茶杯看起來就比較貼近於現實效果，如上圖最左邊的圖。可是當週圍光線較暗時，攝像機捕捉到的圖像也較暗，如上圖中間的圖，此時茶杯的亮度就顯得跟現實世界格格不入。

針對這種狀況，ARKit 提供了光學校準，開啓光學校準後，咱們能夠拿到當前圖像的光照強度，從而可以以更天然的光照強度去渲染虛擬物體，如上圖最右邊的圖。

光學校準基於當前捕捉到的圖像的曝光等信息，給出一個估計的光照強度值(單位爲 lumen，光強單位)。默認的光照強度爲 1000lumen，當現實世界較亮時，咱們能夠拿到一個高於 1000lumen 的值，相反，當現實世界光照較暗時，咱們會拿到一個低於 1000lumen 的值。

ARKit 的光學校準默認是開啓的，固然也能夠經過下述方式手動配置：

configuration.isLightEstimationEnabled = true

獲取光學校準的光照強度也很簡單，只須要拿到當前的 ARFrame，經過如下代碼便可獲取估計的光照強度：

let intensity = frame.lightEstimate?.ambientIntensity

慣性校準

對於 IMU 來講，測量加速度比測量距離或速率更加劇要。IMU 的讀取錯誤隨着時間的推移不斷累積，產生偏差的速度很是快！校準和建模的目標是確保距離的測量在每秒鐘 X 等分時間下的精度足夠高。理想狀況下，這個時間段要足夠長，以減小當鏡頭被遮蓋或場景中發生其餘狀況時，致使攝像機丟失對幾幀畫面的追蹤。

使用 IMU 測量距離稱爲航位推算。這基本算是一個猜想，對 IMU 收集的數據進行建模，肯定積累錯誤的方式，而後編寫過濾器來減少偏差。想象一下，若是你被要求邁出一步，而後猜想邁出的步子有多大。只猜想邁出一步的距離會產生很高的偏差。可是，若是你反覆邁出千步並猜想每一步的距離，所產生的偏差便會很是小。由於你對於踏出哪隻腳、地板的種類、鞋子的款式、移動速度的快慢、身體狀態的好壞等等熟知，那麼你最終的猜想便會很是準確。基本的 IMU 校準和建模即是這一原理。

數據有不少偏差來源。機器臂一般以徹底相同的方式重複地移動設備，捕獲 IMU 的輸出並寫入濾波器，直到來自 IMU 的輸出與來自機器臂的移動精確匹配。爲進一步減少額外的偏差，Google、微軟甚至在國際空間站（ISS）及「零重力飛機」在微型重力環境下進行校準。

實際上，達到真正的精準度，比嘴上說說難的多。OEM 廠商必須對全部設備進行校準，即便許多設備有不一樣的 IMU（例如，Galaxy 7 可能有來自 Invensense 和 Bosch 的 IMU，固然 Bosch 不適用於 Invensense）。固然，這是蘋果相對於 Android OEM 廠商的另外一個優點所在。