Система для построения модели трехмерного пространства Российский патент 2024 года по МПК G06T7/579 H04N13/246 G01S17/894 G01S7/481 

Изобретение относится к моделированию трехмерного пространства.

Основная цель предлагаемого решения - это создать систему для осуществления связи и коллаборативной работы нового поколения. Идея базируется на том, что многие рабочие задачи невозможно удаленно решать только с помощью видео (решения типа Skype, Zoom), так как оно недостаточно информативно и удобно по сравнению с личным присутствием на месте.

Для решения этой проблемы необходимо создать комплексное решение на базе пользовательского смартфона с LIDAR для потоковой передачи видео с данными глубины (RGB-D) и последующей трехмерной реконструкции на базе этих данных удаленным устройством в реальном времени.

Наиболее близким решением является патент РФ №2713611, от 05.02.2020 в котором раскрыто устройство и способ для генерации модели трехмерного пространства. Данное устройство для генерации модели трехмерного пространства, содержит: интерфейс для получения изображения, конфигурированный для получения данных изображения, генерируемых устройством захвата изображения, эти данные изображения представляют результат наблюдения, так что здесь имеет место относительное перемещение между трехмерным пространством и устройством захвата изображения во времени; и механизм моделирования, конфигурированный для обработки данных изображения, полученных интерфейсом для получения изображения, и для вычисления трехмерной модели трехмерного пространства, где этот механизм моделирования содержит: сегментатор модели, конфигурированный для сегментации трехмерной модели и разбиения ее, по меньшей мере, на активные и неактивные части на основе по меньшей мере одного свойства модели, в котором механизм моделирования конфигурирован для использования активных частей трехмерной модели с целью обновления модели во времени; и механизм совмещения конфигурирован для выравнивания активных частей трехмерной модели с неактивными частями трехмерной модели во времени.

Недостатками данного устройства является недостаточная целостность получаемого трехмерной модели, а также ее качество, ввиду присутствия большого количества шумов.

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

Технический результат - повышение точности модели трехмерного пространства.

Технический результат достигается тем, что

Предлагаемая система поясняется фиг.1-5.

На фиг.1 показана схема работы предлагаемого решения по трансляции и обработке данных,

на фиг.2 показана схема шагов и этапов предлагаемой системы для создания трехмерной реконструкции,

на фиг.3 показан паттерн для калибровки камеры,

на фиг.4 показан пример определения ключевых точек в кадре и сравнения их с соседним кадром для определения траектории,

на фиг.5 показан пример реконструированной карты передвижения,

на фиг.6 показан пример реконструкции до срабатывания события Loop Closure. Красным отмечена область расхождения траектории,

на фиг.7 показана реконструкция после срабатывания алгоритма Loop Closure. Красными линиями выделены траектории коррекции точек из текущего кадра,

на фиг.8 пример элемента датасета, кадр №10,

на фиг.9 показана структура октодерева для хранения точек,

на фиг.10 показана отрисовка в реальном времени с промежутками в 500 кадров,

на фиг.11 показан результат без исключения соседних точек, результат с фильтрацией,

на фиг.12 показаны результаты сверки измерений между реальным миром и реконструкцией.

Для реализации предлагаемой системы в качестве устройство захвата изображения был выбран Iphone 13 pro Мах, который позволяет получать карту глубины разрешением 192 на 256 с частотой в 60 кадров в секунду. Сочетая это с подвижностью камеры, мы можем легко и быстро получать плотную и точную карту точек.

При этом передача данных с phone 13 pro Мах в систему моделирования трехмерного пространства осуществлялась с использованием интерфейса WebRTC по протоколу TCP см. фиг. 1.

С точки зрения архитектуры был реализован программный комплекс из трех компонентов

1) Приложение для смартфона "ARstream"

2) Серверное приложение для сигнализирования "Signal"

3) Клиентское приложение для получения и обработки данных "Viewer"

Основная часть задач реализуется непосредственно на устройстве отправки в приложении ARstream.

На нем с помощью использования ARkit 6 и его встроенных функций была реализована возможность получения данных с LIDAR с присвоением параметров глубины и степени уверенности для каждого пикселя.

LIDAR устройства Iphone 13 pro Мах позволяет получать карту глубины разрешением 192 на 256 с частотой в 60 кадров в секунду. Сочетая это с подвижностью камеры мы можем легко и быстро получать плотную и точную карту точек. Тем не менее требуется внимательная фильтрация по краям физических объектов, так как при таком разрешении карты глубины в этих областях находятся потенциальные источники ошибок реконструкции. Для этого помимо глубины каждого пикселя мы передаем и степень уверенности в диапазоне от 0 до 1, которая вычисляется методами встроенными в ARkit 6.

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

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

Реализация трехмерной реконструкции с помощью LIDAR (RGB-D данные) в общем виде реализуема при решении следующий задач (см. фиг..2):

1) Получения данных с сенсоров устройства и их ассоциирование. При этом различные подходы позволяют реализовывать это либо с поправкой на данные с IMU сенсоров устройства или без них

2) Вычисление траектории движения камеры

3) Построение облака точек от кадра к кадру

4) Очистка получающихся данных от шумов

5) Механизмы коррекции траектории для ликвидации накапливаемой ошибки (Loop Closure)

6) Построение итогового меша

Общая методика работы на примере нашего подхода и результатов.

Пример данных на вход:

1) RGB. Поступают в стандартной цифровой кодировке 16 или 8 бит

2) Глубина. Представляют из себя PNG, хранящая данные только в диапазоне черное-белое, где чисто белый цвет (0) обозначает минимальную дистанцию, а черный (1) максимальную дистанцию, захваченную датчиком глубины.

3) IMU данные. Хранятся в текстовом формате типа

Все типы поступаемых данных могут обрабатываться как в реальном времени, так и в виде заранее подготовленной группы данных (датасета).

Механизм передачи данных отправляет следующие типы информации

1) Цвет

2) Глубина

3) Уверенность в глубине

4) Матрица камеры

5) Данные IMU

6) Данные одометрии

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

Для калибровки использовались стандартные алгоритмы. В общих чертах он представляет из себя ряд фотографий паттерна шахматной доски (см. фиг.3).

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

Основную сложность в нашей задаче представляет непосредственно определение траектории и это связано с особенностями скользящего затвора камеры.

Данная особенность означает, что на кадрах, которые захватываются при поворотах есть незаметные глазу, но очень значимые при вычисления искажения. Они возникают из-за того, что верхняя часть кадра захватывается на 15 миллисекунд раньше, чем нижняя. Таким образом формируется сдвиг, который при вычислениях способ визуальной одометрии (сравнение последовательности кадров) будет выдавать определенную ошибку, которая рано или поздно приведет к значительным искажениям или поломке реконструкции.

Для компенсации этой проблемы мы учитываем дополнительные данные с IMU трекеров и встроенные в AR Kit возможности по вычислению траектории движений телефона.

Краткое описание методики определения положения выглядит следующим образом:

1) Для картинки разрешением 720 × 480 определяется 1000 ключевых точек в кадре. Ключевой точкой является область высокого контраста между соседними пикселями. По возможности точки определяются равномерно по кадру, который делится на сетку, состоящую из 60 квадратов, в каждом квадрате алгоритм пытается обнаружить не менее 5 точек.

2) В случае, если для предыдущего кадра поиск точек был успешен, используется модель измерения постоянной скорости, которая используется для вычисления и предсказания движения камеры. В случае если трекинг предыдущего кадра был не успешен, то используется более широкий метод определения местоположения.

3) Абсолютное вычисление позиции.

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

4) Построение карты.

После вычислений позиции карты и определения ключевых точек и их совпадения мы можем спроецировать карту на кадр и обнаружить совпадение с общей картой реконструкции. Эта локальная карта содержит набор ключевых кадров K1, которая хранит его совместно с текущим кадром и набором K2, который представляет из себя соседние кадры к K1 в графе ковидимости (точки попали в поле зрения всех кадров). Карта также имеет эталонный ключевой кадр Kref ∈ K1, который хранит все совпадающие ключевые точки с текущим кадром. Теперь каждая точка карты, видимая в K1 и K2, ищутся в текущем кадре следующим образом:

- Вычисляется проекция ключевой точки х в текущем кадре.

Отменить, если он выходит за границы изображения.

- Вычислить угол между текущим лучом обзора v и ключевой точки. Отменить, если v ⋅ n < cos(60°).

- Вычислить расстояние d от точки карты до центра камеры. Отмена, если он выходит за пределы области инвариантности масштаба точки карты d /∈ [dmin, dmax].

- Рассчитать масштаб в кадре по соотношению d/dmin.

5) Связать ключевые точки с лучшим совпадением из текущей карты и таким образом вычислить позицию камеры f. Новые ключевые точки добавляются на общую карту (см. фиг.4).

Итоговый алгоритм позволяет строить карту пространства на базе абстрактных ключевых точек и примерную геометрию пространства с довольно высоким уровнем точности. Тем не менее, этот метод интересен нам в первую очередь именно для восстановления траектории движения см. фиг.5, дальнейшая реконструкция происходит уже с помощью использования данных от камеры глубины.

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

Также в любых существующих сегодня методах реконструкции имеет место быть накопление ошибки см фиг.6. Используя разные методы и типы камер ее можно сильно сократить, но не убрать полностью. Для решения этой проблемы используется алгоритм Loop Closure. Чтобы он работал, снимающему следует периодически возвращаться к уже захваченным камерой областям. При работе алгоритма, когда возникает ситуация возврата к уже посещенной области происходит процесс сверки ключевых точек текущего кадра с уже хранящимися на карте. При нахождении достаточного количества соответствий алгоритм проводит корректировку всей пройденной траектории между текущим кадром и прошлым кадром, когда эта область попала в камеру.

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

Механизм Loop Closure является чрезвычайно важным элементом при построении реконструкции. В случае работы постоянно движущейся камеры ошибка регулярно возникает и имеет тенденцию накапливаться. Без работы такого алгоритма итоговая реконструкция очень быстро начинает ломаться и теряет вид с которым реально работать и в целом адекватно воспринимать.

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

Это важная особенность, которую надо иметь ввиду при выборе областей применения подобной разработки. На текущем этапе эти методы стоит применять там, где допустима погрешность в 5-10 миллиметров.

Пример построения трехмерного пространства следующие данные:

Последовательность цветных статичных кадров, 19961 штук

Последовательность черно-белых изображений с глубиной цвета 16 бит, 19961 штук

Последовательность перемещений устройства, содержащая временную метку, номер кадра, положение в трехмерной системе координат, кватернионное вращение (далее поза)

Сведения о параметрах камеры устройства

Пример элемента датасета, кадр №10 (см. фиг.8):

Также помимо вышеуказанного датасет содержит:

Формат глубины (Z16)

Ширину и высоту карты глубины (192×256)

Значение масштаба карты глубины (1000)

Параметры матрицы:

Фокусное расстояние (475.8907)

Координаты главной точки снимка (0,0)

Коэффициенты аффинитета и неортогональности (0, 475.8907)

Коэффициенты радиальной дисторсии (0, 322.10426, 240.97993, 1)

Значение количества кадров в секунду, при котором были сняты изображения

Используя данный набор данных (в дальнейшем - датасет), мы собрали первоначальный тестовый вариант системы.

Для переноса данных с реального мира на виртуальную сцену, нам необходимо два инструмента - конвертация координатных систем, и соблюдение единиц измерения.

Основываясь на том, что координаты и углы вращения записывались в системе координат Unity-сцены, мы предположили, что нам достаточно установить на виртуальной сцене виртуальную камеру, в записанную с реального устройства позу, пренебрегая различиями систем координат. Это удовлетворяет первую потребность, далее мы приступили к сопоставлению единиц измерения.

Мы узнали, что карта глубины LIDAR, кодирует информацию о глубине градиентом, где черный цвет обозначает максимальное удаление от камеры, а белый цвет означает максимальное приближение к камере. Согласно техническим данным, максимальная дальность показаний LIDAR на iPhone 14-5 метров. Зная эту информацию, мы декодировали значения пикселей, в значение расстояния точек от виртуальной камеры. Алгоритм декодирования выглядит следующим образом:

Получить набор данных, соответствующий одному кадру,

Поместить виртуальную камеру в позу, записанную с устройства,

Взять кадр с цветной камеры и камеры глубины,

На каждый пиксель изображения, создавать точку,

Основываясь на цвете пикселя карты глубины, задать расстояние по оси Z для точки,

Основываясь на положении пикселя внутри изображений, задать положение по X и Y следующим образом:

Создаем абстрактный экземпляр точки, и помещаем его во временное хранилище

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

Где xPos, yPos - искомые двумерные координаты, - индекс пикселя внутри одномерного массива изображений, HV - высота изображения,

Приводим значение глубины в численное представление, используя текущий обрабатываемый пиксель карты глубины

Производим проверку на наличие шума, у соседних с текущим пикселем значений, если соседствующие пиксели не имеют значения отличного от нуля, то игнорируем данный пиксель

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

Где - координата точки в пространстве виртуальной сцены,

- значение глубины,

- главная точка снимка,

- фокусное расстояние,

- трехмерная координата точки на сцене,

- трехмерная координата камеры на сцене,

- относительный вектор направленный вверх,

- относительный вектор направленный вправо,

- относительный вектор направленный вперед.

Основываясь на цвете пикселя с цветного изображения, задать точке цвет,

Отправить полученную точку в визуализатор, повторять для всех пикселей,

Таким образом, мы собрали первый вариант механизма определения глубины. Использование технологии SLAM на тестовом устройстве, позволило нам пренебречь различиями в системе координат, и синхронизировать положение устройства в реальном мире, и внутри виртуальной сцены. Поскольку при инициализации, ARK.it локализует положение устройства относительно земли, и задает начальное положение. В системе координат, положение, регистрируемое ARKit, имеет значение Y (высота устройства над землей), и пренебрегаемое значение по X и Z (близкое к нулю). Следовательно, положение в реальном мире, получает нулевую координату - место инициализации ARKit, которая также может являться нулевой координатой на виртуальной сцене.

