«Создание собственного виртуального робота и программы управления им в rds»

Вид материалаПояснительная записка

Содержание


Задание к курсовому проектированию
1.1 Concurrency & Coordination Runtime
1.2 Decentralized System Services
Создание 3D модели робота
Рисунок . Создание модели робота в 3D редакторе Blender
Создание робота в RDS
Сервис для робота
Рисунок . Создание нового сервиса из шаблона
Заполнение сцены моделирования
Создание класса робота
Chassis_clearance + chassis_dimensions.y / 2
Создание манифеста
Рисунок . Запуск службы DSS
Рисунок . Simple Dashboard
Рисунок . Робот Boe-Bot в движение.
Подобный материал:
ФГОАУ ВПО «Уральский федеральный университет имени первого Президента России Б.Н. Ельцина»

Институт образовательных информационных технологий

Факультет дистанционного образования

Кафедра Информационных систем и технологий


Оценка работы____________

Члены комиссии___________


ПОЯСНИТЕЛЬНАЯ ЗАПИСКА К КУРСОВОЙ РАБОТЕ


Дисциплина «Системы контроля и управления»

Тема «Создание собственного виртуального робота и программы управления им в RDS»


Преподаватель Ждахин И.Л.

Студент гр. ИТЗ-47011д Леонтьев А.С.

Номер зачётной книжки 18710917


Екатеринбург

2011

Оглавление


Введение 3

Задание к курсовому проектированию 4

1.Приложение для робота — что это такое? 5

1.1 Concurrency & Coordination Runtime 5

1.2 Decentralized System Services 7

1.3 Сервисы 8

2.Создание 3D модели робота 9

3.Создание робота в RDS 12

3.1Сервис для робота 12

3.2Заполнение сцены моделирования 14

3.3Создание класса робота 17

3.4Создание манифеста 19

3.5Поехали! 23

Заключение 26

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




Введение 3

Задание к курсовому проектированию 4

1.Приложение для робота — что это такое? 5

1.1 Concurrency & Coordination Runtime 5

1.2 Decentralized System Services 7

1.3 Сервисы 8

2.Создание 3D модели робота 9

3.Создание робота в RDS 12

3.1Сервис для робота 12

3.2Заполнение сцены моделирования 14

3.3Создание класса робота 17

3.4Создание манифеста 19

3.5Поехали! 23

Заключение 26

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







Введение



Microsoft® Robotics Studio (MSRS) — это нечто большее, чем просто способ поиграть с роботами. Набор MSRS, позволяет создавать приложения для широкого спектра устройств на основе служб. Этот набор содержит среду выполнения, которая хорошо известна разработчикам Windows®Communication Framework (WCF). Кроме того, он содержит средство языка визуального программирования Visual Programming Language (VPL) и среду визуализации Visual Simulation Environment (VSE).

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

Задание к курсовому проектированию


Создать собственного виртуального робота и программы управления им в пакете RDS.
  1. Приложение для робота — что это такое?


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

Все компоненты в 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) — средство создания распределенных приложений на основе сервисов. Остановимся подробнее на этих технологиях.

1.1 Concurrency & Coordination Runtime


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

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

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

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

1.2 Decentralized System Services


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

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

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

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

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

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

1.3 Сервисы


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

Структурированное состояние — некая структура, которая описывает состояние сервиса.

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

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

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

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

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

  1. Создание 3D модели робота


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

Для создания 3D модели робота можно воспользоваться практически любым трехмерным редактором. Для создания модели робота Boe-Bot используем программу трехмерной графики, называемой Blender. Программа позволяет экспортировать изображения в формате obj.

Модель робота была создана последовательным соединением прямоугольников и их последующей модификацией. Например, металлическое шасси было вначале кубом, который был изменен в соответствии с формой и размерами Boe-Bot. Для отображения колес были добавлены цилиндрические объекты. Были установлены иерархические связи, чтобы связать колеса с шасси и дать возможность всему объекту работать как единое целое (рис.1).




Рисунок . Создание модели робота в 3D редакторе Blender


MSRS имеет в своем составе программу командной строки, которая может преобразовывать файлы obj в оптимизированные двоичные файлы с расширением bos. Достоинством данного типа файлов заключается в том, что он загружается гораздо быстрей, чем файл obj. Программа командной строки, называемая Obj2bos.exe, может вызываться с помощью пункта меню "командная строка" в программе MSRS.

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

