Тут недавно мужики на Хабре рассказывали про Flipper и отладку на осциллографе по видеосвязи.
И это, конечно, победа вне конкурса! Но и у нас был интересный опыт отладки робота, находящегося в 2000 км от нас в лодочном гараже на норвежском побережье. Под катом рассказ о том, как мы делали зрение и правили “облачные мозги” роботам во время карантина удаленно:
Весной мы сделали прототип всей системы удаленного управления по 3D стриму и обучения роботом на двуруком YuMi и познакомились норвежской компанией, чье решение нам очень кстати для трансляции 3D потока Realsense камер — Aivero. Так что после не самого простого рабочего периода планы казались безоблачными: слетать в Италию на месяц зимы с семьей, оттуда поездить по выставкам робототехники в Европе и закончить все остановкой на пару недель в городе с прекрасными фьордами в округе — Ставангер, где и обсудить интеграцию 3D кодеков в нашу систему и попробовать убедить Aivero собрать пару роботов вместе.
Что могло пойти не так в этом замечательном плане…
Сидя 2 недели на карантине после возвращения (не без приключений) из итальянского локдауна, пришлось сдуть пыль со своего разговорного и письменного английского и исполнять вторую часть плана уже в Zoom-е, а не в антураже фьордов.
Хотя, тут как взглянуть. Карантин заставил многих всерьез начать работать над возможными способами автоматизацией там, где человека не сложно заменить. Тем более для западных стран, в которых минимальная зарплата выше 1500 Евро, где роботизация простого ручного труда актуальна и без текущей эпидемиологической обстановки.
Напомню, мы сделали обучение роботов по записям удаленного управления. Т.е. робот подключается к интернету, к нашему облаку и начинает слать 3D картинки и показания датчиков. Обратно получает команды и исполняет их. В такой логике наша задача научить ML процессор вести себя также, как оператор. 3D нужно, чтобы отрисовать оператору сцену в виртуальной реальности. Это удобно, да и ML становится намного точнее при хватании объектов, когда есть карта глубин.
По задумке, мы можем подключать разнообразных роботов к нашему облаку, но создавать их все разнообразие самим — это очень тернистый путь. Мы же фокусируемся на их мозгах, на обучении.
В итоге договорились с Aivero о создании универсального однорукого робота с 3D глазами их силами, назовем его “Юнит”, а весь облачный Robotics достается делать нам.
В приоритете была простота и цена решения для конечного заказчика. И, конечно, универсальность. Мы хотим минимизировать порог входа для автоматизации простого ручного труда. В идеале, чтобы даже владелец малого бизнеса, не обладающий специальными навыками, мог купить или арендовать наш “Юнит”, поставить его на рабочем месте и запустить.
Подумали пару недель, потестировали гипотезы пару месяцев и вот, что получилось (версия с Jetson AGX в основании и другой обзорной камерой, чем на заглавной):
И прожектор поближе:
Состав:
Такая телескопическая стойка с вычислителем и вакуумным насосом в основании ставится рядом с рабочей областью робота, подключается к интернету (например по QR коду к WiFi), и сразу начинает решать поставленную задачу практически без настройки.
Здесь можно сразу оценить и стоимость. Самая доступная роборука Eva — 8000 Евро (в России не поставляется), а UR10 уже обойдется почти в 50 000 Евро, но тут нужно отметить, что UR заявляет значительно большую надежность, так что в долгосрочной перспективе может оказаться и не сильно дороже. Да и дешевеют они последнее время. Остальной комплект обходится еще около 2000 Евро.
Мы раньше имели дело с двуруким YuMi, но здесь попробовали новую версию IRB14050, которая по сути просто одна оторванная рука.
Кратко, чем понравилась:
и не понравилось:
И не кратко.
Здесь мы потратили больше всего времени. Рецепт, как запускать, совсем не простой:
Но, конечно, это лишь возможная траектория того, как можно заставить YuMi повиноваться, да и всех мелочей, где можно споткнуться, тут не упомянуть, конечно.
Кратко, чем понравилось:
И минусы:
Конечно, простота управления подкупает:
и
И роборука вжух! и исполняет.
Нет, конечно, потом мы смогли переполнить логи в контроллере руки, после чего она переставала слушаться. Но надо отдать должное производителю — создание issue в их гите хватило, чтобы они разобрались в причинах (и привело к паре созвонов с целым консилиумом о наших проблемах).
И в целом, Automata (производитель Eva) большие молодцы! Надеюсь у них получится расти и развиваться на рынке робототехники и дальше, делая роботов сильно доступнее и проще, чем они есть сейчас.
Понравилось:
Минусы:
Из питона роборука доступна в двух основных сценариях:
Мы стараемся избегать 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:
Т.е. у нас по каждому перемещению записано, как выглядела сцена и что за команда была, например такая:
В общем этого нам достаточно, чтобы обучить сеточки определять bounding box объекта в пространстве и где его хватать.
Так что сидим полчаса и показываем роботу как жонглировать 4-мя типами коробок, получаем около 100 примеров. Нажимаем магическую кнопку… ну точнееsudo docker run -e INPUT_S3_FOLDER=… OUTPUT_S3_FOLDER=… rembrain/train_all_stages:dev. И идем спать. С утра докер отправляет сообщение ML-процессору обновить веса, и мы с замиранием сердца (роботов хоть и дали бесплатно тестировать производители, стоят денег прямо серьезных), запускаем и…
УПС…
Надо сказать, что ни один робот при отладке не пострадал. Я думаю исключительно благодаря невероятному везению.
Однажды мой двухлетний сын подошел и решил поиграться с VR трекером. Залез на стул, взял его с подоконника… И отправил UR10 в невообразимое путешествие, отодвинув штангу с камерой и заведя роборуку в довольно хитрое положение. Так что пришлось добавить немного предохранителей в управление. И вторую обзорную камеру, т.к. иначе порою просто не видно куда уехала рука и можно ли ею двигать.
А если без шуток, то точность детекции таких не сложных коробок в наших тестах превышала 99.5% даже при небольшой обучающей выборке из нескольких сотен примеров. Основной источник проблем здесь уже не компьютерное зрение, а сопутствующие сложности: например, какие-то аномалии в исходной укладки объектов, или непредусмотренные помехи в кадре. Но затем мы и делаем обучающуюся систему с операторами в цикле, чтобы быть готовым ко всему, разрешая проблемы, не вовлекая живых людей на месте.
Снимаем видео монтажа и настройки робота за 2 минуты, готовим материалы для продвижения на нескольких типах задач.
Параллельно ищем новые практические применения помимо понятного и популярного bin-picking (лично я мечтаю о применении роботов на стройке).
Думаю через несколько месяцев мыстанем более лучше одеваться научимся продавать наше решение в максимально разнообразные применения и будем кирпичик за кирпичиком строить наш облачный мозг в чудовищно конкурентной обстановке компаний, делающих роботов умными, что не может не радовать.
Так что карантин пошел на пользу!
И это, конечно, победа вне конкурса! Но и у нас был интересный опыт отладки робота, находящегося в 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-е
Проблема плотной упаковки
Иногда bin-picking применения соседствуют с задачей «bin-stuffing», ну т.е. разумной упаковкой в корзину. В случае одинаковых объектов — это не проблема. Но если мы говорим даже о коробочках разного размера, это реально сложная задача упаковки.
Можно эту задачу решать через планирование, но в нашем случае мы не можем гарантировать, что все легло ровно как мы планируем. Поэтому придется играть в тетрис. Т.е. смотреть что у нас сейчас в корзине, куда все складываем, и думать куда поставить задетектированный объект. Такой жадный подход здесь не самый лучший, но иначе все становится сильно сложнее.
Таким образом, мы переводим трассируем луч по пикселю карты глубин и заполняем воксельный объем корзины. А затем ищем самое лучшее место, где расположить новую коробку (на деле самую нижнюю точку, ближнюю к одному углу корзины). Как-то так:
Иногда получается ерунда, т.к. не под частью коробки просто нет опоры, например как здесь:
Backend
Мы придерживаемся прежней схемы, когда каждому роботу отдали по серверу ретрансляции на websocket-ах, как на этой схеме:
Единственное, сервис Coordinator стал разрастаться в кластер с кучей сервисов внутри. Например, свое место там заняли брокер сообщений Rabbit и mongoDB, сборка логов, как у людей (и это кстати правда удобно в распределенной системе). Так же пришлось добавить активный сервис мониторинга, который активно проверяет целостность всей системы и отвечает о текущем статусе каждого робота.
Но и в целом, конечно, работы по backend-у так много, что позаниматься ML частью системы уже за счастье.
И вот у нас слишком сложный UI
Смиритесь. Если вы разработчик и думаете, что вы сделали UI уже для человеков, то нет. Сходите к человеку и попросите его этим воспользоваться.
Мы привыкли к AWS console, Yandex console, начинает казаться, что и для управления роботами нужно вот именно это, разве что для телефона, а не на десктопе. Не так то и удобно монтировать робота и бегать к компьютеру или ноутбуку.
Казалось, что получилось невероятно круто и понятно.
Вот консоль с роботами, где прямо все про него -> можно зайти в стрим и командовать им -> а если хочется озадачить, то идем в задания, делаем задание, выбирая один из темплейтов -> и даже здесь надо просто обвести пальцем и определить область откуда брать предметы, и куда класть.
Однако, нет “потока”. Тесты показали, что все несколько контринтуитивно и UX нужно менять. Вот он новый интересный опыт — преодолеем и это. А пока что назовем текущий UI robot Console и оставим его для себя.
Иногда bin-picking применения соседствуют с задачей «bin-stuffing», ну т.е. разумной упаковкой в корзину. В случае одинаковых объектов — это не проблема. Но если мы говорим даже о коробочках разного размера, это реально сложная задача упаковки.
Можно эту задачу решать через планирование, но в нашем случае мы не можем гарантировать, что все легло ровно как мы планируем. Поэтому придется играть в тетрис. Т.е. смотреть что у нас сейчас в корзине, куда все складываем, и думать куда поставить задетектированный объект. Такой жадный подход здесь не самый лучший, но иначе все становится сильно сложнее.
Таким образом, мы переводим трассируем луч по пикселю карты глубин и заполняем воксельный объем корзины. А затем ищем самое лучшее место, где расположить новую коробку (на деле самую нижнюю точку, ближнюю к одному углу корзины). Как-то так:
Иногда получается ерунда, т.к. не под частью коробки просто нет опоры, например как здесь:
Backend
Мы придерживаемся прежней схемы, когда каждому роботу отдали по серверу ретрансляции на websocket-ах, как на этой схеме:
Единственное, сервис Coordinator стал разрастаться в кластер с кучей сервисов внутри. Например, свое место там заняли брокер сообщений Rabbit и mongoDB, сборка логов, как у людей (и это кстати правда удобно в распределенной системе). Так же пришлось добавить активный сервис мониторинга, который активно проверяет целостность всей системы и отвечает о текущем статусе каждого робота.
Но и в целом, конечно, работы по backend-у так много, что позаниматься ML частью системы уже за счастье.
И вот у нас слишком сложный UI
Смиритесь. Если вы разработчик и думаете, что вы сделали UI уже для человеков, то нет. Сходите к человеку и попросите его этим воспользоваться.
Мы привыкли к AWS console, Yandex console, начинает казаться, что и для управления роботами нужно вот именно это, разве что для телефона, а не на десктопе. Не так то и удобно монтировать робота и бегать к компьютеру или ноутбуку.
Казалось, что получилось невероятно круто и понятно.
Вот консоль с роботами, где прямо все про него -> можно зайти в стрим и командовать им -> а если хочется озадачить, то идем в задания, делаем задание, выбирая один из темплейтов -> и даже здесь надо просто обвести пальцем и определить область откуда брать предметы, и куда класть.
Однако, нет “потока”. Тесты показали, что все несколько контринтуитивно и UX нужно менять. Вот он новый интересный опыт — преодолеем и это. А пока что назовем текущий UI robot Console и оставим его для себя.
Что дальше
Снимаем видео монтажа и настройки робота за 2 минуты, готовим материалы для продвижения на нескольких типах задач.
Параллельно ищем новые практические применения помимо понятного и популярного bin-picking (лично я мечтаю о применении роботов на стройке).
Думаю через несколько месяцев мы
Так что карантин пошел на пользу!
SakuradaJun
Занятно, но тем не менее какие у него задачи? Например, что делает конкретно этот робот в лодочном гараже?
Пока складывается впечатление что это игрушка без задач.
Vasyutka Автор
хватание разнообразных предметов в робототехнике уже более менее устоявшаяся задача с приличным рынком продаж: загрузка деталей в станки и извлечение, в каких-то технологических операциях, сейчас в ретейл идут чтобы набирать заказы, еще фасовка. С учетом нового поколения обучаемых алгоритмов, все уже ограничено возможностью робота и фантазией технолога. А в гараже сейчас основная задача робота — испытания и быть объектов аддитивной разработки.
Но мы думаем над тем, чтобы открыть там минифабрику, а то столько роботов проставивает :)