Разработка архитектуры управления роботами

Реферат

Для управления роботом была разработана модульная архитектура управления в реальном времени. Распространение коммуникационных шин, таких как полевые шины для заводских и машинных операций, обусловило необходимость единообразия и стандартизации. Несмотря на то, что Ethernet выделяется как наиболее вездесущий, его ресурс для реального времени делает его непригодным для связи на уровне устройства, где требуется постоянное время. Учитывая эту проблему, наши исследования налагают схемы управления трафиком для реализации эффекта реального времени. Разрешающая функция – это коммутируемый Ethernet с использованием UDP/IP. Каждая ось машины управляется микроконтроллером Java в реальном времени, и все контроллеры обмениваются данными через сеть связи Ethernet. Архитектура предназначена для поддержки реконфигурации как аппаратных, так и программных ресурсов с использованием схем модульности и сервис-обнаружения в программном и аппаратном обеспечении. Поэтому устройства, такие как ось и датчики, могут быть легко реорганизованы, удалены или добавлены. Основой объектно-ориентированного программного обеспечения являются коммуникационные и вычислительные архитектуры. Архитектура может быть сконфигурирована для работы в различных схемах групповой связи, то есть в клиентском или многоуровневом, в зависимости от требований задачи.

1. Введение

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

2. Обзор архитектуры управления

Архитектура управления роботом может включать несколько различных архитектурных стилей и структур. Основы вычислений и коммуникации отражают определенный стиль, в то время как архитектурная структура показывает, как система разбивается на подсистемы и как взаимодействуют эти подсистемы. Хорошо продуманная архитектура может иметь множество преимуществ в спецификации, исполнении и проверке системы управления роботом. Было сделано много попыток реализовать эффективные вычислительные архитектуры для ускорения с помощью различных видов многопроцессорных технологий [1–3]. Однако скорость вычислений не должна подрывать общую парадигму архитектуры (расширяемость, открытость, перенастройка и т. д.), а так же требования в реальном времени (детерминизм, синхронизация, целостность данных и т. д.). Обычно обсуждаемые архитектуры управления: централизованная, развязанная и иерархическая архитектуры [4–6]. Для систем с несколькими степенями свободы очень хорошо работает централизованное управление и легко компенсирует связь между управляемыми осями. Его производительность ухудшается по мере увеличения количества осей, поскольку алгоритмы управления становятся более сложными. Кроме того, его реконфигурация, как правило, невелика, поскольку любое изменение количества осей или алгоритма управления может привести к реорганизации его структуры. Напротив, развязанная архитектура имеет процессор блока управления для каждой оси, что позволяет снизить задержки связи и вычисления даже для большого количества осей. Импликация – это более высокие частоты дискретизации сервопривода, легкая реконфигурация и менее точная связь по оси [4]. Дизайнеры интеллектуальных архитектур, которые включают такие функции, как совещательное планирование, обычно предпочитают иерархические архитектуры, где каждый уровень иерархии используется для упрощения и абстрагирования проблемы для слоя выше. Это позволяет более высокоуровневым слоям последовательно изолироваться от реального оборудования и значительно упрощает проектирование системы для переносимости на другое оборудование. Каждая ось имеет свой локальный контроллер уровня управления сервоприводом только с локальным знанием состояния, а все оси контролируются более высоким уровнем с глобальным знанием состояния системы. Это обеспечивает хорошую координацию между осями. Для хорошо продуманной системы это качество дает преимущество перед развязанной архитектурой, и, кроме того, использование распределенной многопроцессорной структуры дает ей лучшую перенастройку, чем централизованная архитектура. В противоположность этому, задержка трафика является потенциальной проблемой в этой архитектуре, поскольку данные датчиков всегда должны перемещаться по сети.

3. Архитектурное устройство для параллельной кинематической машины

Мы используем механическую архитектуру параллельного кинематического манипулятора (ПКМ) для получения параллельных вычислительных алгоритмов. Этот ПКМ – специально разработанный робот с 3 степенями свободы [7], установленный на платформе с 2 степенями свободы. Модель вычисления представляет собой трехуровневую иерархию. Верхний уровень, который мы называем Frame-Constants, вычисляется только один раз для конкретной конфигурации для получения констант, таких как векторы направления и положения. Параметры, полученные из Frame-Constants, передаются во второй алгоритм Iteration-Parameters. Этот алгоритм получает входы от Frame-Constants и центральной точки рабочего органа, а так же генератора путей для генерации матрицы вращения 3 × 3, и вектора переноса, для движущейся платформы. Нижний уровень, Joint-Interpolation получает входы от Iteration-Parameters и вычисляет положение i-го звена шарнира в локальных координатах. Это контрольные точки, которые отправляются отдельным контроллерам. Эта схема, естественно, поддается распределенной архитектуре. У нас есть гибкость в создании различных архитектур, как описано ниже. Мы используем Java Micro-Edition (J2ME) для большинства наших разработок. Это урезанная версия стандартной версии Java и предназначена для встроенных систем.

A. Описание архитектуры управления

Иерархическая архитектура. В этой архитектуре, показанной на рисунке 1 ниже, все три вычислительных уровня расположены на одной платформе или процессоре, который становится главным контроллером, и каждому исполнительному механизму назначается узел интеллектуального контроллера. Концептуально каждый узел способен контролировать до двух приводов для отказоустойчивости. Во время настройки мастер-контроллер проверяет состояние и возможности каждого узла и обнаруживает идентификаторы для каждого узла. В сети могут быть другие узлы, такие как узлы мониторинга и серверы баз данных. Мастер-контроллер многоадресной передачи указывает на сеть в пакетах датаграмм с идентификаторами узлов. Каждый совместный контроллер получает отправленную информацию, но принимае только то, что соответствует его идентификатору. Таймеры интеллектуальных контроллеров синхронизируются во время настройки с настройками главного контроллера. Узлы контроллера периодически отправляют параметры траектории на главный узел. Эта архитектура освобождает вычислительные ресурсы во всех узлах контроллера для других целей и повышает скорость вычислений. Это также предпочтительная архитектура для управления серийными роботами. Однако задержки передачи данных могут вызывать ошибки времени ожидания. Для точных операций должны быть реализованы корректирующие алгоритмы для компенсации задержек колебаний в сети.

Полуиерархическая архитектура. В этой конфигурации (рис. 2) первые два вычислительных уровня (Frame-Constants и Iteration-Parameters) находятся в главном контроллере, тогда как алгоритмы Joint-Interpolation распределяются между совместными контроллерами, так что каждый совместный контроллер вычисляет только его совместные углы. Контроллеры передают данные о состоянии, такие как окончание траектории.

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

B. Архитектура связи

Каждый микроконтроллер в нашей системе подключается к плате ПИД-регулятора с помощью высокоскоростной шины с памятью для формирования единого составного интеллектуального узла контроллера. Контроллеры взаимодействуют через сетевую шину. Ethernet не подходит для сетей с жестким режимом реального времени, особенно когда он совместно используется многими узлами одновременно. Конфликты сообщений и последующие повторные передачи протокола CSMA/CD не являются детерминированными, поэтому не может быть гарантирована своевременность доставки сообщений. Комутирование Ethernet – это попытка реализовать связь в реальном времени. Коммутатор обеспечивает один домен конфликтов для каждого порта (гарантированная полная пропускная способность), тем самым устраняя столкновения, если порт является дюплексным и к нему подключен только один узел. Широко используемая архитектура коммутатора (коммутационная матрица) основана на сверхбыстрой одновременной множественной памяти доступа, разделяемой всеми портами. Последние коммутаторы Ethernet работают со скоростью передачи, т. е. все порты коммутатора могут одновременно передавать или принимать с полной скоростью передачи. Это требует, чтобы коммутационная матрица работала со скоростью передачи данных, равной совокупной скорости всех портов. Все узлы в нашей архитектуре контроллера подключены к маршрутизатору со встроенным коммутатором. Каждый узел может быть либо сервером, предоставляющим услуги, либо клиентом, запрашивающим услуги.

C. Конфигурация системы

Для того, чтобы реализовать наше видение гибкой, самонастраиваемой (PnP) – подобной связи наших контроллеров, необходим надежный и компактный протокол для управления нашим интерфейсом связи. Совершенно идеальный интерфейс подключения к контроллеру – это тот, который можно масштабировать или понижать без проблем – или перемещаться с одного конечного устройства на другое без необходимости настройки сетевых протоколов. Чтобы реализовать это, мы используем протокол Zero Config протокол. Этот протокол позволяет автоматически обнаруживать устройства и службы в IP-сетях, тем самым предоставляя карту для устройств, которые автоматически находят друг друга без внешнего вмешательства [8]. Реализация этого протокола в Java называется JmDNS [9]. Он был переработан для встроенной Java, поскольку наша платформа основана на Java КПОУ (Конфигурация подключенного ограниченного устройства). Протокол выполняется на сервлетах, чтобы включить веб-интерфейс пользователей для просмотра и настройки устройств. Веб-сервер каждого контроллера (Tynamo^TM [10]) содержит информацию о параметрах контроллера, таких как разрешение кодировщика, настройки ПИД и подключение устройства ввода/вывода. При запуске каждый сервер регистрирует Zero Config сервисы своего контроллера во всей сети. Такие службы регистрируются в следующем формате протокола: (тип услуги, имя службы, номер порта, описание). Имя службы может быть любым именем, уникальным для контроллера, если типы услуг объявляют, что это имя службы. Каждая служба имеет уникальный порт и может быть с кратким описанием самого себя. В таблице 1 показаны основные службы, зарегистрированные каждым контроллером. Веб-сервер также прослушивает типы услуг, требуемые контроллером для подключения к другим устройствам. Когда такие услуги принимаются и извлекаются параметрами сети, такие как IP-адрес и номер порта.

Таблица 1 – Регистрируемые службы

Наименование службы	Тип службы	Порт	Описание
Ось 1 Контроллер	_dserver._udp.local.	3000	Сервер датаграмм. Получает данные о трафике из сети
Ось 1 Контроллер	_controller._tcp.local.	2000	Установите соединение сокета с сигналами супервизора и потоком траектории потока и счетчиками энкодера для контроля оси
Ось 1 Контроллер	_http._tcp.local.	80	Веб-услуги
Многоадресная рассылка	_mcast._udp.local.	4000	Многоадресная услуга для приема синхронизирующих сигналов при координации многоосевых координат

Контроллеры ожидают большинство вышеупомянутых сервисов, а также супервизоры, то есть _supervisor._tcp.local. Узел супервизора регистрирует этот тип сервиса и ожидает все выше перечисленные службы. После того, как все необходимые услуги будут получены каждым узлом, будут установлены коммуникационные соединения. В зависимости от архитектуры, супервизор может отправлять заданные значения профиля траектории для заполнения буферов в каждом контроллере, периодически устанавливать точки потока или отправлять позиции точек инструмента контроллерам. На рисунке 4 показана диаграмма последовательности (события в зависимости от времени) многоадресного метода синхронизации движения. Многоадресный сокет становится общим ресурсом для узлов, которые присоединяются к группе многоадресной передачи. Супервизор загружает буфер каждого контроллера с его профилем траектории. Чтобы начать движение, супервизор одновременно выдает команду Пропустить профиль для всех контроллеров путем многоадресной передачи сигнала. Задержка, связанная с этим сигналом, к различным контроллерам не является детерминированной, но достаточно малой, чтобы быть пренебрежимо малой. Задержка составляет от 50 до 400 наносекунд. Поэтому разрешение синхронизации во многом зависит от тактовых дрейфов контроллеров. Алгоритм супервизора выдает команду запуска многоадресной рассылки, а в конце каждой траектории контроллеры сигнализируют супервизору и ждут, чтобы получить следующую синхронизированную команду запуска.

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

На рисунке 6 показан захват экрана некоторых пользовательских интерфейсов на наших контроллерах. GUI позволяет пользователям видеть зарегистрированные устройства и взаимодействовать или настраивать эти устройства онлайн с помощью веб-браузера.

D. Оборудование

Архитектура нашего контроллера – многоуровневая система с независимыми контроллерами для каждого соединения робота (см. рис. 7 ниже). Рабочая станция ПК используется как главный узел для синхронизации часов совместных контроллеров во время запуска, а также для загрузки программ. Он также служит станцией разработки и может играть активную роль в процессе управления в зависимости от выбранной архитектуры. Каждый совместный контроллер состоит из микроконтроллера JStik^TM, построенного на 32-битном встроенном микропроцессоре Java aJile устройстве aJ-100, который использует J2ME-систему Java на основе run-time. JStick оснащается статическим ОЗУ 2 МБ, программируемой флэш-памятью 4 МБ, последовательными портами Ethernet 10 Мбит/с и SPI. JVM-функция aJ100 позволяет выполнять до двух независимых приложений Java с детерминированным графиком с временным разделением и полной защитой памяти. В пределах своего ограниченного интервала выполнения и пространства памяти, каждая среда JVM может безопасно использовать собственные политики многопоточности и использования памяти [11]. JSticks отвечают за интеллектуальные операции на совместном уровне. Каждый из них связан с платой управления движением своей программируемой высокоскоростной шиной ввода/вывода (HSIO). Плата управления движением состоит из микросхемы контроллера движения, ПИД-регулятора LM628 [12] и 12-разрядного ЦАП. Каждый JStick отправляет параметры движения на свою плату контроллера и получает обновления движения и состояния через свой HSIO. LM628 имеет 8-битный интерфейс хоста и состоит из четырех основных функциональных блоков; генератор профиля траектории, компенсационный ПИД-фильтр, суммирующий переход и декодер положения двигателя. Интерфейс вывода запрограммирован для 12-разрядного ЦАП. Его максимальная частота дискретизации составляет 0,341 мс.

4. Результаты

Архитектура контроллера оценивается на основе времени выборки и синхронизации, точности позиционирования и архитектурной гибкости.

A. Выборка и синхронизация

Частота дискретизации сервопривода 1 мс достаточна для большинства контроллеров средней и высокой производительности. Так как в LM628 при дискретизация 0,341 мс колебания связи и задержки между супервизором является основным препятствием в достижении достаточно высокой частоты дискретизации между наблюдателем (в данном случае JSTick) и контроллером. Перед выполнением команд движения супервизор оценивает среднее время передачи для отправки и приема UDP-пакетов каждому контроллеру. Различия выравниваются с использованием периодических потоков send-datagram с периодами, соответствующими размеру корректировки. Для оценки задержек, временная разность между обновлениями траекторий на двух платах движения, была измерена с помощью логического анализатора. В одном случае задержки не учитывались (рис. 8), что приводило к максимальному перекосу в 1 мс. Компенсируя задержки (рис. 9), максимальный угол наклона был уменьшен до 0,1 мс. Это подходит для большинства средств контроля производительности.

B. Точность позиционирования

В этом подразделе обсуждаются характеристики позиционирования контроллеров на 3-осевой машине. Машина оснащена двигателями постоянного тока, напрямую подключенные к 5 мм винтам и 360 линейным однонаправленным квадратурным датчикам (360 × 4 отсчета/оборот). На рисунке 10 показаны измеренные траектории и заданные значения радиуса 5 мм (1440 отсчетов) со скоростью подачи 350 мм/с. Измеренные ошибки дуги (рис. 11) находятся в пределах 11 отсчетов, то есть 0,038 мм. Ошибка была вызвана главным образом сильным трением и низким качеством энкодеров.

C. Гибкость

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

5. Заключение

Описана архитектура и разработка архитектуры модульного контроллера реального времени для реконфигурируемых машин. Работа демонстрирует использование компонентов КПОУ для обеспечения экономической эффективности и легкой интеграции. Для переносимости используются микроконтроллеры на основе Java вместе с коммутируемым Ethernet. Архитектура позволяет устройствам обнаруживать себя и искать службы или транслировать свои службы с использованием стандарта Zero Conf. Архитектура также может быть изменена во время инициализации для оптимальной производительности в зависимости от решения главного контроллера. Это расширяет диапазон приложений для других устройств, таких как серийные роботы. Некоторые результаты испытаний показывают, что контроллер подходит для приложений средней и высокой производительности. Недостатком предлагаемых нами архитектур является неотъемлемая несинхронная природа Ethernet, которая, как правило, подрывает детерминизм. В будущих исследованиях будут представлены сети реального времени, такие как CAN и IEEE 1394.

Список использованной литературы

1. C. M. Gosselin: “Parallel Computational Algorithms for the Kinematics and Dynamics of Planar and Spatial Parallel Manipulators,” Trans. of the ASME: Journal of Dynamic Systems, Measurement, and Control , Vol. 118, No. 1, March, pp. 22-8, 1996.
2. H. Zhang & R. P. Paul: “A Parallel Inverse Kinematics Solution For Robot Manipulators Based On Multiprocessing and Linear Extrapolation,” IEEE Trans. on Robotics and Automation, Vol. 7, No. 5, Oct., pp. 660-69, 1991.
3. C. T. Lin, C. S G. Lee, “Fault-Tolerant Reconfigurable Architecture for Robot Kinematics and Dynamics Computations”, IEEE Transactions on Systems, Man and Cybernetics, Vol 21, No, 5. pp 983-99, Sept 1991.
4. T. J. Yook., K. Chervela., N. Soparkar., “Decentralized, Modular RealTime Control for Machining Applications,” in: 1998 American Control Conference, Philadelphia, PA, June 24-26, 1998, Proceedings. Vol. 2 (A9914618 02-63), IEEE, pp. 844-49, 1998.
5. O. Z. Maimon.; “Real-time Operational Control of Flexible Manufacturing Systems”, Journal of Manufacturing Systems; Vol. 6, No. 2; 1987; pp. 125 – 36.
6. K. Y. Shin; Park-Hong-Seong; Kwon-Wook-Hyun, “Architecture for a Network Based Robot Control System”, in IEEE-Symposium-on-EmergingTechnologies-and-Factory-Automation,-ETFA. v 2, Piscataway, NJ. p 875-80, 1999.
7. F. Xi, W. Han, W. Verner, A. Ross, “Development of a Sliding-Leg Tripod as an Add-On for Manufacturing”, Robotica, Vol. 19, Issue3, pp. 28594.
8. E Guttman, “Autoconfiguration for IP Networking: Enabling Local Communication,” IEEE Internet Computing, pp 81-6, June 2001.
9. JmDNS, http://jmdns.sourceforge.net, April 2005.
10. Tynamo, http://tynamo.qindesign.com, 2003-2005.
11. Systronix, Technical Reference for Systronix JStick, Realtime Java Network Module, Jul. 2003. http://jstik.systronix.com/Resource/jstik_techref.pdf.
12. National Semi-Conductor, LM628/LM629 Precision Motion Controller, Jan. 2003.