Файл obj и все связанные с ним файлы должны располагаться в папке /store/media, относящейся к установленной программе MSRS. Файлы, ассоциированные с сеткой Boe-Bot, которые загружаются вместе с примером программы, следующие: Aluminum.png, Boe-bot.mtl, Boe-bot.obj, BoebotWheel.png и Pcb.png. Поместив файлы в указанную папку, откройте командную строку с помощью программы MSRS и напечатайте:

Obj2bos.exe /i:"store\media\Boe-bot.obj"

Программа конвертирования создаст файл с именем Boe-bot.bos, который будет находиться в упомянутой папке.


  1. Создание робота в RDS


Все взаимодействие Robotics Studio построено на основе сервисов, потому после создания 3D модели робота, необходимо создать сервисы, описывающие его поведение.
    1. Сервис для робота


В Visual Studio 2008 выбрать Файл->Создать->Проект и выбрать из списка шаблон для создания DSS Service(2.2).



Рисунок . Создание нового сервиса из шаблона


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

  • Таблица 1. 

Имя сборки

Описание

PhysicsEngine

Предоставляет доступ к программе моделирования физических взаимодействий AGEIA.

RoboticsCommon

Предоставляет доступ к пространству имен PhysicalModel, которое используется для задания физических параметров роботов.

SimulationCommon

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

SimulationEngine

Предоставляет доступ к обработчику модели.

SimulationEngine.proxy

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


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

using Microsoft.Robotics.Simulation;

using Microsoft.Robotics.Simulation.Engine;

using engineproxy = Microsoft.Robotics.Simulation.Engine.Proxy;

using Microsoft.Robotics.Simulation.Physics;

using Microsoft.Robotics.PhysicalModel;


Первое, о чем нужно упомянуть, — это метод Start, который вызывается автоматически при запуске службы:

protected override void Start()

{

base.Start();

// Orient sim camera view point

SetupCamera();

// Add objects (entities) in our simulated world

PopulateWorld();

}

Метод Start — это то место, где вы добавляете код, описывающий среду вашей модели. Он включает в себя задание камеры и заполнение сцены модели объектами.

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

    1. Заполнение сцены моделирования


Одной из основных задач любой службы модели является размещение объектов в сцене моделирования. Это действие должно выполняться при запуске службы, поэтому обычно метод с названием PopulateWorld добавляется к методу Start. Для моделирования Boe-Bot метод PopulateWorld будет выглядеть так:

private void PopulateWorld()

{

AddSky();

AddGround();

AddBoeBot(new Vector3(1, 0, 1));

AddBox(new Vector3(2, 1, 1));

}

Методы AddSky и AddGround используются для задания окружающей среды, в которую BoeBot будет помещен. Для метода AddSky создается и добавляется к модели новый тип SkyDomeEntity. Направленный свет, который подразумевает солнечный свет, также вставляется в модель.

void AddSky() {

// Add a sky using a static texture. We will use the sky texture

// to do per pixel lighting on each simulation visual entity

SkyDomeEntity sky = new SkyDomeEntity("skydome.dds",

"sky_diff.dds");

SimulationEngine.GlobalInstancePort.Insert(sky);


// Add a directional light to simulate the sun.

LightSourceEntity sun = new LightSourceEntity();

sun.State.Name = "Sun";

sun.Type = LightSourceEntityType.Directional;

sun.Color = new Vector4(0.8f, 0.8f, 0.8f, 1);

sun.Direction = new Vector3(0.5f, -.75f, 0.5f);

SimulationEngine.GlobalInstancePort.Insert(sun);

}

Метод AddGround реализует тип HeightFieldEntity, создающий обширную горизонтальную плоскость нулевого уровня. Рисунок текстуры, поставляемый в составе пакета MSRS, используется для отображения земли. Код данного метода показан ниже:

void AddGround()

{

// create a large horizontal plane, at zero elevation.

HeightFieldEntity ground = new HeightFieldEntity(

"simple ground", // name

"03RamieSc.dds", // texture image

new MaterialProperties("ground",

0.2f, // restitution

0.5f, // dynamic friction

0.5f) // static friction

);

SimulationEngine.GlobalInstancePort.Insert(ground);

}

Следующим необходимо добавить объект Boe-Bot. Метод AddBoeBot принимает входной параметр Vector3, который используется для отображения местоположения робота. Это положение передается конструктору объекта BoeBot. Метод AddBoeBot также запускает в качестве объекта-партнера службу движения модели Boe-Bot. Код этого метода показан здесь:

void AddBoeBot(Vector3 pos)

{

BoeBot boeBot = new BoeBot(pos);

boeBot.State.Name = "SimulatedBoeBot";


// Start simulated Boe-Bot Drive service

CreateService(

drive.Contract.Identifier,

Microsoft.Robotics.Simulation.Partners.CreateEntityPartner(

"/" + boeBot.State.Name));


SimulationEngine.GlobalInstancePort.Insert(boeBot);

}

Последний объект, который нужно добавить, это ящик, который используется в качестве препятствия. Метод AddBox создает объект, имеющий форму коробки, используя тип SingleShapeEntity. Код данного метода показан ниже:


void AddBox(Vector3 position)

{

Vector3 dimensions =

new Vector3(0.2f, 0.2f, 0.2f); // meters


// create simple movable entity, with a single shape

SingleShapeEntity box = new SingleShapeEntity(

new BoxShape(

new BoxShapeProperties(

100, // mass in kilograms.

new Pose(), // relative pose

dimensions)), // dimensions

position);


box.State.MassDensity.Mass = 0;

box.State.MassDensity.Density = 0;


// Name the entity. All entities must have unique names

box.State.Name = "box";


// Insert entity in simulation.

SimulationEngine.GlobalInstancePort.Insert(box);

}

    1. Создание класса робота


Чтобы создать новый тип объектов для робота Boe-Bot, нужно добавить класс, который является производным класса DifferentialDriveEntity. Для получения производного класса от DifferentialDriveEntity можно использовать программу, которая описывает поведение робота Boe-Bot при движении в моделируемой среде. Программа, использованная для создания типа объектов для BoeBot, показана ниже:


[DataContract]

public class BoeBot : DifferentialDriveEntity

{

Port _notifications =

new Port();


// Default constructor, used for creating the entity from XML

public BoeBot() { }


// Custom constructor for building model from hardcoded values.

// Used to create entity programmatically

public BoeBot(Vector3 initialPos)

{

MASS = 0.454f; //in kilograms (around 1 pound)

// the default settings approximate the BoeBot chassis

CHASSIS_DIMENSIONS = new Vector3(0.09f, //meters wide

0.09f, //meters high

0.13f); //meters long

FRONT_WHEEL_MASS = 0.01f;

CHASSIS_CLEARANCE = 0.015f;

FRONT_WHEEL_RADIUS = 0.025f;

CASTER_WHEEL_RADIUS = 0.0125f;

FRONT_WHEEL_WIDTH = 0.01f;

CASTER_WHEEL_WIDTH = 0.008f;

FRONT_AXLE_DEPTH_OFFSET = 0.01f; // distance from center of robot


base.State.Name = "BoeBot";

base.State.MassDensity.Mass = MASS;

base.State.Pose.Position = initialPos;


// chassis position

BoxShapeProperties motorBaseDesc =

new BoxShapeProperties("BoeBot Body", MASS,

new Pose(new Vector3(

0, // Use 0 for X axis offset

CHASSIS_CLEARANCE + CHASSIS_DIMENSIONS.Y / 2,

0.03f)), // minor offset in the z/depth axis

CHASSIS_DIMENSIONS);


motorBaseDesc.Material =

new MaterialProperties("high friction", 0.0f, 1.0f, 20.0f);

motorBaseDesc.Name = "Chassis";

ChassisShape = new BoxShape(motorBaseDesc);


// rear wheel is also called the castor

CASTER_WHEEL_POSITION = new Vector3(0, // center of chassis

CASTER_WHEEL_RADIUS, // distance from ground

CHASSIS_DIMENSIONS.Z / 2); // at the rear of the robot


RIGHT_FRONT_WHEEL_POSITION = new Vector3(

+CHASSIS_DIMENSIONS.X / 2,// left of center

FRONT_WHEEL_RADIUS, // distance from ground of axle

FRONT_AXLE_DEPTH_OFFSET); // distance from center, on z-axis


LEFT_FRONT_WHEEL_POSITION = new Vector3(

-CHASSIS_DIMENSIONS.X / 2,// right of center

FRONT_WHEEL_RADIUS, // distance from ground of axle

FRONT_AXLE_DEPTH_OFFSET); // distance from center, on z-axis


MotorTorqueScaling = 30;


// specify a default mesh

State.Assets.Mesh = "boe-bot.bos";

}

Конструктор для класса BoeBot используется для установки значений нескольких переменных, определенных в классе DifferentialDriveEntity. Например, параметру Mass присваивается значение 0,454, что соответствует массе в килограммах. Кроме этого, шасси Boe-Bot определяется в терминах ширины, длины и высоты.

Положение робота Boe-Bot определяется с помощью набора координат, которые передаются после того, как объект создан. Эти координаты соответствуют точкам осей координат X, Y и Z. Механизм моделирования MSRS использует правую систему координат, что влияет на направление, в котором указывает ось Z.

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

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

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

    1. Создание манифеста


Большинство служб взаимодействуют с другими службами с целью получения доступа к данным и функциям, необходимым данной службе. Такие партнерские службы указываются в верхней части класса реализации с атрибутом Partner. Например, служба моделирования Boe-Bot взаимодействует со службой обработчика модели. Код для включения данного объявления партнера выглядит так:


//Simulation Engine Port

[Partner("Engine",

Contract = engineproxy.Contract.Identifier,

CreationPolicy = PartnerCreationPolicy.UseExistingOrCreate)]

private engineproxy.SimulationEnginePort _engineStub =

new engineproxy.SimulationEnginePort();


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

После загрузки редактора манифестов DSS в левом окне появится полный список доступных служб. В начале работы вам необходимо найти в списке доступных служб основную службу и перетащить ее объект в рабочую область. Если вы сделаете это со службой моделирования Boe-Bot, в рабочей области появится узел для службы SimulatedBoeBot и вспомогательный узел для службы механизма моделирования.

Программа MSRS имеет несколько служб, которые находятся в папке \samples. Одна из них, SimpleDashboard, может использоваться в качестве панели управления моделируемыми роботами. Служба SimpleDashboard позволяет запускать другие службы, используемые для управления специфическими функциями вашего робота. Например, код службы SimulatedBoeBot просто заполняет сцену моделирования объектами, один из которых —Boe-Bot. Кода, который управляет движением робота, в данной службе нет. Этот код берется из службы Drive.

Чтобы загрузить и использовать простой пульт управления, необходимо добавить его в манифест, поместив объект SimpleDashboard в список служб и перетащив этот объект в нижнюю часть рабочей области. Конечный результат должен выглядеть, как показано на (рис.3). Последнее, что остается сделать, это сохранить манифест в папке проекта службы SimulatedBoeBot, сохранив его под именем SimulatedBoeBot.mainfest.xml.



Рисунок . Окончательный вид манифеста


    1. Поехали!


Теперь все готово для запуска службы SimulatedBoeBot. Это можно сделать, выбрав пункты Debug и Run в меню Visual Studio 2008. Вначале на экране появится окно командной строки.



Рисунок . Запуск службы DSS

После того как служба будет загружена, на экране должны появиться два дополнительных окна. Интерфейс Simple Dashboard представляет собой форму Windows, которая содержит несколько групп. В правой части формы содержится группа, называемая Remote Node. Чтобы начать работу, необходимо ввести имя вашего компьютера (localhost) в текстовом окне и нажать кнопку Connect. Этим устанавливается связь со службой SimulatedBoeBot и загружаются партнерские службы объекта, такие как служба движения, которая показана в списке папок (Рис.5).



Рисунок . Simple Dashboard

Служба движения используется для подачи напряжения на колеса, приводящие робота Boe-Bot в движение. Это позволяет роботу Boe-Bot перемещаться по моделируемому миру с помощью виртуального джойстика или настоящего джойстика, подключенного к вашему компьютеру. Чтобы начать работу, необходимо дважды щелкнуть элемент SimulatedBoeBot, который находится в списке. Теперь можно использовать мышь, чтобы управлять виртуальным джойстиком, расположенным в левом верхнем углу формы Simple Dashboard.



Рисунок . Робот Boe-Bot в движение.

Заключение


В процессе создания робота в среде RDS были изучены:
  • основы работы с 3D редактором Blender, создание графических примитивов в виде куба, сферы и выполнения над ними булевых операций. Также были освоены методы редактирования полигональной сетки.
  • компоненты системы MDRS:

Concurrency and Coordination Runtime – это библиотека для работы с параллельными и асинхронными потоками данных, которая базируется на .NET Framework.

Decentralized Software Services – это облегченная базирующаяся на CCR среда для создания распределенных приложений на основе сервисов, которая предусматривает управление множеством сервисов для корректировки поведения в целом.

Visual Programming Language – это язык визуального программирования, разработанный корпорацией Microsoft специально для Microsoft Robotics Developer Studio.

Visual Simulation Environment – это среда симуляции. Так как не у всех есть роботы, она помогает симулировать поведение роботов в виртуальной среде. Для обеспечения реалистичности в виртуальном мире используется технология NVIDIA PhysX.
  • особенности создание службы DSS для MDRS.

В результате проделанной работы была создана модель робота Boe-bot управляемая при помощи Simple Dashboard.

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

  1. Professional Microsoft Robotics Developer Studio: Kyle Johns, Trevor Taylor
  2. ссылка скрыта
  3. ссылка скрыта