簡體   English   中英

Project Tango onPoseAvailable()和getPoseAtTime()的差異

[英]Project Tango onPoseAvailable() and getPoseAtTime() discrepancies

我看到onPoseAvailable()回調和Tango.getPoseAtTime()的姿勢之間存在重大差異。 我編寫了一個測試程序,其中在onPoseAvailable()我記錄了所提供的姿勢,並使用getPoseAtTime()使用來自2個回調的時間戳來請求姿勢。 KEY_BOOLEAN_SMOOTH_POSE配置為false 這是執行此操作的代碼( timestamps_成員變量是LinkedList<Double> ):

@Override
public void onPoseAvailable(TangoPoseData poseData) {
   if (poseData != null && poseData.statusCode == TangoPoseData.POSE_VALID) {
      Log.v("bug",
         String.format("onPoseAvailable t: %f, base: %d,  target %d, p: (%f, %f, %f)",
            poseData.timestamp,
            poseData.baseFrame,
            poseData.targetFrame,
            poseData.translation[0], poseData.translation[1], poseData.translation[2]));
      timestamps_.add(poseData.timestamp);
      if (timestamps_.size() > 3)
         timestamps_.remove();
   }

   if (timestamps_.isEmpty())
      return;

   TangoCoordinateFramePair framePair = new TangoCoordinateFramePair(
      TangoPoseData.COORDINATE_FRAME_START_OF_SERVICE,
      TangoPoseData.COORDINATE_FRAME_DEVICE);
   poseData = tango_.getPoseAtTime(timestamps_.getFirst(), framePair);
   if (poseData != null && poseData.statusCode == TangoPoseData.POSE_VALID) {
      Log.v("bug",
         String.format("getPoseAtTime t: %f, base: %d,  target %d, p: (%f, %f, %f)",
            poseData.timestamp,
            poseData.baseFrame,
            poseData.targetFrame,
            poseData.translation[0], poseData.translation[1], poseData.translation[2]));
   }
}

這是實際日志的摘錄(為清晰起見,我對記錄的調用進行了去交織):

onPoseAvailable t: 2732.762486, base: 2,  target 4, p: (0.280245, 0.412468, 0.562201)
onPoseAvailable t: 2732.802553, base: 2,  target 4, p: (0.296951, 0.420919, 0.599938)
onPoseAvailable t: 2732.852638, base: 2,  target 4, p: (0.317444, 0.429809, 0.646445)
onPoseAvailable t: 2732.882689, base: 2,  target 4, p: (0.330845, 0.434106, 0.676810)
onPoseAvailable t: 2732.932774, base: 2,  target 4, p: (0.350995, 0.439777, 0.723639)
onPoseAvailable t: 2732.962825, base: 2,  target 4, p: (0.363319, 0.442731, 0.754508)
onPoseAvailable t: 2732.992875, base: 2,  target 4, p: (0.373911, 0.445289, 0.784786)
onPoseAvailable t: 2733.032943, base: 2,  target 4, p: (0.387709, 0.448182, 0.822682)
onPoseAvailable t: 2733.062994, base: 2,  target 4, p: (0.398502, 0.450481, 0.852662)
onPoseAvailable t: 2733.073011, base: 2,  target 4, p: (0.401869, 0.451084, 0.862530)
onPoseAvailable t: 2733.103062, base: 2,  target 4, p: (0.411136, 0.452486, 0.890441)

getPoseAtTime t: 2732.712401, base: 2,  target 4, p: (0.269301, 0.410911, 0.549182)
getPoseAtTime t: 2732.732435, base: 2,  target 4, p: (0.277217, 0.415130, 0.567040)
getPoseAtTime t: 2732.762486, base: 2,  target 4, p: (0.288928, 0.421914, 0.595162)
getPoseAtTime t: 2732.802553, base: 2,  target 4, p: (0.305241, 0.429648, 0.632158)
getPoseAtTime t: 2732.852638, base: 2,  target 4, p: (0.324359, 0.437655, 0.680300)
getPoseAtTime t: 2732.882689, base: 2,  target 4, p: (0.332997, 0.442538, 0.712727)
getPoseAtTime t: 2732.932774, base: 2,  target 4, p: (0.353665, 0.447269, 0.759725)
getPoseAtTime t: 2732.962825, base: 2,  target 4, p: (0.369174, 0.451645, 0.790263)
getPoseAtTime t: 2732.992875, base: 2,  target 4, p: (0.382584, 0.454754, 0.819555)
getPoseAtTime t: 2733.032943, base: 2,  target 4, p: (0.396857, 0.456922, 0.856626)
getPoseAtTime t: 2733.062994, base: 2,  target 4, p: (0.409672, 0.460060, 0.888748)

看一下最后一個帶有時間戳2733.062994的getPoseAtTime()條目。 請注意,其位置值與具有相同時間戳記的onPoseAvailable中的姿勢不匹配。 這里不對勁。

我確實認為,樣條曲線的位姿擬合不一定需要通過控制點,但是我認為這不是可以接受的解釋。 首先,擁有一個為同一測量提供不同值的API並沒有多大意義。 但除此之外,實際數字並不支持這一推測。

查看getPoseAtTime() Y值0.460060。 這在所有onPoseAvailable() Y值的Y范圍之前和之后(實際上是整個日志onPoseAvailable()都在Y范圍之外。 沒有合理的插值模型可以產生該值。

我想問題是這里發生了什么? 姿勢不一致,因此至少其中之一是錯誤的(如果不是兩個)。 我的猜測是onPoseAvailable()更可能是正確的。

這是將數位板固定在底座上時,兩種姿勢方法(Nash釋放)的Y位置與時間的關系圖:

在此處輸入圖片說明

藍線是onPoseAvailable()回調,紅線是getPoseAtTime()輪詢。 這些結果有點奇怪。 如果姿勢完全不同,我希望輪詢值會更平滑,因為可以使用輪詢時間之前和之后的樣本貢獻來過濾輪詢值,而回調值將不被過濾或僅使用之前的值進行過濾樣品。 但這不是我們所看到的-輪詢的值看起來更嘈雜。

這是我上下移動平板電腦時捕獲的類似圖形。 輪詢的值仍然具有更高的頻率,並且兩個信號之間的跟蹤並不特別緊密。

在此處輸入圖片說明

感謝rhashimoto指出這一點!

編輯

我必須編輯我以前的帖子。 我聲稱使用GetPoseAtTime而不是OnPoseAvailable回調的姿勢時,漂移更大。

反之亦然。 使用GetPoseAtTime可以獲得更好的結果。

我通過在椅子上旋轉360°進行了掃描。 如您在圖片中所見,我在辦公桌前停下來。

掃描周期的開始和結束(單擊以獲得更高的分辨率) 掃描周期的開始和結束

上方的點雲使用GetPoseAtTime構成,下方的點雲使用OnPoseAvailable回調構成。 兩者同時捕獲。 GetPoseAtTime的漂移很小,但OnPoseAvailable回調的漂移確實很大。

到目前為止,我發現,GetPoseAtTime使用姿勢圖並在檢測到閉環時糾正姿勢。 請參見本文 我測試了結果是否變好,是否立即使用可用的點雲訪問姿勢或在合並所有點雲時才訪問姿勢。

結果的確更好。 因此,到目前為止,我的經驗是:

掃描結束時,OnPoseAvailabe回調<GetPoseAtTime立即具有可用點雲<GetPoseAtTime

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM