Теми рефератів
> Реферати > Курсові роботи > Звіти з практики > Курсові проекти > Питання та відповіді > Ессе > Доклади > Учбові матеріали > Контрольні роботи > Методички > Лекції > Твори > Підручники > Статті Контакти
Реферати, твори, дипломи, практика » Статьи » Моделювання робочого простору мобільного робота

Реферат Моделювання робочого простору мобільного робота





воляє створювати слабо пов'язані розподілені пріложенія.Robotics Studio - це всього лише фундамент для створення багатофункціонального робота.

У контексті робототехніки додаток - це композиція слабосвязанних паралельно виконуються компонентів.

Всі компоненти в Robotics Studio являють собою незалежно виконувані сервіси і виступають як основний елемент в MSRS. Інакше кажучи, з погляду розробника не існує фізичного мотора - є сервіс з інтерфейсом, за допомогою якого розробник звертається до мотору через написану ним програму.

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

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

Сам по собі Runtime складається з двох ключових технологій: Concurrency amp; Coordination Runtime (CCR) - це бібліотека для роботи з паралельними і асинхронними потоками даних, і Decentralized System Services (DSS) - засіб створення розподілених додатків на основі сервісів.

Програмна логіка робота - на відміну від традиційних додатків - повинна взаємодіяти з набагато більш непередбачуваною навколишнім середовищем і адекватно реагувати на інформацію, що надходить від безлічі сенсорів одночасно. Більше того, з багатьох причин має сенс істотну частину логіки перенести на безліч взаємодіючих один з одним комп'ютерів, які фізично можуть знаходитися як на роботе, так і поза ним. У результаті потрібно підхід, який однаково добре годився б як для паралельних, так і для розподілених додатків. Бібліотека Concurrency amp; Coordination Runtime і була спеціально розроблена для того, щоб спростити створення коду для паралельного виконання і хорошого масштабування на сучасних багатоядерних процесорах.

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

При використанні CCR не вимагається вручну управляти потоками, блокуваннями, семафорами, тобто усіма стандартними примітивами синхронізації потоків. CCR - це не просто набір утиліт, це зовсім інший підхід до написання коду. Цей підхід заснований на чергах повідомлень і наборі залежать від даних примітивів синхронізації. Потоки повністю сховані від програміста, і Runtime - залежно від даних і від того, де вони потрібні, - вирішує, який код і де буде виконуватися. Оскільки синхронізація йде за даними, то не рекомендується - і навіть забороняється - використовувати загальну пам'ять (це може повністю порушити схему роботи коду).

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

Згадаємо ще раз, що додаток в контексті MSRS - це композиція слабосвязанних паралельно виконуються сервісів. Тоді для реалізації такого додатка необхідно наступне.

Слабка зв'язаність компонентів - це обеспечивает їх взаємозамінність і легкість повторного використання. Наприклад, можна відключити або підключити сенсор без наслідків для програми в цілому.

Роздільна стану та поведінки - стан сервісу (state) повністю відкрито і при цьому відокремлене від його поведінки (behavior). Це дуже важливо в розподіленої системі і дозволяє сервісам легко взаємодіяти один з одним як локально, так і віддалено по мережі. Поведінка в цій ситуації перетворюється в операції над станом, які можуть його змінювати.

Робота зі станом сервісу, а не із сесією (session-less) - поточний стан сервісу визначається нею самою, і воно ідентичне для всіх, хто б його не запросив. Сервіс не створює індивідуальних сесій для тих, хто з ним працює.

Робота зі структурованими даними - стан сервісу не може бути однорідною масою, і структурування на базі типів CLR дозволяє працювати зі складними структурами даних.

Робота з подіями зміни стану сервісу - відділення стану і його структурованість дають можливість повідомляти про зміни тим, кому це важливо. У DSS є модель, що дозволяє відправляти і отримувати...


Назад | сторінка 10 з 17 | Наступна сторінка





Схожі реферати:

  • Реферат на тему: Розробка інформаційної системи накопичення, зберігання та вибірки даних про ...
  • Реферат на тему: Ознайомлення з мовами програмування web-додатків. Основи роботи з базами д ...
  • Реферат на тему: Розробка додатка в середовищі MS Visual Studio для роботи з базою даних
  • Реферат на тему: Створення бази даних за допомогою програми Microsoft Access: Склад
  • Реферат на тему: Додаток для роботи з базою даних