1.3 Моделирование рабочего пространства робота

Рассмотрим моделирование рабочего про­странства мобильного робота, функционирующего в составе гибкой производственной системы (ГПС).

Пусть существует рабочее пространство Р ро­бота Rb, которое обладает такими свойствами: гео­метрические размеры, объекты рабочей зоны, кли­матические условия, временные параметры P(D(x, y, z), Obj, Clm, T).

В рабочем пространстве существуют опреде­ленные объекты: станки (St), инструмент (Ins), оснастка (Osn), человек (Hum), робот (Rb):

Объекты также обладают определенным набо­ром свойств. Эти свойства обладают значениями и входят в множества имен и значений свойств.

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

Z_Rb обладает такими свойствами:

• диаметр объектива;

• фокусное расстояние;

• разрешающая способность;

• геометрические параметры наблюдае­мой зоны, ограниченные рабочим пространством:.

Между объектами (предметами) и их свойства­ми существуют отношения принадлежности, т.е. определенному объекту принадлежат свойства (объ­ект обладает свойствами).

Предметы взаимодействуют между собой от­ношениями принадлежности Pt(x), следования Rt₁ (x, y), совместимости Rt₂ (x, y), отношениями предопределения Rt₃ (x, y), отношениями ограни­чения Rt₄(x,y), отношениями совместности Rt₅ (x, y), отношениями ограничениями по доступу одних объектов пространства к другим Rt₆ (x, y).

Наличие отношений позволяет ввести опреде­ления:

1. Каждый объект рабочей зоны робота обладает хотя бы одном свойством

,

где - квантор общности,- квантор существо­вания,Obj - множество объектов рабочей зоны, S - множество свойств.

Множество Obj предметов пространства вклю­чает в себя следующие подмножества: St – станок роботизированного пространства, Ins - инструмент, Osn - оснастка, Hum - человек, Rb - робот. Таким образом, данное выражение можно записать в виде:

Множество S свойств предметов включает в себя такие параметры как: S_St - множество свойств станков; SI_ns - множество свойств инструментов; S_Osn - множество свойств оснастки; S_Hum - мно­жества свойств людей; S_Rb - множество свойств роботов. Отсюда следует, что

Из этих определений следует, что

2. Каждый предмет пространства свя­зан каким-либо отношением Rt с другим предметом:

Определение является истинным, так как каж­дый из предметов создан для взаимодействия с дру­гими предметами.

3. Все объекты рабочего про­странства являются упорядоченными по отношению к другим:

4. Для каждого предмета рабочей зоны найдется другой предмет, который совместен с первым в процессе работы:

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

5. Существуют такие предметы, которые предопределяют друг друга в технологиче­ском процессе.

Это отношение является частным случаем вы­ражения из определения 4, поэтому оно существует между теми же объектами.

6. Существуют одни и те же предметы.

^,

где Qt₂ - отношение равенства, используемое для сравнения значений свойств. Для каждого значения [s_i] свойства найдется равное ему. В символиче­ском виде это выражение можно записать так:

7. Для каждого числового значе­ния свойства (кроме максимального на конечном множестве значений N) можно найти значение больше рассматриваемого:

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

Если –конкретные свойства измене­ния маршрута робота, то описание переходов робо­та в рабочем пространстве будет таким:

Тогда из определения следует, что описание технологических операций будет таким, что свой­ства робота будут взаимодействовать со свойствами инструмента, оснастки, человека и станка:

.

Маршрут робота M будет состоять из операций Op и переходов Tr. Описание маршрута может быть представлено в следующем виде:

,

После определения рабочего пространства ро­бота и его составляющих (предметов, объектов и т.д.) необходимо выделить их, то есть идентифици­ровать и распознать каждый из объектов. Это необ­ходимо для ориентации робота относительно других предметов в рабочей зоне [6].

2 ОСНОВЫ ПРИМЕНЕНИЯ РОБОТОВ MICROSOFT ROBOTICS DEVELOPER STUDIO

2.1 Среда моделирования роботов Microsoft Robotics Developer Studio

Платформа Microsoft Robotics Developer Studio (MRDS) — это пакет разработчика для робототехники, ориентированный на программистов разных уровней. Визуальный язык программирования (VPL), входящий в состав MRDS. Симуляция виртуальных роботов позволит работать с техникой, которой еще нет, или выйти из положения, если использовать настоящего робота по каким-то причинам нельзя. На базе технологии CCR гораздо проще писать код, хорошо масштабируемый на несколько ядер. Сервисный подход в технологии DSS позволяет создавать слабо связанные распределенные приложения.

Microsoft Robotics Studio — это всего лишь фундамент для создания многофункционального робота.

В контексте робототехники приложение — это композиция слабосвязанных параллельно выполняющихся компонентов.

Все компоненты в Robotics Studio представляют собой независимо исполняемые сервисы и выступают как основополагающий элемент в MSRS. Иначе говоря, с точки зрения разработчика не существует физического мотора — есть сервис с интерфейсом, с помощью которого разработчик обращается к мотору через написанную им программу.

На концептуальном уровне сервис может быть представлен всем, от чего можно получать данные. Это, например, аппаратное обеспечение (сенсоры, приводы и т. п.), ПО (пользовательский интерфейс, хранилище данных), агрегация (группа сенсоров, mash-up).

Среда, в которой выполняется приложение в Microsoft Robotics Studio, носит название Runtime Environment. В основе Runtime лежит CLR 2.0, что дает возможность писать приложения, используя любые языки программирования платформы Microsoft .NET.

Сам по себе Runtime состоит из двух ключевых технологий: Concurrency & Coordination Runtime (CCR) — это библиотека для работы с параллельными и асинхронными потоками данных, и Decentralized System Services (DSS) — средство создания распределенных приложений на основе сервисов.

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

Для ответа на вопрос «зачем нужна CCR» вспомним определение понятия «приложение» в контексте Robotics Studio: это композиция слабосвязанных параллельно выполняющихся компонентов. Такой подход можно было бы реализовать с помощью существующих примитивов многопоточного программирования. Однако процесс написания многопоточных приложений — далеко не тривиальная задача, и она становится все сложнее по мере роста числа одновременно выполняемых потоков.

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

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

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

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

Разделение состояния и поведения — состояние сервиса (state) полностью открыто и при этом отделено от его поведения (behavior). Это очень важно в распределенной системе и позволяет сервисам легко взаимодействовать друг с другом как локально, так и удаленно по сети. Поведение в этой ситуации превращается в операции над состоянием, которые могут его изменять.

Работа с состоянием сервиса, а не с сессией (session-less) — текущее состояние сервиса определяется им самим, и оно идентично для всех, кто бы его ни запросил. Сервис не создает индивидуальных сессий для тех, кто с ним работает.

Работа со структурированными данными — состояние сервиса не может быть однородной массой, и структурирование на базе типов CLR позволяет работать со сложными структурами данных.

Работа с событиями изменения состояния сервиса — отделение состояния и его структурированность дают возможность сообщать об изменениях тем, кому это важно. В DSS есть модель, позволяющая отправлять и получать уведомления об этих событиях, а также подписываться на них.

Поддержка Web UI — анализировать и отлаживать распределенные приложения достаточно сложно. Структурированные данные в состоянии сервиса можно сериализовать с помощью XML и просматривать с помощью любого браузера. При помощи XSLT можно поверх XML данных создать простой пользовательский интерфейс.

Чтобы реализовать все описанные выше возможности, были частично использованы два существующих подхода к работе с сервисами: REST и Web Services.

REST (Representational State Transfer) — этот термин обозначает абстрагированную и формализованную Web-архитектуру и был предложен Роем Филдингом в 2000 г. REST построена на идее Тима Бернерс-Ли «URI ссылается на ресурс, и все взаимодействия с этим ресурсом происходят путем обмена состояниями». Важно отметить, что REST — это подход к созданию приложений; на текущий момент он успешно реализован в World Wide Web.

