Основи застосування середовища Microsoft Robotics Studio, Середовище моделювання роботів MicrosoftRobotics
Середовище моделювання роботів 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) - поточний стан сервісу визначається ним самим, і він ідентичний всім, хто його запросив. Сервіс не створює індивідуальних сесій для тих, хто працює з ним.
p align="justify"> Робота зі структурованими даними - стан сервісу не може бути однорідною масою, і структурування на базі типів 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].