作者zebb ()
看板VR
标题Re: [闲聊] 关於光学式定位的距离问题
时间Thu Jan 26 16:34:39 2017
交流一下个人想法,有错还请指正
※ 引述《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://webptt.com/cn.aspx?n=bbs/VR/M.1485419683.A.CD0.html
1F:推 kira925: 推 01/26 16:41
2F:推 GenialPP: 推 01/26 18:14
3F:推 SiaSi: 专业 01/26 18:28
4F:推 h1981127: 推!专业分析!不过需要3个USB的原因是他使用了三只相机 01/26 18:50
5F:→ kira925: 因为Oculus的设计两只摄影机还不够Room Scale... 01/26 19:33
6F:推 Kamikiri: 这样买下来 应该已经比VIVE还贵了吧? 一个镜头89镁 01/26 21:54
7F:推 kira925: 三颗镜头 一组手把 本体... 01/26 23:19
好像是这样没错,amazon上现在Oculus+touch价格刚好和vive差不多
再加上个第三摄影机...看来是比较贵
8F:推 ashinet: 写得很好 01/27 00:16
谢谢各位支持,但我的想法不一定对,大家一起交流
9F:→ hsinggg: 我非常不愿意这样说...转头买V吧... 01/27 02:31
这样好像又要被说是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阿...
10F:推 Tunie: 是啊 02/01 18:14
11F:→ ashinet: O家不争气, PSVR虽然用的很干,但最近有沙滩排球让我开心 02/02 11:34
12F:→ kuma660224: 镜头好处是未来容易降价。cam成本随制程降 02/05 11:18
13F:推 kira925: 基础演算法就有落差了 降价没意义阿.... 02/05 17:01
14F:推 h1981127: 如果能把影像演算法写成硬体,用晶片去运算,就不用耗 02/06 01:38
15F:→ h1981127: 到CPU的资源了,这样一来就算换成4K影像也不要紧,再来 02/06 01:38
16F:→ h1981127: 就是晶片放在灯塔上,灯塔只要回传运算完之後的座标资 02/06 01:38
17F:→ h1981127: 料,这样也就解决了频宽不足的问题,最後也最重要的就只 02/06 01:38
18F:→ h1981127: 剩下晶片的成本会多贵了 02/06 01:38
确实这似乎不失为一个选项,但当对手灯塔成本越来越低时(有在研发一个马达版本)
我是觉得不太可能这样进行,尤其现在的价格就已经是一般人不会接受的高了,
要做这样的SoC,成本应该不低喔
19F:推 kira925: 这样损失了灯塔系统有可能做ad-hoc多灯塔扩充的可能性 02/06 09:11
20F:推 h1981127: 不冲突啊,灯塔回传的只是灯塔和头盔的相对座标,多灯 02/06 13:54
21F:→ h1981127: 塔运算再由cpu去反推灯塔之间的相对位置,最後由软体去 02/06 13:54
22F:→ h1981127: 重新制定一个座标轴 02/06 13:54
23F:推 kira925: 没有灯塔的绝对座标的话 会做不出来... 02/06 14:42
24F:推 h1981127: 由灯塔A推得头盔的相对位置a,由灯塔B推得头盔的相对位 02/06 16:23
25F:→ h1981127: 置b,已知a=b,反推A和B的位置,有什麽难的吗? 02/06 16:23
26F:推 kira925: 那你需要的就不只两个灯塔了 是三个阿... 02/06 16:51
27F:推 h1981127: 完全不懂楼上的问题点在哪? 可以详述一下吗? 02/06 16:58
28F:推 kira925: 我被GPS定位法搞混了 我再想想 主要是单纯a=b这件事情 02/06 17:49
29F:→ kira925: 你只能得到一个平面上等距 所以得不到A/B的位置 02/06 17:50
30F:→ kira925: SteamVR在确定游玩范围的时候应该就是要从主机上做定位 02/06 17:51
31F:→ kira925: A/B灯塔出来的距离多远到多远是最大范围边界 如果你 02/06 17:51
32F:→ kira925: 把这些计算扔进灯塔 那就是要有传输路径持续即时连线 02/06 17:52
33F:→ kira925: 到CPU更新让CPU去合成 那我觉得没有头盔上面收讯计算漂亮 02/06 17:52
一开始O家一个摄影机就可以定位三轴
我想或许是利用各个定位点之间的距离来推估深度资讯
(PS Move则是利用光球的大小来推估深度)
所以没有类似GPS定位需要三个的问题
34F:推 h1981127: 我们讲的可能是不同的系统,我是讨论Oculus的系统,目前 02/06 18:32
35F:→ h1981127: O家的系统问题是要先把影像传回电脑,靠CPU去运算灯塔和 02/06 18:32
36F:→ h1981127: 头盔的相对位置,由於O家是使用USB传输,所以会消耗大量 02/06 18:32
37F:→ h1981127: 的频宽在影像传输上,这也是影像解析度无法提升的一个因 02/06 18:32
38F:→ h1981127: 素,我一开始说的重点就是让影像处理这一块改用硬体运 02/06 18:32
39F:→ h1981127: 算,降低CPU以及频宽的负担 02/06 18:32
如果O家做room-scale只是把每个摄影机独立算出来的定位资讯做补足(避免死角),
那麽就不需要摄影机间的沟通
但如果在早期作影像处理时就有一些演算法改用各摄影机的画面同时判断,
那麽定位要改成硬体也需要让各摄影机之间相互沟通
当然也不是做不到,都是成本问题,我是觉得O家不太可能这样处理,CP不高,
需要的成本不低,得到的好处(可定位距离变大之类)却没有非常显着
40F:推 kira925: 如果是Oculus的系统的话....就我之前看到的Hack是 他是 02/06 20:49
41F:→ kira925: 实际上真的用摄影机拍 然後跑特殊的驱动卡在中间丢进CPU 02/06 20:49
42F:→ kira925: 转换输出 但Constellation系统是需要跑多个frame的相差 02/06 20:51
43F:→ kira925: 处理掉影像转换 也还有很大的负担 而且还是会卡到摄影机 02/06 20:52
44F:→ kira925: FPS 所以能够完善多少...我怀疑 02/06 20:53
45F:推 intela60474: 推这篇 也推vive 02/07 15:06
※ 编辑: zebb (220.132.208.60), 02/09/2017 17:54:58
46F:→ kuma660224: 演算法固定後用摄影机内特制asic去分析 02/10 22:25
47F:→ kuma660224: 应该就可以不用大频宽传输,不依赖CPU 02/10 22:25
48F:→ kuma660224: 不受限解析度,应该最可行。 02/10 22:26
49F:→ kuma660224: 用usb传影像回cpu算是初期省硬体的钱 02/10 22:30
50F:→ kuma660224: 但应该只是第一代过渡性质做法。 02/10 22:30