Разработка механизма определения и фильтрации шумов, а также трехмерной реконструкции на базе серверной части оснащенной видеоускорителем

Протестировав прототип механизма определения глубины, мы обнаружили, что данные получаемые с карты глубины несут в себе большое количество бесполезных точек. Это обуславливается механизмом работы LIDAR. Так как LIDAR это оптическая система, то поверхности находящиеся за пределами зоны действия излучателя не считываются. Механизм работы LIDAR обуславливается отражением излучения в преломляемой среде, и получением излучения обратно в приемник. Поскольку поверхности находящиеся дальше зоны действия излучателя не имеют возможность отражать свет, то эти поверхности не регистрируются, и на карте глубины помечаются черным цветом. Эти незарегистрированные поверхности можно считать шумом.

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

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

В первую очередь, мы обладаем тестовым датасетом, в размере 39 922 изображения. Каждое изображение имеет разрешение 640×480, следовательно, каждое изображение содержит 307 200 пикселей, причем необходимо обработать два изображения, следовательно, за 1 кадр необходимо обработать 614 400 пикселей. Видеопоток должен отправлять кадры, на скорости 60 кадров в секунду, значит нам необходимо обрабатывать 36 864 000 пикселей в секунду. Итого, мы получаем весьма серьезные требования к производительности системы и скорости обработки.

Добавить таблицу, в которой сколько за промежуток времени появляется данных, 4 строчки - сколько пикселей, точек, сколько изображений использовано

Имея такие требования, в качестве инструмента визуализации мы выбрали систему частиц. Традиционно, для интерактивных систем, система частиц используется для визуализации большого количества точек, поскольку системы частиц проектировались для создания и управления большим количеством графических элементов. В первую очередь, мы опробовали стандартную систему частиц, входящую в набор Unity. В первую очередь, нас интересовало максимальное доступное количество точек, которые мы можем отрисовать с помощью системы частиц, ведь визуализация облаков точек, для обеспечения плотности и качества отображения, требует в среднем не менее 1 миллиона точек. Эксперименты показали, что стандартная система частиц не справляется с таким количеством элементов, и к тому же не дает возможности управлять отдельно взятыми точками, после чего от ее использования было решено отказаться.

Нами был опробован механизм визуализации, использующий Unity VFX Graph. Данный компонент был создан, для реализации внутри проектов Unity комплексных спецэффектов. Будучи в своей основе системой частиц, VFX Graph поддерживает работу с большим количеством точек, не нагружая чрезмерно ресурсы устройства. Помимо этого, VFX Graph, изначально создавался для работы со сложными расчетами, поэтому имеет функционал доступа к графическому буферу.

Алгоритм декодирования отправлял данные в тестовый вариант VFX Graph, создавая точки, задавая им положение и цвет. Данный вариант показал себя наилучшим образом, сохраняя высокий FPS (-400) и большое количество точек (307 200 точек).

Таким образом, нами был выбран VFX Graph в качестве подсистемы визуализации.

Первоначально, мы отправляли данные в VFX Graph напрямую, однако это создавало ограничение на скорость обработки данных. Для избежания этой проблемы, мы создали вычислительный шейдер. Внутрь этого шейдера, мы перенесли алгоритм декодирования. Такая схема позволила освободить главный вычислительный поток приложения от тяжелых расчетов, и оперировать на уровне графического ядра. Алгоритм декодирования, описанный в главе 1, был перенесен целиком, без изменений, с поправкой на синтаксис языка HLSL.

Далее, возник вопрос, каким образом можно избежать повторного размещения точек на одной и той же координате. Поскольку, мы работаем с видеопотоком, каждый последующий кадр, скорее всего, будет мало отличаться от предыдущего. Из-за этого, в процессе декодирования и размещения точек, имеется недостаток - на одну точку в пространстве могут приходиться другие точки-дубликаты. Эти дубликаты являются шумом, и его требуется отфильтровать, поскольку данные точки повторяют полезную информацию и не несут пользы, нагружая вычислительные ресурсы. Наша система требует все максимально доступные вычислительные ресурсы, и, очищая данные дубликаты, мы высвобождаем больше ресурсов для полезной нагрузки.

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

Однако, в процессе ознакомления с академическими материалами, мы обнаружили материал, посвященный хэшированию вокселей с помощью октодерева. Данная методика справлялась с обоими факторами, и мы решили использовать октодеревья. Первой причиной использования октодеревьев является возможность хранить информацию в структурированном виде, позволяющем быстро обратиться к конкретной точке. Исходя из первой причины, мы можем взаимодействовать с обработанными данными, что потребуется для дальнейшего создания инструментов. Также, структура октодеревьев требует меньше затрат по памяти, нежели другие доступные способы хранения. В совокупности, использование октодеревьев позволяет нам работать внутри ограничений.

