2015-05-21 4 views
1

Я работаю над 3D-реконструкцией с танго. Наша система очень похожа на KinectFusion, которая использует voxel-представление, но использует Tango в качестве трекера. Левое изображение (в видео, приведенном ниже) отображается Raycast при текущей позе (заданной танго) в реальном времени. Исходная поза, преобразованная GetOC2OWMat(), как в примерах кода, кроме того, знак tx и rx перевернут, чтобы справиться с нашей системой. Все работает отлично, за исключением рациона в оси Z, которая меняет угол в визуализированном изображении. Я думаю, что преобразование системы координат не выполняется должным образом, но интеграция по глубине работает, если не задействовано Z-вращение. Я также проверил Det (R) всегда 1.Project Tango странная визуализация вращения

Video

ответ

0

Извините, что я просто найти место, где все идет не так. Когда изображение отображается с opengl, размер отображаемого gl не имеет того же формата изображения, что и изображение Raycasting.

0

Вы программируете с помощью Java/C/Unity? Мне любопытно, потому что у моего устройства есть проблемы с данными камеры, и вы, кажется, захватываете его без проблем. Я совершенно уверен, что это ошибка, но я хотел бы убедиться, что это действительно так.

+0

Я использую C api. Очень сложно получить цветное изображение правильно, потому что это вложенный указатель и он должен рекурсивно хранить данные указателя memcpy внутри. –

1

Похоже, что вы не факторизуетесь внутренними - вы учли кадры и устройства IMU-кадров? Вам нужно, чтобы они полностью восстановили исходную точку обзора, т. Е. Матрицы фотоаппарата и устройства imu должны быть умножены на ваш стек.

+0

Привет, я понял, что из-за соотношения сторон рендеринга gl не соответствует соотношению сторон изображения. Считаете ли вы, что создание карты глубины из облака точек должно учитывать радиальное искажение во внутренней матрице (это сильно улучшает результат?). Мне кажется, что отслеживание танго не так идеально, особенно по оси Z (по сравнению с плоскостью icp в сочетании с коррекцией IMU) –

+0

Не нужно было возиться с искажением объектива, однако для компенсации оригиналов Посмотреть. Да, ось Z должна рассматриваться как статистически точная догадка во времени, а не лазерный дальномер. Это проблема первого порядка. Проблема второго порядка - дрейф - угловое смещение в данном кадре является точным, но кумулятивное угловое смещение имеет дрейф, что приводит к большей ошибке. О Радость. –

+0

Это было учтено в GetOC2OWMat() в образце кода Google (я думаю, что оба фрейма упоминаются во время преобразования)? –

Смежные вопросы