Роботизированная сварка двумя роботами

Оригинал: Self-Organization and Self-Coordination in Welding Automation with Collaborating Teams of Industrial Robots, 2016 (Самоорганизация и самокоординация в автоматизации сварки с использованием комплекса взаимодействующих сварочных роботов)

Аннотация

В области автоматизации сварки можно отметить растущий интерес к применению промышленных робототехнических комплексов для выполнения производственных процессов посредством взаимодействия. Несмотря на то, что взаимодействие роботов может повысить прибыльность и рентабельность производства, программирование роботов по-прежнему остается проблемой. Программирование чрезвычайно трудоемко и требует специальных знаний в области синхронизации действий роботов, чтобы избежать любого столкновения. Поэтому для решения этих проблем мы начали исследовательский проект. В этой статье будут представлены стратегии, концепции и результаты исследований в области применения операционной системы роботов (ROS) и решений на основе ROS для преодоления существующих технических недостатков за счет интеграции возможностей самоорганизации, автономного планирования пути и самокоординации роботов. Новый подход должен способствовать улучшению взаимодействия роботов и самокоординацию в производственном секторе при более высоком уровне гибкости и снижении потребности в человеческом вмешательстве.

Введение

Применение промышленных роботов в автоматизированных сварочных процессах хорошо зарекомендовало себя с увеличением числа продаж роботов по всему миру с каждым годом [1]. Чтобы оставаться конкурентоспособными на этом растущем рынке и удовлетворять потребности клиентов, все производители роботов прилагают много усилий для повышения производительности своей продукции. Это достигается, в частности, за счет технических инноваций, расширения функциональных возможностей и повышения надежности.

В этом контексте в течение нескольких лет в центре внимания оказывались новые концепции автоматизации. Они основаны на производственных ячейках с несколькими промышленными роботами и передовыми концепциями управления, которые позволяют роботам совместно использовать общее рабочее пространство и выполнять производственные процессы посредством сотрудничества.

Существует множество причин, почему используются скоординированные промышленные робототехнические комплексы. Преимущества особенно очевидны в случае сложных сварочных работ, которые сложно, неэффективно или неэкономично выполнять только одному роботу. Поэтому, если это применимо, взаимодействие роботов может способствовать повышению доходности, эффективности и рентабельности при автоматизации производства [2].

В настоящее время большинство «мультироботных» станций, устанавливаемых или предлагаемых на рынке, построены из роботов одного типа или семейства продуктов. Это связано с индивидуальными концепциями, разработанными производителями роботов для обеспечения контролируемого взаимодействия и совместной деятельности. Очень распространены концепции "ведущий-ведомый" для поддержки сложных и трудоемких процедур программирования с помощью специально разработанных функций проприетарного программного обеспечения. Известными примерами в этом контексте являются, например, функция MultiMove ABB, Независимая/координируемая функция Motoman Yaskawa или функция RoboTeam, запущенная KUKA [3-5]. Параллельно с разработкой продуктов производителями роботов, обширные научные исследования также привели к появлению множества новых технологий в робототехнике за последние десятилетия. Это привело к существенному усовершенствованию функциональности, росту применимости и повышению производительности роботизированных систем. В этом контексте технология мультиробота также стала предметом исследований и технологических разработок. Между тем, доступно множество ценных результатов, зависящих от конкретных настроек и прикладных программ. Они предоставляют полезную платформу технологий и программных средств для дальнейшего развития робототехники, и особенно для мультироботных приложений [6,7]. В частности, продукты с открытым исходным кодом со свободным доступом к существующим технологическим достижениям, например, в области планирования движения, предотвращения столкновений, восприятия окружающей среды, локализации, поиска и картографирования, все чаще применяются разработчиками при развертывании новых систем и передовых робототехнических технологий [8,9].

Однако следует признать, что большинство достижений, полученных в результате исследований в этом секторе, были посвящены применению мобильных систем или групп мобильных роботов, участвующих в скоординированных действиях при различной степени автономности системы. Хорошо известны в этом контексте результаты исследовательских инициатив в области RoboCup Soccer и RoboCup Rescue, где постоянно растущее сообщество ученых и исследователей создало широкую платформу для исследований, технологических разработок, конкуренции и обмена многочисленными техническими и технологическими решениями [10-12].

Менее значимым, по сравнению с мировыми исследовательскими инициативами в области мобильных роботов, является разработка передовых технологий и автономии для мультироботных приложений в условиях промышленности. Это особенно актуально в области автоматизации дуговой сварки. Причиной этого являются технико-технологические сложности, поскольку здесь координация и сотрудничество касаются не только того, как контролировать движение роботов внутри комплекса, но и того, как распределить рабочую нагрузку между роботами таким образом, чтобы обеспечить максимальную экономическую эффективность и производительность комплекса, а также как справляться с требованиями и ограничениями, вызванными самим процессом сварки. Компания Motoman Yaskawa в 1994 году впервые внедрила технологию мультиробота для дуговой сварки и стала лидером рынка в этом секторе. Однако применимость их технологии ограничена и позволяет проектировать и настраивать взаимодействующие мультироботные станции только с продуктами Motoman (роботы и контроллеры) и только для конкретных задач автоматизации сварки [13]. Несмотря на этот прогресс, автоматизация совместной сварки с использованием технологии мультиробота остается сложной, и многие технические проблемы и вопросы все еще остаются нерешенными.

Одна из этих проблем, например, связана с вопросом о том, как действовать, если для достижения определенных экономических целей в производстве должно быть реализовано взаимодействие в команде разнородных промышленных роботов с совершенно разными устройствами управления. В этом случае техническая реализация в основном терпит неудачу из-за значительных усилий, необходимых для программирования, отсутствия совместимости и недостаточных концепций управления и взаимодействия

Следовательно, с учетом данной ситуации, исследовательский проект, представленный в данной статье, был инициирован для более подробного изучения проблем применения мультироботов и разработки основных технических решений, которые помогут преодолеть все еще существующие проблемы и обеспечить большую гибкость в применении технологии мультироботов в производственных условиях с автоматизацией дуговой сварки посредством передовых концепций управления и интеграции определенной степени автономности в существующие системы. Чтобы приступить к любому исследованию, связанному с данной темой, сначала необходимо рассмотреть несколько аспектов и вопросов, имеющих особое значение, чтобы обеспечить определенную основу для работы над проектом:

• Как сформировать нейтральное описание работы, в котором будут указаны действия, которые должны выполняться роботами?
• Как следует осуществлять спецификацию работы для планирования действий и самокоординации роботов?
• Как реализовать автономию с точки зрения планирования пути и самокоординации?
• Как обеспечить беспрепятственное движение роботов внутри общего рабочего пространства?
• Как создать и спроектировать соответствующую инфраструктуру коммуникации, взаимодействия и управления?

Описание работы на основе XML

Основополагающим для любых действий по планированию и управляемому взаимодействию в мультироботных системах является подробное описание производственных задач, которые должны выполняться роботами. Как правило, спецификация действий робота является частью работы оператора во время явного программирования каждого отдельного робота и синхронизации их взаимодействия, чтобы избежать любых столкновений.

Для замены так называемого «обучающего» программирования, которое, как уже говорилось, является сложным и часто очень трудоемким, предпочтение отдается решениям на основе сценариев, таким как сети Петри, программирование на основе иконок или другим сценариям. В рамках проекта было предложено описание спецификации действий на основе XML. Он удобочитаем как для человека, так и для машины, может применяться независимо от платформы и способен предоставлять всю информацию и данные о пути для обеспечения надлежащего планирования и координации действий роботов с помощью компьютеров. Для роботизированной сварки в этом описании работы должны учитываться не только геометрические, но и технологические данные. И то, и другое должно быть дополнено инструкциями по управлению периферийными устройствами, если это необходимо. Геометрические данные обычно представляют пространственное положение линий сварки, ориентацию рабочего органа во время сварки, а также точки в трехмерном рабочем пространстве, которые должны использоваться роботами по соображениям безопасности и начального позиционирования. Кроме того, технологические данные должны указывать условия процесса, такие как скорость сварки, ориентация сварочного пистолета, выступ проволочного электрода или плетение горелки. Наконец, необходимо учитывать данные для определения условий источника питания и подачи проволоки, а также положения сварки, такого как горизонтальное, вертикальное вверх, верхнее, вертикальное вниз или сварка в положениях, влияющих на гравитацию. Генерация описания должностных обязанностей в проекте была выполнена с помощью специально разработанного программного средства. Он включает редактор, графические пользовательские интерфейсы и набор функций для интерактивного создания XML-файлов пользователем. Применяемая семантика связана с международными стандартами в области сварочного производства (EN ISO 15611, 15614). На рисунке 1 показана серия инструкций и данных, взятых из типичного описания работы на основе XML, созданного в рамках проекта

Рисунок 1 - описание работы c использованием XML

В этом контексте все XML-описания, применяемые в проекте, касаются только перемещения инструмента, например сварочного пистолета, для выполнения технологического задания. Инструкции или информация, относящиеся к роботу или его кинематической структуре, не рассматриваются. Поэтому описания функций XML очень гибки в использовании и могут быть адаптированы к любому роботу или сварочному аппарату при наличии соответствующего постпроцессора.

Планирование и самоорганизация совместной работы роботов

Как упоминалось ранее, цель этого исследования состояла в том, чтобы дать возможность комплексу роботов организовывать, планировать и координировать свою работу автономно без какого-либо вмешательства человека-оператора.

Для достижения этой цели было решено не начинать с нуля, разрабатывая новые инструменты планирования, а использовать сервисы операционной системы роботов (ROS) в качестве платформы с открытым исходным кодом и применять функции ROS, такие как MoveIt! для планирования движения, обратных кинематических расчетов, проверки столкновений и для управления любым взаимодействием роботов, даже если они имеют разных производителей [14].

Первой задачей для планировщика, являлось декодирование описания работы в формате XML. Для этой цели был создан узел ROS с использованием библиотеки «roscpp» и «TinyXML». С помощью встроенного анализатора узел должен был извлекать данные о местоположении линий сварки, а также соответствующие параметры процесса и загружать их в список действий. После преобразования позиций из координат заготовки в мировые координаты ячейки робота сгенерированный список действий служил базой данных для любых дальнейших действий по планированию.

С практической точки зрения, любая деятельность робота в области автоматизации сварки должна учитывать два стандартных сценария применения, имеющих важное значение для предусмотренной концепции планирования:

• Планирование действий робота, выполняемых в статической рабочей среде при определенном пространственном положении и ориентации обрабатываемой детали;
• Планирование действий робота, выполняемых в постоянно меняющейся рабочей среде. Это произойдет, например, в случае изменения положения заготовки и частой переориентировкой свариваемой детали с помощью интегрированного многоосевого позиционера заготовки.

Самоорганизация робототехнического комплекса в статических рабочих средах

Хотя любое планирование действий для роботов, в комплексе, должно быть приспособлено к типу сценария приложения, есть еще один важный аспект, который следует учитывать. Это связано с критериями оптимизации. В этом контексте рассматривается распределение действий внутри комплекса роботов, которое должно обеспечивать минимальное время выполнения заданий. Таким образом, планирование движения и самоорганизация также должны обеспечивать решение проблемы оптимизации при балансировке рабочей нагрузки внутри комплекса роботов

Для решения такого рода оптимизационных задач были разработаны и внедрены «алгоритмы самоорганизации». Они были разработаны с учетом различных сценариев применения и позволяют определять и распределять действия в режиме реального времени, следуя определенным критериям оптимизации. В этом проекте они были связаны с критерием «кратчайшего пути».

Для статической рабочей среды алгоритмы использовали набор матриц планирования из (n + 2) $\mathrm{\times}$ (n + 2) элементов, по одному для каждого робота комплекса, где (n) представляет общее количество линий, подлежащих сварке. Расширение двумя дополнительными матричными элементами было необходимо для учета перемещений роботов с их исходных позиций на старте выполнения любой работы и возвращения в исходное положение после завершения сварочной работы.

Внутри самой матрицы каждый элемент $P_{i,k}$ с $i\ =\ 1,\ .\ .\ .\ ,\ n\ +\ 2$ (индекс столбца) и $k\ =\ 1,\ .\ .\ .\ ,\ n\ +\ 2$ (индекс строки) содержит параметр времени в секундах. Этот параметр также указывает расчетное время прохождения робота (на основе евклидовых расстояний) при перемещении из его текущей позиции в целевое позицию внутри рабочего пространства. Или, в случае матричных элементов, расположенных по главной диагонали, коэффициенты представляют время сварки соединения, определяемое положением и индексами матричного элемента. Например, $P_{2,2}$ указывает время сварки для соединения 1, $P_{3,3}$ для соединения 2 и т.д.

В соответствии с примером, представленным на рисунке 2, вычисление начинается с элемента $P_{1,1}$ (исходная позиция) и продолжается поиском ближайшей целевой позиции для следующего робота. Эта позиция определяется путем оценки всех временных факторов в элементах матрицы индекса столбца i = 1, соответствующий элементам $P_{1,2}$ до $P_{1,n+2}$. Элемент матрицы, полученный с наименьшим параметром времени, определяет индекс строки k, который должен использоваться для определения позиции, в которую робот должен перейти следующим. Установив индекс i равным k, адресуется соответствующий матричный элемент $P_{i,k}\ =\ P_{k,k}$ на главной диагонали. Это время сварки (20 с) для следующего сварного соединения. Аналогичные вычисления были связаны с матрицами, посвященными другим роботам комплекса. Элементами матрицы, которые уже используются в цикле расчета, следует пренебрегать во всех дальнейших действиях по планированию.

Рисунок 2 - Матрица самоорганизации с данными по времени в секундах (пример)

После того, как все роботы комплекса завершили свои первые сварочные операции, самоорганизационный алгоритм продолжил новую операцию поиска. Отправной точкой теперь был тот матричный элемент на главной диагонали, который был найден для идентификации соединения, выбранного для сварки. С этой позиции матрицы алгоритм снова попытался найти следующий наименьший коэффициент времени, проверив все элементы столбца с индексом i = 2. Как только был определен наименьший коэффициент времени (2 с), найден новый индекс строки k (k = 5). Это устанавливает элемент матрицы на главной диагонали ($P_{5,5}$) с коэффициентом времени (60 с), относящимся к следующему соединению, выбранному для сварки. Таким образом, необходимо выполнить все дальнейшие циклы расчета, каждый с поиском по столбцам наименьшего временного параметра, чтобы найти новый индекс строки k для следующего сварного шва, после чего по строкам идентифицировать элемент матрицы $P_{i,k}$ на главной диагонали с i = k. Данная процедура должна повториться для всех матриц действий роботов в комплексе.

В ходе этой процедуры самоорганизации соответствующие временные параметры для каждого робота накапливались цикл за циклом, так что фактическое рабочее время (время работы + время сварки) для каждого из роботов всегда было доступно и могло контролироваться.

Время работы роботов имело особое значение при подходе к концу процедур расчета и оптимизации. Обычно количество остаточных швов, подлежащих сварке либо:

1. меньше, чем количество роботов в команде; или
2. равно количеству роботов в команде

В случае (1) алгоритм самоорганизации должен распределять итоговые задачи сварки не только в соответствии с критериями «кратчайшего пути». Он также должен заботиться о сбалансированной рабочей нагрузке роботов в комплексе, чтобы обеспечить минимальное время выполнения работы. Поэтому приоритет при распределении сварочных задач предпочтительно отдается тем роботам, у которых наименьшее накопленное время работы. Любое решение «согласованности следующего действия» или «не согласованности следующего действия» после каждого цикла расчета принималось алгоритмами самоорганизации следующим образом:

• Накопленное время работы робота + Остаточное время для выполнения сварных швов]/ [Количество роботов в команде] = Расчетное время работы в среднем на одного робота
• ЕСЛИ [Расчетное время работы в среднем на одного робота] $\mathrm{>}$ [Фактическое накопленное время работы робота], ТО -$\mathrm{>}$ Решение: Следующее действие согласовано
• ЕСЛИ [Следующее действие согласовано], ТО [Расчет индивидуальной коэффициента DRi роботов]
• DRi = [Расчетное время работы в среднем на одного робота]/[Фактическое накопленное время работы робота]; при i = (1, ..., m); m = общее количество роботов в команде
• Окончательное распределение сварочных задач роботам с наименьшим временем работы:
  • ДЛЯ I = 1 к числу остаточных сварных швов, которые необходимо выполнить далее
  • X = Max $\mathrm{\{}$DR1, DR2, ..., DRm$\mathrm{\}}$
  • X определяет робота, который возьмет на себя одну из остаточных сварных швов
  • Удалить коэффициент DRx = X из $\mathrm{\{}$$\mathrm{\}}$
  • ДАЛЬШЕ

Самоорганизация в динамически меняющихся рабочих средах

Как упоминалось выше, второй типичный сценарий применения в автоматизации сварки представляет собой комплексы роботов со встроенными позиционерами заготовок, позволяющими переориентировать заготовки в соответствии с требованиями к качеству. В частности, поворотно-наклонные столы часто применяются для обеспечения сварки в горизонтальном или так называемом «гравитационном» положении (рис. 3). Для высококачественных сварных швов это положение имеет важное значение из-за симметричного подвода тепла к основному материалу и оптимального поведения сварочной ванны.

Рисунок 3 - Поворотно-наклонный стол для сварки в гравитационном положении

Для запуска процесса самоорганизации в динамически изменяющихся средах, программе на основе ROS необходимо извлечь положения линий сварки и ориентации инструмента из XML повторно. После преобразования в мировую систему координат, используемую в ROS и MoveIt!, программа MoveIt! снова подготовила список действий в качестве базы данных для процедур самоорганизации

Организация рабочей нагрузки и распределение работ между роботами, входящими в комплекс, должны были снова соответствовать критерию «кратчайшего пути», чтобы обеспечить минимальное время выполнения работы. Однако на этот раз немаловажное значение имело не только движение робота, но и ориентация заготовки на поворотно-наклонном столе, а также положение линий сварки, заданных в конфигурации.

Чтобы эффективно учитывать эти ограничения, все выполняемые сварные швы, сначала были разделены на два класса. Один класс содержал все линейные, а другой все круговые сварные швы. Это разделение было необходимо из-за различных концепций планирования траектории для роботов при выполнении линейных или круговых путей в сочетании с внешними осями поворотного и наклонного стола. На рисунке 4 приведена структурная схема реализованных алгоритмов самоорганизации. После загрузки всех позиций линии сварки и связанных с процессом параметров с $\mathrm{<}$ROS Parameter Server$\mathrm{>}$ на этапе $\mathrm{<}$Initialization$\mathrm{>}$ последовала последовательность $\mathrm{<}$CheckJob$\mathrm{>}$ для разделения типов сварочных задач на два класса сварных швов LIN и CIRC

Рисунок 4 - Алгоритм самоорганизации, реализованный для совместной сварки роботов с внешними осями поворотно-наклонного стола.

Алгоритм начинается с класса LINE и проверяет расположение и ориентацию линейных сварных швов, закрепленных на поворотном столе. Чтобы обеспечить сварку в «гравитационном положении», ориентация стола должна всегда находиться в наклонном положении 45$\mathrm{{}^\circ}$, как показано на рисунке 3. Если был обнаружен один из линейных сварных швов из класса LIN и разрешена сварка в горизонтальном (гравитационном) положении, то MoveIt! берёт управление на себя, сообщая соответствующее положение для начала сварки, и продолжая планировать движение робота в $\mathrm{<}$Move Robot$\mathrm{>}$. На этапе принятия решения робот выбирался исходя из того, у кого было наименьшее евклидово расстояния до линии сварки

В нашей тестовой программе, обычно, для совместной работы рассматривались два робота разных типов. Таким образом, алгоритмы самоорганизации на рисунке 4 включают две функции планирования пути, управляемые MoveIt!, одну для робота ABB (Вестерас, Швеция) и одну для робота KUKA (Аугсбург, Германия) (LBR).

В случае, если линия сварки в горизонтальном положении из класса LIN не может быть найдена, столу приходила инструкция продолжать вращаться с небольшими шагами до тех пор, пока не будет доступна линия сварки с соответствующей ориентацией. После завершения всех сварных швов класса LIN последовала сварка соединений класса CIRC.

Также алгоритм самоорганизации начал обращаться к классу CIRC, чтобы проверить, совпадает ли данная ориентация с одним из круговых сварных швов с горизонтальной (гравитационной) ориентацией.

Гравитационной положение находится в координатах К1 поворотного стола, если длина вектора WeldStart в K1 является максимальной. В данном случае находится круговой сварной шов в гравитационном положении, и определяется исполняемый робот комплекса для данной задачи. Критерием выбора опять же было кратчайшее евклидово расстояние до WeldStart позиции. Как только «ближайший» робот найден, MoveIt! начинает расчёт обратной кинематической задачи, для того чтобы робот мог перейти в положение WeldStart, путём передачи углов поворота каждого сочленения в контроллер движения робота.

Пока поворотный стол оставался в неизменном положении, были рассчитаны контрольные точки Pc на круговой траектории. Эталоном была локальная система координат Kc с положением начала сварки в качестве исходного. Ось Xc была определена как вектор направления между началом сварки и концом сварки. ZC был направлен параллельно Z3 системы координат таблицы K3 в соответствии с рисунком 5

Рисунок 5 - Геометрические условия при планировании движения робота и поворотного стола для круговых сварных швов в гравитационном положении.

С помощью этого определения контрольные точки $P_{\textrm{С}}(t)$ могут быть рассчитаны вдоль круговой линии сварки для любого времени t путем

$${}^{(c)}{P_{Cx}}\left(t\right)=\left[R\times \frac{{\mathrm{sin} \left(\beta \left(t\right)\right)\ }}{{\mathrm{sin} \left(\alpha \left(t\right)\right)\ }}\right]{\mathrm{cos} \left(\alpha \left(t\right)+{\phi }_M\right)\ }$$

$${}^{(c)}{P_{Cy}}\left(t\right)=\left[R\times \frac{{\mathrm{sin} \left(\beta \left(t\right)\right)\ }}{{\mathrm{sin} \left(\alpha \left(t\right)\right)\ }}\right]{\mathrm{sin} \left(\alpha \left(t\right)+{\phi }_M\right)\ }$$

где: $R$ -- радиус круговой линии сварки; ${\phi }_M$ -- угол между ${\mathrm{X}}_{\mathrm{C}}$ и вектором ${\mathrm{P}}_{\mathrm{START}}$ до центральной точки $\mathrm{M}$ круговой траектории; $\beta (t)$ -- угол между векторами $M_{P_c}$ и $M_{P_{Start}}$; $\alpha (t)$ -- угол между векторами ${P_{START}}_{P_c}$ и $M_{P_c}$. Преобразование координат было необходимо для трансформации позиций $P_c(t)$ в систему координат $K_3$ поворотного стола:

$${}^{(3)}P\left(t\right)={{}^cT}_c\times {{}^{(c)}P}_c\left(t\right)$$

Перед процессом сварки в гравитационном положении с имитацией движения робота и поворотного стола необходимо указать угол $\delta$, равный углу между радиус-вектором ${{}^{(3)}P}_{START}$ и $Y-Axis$ из $K_3$

$${\mathrm{sin} \delta \ }=\frac{{{}^{\left(3\right)}P}_{STARTx}}{r_1}$$

$${\mathrm{cos} \delta \ }=\frac{{{}^{\left(3\right)}P}_{STARTy}}{r_1}$$

$$r^2_1={{}^{(3)}P}^2_{STARTx}+{{}^{(3)}P}^2_{STARTy}$$

Зная $\delta$ и угол поворота стола $\mathrm{\Delta }\delta$ за интервал времени $\mathrm{\Delta }t$, можно рассчитать любое изменение положения управления ${}^{(3)}P(t)$ на круговой линии сварки, пока поворотный стол вращается с угловой скоростью $\omega$ :

$${}^{(3)}{P_X}\left(t\right)=R\times {\mathrm{sin} \left(\delta +n\times \mathrm{\Delta }\delta \right)\ }$$

$${}^{(3)}{P_Y}\left(t\right)=R\times {\mathrm{cos} \left(\delta +n\times \mathrm{\Delta }\delta \right)\ })$$

Где:

$$\omega =\frac{\mathrm{\Delta }\delta }{\mathrm{\Delta }t}$$

$$R^2={{}^{(3)}P}^2_x+^{(3)}P^2_y$$

$$n=0,1,2,\ \dots ,m$$

После преобразования из $K_3$ в мировую систему координат $K_0$ при:

$${}^{(0)}P\left(t\right)={{}^3H}_0{\times }^{(3)}P\left(t\right)$$

Сварка кругового участка в гравитационном положении может быть выполнена с помощью вращающегося стола. Скорость вращения стола определяется длиной сварочного пути и скоростью сварки, указанной в описании работы на основе XML.

В случае, если ни линейный, ни круговой сварной шов не могут быть найдены в гравитационном положении на поворотном столе, орган управления станцией должен дать команду столу поворачиваться на определенный угол (например: $\pm 30^o$) до тех пор, пока новые линии сварки из списка не будут найдены в гравитационном положении для сварки.

Как только сварочный пистолет достиг положения сварки, вращение поворотного стола остановилось, и задача сварки была выполнена. Алгоритмы самоорганизации и планирования продолжились с Check Job (рисунок 4) до тех пор, пока все соединения не будут сварены.

Автономное планирование движения без столкновений

Как видно из предыдущего раздела, алгоритмы, предлагаемые для самоорганизации и координации работы роботов внутри комплекса, не учитывают никакого планирования траектории, позволяющего надлежащим образом и без столкновений выполнять сварочные работы, назначенные каждому из роботов. Поэтому, особенно для перемещений от одной линии сварки к другой, необходимо было расширить функциональность самоорганизации и координации с соответствующими ресурсами для планирования движения. В качестве наиболее эффективного инструмента для этой задачи планирования движения в ROS мы выбрали интегрированную «Open Motion Planning Library (OMPL)» из фреймворка MoveIt! для обеспечения траекторий, свободных от столкновений [15]. Из библиотеки алгоритмов планирования движения, предоставленной OMPL, для задачи планирования были выбраны «методы, основанные на выборке». Вместо детального построения пространства конфигурации «методы, основанные на выборке», исследуют пространство C с помощью схемы выборки. Это означает либо: случайный выбор точек в пространстве C и сохранение статуса робота в этих точках в виде узла дерева поиска, затем создание дорожной карты (фаза обучения) для поиска любого кратчайшего пути между заданной начальной и целевой позицией (фаза запроса), либо, в качестве альтернативы, использование последовательности случайных выборочных движений на основе динамически выполнимых элементов пути для построения дерева поиска и поиска пути без столкновений к целевой позиции.

Методы планирования движения, используемые в нашем проекте, касались двух наиболее эффективных методов. Одним из них было «RRT connect» (быстрое исследование случайных деревьев), которое позволяет быстро выполнять двунаправленный поиск пути без столкновений (ускоренный в 3-5 раз по сравнению со стандартным однонаправленным RRT)

RRT --- это алгоритм, который постепенно выращивает дерево из выборок, нарисованных случайным образом в пространстве 3D-поиска. Как только будет нарисован образец $q_r$, будет предпринята попытка установить соединение между $q_r$ и ближайшим, существующим состоянием $q_c$ дерева. Если это соединение возможно и представляет собой путь, свободный от столкновений, $q_r$ приводит к новому состоянию дерева. Обычно длина нового соединения между $q_r$ и $q_c$ ограничена фактором роста $\mathrm{\Delta}$q. В случае, если соединение между $q_r$ и $q_c$ превышает этот предел, новое состояние будет определено на максимально допустимом расстоянии. Таким образом, фактор роста определяет скорость роста. Рост дерева продолжается до тех пор, пока новый $q_r$ не достигнет целевого положения и не будет найден путь без столкновений.

Очевидно, что поэтапное планирование пути на основе выборок займет значительное время. Для ускорения вычислений была выбрана опция «RRT connect». Здесь два дерева, одно из начальной позиции и одно из целевой позиции, растут навстречу друг другу. Состояния двух деревьев могут быть связаны через отрезок пути, который удовлетворяет «критерию кратчайшего пути». Таким образом, путь без столкновений между начальной и целевой позициями для любого движения робота может быть найден намного быстрее, чем при стандартном подходе RRT. Однако оба метода в основном сходятся к решениям, которые далеки от оптимальных.

Вторая процедура планирования пути, применяемая в проекте, была «BKPIECE» (двунаправленное планирование кинетического движения путем исследования внутренних и внешних ячеек (bidirectional kinodynamic motion planning by interior-exterior cell exploration)). Это было выбрано также с учетом динамических ограничений роботов [17], особенно когда использовалась концепция группового узла URDF. Преимущество BKPIECE заключается в том, что динамическое поведение роботов в комплексе, описывается физическими моделями и симуляцией вместо решения уравнений движения. Кроме того, BKPIECE не требует выборки состояний и метрик для оценки расстояния между состояниями, как в RRT. Он применяет планирование траектории на основе деревьев, созданных путем прямого распространения движения. Выполняется случайное движение в пространстве состояний. Начало движения всегда связано с узлами состояния, уже известными в дереве поиска. Каждое движение поиска ограничено фиксированным интервалом времени (размер шага моделирования), и промежуточные состояния вдоль каждого движения генерируются с фиксированным разрешением (размер шага распространения). На основе этих временных пределов с помощью физического моделирования исследуется динамика робота с точки зрения скорости, ускорения, воздействия сил, трения и т.д. во время движения. Если динамические параметры находятся в допустимых пределах и не обнаружено столкновения с препятствиями или самостоятельного столкновения, то устанавливается новый сегмент пути дерева поиска с новым узлом. Чтобы обеспечить быстрый поиск, исследование пространства состояний будет с высоким приоритетом направлено на области, которые меньше охвачены узлами дерева поиска. Расчет охвата осуществляется с помощью BKPIECE путем дискретизации пространства состояний в сетки с фиксированным размером ячеек. Предусматриваются ячейки, которые содержат только один новый узел состояния дерева. Для достижения этой цели размер ячейки необходимо адаптировать с помощью дополнительных уровней дискретизации до тех пор, пока не будет достигнуто соглашение об одном узле на ячейку.

При планировании с дискретизацией пространства состояний необходимо учитывать два типа ячеек: «внешние ячейки» с менее чем 2n соседними ячейками (n = размерность пространства состояний), содержащими проекции поискового движения, и «внутренние ячейки» с 2n соседними ячейками, покрытыми проекциями узлов из поисковых движений. Для роботов-манипуляторов пространственное перемещение обычно приводит к трехмерной проекции.

На первом этапе планирования пути с помощью BKPIECE создается большое количество «внешних ячеек», в то время как по прошествии некоторого времени планирования многие «внешние ячейки» меняют свой статус на «внутренние ячейки». Для обеспечения быстрого планирования, как уже упоминалось, BKPIECE будет отдавать приоритет поисковым операциям в районах с «внешними ячейками», чтобы как можно быстрее охватить все пространство состояний. Эта стратегия увеличит вероятность нахождения пути без столкновений от начала до конечного пункта назначения.

Подобно «RRT connect», BKPIECE предлагает дополнительные преимущества благодаря созданию дерева поиска с двух направлений, от начальной точки, а также от целевой позиции. Это гарантирует более быстрое планирование движения и проверку столкновений. Таким образом, BKPIECE, по--видимому, является благоприятным, особенно для приложений с несколькими роботами.

Поскольку процедуры планирования, в принципе, состоят из случайно сформированных участков траектории или сегментов движения, которые обеспечивают динамически осуществимое движение роботов, может потребоваться определенное вычислительное время в несколько секунд, пока не будет найден путь без столкновений. Аналогично «RRT connect», снова подчеркивается, что, также с помощью BKPIECE, найденный путь не является оптимальным. Иногда он слишком длинный или включает в себя избыточное движение. Поэтому требуется оптимизация пути, которая направлена либо на минимизацию длины пути, либо на сокращение времени в пути. В этом контексте в проекте была применена «оптимизация линейных кратчайших путей» для достижения приемлемых результатов планирования. Это достигается попыткой последовательно связать узлы пути прямыми линиями в пространстве конфигурации, проверить новый элемент пути, чтобы избежать любого столкновения, и заменить старый путь новым. После нескольких итерационных циклов можно найти упрощенную траекторию (рис. 6).

Рисунок 6 - Необработанная траектория после линейной «оптимизации кратчайшего пути»

В конце процесса планирования траектории, созданные OMPL, преобразуются с помощью MoveIt в динамически выполнимые траектории. Каждая точка вдоль найденных траекторий содержит 3D-данные о местоположении в мировых координатах и ориентацию рабочего органа в форме кватерниона. Поэтому для завершения каждого цикла планирования в конце необходимо выполнить обратные кинематические расчеты, чтобы получить совместные положения роботов и соответствовать желаемым позам. В зависимости от количества попыток найти динамически выполнимый и свободный от столкновений путь, а также от количества шарниров и отдельных совместных подразделений роботов, участвующих в команде, вычисление требует некоторого времени. Поэтому очевидно, что время цикла планирования повлияет на производительность команды роботов при выполнении сварочных работ посредством совместной работы. Подробное изучение этого воздействия является предметом раздела 7

ИТ-инфраструктура на базе ROS для планирования и управления движением

Основанные на ROS и MoveIt! сервисы [18], а также описанные ранее функции самоорганизации, были разработаны и внедрены в ИТ-инфраструктуры для обеспечения автономного планирования, а также независимого от платформы управления деятельностью робота, чтобы обеспечить надлежащее взаимодействие при выполнении предопределенных сварочных работ. На рисунке 7 представлена предлагаемая архитектура системы, где MoveIt! позиционируется в качестве ключевого модуля этой инфраструктуры. Более того, были разработаны и добавлены модули для самоорганизации и координации действий робота, для интерпретации предопределенных должностных инструкций, а также для взаимодействия среды ROS с внешними устройствами, чтобы обеспечить связь, взаимодействия и управления с реальными роботами, периферийными устройствами или даже с инструментом моделирования роботов, таким как Gazebo

Чтобы сэкономить время и избежать затрат на дополнительное оборудование и программное обеспечение для адаптации механизмов связи и взаимодействия с реальными физическими устройствами и требованиями безопасности, в рамках проекта приоритет был отдан имитационным исследованиям с использованием GAZEBO. Он обеспечивает эффективную среду моделирования для приложений ROS [19]

Рисунок 7 - ИТ-инфраструктура для автономного планирования, самоорганизации и управления взаимодействующими роботами при выполнении сварочных работ посредством командной работы

Взаимодействие между MoveIt и Gazebo

Для обеспечения любой совместимости между платформой планирования и управления на основе ROS на рис. 7 и GAZEBO, ROS, или любой инструмент моделирования требуют информации и сведений о моделях роботов, поворотного и наклонного стола, а также рабочей среды. Поэтому было использовано описание 3D-модели в ROS, основанное на файлах URDF (Unified Robot Description Format (унифицированный формат описания робота)). URDF --- это описание модели на основе XML. Спецификации, связанные с кинематической структурой, геометрическими размерами механических элементов, цветами, массой, моментами инерции или другими физическими свойствами, такими как трение, или даже ограничивающие объемы для проверки на столкновение, являются частью URDF

Для проектной работы два разнородных сварочных робота разного размера и кинематической структуры (ABB Irb 6640 и KUKA LBR IV), а также двухкоординатный поворотно-наклонный стол были выбраны и смоделированы с помощью файлов URDF устройства-ориентира, которые подходят для любого применения в MoveIt!, а также в Gazebo.

Визуализация и контроль симуляции

Однако для обеспечения визуализации двух роботов, а также поворотного и наклонного стола одновременно, необходимо было объединить отдельные файлы URDF каждого устройства путем группировки в один файл. Это потому, что MoveIt! и главный сервер ROS, на его текущем уровне разработки, может работать только с одним файлом URDF за раз.

Группировка отдельных файлов URDF роботов и таблицы поворота и наклона может быть достигнута с помощью «концепции макросов XML», поддерживаемой ROS. Файлы макросов указываются через атрибут $\mathrm{<}$xacro$\mathrm{>}$. Поэтому $\mathrm{<}$world.urdf.xacro$\mathrm{>}$ использовался в качестве группового узла для поддержки 3D-визуализации всех трех кинематических устройств только с одним файлом URDF. Кроме того, в зависимости от сварочной работы, выбранной для выполнения робототехническим комплексом, соответствующая модель заготовки также должна быть загружена в файл URDF и должна быть прикреплена к поворотно-наклонному столу, чтобы выполнить описание модели для MoveIt!

Для того, чтобы применять $\mathrm{<}$world.urdf.xacro$\mathrm{>}$ в Gazebo, необходимо было добавить некоторые дополнительные теги, относящиеся к Gazebo, например, с точки зрения цветов материалов, данных о столкновениях, инерционных блоков и параметров передачи (привязки исполнительных механизмов к соединениям).

После данного дополнения MoveIt! теперь может предоставить полный пакет конфигурации для визуализации любой активности и взаимодействия двух роботов и модели поворотного и наклонного стола. Это было достигнуто с помощью подключаемого модуля MoveIt! в «RViz» (визуализатор ROS) и симулятора Gazebo.

Тем не менее, полная интеграция ROS с Gazebo будет достигнута, если будет доступно управляемое моделирование взаимодействия роботов. Поэтому необходимо указать механизмы управления любой деятельностью роботов и моделей столов в Gazebo с помощью сообщений ROS, сервисов и динамической реконфигурации. Для этой цели был реализован узел интерфейса управления. Ключевым элементом этого интерфейса был плагин «ROS control», который обеспечивает общее управление с замкнутым контуром, обычно на основе ПИД-регулятора (рис. 8). Входными данными являются данные о совместном состоянии от датчиков исполнительных механизмов робота и путевые точки, сгенерированные планировщиками траекторий MoveIt!. В качестве выходных данных были выбраны ``данные о совместном местоположении''. Они используются в качестве обратной связи с ПИД-регулятором для управления любым движением каждого отдельного кинематического устройства в сценарии моделирования.

Рисунок 8 - Структура контроллеров ROS

Контроллеры ROS способны выполнять траектории в пространстве шарниров для их комплекса, к которым обращается каждый из роботов и позиционер. Для передачи целей траектории контроллерам необходимо было реализовать так называемый «узел совместного действия траектории» в качестве сервера действий. Сервер сообщает об успехе, если цели траектории выполнены, и позволяет определять конкретные допуски траектории и цели, такие как допустимые временные задержки при достижении целевого положения или ошибки позиционирования траектории, которые допустимы во время движения.

Для управления потоком данных между сервером действий и контроллером ROS с помощью модуля «controller manager» была разработана среда для запуска/остановки и загрузки/выгрузки контроллеров. Он способен управлять передачей данных в сторону Gazebo, а также может подключать MoveIt! к реальным физическим системам роботов, как показано на рисунках 8 и 9

Поскольку для каждого контроллера ROS требуется один сервер действий, в MoveIt необходимо было внедрить три узла сервера действий, конфигурируемого для управления потоком данных между следующими объектами:

• Траектория каждого сочленения ABB -$\mathrm{>}$ Контроллер ABB;
• Траектория каждого сочленения KUKA -$\mathrm{>}$ Контроллер LBR;
• Траектория сочленения Стола -$\mathrm{>}$ Контроллер стола по оси.

Таким образом, действие было передано соответствующим контроллерам роботов ABB и KUKA и поворотному столу, которые были выбраны в качестве демонстрационной и тестовой установки.

Рисунок 9 - Gazebo-ROS/Moveit структура контроллеров

Симуляция взаимодействия роботов

Для того, чтобы начать выполнение сварочных работ и смоделировать, как роботы будут взаимодействовать, самоорганизовываться, само координироваться и планировать траектории с помощью MoveIt!, инструмент $\mathrm{<}$roslaunch$\mathrm{>}$ был использован для запуска узлов ROS и установки параметров, имеющих значение для реализации конкретной функциональности. Загружаемый контент --- это, например, описание моделей роботов и модели поворотно-наклонного стола. Описания моделей были дополнены информации о физике, относящейся к заготовке, выбранной для сварки (деталь 1 или деталь 2).

При запуске системы по умолчанию все параметры, связанные с определением заготовки, отключены. Поэтому необходимо указать деталь, которая подлежит сварке. Это может быть достигнуто, например, путем:

roslaunch world_move_group world_organization.launch piece1:= true

Другие файлы запуска должны быть применены для загрузки XML-описания сварочной работы и блока моделирования Gazebo, включая модель заготовки (например: $\mathrm{<}$piece 2$\mathrm{>}$), как показано на рисунке 10

Рисунок 10 - Деталь 2, роботы и поворотный стол, смоделированные в Gazebo.

Дополнительные файлы запуска также необходимы для загрузки визуализации в RViz, контроллеров траекторий, серверов действий и robot_state_publisher. Как только все узлы, контроллеры, интерфейсы и параметры загружены, связи между ROS, MoveIt! и Gazebo достигнуты, и все узлы готовы к запуску приложения

Результаты прикладных испытаний в статической рабочей среде

Сценарии приложений, выбранные для проверки технической осуществимости и изучения эффективности нашего подхода, были в первую очередь ориентированы на сварочные работы в статической рабочей среде.

Чтобы начать с более низкого уровня сложности, было решено составить робототехнический комплекс с помощью двух аналогичных шестиосевых манипуляторов ABB. Они должны сотрудничать в выполнении определенных сварочных работ.

Геометрия заготовки должна сочетать в себе как линейные, так и круговые сварные швы. Поэтому настольная пластина модели позиционера была загружена $\mathrm{<}$piece 2$\mathrm{>}$ сначала, как показано на рисунке 10. 14 шарниров, которые должны быть сварены в рамках этого прикладного испытания, были расположены в неподвижной ориентации. Положение сварки было определено так, чтобы оно всегда было горизонтальным.

Согласно рисунку 10, позиции двух роботов были выбраны вплотную к позиционеру, напротив друг друга. Таким образом, роботы были вынуждены работать в перекрывающихся рабочих пространствах при выполнении сварочных работ взаимодействуя.

Как упоминалось в предыдущем разделе, M! всегда начинал с создания списка действий путем оценки описания задания XML. Затем он продолжил полностью автономно планировать и организовывать работу двух роботов, выбранных для теста, вызвав сначала узел самоорганизации. Результатом стали списки действий, подписанных на каждого из роботов. До этой подписки был проведен процесс оптимизации для достижения производственных целей путем распределения только тех серий сварочных работ для каждого из роботов, которые обеспечивали минимальное время выполнения.

Полученные последовательности действий, подписанные на двух роботов, предоставили входные данные для MoveIt! в планировании траекторий без столкновений и для создания путевых точек для движения виртуальных роботов в среде моделирования Gazebo. Процедуры планирования были выполнены в соответствии с технологиями, описанными в предыдущих разделах.

Все расчеты и планирование деятельности MoveIt! были выполнены в режиме реального времени, чтобы обеспечить быструю передачу данных о траектории к контроллерам ROS для управления движением роботов.

Для того, чтобы оправдать выполнение вычислительных и плановых усилий при самоорганизации и расчетах траекторий с учетом требований к управлению в режиме реального времени, а также для понимания механизма планирования, временных ограничений и ограничений MoveIt! пришлось с этим справляться, была проведена серия экспериментальных испытаний.

Поэтому статья продолжается обзором важных результатов, а также опытом и первыми выводами, полученными в результате различных прикладных тестов. В первую очередь основное внимание было уделено тестированию приложений в статической рабочей среде. Результаты представлены на рисунках 11 и 12.

Рисунок 11 - Время планирования траектории с помощью «RRT connect» для сварки детали 2 в горизонтальном положении с помощью двух роботов (по вертикали: время планирования в секундах по горизонтали: количество выполнений плана движения).

Рисунок 12 - Время планирования траектории с помощью «RRT connect» только для одного робота для сварки детали 2 в горизонтальном положении (по вертикали: время планирования в секундах по горизонтали: количество планов движения

На графике на рисунке 11 показаны различные вызовы планирования и время выполнения действий по планированию, выполняемых MoveIt! для выполнения сварки 15 шарниров, представленных $\mathrm{<}$piece 2$\mathrm{>}$. Данные основаны на индивидуальных планах для каждого робота с планировщиком «RRT connect».

Для обеспечения более быстрого планирования линейных сварных швов были дополнительно разделены на 130 отдельных сегментов пути длиной 0,015 м соответственно и на сегменты дуги 10${}^{\mathrm{\textrm{◦}}}$, в случае круговых сварных швов

Временная диаграмма показывает 184 цикла планирования для робота 1 и 108 циклов для робота 2. В общей сложности мы можем увидеть 292 действия по планированию пути, выполненные MoveIt! за время 83,744 с = 1,4 мин. Красная линия на диаграмме представляет собой программируемый лимит времени. Все плановые расчеты, выходящие за пределы 3-х секунд, MoveIt! не рассматривал. Они не будут участвовать в процессе планирования и автоматически начнут цикл по новой.

Из общего числа 292 циклов планирования необходимо рассмотреть 18 операций для расчета траекторий без столкновений для перемещения роботов по траекториям пересечения в режиме "точка-точка" (PTP), например, от одной сварочной линии к следующей. Учитывая, что для определения перемещения двух роботов вдоль линий сварки через интерполированные контрольные точки было использовано 130 вычислений, очевидно, что 144 операции могут быть проанализированы без какого-либо результата планирования. Они были прерваны из-за несоблюдения условий ограничения по времени.

Общее время планирования для робота 1 составило 32,745 с, в то время как планирование для робота 2 заняло 51,029 с. Причинами могут быть несбалансированная рабочая нагрузка в результате процессов самоорганизации и, возможно, более сложные обратные кинематические преобразования, связанные с роботом 2.

Тем не менее, время выполнения планирования, которое было измерено для двух роботов, указывает на то, что общая рабочая нагрузка была разделена и распределена между каждым из двух устройств в соответствии с пропорцией времени планирования. Таким образом, вследствие первых испытаний приложений можно утверждать, что совместная работа роботов значительно сократит общее время выполнения сварочных работ. Программирование было осуществлено в течение 1,4 минуты. Это очень быстро по сравнению со стандартным «обучающим» программированием. В случае двух роботов ABB (одного типа), выбранных для испытаний, можно наблюдать сокращение времени выполнения заданий почти на 50\% благодаря совместной работе. Это то, чего мы ожидали.

Однако, что можно сказать об работе по планированию, обеспечиваемой MoveIt! чтобы иметь возможность проверить эти усилия при организации и планировании работы двух роботов более подробно, та же самая сварочная работа была спланирована снова, но на этот раз сварка была выполнена только одним роботом. Результирующее количество и время выполнения циклов планирования представлены на рисунке 12

На рисунке 12 показано в общей сложности 217 циклов планирования различной продолжительности. Из этих 217 циклов 130 циклов рассматриваются для расчета траектории вдоль заранее определенных линий сварки с интерполированными путевыми точками. Четыре цикла планирования потребовались для расчета траекторий перемещения от одной линии сварного шва к другой и для возврата в исходное положение. Согласно этому расчету, 83 цикла планирования были прерваны из-за проблем с коллизиями и / или переполнения времени.

По сравнению со временем планирования действий двух роботов, теперь можно измерить суммарное время планирования всего в 7,365 секунды. Большинству циклов планирования требуется время около 0,02 с. Это 1/10 времени планирования MoveIt!, потраченного на планирование пути с комплексом из двух роботов.

Следовательно, с учетом этих результатов, возможно, было бы целесообразно сосредоточиться на параллелизме, если требуется самоорганизация и автономное планирование пути с помощью MoveIt! для приложений с несколькими роботами.

Чтобы проверить это предположение более подробно, тесты продолжились, но теперь с использованием более сложных сценариев приложения.

Результаты прикладных тестов в динамически изменяющихся рабочих средах

Чтобы проверить эффективность самоорганизации, самокоррекции и автономного сотрудничества на более высоких уровнях сложности, была проведена серия тестов в рамках нового сценария тестирования. Это показано на рисунке 13. Вместо двух роботов одного типа теперь используются два полностью разнородных сварочных робота (ABB, шестиосный и KUKA, семиосный) и управляемый наклонно-поворотный стол (двухосный). протестировать и доказать техническую осуществимость нашего подхода. $\mathrm{<}$piece 1$\mathrm{>}$ был выбран первым из-за его простой геометрии и линейных сварных швов углового типа.

Поскольку предполагалось, что сварка всегда должна выполняться в гравитационном положении во время прикладных испытаний с динамически изменяющимися условиями, поворотно-наклонный стол должен был быть ориентирован из положения загрузки (рис. 13б) в угловое положение стола 45$\mathrm{{}^\circ}$ (рис. 13a). Кроме того, требовалась постепенная переориентация заготовки во время выполнения работы, чтобы гарантировать, что линии сварки всегда располагались в гравитационном положении перед сваркой.

Рисунок 13 - Сварка $\mathrm{<}$piece 1$\mathrm{>}$ в постоянном гравитационном положении с помощью роботов ABB и KUKA. (а) положение сварки; (б) положение загрузки

Основываясь на списке действий, полученных из соответствующего описания работы XML, система снова начала полностью автономно планировать и координировать действия двух роботов и наклонно-поворотного стола. Это произошло в соответствии с алгоритмами и правилами самоорганизации, описанными в разделе 3.2.

Во время планирования список действий постоянно сокращался в зависимости от действий, которые уже были реализованы. Они были исключены из списка после выполнения.

Поскольку соединения, подлежащие сварке в $\mathrm{<}$piece 1$\mathrm{>}$, всегда представляют собой прямые линии в горизонтальном положении, декартов путь между WeldStart и WeldEnd в каждом сочленении планируется при помощи заданной траектории, интерполируемой отрезками по 10 мм. Полученная траектория получилась достаточно оптимальная по критерию наикратчайшего пути в декартовой системе координат.

Как было описано, задачей MoveIt! было спланировать траектории движения роботов и отслеживать столкновения либо между роботами и заготовкой, либо между самими роботами. В случае, если столкновение было предсказано MoveIt!. процесс планирования прерывался и начиналась новая попытка найти путь, свободный от столкновений. Поэтому, особенно в сложных сценариях приложений, применяемых для испытаний, процессы планирования могут занимать много времени и могут приводить к различным временным вычислениям. Это явление отражено на временной диаграмме процесса планирования, представленной на рисунке 14.

Рисунок 14 - Время циклов планирования с «BKPIECE» для сварки $\mathrm{<}$piece 1$\mathrm{>}$.

Планирование сварочной работы чтобы обеспечить взаимодействие двух роботов и стола наклона и поворота (всего 15 осей движения) заняло 43 цикла планирования MoveIt, как показано на рисунке 14. По сравнению с тестами приложений, описанными в разделе 7.1, с индивидуальным планированием движения, теперь процедуры планирования были выполнены с применением концепции группового узла URDF (см. Раздел 6) и использованием планировщика «BKPIECE». Порог в 15 секунд (красная линия) был определен для прерывания цикла планирования из-за превышения времени.

Согласно рисунку 14, среднее время планирования в общей сложности составило 395 с = 6,6 минуты. Девять циклов планирования были прерваны из-за превышения времени. В одном случае необходимо было вызвать отдельных планировщиков движения для робота ABB и робота KUKA (синие и оранжевые точки) из-за отсутствия результатов вычислений с концепцией группового узла. Напоследок, 15 секунд из общего времени планирования было потрачено на оптимизацию траектории.

Затем сложность была снова увеличена за счет выбора сценария приложения для сварки $\mathrm{<}$piece 2$\mathrm{>}$, который включал в себя состав линейных и круговых сварных швов. Как показано на рисунке 15, для планирования взаимодействия внутри комплекса роботов потребовалось 62 цикла планирования в разное время. Общее время планирования действий робота 1 (ABB), робота 2 (KUKA LBR) и трехосного поворотно-наклонного стола составило 398 секунд, т. е. 6,6 мин. Девять планов движения были прерваны. Потери времени, за счёт прерванных планов, составила 136 секунд. Для упрощения пути потребовалось 8 секунд.

Хотя концепция группового узла с $\mathrm{<}$world.urdf.xacro$\mathrm{>}$ и планировщиком пути BKPIECE применялись первоначально для планирования траектории, отдельные вызовы планировщика на основе «RRT connect» для решения проблем планирования часто определяются из-за прерванных вызовов с концепцией группового узла.

Планирование поворота и наклона стола появилось как отдельный планировщик из-за круговых сварных швов, которые требовали постоянного вращения стола, в то время как траектория кругового сварного шва должна была отслеживаться одним из роботов.

Рисунок 15 - Временная диаграмма планирования сварки $\mathrm{<}$piece 2$\mathrm{>}$

Оценка моделирования в реальном времени

Так как совместная работа, выполняемая робототехническим комплексом взаимодействуя с поворотно-наклонным столом, была визуализирована и рассчитана с помощью моделирования в реальном времени (рис. 16), иногда можно было признать, что планирование заняло слишком много времени для расчета обратной задачи кинематики для всей системы из 15 осей в заданном положении.

Рисунок 16 - Симуляция взаимодействия роботов

В данном случае операция планирования была разделена на каждого из роботов и рассчитывалась индивидуально. Данный результат привёл к последовательностям моделирования, в которых каждый робот рассчитывался индивидуально. Причина уже упоминалась и заключается в том, что главный сервер ROS (ROS Master Server) и MoveIt! может выполнять операцию планирования только с помощью одного URDF файла за раз.

В процессе моделирования вдобавок к визуализации, планировщик движений MoveIt! планировал продолжить следующий шаг робота в пространстве конфигурации. Для этой цели планирования MoveIt! предлагает анимацию в виде затенённого робота в движении перед его выполнением представленную на рисунке 17. Данная функция предлагает траекторию которую необходимо выполнить следующим шагов, в то время как реальная модель робота визуализируется в его фактическом положении.

Рисунок 17 - Планирование движения при помощи затенённой модели робота для детальной оценки процесса планирования.

Как только результаты планирования были рассчитаны и опубликованы с помощью MoveIt!, данные о траектории передаются в Gazebo, и смоделированные роботы перемещаются. Таким образом, если необходимо, качество результатов операции планирования может быть детально изучено.

Из-за разного времени выполнения цикла планирования траектории с использованием MoveIt!, а также за счёт различий в выполнении движений, на которые повлияла скорости связи и передачи между MoveIt! и симулятором Gazebo, измеряемое общее время выполнения сварочных работ в моделировании не применялось для прогнозирования любого времени выполнения, которое можно было бы ожидать в реальности.

Однако, Gazebo очень полезен для демонстрации технической осуществимости и применимости нашего подхода. Симулятор также представил мощные инструменты для изучения эффективности самоорганизации и автономного планирования в получении беспрепятственных и выполнимых траекторий для скоординированного и контролируемого выполнения задач сварочных работ при помощи взаимодействия комплекса промышленных роботов.

Применяя концепцию группового узла URDF при планировании траектории, одновременно можно управлять моделируемыми роботами и перемещать их. Однако, как только концепции группового узла не удаётся найти исполняемые траектории, в таком случае использовались индивидуальные планировщики движения. В таком случае быстрые решения достигаются, но только с помощью имитируемых движений робот за роботом.

Концепция интерфейса управления реальными роботами

Разработанная в данном проекте концепция планирования движения на основе MoveIt! позволила составлять траектории и путевые точки для управления движением моделей роботов не только в среде моделирования Gazebo, но и для управления реальными роботами, подключенными к среде планирования и управления ROS, представленной на рисунке 7. Для этой цели интерфейс контроллера должен включать в себя аппаратные модули: Ethernet в реальном времени и TCP/IP для поддержки связи, а также программное обеспечение, которое должно обеспечит преобразование выходных данных из MoveIt! в машинных код, специфичный для робота, а также данные обратной связи от роботов для перемещения.

Для связи с роботом KUKA LBR IV можно использовать пакет «KUKA Ethernet KRL XML». Он поддерживает обмен данными с помощью XML сообщений.

Для роботов ABB необходимо установить соответствующее оборудование для подключение к сети. Кроме того необходимо разработать специальный програмный передатчик и интегировать его в интерфейс контроллера MoveIt!. Данный передатчик преобразует данные путевых точек из MoveIt! в сообщения определённого синтаксиса для передачи на контроллер робота ABB. С помощью задачи «Чтение», предоставляемой контроллером ABB, строки длиной менее 80 символов декодируются для запуска определённых программ робота внутри контроллера ABB. Задача «Отправить» используется в контроллере ABB для отправки сообщений в пространство ROS. Таким образом можно обеспечить двунаправленную связь.

Однако подключение к реальным роботам, вместо моделируемых при помощи Gazebo, не предусматривалось в проекте и является темой для следующей работы.

Заключение

Предлагаемая концепция, основанная на ROS с интегированной самоорганизацией, автономным планированием траектории и возможностями моделирования открывает новые перспективы и преимущества в применении взаимодействующих мультироботных систем для автоматизации сварки. Даже если комплекса роботов состоят из совершенно разнородных машин, с помощью ROS можно продемонстрировать, что всего одного языка программирования достаточно для поддержки прямой связи и любого взаимодействия между ними. Это делает управление и автоматизацию взаимодействия легкой и быстрой для реализации.

В ходе работы над проектом стало очевидно, что ROS и программные функции на основе ROS, доступные в виде продуктов с открытым исходным кодом, могут предоставить разработчикам подходящую платформу для реализации мощных и интеллектуальных решений, способных работать с промышленными роботами и управлять ими в специальных сценариях приложений и передовых концепциях автоматизации.

Благодаря нашему подходу ввод данных для работы с приложениями с несколькими роботами может быть значительно сокращён. Вместо сложного программирования и синхронизации пользователь теперь более сосредоточен на описании производственной работы, которую должны выполнять роботы.

Результаты, достигнутые в результате обширных прикладных испытаний и исследований производительности, продемонстрировали техническую осуществимость нашего подхода в принципе.

Выбранные алгоритмы планирования траектории «RRT Connect» и «BKPIECE» способны производить быстрое планирование движения. Планирование движение для одного робота с «RRT Connect» выполняется за несколько секунд для всей сварочной работы, например, 14 сварных швов и 4 PTP перемещения. Это очень многообещающий результат, который должен стимулировать последующие исследования.

Можно заметить увеличение времени планирования, если количество роботов и дополнительных периферийных кинематических система, таких как многоосевые позиционеры заготовок, будут входить в состав комплекса роботов при учёте их взаимодействия. В частности, решение обратной задачи кинематики, а также проверки на столкновение увеличивают время планирования. Однако от нашего подхода следует ожидать довольно хороших результатов планирования и плавного управления, если приложения ограничены группами, состоящими только из двух или трёх роботов, соответственно, с кинематической цепью максимум в 15--18 степеней свободы.

В дополнении к индивидуальным планировщикам траектории для каждого робота балы внедрена и апробирована концепция группового узла со сгруппированными URDF файлами. Данный подход способствовал к уменьшению числа циклов планирования, но также способствовал увеличению времени вызова планировщика из-за более сложных проверок на столкновения и обратных кинематических расчётов. Вычисления с применением концепцией группового узла могут быть выполнены в пределах заданного времени, можно ожидать плавного и свободного от столкновений взаимодействия роботов, как представлено на рисунке 14. Однако при возрастающей сложности вычислений и усилий по планированию, концепция группового узла URDF теряет свою применимость из-за увеличения числа вызовов планировщика с превышением заданного времени. В данном случае стоит признать доминирование систем с индивидуальными планировщиками как представлено на рисунке 15.

Поэтому дальнейшая работа должна быть сосредоточена на технологическом совершенствовании и повышении применимости. Перспективным подходом, по-видимому, является выполнение параллельных действий по планированию, как только количество роботов или периферийных устройств увеличится до определенных пределов или за эти пределы. В таком случае рекомендуется работать с отдельными фреймворками ROS и планировщиками движения для каждого робота. Основанная на ROSTCP инфраструктура коммуникации обеспечивает бесперебойное взаимодействие внутри комплекса. Кроме того, полезной реализацией может быть выполнение предварительного расчёта для планирования движения и совместного контроля в качестве одного из инструментов для дальнейшего совершенствования.

С учетом целей и видения Индустрии 4.0, которые стимулировали наш проект, достигнутый на данный момент результат демонстрирует, как когнитивные функции и автономия могут открыть новые перспективы для разработки интеллектуальных машин и передовых концепций автоматизации. В этом контексте структуры ROS и ROS-Industrial могут предложить отличные инструменты, функции и программное обеспечение с открытым исходным кодом, особенно применимые для исследований и технологических разработок в области робототехники и приложений для роботов.

Технический подход к самоорганизации и автономному планированию траектории, разработанный для повышения применимости совместной деятельности роботов и взаимодействия в автоматизации сварки, также может способствовать достижению целей и видений в разработке интеллектуальных машин, которые помогут людям справиться с проблемами будущего.

Список литературы

1. IFR: Executive Summary World Robotics 2016 Industrial Robots. Available online:http://www.ifr.org/fileadmin/user_upload/downloads/World_Robotics/2016/Executive_Summary_WR_Industrial_Robots_2016.pdf (accessed on 24 November 2016).
2. Papakostas, N.; Michalos, G.; Makris, S.; Zouzias, D.; Chryssolouris, G. Industrial applications with cooperating robots for the flexible assembly. Int. J. Comput. Integr. Manuf. 2001, 24, 650--660. [CrossRef]
3. ABB: ABB MultiMove Functionality Heralds a New Era in Robot Applications. Available online: https://library.e.abb.com/public/734fb908d1c8ee50c12576dd005b69d0/ABB\%20MultiMove\%20functionality.pdf (accessed on 28 November 2016).
4. Hub Technologies. Available online: http://www.kuka-robotics.com/en/products/software/hub\_technologies/print/start.htm (accessed on 28 November 2016).
5. MOTOMAN XRC 201 Controller Independent-Coordinated Function. Available online:http://cdn2.hubspot.net/hubfs/366775/downloads/documentation/1429691.pdf?t=1468601845515 (accessed on 6 October 2016).
6. Parker, L.E. Current research in multi-robot systems. Artif. Life Robot. 2013, 7, 1. [CrossRef]
7. Lazinica, A. Recent Advances in Multi-Robot Systems; I-Tech Education and Publishing: Rijeka, Croatia, 2008.
8. Ravankar, A.; Ravankar, A.A.; Kobayashi, Y.; Emaru, T. SHP-Smooth Hypocycloidal Paths with Collision-Free and Decoupled Multi-Robot Path Planning. Int. J. Adv. Robot. Syst. 2016, 13, 1--21. [CrossRef]
9. Latombe, J.C. Robot Motion Planning; Springer: New York, NY, USA, 2012.
10. RoboCup. Available online: www.robocup.org (accessed on 28 November 2016).
11. Chen, X.; Stone, P.; Sucar, L.E.; Zant, T. RoboCup 2012: Robot Soccer World Cup XVI; Springer: Berlin/Heidelberg, Germany, 2013.
12. Yan, Z.; Jouandeau, N.; Cherif, A.A. A Survey and Analysis of Multi-Robot Coordination. Int. J. Adv. Robot. Syst. 2013, 10, 1--18. [CrossRef]
13. Multi-Robot Technology. Available online: http://www.motoman.co.uk/en/solutions/multi-robottechnology/ (accessed on 6 October 2016).
14. About ROS. Available online: http://www.ros.org/about-ros/ (accessed on 25 November 2016).
15. S, ucan, I.A.; Moll, M.; Kavraki, L.E. The Open Motion Planning Library. IEEE Robot. Autom Mag. 2012, 4, 72--82. [CrossRef]
16. Kuffner, J.; LaValle, S.M. RRT-connect: An efficient approach to single-query path planning. In Proceedings of 2000 IEEE International Conference on Robotics and Automation, San Francisco, CA, USA, 24--28 April 2000
17. Sucan, I.A.; Kavraki, L.E. Kinodynamic motion planning by interior-exterior cell exploration. In Algorithmic Foundation of Robotics VIII; Springer: Berlin/Heidelberg, Germany, 2009.
18. MoveIt! Setup Assistant Tutorial. Available online: http://docs.ros.org/hydro/api/moveit_setup_assistant/html/doc/tutorial.html (accessed on 4 October 2016).
19. Gazebo: ROS Control, Tutorial. Available online: http://gazebosim.org/tutorials/?tut=ros_control (accessed on 4 October 2016).