Была начата работа над внедрением механизма октодеревьев в наше решение.

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

Первоначально, мы разбиваем пространство на объемы (чанки) произвольного размера, тем самым мы получаем область пространства, в которую входит координата точки. Следующим шагом, поскольку мы имеем наиболее подходящий блок, происходит размещение точки в октодерево, принадлежащее подходящему блоку. Это происходит благодаря рекурсивной функции, которая делит пространство пополам, и проверяет, в какой половине оказывается точка. Путем деления пространства, мы получаем уровни октодерева, рекурсивное деление происходит, пока пространство не будет наиболее полно совпадать с положением точки. Дойдя до самого низкого уровня, мы проверяем, имеется ли в данном регионе выделенная память, и если нет, то мы размечаем регион памяти, и помещаем туда точку.

Таким образом, был реализован алгоритм размещения точек, и один из методов шумоподавления - при заполнении блока, мы не заполняем уже заполненную точку, и таким образом, производим вторичную фильтрацию от шума.

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

Поскольку данные проблемы являются достаточно серьезными, мы начали разработку алгоритма для увеличения разрешения карты глубины. Изначально, разрешение карты глубины LIDAR составляет 256×192 пикселей, и для того, чтобы иметь возможность совмещать цветное изображение и карту глубины, мы увеличиваем карту глубины методом соседних пикселей до разрешения 640×480. Данное разрешение является оптимальным, поскольку позволяет сохранить баланс между качеством картинки и количеством данных, содержащихся в ней. Очевидно, что метод соседних пикселей не справляется с предоставлением карте глубины достаточного качества, поэтому мы начали изыскания для улучшения положения.

Нами был осуществлен анализ существующих решений для увеличения изображения. Ранее, мы обрабатывали изображения вручную, с помощью программы Converseen. Процесс выглядел так:

Загрузка карт глубины в Converseen

Указываем параметры - формат и итоговое разрешение изображений

Запускаем конвертацию

Несмотря на простоту процесса, Converseen не давал требуемой гибкости в настройках методов увеличения изображения, и требовал ручной обработки, что в итоге на тестировании привело к неудовлетворительным результатам и замедляло процесс подготовки. Также, Converseen интерполировал края контрастных участков на изображении, что в итоге давало на сканировании скругленную, не совпадающую с реальным объектом геометрию.

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

Сначала, мы рассматривали OpenCV в качестве поставщика методов увеличения изображения. Однако, поскольку для использования OpenCV требовался wrapper, который не включал в себя необходимые нам методы, этот вариант был отклонен.

Следующим, мы рассматривали встроенные в.NET средства увеличения изображения. Эти средства предоставлялись внутри именного пространства System.Drawing. Этот метод не подошел нам, поскольку на практике, работа этого варианта оказалась весьма медленной, и предоставляла ограниченный набор инструментов.

Наконец, мы рассматривали библиотеку Magicklmage, подключенную с помощью wrapper для языка С#, а именно метод Magicklmage.Scale(), который усредняет среднее значение пикселя с учетом соседних, образуя, таким образом, итоговое интерполированное изображение.

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

Механизм отрисовки трехмерной модели в реальном времени

Мы спроектировали и создали важные фрагменты системы - декодирование данных и их визуализацию, после чего приступили к визуализации в реальном времени.

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

Запустив эмулятор потока в реальном времени с отключенным декодированием точек, мы получили траекторию, совпадающую с реальным перемещением устройства, во время записи датасета. Это подтвердило нашу гипотезу о синхронизации положений с помощью SLAM. Измерения отрезков полученной траектории на сцене соответствовали реальным размерам объекта в метрах.

Получив подтверждение о работоспособности эмулятора потока, и его механики эмуляции перемещения камеры устройства, мы приступили к обработке данных в реальном времени. Первоначально, мы отрисовывали VFX Graph каждые 500 фреймов, в результате чего получили результат изображенный на фиг.10.

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

Удовлетворенные данными результатами, мы уменьшали промежуток кадров, пока в результате оптимизаций алгоритмов, не стали обрабатывать каждый фрейм.

Разработка прототипа визуализации перемещения пользователя в физическом пространстве

После реализации механизма отрисовки трехмерной модели в реальном времени, было решено добавить визуализацию перемещений пользователя в реальном мире, на виртуальной сцене.

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

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

Line Renderer входит в состав стандартных компонентов движка Unity, и предназначен для отрисовки линий. Данный компонент содержит в себе:

Настройку положения и значения толщины промежуточных точек

Настройку материала линии

Настройка положения и толщины промежуточных точек позволяет создавать сложные формы, путем создания записи о промежуточной точке, с указанием координаты положения данной точки. Принцип действия схож с созданием кривых Безье, однако, в отличии от кривой Безье, Line Renderer не сглаживает траекторию, каждая промежуточная точка соединяется по прямой.

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

Line Renderer был выбран в качестве инструмента визуализации, поскольку подходил по следующим критериям:

- низкие требования к ресурсам,

- возможность гибкой настройки,

- возможность создавать промежуточные точки, при изменении траектории.

Далее, для работы с Line Renderer, был создан скрипт под названием CameraTrajectoryRenderer, управляющий созданием промежуточных значений линии. Алгоритм работы данного скрипта, следующий:

При инициализации, скрипт подписывает процедуру обновления линии на событие обновления линии.

Метод обновления линии проверяет, что значение текущего кадра кратно 50, после чего внедряет в компонент Line Renderer новую промежуточную точку, под порядковым номером Index, и с координатами положения, полученными от текущего значения выборки датасета. Затем, порядковый номер Index инкрементируется, после чего процесс повторяется при срабатывании события.

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

Далее, для получения визуальной информации о текущем угле поворота камеры, было решено привязать к объекту камеры трехмерную модель, схематически изображающую человека. Эта модель имеет усредненную высоту взрослого человека (1 м 80 см), и схематически обозначенное положение глаз. Положение модели привязано к положению камеры, где центром модели являются схематические «глаза».

Таким образом, мы смогли получить информацию, о том, в какую сторону смотрит виртуальная камера, в контексте сцены.

Разработка функционала клиент-серверного взаимодействия, между визуализированным пространством и реальным миром

Имея готовый инструментарий для вычисления и визуализации модели внутри виртуальной сцены, следующим шагом стало добавление взаимодействия клиента с сервером, в рамках задачи создания технологического решения для осуществления связи и коллаборативной работы нового поколения.

Поскольку такой шаг требует наличия инструментов взаимодействия, а не только визуализации, нами был добавлен следующий функционал:

Механизмы сохранения визуализированной модели

Одним из важных критериев полезности нашего технологического комплекса, является возможность создания, сохранения, загрузки и обработки информации. Для этого, нами были созданы механизмы сохранения полученного в результате сканирования облака точек.

Во-первых, был создан механизм сохранения полученного облака в формат PLY. Данный формат является стандартом хранения облаков точек и платформонезависимых 3д моделей, а также не требует для работы проприетарных модулей.

Был создан скрипт, который имел следующую структуру:

- ссылка на текущий, действующий, скрипт управления реконструкцией,

- переменная, отвечающая за имя сохраняемого файла,

- переменная, отвечающая за системный путь сохраняемого файла,

- переменная, отвечающая за фактор масштабирования целевого облака точек,

- метод, отвечающий за сохранение облака точек, в текстовом формате,

- метод, отвечающий за сохранение облака точек, в бинарном формате.

Первоначально, была реализована схема сохранения файла в текстовом формате, в кодировке ASCII 1.0. Это было необходимо, поскольку бинарный формат сохраняет данные в виде не читаемым человеком, а нам было необходимо отследить аномалии и ошибки, возникающие при сохранении облака точек. Была изучена структура файла PLY, и установлено, что файл PLY состоит из ряда заголовочных данных, после которых следует массив, описывающий строение 3д модели.

В метод были добавлены следующие заголовки:

Строка "ply", которая означает что данный файл имеет формат PLY

Строка «format ascii 1.0», означающая кодировку целевого файла

Строка «element vertex» с добавлением количества точек, уже просчитанных нашей системой реконструкции. Эта строка позволяет сторонним приложениям ожидать определенное количество структурных элементов 3д-сетки

Далее следует ряд свойств, описывающих структуру массива. Эти свойства - координаты X, Y, Z, а также цвет, в формате R, G, B.

Последним заголовком является строка «end_header», обозначающая переход к массиву структуры.

Далее, следует структура 3д-сетки в формате:

Координата X, координата Y, координата Z, значение R, значение G, значение В

Данные заполняются в цикле, размером с количество просчитанных точек. Заполнение координат происходит по формуле:

Где - значение координаты по одной из осей,

коэффициент сдвига по одной из осей, D - коэффициент фактора масштабирования

После заполнения координатной информацией, происходит заполнение параметров цвета точки. Для соответствия стандартам цвета формата PLY, 32-битное значение цвета, полученное из цветного кадра, переводится в однобайтовое, поканально, после чего записывается. Для удобства пользователя, ведется отсчет времени, затраченного на сохранение.

Алгоритм сохранения модели через текстовый формат показал свою работоспособность, облако точек, состоящее из 11 744 136 вершин, сохранилось за 33.4 секунды, занимая на диске 285 мегабайт.

Однако в силу того, что в текстовом виде, информация занимает больше места, было решено реализовать механизм сохранения файла в бинарном формате. Алгоритм данного механизма идентичен механизму сохранения в текстовом виде, с той разницей, что для бинарного сохранения, значения предварительно переводились в двоичный вид. При тестировании готового механизма, схожий объем данных сохранился за схожее время, но занимал на диске приблизительно 140 мегабайт, что вдвое меньше, чем при текстовом формате.

Далее, был реализован механизм сохранения отсканированного облака точек для последующей визуализации внутри нашего решения.

Имея массив индексов октодерева, мы записываем его в бинарный файл, в формате читаемым нашим решением. Данный метод сохранения позволяет нам продолжать работу с отсканированным ранее пространством, например, продолжить реконструкционное сканирование. Также, поскольку данный метод работает напрямую с форматом данных, используемым внутри механизмов приложения, мы исключаем возможность внесения ошибок интерпретации. Минусом данного метода является невозможность работы с сохраненными данными в сторонних приложениях.

Далее, был реализован механизм измерения расстояний на отсканированном облаке точек. Данный механизм был реализован для того, чтобы иметь возможность сверить значение показаний размера, относительно реальных объектов. Учитывая, что наше приложение предполагается для использования в строительной сфере, механика измерения расстояний является неотъемлимой, для данного направления.

Механизм измерения был реализован благодаря использованию структуры октодеревьев для хранения координат точек, он работает следующим образом:

Создается итеративная репроекция октодерева, заполняемая компонентом Box Collider.

С помощью механизма Raycast, мы ищем наименьший уровень октодерева, содержащий точки.

Создается итеративная репроекция для каждой точки внутри полученного чанка, заполняемая компонентом Box Collider.

С помощью функционала механизма Raycast, мы получаем координату столкновения луча с искомой точкой.

Этот механизм срабатывает дважды, сначала пользователь размещает первую точку отрезка измерения, затем размещает вторую точку. Имея две координаты в пространстве, вычисляется расстояние между ними, с помощью функции Vector3.Distance, результат графически отображается на отрисованном отрезке.

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

В качестве протокола передачи видеопотока, нами был выбрано решение Agora. В первую очередь были написаны реализации TCP сокета для серверной части, и приложения на телефон. ТСР-сокет, внутри нашего решения, отвечает за передачу событий и данных. Поскольку, мы хотим встроить возможность создавать в серверном приложении метки, которые затем увидит пользователь на портативном устройстве, нам необходимо иметь систему событий, которые бы отправлялись на удаленное устройство, интерпретируясь портативным решением как «создать объект метки», или «удалить объект метки». Вместе с событием создания\удаления, нам необходимо передавать текущую координату метки, на которой необходимо поместить метку. Таким образом, ТСР-стэк на сервере, в режиме реального времени отправляет пакет данных следующего вида:

(имя метки), (создание\удаление\обновление), (координаты), (угол поворота)

Этот пакет принимается и интерпретируется алгоритмом работы внутри портативного приложения. Как уже было описано ранее, координаты внутри реального мира, и координаты на виртуальной сцене совпадают, поэтому мы отправляем координаты согласно расположению пользователем объекта на виртуальной сцене. Имя метки необходимо для того, чтобы алгоритм имел ссылку на конкретную метку (если она уже есть), либо для создания новой метки с возможностью ссылки на нее. Событие определяет операцию, которую необходимо выполнить над меткой - в случае создания мы размещаем метку, в случае удаления мы удаляем метку, в случае обновления мы обновляем координаты метки. Далее идут координаты и углы поворота, которые применяются к объекту метки на стороне удаленного приложения.

Agora используется для передачи потока видеокадров с цветной камеры и камеры глубины. Эти кадры поступают в систему реконструкции, и используются согласно описанным выше алгоритмам. Через ТСР-сокет, устройство отправляет параметры камеры (положение, вращение, параметры матрицы) на сервер, и эти данные в дальнейшем используются как описано выше.

При активации инструмента «Метка» на сервере, от пользователя требуется сделать клик мышью на реконструированной модели, поместив метку туда, где это необходимо. Далее, механизм отправляет через ТСР-сокет строку, содержащее событие создания новой метки под определенным именем, и с координатами, соответствующими положению клика. Эта строка принимается устройством, и обрабатывается, создавая метку с определенным именем.

