diff --git a/docs/technologies/img/ca_bt_execution.jpg b/docs/technologies/img/ca_bt_execution.jpg new file mode 100644 index 0000000..aed1c41 Binary files /dev/null and b/docs/technologies/img/ca_bt_execution.jpg differ diff --git a/docs/technologies/img/ca_bt_execution_full.jpg b/docs/technologies/img/ca_bt_execution_full.jpg new file mode 100644 index 0000000..e367afe Binary files /dev/null and b/docs/technologies/img/ca_bt_execution_full.jpg differ diff --git a/docs/technologies/img/ca_schematics.jpg b/docs/technologies/img/ca_schematics.jpg new file mode 100644 index 0000000..500579f Binary files /dev/null and b/docs/technologies/img/ca_schematics.jpg differ diff --git a/docs/technologies/img/ca_special_finger_design.jpg b/docs/technologies/img/ca_special_finger_design.jpg new file mode 100644 index 0000000..19d8819 Binary files /dev/null and b/docs/technologies/img/ca_special_finger_design.jpg differ diff --git a/docs/technologies/o2ac-repo-review.md b/docs/technologies/wrs2020-assembly-challenge.md similarity index 65% rename from docs/technologies/o2ac-repo-review.md rename to docs/technologies/wrs2020-assembly-challenge.md index d5155ab..e474d7a 100644 --- a/docs/technologies/o2ac-repo-review.md +++ b/docs/technologies/wrs2020-assembly-challenge.md @@ -1,8 +1,9 @@ --- -id: o2ac-repo-review -title: 'O2AC Assembly Challenge 2021' +id: wrs2020-assembly-challenge +title: 'Assembly Challenge 2020' --- -## Предыстория + +## Проект команды O2AC ![o2ac_example_2_arm](https://github.com/o2ac/o2ac-ur/raw/main/images/tray_carry.gif) @@ -20,9 +21,7 @@ title: 'O2AC Assembly Challenge 2021' 8. Обнаружение и захват деталей расположенных в лотке неструктурировано 9. Для установленных деталей используется библиотека TF которая содержит локальную систему координат каждого установленного элемента -## Обзор репозитория - -Репозиторий состоит из 19 пакетов, в том числе есть пакеты которые достойны рассмотрения для реализации нашего Робосборщика. Кратко пройдёмся по каждому из них. +Репозиторий проекта состоит из 19 пакетов, в том числе есть пакеты которые достойны рассмотрения для реализации нашего Робосборщика. Кратко пройдёмся по каждому из них. ### aist_modules @@ -131,19 +130,19 @@ def on_stop(self): ![flexbe](img/flexbe_example_1.png) -## o2ac_gazebo +### o2ac_gazebo Данный репозиторий включает сцену симуляции Gazebo для робототехнического сборочного комлпекса O2AC и не включает ничего специфичного, по типу плагинов для данной сцены. -## o2ac_moveit_config +### o2ac_moveit_config Содержит стандартный конфигурацию для moveit подготовленную с помощью moveit_setup_assistant. Из нестандартного здесь представлен pilz_industrial_motion_planner который по-умолчанию не включен в moveit и интегрируется одельно, данный планер предоставляет удобный интерфейс реализации декартовых траекторий. -## o2ac_msgs +### o2ac_msgs Содержит все используемые сообщения, сервисы и действия используемые в проекте. Список следующий: -### Сообщения +#### Сообщения В основном все сообщения основаны на проверки текущей позы манипулятора, список следующий @@ -155,7 +154,7 @@ def on_stop(self): * [RobotStatus.msg](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_msgs/msg/RobotStatus.msg) * [TouchObservation.msg](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_msgs/msg/TouchObservation.msg) -## Сервисы +#### Сервисы Также представлен набор сервисом для управления, рассмотрим список @@ -241,7 +240,7 @@ def on_stop(self): * Выдаёт на выходе * Ничего не выдаёт -### Действия +#### Действия Действия в ROS являются базовым конструктором связи с состоят из клиента и сервера. Модель такова, что клиент отсылает цель(запрос) серверу, который заточен на выполнение определённой операции и получает результат этого действия. В данном репозитории присутствует огромная библиотека действий, подразделяемая также на общие, техническое зрение и поведение. Рассмотрим список общих действий в проекте: @@ -286,11 +285,11 @@ def on_stop(self): * Pick.action * PlayBackSequence.action -## o2ac_parts_description +### o2ac_parts_description Данный пакет не эксплуатировался в последней версии проекта представленной на WRC2020, соответственно опустим -## o2ac_routines +### o2ac_routines Данный пакет является основным в перечне и предоставляет скрипты Python и управляющие программы C++ для управления всей роботизированной системой. @@ -298,7 +297,7 @@ def on_stop(self): * calibration.py и osx_view_testing.py являются процедурами калибровки и тестирования * Остальные файлы (например test.py) предназначены для разных тестов и прочего неважного кода. -### Класс Controller +#### Класс Controller * [`common.py`](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_routines/src/o2ac_routines/common.py) определён в [`base.py`](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_routines/src/o2ac_routines/base.py) и предлагает класс для управления всей роботизированной системой. Этот класс ( O2ACCommon) владеет другими классами, которые управляют разными подсистемами: * Робот руки (с помощью [`robot_base.py`](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_routines/src/o2ac_routines/robot_base.py), [`ur_robot.py`](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_routines/src/o2ac_routines/ur_robot.py), [`dual_arm.py`](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_routines/src/o2ac_routines/dual_arm.py), [`robotiq_gripper.py`](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_routines/src/o2ac_routines/robotiq_gripper.py) и [`ur_force_control.py`](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_routines/src/o2ac_routines/ur_force_control.py)) @@ -306,7 +305,7 @@ def on_stop(self): * Винтовые инструменты (через [`tools.py`](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_routines/src/o2ac_routines/tools.py)) * [`taskboard.py`](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_routines/src/o2ac_routines/taskboard.py) и [`assembly.py`](https://github.com/o2ac/o2ac-ur/blob/main/catkin_ws/src/o2ac_routines/src/o2ac_routines/assembly.py) определены в O2ACCommon с помощью переменных и функций для конкретных задач -### Последовательность действий +#### Последовательность действий Они реализуют командные последовательности, в которых следующее движение либо планируется, в то время как предыдущее движение выполняется, либо совместные траектории могут сохранены или загружены в или из файла для выполнения, не требуя дополнительного времени на планирование. @@ -314,23 +313,23 @@ def on_stop(self): Также см. [Pilz_robot_programming](https://github.com/PilzDE/pilz_industrial_motion/tree/melodic-devel/pilz_robot_programming), чтобы узнать об альтернативной реализации Python, которая, вероятно лучше -## o2ac_rviz +### o2ac_rviz Данный пакет включает в себя виджет для RViz, созданный для манипуляции и отладки процесса сборки. Каждый плагин для RViz пишется с использованием библиотеки Qt и интегрируется за счёт специального файла XML с описанием данного плагина. -## o2ac_scene_description +### o2ac_scene_description Данный пакет включает в себя описание роботизированной системы и сцен. Определения деталей можно найти в o2ac_parts_description. Сцены описаны с помощью фалов xacro (macro XML) и URDF (Unifined Robotic Description Format). -## o2ac_skills +### o2ac_skills Данный пакет не эксплуатировался в последней версии проекта представленной на WRC2020, соответственно опустим -## o2ac_task_planning +### o2ac_task_planning Данный пакет не эксплуатировался в последней версии проекта представленной на WRC2020, соответственно опустим -## o2ac_vision +### o2ac_vision Этот пакет содержит узлы, которые выполняют и передают дейсвия (actions) для комиьютерного зрения, например: @@ -343,7 +342,7 @@ def on_stop(self): Для этого узлы Python объявляют ряд действий, определенных в o2ac_msgs. -### Распознавание деталей +#### Распознавание деталей Узел распознавания детали состоит из двух компонентов. Один - это обнаружение объекта (Chukyo), другой - оценка позы (AIST). @@ -373,7 +372,7 @@ def on_stop(self): ![set_bearing](https://github.com/o2ac/o2ac-ur/raw/main/images/bearing_insertion.gif) -### Порядок распознавания (AIST) +#### Порядок распознавания (AIST) Вы можете построить порядок дейсвий от получения изображения до распознавания 3D - объектов, а также локализации с использованием `o2ac_vision` пакета, в сочетании с другими пакетами компьютерного зрения, т.е. `aist_depth_filter`, `aist_localization` и `aist_model_spawner`(по желанию). Порядок дейсвтий показан на следующем рисунке: @@ -409,10 +408,103 @@ geometry_msgs/PoseWithCovarianceStamped[] detected_poses_with_covariance Пример клиентской программы `o2ac_vision / scripts / o2ac_recognition_client_example.py` показывает, как использовать порядок распознавания из пользовательских прикладных программ. Образец также предоставляет средства для визуализации результатов 3D-локализации с помощью `aist_model_spawner`. -## o2ac_visualisation +### o2ac_visualisation Данный пакет предосатвляет плагин визуализации состояния системы как для облегчения отладки, так и для демонстрации. -## wrs_dataset +### wrs_dataset Данный пакет содержит датасет Pytorch, используемые в пакете o2ac_vision для обучения распознавания объектов. + +## Проект команды UC San Diego + +Оригинал статьи _Aayush Naik, Priyam Parashar, Jiaming Hu and Henrik I. Christensen_ - [Lessons Learned Developing an Assembly System for WRS 2020 Assembly Challenge](https://arxiv.org/pdf/2103.15236.pdf) + + +Система сборки была разделена на три классических архитектурных слоя абстракции: mission (миссия, верхний уровень), task (задача, средний уровень) и behaviour layer (поведенческий уровень, самый нижний). Уровень миссии и задач разбивает общий план сборки на ряд задач (представленных в виде деревьев поведения). Он также выполняет восстановление после сбоев и планирование в случае сбоев на уровне миссии. Уровень поведения содержит определения и программы для выполнения различных навыков, таких как перемещение руки робота, открывание/закрывание захватов и вставка. Дерево поведения для каждой задачи состоит из этих навыков в виде узлов действий. Существует также прозрачный “системный” уровень, который состоит из аппаратного обеспечения (роботов и датчиков), сетей,операционной системы, ROS и менеджера процессов, такой как Supervisor. Системный уровень отвечает за прозрачное восстановление после сбоев, не связанных с планированием. + +### Структурная схема установки + +![](img/ca_schematics.jpg) + +### Планирование задач с обработкой ошибок + +Разработчики смоделировали систему планирования на основе классической трехуровневой архитектуры (3T), сочетающей в себе совещательное планирование на верхнем уровне со специализированным планированием и реактивным управлением потоками на более низких уровнях. Планировщик миссий находил правильный порядок размещения деталей (столкновения между деталями являлись основным фактором) на базе AND/OR-графа, а планировщик задач, основанный на формализме иерархической сети задач (HTN SHOP3 Planner), опирается на знания предметной области и её объекты для создания экземпляра размещения детали в виде полностью упорядоченной последовательности примитивных действий. Результатом этих двух уровней является последовательность действий и связанных с ними предварительных условий для приведения в действие робота на основе таксономии примитивных навыков сборки, предложенной _J. O. Huckaby_ в _Knowledge transfer in robot manipulation tasks_. Для создания экземпляров окончательных планов, разработанных планировщиком задач, и ввода правильных физических параметров использовались деревья поведения. + +Разработчики создали иерархию классов для сбоев, которые могут возникнуть при планировании и выполнении сборки, и заметили, что, хотя некоторые сбои могут быть устранены реактивно на более низком уровне, другие необходимо будет передавать наверх - к совещательному планированию. Хотя объяснение полной иерархии классов выходит за рамки данного исследования, наиболее значимыми классами сбоев в системе сборки были сбои планирования задач, связанные с object grounding, и некритичные сбои выполнения, связанные с вероятностной полнотой. Grounding failures возникали, когда искомые объекты не находились в ожидаемых или оптимальных состояниях для сборочных приспособлений, что иногда требует пересмотра плана с помощью планировщика задач. + +### Деревья поведения + +Для реализации деревьев поведения использовалась библиотека [BehaviorTree.CPP](https://github.com/BehaviorTree/BehaviorTree.CPP) и пользовательский интерфейс для редактирования деревьев [Groot](https://github.com/BehaviorTree/Groot). Деревья поведения загружаются во рантайме и запускаются специальной программой BT-executor, которая работает в другой группе процессов Supervisor, нежели аппаратное обеспечение робота. Таким образом, когда перезапускается аппаратный узел или даже вся роботизированная система, дерево поведения продолжает работать и может возобновить выполнение – это значительно повышает отказоустойчивость. Каждый шаг выполнения записывается в key-value базу данных под названием `Blackboard`, которая используется для сохранения текущего состояния и для связи между узлами. + +Типы действий (конечных узлов Behaviour Tree) поведенческого уровня: +* `MoveJoint` - Принимает в качестве цели (joint goal) либо предварительно вычисленное имя ключевого кадра (keyframe), либо числовые значения шарнира. Если это возможно, перемещает руку робота к цели. +* `MoveEE` - “Перемещение рабочего органа”. Принимает 6-мерную декартову пространственную цель для рабочего органа. Выполняет вычисления обратной кинематики и перемещает манипулятор робота так, чтобы фрейм конечного эффектора совпадал с фреймом цели +* `Grasp` - Открывает/закрывает пальцы захвата. Может также принимать значение от 0 до 1 для частичного открытия/закрытия +* `MoveUntilFF` - Перемещает робота вдоль текущей оси до тех пор, пока датчик силы UR5e не обнаружит силу, превышающую указанный порог +* `SearchAlign` - Выполняет поиск по спирали в текущей плоскости (перпендикулярно пальцам захвата) для отверстия или полости +* `NJInsert` - NonJammingInsert, “Вставка без заклинивания”. После нахождения отверстия с помощью `SearchAlign`, если мы просто протолкнем предмет в руке робота в отверстие, очень вероятно, что он застрянет (из-за строгих допусков). Объект толкается под небольшим углом в направлении, противоположном тому, где датчик ощущает наибольшую силу. Направление изменяется в режиме реального времени в соответствии с текущими значениями датчика силы +* `EstimatePose` - Учитывая изображение RGB и название объекта, оценивает позу объекта(объектов) в 6D в кадре камеры +* `ComputeGrasp` - Используя имя объекта и его 6-мерную позу (в любой допустимой системе координат, обычно в кадре камеры), вычисляет позу конечного эффектора для стабильного захвата объекта. Эта поза захвата предварительно вычисляется для всех объектов с помощью [Graspit](https://github.com/graspit-simulator/graspit) и сохраняется в базе данных. + +Иллюстрация исполнения дерева поведения для реализации задачи вставки детали: + +![](img/ca_bt_execution_full.jpg) + +Подробное описание узлов 5-10 + +![](img/ca_bt_execution.jpg) + +### Специальные конструктивные решения + +Авторы отмечают, что использование специальных конструктивных решений может значительно снизить сложность всей системы. Это наглядно иллюстрируется конструкцией пальцев: + +![](img/ca_special_finger_design.jpg) + +Пальцы имеют углубления для лучшего удержания винтов и стабилизации вала, а также имеют скошенную конструкцию, чтобы убедиться, что после захвата эластичная лента не вырывается. Эта конструкция была разработана в результате тщательного отбора из нескольких вариантов. Конструкция существенно упрощала захват. Например, даже если деталь располагалась с небольшим смещением от оптимальной позиции захвата, то она просто “вставала на место” из-за углублений. + +Авторы также подчеркивают и обратное - неоптимальные конструкторские решения могут увеличить сложность системы. Например, наручные камеры Robotiq были смещены от центра оси захвата (смотрели вниз под углом от запястья) и это создавало проблемы для системы зрения. + +### Оценка положения детали + +Авторы отмечают, что детали сборки из Assembly Challenge отличаются от объектов, которые обычно используются для задач оценки положения - они не имеют ярко выраженной текстуры, имеют различную симметрию, глянцевость, радиальную анизотропию и имеют мало отличительных свойств. Это делает задачу оценки позиции сложнее. Своё видение решения задачи с помощью RGB они изложили в работе [Pose Estimation of Specular and Symmetrical Objects](https://www.researchgate.net/publication/345215874_Pose_Estimation_of_Specular_and_Symmetrical_Objects). + +### Обеспечение надёжности исполнения + +Для проверки надёжности исполнения задания была введена метрика `MTUI` (mean time until intervention, среднее время до вмешательства человека). Без дополнительных мер обеспечения надёжноси MTUI был крайне низким, так как sampling-based планировщики движения не всегда находили правильное решение (в установленные сроки) и многие драйверы оборудования с открытым исходным кодом предоставляли ненадежные интерфейсы. Включение восстанавливающих работу функций с помощью деревьев поведения __немного улучшило показатель MTUI__. Добавление watchdog-подсистемы, которая отслеживала все +аппаратные компоненты и могла даже перезапустить всю систему в случае наихудших сбоев, __значительно улучшило MTUI__. +То есть использование подсистемы сторожевого пса для перезапуска вышедших из строя компонентов и использование деревьев поведения для возобновления выполнения и восстановления. Использование watchdog и деревьев поведения позволило довести показатель MTUI в среднем до трёх часов непрерывной работы. + +### Проблемы + +Аппаратные + +- При проектировании аппаратного обеспечения не учитывалось распределение нагрузки между USB-контроллерами. Из-за перегрузки оборудования (слишком много камер на одном контроллере) наблюдались частые сбои драйверов для камер. Эта проблема также перешла на захваты, которые находились на том же контроллере, что и камера. Исправлено путем подключения камер к различным USB-контроллерам и захватам к третьей шине компьютера +- Помехи между протоколами/кабелями USB-2 и USB-3 приводили к частым сбоям драйверов как для камер, так и для захватов. Исправлено с помощью удлинителей USB 3.0 +- Проблемы с отключениями механических захватов. Несмотря на то, что захваты были на другом USB-контроллере, всё равно приходилось время от времени перезапускать захваты с помощью watchdog +- Сбой связи с манипуляторами. Протокол для связи ROS и UR5e имеет случайные сбои и требовал перезапуска. Это было обнаружено в логах +- Колебательное поведение робота при включении контроллера соответствия. Потребовались месяцы, прежде чем они определили первопричину: точка доступа Wi-Fi поблизости вызвала шум датчика силы и крутящего момента робота. + +Программные + +- Контроллеры ROS не запускались. Было исправлено путем отслеживания списка активных контроллеров и перезапуска вышедших из строя контроллеров +- Планировщики стохастического движения иногда падали, даже если существовал выполнимый план. Решалось простым перепланированием +- Состояние гонки по описанию робота (описание робота не загружено на сервер параметров ROS до того, как это потребуется Контролеру соответствия - compliance controller из ros_control). Исправлено путем добавления 5-секундной задержки перед запуском контроллера соответствия +- Многие драйверы оборудования с открытым исходным кодом предоставляли ненадежные интерфейсы + +### Извлечённые уроки + +- Ориентация на устранение неисправностей, модульность, реактивность - ключевые характеристики для обеспечения гибкой сборки +- Продуманные конструкторские решения снижают сложность задачи +- ROS 1 не подходит для промышленного применения: + - Интеграция двух манипуляторов и захватов робота в интегрированную систему была сложной задачей и требовала сложного управления пространством имен. ROS 1 не очень хорошо подходит для настройки нескольких роботов. + - ROS 1 изначально не поддерживает управление в реальном времени. Без реального контроля в режиме реального времени невозможно дать официальные гарантии + - Ограниченные промежуточные и продвинутые учебные руководства. Нет стандартных рекомендаций по структурированию сложной роботизированной системы. + +### Использованное ПО + +- ОС Ubuntu 18.04 +- ROS Melodic +- MoveIt/OMPL/LazyPRM для планирования движений +- BehaviorTree.CPP для деревьев поведения +- PyTorch для оценки позиции детали \ No newline at end of file diff --git a/sidebars.js b/sidebars.js index 860df29..cf649b8 100644 --- a/sidebars.js +++ b/sidebars.js @@ -27,7 +27,7 @@ module.exports = { items: [ 'technologies/machine-learning-in-robotics', 'technologies/gripper-tools-research', - 'technologies/o2ac-repo-review', + 'technologies/wrs2020-assembly-challenge', 'technologies/plansys2', 'technologies/ASP-overview', 'technologies/motion-planning',