В трекании меток есть два основных подхода:
1. Трекать специальные изображения. В этом случае, на метки накладывается куча ограничений, но и распознавание изображений происходит по алгоритмам, учитывающим эти особенности
2. Трекать потенциально любые изображения. В этом случае, изображение анализируется и разбивается на набор "особенностей". Под особенностью понимают контрастные острые углы. Чем контрастнее цвет и чем прямее угол, тем лучше.
В MagicLeap используется второй подход. И тут мы встречаем первую проблему. Казалось бы, QR-код идеален. Он состоит из максимально контрастных квадратов с максимально прямыми углами. Но есть "но". Они генерируются по специальным правилам, содержат значительную регулярность. Этот паттерн из-за повторяемости элементов анализировать и трекать для техники сложнее. Тут можно было бы привлечь сторонние библиотеки компьютерного зрения, но это сильно усложняет процесс разработки. А SDK типа Vuforia и другие просто не поддерживают MagicLeap, то ли в силу его новизны, то ли потому что перспективы устройства туманные.
Помимо проблемы паттернов, есть проблема, связанная с плохим освещение. Освещение сильно влияет на контраст изображения и, соответственно, возможность его трекать. MagicLeap имеет нормальную камеру, но в отличие от тех же телефонов у него нет подсветки, которая была бы очень кстати для такой задачи. С другой стороны, MagicLeap рассчитан на дистанции побольше, чем телефон. Значит и фонарик нужен побольше... Проще комнату поменять. Это точно приводит к плохому распознаванию, "улетанию" и прочим проблемам трекинга на MagicLeap.
В итоге мы поменяли метки на менее повторяеммые и трекаться они стали лучше. Добавили освещения с телефонов. Но этого всего не хватило. Поменять окружение было проблематично, может быть это помогло. Также, возможно, проблема была и в алгоритмах сглаживания позиции меток в очках MagicLeap, потому что результат сглаживания был неудовлетворительный. Изображение дрожало иногда. Из-за чего мы в итоге применили линейное сглаживание. Могли бы докрутить и фильтр Калмана, он в целом лучше подходит для таких задач из-за того, что как раз нелинейный. Но в ситуации с заказчиком нужно было решение, работающее сейчас. В итоге сглаживанием заказчик остался доволен.
