[Алгоритмы, Машинное обучение, Развитие стартапа, Робототехника] Роботы на карантине

Автор Сообщение
news_bot ®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
04-Авг-2020 14:31

Тут недавно мужики на Хабре рассказывали про 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, которая по сути просто одна оторванная рука.
Извините, данный ресурс не поддреживается. :(
Кратко, чем понравилась:
  • точность и механическое качество исполнения
  • высокая чувствительность к коллизиям и демпферы на суставах

и не понравилось:
  • тяжело удаленно разрешать коллизии и нештатные ситуации
  • малый угловой ход некоторых суставов делает траектории довольно сложными для, казалось бы, простых движений, которые для кинематики других 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
Извините, данный ресурс не поддреживается. :(
Понравилось:
  • отлично сделана по механике и высокая точность
  • большие диапазоны углов в суставах, что делает планировку траектории заметно проще
  • коллизии можно разрешить в 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:
Извините, данный ресурс не поддреживается. :(
Т.е. у нас по каждому перемещению записано, как выглядела сцена и что за команда была, например такая:
{“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-е

SPL
Проблема плотной упаковки
Иногда bin-picking применения соседствуют с задачей «bin-stuffing», ну т.е. разумной упаковкой в корзину. В случае одинаковых объектов — это не проблема. Но если мы говорим даже о коробочках разного размера, это реально сложная задача упаковки.
Можно эту задачу решать через планирование, но в нашем случае мы не можем гарантировать, что все легло ровно как мы планируем. Поэтому придется играть в тетрис. Т.е. смотреть что у нас сейчас в корзине, куда все складываем, и думать куда поставить задетектированный объект. Такой жадный подход здесь не самый лучший, но иначе все становится сильно сложнее.
Таким образом, мы переводим трассируем луч по пикселю карты глубин и заполняем воксельный объем корзины. А затем ищем самое лучшее место, где расположить новую коробку (на деле самую нижнюю точку, ближнюю к одному углу корзины). Как-то так:

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

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

Единственное, сервис Coordinator стал разрастаться в кластер с кучей сервисов внутри. Например, свое место там заняли брокер сообщений Rabbit и mongoDB, сборка логов, как у людей (и это кстати правда удобно в распределенной системе). Так же пришлось добавить активный сервис мониторинга, который активно проверяет целостность всей системы и отвечает о текущем статусе каждого робота.
Но и в целом, конечно, работы по backend-у так много, что позаниматься ML частью системы уже за счастье.
И вот у нас слишком сложный UI
Смиритесь. Если вы разработчик и думаете, что вы сделали UI уже для человеков, то нет. Сходите к человеку и попросите его этим воспользоваться.
Мы привыкли к AWS console, Yandex console, начинает казаться, что и для управления роботами нужно вот именно это, разве что для телефона, а не на десктопе. Не так то и удобно монтировать робота и бегать к компьютеру или ноутбуку.
Казалось, что получилось невероятно круто и понятно.
Вот консоль с роботами, где прямо все про него -> можно зайти в стрим и командовать им -> а если хочется озадачить, то идем в задания, делаем задание, выбирая один из темплейтов -> и даже здесь надо просто обвести пальцем и определить область откуда брать предметы, и куда класть.

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

Что дальше
Снимаем видео монтажа и настройки робота за 2 минуты, готовим материалы для продвижения на нескольких типах задач.
Параллельно ищем новые практические применения помимо понятного и популярного bin-picking (лично я мечтаю о применении роботов на стройке).
Думаю через несколько месяцев мы станем более лучше одеваться научимся продавать наше решение в максимально разнообразные применения и будем кирпичик за кирпичиком строить наш облачный мозг в чудовищно конкурентной обстановке компаний, делающих роботов умными, что не может не радовать.
Так что карантин пошел на пользу!
===========
Источник:
habr.com
===========

Похожие новости: Теги для поиска: #_algoritmy (Алгоритмы), #_mashinnoe_obuchenie (Машинное обучение), #_razvitie_startapa (Развитие стартапа), #_robototehnika (Робототехника), #_robot (робот), #_kamery_glubiny (камеры глубины), #_startap (стартап), #_blog_kompanii_recognitor (
Блог компании Recognitor
)
, #_algoritmy (
Алгоритмы
)
, #_mashinnoe_obuchenie (
Машинное обучение
)
, #_razvitie_startapa (
Развитие стартапа
)
, #_robototehnika (
Робототехника
)
Профиль  ЛС 
Показать сообщения:     

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 23-Ноя 00:21
Часовой пояс: UTC + 5