Давно ничего не писал на Хабре. К сожалению, не возникало одновременно сложных и интересных задач, о которых хотелось бы рассказать. А так как читатель Хабра человек, как правило, искушённый, то лишний раз "стыдиться" не хотелось.

Однако, с недавних пор руковожу отделом компьютерного зрения в DANNIE gr., где мы разрабатываем для наших клиентов различные EDGE ML/AI устройства. EDGE – это когда вся «математика» алгоритмов обработки изображения делается на устройстве, а не отправляется на сервер для последующей обработки.

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

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

Поехали!


Как я уже написал ранее, мы разрабатываем устройства компьютерного зрения с математикой «на борту» (далее EDGE ML/AI устройства).

В качестве аппаратной базы был выбран SoC от китайского производителя Ingenic (специализируются на чипах с аппаратными NPU). Сам чип имеет название T40 – не буду сейчас на нём останавливаться, работа с ним в части ML/AI это тема отдельной статьи, там тоже много «весёлого», «интересного» и «неожиданного». Но не прошло каких-то *грустно улыбаюсь* 4 месяца, и мы полностью овладели инструментарием обучения, трансформации и имплементации алгоритмов (да, там свой собственный ToolKit под это) для нашего SoC. Начинается самое интересное.

DevKit Ingenic T40
DevKit Ingenic T40

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

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

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

Да, напомню тем, кто знал, и тем, кто догадывался, но не знал. Выход нейронной сети всегда вероятность. Сетка никогда не скажет вам, что вы человек на 100%, скорее всего это будет так: человек – 96%, куница – 3%, ВАЗ 2109 – 1%. Утрирую, но посыл понятен.

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

Но мы сразу столкнулись с набором локальных проблем:

  1. Пешеходные переходы имеют разный вид, разное качество нанесения, разные формы и, что самое неприятное, камера «смотрит» на них под разными углами.

  2. Тень. Оказалось, что на детекцию подобных объектов падение тени влияет критически.

  3. Полосатая структуры очень распространена в мире, нужно уметь отличать.

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

Такие одинаковые и всё-таки разные

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

Пешеходные переходы
Пешеходные переходы

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

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

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

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

Тень

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

Пример "трудного" перехода
Пример "трудного" перехода

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

Существенно лучший результат получился, когда мы ввели дополнительный детектируемый класс «shadow». То есть на выходе нейросети мы имели результат детектирования по двум классам: shadow и crosswalk. Это решение существенно улучшило качество срабатывания, не сильно затронув вычислительные ресурсы.

Полосы

Вполне очевидно, что визуальная структура пешеходного перехода — это повторяющаяся двухцветная последовательность, проще говоря – полосы.

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

	Примеры ложных срабатываний
Примеры ложных срабатываний

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

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

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


На этом очевидном примере я попытался рассказать об интересных буднях разработчиков EDGE ML/AI устройств компьютерного зрения.

Попытался быть максимально поверхностным в области техники, не описывал наш технологически стек и т. д. Всё это с удовольствием готов обсудить в комментариях, если кому-то будет интересно.

Ниже два видео работы нашего алгоритма в «полевых условиях» - улицы Москвы (1 – видео сенсором выступает камера смартфона, 2 – полностью работа DevKit’а со штатным видео сенсором), там ещё добавлен один класс детектирования – автомобили, но это уже совсем другая история.

Всем спасибо за внимание и до встречи на Хабре!

Комментарии (4)


  1. ZlodeiBaal
    28.03.2022 00:46
    +1

    С удовольствием бы почитал про особенности Ingenic T40

    Обычно исходя из особенностей платформ можно заранее понять где что работать будет/не будет. Например почему не использовать более мощную сетку детекции? Какие ограничения на сети/на fps. Почему не использовать сегментацию/детекции с поворотом (переход все же плохо описывается прямоугольным BoundingBox). И.т.д., и.т.п.

    Ещё отмечу, что у вас не понятна постановка задачи из написанного. В общем случае переход искать сложно. Скорее всего у вас авторегистраторы? Это очень сильно сжимает домен данных, можно более точно нацелиться на то как переход выглядит для ракурсов с дороги. Скорее всего у вас машина не будет ехать перпендикулярно переходу.
    End-to-end тесты говорят про качество алгоритма сильно больше чем метрики.


    1. justakoma Автор
      28.03.2022 09:03

      Думаю, мы с командой как-нибудь доберёмся до описания особенностей SoC. Действительно интересный топик. Главный посыл будет, что выбор должен быть осознанным компромиссом между стоимостью конечного девайса в производстве и трат на R&D.

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

      Тут да, к сожалению, полную задачку раскрыть не можем по причине NDA. Действительно, это регистратор, но не совсем в классическом понимании. Как раз всеми силами готовимся к End-to-end.

      Спасибо за вопросы!


  1. Alex_ME
    28.03.2022 14:11

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

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

    Я ненастоящий сварщик, задам автору статьи (и комментаторам) вопрос дилетанта, на который, я понимаю, нельзя дать краткий и однозначный ответ: как вообще настоящие ML/AI инженеры/исследователи решают прикладные задачи, создают архитектуру сетей итп? Если почитать какой-нибудь учебник, гайды, курсы итп по ML, можно встретить (в разных пропорциях): матстат и прочий матан в основе, классы решаемых задач, основные существующие архитектуры, способы решать различные проблемы обучения (нормализация итп итд).

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


    1. justakoma Автор
      28.03.2022 16:55
      +1

      Наверное, за весь мир ML/AI инженерии не скажу, везде есть свои особенности, но в наших задачах (EDGE устройства) важно чётко обговорить бизнес-задачу клиента.

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

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

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

      Надеюсь, смог "на пальцах" ответить.

      Спасибо! =)