Про Web Services говорят уже давно и много. В основе Web-сервисов лежит протокол SOAP, который как раз и позволяет работать со структурированными данными и событиями.

Какой-то один из подходов, REST или Web-Services, не позволяет реализовать в платформе робототехники все задуманные возможности. Поэтому была выбрана унифицированная модель, в основу которой лег протокол Decentralized System Services Protocol (DSSP), в свою очередь базирующийся на SOAP. Реализация DSSP в Microsoft Robotics Studio предназначена специально для работы с сервисами [7].

2.2 Моделирование пространства и объектов рабочей области с помощью визуальной среды Visual Simulation Environment

Visual Simulation Environment включает в себя две программы: графиче­ский и физический движок.

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

Физический движок – производит симуляцию физических законов ре­ального мира в виртуальном мире с той или иной степенью точности.

Физический движок позволяет создать виртуальное пространство, в которое можно добавить виртуальные статические и динамические объ­екты и указать законы взаимодействия тел и среды. Расчет взаимодей­ствия тел выполняется самим движком. Рассчитывая взаимодействие тел между собой и средой, физический движок приближает физическую модель получаемой системы к реальной, передавая уточненные геометри­ческие данные графическому движку. В состав MRDS входит физический движок AGEIA PhysX Engine.

Объекты в симуляторе могут создавать иерархию, реализуя отноше­ние предок/потомок. Например, манипулятор и сенсор являются дочерни­ми объектами робота.

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

• W – движение вперед;

• S – движение назад;

• A – передвижение влево;

• D – передвижение вправо;

• Q – перемещение вверх;

• E – перемещение вниз.

Можно использовать сочетания этих клавиш. Удерживая нажатой клавишу Shift одновременно с одной из клавиш управления камерой, вы ускорите движение камеры в 10 раз.

Доступны следующие команды (клавиши) управления симулятором:

• F2 – изменяет режим рендеринга;

• F3 –включает/выключает физический движок;

• F5 –переключение между режимами Run и Edit;

• F8 – переключение активной камеры.

Симулятор может работать в следующих двух режимах.

• Edit - в данном режиме возможно изменение сцены, параметров объ­ектов, находящихся на сцене, добавление новых объектов в сцену;

• Run - в данном режиме запускается процесс симуляции;

• симулятор поддерживает следующие режимы отображения сцены;

• Visual - полностью отображаются все объекты сцены;

• WireFrame - отображаются только линии треугольников, из которых построены объекты сцены;

• Physics - отображаются фигуры, из которых построены объекты и с которыми работает физический движок. Сложные объекты иногда представляются в виде простых объектов, таких как кубы и сферы. Если некоторые объекты не сталкиваются или передвигаются случай­ным образом, нужно переключиться в указанный режим и проанали­зировать фигуры, составляющие объекты;

• Combined - объединяет режимы Visual и Physics (рис. 2.1).

Рисунок 2.1 - Режим Combined

Параллелепипед, размещенный внутри объекта, показывает центр масс. Если цвет параллелепипеда красный, то объект управляется вручную (т. е. является кинематическим), если - белый, то объект управляется физиче­ским симулятором.

Настройки графического движка открываются после выбора пункта глав­ного меню Render -> Graphics Settings. Рассмотрим параметры движка.

• Exposure - определяет значение экспозиции камеры. Увеличение зна­чения экспозиции приводит к увеличению яркости сцены;

• Anti-aliasing - устанавливает значение сглаживания границ объектов;

• Rotation and Translation Movement Scale - используется для управле­ния чувствительностью мыши и клавиатуры. С помощью указанных параметров можно настроить управление камерой мышью и клавиа­турой так, что движение мыши в несколько миллиметров будет при­водить к перемещению вдоль всего экрана;

• Quality level - выбор используемой версии шейдеров. Версия, которая поддерживается графической картой, отмечена как Recommend.

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

Настройки физического движка открываются после выбора пункта глав­ного меню PhysicsSettings. Рассмотрим параметры движка:

• Enable rigid body for default camera - позволяет связать с камерой фи­зическое тело, имеющее форму сферы. В результате камера сможет взаимодействовать с объектами сцены (например, сталкиваться с ними). После установки данной опции камера будет отображаться в виде белого круга в центре экрана;

• Gravity - значение гравитации, действующей в симуляторе; опреде­ляется как сила, действующая вдоль оси Y. Данное значение является отрицательным, так как ось Y направлена в направлении, противо­положном действия гравитации. Значение гравитации указывается в метрах в секунду;

• Time Base Run-time Settings - определяет отношение времени симуля­тора к реальному времени. Для повышения точности при перемеще­нии робота необходимо уменьшить отношение времени симулятора к реальному времени. Для замедления времени в 10 раз в поле Real time Scale нужно установить значение 0.1;

Можно повысить точность симуляции, отведя на фрейм небольшой интервал времени, допустим, 60 микросекунд (0.00006) и отключив визуа­лизацию. Рендеринг можно запускать периодически для просмотра сцены. Виртуальный мир может включать следующие объекты:

• динамические - находятся под контролем физического движка, после их создания их позиция и движение определяются только гравитаци­ей и взаимодействием с другими объектами;

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

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

Сцена, находящаяся в симуляторе, может быть сохранена в XML-файл и затем загружена. При загрузке сцены все объекты получают то же место­положение и скорость, которые они имели при сохранении сцены. Для со­хранения сцены используется пункт меню File ^ Save Scene, для загрузки - File ^ Load Scene.

При сохранении сцены записываются два файла: первый содержит со­стояние сцены и имеет расширение .xml, второй содержит манифест для сцены и заканчивается на .manifest.xml.

Редактор симулятора открывается при выборе пункта Mode ^ Edit главно­го меню окна. После запуска редактора окно будет содержать отображение сцены, список объектов сцены и свойства выделенного объекта (рис. 2.2)

Рисунок 2.2 - Симулятор в режиме Edit

Объект можно отметить на сцене, если выделить его в списке объектов и нажать клавишу Ctrl. Если после выполнения данной операции камера не показывает объект, то можно использовать сочетания клавиш Ctrl, Shift и клавиш управления курсором для просмотра различных видов объекта:

• Ctrl + клавиша вверх: вид сверху;

• Ctrl + Shift + клавиша вверх: вид снизу;

• Ctrl + клавиша влево: вид справа;

• Ctrl + Shift + клавиша влево: вид слева;

• Ctrl + клавиша вправо: вид спереди;

• Ctrl + Shift + клавиша вправо: вид сзади.

Для перемещения выбранного объекта по сцене нужно выбрать на­правление движения в меню редактирования свойств (Move XYZ, Move XZ, Move X, Move Y, Move Z) и при нажатой левой кнопке мыши переме­стить курсор в нужном направлении. Также возможно указать точные ко­ординаты расположения объекта в том же меню. Подобным образом вы­полняется вращение объекта вдоль каждой из осей (рис. 2.3).

Рисунок 2.3 – Меню управления объектом

Редактор предоставляет возможность загрузки, сохранения и добав­ления новых объектов. К объектам также можно применять операции вставки, копирования и удаления.

Физический движок корректирует перекрытие динамических объек­тов (в реальном мире невозможное). Добавьте в сцену несколько объектов с одинаковыми координатами и нажмите клавишу F3. В результате объек­ты будут размещены по свободному пространству сцены без перекрытия.

При вставке объекта в сцену можно указать предка для данного объ­екта, которым может быть один из объектов сцены. В результате симуля­тор будет рассматривать эти два объекта как единое целое.

Объект может обладать такими свойствами:

• Position, Rotation – определяют позицию и угол наклона объекта к каждой из осей координат;

• MeshScale/MeshTranslation/MeshRotation – позволяют упростить под­гонку формы (сетки) объекта к самому объекту. Это связано с тем, что разные средства создания трехмерных объектов могут использовать разные направления осей и масштаб;

