Роботы на карантине04.08.2020 12:18

Тут недавно мужики на Хабре рассказывали про Flipper и отладку на осциллографе по видеосвязи.

И это, конечно, победа вне конкурса! Но и у нас был интересный опыт отладки робота, находящегося в 2000 км от нас в лодочном гараже на норвежском побережье. Под катом рассказ о том, как мы делали зрение и правили «облачные мозги» роботам во время карантина удаленно:

Весной мы сделали прототип всей системы удаленного управления по 3D стриму и обучения роботом на двуруком YuMi и познакомились норвежской компанией, чье решение нам очень кстати для трансляции 3D потока Realsense камер — Aivero. Так что после не самого простого рабочего периода планы казались безоблачными: слетать в Италию на месяц зимы с семьей, оттуда поездить по выставкам робототехники в Европе и закончить все остановкой на пару недель в городе с прекрасными фьордами в округе — Ставенгер, где и обсудить интеграцию 3D кодеков в нашу систему и попробовать убедить Aivero собрать пару роботов вместе.

Что могло пойти не так в этом замечательном плане…

Сидя 2 недели на карантине после возвращения (не без приключений) из итальянского локдауна, пришлось сдуть пыль со своего разговорного и письменного английского и исполнять вторую часть плана уже в Zoom-е, а не в антураже фьордов.

Хотя, тут как взглянуть. Карантин заставил многих всерьез начать работать над возможными способами автоматизацией там, где человека не сложно заменить. Тем более для западных стран, в которых минимальная зарплата выше 1500 Евро, где роботизация простого ручного труда актуальна и без текущей эпидемиологической обстановки.

Подключаем разных роботов

Напомню, мы сделали обучение роботов по записям удаленного управления. Т.е. робот подключается к интернету, к нашему облаку и начинает слать 3D картинки и показания датчиков. Обратно получает команды и исполняет их. В такой логике наша задача научить ML процессор вести себя также, как оператор. 3D нужно, чтобы отрисовать оператору сцену в виртуальной реальности. Это удобно, да и ML становится намного точнее при хватании объектов, когда есть карта глубин.

По задумке, мы можем подключать разнообразных роботов к нашему облаку, но создавать их все разнообразие самим — это очень тернистый путь. Мы же фокусируемся на их мозгах, на обучении.
В итоге договорились с Aivero о создании универсального однорукого робота с 3D глазами их силами, назовем его «Юнит», а весь облачный Robotics достается делать нам.

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

Подумали пару недель, потестировали гипотезы пару месяцев и вот, что получилось (версия с Jetson AGX в основании и другой обзорной камерой, чем на заглавной):

И прожектор поближе:

Состав:

Jetson NX
2 3D камеры Realsense (одна обзорная, другая для рабочей области)
прожектор
вакуумный насос, если нужен
роборука (Eva / UR / ABB YuMi) с вакуумным или механическим захватом
интернет WiFi или проводной

Такая телескопическая стойка с вычислителем и вакуумным насосом в основании ставится рядом с рабочей областью робота, подключается к интернету (например по QR коду к WiFi), и сразу начинает решать поставленную задачу практически без настройки.

Здесь можно сразу оценить и стоимость. Самая доступная роборука Eva — 8000 Евро (в России не поставляется), а UR10 уже обойдется почти в 50 000 Евро, но тут нужно отметить, что UR заявляет значительно большую надежность, так что в долгосрочной перспективе может оказаться и не сильно дороже. Да и дешевеют они последнее время. Остальной комплект обходится еще около 2000 Евро.

ABB YuMi IRB 14050

Мы раньше имели дело с двуруким YuMi, но здесь попробовали новую версию IRB14050, которая по сути просто одна оторванная рука.

[embedded content]

Кратко, чем понравилась:

точность и механическое качество исполнения
высокая чувствительность к коллизиям и демпферы на суставах

и не понравилось:

тяжело удаленно разрешать коллизии и нештатные ситуации
малый угловой ход некоторых суставов делает траектории довольно сложными для, казалось бы, простых движений, которые для кинематики других 6-ти координатных рук не представляют сложности
малая грузоподъемность в сравнении с аналогами
дополнительно требует заливать (а порою и отлаживать) программу на своем языке программирования от ABB, которая обрабатывает команды по TCP от компьютера

И не кратко.

Здесь мы потратили больше всего времени. Рецепт, как запускать, совсем не простой:

Возьмите машину с Windows, т.к. иначе не получится установить RobotStudio от ABB.
Идем в репу https://github.com/BerkeleyAutomation/yumipy и добываем там RAPID (это язык программирования от ABB) файл для загрузки в робота (у нас одна рука, так что левая или правая подойдут одинаковые), заодно переделываем python API для однорукого YuMi IRB 14050 вместо двурукого IRB 14000.
Если хотим планирование траектории, то находим IRB14000 urdf файл описания геометрии робота и его кинематики для ROS moveit. Удаляем одну руку и корпус робота IRB14000, так и получаем IRB14050.
Забираем из планировщика ROS moveit нужную траекторию и с помощью слегка модифицированного Python API запускаем.
В случае коллизии или иных происшествий запускаем FlexPendant for OmniCore, сбрасываем состояние и визуально разрешаем проблему.

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

Eva

Кратко, чем понравилось:

Конечно, цена
API простое и лаконичное

И минусы:

нет детекции коллизий (заявлено в релизе осенью)
точность позиционирования — над ней еще нужно поработать производителю, но нам хватает

Конечно, простота управления подкупает:

pip install evasdk

и

import evasdk
eva = evasdk.Eva(host_ip, token)

with eva.lock():
    eva.control_wait_for_ready()
    eva.control_go_to([0, 0, 0, 0, 0, 0])

И роборука вжух! и исполняет.

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

И в целом, Automata (производитель Eva) большие молодцы! Надеюсь у них получится расти и развиваться на рынке робототехники и дальше, делая роботов сильно доступнее и проще, чем они есть сейчас.

UR

[embedded content]

Понравилось:

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

Минусы:

устаревшая ОС на контроллере UR, где-то уже полтора года нет никаких обновлений безопасности
все-таки не самый современный способ коммуникации, хотя он неплохо прикрыт доступными открытыми библиотеками

Из питона роборука доступна в двух основных сценариях:

Установить https://github.com/SintefManufacturing/python-urx и наслаждаться. Немного длиньше листинг, чем в случае evasdk, так что не буду приводить. Также есть известные проблемы совместимости с новыми роборуками, судя по issue-трекеру. Кое что пришлось так же поправить под себя, т.к. не все режимы перемещения были имплементированы в библиотеке, но это тонкости.
Пойти по особому «ROS-до» (https://github.com/ros-industrial/universal_robot). Для тех, кто в ROS как рыба, тут все просто: немного магии с загрузкой некого скрипта в тушку UR и вы можете использоваться moveit (очень полезный кусок ROS, который позволяет, например, планировать траекторию в условиях наличия препятствий).

Мы стараемся избегать ROS, т.к. частично его функции (брокер сообщений) выполняет rabbitmq в нашей системе, да и происходит серьезное усложнение стека используемых технологий. Так что для случая, когда нужно объезжать препятствия, мы инскапсулируем ROS в микросвервис на серверной стороне.

А теперь трюк!

Чтобы вы понимали, UR это:

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

Оказалось, что на UR контроллере установлен linux (и кстати не самый слабый x86 процессор).
Набираем ssh IP… user: root, password: easybot.

И вы в Debian Wheezy.

Так что берем и ставим VNC server и обнаруживаем себя полным хозяином робота! (Тут надо только заметить, что Wheezy уже 2 года как не обновляется и просто взять и поставить vnc сервер у вас не получится из-за устаревших регистров. Но тут есть ссылка на «magic file», который позволяет это сделать).

Кстати, в Universal Robots, когда мы им показали наше демо, сказали, что подобное удаленное управление требует новой процедуры сертификации безопасности. Справедливо. Очень любопытно, как в Smart Robotics с этим обстоят дела в целом. Не могу представить, чтобы переменные целеуказания от компьютерного зрения могли бы быть 100% безопасны для окружающих.

Пришло время учить робота хватать коробочки

Напомню, мы же показываем что делать роботу в VR:

[embedded content]

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

{"op": "pickup_putdown_box", 
"pos1": [441.1884, -112.833069, 151.29303],
"pos2": [388.1267, 91.0179138, 114.847595],
"rot1": [[0.9954941, 0.06585537, -0.06822499], [0.0917332, -0.851038456, 0.517028868], [-0.0240128487, -0.52095747, -0.85324496]],
"rot2": [[0.992139041, 0.102700718, -0.07150351], [0.100485876, -0.99436, -0.0339238755], [-0.0745842, 0.026472155, -0.996863365]],
"calibration": [[-0.01462146, 0.9814359, -0.191232175, 551.115051], [0.9987302, 0.0051134224, -0.0501191653, -6.613386], [-0.0482108966, -0.191722155, -0.9802644, 771.933167]],
"box": [[474.331482, -180.079529, 114.765076], [471.436157, -48.88102, 188.729553], [411.868164, -180.27713, 112.670532], [476.105164, -148.54512, 58.89856]],
"source": "operator"}

В общем этого нам достаточно, чтобы обучить сеточки определять bounding box объекта в пространстве и где его хватать.

Так что сидим полчаса и показываем роботу как жонглировать 4-мя типами коробок, получаем около 100 примеров. Нажимаем магическую кнопку… ну точнееsudo docker run -e INPUT_S3_FOLDER=… OUTPUT_S3_FOLDER=… rembrain/train_all_stages: dev. И идем спать. С утра докер отправляет сообщение ML-процессору обновить веса, и мы с замиранием сердца (роботов хоть и дали бесплатно тестировать производители, стоят денег прямо серьезных), запускаем и…

Надо сказать, что ни один робот при отладке не пострадал. Я думаю исключительно благодаря невероятному везению.

Однажды мой двухлетний сын подошел и решил поиграться с VR трекером. Залез на стул, взял его с подоконника… И отправил UR10 в невообразимое путешествие, отодвинув штангу с камерой и заведя роборуку в довольно хитрое положение. Так что пришлось добавить немного предохранителей в управление. И вторую обзорную камеру, т.к. иначе порою просто не видно куда уехала рука и можно ли ею двигать.

А если без шуток, то точность детекции таких не сложных коробок в наших тестах превышала 99.5% даже при небольшой обучающей выборке из нескольких сотен примеров. Основной источник проблем здесь уже не компьютерное зрение, а сопутствующие сложности: например, какие-то аномалии в исходной укладки объектов, или непредусмотренные помехи в кадре. Но затем мы и делаем обучающуюся систему с операторами в цикле, чтобы быть готовым ко всему, разрешая проблемы, не вовлекая живых людей на месте.

Еще об одном алгоритме, о том, что меня в backend и промахе в UI frontend-е

Проблема плотной упаковки

Иногда bin-picking применения соседствуют с задачей «bin-stuffing», ну т.е. разумной упаковкой в корзину. В случае одинаковых объектов — это не проблема. Но если мы говорим даже о коробочках разного размера, это реально сложная задача упаковки.

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

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

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

Backend

Мы придерживаемся прежней схемы, когда каждому роботу отдали по серверу ретрансляции на websocket-ах, как на этой схеме:

Единственное, сервис Coordinator стал разрастаться в кластер с кучей сервисов внутри. Например, свое место там заняли брокер сообщений Rabbit и mongoDB, сборка логов, как у людей (и это кстати правда удобно в распределенной системе). Так же пришлось добавить активный сервис мониторинга, который активно проверяет целостность всей системы и отвечает о текущем статусе каждого робота.

Но и в целом, конечно, работы по backend-у так много, что позаниматься ML частью системы уже за счастье.

И вот у нас слишком сложный UI

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

Мы привыкли к AWS console, Yandex console, начинает казаться, что и для управления роботами нужно вот именно это, разве что для телефона, а не на десктопе. Не так то и удобно монтировать робота и бегать к компьютеру или ноутбуку.

Казалось, что получилось невероятно круто и понятно.

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

Однако, нет «потока». Тесты показали, что все несколько контринтуитивно и UX нужно менять. Вот он новый интересный опыт — преодолеем и это. А пока что назовем текущий UI robot Console и оставим его для себя.

Что дальше

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

Параллельно ищем новые практические применения помимо понятного и популярного bin-picking (лично я мечтаю о применении роботов на стройке).

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

Так что карантин пошел на пользу!