Сказ о том, как на хакатоне AR SDK искали, да свой собрали

В тридевятом царстве в тридесятом государстве… Свой рассказ о хакатоне в Wrike я начал так, потому что Хакатон — он как сказка: собираются энтузиасты, чтобы дать жизнь своим идеям. Выпускается идея, как стрела сказочная, а дальше может и на боярский двор упасть, а может и в болоте повседневности сгинуть. И, как в сказке, это всегда захватывающе. Не просто ведь за очень короткое время и команду собрать, и из идеи продукт сделать, да еще и показать его так, чтобы люд честной удивить.

А если серьезно, то хочется поделится опытом участия в хакатоне, где мы свою augmented reality (AR) разработали. Расскажу про то, как мы пытались найти готовую AR SDK под нашу задачу, но не смогли. В итоге решили сами написать AR и получилось.

Присказка

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

Хакатоны зачастую проводятся конкретными организациями, и это работает на HR бренд компании. Цели при этом могут быть разные: рассказ о компании или продукте, найм разной степени агрессивности, организация тематического сообщества, поиск свежих идей (несмотря на армии собственных продуктологов, может быть полезно получить букет идей от мечтателей с незамыленным взглядом на предметную область) и т.д.

Для участников это возможность познакомиться с компанией, ведь часто хакатон — это её отражение, и по нему можно делать выводы о внутренней кухне. Чтобы понять процессы в компании, можно смотреть на то, как она организует хакатон: какие ограничения для проектов, участвующих в хакатоне (объем задач, предметная область, технология, инструментарий и т.п.); уровень проведения мероприятия; критерии и прозрачность соревновательной части; судейство — состав и качество; какие установлены правила и методы формирования команд. В целом же, компании делятся на тех, кто проводит хакатоны (внутренние или публичные) и тех, кто нет. Мне больше нравятся те, кто проводит, т.к. это более открытые компании.

Сам я хожу на хакатоны не ради победы, а ради участия. Мне интересно:

• Попробовать новые технологии. На одном «едовом» хакатоне мы взяли Flutter, и написали приложение под ios и android. Хотя до этого никто из нас не пробовал Flutter, правда Dart мы умели.
• Познакомиться и поработать с новыми людьми, так после одного из «городских» хакатонов, я позвал соучастника хакатоновского проекта работать в свою команду на основную работу, о чем ни разу не пожалел. Хакатон — это отличный способ проверить боевого товарища в деле.
• Сделать, что-нибудь, что реально нужно мне самому. На внутреннем хакатоне запилили приложение, которое потом использовали в работе.
• Просто получить позитивные эмоции от созидания. Мне очень нравится атмосфера хакатонов!

Поэтому я с радостью участвую в хакатонах wrike (в этом году был уже третий внутренний хакатон), где мы придумываем и делаем wrike еще лучше: часть предыдущих хакатоновских проектов уже живут в нашем продукте, а некоторые находятся в бэклогах команд. Вдохновляет и масштаб, несмотря на то, что хакатон внутренний, набирается около 30 команд (больше 100 человек) — все со свежими крутыми идеями.

На хакатоне 2018 я решил попробовать работу с AR. В MVP хотелось сделать отображение задач wrike (название, статус, исполнители и т.д.) на экране мобильного телефона при наведении на графический код с зашифрованным в нём идентификатором задачи, а также добавить возможность изменения статуса и назначение / снятия задачи с себя. Идея есть, хакатон есть, за командой дело тоже не встало. В назначенный день все завертелось.

Я спросил у ясеня

Я особо не готовлюсь к хакатонам в плане настройки окружения (поиск SDK и фреймворков; установка софта; конфигурирование и т.п.), написания кода зарание и т.д., а занимаюсь только проработкой идей, фичей, обдумыванием что в каком порядке делать и т.п. Поэтому посовещались мы с командой решили, что писать будем на Java (на ней же нативно под Android пишут), и была гипотеза, что наверняка полно готовых AR библиотек. Наш план: возьмем удобную SDK, приладим к ней API Wrike, а дальше сосредоточимся на написании логики нашего приложения. Таким образом первой нашей задачей стало найти удобную Java AR SDK, которая позволяет:

• Рисовать что-нибудь на заданной виртуальной поверхности.
• Интегрироваться / уже содержит сканер динамических графических элементов (barcode, QR, и т.п.).
• Работать с низким порогом входа (мы же на хакатоне, нам надо быстро): есть демка, есть документация, есть бесплатная / триальная версия.