• Meshes – отображает информацию о сетках, загруженных для объекта. Сетка может быть создана из фигур, которые составляют объект, или загружена из .obj-файла. Также данное свойство позволяет изменять цвет, яркость и другие параметры объекта. Если были изменены па­раметры материала, их можно сохранить, используя пункт меню File -> Save Material Changes.

Свойства, определяющие освещенность объекта:

• Ambient – определяет, как объект отражает свет, поступающий из окружающей среды, т. е. свет, отраженный от поверхности других объектов;

• Diffuse – определяет, как свет будет отражаться от объекта, если он будет освещен рассеянным светом. Данная величина определя­ет максимальное значение света, которое будет отражено частью объекта, повернутой к источнику света. Если некоторая часть объекта размещена перпендикулярно источнику света, то она ни­чего отражать не будет. Диффузный свет позволяет видеть объ­екты трехмерными;

• Specular – определяет, как много света будет отражаться от объек­та при его освещении отраженным светом, обычно используемым для создания эффекта освещения солнцем. Цвет отраженного света эквивалентен цвету света, а цвет диффузного света – цвету объекта;

• Power – определяет плотность отраженного пятна, большее значе­ние параметра соответствует меньшему отражению.

Каждый объект имеет состояние, представляющее собой набор пара­метров:

1. Graphics Assets:

• Default Texture – если с объектом не связана сетка, определяющая ее форму, то она генерируется из физических фигур, составляю­щих объект. В этом случае указанное свойство определяет тек­стуру, которая накладывается на сгенерированную сетку. Тексту­ра должна быть двумерной и находиться в одном из следующих форматов: .dds, .bmp, .png, .jpg, .tif;

• Mesh – файл, определяющий форму объекта. Формат файла - .obj или .bos. Симулятор для ускорения работы преобразует формат .obj в формат .bos и только после этого отображает объект. Для этого используется утилита Obj2Bos.exe.

2. Misc:

• Flags – определяет поведение объекта. Если флаги не определены, предполагается, что объект – динамический;

• Kinematic – кинематический объект;

• IgnoreGravity – на объект не имеет влияние гравитация;

• DisableRotationX, DisableRotationY, DisableRotationZ – за­прещает вращение объекта вдоль указанных осей;

• DisableCollisions – объект не взаимодействует с другими объектами сцены;

• Name – имя объекта (должно быть уникальным). При изменении имени некоторые сервисы не смогут работать с данным объек­том.

3. Motion:

• Angular Velocity – вектор угловой скорость перемещения объекта в каждом из направлений;

• Velocity – вектор скорости перемещения объекта в каждом из на­правлений.

4. Physical Properties:

• Mass/Density – масса и плотность объекта. Если хотя бы одна из фигур объекта имеет массу и плотность, то вычисляется масса и плотность всего объекта из суммы масс фигур, составляющих объект. Если сумма масс фигур равна нулю, симулятор исполь­зует величину Mass для определения массы объекта. Центр масс вычисляется так, как если бы плотность объекта была однород­ной. Указанные замечания также касаются и плотности объекта;

• Inertia Tensor – тензор моментов инерции, определяет насколько сложно повернуть фигуру в различных направлениях. Например, цилиндр просто повернуть около его продольной оси, но слож­но повернуть около двух других осей, вследствие распределения масс. Если вектор не определен, симулятор вычисляет его на основе расположения и относительной массы фигуры объекта;

• Angular Damping/Liner Damping – данные параметры позволяют моделировать свойство трения. Большие значения данных пара­метров соответствуют более быстрому затуханию угловой или линейной скорости. При нулевом значении объект будет двигать­ся бесконечно до тех пор, пока не столкнется с другим объектом.

2.3 Управление роботом

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

В MRDS программный доступ к дифференциальному приводу робо­та реализован в виде сервиса GenericDifferentialDrive. По умолчанию дан­ный сервис не связан с определенным приводом. Для соединения сервиса с приводом используется специальный файл, называемый манифестом. Одно из преимуществ MRDS заключается в том, что, разработав програм­му управления определенным роботом, можно использовать ее для управ­ления другими роботами. Для этого достаточно будет изменить манифест, связывающий сервис и робота.

