Проблемы с синхронизацией с кадрами изображений Tango

Question

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

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

Я добавил logcat дампы для каждого обратного вызова и распечатывал системное время (std :: chrono :: system_clock :: now()) и временную метку TangoSystem возвращаемых данных, будь то глубина, изображение или поза. Некоторые из них были описаны в exactly how do we compute timestamp differentials?.

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

   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()?

Answer 1

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