Пользователь также может отредактировать положение уже размещенной метки. Для этого, первым кликом выбирается метка, а вторым кликом определяется ее новое положение. После второго клика, ТСР-сокет отправляет событие обновления метки под именем, полученным после выбора метки. Это событие принимается устройством, и интерпретируется как изменение положения выбранной метки, задавая ей новые координаты.

Помимо создания и обновления, пользователь может удалить метку. Для этого нужно выбрать уже размещенную метку, после чего нажать на кнопку удаления. ТСР-сокет отправляет событие удаления, и имя выбранной метки. Устройство принимает данное событие и производит удаление данной метки.

Тестирование прототипа системы

Имея готовую версию, мы приступили к тестированию.

Сверка измерений между реальным миром и реконструкцией

Нами был выбран полигон в лице лестничной площадки. Также, в реальном мире, была размещена линейка длиной 30 сантиметров. В результате реконструкции, мы измерили виртуальным инструментом длину линейки, и получили в результате 30 сантиметров с погрешностями меньше одной тысячной метра см. фиг. 12.

По итогам проделанных работ нам удалось подтвердить все стартовые гипотезы. Мы доказали, что возможна реализация системы точной трехмерной реконструкции в реальном времени с использование LIDAR низкого разрешения, который размещен в устройствах семейства Iphone.

При этом была решена значительная проблема - устройство динамически перемещается в пространстве и каждый кадр требуется вычислять его точную позицию для реконструкции. Решение данной проблемы позволило нам создать инструмент, позволяющий получить трехмерную копию любого объекта или помещения без наличия дорогостоящего оборудования или специфических навыков в фотограмметрии или пользовании промышленными сканерами. Более того в процессе реализации решения мы открыли для себя новые подходы к построению облаков точек и работы с этими данными, это позволило нам создать возможность регуляции разрешения итогового скана. Теперь мы можем также подстраивать точность под различные нужды и вычислительные возможности конечных устройств.

Созданное решение не имеет аналогов по степени точности и возможности работы в реальном времени. Мы превосходим их как в плане скорости, так и в плане точности.

Уже сейчас понятны перспективы и новые задачи – возможно, на основе существующего решения как построение точного меша (3D модели), так и с использованием ИИ превращать созданные облака точек в 2D или 3D планы для архитектурных программ.

Изобретение относится к области вычислительной техники, а именно к моделированию трехмерного пространства. Технический результат направлен на повышение точности построения трехмерных моделей пространства. Система для построения модели трехмерного пространства, содержащая устройство захвата изображения, перемещаемое в трехмерном пространстве, интерфейс для получения изображений трехмерного пространства и систему моделирования трехмерного пространства, при этом устройство захвата изображения выполнено в виде телефона на базе IOS с LIDAR, а перед построением трехмерного пространства осуществляют калибровку оптической части, камера устройства захвата изображения для каждого кадра видеоизображения одновременно захватывает данные цвета в формате RGB, данные глубины, IMU данные и данные одометрии, а система моделирования трехмерного пространства переводит данные цвета в формате RGB и данные глубины в матрицу пикселей, осуществляет вычисление точной позиции для каждого кадра, полученного перемещающимся в пространстве телефоном для последующей реконструкции трехмерного пространства. 1 з.п. ф-лы, 12 ил.

1. Система для построения модели трехмерного пространства, содержащая:

- устройство захвата изображения, перемещаемое в трехмерном пространстве, для получения изображения трехмерного пространства во времени,

- интерфейс для получения изображений трехмерного пространства, получающий данные изображений от устройства захвата изображения, и

- систему моделирования трехмерного пространства, обрабатывающую данные изображений трехмерного пространства, полученных устройством захвата изображения во времени,

отличающаяся тем, что

устройство захвата изображения выполнено в виде телефона на базе IOS с LIDAR,

перед построением трехмерного пространства осуществляют калибровку оптической части

камеры и линзы устройства захвата изображения,

камера устройства захвата изображения для каждого кадра видеоизображения одновременно захватывает данные цвета в формате RGB, данные глубины, IMU данные и данные одометрии,

а система моделирования трехмерного пространства переводит данные цвета в формате RGB и данные глубины в матрицу пикселей, каждому элементу которой присваивается значение положения, опираясь на значения глубины, и индекса элемента внутри матрицы, после этого полученные координаты точек распределяются по виртуальной сцене, опираясь на данные обработанного элемента, а также на данные IMU и одометрии, во время распределения точек на сцене, создается структура октодерево, служащая для хранения точек в пространстве, с возможностью быстрого доступа к конкретным точкам, затем, на основе заполненного октодерева, создаются визуализационные элементы, отображающие цвет и положение точек, и по полученным данным:

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

2. Система по п. 1 формулы, отличающаяся тем, что при калибровке оптической части камеры и линзы устройства захвата изображения вычисляют параметры матрицы и линзы для определения искажений попадающего света.