Рассмотрим действия сервиса GenericDifferentialDrive:

• AllStop - останавливает движение, прекращает все операции, выпол­няемые приводом, устанавливает величину подаваемой энергии на оба двигателя в 0 и выключает двигатели. Для повторного запуска ро­бота необходимо вызвать метод EnableDrive, установив Enable в true;

• EnableDrive используется для разрешения или запрещения движения робота. Данное действие имеет один параметр логического типа. Если значение параметра - false, то запросы на управление движением вы­полняться не будут. Если привод выключается во время движения, он должен немедленно остановиться независимо от типа выполняемой операции;

• SetDrivePower устанавливает количество энергии, которое по­дается на правое (параметр RightWheelPower) и левое (параметр LeftWheelPower) колеса. Количество энергии может изменяться от -1.0 до 1.0 (тип double). Отрицательная величина указывает на то, что ко­леса должны вращаться назад, положительная - вперед. Каждый но­вый вызов действия изменяет значение энергии, поданной на колеса.

Возможны следующие варианты движения робота:

• движение вперед: LeftWheelPower > 0, RightWheelPower > 0, Left -WheelPower = RightWheelPower;

• движение назад: LeftWheelPower < 0, RightWheelPower < 0, Left- WheelPower = RightWheelPower;

• движение по дуге: LeftWheelPower Ф RightWheelPower (если на одно колесо робота подать большее количество энергии, чем на другое, то колесо, на которое подано больше энергии продвинется вперед дальше, чем колесо, на которое подано меньшее значение, в результате робот будет двигаться по дуге);

• вращение на месте: LeftWheelPower = -RightWheelPower. Установка значений энергии, подаваемой на оба колеса, в нулевое зна­чение приводит к остановке робота. Для остановки роботу может по­надобиться время. Между значением энергии, подаваемой на колеса, и скоростью робо­та нет прямой зависимости. Однако при больших значениях энергии колеса крутятся с большей скоростью. В ряде случаев робот может до­стигать своей максимальной скорости при значении энергии меньше 1.0, а при малых значениях энергии (например, 0.1) может не тронуть­ся с места. Некоторые роботы поддерживают только дискретный на­бор уровней мощности, в ряде случаев возможно наличие лишь двух состояний двигателя – включено и выключено;

• SetDriveSpeed – устанавливает скорость движения робота в метрах в секунду;

• DriveDistance – устанавливает расстояние, на которое должен переме­ститься робот (в метрах).

Параметры действия:

• Distance – расстояние в метрах, на которое должен переместиться робот (тип double);

• Power – количество энергии, подаваемое на колеса (см. действие SetDrivePower);

• параметр DriveDistanceStage при вызове действия DriveDistance должен быть установлен в DriveStage.InitialRequest. Данный пара­метр используется для отображения процесса выполнения опера­ции. Любой запрос на движение (включая DriveDistance) отменяет DriveDistance [3]. Однако некоторые роботы не могут прервать начатое дви­жжение;

• RotateDegrees – используется для поворота робота на месте на указан­ный угол (в градусах). Положительный угол означает движение влево или против часовой стрелки относительно центра робота, если смо­треть сверху.

Параметры действия:

• Degrees – угол, на который выполняется поворот;

• Power – количество энергии, подаваемой на оба колеса;

• параметр RotateDegreesStage должен быть установлен в DriveStage. InitialRequest.

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

Связать сервис GenericDifferentialDrive с приводом робота (моделью робота в симуляторе) можно следующим образом:

• Выбрать сервис GenericDifferentialDrive на диаграмме.

• Выбрать в окне Properties в поле Configuration пункт Use a manifest.

Нажать кнопку Import и выбрать в открывшемся окне пункт IRobot.Create.Simulation.Manifest.xml (рис. 2.4). Выбранный манифест определяет робота, который будет добавлен в симулятор. После выполнения указанных действий окно Properties должно выгля­деть, как показано на рисунке 2.5 [8].

Рисунок 2.4 – Список манифестов

Рисунок 2.5 – Установка параметров сервиса