Разбираем пример автоматического магазина

Иногда на своем канале я разбираю как работают различные системы машинного зрения. Точнее, анализирую как бы я реализовал какую-нибудь интересную систему, исходя из тех проявлений что я вижу. Для меня это полезно, так как позволяет понять “а не упускаю ли я какие то подходы или технологии”. Но, возможно для кого-то будет полезно, чтобы понимать как устроены кишки какой-нибудь системы.
Сегодня мы будем препарировать “Магазин без касс” от Азбуки Вкуса. Чуть подробнее агитку можно посмотреть вот тут. А в статье разберем как он сделан с технической стороны, и как бы я его сделал с алгоритмической.

Я не буду сравнивать с другими проектами магазинов без касс. Их десятки. К ним можно отнести и Amazon Go и Пятерочку. Очевидно, что в каждом из них принципиально разные задачи решаются, разная бизнес модель, разный стек алгоритмов. Цель моего рассказа будет скорее “как понять что в кишках, и почему люди пришли к такой конфигурации в данном конкретном случае”.

Для начала посмотрим общую логику магазина:

  • Магазин имеет площадь где-то 2.5*6 метров
  • Вход в магазин через турникет, через одну точку, после демонстрации индивидуально сгенерированного QR-кода
  • Взятый с полки товар должен быть возвращен на ту же полку откуда взят

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

На потолке развешано 13 камер RealSense 435. Плюс одна обзорная камера. Я уверен на 99% что обзорная камера используется только охранниками, и не заведена в алгоритм.
Такое количество RealSense это, конечно, дикий оверкил. 435 модель имеет большой угол обзора – 86*57 градусов на датчике глубины и 70*42 на RGB камере. При высоте подвеса в ~4 метра такая камера на высоте человеческой головы (1.7 метра) будет давать площадь ~4.5*2.6 метра для датчика глубины. Учитывая, что камеры нацелены с небольшим захватом полок – это где-то трехкратное перекрытие площади. На уровне пола – ещё больше.
Зачем? Поговорим от этом чуть позже.

Кроме того, каждый тип товаров лежит в специальном контейнере, который является весами:

Всего таких весов в этом маленьком магазине ~150. И они не дублируются.

Что видят камеры?

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

На уровне пола 435 в карте глубины видит прямоугольник ~8 на 5 метров. С разрешением 1280*720 (~1.5 пикселя в сантиметре). И, RGB камера имеет прямоугольник 5.6*3 с разрешением 1920*1080 (~3.5 пикселя на сантиметр). При этом, угол подвеса камеры такой, что товары попадают в поле зрения (фото с места где стоит товар, камеры видны):

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

Так что единственное, что с этих камер видно – люди. Но люди должны быть видны хорошо:

  • Голова – достаточно хороший объект для камеры глубины
  • Можно использовать одновременно RGB и Depth составляющие

Как вы, возможно, помните, я предпочитаю для трекинга использовать связку детектор + трекер. Такой подход должен работать идеально, ведь по Depth составляющей детектор можно делать и не на базе нейронной сети (качества картинки хватает). Использование нейронной сети + Depth + RGB должно давать точность детекции >99.9. RealSense имеет достаточно высокую частоту кадров, что должно давать высокое качество трекера.

Самая сложная часть

Абсолютно понятно как сделать детектор и трекер. Что не до конца понятно – как реализовать аппаратную составляющую. RealSense 435 есть только USB-шный. А USB-разъем сам по себе нестабилен. По нашему опыту, на длинном кабеле любая USB-девайсина работающая 24*7 будет отваливаться где-то раз в месяц. Плохой коннект/наводка/не подцепился драйвер. Возможно это то почему нужны 13 камер – чтобы иметь резервирование.

Второй нетривиальной проблемой является вопрос аппаратной реализации обработки. На мой взгляд невозможно обработать 13 USB камер подключенных к единой машине. Я вижу три возможных решения:

  1. Для каждой камеры имеется своя обработка стрима. Объекты детектируются независимо, потом на единой машине производится сведение задетектированных объектов. На каждые 2-3 камеры есть своя машина, которая реализует обработку
  2. Есть машины которые принимают картинки с 3-4 соседних камер, сводящие их в единое изображение. Полученные изображения с 3-4 машин отправляется на машину где происходит сведение 3-4 полученных карт в единую.
  3. 2/3 камер не работают:)

Возможна какая-то компиляция первого и второго подхода.

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

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

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

Общая логика

Нужно понимать что трекинг в этой задаче – это еще не все. Ключевой вопрос – привязка к треку внешних событий: покупки, вход и выход.
Как вы понимаете, весы должны давать событие “взятие товара”, “возвращение товара” и что-то вроде “неправильный вес” (для контроля оператором).
Турникет должен давать события “вход” и “выход”.

По алгоритмам – есть два варианта, делать честно и делать быстро. Чтобы сделать быстро – можно привязать события к ближайшему треку. Чтобы сделать хорошо – нужно фиксировать “взятие” и “возврат” товара.
3D камера должна давать достаточно качественную картинку, чтобы это действие можно было подтвердить (руку которую человек протягивает к полке).
Без подтверждения – легко перепутать товары которые привязываются к двум рядом стоящим людям.
Но, учитывая что в моём чеке было написано “чек №1251”, а магазин работает чуть меньше года – не думаю что этот алгоритм, даже если написан, часто используется.

Операторы?

Чек приходит через минут 5-10 после покупки. Я почти уверен что это означает верификацию покупок оператором. Но не могу это гарантировать. Интересный вопрос.

Итого, мысли

С одной стороны мне понравилось. Видны явно дубовые алгоритмы. Нужен трекинг? Взяты лучшие камеры которые могут его обеспечить. Нужно перекрытие между камерами? Сделаем тройное? Весы? Поставим для каждого товара. Но:

  • Я не знаю насколько стабильно будут работать 150 весов. Не придётся ли заменять какие-то из них каждую неделю?
  • Мне кажется что 13 RealSense камер это оверкил. Нельзя ли было сделать весь трекинг на двух обычных камерах?
  • USB камеры – это технологический ужас. Я не верю что такое решение может быть масштабируемо.
  • Очевидно что при одном посетителе все будет работать в 100% случаев. А вот как система работает если покупателей много – очень интересно.

Все то же самое но в видео –

З.Ю.

В последнее время свои статьи я публикую на очень разных платформах.
И, так получилось, что единое место куда я их свожу тут – https://vk.com/cvml_team ( дублирую в https://t.me/CVML_team )