Выглядит как довольно простая задача. И мы начали перебирать варианты, основываясь на статьях типа "Top Augmented Reality SDK in 2018"

ARCore от Google

Сперва свои взгляды мы обратили на Google. Открыли "Быстрый старт", сделали всё по инструкции, запустили и, о чудо, всё работает: у меня на столе появляются Андроидики, которых можно еще и перемещать. Ощущение, что мы нашли «основу» для нашего приложения. Но дальше последовало разочарование, распознавание картинок работает не так, как нам надо: картинка может быть только одна, она должна быть хорошо видна, и она должна быть из базы заранее известных картинок (а у нас для каждой задачи должен быть свой уникальный маркер). И что самое печальное, это невозможность управлять фокусом, из-за чего поймать для распознавания нужное нам изображение становится непростой задачей для пользователя. Правда сейчас с фокусом проблему решили, а нам пришлось продолжить поиски. В целом Google оказался хорош, но не для нашей задачи. А еще из-за специфики работы OpenGL на OSX, мы не смогли заставить работать демку в эмуляторе и всё делали на живом телефоне.

Vuforia

Прочитали документацию, посмотрели ролики, выглядит впечатляюще. Фичей много, например, Image Targets. Решили попробовать: зарегистрировались, скачали, собрали, запустили. Demo приложение запустилось, но ни на эмуляторе, ни на живом android-e не работало. Попытка проверить любую функцию приводила к краху всего приложения. Было решено не тратить время на поиск проблемы и её починку, и перейти к следующему SDK.

Wikitude

Скачали SDK, пошли по туториалу, запустили демку. Тут куча всяких возможностей, демка сразу впечатляет, куча мини примеров, мы вдоволь наигрались (например, есть распознавание лиц), и, о чудо, в демке уже есть распознавание QR. Но проблема в том, что мы получаем то, что зашифровано в коде, но не знаем, где он расположен. Стали разбираться, как устроен сканер QR. Оказалось, что он сделан как надстройка над ZBar в виде плюсового плагина к SDK. Сперва посетила шальная мысль расчехлять gcc и допиливать плагин, чтобы он еще и координаты отдавал, но мы вовремя остановились.

И бились они 3 дня и 3 ночи

Осознав, что добрая четверть времени из отведенных суток позади, а мы все еще ищем свою SDK (были пробы и других решений, не только описанных выше, но и там тоже фиаско), решили больше не искать «серебряную пулю», а взять всё в свои руки. Созрел новый план: в качестве маркера задачи берем QR код, как простой и распространенный; для их распознавания берем ZXing, который умеет распознавать одновременно несколько кодов и помимо значения, библиотека еще отдает координаты 3 «поисковых» точек QR кода. А затем поверх считывалки кодов будем реализовать свой AR. Засучили рукава и вперед, у нас есть 3 точки, а значит при помощи аффинных преобразований можем получить всё, что нам потребуется.

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

• Изображение с камеры передаем в ZXing, получаем массив с координатами точек и значениями QR кода.
• Из 3 координат рассчитываем 4-ый угол квадрата, квадрат увеличиваем в полтора раза, чтобы перекрыть исходный QR код, и получаем основу для карточки.
• Делаем запрос в API Wrike, чтобы забрать данные о задаче.
• Рисуем карточку, благодаря аффинным преобразованиям, сохраняем все искажения (угол обзора, поворот, масштаб).

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

И я там был, мёд-пиво пил

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

Поэтому в своей презентации помимо демонстрации полученного функционала, мы призвали силу воображения и описали ситуации, в которых подобная дополненная реальность (AR очки уже скоро станут обыденностью) может улучшать жизнь тем, кто работает не за компьютером, но чья работа связана с wrike. Например, для взаимодействия между дизайнером-архитектором, занимающимся ремонтом дома, и бригадой, которая непосредственно реализует проект в самом доме.
Мне кажется мы с честью продемонстрировали наш MVP, и словили свои лучики любви. Лето закончилось, и подходит к концу пора пикников и отпусков, и мы подумываем посвятить осенние вечера развитию нашей Wrike AR.

За иллюстрации спасибо Sai Kin!

Автор: Dmitry Podkorytov

Источник