Как стать автором
Обновить

Как мы создали прототип робота-мерчандайзера и что дальше

Время на прочтение8 мин
Количество просмотров3.5K


Коронавирус продолжает свое смертоносное распространение по всему миру и по нашей стране. Мы работаем из дома уже почти два месяца, как и все IT-шники по всему миру и, с одной стороны, все больше и больше грустим по нашему старому доброму openspace-у и возможности обсуждать все задачи и проблемы в живую, а не по безумно полезному, но все-таки бездушному zoom-у (мы к сожалению не успели взять калифорнийскую ламу в аренду на все наши meet-up'ы :)). С другой стороны мы все больше и больше задумываемся об автоматизации и роботизации всех процессов, в том числе и процессов создания тех аналитических данных, с которыми работаем мы и наша система.

Если говорить более детально, то мы вспоминаем нашего первого робота-мерчандайзера, которого мы сделали в виде прототипа 2 года назад и все больше думаем (и уже не только думаем!) над второй версией, которую можно будет запустить в промышленное производство и эксплуатацию.

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

Немного предыстории: наша компания (ShelfMatch Robotics) начала заниматься автоматизацией мерчандайзинга примерно 5 лет назад. Автоматизация в данном случае означает, что мы тем или иным образом получаем фотографии товарных полок в магазинах (в аптеках, на заправках и т.д.), сделанные мерчандайзерами, распознаем все товары на них и выдаем необходимую клиентам аналитику.

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

Вторая, не менее важна причина, по которой автоматизация аналитики внутри магазина имеет смысл, заключается в том, что магазины ежесекундно теряют деньги на различных ошибках выкладки, таких как out-of-stock или не соблюдение планограммы. И деньги они теряют немалые, по оценкам аналитиков из компании bossa nova robotics out-of-stock приводят к потере выручки в 0.5 трлн. долларов в год во всем мире. Вообще, для магазина внедрение «дополнительных глаз», которые будут сканировать все пространство торгового зала и склада является крайне важной и плохо реализованной на данный момент.

Нам в тот момент сразу пришло в голову другое, более интересное на наш взгляд решение — почему бы не перепоручить делать фотографии кому-то, кто по своей сути делает все ВСЕГДА точно по инструкции и почти никогда не ошибается (при учете точной и качественной инструкции). Наверное вы уже догадались, что речи идет о роботе-мерчандайзеры.

Помню мы тогда рассматривали все самые безумные идеи, начиная от роботов-дронов, которые будут летать по магазину и заканчивая роботами-автоматическими камерами, которые будут ездить по моно-рельсам по потолку магазина. Первое, что мы увидели и что реально нас вдохновило — это роботы компании bossa nova robotics, которые рассекают по американским магазинам (например по Walmart'у), предоставляя покупателям возможность немного прикоснуться к недалекому будущему. В итоге мы все же пришли к тому, что нужно создавать традиционного робота на «тележке-шасси» типа робота-пылесоса и оснащать его всевозможными камерами и датчиками, необходимыми для навигации и фотографирования полок.

Постановка задачи:


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

Первая версия робота была названа в честь командира репликантов из старого доброго, надеюсь всем хороши знакомого и любимого фильма Ридли Скотта Blade Runner — Roy (так мы его и будем дальше называть).

Из чего состоял Roy


Шасси:

  • швейцарские моторчики maxon — швейцарские потому что их китайские дешевые товарищи почему-то очень быстро перегорали в наших руках
  • 4 колеса по типу omni-wheels — на тот момент нам казалось, что нам нужны именно омни-колеса для того, чтобы робот мог быстро и без лишних движений изменять направление движения
  • основание, выполненное из алюминия и пластика
  • контроллер моторов
  • аккумулятор
  • NUC с ROS поверх Ubuntu внутри для навигации
  • Лидар RPLidar A2 для построения карты, навигации и локализации

Туловище (башня):

  • каркас из алюминиевых профилей
  • пластиковая отделка
  • пластиковые крепления для камер, напечатанные на 3D-принтере
  • 4 USB-Камеры Bustler
  • NUC для фотографирования и отправки фото на сервер через WiFi
  • 3D-камера глубины типа Intel IntelliVision, которую нам так и не удалось подключить
  • ЖК-экран для отладки и вывода сервисной и рекламной информации

Собрать тележку и туловище не составило особого труда, мы потратили на это несколько месяцев. В сборке и настройке тележки нам помогали несколько бывших сотрудников ЦНИИ-РТК.

Как все это работало и что из этого получилось


Всем, кто хорошо знаком с работой в ROS можно пропустить эту главу, они вряд ли найдут в ней что-то уникальное или оригинальное, тем же кто «не в теме» будет интересно. Расскажу сразу, как все это происходило в реальном магазине (мы тогда тестировались в еще живом и здравствующем SPARе в Купчино):

  1. Мы приезжаем в магазин, находим нужный нам стеллаж (прототип проверялся на товарной категории Чай, потом отфотогрфировали еще 4-5 товарных категорий), находим незанятую розетку (это, кстати, было довольно непросто), и распаковываем весь скарб.
  2. Собираем Roy (он перевозился по отдельности — тело отдельно, шасси отдельно, влезал в самую обычную легковушку).

  3. Подключаем здоровую WiFi-антенну для стабильного и мощного сигнала.
  4. Загружаем ноутбук с Ubuntu+ROS внутри для удаленного управления всеми процессами, подключаем Game-Pad для построения карты.
  5. Стартуем все модули: ROS, Teleop (нужно для управления роботом), Gmapping (нужно для построения карты), Rviz (нужно для визуализации карты и позиции Roy).
  6. Начинаем построение карты — нужно несколько раз проехать, управляя Roy с джойстика с минимальной скоростью по всему видимому глазом пространству магазина и убедиться, что карта каждый раз получается одна и та же (одна из основных проблем у нас как раз была в том, что карта часто выходила плохого качеств и Roy на ней «путался» и «терялся»).
  7. После того, как карта построена, сохраняем ее, забиваем в скрипт координаты точек съемки (начало стеллажа 1 — точка «А», конец стеллажа 1 — точка «Б», поворот на 90 градусов, конец стеллажа 2 — точка «С». Мы в основном снимали стеллаж в форме буквы «Г»)

Далее запускаем скрипт фотографирования (тут все уже без gamepad, настоящая «магия»):

  1. Roy выходит на заданную позицию — точка «А».
  2. Roy разворачивается правильным образом (камерами к полке), градусы разворота также задаются в скрипте.
  3. Roy начинает медленно ехать вдоль стеллажа, несколько раз в секунду делая съемку каждой камерой и сохраняя фото на диск NUC. При этом камеры синхронизированы и делают фото одновременно.
  4. В этот же момент другой скрипт начинает асинхронно отправлять фото по WiFi на сервер.
  5. Roy проезжает вдоль одного стеллаж (точка «Б»), останавливает камеры на время поворота, делает поворот на 90 градусов, опять включает камеры.
  6. Проезжает вдоль 2го стеллажа в точку «С».
  7. Выключает камеры.
  8. Возвращается на исходную позицию (точка «А»).

Дальше работа уже непосредственно на сервере:

  1. В тот момент, когда все фото переданы на сервер, на сервере начинается склейка фотографий и процесс распознавания товаров на полке
  2. Когда все процессы завершены, в веб-интерфейсе появляются стеллажи с товарами с нанесенной на них разметкой товаров + вся необходимая аналитика (доля товаров на полке, out-of-stock, сравнение с планограммой и т.д.)



Подводя итоги, что нам удалось выяснить


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

Недостатки Roy, которые были выявлены после создания и испытания прототипа


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

  • карта не всегда строилась точно
  • очень часто строилась плохо с 1го или 2го раза, приходилось по полчаса ездить для построения карты
  • Roy иногда «терялся» даже на хорошей карте (это сразу было понятно так как он начинал крутиться на одном месте и дальше никуда не ехал, приходилось включать геймпад и переходить на ручное управление)

У нас были такие гипотезы по поводу этой проблемы:

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

Другие недостатки:
  • на выходе мы получали огромные объемы данных — это довольно долго для передачи по сети и для обработки (склейка+распознавание товаров), обработка одного стеллажа занимала у нас от 30 до 60 минут при том, что Roy проезжал свой путь минуты за 2
  • камеры давали сферическое искажение (эффект рыбьего глаза), что затрудняло обучение детектора (точнее использование обученного на других камерах детектора) и ухудшало качество распознавания товаров
  • Roy не был оснащен оборудованием для того, чтобы объехать весь магазин, нужна была какая-то привязка к глобальной карте (QR-коды стеллажей, bluetooth-маячки и т.д.)
  • в процессе движения тело(стойка) иногда (точнее обычно) начинали прицессировать вдоль горизонтальной оси, причем прецессия иногда была довольно значительной, что плохо отражалось на качестве фотографий
  • не было предусмотрено подсветки во время фотографирования (точнее мы взяли светодиодную ленту, но вскоре от нее отказались так как она обладала эффектом мерцания, не заметным глазом, но очень заметным для камер)
  • все запчасти (камеры и моторчики, лидар) были слишком дорогими (в сумме весь робот обошелся нам более чем в 10К долларов)
  • Roy не обладал привлекательным, промышленным дизайном, он был хорош для прототипа, но не для реальной работы (много не хватало, многое было сделано «на коленке»)
  • запчасти из которых был собран Roy не были всегда легко доступы (моторчиков и камер можно было ждать по 3-4 месяца), то есть они не подходили для масштабирования устройства

Задача на создание 2й версии робота(Zhora или Leon)


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

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

  • таргетированная реклама на ЖК-экранах: из серии вижу женщину с младенцем — предлагаю памперсы, вижу пенсионеров — предлагаю товары по акциям;
  • помощь покупателям в поиске товаров
  • мониторинг магазинных воров по базе лиц
  • инвентаризация склада, помощь отделу логистики в планировании закупок
  • и т.д. вплоть до выставления товаров на полки

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

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

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

P.P.S. Также пишите, если тема интересна, постараюсь более подробно рассказать о второй части нашего проекта.
Теги:
Хабы:
Всего голосов 14: ↑14 и ↓0+14
Комментарии16

Публикации

Истории

Ближайшие события

19 августа – 20 октября
RuCode.Финал. Чемпионат по алгоритмическому программированию и ИИ
МоскваНижний НовгородЕкатеринбургСтавропольНовосибрискКалининградПермьВладивостокЧитаКраснорскТомскИжевскПетрозаводскКазаньКурскТюменьВолгоградУфаМурманскБишкекСочиУльяновскСаратовИркутскДолгопрудныйОнлайн
24 – 25 октября
One Day Offer для AQA Engineer и Developers
Онлайн
25 октября
Конференция по росту продуктов EGC’24
МоскваОнлайн
26 октября
ProIT Network Fest
Санкт-Петербург
7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань