Re: [閒聊] 關於光學式定位的距離問題

[zebb ()]

交流一下個人想法，有錯還請指正

※ 引述《h1981127 (NEST)》之銘言：
: Oculus 和Sony 都是採用影像辨識定位
: 這種定位的好處是頭盔上只要裝led就好
: 可以減輕頭盔的重量與設計上的麻煩

兩種定位技術應該和頭盔整體重量沒有什麼關係，LED很輕，但vive的photodiode
sensor也沒有重到哪去，更何況Oculus用的LED比Vive sensor還要多，連後腦都要
拉線過去擺LED，我想光比較定位系統重量應該相差無幾。
(vive 32 sensor，oculus 44 LEDs)
整體頭盔重量關鍵應該不在定位系統，比較像是在電子機構的功力，要輕、要堅固、
要舒適、要美觀，還要低成本
實際上，以重量而言Oculus(440g) < Vive(555g) < PSVR(610g)
而Oculus和PSVR都是使用光學定位，所以定位技術應該和重量沒什麼關係

: 壞處很明顯，原地遊玩就算了
: 定位距離與定位精度在room scale模式下都顯得不足
: 依照我的理解，定位距離應該是跟sensor靈敏度有關
: 定位精度則是跟sensor解析度（總畫素）以及快門時間有關
: 若是要改善以上的問題，是否只要升級現有的相機sensor就好
: 還是說有其他我沒想到的地方
: 不知道板上有沒有熟悉這一塊領域的大大可以幫忙解惑

不知你指的「sensor靈敏度」是否可以看為「感光度」
如果是感光度，它拉越高雜訊就多，對後面處理的負擔就越大，所以無法一直拉高
而相同感光度下，LED的亮度太低時，距離太遠就收不到，但亮度太高，近距離
又可能出現耀光鬼影等問題，加上LED需要閃爍，由暗到亮時亮度太高可能出現
其他問題，所以這一切都需要取得一個相互間的平衡設置

至於距離問題，我覺得除了太遠時LED亮度不夠以外，或許也和解析度有關

先看看Oculus的定位方式，是利用高速IMU（1000Hz）加上光學定位
為什麼不只用IMU定位呢？
因為會累積誤差，用在短時間的高速位移/角度偵測還不錯（因一秒取樣1000次
回報500次），但長期的雜訊誤差累積下來，將無法判斷物體位於空間中的位置
https://goo.gl/cQb8lO
而為什麼不只用光學定位呢？
最明顯是因為無法判斷高速移動，或許是因為每個LED需要10個frame才能重新定位
https://goo.gl/nvjMLc

所以，或許可以推測，O家利用IMU+光學用來判斷頭盔角度/面向，然後用IMU判斷
短時間高速移動下頭盔的位置，用光學修正長期頭盔位於整個空間中的位置

而O家用戶回報的通常是距離單攝影機3.5公尺後明顯追蹤不穩定，2.5公尺內很穩
https://goo.gl/bF6Hsb
我猜這「不穩定」應該就是屬於「光學定位端失效」導致的不穩定，因為IMU持續
運作中，可以想見是整個頭盔位置跳動，而不是角度跳動
（我沒有玩過Oculus，有錯請指正）

而為何光學會定位失效？
我們看看這個影片：
https://goo.gl/gA95I5

可以發現：
1. 每個定位點因為需要閃爍來編號，而閃爍時攝影機看到的光點忽大忽小，形狀
   也不斷改變，導致定位出來的位置也不斷抖動（注意看頭盔放桌上不動時，
   每個LED編號的文字）
2. 位於邊緣的定位點非常不穩定，編號還會亂跳
3. 定位點光源不夠大/不夠圓似乎都不會被編號

然後再看看此影片：
https://goo.gl/ZUeFHT
注意上面中央的15號LED，可以看到他因為在邊緣，時有時無的定位，也導致了
整個頭盔3D module不斷跟著15號LED偏移

由以上資訊推測出，光學定位精確度就是無法很高（其實影像處理定位因雜訊/解析
度等問題原本就無法很精準，這邊說的是Oculus並沒有比較神奇的解決那些問題）

而解析度方面，Oculus camera FOV是100x70度
https://goo.gl/fCvLKO
而Oculus camera解析度最高是1080P
以橫向100度、1920解析度來換算，
距離2.5公尺遠時，兩個pixel間對應實際距離是2.27mm
距離3.5公尺遠時，兩個pixel間對應實際距離是3.18mm

也就是說如果光學定位有1 pixel的抖動，實際上在2.5公尺時，頭盔是2.27mm的抖動

但如果用更高解析度的camera，假設是4k的，橫向3840點，
那麼一樣是1 pixel的抖動情形下，頭盔要拉到5公尺才會有2.27mm的抖動
所以解析度增加會改善可定位距離，改成4K理論上就是到5公尺還能接受

但增加解析度同時也會增加資料傳輸量/定位系統運算量，還是得取捨
目前Oculus要room-scale已經需要至少3個USB3.0傳資料了，
增加解析度這條路將來應該不太會被選擇

------------------------------------------------------------

總之，我總覺得O牌現在有點像是開理髮店已經把客人頭洗下去了也發明並生產了
傳統剃刀，原本小鎮只有他一家理髮店，大家都喜歡。
但不知何時旁邊又突然開了間V牌理髮店，用的是又快又好又乾淨的電動剃刀，
O看新客人都跑過去了，想想不對，要開始追趕才發現傳統剃刀需要高超技巧才能
剃的又快又好又乾淨，而電動剃刀又是V發明的，只好硬著頭皮逼師父練技巧這樣...

一開始Oculus似乎就是針對「電腦桌前坐姿」（不常轉頭，不會快速移動頭盔）
與「近距離」來開發Oculus，定位系統在這種情形下是非常完美的，設定容易、夠準確
且連控制器都沒有設計，只是直接使用xbox360手把，似乎就是定位為VR 3D螢幕
結果...Vive突然帶著各方面都比較優秀的定位系統亂入這個獨佔市場，還直接支援
room-scale與兩個可高速精準定位搖桿。所以O家無法再擠牙膏，只能快點追趕，
但一開始選擇的定位方式要更改用途難度高，又無法直接捨棄，只能一直不斷的往
這坑越挖越深，然後發現因為每個LED都要閃爍才能識別編號，需要10frame才能識別，
這樣的設計本質上就是不適合用在常需要高速移動的控制器上，只好一直想辦法彌補

參考這篇：
https://goo.gl/KLClPt


以上個人觀點，有錯請指正




--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.132.208.60
※ 文章網址: https://www.ptt.cc/bbs/VR/M.1485419683.A.CD0.html
推 kira925: 推
推 GenialPP: 推
推 SiaSi: 專業
推 h1981127: 推!專業分析!不過需要3個USB的原因是他使用了三隻相機
→ kira925: 因為Oculus的設計兩隻攝影機還不夠Room Scale...
推 Kamikiri: 這樣買下來  應該已經比VIVE還貴了吧？  一個鏡頭89鎂
推 kira925: 三顆鏡頭 一組手把 本體...
好像是這樣沒錯，amazon上現在Oculus+touch價格剛好和vive差不多
再加上個第三攝影機...看來是比較貴

推 ashinet: 寫得很好
謝謝各位支持，但我的想法不一定對，大家一起交流

→ hsinggg: 我非常不願意這樣說...轉頭買V吧...
這樣好像又要被說是vive板了 XD
我個人是覺得，如果現在要新入手，沒理由選Oculus(除了真愛...)
如果已經投資了Oculus，不玩room-scale，也不用管這些問題
如果已經投資了Oculus又想玩room-scale，其實也不用特地換陣營
因為網路上也是不少人說他們Oculus的room-scale非常好
雖然我沒有交叉比較過，不排除是沒比較過vive不知道vive的準確性如何
但我想至少會是還ok的情形吧
只是看起來Oculus設定反而會比vive麻煩就是了，參考這篇新文章:
Oculus room-scale VR tracking is still a bit of a mess
https://goo.gl/adZWQe
Oculus camera FOV比較小，比vive的燈塔還需要用心擺設
且需要的CPU資源一定比vive多，因為定位系統需要即時做高計算量的影像處理運算
而尷尬的是此時因為GPU要讓給遊戲使用，所以應該無法使用CUDA等技術來丟給顯卡
做平行運算，結果都在吃CPU資源 （或許因此才限定最低CPU？）
所以同樣效果下需要的硬體反而比vive還高

其實每次看有人說VR板是vive板就覺得...
阿明明就是其他家不爭氣，所以才大部分都討論vive推薦vive阿...

推 Tunie: 是啊
→ ashinet: O家不爭氣, PSVR雖然用的很幹,但最近有沙灘排球讓我開心
→ kuma660224: 鏡頭好處是未來容易降價。cam成本隨製程降
推 kira925: 基礎演算法就有落差了 降價沒意義阿....
推 h1981127: 如果能把影像演算法寫成硬體，用晶片去運算，就不用耗
→ h1981127: 到CPU的資源了，這樣一來就算換成4K影像也不要緊，再來
→ h1981127: 就是晶片放在燈塔上，燈塔只要回傳運算完之後的座標資
→ h1981127: 料，這樣也就解決了頻寬不足的問題，最後也最重要的就只
→ h1981127: 剩下晶片的成本會多貴了
確實這似乎不失為一個選項，但當對手燈塔成本越來越低時(有在研發一個馬達版本)
我是覺得不太可能這樣進行，尤其現在的價格就已經是一般人不會接受的高了，
要做這樣的SoC，成本應該不低喔

推 kira925: 這樣損失了燈塔系統有可能做ad-hoc多燈塔擴充的可能性
推 h1981127: 不衝突啊，燈塔回傳的只是燈塔和頭盔的相對座標，多燈
→ h1981127: 塔運算再由cpu去反推燈塔之間的相對位置，最後由軟體去
→ h1981127: 重新制定一個座標軸
推 kira925: 沒有燈塔的絕對座標的話 會做不出來...
推 h1981127: 由燈塔A推得頭盔的相對位置a，由燈塔B推得頭盔的相對位
→ h1981127: 置b，已知a=b，反推A和B的位置，有什麼難的嗎？
推 kira925: 那你需要的就不只兩個燈塔了 是三個阿...
推 h1981127: 完全不懂樓上的問題點在哪？  可以詳述一下嗎？
推 kira925: 我被GPS定位法搞混了 我再想想  主要是單純a=b這件事情
→ kira925: 你只能得到一個平面上等距 所以得不到A/B的位置
→ kira925: SteamVR在確定遊玩範圍的時候應該就是要從主機上做定位
→ kira925: A/B燈塔出來的距離多遠到多遠是最大範圍邊界 如果你
→ kira925: 把這些計算扔進燈塔 那就是要有傳輸路徑持續即時連線
→ kira925: 到CPU更新讓CPU去合成 那我覺得沒有頭盔上面收訊計算漂亮
一開始O家一個攝影機就可以定位三軸
我想或許是利用各個定位點之間的距離來推估深度資訊
(PS Move則是利用光球的大小來推估深度)

所以沒有類似GPS定位需要三個的問題

推 h1981127: 我們講的可能是不同的系統，我是討論Oculus的系統，目前
→ h1981127: O家的系統問題是要先把影像傳回電腦，靠CPU去運算燈塔和
→ h1981127: 頭盔的相對位置，由於O家是使用USB傳輸，所以會消耗大量
→ h1981127: 的頻寬在影像傳輸上，這也是影像解析度無法提升的一個因
→ h1981127: 素，我一開始說的重點就是讓影像處理這一塊改用硬體運
→ h1981127: 算，降低CPU以及頻寬的負擔
如果O家做room-scale只是把每個攝影機獨立算出來的定位資訊做補足(避免死角)，
那麼就不需要攝影機間的溝通

但如果在早期作影像處理時就有一些演算法改用各攝影機的畫面同時判斷，
那麼定位要改成硬體也需要讓各攝影機之間相互溝通

當然也不是做不到，都是成本問題，我是覺得O家不太可能這樣處理，CP不高，
需要的成本不低，得到的好處(可定位距離變大之類)卻沒有非常顯著

推 kira925: 如果是Oculus的系統的話....就我之前看到的Hack是 他是
→ kira925: 實際上真的用攝影機拍 然後跑特殊的驅動卡在中間丟進CPU
→ kira925: 轉換輸出 但Constellation系統是需要跑多個frame的相差
→ kira925: 處理掉影像轉換 也還有很大的負擔 而且還是會卡到攝影機
→ kira925: FPS 所以能夠完善多少...我懷疑
推 intela60474: 推這篇 也推vive
※ 編輯: zebb (220.132.208.60), 02/09/2017 17:54:58
→ kuma660224: 演算法固定後用攝影機內特製asic去分析
→ kuma660224: 應該就可以不用大頻寬傳輸，不依賴CPU
→ kuma660224: 不受限解析度，應該最可行。
→ kuma660224: 用usb傳影像回cpu算是初期省硬體的錢
→ kuma660224: 但應該只是第一代過渡性質做法。