Сроки проблемы с кадрами изображения Tango

Похоже, что Tango сбрасывает кадры изображения, когда я пытаюсь получить данные глубины, данные изображения и данные позы одновременно.

Я пытаюсь захватить глубину и кадры изображения и синхронизировать их с данными позы. Используя C point-cloud-jni-example, я добавил код для сброса данных облака точек в буферы памяти, а затем в файлы. Я добавил обратный вызов для onFrameAvailable() и скопировал данные изображения в буферы, а затем в файлы. Поскольку данные изображения имеют частоту 30 Гц, а данные глубины - ~5 Гц, я наивно ожидал, что последнее изображение будет достаточно близко соответствовать последнему кадру глубины. Метки времени были не очень близки. В некоторых случаях они отличались более чем на 100 миллисекунд. Поэтому я начал исследовать синхронизацию обратных вызовов onXYZijAvailable(), onFrameAvailable() и onPoseAvailable() и соответствующих временных меток данных.

Я добавил дампы logcat к каждому обратному вызову и распечатал системное время (std::chrono::system_clock::now()) и метку времени TangoSystem для возвращаемых данных, будь то глубина, изображение или поза. Часть этого была описана точно, как мы вычисляем дифференциалы меток времени?,

Вот некоторые сроки позы. Системное время - это текущее время часов при выполнении обратного вызова. Отметка времени позы происходит от фактической структуры позы.

             sys time   pose timestamp
TM CLK Pose  10.008419  245.976464
TM CLK Pose  10.025983  246.009791
TM CLK Pose  10.124470  246.043119
TM CLK Pose  10.133542  246.076447
TM CLK Pose  10.147136  246.109774
TM CLK Pose  10.192470  246.143102
TM CLK Pose  10.200370  246.176430
TM CLK Pose  10.225367  246.209757
TM CLK Pose  10.300509  246.243085
TM CLK Pose  10.311827  246.276413
TM CLK Pose  10.335946  246.309740
TM CLK Pose  10.399209  246.343068
TM CLK Pose  10.407704  246.376396
TM CLK Pose  10.426889  246.409723
TM CLK Pose  10.504403  246.443051

Соответствующие различия от позы к позе показаны здесь. Синхронизация позы очень сильна и составляет 33 мсек на основании записанных временных отметок. Время обратного вызова сильно отличается, предположительно из-за загрузки приложения.

time:  0.017564   pose:  0.033327
time:  0.098487   pose:  0.033328
time:  0.009072   pose:  0.033328
time:  0.013594   pose:  0.033327
time:  0.045334   pose:  0.033328
time:  0.007900   pose:  0.033328
time:  0.024997   pose:  0.033327
time:  0.075142   pose:  0.033328
time:  0.011318   pose:  0.033328
time:  0.024119   pose:  0.033327
time:  0.063263   pose:  0.033328
time:  0.008495   pose:  0.033328
time:  0.019185   pose:  0.033327
time:  0.077514   pose:  0.033328
time:  0.011892   pose:  0.033328

Вот некоторые временные рамки и соответствующие различия. Временные метки очень стабильны и составляют примерно 0,2 секунды.

             sys time : xyz timestamp
TM CLK XYZ   10.161695  246.017013
TM CLK XYZ   10.363448  246.216639
TM CLK XYZ   10.595306  246.438693
TM CLK XYZ   10.828368  246.668223
TM CLK XYZ   11.025787  246.890277
TM CLK XYZ   11.233364  247.097379
TM CLK XYZ   11.433941  247.297005
TM CLK XYZ   11.633176  247.496631
TM CLK XYZ   11.830650  247.696257

time:  0.201753   depth:  0.199626
time:  0.231858   depth:  0.222054
time:  0.233062   depth:  0.229530
time:  0.197419   depth:  0.222054
time:  0.207577   depth:  0.207102
time:  0.200577   depth:  0.199626
time:  0.199235   depth:  0.199626
time:  0.197474   depth:  0.199626
time:  0.196935   depth:  0.199626

Вот немного времени изображения. Строки с пометкой "---" являются проблемными кадрами.

             sys time : img timestamp
TM CLK Img   10.041056  246.005896
TM CLK Img   10.074105  246.105709   -----
TM CLK Img   10.106492  246.105709
TM CLK Img   10.142581  246.138980
TM CLK Img   10.176176  246.172251
TM CLK Img   10.241146  246.205522
TM CLK Img   10.274909  246.305335   -----
TM CLK Img   10.317819  246.305335
TM CLK Img   10.361682  246.345225
TM CLK Img   10.397533  246.390139
TM CLK Img   10.472859  246.430886
TM CLK Img   10.514923  246.538175   -----
TM CLK Img   10.551663  246.545651
TM CLK Img   10.585960  246.586398
TM CLK Img   10.626671  246.620526
TM CLK Img   10.705709  246.656249
TM CLK Img   10.734324  246.767705   -----
TM CLK Img   10.774233  246.768562
TM CLK Img   10.808848  246.804285
TM CLK Img   10.847230  246.842580
TM CLK Img   10.927872  246.878303
TM CLK Img   10.957309  246.989759   -----
TM CLK Img   10.991136  246.990616

Вот соответствующие различия во времени для приведенного выше списка.

time:  0.033049   image:  0.099813
time:  0.032387   image:  0.000000
time:  0.036089   image:  0.033271
time:  0.033595   image:  0.033271
time:  0.064970   image:  0.033271
time:  0.033763   image:  0.099813
time:  0.042910   image:  0.000000
time:  0.043863   image:  0.039890
time:  0.035851   image:  0.044914
time:  0.075326   image:  0.040747
time:  0.042064   image:  0.107289
time:  0.036740   image:  0.007476
time:  0.034297   image:  0.040747
time:  0.040711   image:  0.034128
time:  0.079038   image:  0.035723
time:  0.028615   image:  0.111456
time:  0.039909   image:  0.000857
time:  0.034615   image:  0.035723
time:  0.038382   image:  0.038295
time:  0.080642   image:  0.035723
time:  0.029437   image:  0.111456
time:  0.033827   image:  0.000857

Обратите внимание, что каждые 4 кадра имеет место большая задержка во времени изображения, примерно 100 мсек. Затем следуют два кадра с одинаковой или почти одинаковой отметкой времени. Даже в тех случаях, когда метка времени на двух последовательных изображениях идентична, обратный вызов все еще срабатывает, чтобы указать новый кадр. В результате я пропускаю каждый пятый кадр видео. Это воняет для приложения, пытающегося сопоставить данные глубины и изображения.

Я удалил любую дополнительную обработку из кода. В обратных вызовах происходит только то, что данные копируются в статические буферы. Рендеринг облака точек все еще выполняется в обычном потоке рендеринга.

Итак, что дает? Может ли устройство Tango не обрабатывать обратные вызовы глубины, изображения и позы, работающие одновременно? Нужно ли использовать UpdateTexture() вместо onFrameAvailable()?

1 ответ

В текущей версии Project Tango Tablet RGB ИК-камера используется как для глубинных, так и для цветных изображений, и она может делать только одно или другое для каждого кадра. Таким образом, в потоке мы получаем 4 кадра RGB, за которыми следует 1 кадр глубины, в результате чего вы наблюдаете шаблон. Это больше аппаратное ограничение.

Другие вопросы по тегам