Added UC San Jose Assembly Challenge project
This commit is contained in:
parent
2f6c56584e
commit
7223c8636d
6 changed files with 118 additions and 26 deletions
BIN
docs/technologies/img/ca_bt_execution.jpg
Normal file
BIN
docs/technologies/img/ca_bt_execution.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 85 KiB |
BIN
docs/technologies/img/ca_bt_execution_full.jpg
Normal file
BIN
docs/technologies/img/ca_bt_execution_full.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
BIN
docs/technologies/img/ca_schematics.jpg
Normal file
BIN
docs/technologies/img/ca_schematics.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
docs/technologies/img/ca_special_finger_design.jpg
Normal file
BIN
docs/technologies/img/ca_special_finger_design.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
|
|
@ -1,8 +1,9 @@
|
|||
---
|
||||
id: o2ac-repo-review
|
||||
title: 'O2AC Assembly Challenge 2021'
|
||||
id: wrs2020-assembly-challenge
|
||||
title: 'Assembly Challenge 2020'
|
||||
---
|
||||
## Предыстория
|
||||
|
||||
## Проект команды O2AC
|
||||
|
||||
|
||||
|
||||
|
|
@ -20,9 +21,7 @@ title: 'O2AC Assembly Challenge 2021'
|
|||
8. Обнаружение и захват деталей расположенных в лотке неструктурировано
|
||||
9. Для установленных деталей используется библиотека TF которая содержит локальную систему координат каждого установленного элемента
|
||||
|
||||
## Обзор репозитория
|
||||
|
||||
Репозиторий состоит из 19 пакетов, в том числе есть пакеты которые достойны рассмотрения для реализации нашего Робосборщика. Кратко пройдёмся по каждому из них.
|
||||
Репозиторий проекта состоит из 19 пакетов, в том числе есть пакеты которые достойны рассмотрения для реализации нашего Робосборщика. Кратко пройдёмся по каждому из них.
|
||||
|
||||
### aist_modules
|
||||
|
||||
|
|
@ -131,19 +130,19 @@ def on_stop(self):
|
|||
|
||||
|
||||
|
||||
## 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):
|
|||
|
||||
|
||||
|
||||
### Порядок распознавания (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. Системный уровень отвечает за прозрачное восстановление после сбоев, не связанных с планированием.
|
||||
|
||||
### Структурная схема установки
|
||||
|
||||
|
||||
|
||||
### Планирование задач с обработкой ошибок
|
||||
|
||||
Разработчики смоделировали систему планирования на основе классической трехуровневой архитектуры (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) и сохраняется в базе данных.
|
||||
|
||||
Иллюстрация исполнения дерева поведения для реализации задачи вставки детали:
|
||||
|
||||
|
||||
|
||||
Подробное описание узлов 5-10
|
||||
|
||||
|
||||
|
||||
### Специальные конструктивные решения
|
||||
|
||||
Авторы отмечают, что использование специальных конструктивных решений может значительно снизить сложность всей системы. Это наглядно иллюстрируется конструкцией пальцев:
|
||||
|
||||
|
||||
|
||||
Пальцы имеют углубления для лучшего удержания винтов и стабилизации вала, а также имеют скошенную конструкцию, чтобы убедиться, что после захвата эластичная лента не вырывается. Эта конструкция была разработана в результате тщательного отбора из нескольких вариантов. Конструкция существенно упрощала захват. Например, даже если деталь располагалась с небольшим смещением от оптимальной позиции захвата, то она просто “вставала на место” из-за углублений.
|
||||
|
||||
Авторы также подчеркивают и обратное - неоптимальные конструкторские решения могут увеличить сложность системы. Например, наручные камеры 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 для оценки позиции детали
|
||||
|
|
@ -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',
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue