Added UC San Jose Assembly Challenge project

docs/technologies/wrs2020-assembly-challenge.md

@@ -1,8 +1,9 @@
 ---
-id: o2ac-repo-review
+id: wrs2020-assembly-challenge
-title: 'O2AC Assembly Challenge 2021'
+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 для оценки позиции детали

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',