Compare commits
No commits in common. "master" and "50-asp" have entirely different histories.
86 changed files with 62 additions and 2022 deletions
|
|
@ -1,216 +0,0 @@
|
|||
---
|
||||
slug: 2nd-year-summary
|
||||
title: Итоги 2023 года
|
||||
author: Игорь Брылёв
|
||||
author_title: Team Lead @ Robossembler
|
||||
author_url: https://gitlab.com/movefasta
|
||||
author_image_url: https://gitlab.com/uploads/-/system/user/avatar/4249760/avatar.png
|
||||
tags: [robossembler, milestone, summary]
|
||||
---
|
||||
|
||||
[Видео-версия](https://youtu.be/vWpaZ8DRftI)
|
||||
|
||||
В этом обзоре мы расскажем о разработках в рамках проекта Робосборщик в 2022-2023 годах.
|
||||
|
||||
## Аппаратное обеспечение
|
||||
|
||||
### Robossembler Arm и его двигатели
|
||||
|
||||
Самая главная аппаратная разработка этих полутора лет — рука Робосборщика или [Robossembler Arm](https://gitlab.com/robossembler/roboarm-diy-version).
|
||||
|
||||
|
||||
|
||||
Это шести-осевой робот манипулятор, который существенно изменился - сокращены габаритные размеры, вес, снижено общее количество деталей и крепежа.
|
||||
|
||||
|
||||
|
||||
Всего в конструкции теперь 66 деталей и 32 соединителя, которые достаточно крупные, чтобы вставлять их вручную, без помощи вспомогательного инструмента, или даже автоматически - разработанным нами захватным устройством. Все детали содержат специальные пазы для удобства захвата.
|
||||
|
||||
|
||||
|
||||
Конструкция робота предполагает возможность гибко менять количество степеней свободы под задачу.
|
||||
|
||||
|
||||
|
||||
Одной из ключевых особенностей робота является [симметричный стыковочный интерфейс](https://gitlab.com/robossembler/arm-tools/connection-tool), который позволяет роботу перемещаться между совместимыми с ним посадочными местами и, тем самым, расширять доступную для работы зону.
|
||||
|
||||
|
||||
|
||||
Стыковочный интерфейс претерпел уже 8 модификаций, прошёл первичные испытания на прочность соединения и готов к интеграционным испытаниям с остальной частью робота.
|
||||
|
||||
|
||||
|
||||
Мы его упростили, облегчили, при этом сохранив его достаточно жёстким; конструкция препятствует повреждению контактов при ручной установке.
|
||||
|
||||
Ключевым узлом робота является разработанный нами с нуля серводвигатель. На данный момент изготовлен его прототип вместе с контроллерами и ведётся разработка программного обеспечения для управления.
|
||||
|
||||
|
||||
|
||||
Изначально мы разработали две модификации серводвигателя - один для создания крутящего момента на звене манипулятора, второй - для монтажа рабочего органа или монтажа самого манипулятора к опорному каркасу, но со временем заменили их на один универсальный контроллер для всех версий привода, что позволит ещё больше сократить номенклатуру компонентов и, соответственно, уменьшить себестоимость изделия.
|
||||
|
||||
|
||||
|
||||
|
||||
Изменения в серводвигателях коснулись в основном системы вентиляции обмоток и подшипникового узла, который на данный момент может быть использован как радиально-упорный подшипник скольжения, изготовленный методом печати, так и на его место может быть установлен стандартный набор из двух подшипников качения. Улучшено крепление магнитов к ротору с целью уменьшения магнитного зазора. На данный момент испытано семь вариантов печатных роторов и найден оптимальный механизм крепления магнитов.
|
||||
|
||||
|
||||
|
||||
Также разработана заглушка для стыковочного интерфейса, позволяющая подключить манипулятор напрямую, без опорного каркаса, если в нём нет необходимости.
|
||||
|
||||
|
||||
|
||||
Разработан и изготовлен прототип датчика угла поворота на выходе редуктора для того, чтобы понимать реальное перемещение звена, что позволит сделать робота в дальнейшем коллаборативным.
|
||||
|
||||
|
||||
|
||||
Датчик реализован на кондуктометрическом принципе и обладает чрезвычайно низкой себестоимостью.
|
||||
|
||||
### Опорный каркас
|
||||
|
||||
[Опорный каркас](https://gitlab.com/robossembler/cnc/cubic-modular-workspace), который мы показывали в прошлый раз, тоже претерпел большие изменения. Мы убрали дополнительные соединители и теперь весь каркас состоит из практически одних и тех же универсальных сборочных единиц - опорных пластин. Пластины могут быть двух типов.
|
||||
|
||||
|
||||
|
||||
Первый тип — это пластины с симметричным стыковочным интерфейсом. К ним подключается активное оборудование - роботы или рабочие органы. Другие пластины - пассивные, в них вместо стыковочного интерфейса установлена заглушка. Они выполняют функции передатчиков сигналов и обеспечивают жесткость всей конструкции.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Источик питания
|
||||
|
||||
Также разработан совместимый с опорным каркасом [источник питания](https://gitlab.com/robossembler/arm-tools/power-supply-box) от сети переменного тока.
|
||||
|
||||
### Оснастка для производства
|
||||
|
||||
Мы стремимся сделать робота максимально простым в изготовлении, поэтому помимо конструктивных решений для удобства сборки, разрабатываем и вспомогательную оснастку для автоматизации производства. Мы активно разрабатываем [станок для намотки катушек индуктивности двигателя](https://gitlab.com/robossembler/cnc/motor-wire-winder).
|
||||
|
||||
|
||||
|
||||
Опробованы два варианта намоточного станка - ручной и полуавтоматический, сейчас разрабатывается третий вариант. Станок позволит нам обеспечить серийное производство моторов и сервоприводов. Как и во всех остальных случаях, конструкторская документация на станок будет открыта.
|
||||
|
||||
### Приспособление для захвата
|
||||
|
||||
Существенно изменена конструкция [приспособления для захвата](https://gitlab.com/robossembler/arm-tools/grip-tool), в котором теперь используются те же самые узлы, что и в манипуляторе - двигатель с контроллером, стыковочный интерфейс.
|
||||
|
||||
|
||||
|
||||
В новой версии улучшены передаточные механизмы, добавлены редукторы, изменён корпус. Новая конструкция позволяет вращать пальцы на угол 360 градусов, а новая форма пальцев - "захватывать" объекты внешней стороной.
|
||||
|
||||
## Программные решения
|
||||
|
||||
### Robonomics Bridge
|
||||
|
||||
В 2022 году нашей командой разработан [мост между Робономикой и ROS2](https://gitlab.com/robossembler/robonomics_bridge), который решает проблему взаимодействия различных кибер-физических систем через публичную сеть интернет.
|
||||
|
||||
|
||||
|
||||
Фреймворк ROS2 основан на протоколе под названием DDS или Data Distrubution Service, который обеспечивает взаимодействие узлов ROS друг с другом. Этот протокол ориентирован на работу в локальной сети, в нём заложены механизмы автоматического обнаружения устройств и очень интенсивное взаимодействие между ними. Однако, в случах когда требуется обеспечить работу отдельных узлов ROS с каким-то внешним сервисом или системой, то возникает проблема безопасности - получив доступ к одному узлу, сторонний сервис получает доступ и ко всем остальным - он может полностью прослушивать весь внутренний трафик DDS.
|
||||
|
||||
Чтобы решить проблему доступа узлов друг к другу можно использовать пакет ROS2 Security, который настраивает политики доступа к данным. Однако, этот подход обладает большим минусом - весь трафик в системе шифруется, что может сказаться на быстродействии при той нагрузке на сеть, которую создаёт DDS. Другое решение заключается в создании так называемых шлюзов, которые публикуют нужные данные, сохраняя всё остальное приватным. Как правило, это достигается при помощи тоннелей VPN или SSH между взаимодействующими узлами. Такой подход применён в таких проектах как Husarnet, Integration Service и Zenoh, но и он не лишён недостатков. В этом случае вам нужно создать защищённый канал связи, который жёстко привязан к IP-адресу или доменному имени контрагента, а они имеют свойство меняться, блокироваться и подвергаться атакам.
|
||||
|
||||
Проблему можно обойти с помощью технологий p2p, на которых построен блокчейн [Robonomics](https://robonomics.network/). По сути блокчейн может являться в этом случае очень защищённой таблицей маршрутизации, адресами контрагентов в которой являются публичные ключи узлов. Вам нужен локальный узел блокчейна и знание о том какой публичный ключ у вашего контрагента, чтобы далее не зависеть от системы DNS и блокировок IP-адресов. Библиотека libp2p, на которой построен блокчейн Робономики, может использовать разные транспортные протоколы для доставки сообщений. Однако, это не все возможности, которые может дать блокчейн. Помимо простого коммутирования потоков сообщений, в блокчейне в будущем может быть реализована и более сложная логика на смарт-контрактах, подразумевающая взаимодействие большого количества агентов. Например, принятие решение о запуске производства какого-то продукта может быть привязано к голосованию в организации потенциальных потребителей этого продукта, с учётом экономической целесообразности. Сейчас решение о запуске какого-либо производства принимается с помощью механизма инвестиций, когда инвесторы, получив информацию о потенциальном спросе, могут приобретать акции отдельных компаний, которые этот спрос смогут в будущем удовлетворить. То есть инвесторы являются лишним передаточным звеном между потребителями и производителями. Если потребители смогут более активно участвовать в разработке и ценообразовании новых продуктов, то мы сможем в перспективе перейти на такую схему работы, когда производство будет автоматически перестраиваться на удовлетворение спроса по данным, предоставляемым в блокчейн потребителями.
|
||||
|
||||
### Robossembler Framework
|
||||
|
||||
Основной разработкой проекта по-прежнему является Фреймворк Робосборщик, в котором можно выделить два основных блока - Offline и Online.
|
||||
|
||||
|
||||
|
||||
[Оффлайн-часть](https://gitlab.com/robossembler/framework) связана с подготовкой моделей для симуляции, машинному обучению, взаимодействию с системами контроля версий и непрерывной интеграции. По сути она представляет собой конвейер подготовки трёхмерных моделей и инструменты анализа статической структуры изделия. Одним из важнейших узлов в этом конвейере является разработанный нами планировщик сборки или планировщик последовательности сборки — Assembly Sequence Planner.
|
||||
|
||||
|
||||
|
||||
Этот программный компонент анализирует сборку в формате STEP, проверяет наличие дефектов в геометрии, которые делают проблематичным подготовку моделей в формат пригодный для симуляции. Также он проверяет требуемые допуски между деталями и строит так называемую матрицу смежности, которая содержит полную информацию о сопряжениях между деталями. Чтобы построить всю последовательность сборки. Дальше сформированные подсборки проверяются на стабильность в гравитационном поле и алгоритм генерирует подходящие варианты для отладки в симуляции. В 2023 году мы дополнили нашу [коллекцию исследований](https://robossembler.org/docs/technologies/ASP-overview) по генерации последовательности сборки. Найдены новые исследователи, работающие в направлении автоматизации планирования сборки - в частности, доктор технических наук Божко Аркадий Николаевич, преподаватель из Бауманского университета, с достаточно оригинальным подходом к решению задачи через использование гипер-графов, который мы планируем поддержать в нашей программной части.
|
||||
|
||||
Далее работу принимает часть конвейера, отвечающая за компьютерную графику.
|
||||
|
||||
|
||||
|
||||
Детали, входящие в сборки, преобразовываются в так называемые ассеты компьютерной графики разной степени полигональности. Для преобразования ассетов используется свободный редактор компьютерной графики Blender и разработанный нами аддон. Аддон формирует три типа ассетов. Высоко-полигональные модели содержат много деталей и могут использоваться для качественной визуализации. Для симуляции требуется обратное - чтобы количество полигонов было как можно меньшим. Поэтому производится оптимизация полигональной сети и в некоторых случаях склейка отдельных компонентов в монолитный кусок. Также аддон, используя информацию об материалах деталей из CAD, генерирует так называемые физически реалистичные текстуры, производит так называемое запекание текстур. Чтобы познакомиться с конвейером компьютерной графики подробнее, рекомендую прочесть статью на нашем сайте.
|
||||
|
||||
Онлайн-часть или рантайм [Robossembler ROS2](https://gitlab.com/robossembler/robossembler-ros2) непосредственно выполняется на железе в момент работы робота. За прошедший год мы перевели проект с ROS2 Foxy, поддержка которой была прекращена в 2023 году, на ROS 2 Humble. ROS2 Humble является так называемым долгоживущим релизом или LTS, который будет поддерживаться еще три года.
|
||||
|
||||
### Архитектура runtime
|
||||
|
||||
В рантайме у нас реализована архитектура из нескольких разных уровней планирования.
|
||||
|
||||
|
||||
|
||||
Самый верхний уровень стека - уровень миссии. Там происходит по сути планирование производственных заданий, подобно ERP-системе, где определяется сколько чего мы производим. Далее следует уровень планирования задач - разбиение процесса сборки отдельного изделия на кванты - логические операции, которые, в свою очередь, опираются на уровень поведения, где работают соответствующие задаче комбинации навыков в виде деревьев поведения. Это поведение стоится на базе атомарных навыков, например, движение к точке, движение по траектории, различные типы восприятия изображений, из которых собирается более сложное поведение. Атомарные навыки работают с аппаратным слоем, то есть с железом, через драйвера устройств. Там решается как именно мы получаем данные, через какие интерфейсы, топики или сервисы, как сигналы преобразовываем и куда передаем.
|
||||
|
||||
### Деревья поведения и управление жизненным циклом навыков
|
||||
|
||||
В основе рантайма у нас лежат деревья поведения. Изначально деревья поведения появились в сфере разработки компьютерных игр для того, чтобы программировать персонажей NPC. Однако, со временем данный подход был предложен также для использования и в робототехнике, в частности Петером Оргеном, который популяризирует и всячески пытается приладить к задачам робототехники. Очень хорошо данный подход себя зарекомендовал себя в области мобильной робототехники - это разнообразная навигация по помещениям. В основе популярнейшего пакета ROS Navigation лежат именно деревья поведения. Мы увидели преимущества этого подхода прежде всего в модульности. Мы заранее не знаем какие именно методы подойдут лучше всего для тех или иных задач, поэтому от фреймворка требуется обеспечить изменяемость - чтобы не надо было менять всю остальную программу при изменениях в отдельном навыке или дереве поведения. Также этому подходу присуща и нужная для производства отказоустойчивость.
|
||||
|
||||
|
||||
|
||||
В проекте Robossembler ROS2 разработан BT-executor, в котором реализованы первые узлы или навыки - в частности, движения к точке пространства через решение обратной задачи кинематики, обнаружение объектов в сцене - Object Detection, а также оценка 6D позиции объектов - Pose Estimation для распознавания положения деталей в пространстве перед захватом и сборкой.
|
||||
|
||||
Помимо деревьев поведения, нами также внедрён один из важных концептов, появившихся в ROS2 под названием Lifecycle Nodes или Managed Nodes. Это такой тип узлов ROS2, который позволяет их включать, выключать, конфигурировать, когда надо убирать, добавлять. Это делает удобным подмену, конфигурацию и запуск отдельных навыков в ходе исполнения программы.
|
||||
|
||||
|
||||
|
||||
Например, навык Object Detection у нас используется в нескольких вариантах. В ходе работы программы часто возникает ситуация, когда нужно переключиться на другую реализацию навыка, если текущая не сработала. Разумеется, мы не можем держать всех их в памяти одновременно. Особенно это актуально когда для работы навыка требуется много ресурсов, что часто бывает с нейронными сетями. Здесь на помощь приходят Lifecycle Nodes. Почти все имеющиеся на данный момент навыки в фреймворке реализованы в виде Lifecycle Nodes.
|
||||
|
||||
### Управление виртуальными средами
|
||||
|
||||
Одним из нововведений, которые мы сделали в фреймворке, является Environment Manager или менеджер управления виртуальными средами. Это модуль, который соединяет рантайм с разнообразными средами - как виртуальными, так и не очень. Виртуальной средой может быть игровой движок или симулятор.
|
||||
|
||||
|
||||
|
||||
Environment Manager реализует абстрактный интерфейс, который позволяет соединять рантайм, его драйвера с виртуальной средой. Например, мы можем получать изображение от реальной камеры через какой-то топик, а в этот же топик Environment Manager может нам в дальнейшем, когда мы переключимся на режим симуляции, передавать данные не с камеры, а с симулятора. В этом случае сама программа останется прежней, ничего переписывать не надо. В качестве первой среды мы выбрали симулятор Gazebo, архитектура которого предусматривает разбиение на отдельные компоненты, которые реализовывают физику, рендеринг и многое другое, что делает удобными применение нашего подхода. По нашей задумке Environment Manager должен оказать большое влияние на сам подход к разработке управляющих программ роботов, делая более простым и доступным обучение с подкреплением.
|
||||
|
||||
## Прикладные решения
|
||||
|
||||
### Растениеводство
|
||||
|
||||
Продвигается и разработка прикладных решений на базе наших модулей. Одним из таких решений является роботизированный комплекс для размножения растений методом микроклонирования, который разрабатывается вместе с нашими коллегами из компании [Фито Слим](https://agrostab.ru/).
|
||||
|
||||
|
||||
|
||||
На данный момент микроклонирование представляет собой комплекс сложных операций, каждая из которых требует большого объёма рутинного ручного труда, а качество результата очень чувствительно к чистоте и стерильности помещений. Любой случайно привнесенный вирус может означать гибель всех организмов на той стадии, когда они еще очень слабы и не могут этому вирусу сопротивляться. Роботы потенциально могут решить эти проблемы. В рамках концептуального проектирования разработано специальное приспособление для манипулирования растениями в пробирках.
|
||||
|
||||
|
||||
|
||||
Форма нашего робота хорошо подошла для оперировавания в таких стеснённых пространствах как ламинатор.
|
||||
|
||||
В рамках смежного направления также разработана концепция использования манипуляторов для черенкования, не столь требовательная к самим помещениям, но требовательная к стерильности инструментов. Мы разработали эскиз линии или аппаратный комплекс для отладки исследовательских программ черенкования.
|
||||
|
||||
|
||||
|
||||
Комплекс включает в себя камеры для разносторонней съёмки процесса, чтобы собирать данные и в дальнейшем использовать их для научной и инженерной работы.
|
||||
|
||||
|
||||
|
||||
На базе обоих решений можно создать научно-исследовательский комплекс, которые позволит проводить эксперименты по селекции и отлаживать весь цикл выращивания от микроклонирования до получения саженцев пригодных к открытому грунту.
|
||||
|
||||
|
||||
|
||||
## Вместо заключения
|
||||
|
||||
В заключение хотелось бы отметить, что мы кардинально изменили наш статус - открыли предприятие. Теперь Робосборщик — это не только кружок или клуб единомышленников, а полноценная организация с юридическим статусом. Организация оформлена после победы в конкурсе соискателей финансирования для открытых проектов библиотек программного обеспечения под названием «Код цифровые технологии», организованного Фондом содействия инновациям.
|
||||
|
||||
В 2024 году мы планируем завершить разработку программного обеспечения контроллера серводвигателя, запустить манипулятор и испытать его вместе с нашим рантайм модулем. Параллельно этой работе будет вестись и проект фреймворка для отладки программ через симуляцию.
|
||||
|
||||
Подписывайтесь на наши каналы в [Telegram](https://t.me/robossembler_ru) и [Youtube](https://www.youtube.com/channel/UC32Xgbsw9XQlN1QH59pe8HA). Если у Вас есть идеи как можно помочь проекту, то Вы можете непосредственно зайти в [GitLab](https://gitlab.com/robossembler), выбрать нужный подпроект и просто написать там issue, где поделиться своими мыслями.
|
||||
|
||||
## Команда
|
||||
|
||||
В работе участвовали:
|
||||
|
||||
- Игорь Брылёв
|
||||
- Станислав Сгонов
|
||||
- Алексей Топтун
|
||||
- Александр Оликевич
|
||||
- Роман Андрианов
|
||||
- Илья Ураев
|
||||
- Марк Вольтов
|
||||
- Илья Курочкин
|
||||
- Никита Молканов
|
||||
- Андрей Ермаков
|
||||
- Вячеслав Македонский
|
||||
- Александр Шевеленко
|
||||
- Иван Ершов
|
||||
- Михаил Якушкин
|
||||
- Степан Воронов
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
---
|
||||
slug: rbs-framework-videos
|
||||
title: Видео-демонстрации работы программных модулей Фреймворка Робосборщик
|
||||
author: Игорь Брылёв
|
||||
author_title: Team Lead @ Robossembler
|
||||
author_url: https://gitlab.com/movefasta
|
||||
author_image_url: https://gitlab.com/uploads/-/system/user/avatar/4249760/avatar.png
|
||||
tags: [robossembler, milestone, summary]
|
||||
---
|
||||
|
||||
Краткие ознакомительные видео-демонстрации работы программных модулей Robossembler Framework (https://robossembler.org/docs/robossembler-framework/), который сейчас разрабатывается нашей командой.
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/OR-pSsiaEF0?si=EYauUCESIGjsND0L" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 497 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.6 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.5 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.8 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.1 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.6 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 671 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 359 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 659 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 584 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 391 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 448 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 448 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 567 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 462 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 320 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 507 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 566 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 401 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 401 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 416 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 988 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 665 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 355 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.9 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.3 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.5 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.9 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 613 KiB |
|
|
@ -21,7 +21,7 @@ git и сервисы, построенные вокруг него стали
|
|||
|
||||
### Роль инструментов управления зависимостями
|
||||
|
||||
Однако, одного инструмента контроля версии git оказалось недостаточно для сложных проектов разработки. Подход моно-репозитория, когда все компоненты сложной системы размещались в одном хранилище кода, упирался в административные барьеры (у репозитория один владелец) и технические возможности git. Новые функции git, такие как `подмодули`(`submodules`), не решили задачу управления зависимостями так, как это требует современная индустрия разработки. Вокруг каждого нового языка стали вырастать специальные инструменты управления зависимостями - `npm`, `pip` и многие другие. Это вывело возможности коллаборации на новый уровень. Например, сейчас в `Github` можно просмотреть в каких других проектах используется та или иная библиотека по `Network Graph`, что делает поиск аналогов простым и доступным. Ведь в open source зачастую важнее найти уже существующее, чем писать своё собственное, "изобретая велисипед". Тем не менее, специфичность отдельного пакетного менеджера для своих языков не облегчило процесс управления зависимостями в проектах, в состав которых входят программы на разных языках. К таким проектам относятся и `кибер-физические системы` (КФС), где используются слишком разнообразные инструменты разработки, форматы файлов и сборочные системы. Так сложилась потребность в независимом от языков и IDE способе управлять зависимостями, без которой проектирование много-сложных техническим систем затруднительно.
|
||||
Однако, одного инструмента контроля версии git оказалось недостаточно для сложных проектов разработки. Подход моно-репозитория, когда все компоненты сложной системы размещались в одном хранилище кода, упирался в административные барьеры (у репозитория один владелец) и технические возможности git. Новый функции git, такие как `подмодули`(`submodules`) не решили задачу управления зависимостями так, как это требует современная индустрия разработки. Вокруг каждого нового языка стали вырастать специальные инструменты управления зависимостями - `npm`, `pip` и многие другие. Это вывело возможности коллаборации на новый уровень. Например, сейчас в `Github` можно просмотреть в каких других проектах используется та или иная библиотека по `Network Graph`, что делает поиск аналогов простым и доступным. Ведь в open source зачастую важнее найти уже существующее, чем писать своё собственное, "изобретая велисипед". Тем не менее, специфичность отдельного пакетного менеджера для своих языков не облегчило процесс управления зависимостями в проектах, в состав которых входят программы на разных языках. К таким проектам относятся и `кибер-физические системы` (КФС), где используются слишком разнообразные инструменты разработки, форматы файлов и сборочные системы. Так сложилась потребность в независимом от языков и IDE способе управлять зависимостями, без которой проектирование много-сложных техническим систем затруднительно.
|
||||
|
||||
### Пакетный менеджер общего назначения
|
||||
|
||||
|
|
@ -36,7 +36,9 @@ git и сервисы, построенные вокруг него стали
|
|||
|
||||
Современная системная инженерия (например, согласно стандарту IEC 81346—1:2022) выделяет несколько типов декомпозиции систем: функциональное, конструктивное, пространственное, стоимостное. Функциональное разбиение строится по иерархии функциональных компонентов, которые именуются по их роли и могут быть реализованы различными физическими объектами. Конструктивное - по ссылкам на конкретные классы оборудования или их модели. Пространственное - по локализации в пространстве надсистемы. Стоимостное - по стоимости работ и оборудования.
|
||||
|
||||
Система всегда имеет воплощение в физическом мире, занимает место в пространстве, что нельзя упускать из виду при любой разработке, а потому в качестве базиса для разбиения систем и их отражения в структуре зависимостей nix должна использоваться модульная/конструктивная/синтетическая структура системы в виде дерева/графа с рёбрами типа `является-частью` (в англоязычной литературе по онтологии `is-part-of`). Дополнительным обоснованием этого решения является тот факт, что производство/сборка/модульный синтез осуществляется по конструктивным описаниям. По мере роста степени автоматизации возможна ситуация, когда машина сможет преобразовывать декларативное описание функций системы от человека в императивное описание способа построения, но при этом само преобразование не исчезнет - изменится актор, который будет это преобразование осуществлять.
|
||||
Система всегда имеет воплощение в физическом мире, занимает место в пространстве, что нельзя упускать из виду при любой разработке, а потому в качестве базиса для разбиения систем и их отражения в структуре зависимостей nix должна использоваться модульная/конструктивная/синтетическая структура системы в виде дерева/графа с рёбрами типа `является-частью` (в англоязычной литературе по онтологии `is-part-of`) по следующим причинам:
|
||||
|
||||
Основной причиной является то, что производство/сборка/модульный синтез осуществляется по конструктивным описаниям. По мере роста автоматизации возможна ситуация, когда машина сможет преобразовывать декларативное описание функций системы от человека в императивное описание способа построения, но при этом само преобразование не исчезнет - изменится актор, который будет это преобразование осуществлять.
|
||||
|
||||
Функциональное разбиение является более "субъективным" и часто формируется в контексте т.н. "сценариев использования". Например, в роли молотка может выступать множество предметов - да, в том числе микроскоп. Поэтому идентификация объектов по выполняемой функции может быть затруднительной.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +1,14 @@
|
|||
---
|
||||
id: robossembler-framework
|
||||
title: Фреймворк Робосборщик
|
||||
title: Фреймворк Робосборщик
|
||||
---
|
||||
|
||||
Фреймворк Робосборщик (Robossembler) представляет собой комплекс открытого программного обеспечения и предназначен для автоматизации сборки произвольных изделий роботами-манипуляторами. Идея проекта родилась из попыток решить задачу автоматизации сборки и отсутствия необходимых для этого инструментов и наборов данных. Фреймворк призван решить эту проблему путём предоставления широкому кругу специалистов инструмента, позволяющего создавать адаптированные для виртуальных сред 3D-модели образцов промышленной продукции, генерировать технологические карты сборки в удобном для автоматического планирования формате, производить симуляцию, использовать её для получения синтетических наборов данных (датасетов) и адаптировать данные решения к реальным производственным процессам. Планируемый функционал фреймворка снизит порог требований к квалификации и позволит широкому кругу исследователей поучаствовать во внедрении технологий ИИ в промышленность.
|
||||
|
||||
Фреймворк состоит из двух основных частей:
|
||||
Фреймворк состоит из двух частей:
|
||||
1. [Robossembler Framework](https://gitlab.com/robossembler/framework) (_Offline-часть_). Представляет собой комплекс ПО для предварительной подготовки моделей и робота к сборке.
|
||||
2. [Robossembler ROS2](https://gitlab.com/robossembler/robossembler-ros2) (_Online-часть_). Представляет собой комплекс ПО для исполнения на роботизированной установке в режиме реального времени. Используется ROS2 и основанные на нём фреймворки планирования движений MoveIt и задач PlanSys.
|
||||
|
||||
Для работы с обоими частями разработан специализированный [веб-сервис](software/webservice), который позволяет работать как с Offline, так и с Online-частами фреймворка.
|
||||
|
||||
## Актуальность и востребованность
|
||||
|
||||
Многие, производственные предприятия не рассматривают применение роботов. Это происходит не столько по причине высокой стоимости самих роботов, сколько из-за высокой стоимости их программирования, внедрения и эксплуатации, которые, по данным проекта [SMERobotics](/docs/papers/smerobotics), составляют около 63% от общего количество затрат на внедрение. При отсутствии широкого рынка сбыта высокие начальные затраты делают роботизацию нерентабельной для малого и среднего бизнеса.
|
||||
|
|
@ -58,6 +56,27 @@ title: Фреймворк Робосборщик
|
|||
- Специалист-робототехник декомпозирует задачи из плана на конкретные навыки (skills - detect/pose_estimate/move/align/grasp), формирует запрос на решающие эти задачи и отсутствующие у него подпрограммы (подпрограммы - узлы Дерева Поведения)
|
||||
- Специалисты по multi-robot, assembly/motion planning и CV формируют предложение по каждой конкретной операции - робот получает недостающие подпрограммы и производит тестирование сборки, давая обратную связь разработчикам, чтобы те скорректировали подпрограммы, созданные в симуляции.
|
||||
|
||||
|
||||
## Текущий прогресс
|
||||
|
||||
На данный момент подобраны, изучены и проверены указанные в способах реализации открытые библиотеки для решения задач с планированием задач и движений. Частично реализованы экспорт моделей в формате SDF из свободной CAD-системы FreeCAD для включения в симулятор Gazebo, разметка позиций захвата, интеграция планировщика движений и планировщика задач.
|
||||
- Проведены обширные исследования научных публикаций и проектов открытого ПО по теме
|
||||
- [Обзор новейших публикаций по планированию последовательности сборки](technologies/ASP-overview)
|
||||
- [Исследование проектов конкурса промышленной роботизированной сборки в 2021 году](technologies/wrs2020-assembly-challenge)
|
||||
- [Обзор исследований в области машинного обучения в робототехнике](technologies/machine-learning-in-robotics)
|
||||
- Разработан прототип системы. Исходные коды опубликованы в публичном репозитории [robossembler-ros2](https://gitlab.com/robossembler/robossembler-ros2)
|
||||
- Доступны [видео-демонстрация](https://www.youtube.com/watch?v=J3m5hXf-cro) работы прототипа системы и [видео-презентация](https://www.youtube.com/watch?v=AFROcGW73j0&t=574s) её архитектуры.
|
||||
|
||||
## Конкурентные преимущества
|
||||
|
||||
- Создание сообщества вокруг разработки библиотеки
|
||||
- Использование только свободные библиотек, форматов и стандартов, независимость от импортного проприетарного ПО
|
||||
- Накопление библиотеки 3D-моделей и программ сборки для роботов-манипуляторов
|
||||
- Формирование общедоступных датасетов для обучения роботов-манипуляторов
|
||||
- Использование ИИ для автоматической генерации программ сборки для роботов-манипуляторов
|
||||
- Применение разнообразных комбинаций алгоритмов генерации, планирования, обучения с подкреплением для повышения производительности.
|
||||
- Освобождение потенциальных пользователей из малого и среднего бизнеса от необходимости интегрировать в свои бизнес-процессы громоздкие и дорогостоящие PLM-системы.
|
||||
|
||||
## Аналоги
|
||||
|
||||
[ConnTact](https://github.com/swri-robotics/ConnTact). Создан при поддержке Национального института стандартов и технологий США (NIST). Этому фреймворку присущи следующие недостатки:
|
||||
|
|
@ -67,23 +86,4 @@ title: Фреймворк Робосборщик
|
|||
- Не поддерживает ROS2
|
||||
- Не поддерживает алгоритмы машинного обучения.
|
||||
|
||||
__AutoAssembly__. Разрабатывается командой робототехников из компании Arrival, известного производителя электромобилей с R&D командой из Санкт-Петербурга. Фреймворк предназначен для автоматической роботизированной сборки напрямую из CAD. В научной публикации с описанием фреймворка представлена практическая реализация на примере двух манипуляторов Universal Robotics. Исходный код проекта не публикуется; многие технические решения (спецификации, схемы данных, описания языков, тип базы данных) неизвестны. Более подробный обзор см. по [ссылке](/docs/papers/auto-assembly).
|
||||
|
||||
## Минимальные технические требования
|
||||
|
||||
Минимальные системные требования для запуска модуля исполнения планов:
|
||||
|
||||
1. **Важно!** Совместимо только с операционной системой Ubuntu 22.04.
|
||||
2. Процессор: 64-разрядный процессор с поддержкой SSE4.2 (например, Intel Core i3 или AMD Ryzen 3).
|
||||
3. Оперативная память: не менее 8 ГБ RAM.
|
||||
4. Свободное место на диске: не менее 50 ГБ свободного места на диске.
|
||||
5. Графический процессор: не требуется, но рекомендуется для визуализации и симуляции; для ускорения инференса моделей весов искусственных нейронных сетей может быть использован графический ускоритель.
|
||||
6. ROS 2 версия: Humble.
|
||||
|
||||
Минимальные системные требования для запуска остальных модулей:
|
||||
|
||||
1. Операционная система: Ubuntu 18.04 (Bionic Beaver) или более новая версия, либо Windows 10 или более новая версия.
|
||||
2. Процессор: 64-разрядный процессор с поддержкой SSE4.2 (например, Intel Core i5 или AMD Ryzen 5).
|
||||
3. Оперативная память: не менее 16 ГБ RAM.
|
||||
4. Свободное место на диске: не менее 150 ГБ свободного места на диске.
|
||||
5. Графический процессор: NVIDIA GeForce RTX 2060 Super с поддержкой CUDA 10.0 или более новой версии.
|
||||
__AutoAssembly__. Разрабатывается командой робототехников из компании Arrival, известного производителя электромобилей с R&D командой из Санкт-Петербурга. Фреймворк предназначен для автоматической роботизированной сборки напрямую из CAD. В научной публикации с описанием фреймворка представлена практическая реализация на примере двух манипуляторов Universal Robotics. Исходный код проекта не публикуется; многие технические решения (спецификации, схемы данных, описания языков, тип базы данных) неизвестны. Более подробный обзор см. по [ссылке](/docs/papers/auto-assembly).
|
||||
|
|
@ -1,412 +0,0 @@
|
|||
---
|
||||
title: Генерация датасетов
|
||||
---
|
||||
|
||||
Одной из подзадач управления робототехнической системой является задача обнаружения и классификации объектов в сцене, реализуемая с помощью камеры (машинного зрения). Одним из методов решения данной задачи является использование нейросетевой модели, полученной в ходе обучения на предварительно подготовленных наборах данных. Разработанный модуль генерации наборов данных (датасетов) позволяет автоматизировать процесс их подготовки. Полигональные модели экспортируются из CAD-системы - в результате получается mesh-файл формата `obj`. В ходе генерации формируется сцена для симуляции окружения робота (файл сцены в формате blend). В модуле используется пакет создания синтетических изображений BlenderProc, с помощью которого подготавливается набора данных для обучения нейросети.
|
||||
|
||||
## Обнаружение объектов (Object Detection)
|
||||
|
||||
### Описание API навыка
|
||||
|
||||
Вначале попытаемся описать полную последовательность действий по подготовке и использованию навыка обнаружения объектов. Задача обнаружения объектов сенсорами робота (в частности, RGB камерой в нашем случае) ставится в случае, например, когда необходимо в заданном окружении (сцене) определить наличие или отсутствие необходимых деталей для сборки изделия. Такие детали представлены в информационной среде в виде ассетов, хранимых в базе данных с заданными характеристиками. Поэтому входным параметром навыка обнаружения объектов является список ассетов, экземпляры которых в текущей задаче необходимо обнаруживать. Результатом использования навыка в информационной системе будет являться получение данных о заданном ассете на конкретном изображении, полученном с помощью RGB камеры.
|
||||
|
||||
Начальным этапом навыка является создание датасета, состоящего из синтетических изображений, полученных с использованием пакета [BlenderProc](https://github.com/DLR-RM/BlenderProc). Этот датасет представляет из себя набор файлов изображений и файлов меток к ним, а также файл аннотации, описывающий весь датасет в целом. Он имеет определённую структуру папок и будет использован для обучения нейросетевой модели обнаружения объектов на реальных изображениях в работе (runtime-режим). После создания такой датасет должен быть помещён в базу данных, как единый объект, с заданными характеристиками. В дальнейшем датасет может быть пополнен другими изображениями (например, фото из реального окружения робота), позволяющими произвести дообучение нейросети и улучшить качество работы навыка.
|
||||
|
||||
На втором этапе происходит обучение нейросетевой модели [YOLOv8](https://github.com/ultralytics/ultralytics). На выходе получаем файл весов модели, который также помещается в базу данных, с указанием версии этого файла и параметров обучения.
|
||||
|
||||
Теперь мы имеем всё необходимое для использования навыка обнаружения объектов (Object Detection) в реальном сценарии при управлении роботом в режиме runtime.
|
||||
|
||||
Рассмотрим наиболее общий вариант использования этого навыка в среде ROS2.
|
||||
|
||||
Первым шагом будет являться первоначальный запуск lifecycle-узла ROS2, отвечающего за работу навыка. Чтобы начать процесс обнаружения конкретной детали на изображении нужно выполнить стартовые действия по шаблону в дереве поведения, задав необходимые параметры процесса (топики получения изображения и выдачи результатов обнаружения, режим работы и другие). После решения поставленной задачи обнаружения конкретного объекта выполняются действия по шаблону приостановки работы навыка. Данные шаблоны деревьев поведения выполняются с помощью исполнителя [BehaviorTree](https://github.com/BehaviorTree/BehaviorTree.ROS2). Затем можно начать обнаружение другого объекта, вновь выполнив стартовый шаблон действий и подготовив новые параметры процесса.
|
||||
|
||||
Теперь перейдём к полному описанию данного API.
|
||||
|
||||
### Генерация датасета в формате COCO
|
||||
|
||||
Для создания датасета используется модуль на Python для BlenderProc. Внешними параметрами для модуля являются:
|
||||
- файл, описывающий параметры рандомизиции, а также объекты сцены с подготовленными мешами (файл *.json)
|
||||
- выходной каталог.
|
||||
|
||||
Формируется сцена для случайного размещения в ней объектов из описания. Затем производится рендеринг полученной сцены с рандомизацией параметров освещения, текстур и размещением камеры. Имена объектов должны совпадать с именами ассетов в нашей базе данных.
|
||||
В результате будет получен датасет в формате [BOP](../technologies/cv-perception-methods#соревнование-bop-benchmark-of-pose-estimation)
|
||||
|
||||
Пример запуска модуля генерации датасета:
|
||||
```bash
|
||||
blenderproc run renderBOPdataset2.py --form description.json --path /home/user/path/to/dataset
|
||||
```
|
||||
Пример файла description.json:
|
||||
```json
|
||||
{"output":{
|
||||
"datasetObjects":{
|
||||
"details":[
|
||||
{"name":"star",
|
||||
"inertia":{
|
||||
"ixx":0.1,"ixy":0,"ixz":0,"iyy":0.1,"iyz":0,"izz":0.1
|
||||
},
|
||||
"mass":"0",
|
||||
"visual":"/assets/libs/objects/star.dae",
|
||||
"collision":"/assets/libs/objects/star.stl",
|
||||
"type":"env",
|
||||
"material_path":"",
|
||||
"part_path":"/libs/objects/star.stl",
|
||||
"fbx":"/home/webservice/server/build/public/4c4f3909-74b0-4206-aec1-fc4acd3a1081/assets/libs/objects/star.fbx",
|
||||
"solidType":"active",
|
||||
"isSelect":true
|
||||
}
|
||||
]
|
||||
},
|
||||
"typedataset":"ObjectDetection",
|
||||
"models_randomization":{
|
||||
"loc_range_low":[-1,-1,0],"loc_range_high":[1,1,2]
|
||||
},
|
||||
"scene":{
|
||||
"objects":[
|
||||
{"name":"floor","collision_shape":"BOX","loc_xyz":[0,0,0],"rot_euler":[0,0,0],"material_randomization":{"specular":[0,1],"roughness":[0,1],"metallic":[0,1],"base_color":[[0,0,0,1],[1,1,1,1]}}},
|
||||
{"name":"star","collision_shape":"BOX","loc_xyz":[0,0,0.2],"rot_euler":[0,0,0],"material_randomization":{"specular":[0,1],"roughness":[0,1],"metallic":[0,1],"base_color":[[0,0,0,1],[1,1,1,1]}}
|
||||
],
|
||||
"lights":[
|
||||
{"id":1,"type":"SUN","loc_xyz":[5,5,5],"rot_euler":[-0.06,0.61,-0.19],"color_range_low":[0.5,0.5,0.5],"color_range_high":[1,1,1],"energy_range":[2,9]}
|
||||
]
|
||||
},
|
||||
"camera_position":{
|
||||
"center_shell":[0,0,0],
|
||||
"radius_range":[0.3,0.65],
|
||||
"elevation_range":[10,90]
|
||||
},
|
||||
"generation":{
|
||||
"n_cam_pose":3,
|
||||
"n_sample_on_pose":3,
|
||||
"n_series":222,
|
||||
"image_format":"JPEG",
|
||||
"image_size_wh":[640,480]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
В результате работы модуля в папке '/home/user/path/to/dataset' будет создана файловая структура с датасетом.
|
||||
|
||||
### Генерация датасета в формате BOP Challenge
|
||||
|
||||
Внешними параметрами для модуля являются:
|
||||
1. Файл, описывающий параметры рандомизиции, а также объекты сцены с подготовленными мешами (файл *.json)
|
||||
2. Выходной каталог.
|
||||
|
||||
Формируется сцена для случайного размещения в ней объектов из описания. Затем производится рендеринг полученной сцены с рандомизацией параметров освещения, текстур и размещением камеры. Имена объектов должны совпадать с именами ассетов в нашей базе данных.
|
||||
|
||||
Пример запуска модуля генерации датасета:
|
||||
```bash
|
||||
blenderproc run renderBOPdataset2.py --form description.json --path /home/user/path/to/dataset
|
||||
```
|
||||
|
||||
Пример файла description.json:
|
||||
```json
|
||||
{"output":{
|
||||
"datasetObjects":{
|
||||
"details":[
|
||||
{"name":"star",
|
||||
"inertia":{
|
||||
"ixx":0.1,"ixy":0,"ixz":0,"iyy":0.1,"iyz":0,"izz":0.1
|
||||
},
|
||||
"mass":"0",
|
||||
"visual":"/assets/libs/objects/star.dae",
|
||||
"collision":"/assets/libs/objects/star.stl",
|
||||
"type":"env",
|
||||
"material_path":"",
|
||||
"part_path":"/libs/objects/star.stl",
|
||||
"fbx":"/home/webservice/server/build/public/4c4f3909-74b0-4206-aec1-fc4acd3a1081/assets/libs/objects/star.fbx",
|
||||
"solidType":"active",
|
||||
"isSelect":true
|
||||
}
|
||||
]
|
||||
},
|
||||
"typedataset":"ObjectDetection",
|
||||
"models_randomization":{
|
||||
"loc_range_low":[-1,-1,0],"loc_range_high":[1,1,2]
|
||||
},
|
||||
"scene":{
|
||||
"objects":[
|
||||
{"name":"floor","collision_shape":"BOX","loc_xyz":[0,0,0],"rot_euler":[0,0,0],"material_randomization":{"specular":[0,1],"roughness":[0,1],"metallic":[0,1],"base_color":[[0,0,0,1],[1,1,1,1]}}},
|
||||
{"name":"star","collision_shape":"BOX","loc_xyz":[0,0,0.2],"rot_euler":[0,0,0],"material_randomization":{"specular":[0,1],"roughness":[0,1],"metallic":[0,1],"base_color":[[0,0,0,1],[1,1,1,1]}}
|
||||
],
|
||||
"lights":[
|
||||
{"id":1,"type":"SUN","loc_xyz":[5,5,5],"rot_euler":[-0.06,0.61,-0.19],"color_range_low":[0.5,0.5,0.5],"color_range_high":[1,1,1],"energy_range":[2,9]}
|
||||
]
|
||||
},
|
||||
"camera_position":{
|
||||
"center_shell":[0,0,0],
|
||||
"radius_range":[0.3,0.65],
|
||||
"elevation_range":[10,90]
|
||||
},
|
||||
"generation":{
|
||||
"n_cam_pose":3,
|
||||
"n_sample_on_pose":3,
|
||||
"n_series":222,
|
||||
"image_format":"JPEG",
|
||||
"image_size_wh":[640,480]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
В результате работы модуля в папке '/home/user/path/to/dataset' будет создана файловая структура с датасетом.
|
||||
|
||||
### Обучение модели Yolov8
|
||||
|
||||
Для обучения модели используется модуль на Python. Внешним параметром для модуля является:
|
||||
- каталог с датасетом, сгенерированный на первом этапе.
|
||||
|
||||
Пример запуска модуля обучения:
|
||||
```bash
|
||||
python train_Yolo.py --path /home/user/path/to/dataset --epoch 11 --outpath /home/user/path/to/weights
|
||||
```
|
||||
- path: путь к каталогу с датасетом
|
||||
- epoch 11: количество эпох обучения (пока рекомендуем 30-50)
|
||||
В результате работы создается файл весов нейросети с лучшими характеристиками обнаружения best.pt
|
||||
|
||||
### Использование навыка в ROS2 для обнаружения объекта на изображении (runtime)
|
||||
|
||||
1. Подготовить папку с файлами BT v.4
|
||||
* Папка /path/to/bt/
|
||||
* bt.xml
|
||||
```xml
|
||||
<root BTCPP_format="4">
|
||||
<BehaviorTree ID="Main">
|
||||
<Sequence>
|
||||
<Action ID="RbsAction" do="ObjectDetection" command="odConfigure" sid="a"></Action>
|
||||
</Sequence>
|
||||
</BehaviorTree>
|
||||
</root>
|
||||
```
|
||||
* skills.json
|
||||
```json
|
||||
{"skills": [
|
||||
{
|
||||
"sid": "a",
|
||||
"SkillPackage": {
|
||||
"name": "Robossembler", "version": "1", "format": "1.0"
|
||||
},
|
||||
"Module": {
|
||||
"node_name": "lc_yolo", "name": "ObjectDetection", "description": "Object detection skill with YOLOv8"
|
||||
},
|
||||
"BTAction": [
|
||||
{
|
||||
"name": "odConfigure",
|
||||
"type": "run",
|
||||
"param": [
|
||||
{
|
||||
"type": "weights",
|
||||
"dependency": {"object_name": "board", "weights_file": "/home/shalenikol/0_rbs/w_od_board.pt"}
|
||||
},
|
||||
{
|
||||
"type": "topic",
|
||||
"dependency": {
|
||||
"type": "topic",
|
||||
"topicType": "sensor_msgs/msg/Image",
|
||||
"sid": "7b832b17-3030-4758-aab5-96a5046797f7",
|
||||
"topicOut": "/robot_camera/image"
|
||||
},
|
||||
"isFilled": true
|
||||
}
|
||||
],
|
||||
"result": [],
|
||||
"typeAction": "ACTION"
|
||||
}
|
||||
],
|
||||
"topicsOut": [
|
||||
{
|
||||
"name": "lc_yolo/object_detection",
|
||||
"type": "rbs_skill_interfaces/msg/BoundBox"
|
||||
}
|
||||
],
|
||||
"Launch": {
|
||||
"executable": "od_yolo_lc.py",
|
||||
"package": "rbss_objectdetection"
|
||||
}
|
||||
}
|
||||
]}
|
||||
```
|
||||
|
||||
2. Запуск интерфейсной ноды с сервером навыка, реализующего алгоритм обнаружения объектов.
|
||||
|
||||
```bash
|
||||
ros2 launch rbs_bt_executor interface.launch.py bt_path:=/path/to/bt
|
||||
```
|
||||
|
||||
3. Запуск процесса обнаружения заданного объекта через дерево поведения.
|
||||
Выполняется командой:
|
||||
```bash
|
||||
ros2 launch rbs_bt_executor rbs_executor.launch.py bt_path:=/path/to/bt
|
||||
```
|
||||
После этого узел начинает публиковать в выходной топик информацию об обнаружении объекта на каждом полученном с камеры изображении.
|
||||
|
||||
4. Прекращение процесса обнаружения объекта.
|
||||
|
||||
Для завершения навыка нужно выполнить дерево поведения:
|
||||
```xml
|
||||
<root BTCPP_format="4">
|
||||
<BehaviorTree ID="Main">
|
||||
<Sequence>
|
||||
<Action ID="RbsAction" do="ObjectDetection" command="odStop" sid="b"></Action>
|
||||
</Sequence>
|
||||
</BehaviorTree>
|
||||
</root>
|
||||
```
|
||||
Файл skills.json
|
||||
```json
|
||||
{"skills": [
|
||||
{
|
||||
"sid": "b",
|
||||
"SkillPackage": { "name": "Robossembler", "version": "1", "format": "1.0" },
|
||||
"Module": {"node_name": "lc_yolo", "name": "ObjectDetection", "description": "Object detection skill with YOLOv8"},
|
||||
"BTAction": [
|
||||
{
|
||||
"name": "odStop",
|
||||
"type": "stop",
|
||||
"param": [],
|
||||
"result": [],
|
||||
"typeAction": "ACTION"
|
||||
}
|
||||
],
|
||||
"topicsOut": [
|
||||
{
|
||||
"name": "lc_yolo/object_detection",
|
||||
"type": "rbs_skill_interfaces/msg/BoundBox"
|
||||
}
|
||||
],
|
||||
"Launch": {
|
||||
"executable": "od_yolo_lc.py",
|
||||
"package": "rbss_objectdetection"
|
||||
}
|
||||
}
|
||||
]}
|
||||
```
|
||||
Команда запуска этого дерева та же, что и в пункте 3.
|
||||
После выполнения этих действий lifecycle-узел навыка перейдёт в начальное состояние и можно, повторив пункт 1-3, вновь запустить процесс обнаружения уже с другим объектом.
|
||||
ного модуля являются: модель объекта в формате `obj`, файл описания сцены в формате `blend` и параметры генерации. Интерфейс реализован через параметры командной строки (Command Line Interface — CLI):
|
||||
- `scene` (путь к файлу описания сцены в формате blend);
|
||||
- `obj_path`: путь к каталогу с файлами описания детектируемых объектов в формате `obj`;
|
||||
- `output_dir`: выходной каталог;
|
||||
- `vhacd_path`: каталог, в котором должен быть установлен или уже установлен vhacd;
|
||||
- `-imgs`: количество серий рендеринга (по 15 изображений в каждой серии) на выходе
|
||||
|
||||
Пример вызова:
|
||||
```bash
|
||||
blenderproc run objs2Yolov4dataset.py [scene] [obj_path] [output_dir] [vhacd_path] [–imgs 1]
|
||||
```
|
||||
|
||||
Пример полученных синтетических изображений из набора:
|
||||
|
||||
|
||||
|
||||
### Производительность
|
||||
|
||||
Процесс создания набора изображений для одной детали в количестве 3000 шт. занимает около 10 часов машинного времени (1 CPU Ryzen 3700X + 1 GPU Nvidia RTX 2060 Super), поэтому для снижения ресурсоёмкости работы алгоритма применяется оригинальный метод - на вход программы подаются вместе со сценой также набор 3D-моделей заданных объектов для их совместного включения в изображения, что соответствует реальным условиям работы, где необходимо обнаруживать и распознавать сразу множество различных объектов, представляющих детали сборки или оснастку. Помимо этого, данный подход позволяет сократить размер общего дискового пространства, занимаемого файлами с весами нейросетевых моделей всех деталей, что также полезно для прикладных применений.
|
||||
|
||||
## Оценка 6D положения объекта (Pose Estimation)
|
||||
|
||||
### Создание датасета
|
||||
|
||||
Этот этап точно такой же, как и в случае с Object Detection. Так как синтетический датасет формата [BOP](https://github.com/thodan/bop_toolkit/blob/master/docs/bop_datasets_format.md) содержит в аннотации истинные позиции заданных объектов в сцене (ground true pose), поэтому его можно использовать также и при обучения модели [DOPE](https://github.com/NVlabs/Deep_Object_Pose) для оценки 6D положения объекта.
|
||||
|
||||
|
||||
### Обучение модели [DOPE](https://github.com/NVlabs/Deep_Object_Pose/tree/master/train)
|
||||
|
||||
Для обучения модели используется скрипт на Python. Аргументом для скрипта является:
|
||||
- каталог с датасетом, сгенерированный на первом этапе.
|
||||
В ходе работы скрипта исходный датасет предварительно конвертируется в формат, который используется непосредственно при обучении модели DOPE.
|
||||
|
||||
Пример запуска модуля обучения:
|
||||
```bash
|
||||
python train_Dope.py --path /home/user/path/to/dataset --epoch 44 --outpath /home/user/path/to/weights --name weightsX
|
||||
```
|
||||
- path: путь к каталогу с датасетом
|
||||
- epoch: количество эпох обучения
|
||||
- name: наименование файла весов модели на выходе
|
||||
- outpath: выходной каталог
|
||||
В результате работы создается файл весов модели с лучшими характеристиками обнаружения weightsX.pth
|
||||
|
||||
### Использование навыка в ROS2 для оценки 6D-положения объекта на изображении (runtime)
|
||||
|
||||
Этот процесс аналогичен такому же при обнаружении объекта (YoloV8), здесь приведу лишь дерево (bt.xml) и файл описания скилов в дереве (skills.json).
|
||||
* Папка /path/to/bt/
|
||||
* bt.xml
|
||||
```xml
|
||||
<root BTCPP_format="4">
|
||||
<BehaviorTree ID="Main">
|
||||
<Sequence>
|
||||
<Action ID="RbsAction" do="PoseEstimation" command="peConfigure" sid="a"></Action>
|
||||
</Sequence>
|
||||
</BehaviorTree>
|
||||
</root>
|
||||
```
|
||||
* skills.json
|
||||
```json
|
||||
{"skills": [
|
||||
{
|
||||
"sid": "a",
|
||||
"SkillPackage": {"name": "Robossembler","version": "1.0","format": "1"},
|
||||
"Module": {"node_name": "lc_dope","name": "PoseEstimation","description": "Pose Estimation skill with DOPE"},
|
||||
"BTAction": [
|
||||
{
|
||||
"name": "peConfigure",
|
||||
"type": "run",
|
||||
"param": [
|
||||
{
|
||||
"type": "weights",
|
||||
"dependency": { "object_name": "knight", "weights_file": "/home/shalenikol/0_rbs/w_knight.pth", "dimensions": [0.03, 0.026, 0.065] }
|
||||
},
|
||||
{
|
||||
"type": "topic",
|
||||
"dependency": {
|
||||
"type": "topic",
|
||||
"topicType": "sensor_msgs/msg/Image",
|
||||
"topicOut": "/rgbd_camera/image"
|
||||
},
|
||||
"isFilled": true
|
||||
},
|
||||
{
|
||||
"type": "topic",
|
||||
"dependency": {
|
||||
"type": "topic",
|
||||
"topicType": "sensor_msgs/msg/CameraInfo",
|
||||
"topicOut": "/rgbd_camera/camera_info"
|
||||
},
|
||||
"isFilled": true
|
||||
}
|
||||
],
|
||||
"result": [],
|
||||
"typeAction": "ACTION"
|
||||
}
|
||||
],
|
||||
"topicsOut": [
|
||||
{
|
||||
"name": "lc_dope/pose_estimation",
|
||||
"type": "geometry_msgs/msg/Pose"
|
||||
}
|
||||
],
|
||||
"Launch": {
|
||||
"executable": "pe_dope_lc.py",
|
||||
"package": "rbss_poseestimation"
|
||||
},
|
||||
"Settings": {
|
||||
"output": {
|
||||
"params": [
|
||||
{
|
||||
"name": "publishDelay",
|
||||
"value": "0.5"
|
||||
},
|
||||
{
|
||||
"name": "tf2_send_pose",
|
||||
"value": "1"
|
||||
},
|
||||
{
|
||||
"name": "mesh_scale",
|
||||
"value": "0.001"
|
||||
}
|
||||
]
|
||||
},
|
||||
"type": "formBuilder"
|
||||
}
|
||||
}
|
||||
]}
|
||||
```
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
---
|
||||
title: Модуль управления виртуальными средами
|
||||
---
|
||||
|
||||
При управлении роботами в симуляторе Gazebo через фреймворк ROS2 возникает необходимость конфигурировать не только робота-манипулятора, но и саму сцену. Однако стандартный подход, основанный на конфигурационных файлах Gazebo, зачастую оказывается избыточным и недостаточно гибким для динамических сценариев, к которым относится обучение с подкреплением.
|
||||
|
||||
**env_manager** — это пакет, предназначенный для конфигурирования сцен в симуляторе Gazebo, предоставляющий более удобный и гибкий подход к созданию и настройке симуляционных сред.
|
||||
|
||||
## Возможности пакета
|
||||
|
||||
С последнего обновления модуль был полностью переработан. Если ранее его функции ограничивались указанием объектов, находящихся в среде, для работы в ROS2, то теперь он предоставляет инструменты для:
|
||||
- полного конфигурирования сцены,
|
||||
- настройки объектов наблюдения для ROS2.
|
||||
|
||||
Конфигурация осуществляется с использованием **датаклассов** или **YAML-файлов**, что соответствует декларативному подходу описания сцены. Это делает процесс настройки интуитивно понятным и легко масштабируемым. Пример файла описания сцены, а также файл с конфигурацией по умолчанию доступны [здесь](https://git.robossembler.org/nodes/seed.robossembler.org/rad:z46gtVRpXaXrGQM7Fxiqu7pLy7kip/tree/env_manager/rbs_runtime/config/default-scene-config.yaml).
|
||||
|
||||
## Возможности конфигурации
|
||||
|
||||
Модуль поддерживает добавление различных типов объектов в сцену, включая:
|
||||
- **Модель**
|
||||
- **Меш**
|
||||
- **Бокс**
|
||||
- **Цилиндр**
|
||||
- **Сферу**
|
||||
|
||||
Различие между "моделью" и "мешем" заключается в том, находится ли объект в библиотеке **rbs_assets_library** (подробнее о ней см. [соответствующий раздел](https://robossembler.org/docs/software/ros2#rbs_assets_library)). Дополнительно поддерживается **рандомизация объектов**, позволяющая случайным образом изменять их цвет и положение в сцене.
|
||||
|
||||
Помимо объектов, с помощью пакета можно настраивать:
|
||||
- **Источники света**
|
||||
- **Сенсоры**
|
||||
- **Роботов**
|
||||
- **Рабочие поверхности**
|
||||
|
||||
Каждый тип объекта обладает как параметрами размещения, так и параметрами рандомизации. Для камер предусмотрены настройки публикации данных:
|
||||
- изображения глубины
|
||||
- цветного изображения
|
||||
- облаков точек.
|
||||
|
||||
Параметры рандомизации могут включать в себя положение, ориентацию в заданных пользователем пределах, а также. Для рабочей поверхности также включается возможность рандомизации текстуры, а для робота имеется возможность рандомизировать его положения, в том числе конфигурацию и расположение базы робота.
|
||||
|
||||
## Архитектура и спецификации
|
||||
|
||||
Основная структура модуля включает обертки для добавления объектов в сцену. Полная спецификация доступных параметров и взаимосвязей между классами представлена в папке конфигураций. Для каждой категории объектов используются отдельные датаклассы, что упрощает организацию и модификацию параметров.
|
||||
|
||||
Диаграмма классов конфигурации сцены представлена ниже:
|
||||
|
||||
|
||||
*Диаграмма классов конфигурации сцены*
|
||||
|
||||
## Примеры
|
||||
|
||||
Ниже представлены различные сцены, созданные с использованием возможностей **env_manager**:
|
||||
|
||||
| **Сценарий 1** | **Сценарий 2** | **Сценарий 3** |
|
||||
|-----------------|-----------------|-----------------|
|
||||
|  |  |  |
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 779 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 90 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 82 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 752 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 750 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 474 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 463 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 508 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 243 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 98 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 270 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 935 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 74 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 176 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 628 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 267 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
|
|
@ -1,264 +0,0 @@
|
|||
<mxfile host="Electron" agent="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.7.17 Chrome/130.0.6723.59 Electron/33.0.2 Safari/537.36" version="24.7.17">
|
||||
<diagram name="Page-1" id="5otglrqMj2LtwML2cxqW">
|
||||
<mxGraphModel dx="927" dy="1094" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-2" value="" style="rounded=1;whiteSpace=wrap;html=1;arcSize=3;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="970" y="712.5" width="620" height="137.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-3" value="" style="rounded=1;whiteSpace=wrap;html=1;arcSize=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="970" y="315" width="620" height="345" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-4" value="" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;arcSize=6;" parent="1" vertex="1">
|
||||
<mxGeometry x="990" y="560" width="580" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-5" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#CC0000;startArrow=classic;startFill=1;" parent="1" source="WfpB3c1-lRLewIncIU-h-7" target="WfpB3c1-lRLewIncIU-h-8" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="1140" y="715" />
|
||||
<mxPoint x="1140" y="715" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-7" value="realsense camera" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1077.5" y="600" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-8" value="camera" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1085" y="760" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-9" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#CC0000;startArrow=classic;startFill=1;" parent="1" source="WfpB3c1-lRLewIncIU-h-10" target="WfpB3c1-lRLewIncIU-h-24" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-10" value="robot 1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1215" y="600" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-12" value="robot 2" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1357.5" y="600" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-13" value="ROS 2" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;fontStyle=1;fontSize=22;" parent="1" vertex="1">
|
||||
<mxGeometry x="1510" y="275" width="90" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-14" value="Аппаратные интерфейсы (Hardware interfaces) / Цифровые двойники (Digital Twins)" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="1035" y="560" width="490" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-16" value="" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;arcSize=6;" parent="1" vertex="1">
|
||||
<mxGeometry x="990" y="380" width="580" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-17" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;startArrow=classic;startFill=1;dashed=1;dashPattern=1 1;strokeColor=#001933;" parent="1" source="WfpB3c1-lRLewIncIU-h-18" target="WfpB3c1-lRLewIncIU-h-22" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-18" value="Skill N" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1220" y="410" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-19" value="Дерево поведения (Behaviour Tree)" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="1167.5" y="380" width="220" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-20" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;startArrow=classic;startFill=1;dashed=1;dashPattern=1 1;strokeColor=#001933;" parent="1" source="WfpB3c1-lRLewIncIU-h-21" target="WfpB3c1-lRLewIncIU-h-18" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-21" value="Skill M" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1000" y="410" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-22" value="Move to Pose" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1440" y="410" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-23" value="usb" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" parent="1" vertex="1">
|
||||
<mxGeometry x="1095" y="670" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-24" value="servodrive" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1215" y="760" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-25" value="" style="rounded=1;whiteSpace=wrap;html=1;arcSize=5;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="970" y="130" width="620" height="135" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-26" value="Web" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;fontStyle=1;fontSize=22;" parent="1" vertex="1">
|
||||
<mxGeometry x="1520" y="90" width="70" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-98" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=0;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;startArrow=open;startFill=0;strokeColor=#4D4D4D;endArrow=open;endFill=0;" parent="1" source="WfpB3c1-lRLewIncIU-h-28" target="WfpB3c1-lRLewIncIU-h-40" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-32" value="can" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" parent="1" vertex="1">
|
||||
<mxGeometry x="1227.5" y="670" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-38" value="websocket" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" parent="1" vertex="1">
|
||||
<mxGeometry x="1282.5" y="280" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-40" value="Серверная часть (Backend)" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" parent="1" vertex="1">
|
||||
<mxGeometry x="990" y="230" width="580" height="25" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-41" value="" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" parent="1" vertex="1">
|
||||
<mxGeometry x="990" y="145" width="580" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-44" value="Linux" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;fontStyle=1;fontSize=22;" parent="1" vertex="1">
|
||||
<mxGeometry x="1510" y="670" width="80" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-46" value="ros2 launch + [ args ]" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1430" y="730" width="140" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-49" value="rbs" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" parent="1" vertex="1">
|
||||
<mxGeometry x="1155" y="400" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-50" value="rbs" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" parent="1" vertex="1">
|
||||
<mxGeometry x="1365" y="400" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="V1WyhFd76DXo4EdTU4iS-2" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=1;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="WfpB3c1-lRLewIncIU-h-58" target="jR0a6fk9G7gRTK2krb-A-1" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-58" value="Оператор-технолог" style="shape=umlActor;verticalLabelPosition=bottom;verticalAlign=top;html=1;outlineConnect=0;" parent="1" vertex="1">
|
||||
<mxGeometry x="1447.5" y="40" width="30" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-59" value="" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;arcSize=6;" parent="1" vertex="1">
|
||||
<mxGeometry x="990" y="465" width="580" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-61" value="zmq" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" parent="1" vertex="1">
|
||||
<mxGeometry x="1135" y="280" width="50" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-62" value="Серверы навыков (Skill Servers)" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="1180" y="465" width="200" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-63" value="Dope 6D" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1000" y="495" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-64" value="Cartesian" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1310" y="495" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-65" value="MoveIt" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1440" y="495" width="120" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-66" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;startArrow=classic;startFill=1;dashed=1;dashPattern=1 1;strokeColor=#001933;endArrow=none;endFill=0;entryX=0.21;entryY=0.072;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" source="WfpB3c1-lRLewIncIU-h-59" target="WfpB3c1-lRLewIncIU-h-14" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="450" y="430" as="sourcePoint" />
|
||||
<mxPoint x="1140" y="610" as="targetPoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="1138" y="550" />
|
||||
<mxPoint x="1138" y="550" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-69" value="BT Builder" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#FFCCE6;" parent="1" vertex="1">
|
||||
<mxGeometry x="1392.5" y="182.5" width="80" height="25" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-70" value="Сцена" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#FFCCE6;" parent="1" vertex="1">
|
||||
<mxGeometry x="1300" y="182.5" width="82.5" height="25" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-76" value="Модели" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#FFCCE6;" parent="1" vertex="1">
|
||||
<mxGeometry x="1220" y="182.5" width="70" height="25" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-77" value="Датасеты" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#FFCCE6;" parent="1" vertex="1">
|
||||
<mxGeometry x="1142.5" y="182.5" width="65" height="25" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-78" value="Детали" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#FFCCE6;" parent="1" vertex="1">
|
||||
<mxGeometry x="1077.5" y="182.5" width="52.5" height="25" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-79" value="Проекты" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#FFCCE6;" parent="1" vertex="1">
|
||||
<mxGeometry x="1002.5" y="182.5" width="60" height="25" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-80" value="Object Detection YOLOv7" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1130" y="495" width="165" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-86" value="Мониторинг" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1482.5" y="182.5" width="80" height="25" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-88" value="Клиентская часть (Frontend)" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="1187.5" y="145" width="180" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-89" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;curved=0;fillColor=#e1d5e7;strokeColor=#9673a6;strokeWidth=2;startArrow=classic;startFill=1;" parent="1" source="WfpB3c1-lRLewIncIU-h-70" target="WfpB3c1-lRLewIncIU-h-46" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="1370" y="160" />
|
||||
<mxPoint x="1630" y="160" />
|
||||
<mxPoint x="1630" y="740" />
|
||||
</Array>
|
||||
<mxPoint x="700" y="730" as="sourcePoint" />
|
||||
<mxPoint x="660" y="110" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-90" value="Разработчик<br>&nbsp;серверов<br>навыков" style="shape=umlActor;verticalLabelPosition=bottom;verticalAlign=top;html=1;outlineConnect=0;" parent="1" vertex="1">
|
||||
<mxGeometry x="910" y="535" width="30" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-91" value="<span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: center; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(251, 251, 251); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">args</span>" style="text;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1600" y="712.5" width="40" height="25" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-95" value="<span style="text-align: center;">topic list</span>" style="text;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1600" y="130" width="60" height="37.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-96" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;startArrow=classic;startFill=1;strokeColor=#333333;" parent="1" source="WfpB3c1-lRLewIncIU-h-21" target="WfpB3c1-lRLewIncIU-h-63" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-99" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;startArrow=open;startFill=0;strokeColor=#4D4D4D;endArrow=open;endFill=0;exitX=0.26;exitY=-0.016;exitDx=0;exitDy=0;exitPerimeter=0;" parent="1" source="WfpB3c1-lRLewIncIU-h-16" target="WfpB3c1-lRLewIncIU-h-40" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="1110" y="280" as="sourcePoint" />
|
||||
<mxPoint x="1290" y="265" as="targetPoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="1141" y="270" />
|
||||
<mxPoint x="1140" y="270" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-28" value="Мост ROS 2 - Web" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;arcSize=9;" parent="1" vertex="1">
|
||||
<mxGeometry x="987.5" y="335" width="585" height="25" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-100" value="<span style="text-wrap: nowrap;">get_interfaces.py</span>" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1430" y="770" width="140" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<UserObject label="" id="WfpB3c1-lRLewIncIU-h-102">
|
||||
<mxCell style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1430" y="810" width="140" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-103" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;curved=0;fillColor=#e1d5e7;strokeColor=#9673a6;strokeWidth=2;" parent="1" source="WfpB3c1-lRLewIncIU-h-86" target="WfpB3c1-lRLewIncIU-h-102" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="1650" y="195" />
|
||||
<mxPoint x="1650" y="825" />
|
||||
</Array>
|
||||
<mxPoint x="1590" y="150" as="sourcePoint" />
|
||||
<mxPoint x="1580" y="790" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-106" value="simulate" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" parent="1" vertex="1">
|
||||
<mxGeometry x="1585" y="820" width="70" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="WfpB3c1-lRLewIncIU-h-109" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;curved=0;fillColor=#e1d5e7;strokeColor=#9673a6;strokeWidth=2;startArrow=classic;startFill=1;entryX=0.75;entryY=1;entryDx=0;entryDy=0;" parent="1" source="WfpB3c1-lRLewIncIU-h-100" target="WfpB3c1-lRLewIncIU-h-91" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="1630" y="785" />
|
||||
</Array>
|
||||
<mxPoint x="1343" y="153" as="sourcePoint" />
|
||||
<mxPoint x="1580" y="750" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="jR0a6fk9G7gRTK2krb-A-12" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="jR0a6fk9G7gRTK2krb-A-1" target="WfpB3c1-lRLewIncIU-h-77" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="1175" y="150" />
|
||||
<mxPoint x="1175" y="150" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="jR0a6fk9G7gRTK2krb-A-1" value="Модель предметной области (domain)" style="rounded=1;whiteSpace=wrap;html=1;verticalAlign=top;" parent="1" vertex="1">
|
||||
<mxGeometry x="970" y="40" width="410" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jR0a6fk9G7gRTK2krb-A-5" value="Метод работы&nbsp;2" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1115" y="70" width="120" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jR0a6fk9G7gRTK2krb-A-6" value="Метод работы&nbsp;3" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1245" y="70" width="120" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jR0a6fk9G7gRTK2krb-A-7" value="Метод работы 1" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="987.5" y="70" width="120" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jR0a6fk9G7gRTK2krb-A-8" value="Инженер <br>машинного<br>&nbsp;обучения" style="shape=umlActor;verticalLabelPosition=bottom;verticalAlign=top;html=1;outlineConnect=0;" parent="1" vertex="1">
|
||||
<mxGeometry x="910" y="145" width="30" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="V1WyhFd76DXo4EdTU4iS-5" value="Разработчик<br>&nbsp;драйверов" style="shape=umlActor;verticalLabelPosition=bottom;verticalAlign=top;html=1;outlineConnect=0;" parent="1" vertex="1">
|
||||
<mxGeometry x="910" y="737.5" width="30" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="V1WyhFd76DXo4EdTU4iS-8" value="Разработчик<br>&nbsp;сценариев<br>поведения" style="shape=umlActor;verticalLabelPosition=bottom;verticalAlign=top;html=1;outlineConnect=0;" parent="1" vertex="1">
|
||||
<mxGeometry x="910" y="380" width="30" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 250 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 602 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 373 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 53 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 126 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 111 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 104 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 80 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 135 KiB |
|
|
@ -1,164 +0,0 @@
|
|||
---
|
||||
title: Модуль исполнения планов
|
||||
---
|
||||
|
||||
Модуль исполнения планов (Robossembler Runtime) представляет собой набор пакетов ROS 2 (на данный момент Humble), которые реализуют логику управления роботом манипулятором, взаимодействие с виртуальным и реальным окружениями. Исходный код всех пакетов размещён на [gitlab.com/robossembler/robossembler-ros2](https://gitlab.com/robossembler/robossembler-ros2).
|
||||
|
||||
## Архитектура
|
||||
|
||||
|
||||
|
||||
## Пакеты ROS 2 и их функции
|
||||
|
||||
- **`env_manager`** - менеджер виртуальных сред:
|
||||
- **`env_manager`** - управление объектами в сцене симуляции Gazebo.
|
||||
- **`env_manager_interfaces`** - ROS 2 интерфейсы для конфигурации, загрузки, активации и выгрузки сред.
|
||||
- **`rbs_gym`** - модуль обучения с подкреплением: управление обучением, создание симуляционных сред, управление пространствами действий и наблюдений, утилиты. Предназначен для реализации среды обучения с подкреплением для роботов-манипуляторов. Он активно использует возможности пакета **env_manager**, упрощая управление сценой и настройку среды. Подробнее о нём в разделе [Сценарии использования](usecases).
|
||||
- **`rbs_runtime`** - запуск основного рантайма с использованием `env_manager`.
|
||||
- **`rbs_bringup`** - запуск сценариев: симуляция, реальный робот, многороботные конфигурации.
|
||||
- **`rbs_bt_executor`** - выполнение деревьев поведения с Behavior Tree CPP v4.
|
||||
- **`rbs_interface`** - интерфейс для связи деревьев поведения со скилл-серверами (рекомендуется объединить с `rbs_bt_executor`).
|
||||
- **`rbs_perception`** - модуль машинного зрения с различными версиями.
|
||||
- **`rbs_simulation`** - модели для симуляции (рекомендуется объединить с `env_manager` или `rbs_gym`).
|
||||
- **`rbs_skill_interfaces`** - общие интерфейсы для взаимодействия с скилл-серверами и деревьями поведения.
|
||||
- **`rbs_skill_servers`** - пакеты для скилл-серверов (рекомендуется заменить на индивидуальные пакеты для каждого сервера).
|
||||
- **`rbs_task_planner`** - планировщик задач на основе PDDL.
|
||||
- **`rbs_utils`** - утилиты для работы с конфигурациями, содержащими позиции захвата.
|
||||
- **`rbss_objectdetection`** - скилл-сервер для обнаружения объектов с YOLOv8.
|
||||
|
||||
## rbs_runtime
|
||||
|
||||
Модуль **rbs_runtime** предназначен для управления симуляцией в режиме реального времени. Если **env_manager** отвечает за конфигурирование сцены, а **rbs_gym** связывает обучаемых агентов с ROS2, то **rbs_runtime** используется для стандартного запуска симуляции без ограничения по времени. Этот модуль представляет собой обёртку для запуска **env_manager** как ROS2-ноды и реализует базовые сервисы управления средой. На данный момент доступен сервис сброса симуляции в начальное состояние. При этом, если для объектов сцены установлены параметры рандомизации, они будут пересчитаны и применены при каждом сбросе. Модуль обеспечивает интеграцию конфигураций среды в инфраструктуру ROS2 и позволяет легко запускать симуляцию, оставляя её гибкой для последующего расширения или взаимодействия.
|
||||
|
||||
## rbs_assets_library
|
||||
|
||||
**rbs_assets_library** представляет собой инструмент для интеграции трёхмерных объектов в симуляцию. Она содержит все необходимые ресурсы, включая возможность автоматического расчета инерциальных параметров на основе геометрии объекта. Это достигается благодаря использованию библиотеки **trimesh**, которая анализирует предоставленные модели и генерирует данные, необходимые для корректного воспроизведения физики объекта в симуляторе.
|
||||
|
||||
В библиотеку также входит скрипт для автоматической генерации изображений объектов с различных ракурсов. Эти изображения используются для создания датасета, применяемого в задачах сегментации (выделения объектов) на основе зрения. Для этого используется фреймворк [CNOS](https://arxiv.org/pdf/2307.11067), который интегрируется с библиотекой.
|
||||
|
||||
|
||||
*Пример сгенерированного датасета для CNOS, созданного с помощью скрипта из **rbs_assets_library***
|
||||
|
||||
### Возможности библиотеки
|
||||
|
||||
Библиотека предоставляет внешний API, который позволяет получать любую информацию о модели по её имени. Название модели формируется автоматически, исходя из имени папки, в которую она была помещена.
|
||||
|
||||
Для работы с геометрией объекта пользователю необходимо:
|
||||
1. Создать папку с именем модели.
|
||||
2. Разместить в ней файлы геометрии: `.dae` для визуализации и `.obj` или `.stl` для описания коллизии (на выбор).
|
||||
|
||||
После этого пользователь запускает скрипт, который предлагает:
|
||||
- выбрать модель для обработки
|
||||
- задать плотность материала детали
|
||||
|
||||
Если выбранная модель уже существует, скрипт перезапишет её данные. Такой подход позволяет эффективно генерировать конфигурации модели на основе предоставленных геометрических файлов и параметров материала.
|
||||
|
||||
### Пример использования
|
||||
|
||||
Тестирование возможностей **CNOS** проводилось через разработку навыка для инференса модели сегментации. Это стало возможным благодаря использованию предварительно обученных моделей, таких как **SAM** и **DINOv2**:
|
||||
- **SAM** обеспечивает высококачественную сегментацию изображения,
|
||||
- **DINOv2** используется для извлечения дополнительных признаков объектов.
|
||||
|
||||
Результаты тестирования показали успешное применение **CNOS** в симуляторе Gazebo. Камера, расположенная на эффекторе робота-манипулятора, фиксировала детали, как, например, "звезда".
|
||||
|
||||
Пример результатов представлен на рисунке:
|
||||
|
||||
|
||||
*Результаты тестирования **CNOS** в симуляторе Gazebo на примере детали "звезда"*
|
||||
|
||||
## robot_builder
|
||||
|
||||
Модуль **robot_builder** представляет собой универсальное решение для парсинга, конвертации и формирования конфигураций роботов. Его архитектура включает масштабируемый парсер и конвертер, а также дополнительные модули для обработки и использования распарсенной информации. **robot_builder** упрощает работу с конфигурациями роботов и обеспечивает гибкость в интеграции с другими инструментами.
|
||||
|
||||
На данный момент поддерживаются два формата:
|
||||
- **URDF** — стандартный формат для описания структуры роботов в ROS
|
||||
- **YAML** — формат, который выделяется своей универсальностью, читабельностью и возможностью ссылаться на внешние данные, что упрощает повторное использование уже описанной информации.
|
||||
|
||||
Архитектура модуля спроектирована так, чтобы её можно было легко расширять, добавляя новые форматы или улучшая существующие функции. Классовая диаграмма, иллюстрирующая структуру модуля.
|
||||
|
||||
### Пример использования
|
||||
|
||||
Генерацию контроллеров управления для нового робота-манипулятора. За счет парсинга инфомации из URDF робота производится классификация необходимых параметров из файла. Таким образом, проверяется стабильность при вычислении конфигурационных параметров контроллеров для разных роботов-манипуляторов.
|
||||
|
||||
| AR4 | Robossembler Arm |
|
||||
| -------------- | --------------- |
|
||||
|  |  |
|
||||
|
||||
На рисунках можно заменить, что требуемые параметры вычисляются должным образом. Два робота с разным числом степеней свободы и разными наименовниями конечных звеньев формируют
|
||||
рабочую конфигурацию. Для проверки движений обоих роботов можно использовать метод телеуправления роботов с помощью интерактивного маркера входящий в состав Rviz2. Для передачи сигналов с интерактивного маркера используется отдельный контроллер `motion_control_handle`, который также генерируется в автоматизированном режиме для любого робота и который позволяет передавать управляющие сигналы на `cartesian_motion_controller`, конфигурация которого представлена на рисунке выше.
|
||||
|
||||
Пример запуска конфигурации робота AR4:
|
||||
|
||||
|
||||
Пример запуска конфигурации робота Robossembler Arm
|
||||
|
||||
|
||||
|
||||
## rbs_skill_servers
|
||||
|
||||
Модуль **rbs_skill_servers** представляет собой систему управления движением робота. Он обеспечивает удобство работы с навыками, не привязан к MoveIt2 и снижает общую сложность конфигурации, которую MoveIt2 накладывает на экосистему ROS 2. Для выполнения задач, где не требуется избегать препятствий, использование MoveIt2 избыточно. Более того, прежняя система навыков движения была тесно связана с типом используемых контроллеров: пользователю приходилось либо ограничиваться навыками, использующими один и тот же контроллер, либо вручную переключать контроллеры. Новая библиотека решает эти проблемы, предоставляя гибкий инструмент в виде обёртки для ROS2 Action Server, который скрывает логику работы с контроллерами.
|
||||
|
||||
Теперь при разработке нового навыка движения пользователю нужно указать:
|
||||
- **Контроллер действия**, который будет управлять движением
|
||||
- **Контроллеры состояния**, от которых навык будет получать обратную связь
|
||||
- **Параметры**, которые контроллер действия может запрашивать у пользователя
|
||||
|
||||
Для реализации навыка пользователь должен написать функцию `executeAction()`, определяющую логику успешного или неуспешного выполнения задачи. Автоматическое переключение контроллеров реализовано через запросы к сервисам ROS 2 в ноде `controller_manager`. Конфигурация контроллеров формируется автоматически на основе URDF-модели робота с использованием библиотеки `robot_builder`.
|
||||
|
||||
Диаграмма последовательности работы с переключение навыков представлена ниже:
|
||||
|
||||
|
||||
*Диаграмма последовательности работы библиотеки навыков с автоматическим переключением контроллеров.*
|
||||
|
||||
#### Преимущества и возможности
|
||||
|
||||
1. **Автоматизированное переключение контроллеров**
|
||||
Это упрощает вызов навыков из дерева поведения, даже если они используют разные контроллеры.
|
||||
2. **Расширенный набор навыков**
|
||||
Помимо движений через декартовы контроллеры, добавлены:
|
||||
- Навыки для движения в конфигурационном пространстве робота.
|
||||
- Навыки в пространстве задач, которые используют обратную кинематику для избегания сингулярных положений.
|
||||
3. **Улучшение декартовых контроллеров.**
|
||||
В новой версии движения по декартовым траекториям обрабатываются с использованием линейной интерполяции между точками. Это позволяет избегать неконтролируемых отклонений при попадании в сингулярные положения, делая движения робота более плавными и предсказуемыми.
|
||||
|
||||
Переработка системы навыков значительно повысила надёжность управления движением и упростила разработку новых задач.
|
||||
|
||||
### Пример использования
|
||||
|
||||
Проведём инициализацию системы с контроллером, который не соответствует стартовому, и произведём запрос на движение навыком, который требует другой контроллер. Изначально таблица загруженных контроллеров выглядит следующим образом:
|
||||
|
||||
|
||||
*Состояние контроллеров перед запуском навыка*
|
||||
|
||||
Отправляемые запрос на движение выглядит следеющим образом
|
||||
|
||||
|
||||
*Отправляемый запрос на выполнение движения навыком*
|
||||
|
||||
Видно, что навык запрос отправляется для навыка `mtp_jtc`. Данный навык представляет собой решение обратной задачи кинематики для целевой точки и планирование движения в конфигурационном пространстве
|
||||
робота. Видно, что навык вернул результат SUCEEDED, что является успешным выполнением в данном случае
|
||||
|
||||
Общий вид логированных данных выглядит следующим образом
|
||||
|
||||
|
||||
*Логи при выполнении навыка*
|
||||
|
||||
Приведём комментарий к выводу:
|
||||
- Изначально запрос отправляется для робота и менем rbs_arm;
|
||||
- Производится запрос для получения текущего состояния контроллеров;
|
||||
- Производится попытка загрузка требуемого контроллера;
|
||||
- Контроллер успешно загружен и сконфигурирован;
|
||||
- Производится проверка всех загруженных контроллеров на возможные конфликты аппаратных интерфейсов;
|
||||
- Найден конфликтующий контроллер с именем cartesian_motion_controller;
|
||||
- Теперь контроллер активирован, а конфликтный контроллер деактивирован;
|
||||
- Проверяем, есть ли в навыке параметр joints;
|
||||
- Подключаемся к серверу параметров контроллера и запрашиваем необходимые параметры;
|
||||
- Начинаем выполнения цели;
|
||||
- Начинаем решение обратной задачи кинематики;
|
||||
- Начинаем интерполяцию траектории в конфигурационном пространстве робота;
|
||||
- Отправляем результат в целевой контроллер;
|
||||
- Принимаем ответ, что движение выполнено успешно;
|
||||
|
||||
После завершения операции можно вывести список состояний контроллеров:
|
||||
|
||||
|
||||
|
|
@ -1,112 +0,0 @@
|
|||
# Инструкция по добавлению нового робота в фреймворк Robossembler ROS 2
|
||||
|
||||
Прежде всего необходимо скачать пакет робота, содержащий файлы `xacro` или `urdf`, а также файлы геометрии робота в формате `.stl`, `.dae`, `.obj` и других.
|
||||
|
||||
Перед началом работы важно ознакомиться с основными аспектами формата [xacro](https://github.com/ros/xacro/wiki). Этот формат позволяет переиспользовать существующие фрагменты URDF-описания робота, что упрощает создание и модификацию описания.
|
||||
|
||||
### Шаги по добавлению нового робота:
|
||||
|
||||
1. **Установка пакета робота**
|
||||
После установки пакета робота создайте файл `xacro_args.yaml` в директории `{description_package}/config/`. В этом файле необходимо указать аргументы для преобразования xacro-файла в URDF.
|
||||
|
||||
2. **Настройка запуска**
|
||||
Отредактируйте файл `rbs_bringup/launch/rbs_bringup.launch.py`, указав параметры для запуска робота.
|
||||
|
||||
Пример стандартной реализации:
|
||||
```python
|
||||
main_script = IncludeLaunchDescription(
|
||||
PythonLaunchDescriptionSource(
|
||||
[
|
||||
PathJoinSubstitution(
|
||||
[FindPackageShare("rbs_runtime"), "launch", "runtime.launch.py"]
|
||||
)
|
||||
]
|
||||
),
|
||||
launch_arguments={
|
||||
"with_gripper": "true",
|
||||
"gripper_name": "rbs_gripper",
|
||||
"robot_type": "rbs_arm",
|
||||
"description_package": "rbs_arm",
|
||||
"description_file": "rbs_arm_modular.xacro",
|
||||
"robot_name": "rbs_arm",
|
||||
"use_moveit": "false",
|
||||
"moveit_config_package": "rbs_arm",
|
||||
"moveit_config_file": "rbs_arm.srdf.xacro",
|
||||
"use_sim_time": "true",
|
||||
"hardware": "gazebo",
|
||||
"use_controllers": "true",
|
||||
"scene_config_file": "",
|
||||
"base_link_name": "base_link",
|
||||
"ee_link_name": "gripper_grasp_point",
|
||||
"control_space": "task",
|
||||
"control_strategy": "position",
|
||||
}.items(),
|
||||
)
|
||||
```
|
||||
Здесь выполняется запуск другого launch-файла с указанными аргументами. Ниже приводится описание каждого аргумента.
|
||||
|
||||
### Описание параметров:
|
||||
|
||||
- **`with_gripper`**
|
||||
Указывает, есть ли на роботе захватное устройство (гриппер). Если значение `true`, будет настроен и запущен `gripper_controller`.
|
||||
|
||||
- **`gripper_name`**
|
||||
Используется как ключевое слово для указания линков и джоинтов, относящихся к грипперу. Также применяется в xacro-аргументах.
|
||||
|
||||
- **`robot_type`**
|
||||
Обозначает группу роботов одного типа. Например, все роботы с разными именами, но одинаковой конструкцией.
|
||||
|
||||
- **`description_package`**
|
||||
Пакет, содержащий описание URDF робота. Обязательный параметр. Используется для определения пути к файлу описания и конфигурации контроллеров.
|
||||
|
||||
- **`description_file`**
|
||||
Имя файла описания, который должен находиться в `{description_package}/urdf/`.
|
||||
|
||||
- **`robot_name`**
|
||||
Уникальное имя робота, которое позволяет отличить его от других в сцене.
|
||||
|
||||
- **`use_moveit`**
|
||||
Указывает, нужно ли использовать [MoveIt 2](https://moveit.picknik.ai/humble/index.html). Для базовых перемещений MoveIt 2 не обязателен, но для работы с препятствиями рекомендуется его включить.
|
||||
|
||||
- **`moveit_config_package`**
|
||||
Имя пакета конфигурации MoveIt 2, который генерируется на основе `{description_package}`. Обязательный параметр, если используется MoveIt 2.
|
||||
|
||||
- **`moveit_config_file`**
|
||||
Файл запуска MoveIt 2, находящийся в `{moveit_config_package}/launch/`.
|
||||
|
||||
- **`use_sim_time`**
|
||||
Обязательный параметр при работе в симуляции. Обеспечивает синхронизацию времени с симулятором.
|
||||
|
||||
- **`hardware`**
|
||||
Указывает интерфейс для управления роботом. Например, `gazebo`. Используется в основном в xacro-файлах.
|
||||
|
||||
- **`use_controllers`**
|
||||
Указывает, нужно ли использовать стандартные контроллеры. Если значение `false`, робот не сможет двигаться. Влияет на запуск файла `rbs_bringup/launch/control.launch.py`.
|
||||
|
||||
- **`scene_config_file`**
|
||||
Файл конфигурации сцены в формате YAML. Пример можно найти `env_manager/rbs_runtime/config/default-scene-config.yaml`. Обратите внимание на соответствие количества степеней свободы робота.
|
||||
|
||||
- **`base_link_name`**
|
||||
Имя базового линка, от которого начинается робот. Важно для настройки навыков. Рекомендуется свериться с URDF.
|
||||
|
||||
- **`ee_link_name`**
|
||||
Имя конечного линка (энд-эффектора), где заканчивается робот. Этот параметр также настраивается на основе URDF.
|
||||
|
||||
- **`control_space`**
|
||||
Указывает, в каком пространстве робот будет управляться.
|
||||
Возможные значения:
|
||||
- `task` — управление в пространстве задач (например, с использованием позиций и ориентации в рабочем пространстве).
|
||||
- `joint` — управление в пространстве суставов (например, с использованием угловых значений для каждого сустава робота).
|
||||
Значение по умолчанию: `task`.
|
||||
|
||||
- **`control_strategy`**
|
||||
Указывает стратегию управления роботом.
|
||||
Возможные значения:
|
||||
- `position` — управление положением, когда задаются желаемые позиции для суставов или рабочей точки.
|
||||
- `velocity` — управление скоростью, когда задаются желаемые скорости движения.
|
||||
- `effort` — управление усилием, когда задаются моменты или силы, прикладываемые к суставам.
|
||||
Значение по умолчанию: `position`.
|
||||
|
||||
- **`interactive`**
|
||||
Указывает, нужно ли запускать контроллер `motion_control_handle`.
|
||||
Значение по умолчанию: `true`.
|
||||
|
|
@ -1,77 +0,0 @@
|
|||
# Инструкция по установке фреймворка
|
||||
|
||||
## Шаг 1: Установка ROS2 Humble
|
||||
|
||||
Для начала установите [ROS2 Humble](https://docs.ros.org/en/humble/Installation/Ubuntu-Install-Debs.html).
|
||||
Рекомендуется минимальная установка `ros-humble-ros-base`, а также пакет `ros-dev-tools`.
|
||||
|
||||
## Шаг 2: Проверка среды ROS2
|
||||
|
||||
Перед продолжением убедитесь, что среда ROS2 активирована. Для этого выполните:
|
||||
```sh
|
||||
source /opt/ros/humble/setup.bash
|
||||
```
|
||||
|
||||
## Шаг 3: Если Вы этого не делали то сделайте
|
||||
```sh
|
||||
sudo rosdep init
|
||||
rosdep update
|
||||
```
|
||||
|
||||
## Шаг 4: Установка фреймворка
|
||||
|
||||
```sh
|
||||
cd
|
||||
mkdir -p robossembler-ws/src && cd robossembler-ws/src
|
||||
git clone --recurse-submodules https://gitlab.com/robossembler/robossembler-ros2.git
|
||||
```
|
||||
|
||||
Далее необходимо собрать [`ros2_control`](https://github.com/ros-controls/ros2_control) из исходников, используя этот [форк](https://github.com/solid-sinusoid/ros2_control/tree/gz-ros2-cartesian-controllers).
|
||||
Также доступна альтернатива с использованием [`vsctool`](https://github.com/dirk-thomas/vcstool), который входит в состав базовых пакетов ROS2.
|
||||
|
||||
Если вы решили использовать `vcstool`, нужные пакеты будут клонированы в тоже рабочее пространство, что и сам фреймворк. Команда для этого выглядит следующим образом:
|
||||
```sh
|
||||
vcs import . < robossembler-ros2/repos/all-deps.repos
|
||||
```
|
||||
|
||||
Вы также можете установить все необходимые библиотеки Python, выполнив команду:
|
||||
```shell
|
||||
pip install -r robossembler-ros2/repos/requirements.txt
|
||||
# Если Вы получили ошибку с установкой Shapely
|
||||
sudo apt install libgeos-dev
|
||||
```
|
||||
|
||||
> **[!ВНИМАНИЕ]**
|
||||
> Убедитесь, что у вас установлен `git lfs`. В файле `requirements.txt` указан модуль `rbs_assets_library`, который содержит большие файлы и устанавливается как Python-модуль.
|
||||
|
||||
Эти команды нужно выполнять в директории `robossembler-ws/src/`.
|
||||
|
||||
Установка зависимостей при помощи `rosdep`
|
||||
```sh
|
||||
cd ~/robossembler-ws
|
||||
rosdep install --from-paths src -y --ignore-src --rosdistro ${ROS_DISTRO}
|
||||
```
|
||||
|
||||
Сборка фреймворка при помощи `colcon`
|
||||
```sh
|
||||
colcon build
|
||||
```
|
||||
|
||||
## Полная последовательность команд
|
||||
|
||||
Ниже приведён полный набор команд для настройки фреймворка:
|
||||
```sh
|
||||
cd
|
||||
mkdir -p robossembler-ws/src && cd robossembler-ws/src
|
||||
git clone --recurse-submodules https://gitlab.com/robossembler/robossembler-ros2.git
|
||||
# Или, если вы предпочитаете Radicle:
|
||||
git clone --recurse-submodules https://seed.robossembler.org/z46gtVRpXaXrGQM7Fxiqu7pLy7kip.git robossembler-ros2
|
||||
rad clone rad:z46gtVRpXaXrGQM7Fxiqu7pLy7kip
|
||||
|
||||
vcs import . < robossembler-ros2/repos/all-deps.repos
|
||||
pip install -r robossembler-ros2/repos/requirements.txt
|
||||
cd ..
|
||||
rosdep install --from-paths src -y --ignore-src --rosdistro ${ROS_DISTRO}
|
||||
colcon build
|
||||
```
|
||||
|
||||
|
|
@ -1,156 +0,0 @@
|
|||
---
|
||||
title: Пример обучения и запуска навыка Object Detection
|
||||
---
|
||||
|
||||
## Унифицированное API
|
||||
|
||||
Вначале попытаемся описать полную последовательность действий по подготовке и использованию навыка обнаружения объектов. Задача обнаружения объектов сенсорами робота (в частности, RGB камерой в нашем случае) ставится в случае, например, когда необходимо в заданном окружении (сцене) определить наличие или отсутствие необходимых деталей для сборки изделия. Такие детали представлены в информационной среде в виде ассетов, хранимых в базе данных с заданными характеристиками. Поэтому входным параметром навыка обнаружения объектов является список ассетов, экземпляры которых в текущей задаче необходимо обнаруживать. Результатом использования навыка в информационной системе будет являться получение данных о заданном ассете на конкретном изображении, полученном с помощью RGB камеры.
|
||||
|
||||
Начальным этапом навыка является создание датасета, состоящего из синтетических изображений, полученных с использованием пакета [BlenderProc](https://github.com/DLR-RM/BlenderProc). Этот датасет представляет из себя набор файлов изображений и файлов меток к ним, а также файл аннотации, описывающий весь датасет в целом. Он имеет определённую структуру папок и будет использован для обучения нейросетевой модели обнаружения объектов на реальных изображениях в работе (runtime-режим). После создания такой датасет должен быть помещён в базу данных, как единый объект, с заданными характеристиками. В дальнейшем датасет может быть пополнен другими изображениями (например, фото из реального окружения робота), позволяющими произвести дообучение нейросети и улучшить качество работы навыка.
|
||||
|
||||
На втором этапе происходит обучение нейросетевой модели [YOLOv8](https://github.com/ultralytics/ultralytics). На выходе получаем файл весов модели, который также помещается в базу данных, с указанием версии этого файла и параметров обучения.
|
||||
|
||||
Теперь мы имеем всё необходимое для использования навыка обнаружения объектов (Object Detection) в реальном сценарии при управлении роботом в режиме runtime.
|
||||
|
||||
Рассмотрим наиболее общий вариант использования этого навыка в среде ROS2.
|
||||
|
||||
Первым шагом будет являться первоначальный запуск lifecycle-узла ROS2, отвечающего за работу навыка. Чтобы начать процесс обнаружения конкретной детали на изображении нужно выполнить стартовые действия по шаблону в дереве поведения, задав необходимые параметры процесса (топики получения изображения и выдачи результатов обнаружения, режим работы и другие). После решения поставленной задачи обнаружения конкретного объекта выполняются действия по шаблону приостановки работы навыка. Данные шаблоны деревьев поведения выполняются с помощью исполнителя [BehaviorTree](https://github.com/BehaviorTree/BehaviorTree.ROS2). Затем можно начать обнаружение другого объекта, вновь выполнив стартовый шаблон действий и подготовив новые параметры процесса.
|
||||
|
||||
Теперь перейдём к полному описанию данного API.
|
||||
|
||||
## Этап 1. Создание датасета
|
||||
|
||||
См. раздел [Генерация датасетов](../dataset-generator#датасет-для-обучения-обнаружению-в-формате-bop-challenge)
|
||||
|
||||
## Этап 2. Обучение модели Yolov8
|
||||
|
||||
Для обучения модели используется модуль на Python. Внешним параметром для модуля является:
|
||||
- каталог с датасетом, сгенерированный на первом этапе.
|
||||
|
||||
Пример запуска модуля обучения:
|
||||
```bash
|
||||
python train_Yolo.py --path /home/user/path/to/dataset --epoch 11 --outpath /home/user/path/to/weights
|
||||
```
|
||||
- path: путь к каталогу с датасетом
|
||||
- epoch 11: количество эпох обучения (пока рекомендуем 30-50)
|
||||
В результате работы создается файл весов нейросети с лучшими характеристиками обнаружения best.pt
|
||||
|
||||
## Этап 3. Использование навыка в ROS2 для обнаружения объекта на изображении (runtime)
|
||||
|
||||
### Подготовить папку с файлами BT v.4
|
||||
* Папка /path/to/bt/
|
||||
* bt.xml
|
||||
```xml
|
||||
<root BTCPP_format="4">
|
||||
<BehaviorTree ID="Main">
|
||||
<Sequence>
|
||||
<Action ID="RbsAction" do="ObjectDetection" command="odConfigure" sid="a"></Action>
|
||||
</Sequence>
|
||||
</BehaviorTree>
|
||||
</root>
|
||||
```
|
||||
* skills.json
|
||||
```json
|
||||
{"skills": [
|
||||
{
|
||||
"sid": "a",
|
||||
"SkillPackage": {
|
||||
"name": "Robossembler", "version": "1", "format": "1.0"
|
||||
},
|
||||
"Module": {
|
||||
"node_name": "lc_yolo", "name": "ObjectDetection", "description": "Object detection skill with YOLOv8"
|
||||
},
|
||||
"BTAction": [
|
||||
{
|
||||
"name": "odConfigure",
|
||||
"type": "run",
|
||||
"param": [
|
||||
{
|
||||
"type": "weights",
|
||||
"dependency": {"object_name": "board", "weights_file": "/home/shalenikol/0_rbs/w_od_board.pt"}
|
||||
},
|
||||
{
|
||||
"type": "topic",
|
||||
"dependency": {
|
||||
"type": "topic",
|
||||
"topicType": "sensor_msgs/msg/Image",
|
||||
"sid": "7b832b17-3030-4758-aab5-96a5046797f7",
|
||||
"topicOut": "/robot_camera/image"
|
||||
},
|
||||
"isFilled": true
|
||||
}
|
||||
],
|
||||
"result": [],
|
||||
"typeAction": "ACTION"
|
||||
}
|
||||
],
|
||||
"topicsOut": [
|
||||
{
|
||||
"name": "lc_yolo/object_detection",
|
||||
"type": "rbs_skill_interfaces/msg/BoundBox"
|
||||
}
|
||||
],
|
||||
"Launch": {
|
||||
"executable": "od_yolo_lc.py",
|
||||
"package": "rbss_objectdetection"
|
||||
}
|
||||
}
|
||||
]}
|
||||
```
|
||||
|
||||
### Запуск интерфейсной ноды с сервером навыка, реализующего алгоритм обнаружения объектов.
|
||||
|
||||
```bash
|
||||
ros2 launch rbs_bt_executor interface.launch.py bt_path:=/path/to/bt
|
||||
```
|
||||
|
||||
### Запуск процесса обнаружения заданного объекта через дерево поведения.
|
||||
Выполняется командой:
|
||||
```bash
|
||||
ros2 launch rbs_bt_executor rbs_executor.launch.py bt_path:=/path/to/bt
|
||||
```
|
||||
После этого узел начинает публиковать в выходной топик информацию об обнаружении объекта на каждом полученном с камеры изображении.
|
||||
|
||||
### Прекращение процесса обнаружения объекта.
|
||||
|
||||
Для завершения навыка нужно выполнить дерево поведения:
|
||||
```xml
|
||||
<root BTCPP_format="4">
|
||||
<BehaviorTree ID="Main">
|
||||
<Sequence>
|
||||
<Action ID="RbsAction" do="ObjectDetection" command="odStop" sid="b"></Action>
|
||||
</Sequence>
|
||||
</BehaviorTree>
|
||||
</root>
|
||||
```
|
||||
Файл skills.json
|
||||
```json
|
||||
{"skills": [
|
||||
{
|
||||
"sid": "b",
|
||||
"SkillPackage": { "name": "Robossembler", "version": "1", "format": "1.0" },
|
||||
"Module": {"node_name": "lc_yolo", "name": "ObjectDetection", "description": "Object detection skill with YOLOv8"},
|
||||
"BTAction": [
|
||||
{
|
||||
"name": "odStop",
|
||||
"type": "stop",
|
||||
"param": [],
|
||||
"result": [],
|
||||
"typeAction": "ACTION"
|
||||
}
|
||||
],
|
||||
"topicsOut": [
|
||||
{
|
||||
"name": "lc_yolo/object_detection",
|
||||
"type": "rbs_skill_interfaces/msg/BoundBox"
|
||||
}
|
||||
],
|
||||
"Launch": {
|
||||
"executable": "od_yolo_lc.py",
|
||||
"package": "rbss_objectdetection"
|
||||
}
|
||||
}
|
||||
]}
|
||||
```
|
||||
Команда запуска этого дерева та же, что и в пункте 3.
|
||||
После выполнения этих действий lifecycle-узел навыка перейдёт в начальное состояние и можно, повторив пункт 1-3, вновь запустить процесс обнаружения уже с другим объектом.
|
||||
|
|
@ -1,142 +0,0 @@
|
|||
---
|
||||
title: Сценарии использования
|
||||
---
|
||||
|
||||
Фреймворк может найти достаточно широкое распространение. Несмотря на то, что основной задачей фреймворка являлась автоматизация процесса разработки программ роботизированной сборки, программное обеспечение может применяться также и для других задач.
|
||||
|
||||
В частности,
|
||||
- веб-сервис с модулями генерации датасетов и интерфейсом создания новых навыков может применяться для запуска любых других поддерживающих API навыков, не связанным напрямую с задачей сборки изделий;
|
||||
- модуль исполнения программ ROS 2 включает в себя довольно гибкую систему управления исполнением с помощью деревьев поведения и может быть применён к любым задачам планирования, требующих модульности и реактивности;
|
||||
- для студентов, исследователей и инженеров фреймворк может упростить разработку и отладку программного обеспечения за счёт использования функций высокого уровня абстракции при решении задач манипулирования.
|
||||
|
||||
Ниже рассмотрены сценарии использования, которые были разработаны командой Robossembler.
|
||||
|
||||
## Обучение с подкреплением - rbs_gym
|
||||
|
||||
Модуль **rbs_gym** предназначен для реализации среды обучения с подкреплением для роботов-манипуляторов. Он активно использует возможности открытой библиотеки Робосборщик, упрощая управление сценой и настройку среды.
|
||||
|
||||
Основные компоненты модуля обеспечивают:
|
||||
- получение пространства наблюдения,
|
||||
- передачу управляющих сигналов агенту,
|
||||
- рандомизацию параметров среды,
|
||||
- настройку задач, определяющих награды и условия для агента.
|
||||
|
||||
### Пространства наблюдения и действий
|
||||
|
||||
**Пространство наблюдения** включает:
|
||||
- скорость на эффекторе робота,
|
||||
- положения суставов робота,
|
||||
- изображения с камеры (глубина, цвет или облака точек).
|
||||
|
||||
**Пространство действий** позволяет:
|
||||
- отправлять управляющие сигналы в виде усилий или скоростей в пространстве задач робота,
|
||||
- управлять положением захватного устройства,
|
||||
- задавать усилия в конфигурационном пространстве робота.
|
||||
|
||||
### Гибкая настройка агентов
|
||||
|
||||
В составе модуля реализован класс **ExperimentManager**, который управляет предварительной настройкой агентов обучения. Конфигурации описываются в формате YAML. Пример гиперпараметров для алгоритма TD3 доступен [здесь](https://git.robossembler.org/nodes/seed.robossembler.org/rad:z46gtVRpXaXrGQM7Fxiqu7pLy7kip/tree/env_manager/rbs_gym/hyperparams/td3.yml).
|
||||
|
||||
Поддерживаются следующие алгоритмы обучения:
|
||||
- [TD3](https://arxiv.org/abs/1802.09477)
|
||||
- [SAC](https://arxiv.org/abs/1801.01290)
|
||||
- [TQC](https://arxiv.org/abs/2005.04269)
|
||||
|
||||
### Общая структура и примеры
|
||||
|
||||
Общий вид среды обучения для задачи достиженая точки пространства представлен на изображении:
|
||||
|
||||
|
||||
|
||||
_Общий вид среды для задачи "достижения точки" в **rbs_gym**_
|
||||
|
||||
На рисунке точка отмечена зеленым шаром. Каждую эпоху обучения выбираются разные позиции для робота в конфигурационном пространстве, а также позиция объекта выбирается случайным образом.
|
||||
|
||||
Диаграмма классов на примере задачи Reach детализирует архитектуру модуля:
|
||||
|
||||
|
||||
*Диаграмма классов для задачи Reach*
|
||||
|
||||
Агент использует усилия в пространстве задач для достижения до точки.
|
||||
|
||||
**Управляющие сигналы**:
|
||||
|
||||
$$
|
||||
\bm{W} = \begin{bmatrix} f_x & f_y & f_z & 0 & 0 & 0 \end{bmatrix}^T
|
||||
$$
|
||||
|
||||
где $f$ — компоненты силы.
|
||||
|
||||
**Пространство наблюдения**:
|
||||
|
||||
$$
|
||||
\bm{O} = \begin{bmatrix} \bm{p}_e & \bm{p}_o & \bm{v}_e \end{bmatrix}^T
|
||||
$$
|
||||
|
||||
где:
|
||||
- $\bm{p}_e = [x, y, z]^T$ — положение эффектора робота,
|
||||
- $\bm{p}_o = [x, y, z]^T$ — положение цели,
|
||||
- $\bm{v}_e$ — пространственный вектор скорости эффектора.
|
||||
|
||||
**Функция наград**:
|
||||
|
||||
1. **За уменьшение дистанции до цели**:
|
||||
|
||||
$$
|
||||
R_d = \sum_{t=0}^{T-1} \Delta D_t \cdot 10
|
||||
$$
|
||||
|
||||
где $T$ — число шагов, $D_t$ — расстояние до цели, $\Delta D_t = D_{t} - D_{t-1}$.
|
||||
|
||||
2. **За коллизии**:
|
||||
|
||||
$$
|
||||
R_c = \sum_{t=0}^{T-1} \begin{cases}
|
||||
-10, & \text{если } q_t \in C_o, \\
|
||||
0, & \text{иначе}
|
||||
\end{cases}
|
||||
$$
|
||||
|
||||
где $C_o$ — пространство коллизий.
|
||||
|
||||
3. **Штраф за медленное выполнение задачи**:
|
||||
|
||||
$$
|
||||
R_q = \sum_{t=0}^{T-1} -0.01
|
||||
$$
|
||||
|
||||
4. **Бонус за достижение цели**:
|
||||
|
||||
$$
|
||||
R_s = \begin{cases}
|
||||
100, & \text{если } D_t < 0.05, \\
|
||||
0, & \text{иначе.}
|
||||
\end{cases}
|
||||
$$
|
||||
|
||||
**Результирующая награда**:
|
||||
|
||||
$$
|
||||
R = R_c + R_d + R_q + R_s
|
||||
$$
|
||||
|
||||
Агент считается обученным, если $R = 100 \pm 10$ за эпизод.
|
||||
|
||||
### Тестирование и результаты
|
||||
|
||||
На графике представлены результаты обучения:
|
||||
|
||||
|
||||
*Графики обучения. Допустимая область (100 ± 10) показывает диапазон, при котором агент считается обученным.*
|
||||
|
||||
### Самостоятельный запуск обучения
|
||||
|
||||
Для самостоятельно запуска этого примера следуйте [инструкции](https://gitlab.com/solid-sinusoid/env_manager/-/blob/main/docs/getting_started/getting_started.ru.md).
|
||||
|
||||
## Имитационное обучение с помощью деревьев поведения
|
||||
|
||||
Описанный выше модуль `rbs_gym` также можно использовать для более специфических сценариев применения - в частности, для имитационного обучения, где обучение с подкреплением дополняется демонстрациями, полученными в симуляторе или с помощью устройств телеуправления роботом. Ниже приведена диаграмма ориентировочной реализации такого сценария, на которой отражены основные модули системы и их взаимосвязи.
|
||||
|
||||
|
||||
|
||||
На диаграмме показано каким образом программные модули фреймворка `bt_executor`, `scene_builder`, `rbs_runtime`, `env_manager` интегрируются со сторонними библиотеками - в частности, с библиотекой [lerobot](https://github.com/huggingface/lerobot), из которой используются модули для формирования `Policy`, обучения и конвертации датасета. На диаграмме также выделены примитивы дерева поведения, среди которых можно отметить RecordEpisode, осуществляющий запись демонстраций в runtime в цикле.
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
title: Веб-сервис Robossembler
|
||||
---
|
||||
|
||||
Исходный код: https://gitlab.com/robossembler/webservice
|
||||
|
||||
Основная прикладная задача сервиса - сопровождение процесса/жизненного цикла генерации датасетов для множества деталей. Сервис "связывает" воедино процессы разработки управляющих программ для роботов. Каждая фаза жизненного цикла имеет своё представление в виде страницы в веб-сервисе. Переключение между фазами осуществляется через нажатие соответствующей вкладки.
|
||||
|
||||
## Основные функции
|
||||
|
||||
- Создание проекта сборки
|
||||
- Подготовка и генерация датасета
|
||||
- Конфигурация сцены - Scene Builder
|
||||
- Создание дерева поведения из навыков
|
||||
- Просмотр результатов симуляции
|
||||
- Оценка производительности обучения навыков
|
||||
|
||||
## Основные компоненты
|
||||
|
||||
Веб-сервис включает в себя серверную и клиентскую части. Серверная часть состоит из NodeJS приложения и документ-ориентированной базы данных MongoDB. Она служит для запуска всех необходимых процессов генерации датасетов или машинного обучения в конвейере подготовки роботизированных программ сборки, хранения и обеспечения доступа к исходным и генерируемым данным. Клиентская часть представляет собой браузерное приложение (веб-интерфейс), написанное на языке TypeScript, которое позволяет создавать, конфигурировать и запускать разнообразные процессы вычисления - генерации синтетических датасетов и обучения. Каждый запущенный процесс вычисления отображается в веб-интерфейсе соответствующим элементом интерфейса типа «карточка» (card), который позволяет с помощью модуля оценки производительности перейти к отображению логов обучения.
|
||||
|
||||
## Конфигуратор навыков
|
||||
|
||||
Веб-сервис позволяет создавать шаблоны навыков, описывать их параметры и добавлять сколь угодное количество параметризированных навыков для прикладных задач. Каждый навык содержит команды запуска (ros2 launch), параметры конфигурирования и интерфейсы для взаимодействия с ним в ходе исполнения.
|
||||
|
||||
|
||||
|
||||
## Запуск процессов вычислений/обучения
|
||||
|
||||
Веб-сервис позволяет создавать типы процессов, запускать их экземпляры для конкретных навыков и публиковать результаты в веб-интерфейсе. Например, типом процесса может быть «Обучение навыку обнаружения объектов с помощью YOLOv8» или «Обучение навыку планирования движений робота с помощью алгоритма Soft-Actor-Critic». Для каждого типа процесс задаётся соответствующий набор команд, аргументов/параметров вызова. После сохранения соответствующего типа процесса в интерфейсе для обучения появляется возможность создать конкретный процесс, задав требуемые навыки. Конкретным процессом может быть «Обучение навыку обнаружения детали N с помощью метода YOLOv8», который, будучи запущенным со всеми необходимыми параметрами, запускает вычисления с последующим сохранением результатов в виде логов обучения, файлами моделей весов нейронной сети и т. п. артефактами.
|
||||
|
||||
Типы процессов и формы заполнения параметров создаются с помощью Form Builder — специального программного модуля серверной части веб-сервиса, который осуществляет разбор конфигурационного файла формы в json-подобном формате и автоматически создаёт соответствующий ему графический веб-интерфейс для заполнения без необходимости править конфигурационные файлы вручную, что позволяет снизить шансы на ошибку при вводе данных. Для каждого процесса может быть задана мета-модель параметров под названием «context» и сама модель параметров под названием «result». В мета-модели описываются основные типы данных. На снимке экрана ниже представлен пример навыка обнаружения объектов, для которого задаются параметры ITEM, представляющие собой словарь.
|
||||
|
||||
|
||||
|
||||
## Редактор деревьев поведения
|
||||
|
||||
В состав веб-сервиса входит графический редактор деревьев поведения, который предоставляет возможность создать дерево поведения из тех навыков, которые были получены в ходе подготовки и обучения.
|
||||
|
||||
|
||||
|
||||
|
|
@ -45,91 +45,6 @@ title: 'Планирование последовательности сборк
|
|||
|
||||
## Обзор актуальных исследований
|
||||
|
||||
|
||||
### Гиперграфовый подход в декомпозиции сложных технических систем
|
||||
__Божко А.Н. (2016-2019 гг.)__
|
||||
|
||||
Декомпозиция технической системы на сборочные единицы (СЕ) – одна из важных инженерных задач технической подготовки дискретного производства. На основе выбранной иерархии сборочных единиц формируются многие конструкторские и технологические документы: схема сборки, сборочного состава, разузлования, технологического членения и т.д.
|
||||
Известно, что с вычислительной точки зрения – это труднорешаемая задача. Даже самая простая ее постановка – разбиение плоской фигуры на связные составные части – является NP-полной. Тем не менее, существуют различные подходы, призванные в той или иной степени упростить и автоматизировать решение данной задачи.
|
||||
Одним из таких подходов является применение гиперграфов для декомпозиции сложных технических систем. Данный подход был предложен А.Н. Божко в ряде работ, где он описывает математический аппарат и обосновывает преимущества подхода применительно к задаче.
|
||||
|
||||
Для описания подхода введем необходимые понятия:
|
||||
Гиперграфом называется пара $H = (X, E)$, где $X$ – множество вершин, а $E$ – семейство подмножеств $X$, называемых гиперребрами. В общем случае, от обычного графа гиперграф отличается тем, что его гиперребра могут содержать в себе более двух вершин.
|
||||
|
||||
|
||||
|
||||
Важным понятием является базирование.
|
||||
|
||||
__Базирование__ – это придание заготовке, детали или изделию требуемого положения относительно выбранной системы координат.
|
||||
|
||||
__База__ – поверхность или заменяющее ее сочетание поверхностей, ось, точка, принадлежащая заготовке, детали или изделию, которая используется для базирования.
|
||||
|
||||
__Конструкторская база__ – база, которая служит для базирования детали или сборочной единицы при сборке изделия.
|
||||
|
||||
В работах Божко рассматриваются изделия, для которых сборочные операции соответствуют следующим требованиям:
|
||||
1. Осуществляются механические связи между деталями (__когерентность__)
|
||||
2. Могут быть выполнены при помощи двух независимых движений рабочих органов (__секвенциальность__)
|
||||
|
||||
При этом фиксированное положение детали рассматривается как частный случай движения. Приспособление, используемое для закрепления детали, также является рабочим органом.
|
||||
|
||||
|
||||
|
||||
Чертеж изделия и гиперграф конструкции
|
||||
|
||||
Корректной математической моделью механической структуры является __s-гиперграф__, т.е. гиперграф, который можно преобразовать в точку при помощи последовательности нормальных стягиваний. Нормальным стягиванием называется преобразование гиперграфа, заключающееся в отождествлении двух вершин ребра и удалении этого ребра.
|
||||
При этом важно отметить, что поскольку СЕ должна соответствовать требованиям независимой собираемости, механическая структура СЕ описывается s-подграфом s-гиперграфа.
|
||||
|
||||
Божко вводит ряд возможных ограничений, позволяющих формализовать и автоматизировать процесс построения гиперграфа сборки. Перечислим их:
|
||||
1. Деталь не может входить в две и более СЕ
|
||||
2. Гиперребро (а также ребро) входит в отдельную СЕ или соединяет различные СЕ
|
||||
3. Любая СЕ содержит хотя бы одно ребро
|
||||
4. Для СЕ должно выполняться линейное соотношение между числом вершин и связей гиперграфа
|
||||
5. Если гиперребро (а также ребро) включено в состав СЕ, то все его инцидентные вершины должны войти в данную СЕ. Верно и обратное
|
||||
6. Разбиение не может быть тривиальным, должна быть хотя бы одна невырожденная (содержащая более одного элемента) СЕ
|
||||
При этом, конструктор может налагать ряд дополнительных ограничений исходя из специфики объекта:
|
||||
1. Некоторые детали входят в одну СЕ
|
||||
2. Некоторая пара деталей не входит в одну СЕ
|
||||
3. Запрет на включение детали в конкретную СЕ
|
||||
4. Запрет на включение детали в любую СЕ
|
||||
5. Числовые ограничения на СЕ, например, по массе, габаритам, составу и тд
|
||||
Можно формализовать и структурные ограничения на гиперграф - возможность маскировки гиперребер – замены гиперребер на отдельные вершины в дереве сборки. Для этого маскируемые (схлопываемые) вершины должны принадлежать одной сборочной единице.
|
||||
|
||||
Для оптимизации можно задать целевые функции, которые позволят формализовать принятие рациональных решений:
|
||||
1. Большинство деталей должны войти в СЕ
|
||||
2. Число СЕ должно быть максимальным
|
||||
3. Механические связи высокой «валентности» целесообразно реализовывать на начальных этапах сборочного процесса.
|
||||
4. Упрощение сборки сложного изделия путем минимизации числа механических связей на финальных операциях
|
||||
5. Минимизировать число необходимых сопряжений для реализации механической связи.
|
||||
При этом, в зависимости от специфики процесса, данный список можно дополнить требованиями и ограничениями, учитывающими специфику принятия решений.
|
||||
|
||||
Данные принципы были реализованы в программном комплексе (далее - ПК) AssemBL, работающем в среде САПР Siemens NX 10.0. ( ["Структурный анализ изделия и проектирование сборочных комплексов в программном комплексе AssemBL"](https://cyberleninka.ru/article/n/strukturnyy-analiz-izdeliya-i-proektirovanie-sborochnyh-protsessov-v-programmnom-komplekse-assembl))
|
||||
|
||||
В данный комплекс входят подпрограммы, позволяющие осуществлять:
|
||||
- Моделирование механических структур
|
||||
- Структурный анализ конструкции
|
||||
- Анализ геометрической разрешимости
|
||||
- Синтез последовательности сборки
|
||||
- Синтез декомпозиции изделия на сборочные единицы
|
||||
|
||||
При этом, данный ПК опирается на ресурсы NX, в частности – команды меню Assemblies (Сборки) и Analysis (Анализ), а так же – на штатные инструменты NX для создания, редактирования и визуализации трехмерных моделей деталей и сборок.
|
||||
|
||||
Сперва модуль анализирует модель, фиксирует существование механической связи между деталями. При этом, важно определить важные исключения – интерференции в сборке, зазоры, применение косвенного базирования, ограничения, введенные для моделирования законов движения в изделии. Определив их, оператор ПК должен штатными средствами NX устранить обнаруженные проблемы.
|
||||
|
||||
Получив список механических связей, оператор выполняет экспертную постобработку, убирая ненужные для работы сопряжения и добавляя пары элементов, в каких применено косвенное базирование. Обработав и верифицировав эту информацию, возможно построить граф механических связей. При этом, программа анализирует построенный граф, вычленяет в его структуре клики.
|
||||
|
||||
Далее, эксперт анализирует граф, выбирает те клики, которые представляют минимальный геометрически определенный фрагмент конструкции. Это позволяет перейти к построению гиперграфа. Полученный гиперграф в автоматическом режиме анализируется согласно изложенным выше принципам, производится проверка на стягиваемость, линеаризация графа (удаление избыточных связей). Создается s-гиперграф, позволяющий создать максимально большое число СЕ и последовательностей сборки.
|
||||
|
||||
|
||||
|
||||
Линеаризация и стягивание гиперграфа
|
||||
|
||||
Наконец, в автоматическом режиме или с помощью эксперта производится анализ геометрической разрешимости сборки. Анализ производится на основании отсутствия коллизий посредством инструментария NX. При этом, автор отмечает, что автоматический анализ даже для относительно несложных изделий достаточно ресурсоемкий и занимает много времени.
|
||||
|
||||
Наконец, на основе всех полученных данных возможно произвести синтез последовательности сборки и разбиение изделия на сборочные единицы.
|
||||
|
||||
|
||||
|
||||
|
||||
### 3D Model-Based Assembly Sequence Optimization using Insertionable Properties of Parts - 2020
|
||||
|
||||
Kento Tariki, Takuya Kiyokawa, Gustavo Alfonso Garcia Ricardez, Jun Takamatsu, Tsukasa Ogasawara (Japan)
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 79 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 37 KiB |
|
|
@ -148,139 +148,6 @@ PDDL (Planning Domain Definition Language) - Lisp-подобный язык дл
|
|||
|
||||
PlanSys2 был проверен сначала в симуляции, а потом и на реальной системе, состоящей из 3-ёх роботов. Исходные коды проекта опубликованы на [Github](https://github.com/IntelligentRoboticsLabs/plansys2_cooking_experiment).
|
||||
|
||||
## Имплементация модуля в составе фреймворка
|
||||
|
||||
В качестве основной рабочей среды модуля используется параметрическая САПР с открытым программным кодом FreeCAD. Данный выбор был сделан как из-за открытого программного кода и общедоступности системы, так и благодаря существенной гибкости и широким возможностям этого программного пакета, позволяющего включать в его работу пользовательские скрипты, макросы и верстаки самого широкого назначения. Модуль построения технологических карт и спецификаций производственного оборудования является верстаком (англ. workbench, аналог плагина или расширения) к FreeCAD, а не его модификацией. Исходный код модуля не предполагается встраивать в исходный код FreeCAD, поэтому лицензионные ограничения LGPL2+ на него не распространяются.
|
||||
|
||||
Модуль технологической подготовки имеет ценность не только как часть фреймворка Робосборщик, но и как самостоятельный инструмент, который позволит пользователю — участнику производственного коллектива — более эффективно и удобно создавать необходимую для запуска документацию — файлы, чертежи, 3D-модели и т.д., а также управлять производственными процессами в небольшом масштабе. При этом, будучи включенным в фреймворк, модуль многократно увеличивает свои возможности, позволяя создавать исполняемые спецификации, которые используются для подготовки автоматизированного производства. Метрикой для оценки работы модуля будет затрачиваемое оператором время на формирование спецификации с разметкой моделей.
|
||||
|
||||
Основные задачи модуля технологической подготовки:
|
||||
1. Создание технологических карт и спецификаций;
|
||||
2. Разметка геометрических моделей и наложение на них вспомогательной информации: позиций захвата, рабочих зон, плоскостей базирования, участков сопряжения и позиционирования, зон с особыми условиями допусков и посадок;
|
||||
3. Разметка моделей оборудования с целью указания области работ, инструментов, указания связей с возможными технологическими операциями;
|
||||
4. Экспорт моделей для последующей обработки в Blender, включая информацию об активно управляемых сочленениях робота (Joints).
|
||||
|
||||
В верстаке используется дополнительное дерево построения вспомогательных объектов, таких как ориентированные системы координат, выделенные плоскости, объемы и тела, в которых указывается информация, описывающая состояния, привязки и характеристики описываемой сущности. Затем осуществляется экспорт объектов в форматах JSON, PDDL, SDF в пригодном для использования другими модулями виде.
|
||||
|
||||
Для CAD-модели изделию формируется набор PDDL, SDF и JSON файлов, которые полностью описывают его поведение как производственной единицы, а также технологическая карта на изготовление. Для этого используются реализованные алгоритмы создания спецификаций, расчета заданий на 3д-печать, загрузка полученной очереди в слайсер и анализ полученной программы на языке G‑код с целью внесения информации в PDDL-спецификацию задачи для оценки длительности работ. На примере робота-манипулятора Robossembler Arm продемонстрирована генерация вспомогательной разметки и спецификации. В модели манипулятора размечены позиции сочленений звеньев, экспортируемые в виде JSON-файлов, которые затем использовались в ходе адаптации модели для задач симуляции.
|
||||
|
||||
### Примеры генерации
|
||||
|
||||
Для демонстрации работоспособности модуля в части генерации спецификаций для системы планирования сгенерируем файлы `domain.pddl` и `problem.pddl`. `domain.pddl` описывает рабочий домен, состоящий из 3д-принтера, производящего печать деталей, робота-манипулятора, производящего операции извлечения и сборки деталей, и наблюдателя, осуществляющего подготовку 3д-принтера к работе.
|
||||
|
||||
Фрагмент исходного кода сгенерированной спецификации [domain.pddl](https://gitlab.com/robossembler/framework/-/blob/03f8b868779f446cab497df86ea8cc6a63058084/freecad_workbench/freecad/robossembler/pddl/domain.pddl):
|
||||
|
||||
```pddl
|
||||
(define (domain Printer)
|
||||
|
||||
(:requirements :strips :typing :fluents :durative-actions)
|
||||
(:types
|
||||
printer workspace - zone
|
||||
part
|
||||
arm
|
||||
assembly
|
||||
human
|
||||
filament
|
||||
)
|
||||
(:predicates
|
||||
(arm_available ?a - arm)
|
||||
(part_at ?p - part ?z - zone)
|
||||
(printer_ready ?p - printer)
|
||||
(printer_checked ?p - printer)
|
||||
(printer_at_work ?p - printer)
|
||||
(part_of ?part - part ?whole - assembly)
|
||||
(assembly_order ?prev ?next - assembly)
|
||||
(assembled ?whole - assembly ?z - zone)
|
||||
(observer_free ?h - human)
|
||||
(filament_at ?f - filament ?z - zone)
|
||||
)
|
||||
|
||||
(:durative-action print
|
||||
:parameters ( ?p - part ?pr - printer )
|
||||
:duration ( = ?duration 20)
|
||||
:condition (and
|
||||
(at start(printer_ready ?pr))
|
||||
)
|
||||
:effect (and
|
||||
(at start (not (printer_ready ?pr)))
|
||||
(at start (printer_at_work ?pr ))
|
||||
(at end(part_at ?p ?pr))
|
||||
(at end (not (printer_at_work ?pr )))
|
||||
)
|
||||
)
|
||||
...
|
||||
```
|
||||
|
||||
Генерация спецификации предметной области позволяет получить полную информацию о входящих в состав изделия элементах, что, впоследствии, используется как напрямую, так и для создания производственных заданий.
|
||||
|
||||
`problem.pddl` описывает производственную задачу для сборки конкретного изделия. В данном случае, на примере коробки передач.
|
||||
|
||||
|
||||
|
||||
Исходный код сгенерированной PDDL-спецификации производственной задачи `problem.pddl`:
|
||||
|
||||
```pddl
|
||||
(define (problem p1)
|
||||
(:domain robossembler)
|
||||
(:objects
|
||||
;; information from Scene
|
||||
rasmt - arm
|
||||
printer1 printer2 printer3 - printer
|
||||
workspace1 - workspace
|
||||
worker - human
|
||||
filament1 filament2 filament3 - filament
|
||||
;; information from CAD
|
||||
pad009003002002 pad009003002003 pad009003002005 pad009003002011 fusion004003 o_2_a001 o_2_m001 o_3_m001 o_3_a001 pad009003002008 fusion005 o_4_m001 o_5_m001 o_5_a001 o_4_a001 fusion006 r_a001 r_m001 r_l001 synfix synfix001 fusion fusion001 synfix002 fusion002 synfix003 fusion007 pad009003002012 pad001 pocket pad002 fusion008 fusion009 bearing_dgsr_6006_001 bearing_dgsr_6006_002 bearing_dgsr_6006_003 bearing_dgsr_6005_ bearing_dgsr_6005_001 bearing_dgsr_6005_002 bearing_dgsr_6005_003 bearing_dgsr_6005_004 pad003 pocket001 - part
|
||||
subasm00 subasm0 subasm1 subasm2 subasm3 subasm4 subasm5 subasm6 subasm7 subasm8 subasm9 subasm10 subasm11 subasm12 subasm13 subasm14 subasm15 subasm16 subasm17 subasm18 subasm19 subasm20 subasm21 subasm22 subasm23 subasm24 subasm25 subasm26 subasm27 subasm28 subasm29 subasm30 subasm31 subasm32 subasm33 subasm34 subasm35 subasm36 subasm37 subasm38 subasm39 subasm40 subasm41 subasm42 - assembly
|
||||
)
|
||||
(:init
|
||||
;; information from Scene
|
||||
|
||||
(observer_free worker)
|
||||
; (not(printer_ready printer1))
|
||||
|
||||
; (printer_ready printer2)
|
||||
; (printer_ready printer3)
|
||||
(filament_at filament1 workspace1)
|
||||
(filament_at filament2 workspace1)
|
||||
(filament_at filament3 workspace1)
|
||||
|
||||
(arm_available rasmt)
|
||||
;; information from CAD
|
||||
(assembled subasm00 workspace1)
|
||||
|
||||
(part_of pad009003002002 subasm0)
|
||||
(part_of pad009003002003 subasm1)
|
||||
(part_of pad009003002005 subasm2)
|
||||
(part_of pad009003002011 subasm3)
|
||||
(part_of fusion004003 subasm4)
|
||||
...
|
||||
|
||||
```
|
||||
|
||||
|
||||
Полученные файлы передаются в качестве параметров в программу-решатель планов [POPF](https://github.com/fmrico/popf), который формирует план сборки. Фрагмент вывода полученного плана сборки в терминал:
|
||||
```bash
|
||||
/nix/store/j9i8z3271jv3hf43i30d41sx2m3zwxia-ros-humble-popf-0.0.14-r1/lib/popf/popf domain.pddl problem.pddl
|
||||
Constructing lookup tables: [10%] [20%] [30%] [40%] [50%] [60%] [70%] [80%] [90%] [100%]
|
||||
Post filtering unreachable actions: [10%] [20%] [30%] [40%] [50%] [60%] [70%] [80%] [90%] [100%]
|
||||
92% of the ground temporal actions in this problem are compression-safe
|
||||
b (174.000 | 1.000)b (173.000 | 6.001)b (172.000 | 6.001)b (171.000 | 27.003)b (170.000 | 47.004)b (169.000 | 48.005)b (168.000 | 68.006)b (167.000 | 69.007)b (166.000 | 89.008)b (165.000 | 90.009)b (164.000 | 110.010)b (163.000 | 111.011)b (162.000 | 131.012)b (161.000 | 132.013)b (160.000 | 152.014)b (159.000 | 153.015)b (158.000 | 173.016)b (157.000 | 174.017)b (156.000 | 194.018)b (155.000 | 195.019)b (154.000 | 215.020)b (153.000 | 216.021)b (152.000 | 236.022)b (151.000 | 237.023)b (150.000 | 257.024)b (149.000 | 258.025)b (148.000 | 278.026)b (147.000 | 279.027)b (146.000 | 299.028)b (145.000 | 300.029)b (144.000 | 320.030)b (143.000 | 321.031)b (142.000 | 341.032)b (141.000 | 342.033)b (140.000 | 362.034)b (139.000 | 363.035)b (138.000 | 383.036)b (137.000 | 384.037)b (136.000 | 404.038)b (135.000 | 405.039)b (134.000 | 425.040)b (133.000 | 426.041)b (132.000 | 446.042)b (131.000 | 447.043)b (130.000 | 467.044)b (129.000 | 468.045)b (128.000 | 488.046)b (127.000 | 489.047)b (126.000 | 509.048)b (125.000 | 510.049)b (124.000 | 530.050)b (123.000 | 531.051)b (122.000 | 551.052)b (121.000 | 552.053)b (120.000 | 572.054)b (119.000 | 573.055)b (118.000 | 593.056)b (117.000 | 594.057)b (116.000 | 614.058)b (115.000 | 615.059)b (114.000 | 635.060)b (113.000 | 636.061)b (112.000 | 656.062)b (111.000 | 657.063)b (110.000 | 677.064)b (109.000 | 678.065)b (108.000 | 698.066)b (107.000 | 699.067)b (106.000 | 719.068)b (105.000 | 720.069)b (104.000 | 740.070)b (103.000 | 741.071)b (102.000 | 761.072)b (101.000 | 762.073)b (100.000 | 782.074)b (99.000 | 783.075)b (98.000 | 803.076)b (97.000 | 804.077)b (96.000 | 824.078)b (95.000 | 825.079)b (94.000 | 845.080)b (93.000 | 846.081)b (92.000 | 866.082)b (91.000 | 867.083)b (90.000 | 887.084)b (89.000 | 888.085)b (88.000 | 908.086)b (87.000 | 909.087)b (86.000 | 914.088)b (85.000 | 914.088)b (84.000 | 919.089)b (83.000 | 919.089)b (82.000 | 924.090)b (81.000 | 924.090)b (80.000 | 929.091)b (79.000 | 929.091)b (78.000 | 934.092)b (77.000 | 934.092)b (76.000 | 939.093)b (75.000 | 939.093)b (74.000 | 944.094)b (73.000 | 944.094)b (72.000 | 949.095)b (71.000 | 949.095)b (70.000 | 954.096)b (69.000 | 954.096)b (68.000 | 959.097)b (67.000 | 959.097)b (66.000 | 964.098)b (65.000 | 964.098)b (64.000 | 969.099)b (63.000 | 969.099)b (62.000 | 974.100)b (61.000 | 974.100)b (60.000 | 979.101)b (59.000 | 979.101)b (58.000 | 984.102)b (57.000 | 984.102)b (56.000 | 989.103)b (55.000 | 989.103)b (54.000 | 994.104)b (53.000 | 994.104)b (52.000 | 999.105)b (51.000 | 999.105)b (50.000 | 1004.106)b (49.000 | 1004.106)b (48.000 | 1009.107)b (47.000 | 1009.107)b (46.000 | 1014.108)b (45.000 | 1014.108)b (44.000 | 1019.109)b (43.000 | 1019.109)b (42.000 | 1024.110)b (41.000 | 1024.110)b (40.000 | 1029.111)b (39.000 | 1029.111)b (38.000 | 1034.112)b (37.000 | 1034.112)b (36.000 | 1039.113)b (35.000 | 1039.113)b (34.000 | 1044.114)b (33.000 | 1044.114)b (32.000 | 1049.115)b (31.000 | 1049.115)b (30.000 | 1054.116)b (29.000 | 1054.116)b (28.000 | 1059.117)b (27.000 | 1059.117)b (26.000 | 1064.118)b (25.000 | 1064.118)b (24.000 | 1069.119)b (23.000 | 1069.119)b (22.000 | 1074.120)b (21.000 | 1074.120)b (20.000 | 1079.121)b (19.000 | 1079.121)b (18.000 | 1084.122)b (17.000 | 1084.122)b (16.000 | 1089.123)b (15.000 | 1089.123)b (14.000 | 1094.124)b (13.000 | 1094.124)b (12.000 | 1099.125)b (11.000 | 1099.125)b (10.000 | 1104.126)b (9.000 | 1104.126)b (8.000 | 1109.127)b (7.000 | 1109.127)b (6.000 | 1114.128)b (5.000 | 1114.128)b (4.000 | 1119.129)b (3.000 | 1119.129)b (2.000 | 1124.130)b (1.000 | 1124.130);;;; Solution Found
|
||||
```
|
||||
|
||||
Модуль технологической подготовки позволяет описывать все составные части объектов проекта — от оборудования и роботов-манипуляторов и до производимых изделий. При этом один и тот же объект в разных случаях может фигурировать как в одной, так и в другой роли.
|
||||
|
||||
В модуле реализованы следующие функции технологической подготовки:
|
||||
|
||||
1. [Добавление позиций с метаданными в CAD-модели](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/markupEntities.py)
|
||||
2. [Экспорт и импорт точек с метаданными о моделях для использования в средах симуляции и визуализации](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/ImportExportEntities.py).
|
||||
3. [Генератор PDDL-спецификаций](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/pddl/freecad2pddl.py);
|
||||
4. [Расчёт длительности печати для печатных деталей](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/printETA.py).
|
||||
5. [Подготовка материалов к экспорту в среды визуализации](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/modelExport.py).
|
||||
6. [Генерация сборочных спецификаций для САПР-модели](https://gitlab.com/robossembler/framework/-/blob/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames/BoMList.py).
|
||||
|
||||
[Исходный код модуля технологической подготовки](https://gitlab.com/robossembler/framework/-/tree/9eaf12a4fac7cdcec5b6197924795dd62d241933/cg/freecad/Frames).
|
||||
|
||||
## Другие полезные ссылки
|
||||
|
||||
### Основные классы алгоритмов планирования
|
||||
|
|
|
|||
|
|
@ -28,12 +28,7 @@ module.exports = {
|
|||
},
|
||||
{to: 'blog', label: 'Новости', position: 'left'},
|
||||
{
|
||||
href: 'https://t.me/robossembler_ru',
|
||||
label: 'Telegram',
|
||||
position: 'right',
|
||||
},
|
||||
{
|
||||
href: 'https://gitlab.com/robossembler',
|
||||
href: 'https://gitlab.com/robossembler/robossembler.gitlab.io',
|
||||
label: 'GitLab',
|
||||
position: 'right',
|
||||
}
|
||||
|
|
|
|||
152
sidebars.js
152
sidebars.js
|
|
@ -12,88 +12,35 @@ module.exports = {
|
|||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Аппаратное обеспечение',
|
||||
label: 'Компоненты',
|
||||
items: [
|
||||
{
|
||||
type: 'link',
|
||||
href: 'https://gitlab.com/robossembler/servo',
|
||||
label: 'Сервопривод',
|
||||
},
|
||||
{
|
||||
type: 'link',
|
||||
href: 'https://gitlab.com/robossembler/roboarm-diy-version',
|
||||
label: 'Робот-манипулятор',
|
||||
},
|
||||
{
|
||||
type: 'link',
|
||||
href: 'https://gitlab.com/robossembler/cnc/motor-wire-winder',
|
||||
label: 'Станок намотки',
|
||||
},
|
||||
'autostorage',
|
||||
'information/information_support',
|
||||
'information/planner',
|
||||
'information/cfs-models-pub-in-nix'
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Программное обеспечение',
|
||||
label: 'Технологии',
|
||||
items: [
|
||||
'robossembler-framework',
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'technologies/ASP-overview',
|
||||
label: 'Генерация последовательности сборки',
|
||||
},
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'technologies/cad-cg-pipeline',
|
||||
label: 'Экспорт моделей в виртуальные среды',
|
||||
},
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'technologies/plansys2',
|
||||
label: 'Генерация технологических карт',
|
||||
},
|
||||
'software/dataset-generator',
|
||||
'software/environment-manager',
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Модуль исполнения планов',
|
||||
items: [
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'software/ros2',
|
||||
label: 'Архитектура',
|
||||
},
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'software/ros2/installation',
|
||||
label: 'Установка',
|
||||
},
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'software/ros2/add_new_robot',
|
||||
label: 'Добавление нового робота',
|
||||
},
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'software/ros2/prepare-and-execute-skill',
|
||||
label: 'Создание и запуск навыка',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'software/webservice',
|
||||
label: 'Веб-интерфейс',
|
||||
},
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'software/usecases',
|
||||
label: 'Сценарии использования',
|
||||
},
|
||||
'technologies/open-source-robots-and-tools',
|
||||
'technologies/cad-cg-pipeline',
|
||||
'technologies/robonomics',
|
||||
'technologies/machine-learning-in-robotics',
|
||||
'technologies/cv-perception-methods',
|
||||
'technologies/mrs-robotics-assembly-review',
|
||||
'technologies/plansys2',
|
||||
'technologies/ASP-overview',
|
||||
'technologies/wrs2020-assembly-challenge',
|
||||
'technologies/knowledge-management',
|
||||
'technologies/wood',
|
||||
'technologies/recycling',
|
||||
],
|
||||
},
|
||||
/* {
|
||||
type: 'category',
|
||||
label: 'Прикладные решения',
|
||||
label: 'Приложения',
|
||||
items: [
|
||||
'applications/beehive',
|
||||
'applications/microalgae-garden',
|
||||
|
|
@ -103,66 +50,33 @@ module.exports = {
|
|||
}, */
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Переводы статей, обзоры',
|
||||
label: 'Модели',
|
||||
items: [
|
||||
'technologies/cv-perception-methods',
|
||||
'technologies/wrs2020-assembly-challenge',
|
||||
'papers/mania-beetz-self-training-with-vr-2019',
|
||||
'technologies/dds_and_ros2',
|
||||
'papers/self-organization-in-robotic-welding',
|
||||
'papers/smerobotics',
|
||||
'papers/auto-assembly',
|
||||
'technologies/mrs-robotics-assembly-review',
|
||||
'technologies/machine-learning-in-robotics',
|
||||
'models/generation/generation',
|
||||
'models/growth/growth'
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Самовоспроизводство техники',
|
||||
label: 'Переводы',
|
||||
items: [
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'replication',
|
||||
label: 'Дорожная карта САС',
|
||||
},
|
||||
'analogy',
|
||||
'mining',
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Модели',
|
||||
items: [
|
||||
'models/generation/generation',
|
||||
'models/growth/growth'
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Технические решения',
|
||||
items: [
|
||||
'technologies/robonomics',
|
||||
'autostorage',
|
||||
'information/information_support',
|
||||
'information/planner',
|
||||
'technologies/wood',
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'technologies/recycling',
|
||||
label: 'Мусор как сырьё',
|
||||
},
|
||||
],
|
||||
},
|
||||
'glossary',
|
||||
'papers/mania-beetz-self-training-with-vr-2019',
|
||||
'technologies/dds_and_ros2',
|
||||
'papers/self-organization-in-robotic-welding',
|
||||
'papers/smerobotics',
|
||||
'papers/auto-assembly'
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Разное',
|
||||
items: [
|
||||
'technologies/open-source-robots-and-tools',
|
||||
'concept/engelmeyer',
|
||||
'workflow-rules',
|
||||
'technologies/knowledge-management',
|
||||
'information/cfs-models-pub-in-nix'
|
||||
'replication',
|
||||
'mining',
|
||||
'glossary',
|
||||
'analogy',
|
||||
'workflow-rules'
|
||||
],
|
||||
},
|
||||
],
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue