Программная платформа Microsoft Robotics Studio — это лишь фундамент для создания многофункционального робота, но он может стать основой для дальнейшего развития робототехники при участии энтузиастов и профессионалов, которым будет интересно попробовать себя в новой отрасли.

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

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

Согласно прогнозу Японской ассоциации робототехники, через 5–10 лет объем рынка персональной и домашней робототехники достигнет десятков миллиардов долларов (рис. 1). Но чтобы роботы смогли все таки дойти до потребительского уровня, надо решить ряд проблем, которые пока не позволяют робототехнике сделать такой рывок.

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

Проведя анализ рынка робототехники и пообщавшись как с основными игроками, так и с потенциальными новичками на рынке, корпорация Microsoft (www.microsoft.com) приняла решение выйти на рынок робототехники со своей программной платформой, которая помогла бы в решении основных проблем и позволила бы всем работать вместе.

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

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

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

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

Все компоненты в 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

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

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

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

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

Decentralized System Services

Вспомним еще раз, что приложение в контексте 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 предназначена специально для работы с сервисами.

Microsoft занялась роботами

О своем намерении всерьез заняться направлением робототехники корпорация Microsoft заявила еще летом 2006 г., представив предварительную версию Robotics Studio. Уже первая реакция аналитиков на это объявление показала, что движение Microsoft в этом направлении оказалось очень своевременным и может дать серьезный импульс к развитию данного рынка, который сегодня, с одной стороны, вызывает постоянно растущий коммерческий интерес, а с другой — сильно фрагментирован по причине несовместимости различных платформ.

Уже в конце 2006 г. вышел окончательный вариант Microsoft Robotics Studio — Windows-среды разработки для создания роботизированных приложений для широкого круга аппаратных платформ. В заявлении компании тогда подчеркивалось, что этот инструмент предназначен не только для коммерческих разработчиков, но и для академических и исследовательских организаций и даже просто отдельных энтузиастов.

Одновременно с выпуском продукта Microsoft объявила о начале партнерской программы, направленной на создание ПО, сервисов и роботов на базе Robotics Studio независимыми разработчиками, поставщиками услуг и производителями аппаратных компонентов и законченных устройств. В моменту этого анонса уже более 30 компаний (среди них такие известные поставщики в области робототехники, как CoroWare, KUKA Robot, Robosoft, RoboticsConnection, White Box Robotics) представили свои продукты и изделия, реализованные на базе инструментария Microsoft (с ними можно познакомиться на сайте www.microsoft.com/robotics). Кроме того, Microsoft продолжает тесное сотрудничать в этой сфере с ведущими университетами и исследовательскими институтами.

В Microsoft Robotics Studio входит визуальный программный инструмент для создания и отладки роботизированных приложений, предоставляющих модульные сервисы, с помощью которых пользователи могут взаимодействовать с роботами через Web или Windows-интерфейсы. Разработчики могут моделировать программы и устройства с использованием трехмерных моделей. Для этого Microsoft применила движок PhysX, лицензированный у компании AGEIA, пионера аппаратных и программных технологий в области робототехники.

Для поддержки режима исполнения в Robotics Studio служит .NET-библиотека, включающая функции асинхронного взаимодействия (на основе механизма обмена сообщениями) с различными датчиками и исполняющими устройствами. Программная модель платформы Microsoft позволяет работать с различными аппаратными платформами роботов, реализуя как удаленные (на основе ПК), так и автономные (непосредственно на роботах) сценарии управления с помощью языков Visual Studio (C# и VB.NET), а также других языков, поддерживаемых Microsoft (например, Jscript и Iron Python) либо другими поставщиками.

Программа лицензирования Robotics Studio предполагает различные схемы. В частности, для студентов, преподавателей и просто любителей-программистов инструмент Microsoft доступен бесплатно.

На прошедшей в конце ноября в Москве конференции «Microsoft Платформа 2008» продукт Microsoft Robotics Studio был впервые представлен в России широкому ИТ-сообществу. Его презентацию на конференции и на выставке провели авторы этой статьи.

Андрей Колесов

Сервисы

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

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

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

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

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

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

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

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

Работа приложений

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

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

Рисуем программу для робота

Язык визуального программирования VPL был специально написан для MSRS, чтобы помочь начинающим программистам роботов. Программа на VPL представляет собой диаграмму, где каждый блок имеет свою функциональность и все блоки связаны между собой. Благодаря модели приложений в MSRS, основанной на сервисах и технологиях CCR и DSS, VPL превращается в блок-схему координации сообщений между разными сервисами.

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

Стоит еще добавить, что язык визуального программирования хорошо подходит для быстрого создания прототипов, тем более что диаграмму, написанную на VPL, можно перекомпилировать в код сервиса на C#. Так как диаграмма в VPL сама представляет собой сервис, ее можно использовать повторно в других диаграммах и других сервисах, написанных на языках платформы .NET. На рис. 3 показан пример простой программы, написанной на VPL, которая выводит на экран сообщение «Привет, мир» (Hello world).

В инсталляционный пакет Microsoft Robotics Studio помимо собственно VPL входят многочисленные примеры и уроки его использования.

Что делать, когда робота нет

Часто команды разработчиков ПО для роботов сталкиваются с такой проблемой, как отсутствие реального робота или же очень ограниченное его присутствие (например, один на команду). Отладка программы для роботов на реальном роботе — это также весьма трудоемкая задача. Для разрешения такого рода проблем и был создан симулятор (рис. 4), который поставляется вместе с Microsoft Robotics Studio. У симулятора есть как явные плюсы, так и ряд ограничений.

К плюсам симулятора можно отнести следующие:

  • его достаточно легко начать использовать;
  • это замечательная утилита для обучения и исследований;
  • сценический подход позволяет моделировать окружающий мир, создавая предметы и расставляя их в нужных местах;
  • развитая графика (за счет возможностей трехмерных ускорителей) позволяет точно моделировать визуальную составляющую окружающего мира;
  • cимуляция физики поддерживается в полном объеме.

Ограничения же симулятора таковы. Во-первых, в симуляторе мир идеализирован, т. е. нет искажения данных, как в реальном мире. Например, поверхность, по которой ездит робот, может не создавать трения, в то время как в реальном мире такой поверхности не существует. Впрочем, при написании сервисов для конкретных «виртуальных» сенсоров можно добавлять шум, похожий на экспериментальный.

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

В-третьих, чем более точную модель мы хотим создать, тем более четкой должна быть настройка, а это требует очень много времени.

И наконец, модель физики в Microsoft Robotics Studio достаточно упрощена, поэтому симуляция не подойдет там, где нужны сверхточные расчеты.

Робототехника в жизни

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

На сегодня можно выделить следующие основные направления развития технологии Microsoft Robotics Studio:

  • потребительская робототехника;
  • образовательная и исследовательская робототехника;
  • помощь энтузиастам в робототехнике;
  • соревнования и конкурсы в робототехнике;
  • использование компонентов MSRS отдельно от робототехники.

Добавим еще, что дополнительную информацию на эту тему можно найти на сайте www.microsoft.com/robotics  и в блоге команды разработчиков по адресу http://blogs.msdn.com/msroboticsstudio.

Потребительская робототехника

Множество компаний — партнеров Microsoft используют Microsoft Robotics Studio в потребительской робототехнике, разрабатывая реальные коммерческие модели роботов. Но этот рынок пока продвинулся до реальных потребителей лишь в некоторых странах, по своей культуре более к этому предрасположенных — таковы, например, Корея и Япония. В России этот рынок пока находится в зачаточном состоянии, но мы надеемся, что вскоре сможем найти партнеров и начать успешно работать с российскими компаниями.

Изучение робототехники

Microsoft Robotics Studio — идеальный вариант для изучения роботов и методов их программирования. Для этого существуют дешевые, очень простые в использовании и программировании и при этом достаточно функционально богатые роботы, такие, как Lego NXT и iRobot Create. К примеру, Lego NXT состоит из трех моторов, четырех сенсоров и управляющего микроконтроллера с интерфейсом Bluetooth для связи с компьютером. С помощью обыкновенного конструктора Lego и этого набора можно собрать любых роботов, ограниченных лишь фантазией их авторов.

Помощь энтузиастам

Энтузиасты, которые занимаются робототехникой, с помощью Microsoft Robotics Studio смогли существенно расширить возможности своих роботов и воспользоваться огромным количеством аппаратных платформ, которые поддерживаются как сервисы в MSRS.

Соревнования в робототехнике

В мире постоянно проводятся соревнования среди роботов. И в них каждый волен использовать того робота и те средства программирования, которые покажутся наиболее привлекательными (и соответствуют условиям конкурса). С выходом Microsoft Robotics Studio многие команды стали использовать именно MSRS для разработки своих проектов, добившись впечатляющих результатов. Рассмотрим лишь два примера. В гонке робото-автомобилей Darpa Urban Challenge команда из Принстона использовала MSRS и вышла в полуфинал, имея самый маленький бюджет среди всех команд. В соревнованиях среди роботов — подводных лодок, проводимых Office of Naval Research, робот из Университета Флориды, запрограммированный с помощью Microsoft Robotics Studio, занял первое место в конкурсе.

Использование компонентов MSRS отдельно от робототехники

Некоторые компоненты Microsoft Robotics Studio используются в сторонних проектах, никак не связанных с робототехникой. Наибольшую популярность получила библиотека Concurrency & Coordination Runtime. Работа с многопоточным программированием достаточно трудоемка, и в этом свете библиотека CCR, существенно упрощающая создание многопоточных приложений на платформе Microsoft .NET, имеет много преимуществ. Один из наиболее известных примеров — сайт mySpace.com, который использует CCR как часть инфраструктуры back-end.

* * *

Подводя итог, хочется сказать, что Microsoft Robotics Studio — это проба пера, первый шаг Microsoft в области робототехники. И сейчас, спустя год после выхода MSRS, можно смело утверждать, что этот шаг был действительно успешным.

Евгений Марченков, эксперт по разработке ПО, evgenym@microsoft.com, корпорация Microsoft, Павел Хижняк, инженер по разработке ПО, pavelkh@microsoft.com корпорация Microsoft 08.02.2008