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

среда, 24 декабря 2008 г.

Microsoft Robotics Studio. Sumo-робот

Продолжаю серию статей про Robotics Studio.

В этой статье я расскажу, как сделать собственного Sumo-робота для соревнований симуляций сумо-роботов от Microsoft. Для этого, помимо установленной Robotics Studio (у меня - версия 1.5), необходимо скачать проект сумо-симуляции с сайта Microsoft.

Скачав, распакуйте zip-архив, и запустите файл Sumo Competition for Microsoft Robotics Studio (1.5).exe. В конце быстрой и простой установки откроется html-инструкция по использованию данного продукта.

Инструкцию можете закрывать, я вам итак все расскажу. Сначала нужно запустить командную строку Robotics Studio (эта "функция" доступна через меню Пуск). Затем выполните команды cd bin (переход в каталог [bin]), и makesumoplayer /name:имя-вашего-сумо-робота /forse:true. Я своего назвал просто: MySumo. В имени должны присутствовать только английские буквы и цифры - без пробелов. Вы, наверное, сможете придумать что-нибудь более оригинальное :) Вот что видим в ответ:

Итак, новый проект создан. Путь, где его можно отыскать, указан. Идем туда, открываем файл проекта. В моем случае этот файл называется MySumo.csproj.

Мне потребовалось сконвертировать проект под 2008-ю студию, т.к. создан он под какую-то более древнюю версию. Но это пара кликов мышью, ничего сложного... В итоге видим:

Итак, проект открыт - и теперь начинается самое интересное. Для начала, просто запускаем проект, нажимая F5. Выбираем в качестве соперника стандартную симуляцию (sumoplayer):

Между прочим, у вас наверняка возник вопрос: как сделать своему роботу особенную картинку? Все очень просто: нужна BMP-картинка 64х64 пиксела. Скопировать ее нужно в папку [Resources] внутри проекта, заменив файлик PlayerImage.bmp.

Несколько матчей подряд я смотрел, как ведут себя роботы. И пришел к выводу, что у них есть 2 достаточно большие проблемы:

  1. Если один робот, оказывается к другому роботу задом, - все, первый почти гарантированно проигрывает.
  2. Иногда робот сам усугубляет свое положение, оказываясь близко к линии в момент атаки. Логично было бы держаться центра ринга как можно дольше.

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

Как только понимание сути изменений достигнуто - можно приступать к следующему этапу: разбору кода. Код сгруппирован в несколько групп с помощью директив #region и #endregion. Нас будут интересовать только две группы: Sensor Handlers to be copied, и Timer Handler to be copied.

Как не сложно догадаться, первая группа отвечает за обработку событий от сенсоров, в то время как вторая - это таймер. В первой группе задается ПЕРВАЯ реакция робота. Например: увидел линию? - развернись на 130 градусов. Или: увидел соперника через камеру? - начни сближение.

Соответственно, если мы хотим предусмотреть в качестве реакции не единичное действие, а целую последовательность действий (например, сначала развернуться, потом проехать вперед, потом постоять, потом вернуться назад - и т.д.) - то нам необходимо дальнейшие действия указывать уже в процедуре обработки такта таймера.

Сложно? Да нет! Это только так кажется. В любом случае, привыкайте, такова стандартная событийная модель программирования.

Продолжим... Естественно, для связи процедуры таймера и процедур обработки непосредственных событий - необходимы какие-то состояния. Они есть, и содержатся в переменной _state. Что это такое - нам по большому счету неинтересно, по названию понятно. Немного поизучав код, мы можем обнаружить основные состояния робота:

  • _state.SumoMode == SumoMode.Contact - состояние, когда роботы столкнулись друг с другом и находятся в противоборстве. Основная проблема этого состояния состоит в том, кстати, что робот физически не может определить касание сзади - у него там нет датчика касания.
  • _state.SumoMode == SumoMode.AvoidBoundary - состояние, в котором робот старается избежать попадания за границу ринга.
  • _state.SumoMode == SumoMode.Tracking - робот засек противника камерой и едет за ним.
  • _state.SumoMode == SumoMode.Wander - режим свободного поиска противника.

Есть также и некоторые другие состояния робота, не столь критичные. Если вам понадобятся их описания, весь список присутствует в файле MySumoTypes.cs (ИмяВашегоСумоистаTypes.cs), при описании enum'а SumoMode.

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

Начнем с простого: как заставить робота держаться центра ринга? Очень просто. Надо заставить его просто крутиться на месте, не давая при этом двигаться вперед. В таком случае, качество поиска измениться не сильно, зато подставляться наш "боец" будет меньше.

Очевидно, что нам необходимо изменить действия робота в режиме свободного поиска. Поискав "SumoMode.Wander" в коде (Ctrl-F в MS Visual Studio), находим процедурку SetWanderDrive(), для которой написано в комментариях: This is the default drive configuration for wander mode. То есть, эта процедура назначает действия по умолчанию для робота, переходящего в режим свободного поиска.

Она состоит всего из двух строк, в первой изменяем текущее состояние робота на Wander, а вот во второй вызываем пока непонятную процедурку InternalDrivingMilliseconds().

Что же, жмем по названию этой процедуры правой кнопкой, выбираем в меню Go to definion. Смотрим заголовок процедуры:

public void InternalDrivingMilliseconds(int left, int right, double ms)

Что же, все понятно. Эта процедура задает скорости для двух моторов - левого, и правого - на определенное число миллисекунд (которое тоже задается). Скорости моторов, насколько я понял из кода, варьируются от -500 до +500, а число миллисекунд можно задать какое угодно, лишь бы больше нуля, естественно :)...

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

Вот что получилось у меня в итоге:

private void SetWanderDrive()
{
   _state.SumoMode = SumoMode.Wander;
   InternalDrivingMilliseconds(0, 400, 250.0);
}

Запускаем, смотрим: все именно так, как нужно. Наш робот вертится на месте, а его противник бегает туда-сюда. Правда, для весомого преимущества этого недостаточно.

Давайте попробуем воплотить вторую мою мысль.

Нам необходим фрагмент кода внутри процедуры RobotUpdateFloorSensorsHandler, содержащий текст "SudoMode.AvoidBoundary". Этот фрагмент отвечает за реакцию робота на засечение им линии впереди. Поскольку сам собой наш робот не движется, то если он засек линию - это может означать только лишь тот факт, что его толкает сзади враг. А значит, нужно срочно на всех парах мчаться назад! Ничего особенного, кроме уже известной нам процедуры InternalDrivingMilliseconds, в этом фрагменте нет. Вот что получилось у меня в итоге:

if (_state.Sensors.LineDetected)
{
  _state.SumoMode = SumoMode.AvoidBoundary;
  LogVerbose(LogGroups.Console, "Sumo Mode: AvoidBoundary");
  if (_state.Sensors.LineLeft && 
     !_state.Sensors.LineRight && 
     !_state.Sensors.LineFrontRight)
    InternalDrivingMilliseconds(-100, -400, 200.0);
  else if (_state.Sensors.LineRight && 
          !_state.Sensors.LineLeft && 
          !_state.Sensors.LineFrontLeft)
    InternalDrivingMilliseconds(-400, -100, 200.0);
  else
    InternalDrivingMilliseconds(-500, -500, 400.0);
}

Запускаем, лучше всего штуки три матча подряд. У меня статистика трех матчей получилась такая: 2 раунда проиграно, 1 ничья, 6 раундов выиграно. Думаю, комментарии излишни :)

P.S. На написание данной статьи меня сподвиг Дмитрий Калинин (kalisha), за что ему огромное спасибо. Он прислал собственную статью, на тему создания робота для соревнований Microsoft ImagineCup, однако эта статья потребовала настолько глобальной переделки, что я ее полностью переписал, полностью сам разобрался в коде, адаптировал его под стандартную сумо-арену, ну и т.д. Очень надеюсь, что следующую статью Дмитрия я смогу выложить в менее "отредактированном" варианте :)

среда, 5 ноября 2008 г.

Программирование. Среды разработки для роботов

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

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

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

Сама же Microsoft, выпуская робототехническую среду разработки, руководствовалась фактами повального внедрения роботов в нашу жизнь. Может быть, кстати, поводом стало то, что какому-нибудь из топ менеджеров корпорации подарили на день рождения робота(что, кстати, часто бывает)... Или же это было серьезнейшее исследование из серии "Куда вложить деньги?". Не знаю.

Зато знаю, что статистику по роботам можно свободно посмотреть на сайте IFR Statistical Department (на английском). Очень познавательно, и главное - сразу понятно, чем руководствовался Microsoft :)

В общем, роботы продаются. А значит - это бизнес. А значит - их производят, и готовы вкладывать в их изготовление деньги. Ну и как следствие, нужны специализированные среды разработки, чтобы программировать роботов с минимальными затратами. Нужны также и стандарты (которых, правда, пока маловато). И все это, на самом деле, робототехникам-любителям - очень даже на руку:

  • Во-первых, это потенциальная работа. Сегодня пишут: требуется программист со знанием Ajax, C#, ASP.Net. Завтра - кто знает, может быть на кругленькие суммы будут требоваться знания Microsoft Robotics Studio?
  • Во-вторых - это готовые драйвера для различных робототехнических устройств и для наиболее распространенных роботов-конструкторов.
  • В-третьих - это готовые к использованию, мощные библиотеки алгоритмов и решений. Например, поиск пути, распознавание образов, голосовое управление и т.д.

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

При этом, конкуренция очень важна. Microsoft, они возьмут завтра, и сделают Robotics Studio платной (кстати, для коммерческого использования она платная уже сейчас). Да и вообще, всегда приятно, когда есть альтернатива. Ведь кто пользуется Windows Media Player? Правильно, те, кто ни разу в жизни не видел Winamp :)

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

Skilligent - эта фирма является лидером в области технологий обучения роботов и их взаимодействия с окружающей средой. Философия Skilligent - отказаться от жесткого программирования функций робота, и сосредоточиться на предоставлении интерфейса для обучения робота любым функциям (между прочим, помните про робота, которого научили готовить яичницу?). Основной продукт фирмы называется Robot Learning and Behavior Control System, и в его составе поставляются следующие модули:

  • Система машинного зрения, позволяющая распознавать и отслеживать объекты, описания которых берутся из соответствующей базы данных.
  • Система навигации, которая берет на себя функции ориентирования в знакомых помещениях. Знакомыми помещения становятся после обучающей сессии...
  • Урезанная версия отказоустойчивой системы управления (Fault-Tolerant Control Framework), служащей для координации работы всех остальных модулей.

Robot Learning and Behavior Control System на самом деле не является самостоятельной средой разработки, зато представляет из себя прекрасный сборник решений. Силами специалистов Skilligent она была интегрирована в Microsoft Robotics Studio.

Полнофункциональная система разработки Urbi, детище компании Gostai, по функционалу стоит очень близко к Microsoft Robotics Studio. Urbi использует симуляционную среду Webots, и имеет готовые интерфейсы для роботов Aibo, iRobot Create, LEGO Mindstorms NXT. Интерфейсы для других роботов находятся в разработке.

Большим преимуществом Urbi является ее кроссплатформенность: система работает под Windows, Linux, и Mac OS. Также, благодаря модульности продукта, по весу Urbi получается гораздо меньше, чем MSRS.

Urbi имеет неплохой набор графических утилит разработки. Например, urbiMove - позволяет записывать последовательность действий робота, и затем воспроизводить их. Управляются роботы с помощью скриптового языка urbiScript.

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

В сообщении Наборы для роботостроения. Конструкторы роботов я уже описывал (немного гневно) набор ER1 от компании Evolution Robotics. Программное обеспечение для вышеупомянутого конструктора - продукт ERSP, является на самом деле серьезной средой разработки ПО для роботов, и состоит из трех основных частей: модуля визуального распознавания, модуля ориентирования (также с использованием веб-камеры), и операционной системы робота. Именно этому продукту, судя по всему, система ER1 обязана своей немаленькой ценой.

OROCOS (Open RObot COntrol Software) - это, как видно из названия, открытое программное обеспечение для управления роботами. К сожалению, у OROCOS отсутствуют как графические инструменты разработки, так и симуляционная среда; по сути дела это всего лишь набор библиотек для работы с роботами. Впрочем, иногда, чисто программистский подход - это намного лучше концептуально новых, и оттого непонятных, графических сред...

Общие данные по перечисленным выше системам собраны в таблице:

  MSRS 1.5 Skilligent Urbi ERSP OROCOS
Открытый исходный код Нет Нет Частично Нет Да
Бесплатно Edu/hby Нет Частично Нет Да
Windows Да Да Да Да Нет
Linux Нет Да Да Да Да
Распределенная архитектура
(сервисы)
Да Да Да Нет Нет
Отказоустойчивость Нет Да Нет Нет Нет
Стандарт JAUS Нет Да Нет Нет Нет
Графический контрольный
интерфейс
Да (Web) Да Да Да Нет
Графическое Drag-n-Drop IDE Да Нет Да Да Нет
Встроенный контроль
манипулятора робота
Нет Да Нет Нет Да
Встроенная система
распознавания изображений
Нет Да Нет Да Нет
Встроенная система
ориентирования
Нет Да Нет Да Нет
Обучаемость Нет Да Нет Нет Нет
Симуляционная среда Да Нет Да (Webots) Нет Нет
Система реального времени Нет Нет Нет Нет Да

понедельник, 8 сентября 2008 г.

Робототехника и полезность ненужных дел

Наткнулся на интересную новость: сделали робота, представляющий из себя солнечные часы. Насколько я понял принцип его действия, робот поворачивается вокруг своей оси до тех пор, пока тень от закрепленной на нем длинной планки не упадет на фотодиод, установленный в определенном месте. Градус поворота сравнивается с показаниями встроенного компаса. Вычисленное таким образом текущее время выставляется на обычном табло с "нормальными" часами:

Оригинал статьи находится в англоязычном блоге «The NXT STEP», а сам робот, как нетрудно догадаться из названия блога, сделан из робототехнического конструктора LEGO Mindstorms NXT.

Теперь посмотрим, для чего этот робот может пригодиться на практике. Даже если предположить его применимость и полезность в дальнем походе, ну скажите честно, не проще ли взять гораздо примитивнее устроенные (и следовательно более надежные) обыкновенные часы? Если есть теоретическая вероятность выхода часов из строя - можно взять 10 часов :). Робот, даже если его размеры значительно уменьшить, в любом случае будет габаритнее и менее надежным, чем часы. Просто потому, что он сложнее устроен, содержит движущиеся части и т.д.

Де факто, этот робот был сделан энтузиастами просто для галочки. Что, мол, это реально. Что, скажем прямо, Lego Mindstorms NXT, это как бы здорово, и какой только фигничто только с его помощью не сделаешь!

Итак, робот бесполезен. Вопрос: зачем люди тратили время (а время, как известно - это потенциальные деньги)? Дак вот, зачем же люди тратили деньги? Зачем все это?

Расскажу другую историю, на этот раз лично про меня. Буквально пару дней назад сидел и адаптировал код бэйсиковской игрушки "Hamurabi" (Хаммурапи) для собственного интерпретатора языка tiny Basic. Интерпретатор этот был написал на придуманном мною языке XM, и скомпилирован в обычный exe-шник с помощью собственноручно написанного компилятора этого моего языка...

Вышеупомянутый компилятор, кстати сказать, имеет еще одну особенность. Он позволяет писать программки для моей собственной операционной системы под названием SOS. Ее я когда-то написал на ассемблере...

Как сейчас помню, целый месяц ушел на создание компилятора, два месяца - на создание и последующую доработку операционки...

Снова позволю себе поставить перед вами тот же самый вопрос: оно нужно? Оно полезно? Компиляторов самых различных языков существует на сегодняшний день просто масса. Их сопровождают мощные среды программирования, в том числе такие монстры, как Microsoft Visual Studio. В то же время я, кроме редактора Notepad++, или какого нибудь самодельного редактора с встроенным компонентом SciLexer - предложить ничего не могу... Да, придуманный мной язык позволяет писать программы как на высоком, так и на очень низком уровне, благодаря чему можно избежать в теле программы обращений к функциям специфической операционки, заменив их на функции другой (моей собственной) операционки. Но на самом деле, благодаря ассемблерным вставкам - такой же фокус можно провернуть, например, и в Pascal/Delphi, и в C/C++...

Да, мой компилятор генерирует чудовищно компактные exe-шники, главным образом благодаря тому, что не использует множество ненужных библиотек. Но вот вопрос: при современных объемах жестких дисков, есть ли разница между программой размером 1Мб, и программой размером 10Кб? Разницы этой - пшик...

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

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

Да, моя ОС загружается и работает при отсутствии Windows... Умеет работать с файловыми системами FAT12, FAT16, FAT32, и ограниченно - с ext2. Умеет выполнять специально под нее написанные программы. Но какая в этом польза? В принципе, можно бы сделать компактную, умещающуюся на дискетку операционку для управления роботом. Ведь в роботе это очень практично, - использовать вместо жесткого диска или USB-флэшки, - старенький флоповод, никому уже не нужный и стоящий копейки. Вся проблема состоит в том, что операционка такая уже есть - это, например, QNX. И если поискать - можно найти еще пару таких же крохотных операционных систем. Наконец, всегда есть возможность подработать некоторые особенно компактные дистрибутивы Linux...

Итак, убито три месяца времени, которое можно было бы потратить на что-либо другое. В чем же состоит она, пресловутая «полезность ненужных дел»?

Во-первых, приобретен опыт. Во-вторых, получено удовольствие (по этому поводу я уже писал статью Хобби и робототехника). В-третьих, что бы значила для нас сейчас фамилия Энштейн, если бы один молодой парень в свое время не пытался сделать то, что уже вроде бы давным давно уже сделано?!

Всегда можно и всегда нужно пробовать, пытаться. Лучше, конечно, чтобы Вы пытались сделать что-то действительно полезное. Но как минимум это должно быть интересным лично для Вас. А уж полученные навыки никогда не поздно применить!

воскресенье, 24 августа 2008 г.

Машинное зрение реальных роботов

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

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

Исходные коды программы управления роботом команды "Зоркие", победителя фестиваля мобильных роботов-2007, выложены на их сайте, вместе с подробнейшими пояснениями. Этот робот также использует алгоритмы распознавания образов, причем на основе нейронных сетей.

Структурная схема робота команды "Зоркие" представлена на рисунке (кликните для увеличения):

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

Наконец, еще несколько исходников для Borland C++ Builder по работе с распознаванием образов есть на странице некоего господина, скрывающегося под ником smorodov. Демонстрируются приемы по работе с библиотекой OpenCV, являющейся мощным инструментом для работ в области машинного зрения.

Обновление 25.06.2010: изменился адрес сайта команды "Зоркие", теперь ссылка актуальна. Спасибо человеку mega16, который мне об этом сообщил :)

вторник, 19 августа 2008 г.

Роботы и онлайн-игры

Идея о создании системы с дистанционно управляемыми роботами захватила меня очень давно. Началось, помню, с того, как мне рассказали про робота, который сажал семечко и за ним ухаживал. Посадить собственное семечко мог каждый. Эдакий получался "тамагочи" - нового поколения... (правда, ссылку на тот сайт - так и не нашел, может, кто из читателей подскажет?)

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

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

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

И в душе всегда лелеял надежду - да и до сих пор она меня не оставила, - что когда-нибудь смогу сделать какую-нибудь онлайн-игру, в которой бы люди управляли реальными роботами... Причем, чтобы можно было бы поиграть даже бесплатно - пускай, "простояв" некоторое время в очереди.

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

Вновь интерес к этой теме проснулся, когда, достаточно недавно, прочитал о подобной идее в списке проектов сайта Robotronic.Ru. Правда, связавшись с представителями сайта, понял, что в ближайшем будущем "онлайн-реалити шоу", как они эту штуку назвали, врядли будет создано, если будет создано вообще... А жаль, ведь подразумевалось использование в игре роботов iSobot, достаточно дорогих и весьма продвинутых по функционалу. И у кого, как не у очень крупного интернет-магазина по продаже роботов, каковым и является Robotronic, есть возможность эту идею действительно воплотить в жизнь!

Давайте немного обратим внимание на пути реализации. Ведь на самом деле, все не так уж и сложно. Большинство серийных, наиболее популярных роботов - имеют библиотеки для Robotics Studio. А значит, есть очень серьезный и продуманный инструмент, постоянно развивающийся, с возможностью подключения веб-интерфейсов и интеграцией практически с чем угодно. Так что, создание программы - не такая уж и сложная задача, думаю, первый вариант системы управления онлайн-роботами можно создать в течение месяца, максимум двух.

Конечно, для конкретной задачи роботов нужно особенных. И это - тоже не страшно! Существуют конструкторы роботов, с их помощью можно создать именно то, что нужно. Хотя, в России такие конструкторы - вещь редкая, однако найти можно. Кстати, минимальная цена в России за робота iRobot Create, которого я так долго порывался купить - 6 700 рублей.

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

Жаль, но купив квартиру, я теперь вынужден платить немаленький кредит, и сам организовать игрушку, - уже ясно, - не потяну. А идея очень хороша. Я спрашивал своих знакомых. Практически все были заинтересованы. Может, кто-нибудь из уважаемых читателей возьмется инвестировать, или полностью воплотить в жизнь эту идейку? Если так, рассчитывайте на мою полную поддержку :)

Сомневаетесь, что это оправдано? Не уверены, что "тема пойдет"?

Между тем, буржуи, хотя у них проблем с покупкой "живых" роботов вроде бы особых и нету, не дремлют. Пять небольших роботов модели Surveyor SRV–1 Blackfin Robot на полигоне в Австралии уже ожидают добровольцев, готовых ими поуправлять...

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

Мне, правда, почему-то не удалось поиграть, либо скорость недостаточна, либо у них там какие-то баги, либо у меня нужные порты закрыты (что скорее всего)... Экран оставался черным, а примерно через минуту вылетало окно с ошибкой "Timeout error" :(

четверг, 31 июля 2008 г.

Модульные роботы

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

Наиболее известный на сегодняшний день модульный робот называется SuperBot. Состоит любой Superbot из множества кубического вида модулей, которые могут соединяться с другими модулями любой из шести своих граней.

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

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

Впрочем, лучше один раз увидеть, чем сто раз услышать. Так что, смотрим репортаж FOX news о Superbot'е:

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

Подобных SuperBot'у модульных роботов существует, на сегодняшний день, уже очень много. Например, наш российский модульный робот Змеелок, собранный в ЦНИИ РТК. Иностранных разработок в этом направлении - также великое множество. Например, очень интересен модульный робот YaMoR, модули которого обмениваются друг с другом информацией через Bluetooth. Или вот ссылка на описания сразу нескольких иностранных модульных проектов: http://www2.parc.com/spl/projects/modrobots

А вот еще один робот, модули которого умеют собираться вместе, если их отбросить друг от друга:

Как можно заметить, модульные роботы обладают рядом серьезных преимуществ. Надежность, способность преодолевать сложные препятствия, менять форму, делиться и соединяться вновь. Superbot'у, например, уже давно пророчат будущее исследователя иных планет.

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

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

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

Об идеологии распределенной работы хорошо написано в статье Кластеры, а текущие проекты распределенных вычислений в Интернет - освещены в другой статье, Распределенные вычисления.

Из этих статей видно, что современные распределенные вычисления - это не совсем то, что нужно модульным роботам. Таким образом недостаток алгоритмов - сейчас главная проблема направления модульности в робототехнике. Впрочем, работы по созданию новых алгоритмов ведутся уже полным ходом. В частности, пара подходов рассмотрена в документе Declarative Programming for Modular Robots (на английском языке).

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

четверг, 29 мая 2008 г.

Искусственный интеллект роботов. Игры

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

Ведь согласитесь, BEAM-роботы хороши, но это ведь каменный век!

Неплохим подспорьем (тренировкой) на пути к созданию Умного Робота - может стать разработка алгоритмов для виртуальных роботов, и участие в онлайн-чемпионатах алгоритмов. Я уже писал об этом в сообщении Виртуальные соревнования роботов. Поединок программ.

Тогда я упоминал проект Арена Роботов. Недавно со мной связался создатель этого проекта, Александр Залога, и поинтересовался моим мнением относительно своей Арены.

Также, Александр подкинул пару ссылок на в той или иной степени аналогичные проекты:

  • Robot Warfire - это проект, послуживший основной для Арены Роботов. Все довольно примитивно, однако играть, я подозреваю, было очень интересно. Вкратце: на поле выставляется несколько типов предметов: стена, яма, элемент питания, боеприпасы, вражеский робот, дружественный робот. У самого робота есть 4 слота, смотрящих в разные стороны. В слот можно помещать либо оружие, либо глаз робота. Робот видит соседние клетки, если они примыкают к его глазам. Ну и наконец, пишем суперхитрый скрипт поведения и маневрирования, и вперед, на чемпионат... Скриптовый язык, кстати, очень напоминает Бэйсик. Об этой простой, в общем-то, программке писали даже на Игромании!
  • Описание трехмерной арены роботов можно найти на Delphi Lab. Написано, правда, не русскими, но зато ребята очень мощно шагнули в графическом плане.

Кстати, самой крутой игрой по части "игрового искусственного интеллекта" я до сих пор считаю игрушку Генерал от NewGame Software. Ничего лишнего, никакой графики, но уж очень интересно играть. И, как ни странно, безумно реалистично (сочетание реализма и геймплея - это весьма сложная задача для практически любой игры).

Создание игрового ИИ - задача сложная и очень серьезная. Играя в проекты, подобные RoboChamps или Арене Роботов, Вы эту задачу пытаетесь решить.

На самом деле, если бы я стал делать что-то подобное проекту Александра, вот на что я бы обратил внимание в первую очередь:

  1. Позаботился бы о наличии в игре реализма.
    • Выбор типа шасси. У каждого типа шасси свои особенности - разная проходимость, разная скорость передвижения, и т.д. Основные типы шасси: колесное, шагающее, прыгающее, ползающее, гусеничное, летающее, плавающее, амфибия и т.п.
    • Выбор набора датчиков. Тепловые, световые, видеокамера, радары разной дальности, дальномеры и т.п. Набор датчиков сильно влияет на способ выбора цели, скорость наведения, скорость движения по пересеченной местности; на способ обхода препятствий и построения маршрута движения и т.п.
    • Выбор набора оружия. Разная поражающая способность, разный вес, разный нагрев, разное потребление припасов и боезапаса. Я бы даже сделал оружие более приближенным к реальному. Т.е. например, пневматическая стрельба железными пульками; укрепленная на роботе бензопила и т.п.
    • Выбор количества и типа элементов питания. Солнечные батареи, различные аккумуляторы (какие-то работают дольше, но и заряжаются дольше, какие-то всем хороши, но имеют очень большой вес) и т.п. Это будет сильно влиять на зависимость робота от подзарядки.
    • Выбор брони. Ну здесь главное - вес. Чем тяжелее броня, тем сложнее роботу двигаться, а следовательно, тем больше он жрет энергии и медленнее ходит.
    На самом деле, настоящий робототехник действует по сути точно также: выбирает шасси, набор датчиков, тип элементов питания. Ну оружие и броня - только в случае роботов сумо или роботов для чемпионатов по стрельбе в цель.
    Реализм прибавляет игре привлекательность, но важно при этом не забыть о геймплее. Если выбора слишком много - глаза начинают разбегаться, и интерес к игре пропадает, либо сводится к перебору многих сотен вариантов оснащения робота, даже не доходя до главного - до алгоритма его поведения...
  2. Я бы сделал игру достаточно простой в графическом исполнении, но такой, чтобы максимальное число людей могли за игрой наблюдать онлайн. Например, чтобы можно было смотреть за игрой через браузер.
  3. Я бы сделал формат задания роботов и алгоритмов их поведения максимально стандартизированным. Например, есть такой язык RoboML, я о нем написал целую статью в свое время: Язык описания роботов - RoboML.
    Это весьма проработанный язык для описания роботов и их поведенческих функций. Как показывает практика, стандартизация в современном мире - это задача №1. Также, можно использовать стандарты, совместимые с Microsoft Robotics Studio, это еще более перспективное направление. Например, как вам такая идея: робот может работать согласно алгоритмам, созданным в Visual Programming Language? :) Ведь потом благодаря Robotics Studio можно будет перенести наработки алгоритмов на использование с совершенно реальными роботами!
  4. Систему управления я бы организовал из множества блоков "если". Например:
    • Если увидел цель - сближайся на максимальной скорости и тарань ее.
    • Если зарядки осталось 20% - ищи электростанцию.
    • Если зарядки более 20% и никто не нападает - свободный поиск..
    Это обыкновенный алгоритмический способ управления. Все алгоритмы более низкого уровня (поиск пути, захват цели) - пусть будут реализованы внутри игры. И для задания алгоритмов верхнего уровня я бы сделал нормальный обычный интерфейс, можно даже интерфейс на сайте, чтобы никуда не надо было ходить и ничего не нужно было бы скачивать.
    Таким образом, игра будет иметь больше игроков, ведь алгоритм может придумать почти каждый, а на С или на чем-нибудь еще - умеет программировать лишь ограниченное число людей. Даже после появления .Net...
    Но для истинных любителей, конечно, можно оставить альтернативную возможность создания полномасштабной программы управления.
  5. Добавил бы игрокам вселенскую цель, помимо уничтожения друг друга. Ведь сами подумайте, вот например в Арене Роботов. Там есть электростанции, от которых роботы подзаряжаются. Напрашивается следующая тактика: ищем электростанцию, заряжаемся, сидим ждем. Приходит враг - расстреливаем его, заряжаемся снова, ждем дальше. Разве интересно?! А представьте два противника и две электростанции - и сидят ждут друг друга...
    Нужна вселенская цель, которой заканчивается игра. Скорее всего, захват какого-либо артефакта, или флага.
  6. Добавил бы возможность командной игры. Это чрезвычайно важно в любой онлайн-игре. Банальный хороший чат. И как следствие - нужна возможность перепрограммирования роботов "на лету". И еще как одно следствие - необходима возможность создания и сохранения нескольких типов поведения, которые можно быстро, одним кликом мыши, менять друг с другом в процессе игры (типа мирное существование, избегание боев, агрессивность и т.п. Кстати, чтобы перепрограммирование не было слишком частым, лучше всего ввести зависимость этой возможности от наличия на роботе, например, некоего радиоприемника. А вместо радиоприемника ведь всегда можно поставить хорошую пушку, так что возможность перепрограммирования в данном случае компенсируется.

Да, кстати, если вдруг кто захочет такую вот штуковину написать - с удовольствием предоставлю бесплатный хостинг :) Обращайтесь!

суббота, 19 апреля 2008 г.

Wiimote + Robotics Studio

Сегодня я хочу рассказать еще немного о замечательном устройстве ввода информации с обратной связью от компании Nintendo - Wii Remote. Для тех, кто забыл, или не знал (я уже о Wii Remote писал) - вот какие, например, возможности дает это устройство:

Этот прекрасный демонстрационный ролик от Джонни Ли (я был просто поражен, когда увидел это видео впервые...), конечно, больше относится к игровой индустрии, однако и для роботов Wii Remote может пригодиться. Например, вот в таком виде:

Это видео сделано французом по имени Альберто Биэтти (Alberti Bietti), который на своем блоге разместил целое руководство по подключению Wii Remote к Microsoft Robotics Studio, и использованию этой связки для управления роботом Lego Nxt. Достаточно вольный и немного укороченный перевод данного руководства я постараюсь привести здесь.

К сожалению, я сам в данный момент не могу себе позволить приобрести Wii Remote, чтобы проверить все, о чем сейчас напишу - на практике, хотя недавно видел этот прекрасный «девайс» в свободной продаже (отдельно от приставки), и обязательно куплю его позже, когда позволят финансовые возможности...

Помимо устройства WiiRemote, для создания описываемой программы, необходимо установить на Вашем компьютере .Net Framework, Microsoft Visual Studio, Microsoft Robotics Studio. Речь будет идти о программировании на C#, и подразумевается, что Вы уже имеете какие-то базовые знания о .Net и C#.

Итак, задача: совместить мощную среду разработки ПО для роботов - Microsoft Robotics Studio - с устройством Wii Remote (обычно его сокращают - до Wiimote).

Задача эта, на самом деле, уже решена на низком уровне совместимости. Так что драйвер мы писать не будем - ведь существует специальная библиотека для этих целей, Managed Library for Nintendo's Wiimote, которую можно свободно скачать с CodePlex.

Создание сервиса

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

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

Кроме того, веб-сервисы реализуют принцип создания "reusable" компонентов. Подробнее об этом можно почитать, например, в соответствующей статье на MSDN (по-английски).

Для создания заготовки для веб-сервиса, вам потребуется выполнить следующую команду (из командной строки, которая, кстати сказать, используется в MSRS очень часто):

dssnewservice /s:wiimoteNxt

Здесь параметр /s задает имя создаваемого сервиса.

Теперь перейдите в каталог (созданный при создании веб-сервиса) 'wiimoteNxt' в папке C:\Microsoft Robotics Studio (1.5)\ (или в другой, куда Вы установили MSRS 1.5). Откройте файл wiimoteNxt.sln (конечно, для этого у вас должна быть установлена среда разработки Visual Studio). Это и есть проект нашего веб-сервиса.

Добавление связей

Теперь, собственно, давайте добавим в проект связь с библиотекой WiimoteLib. Первая проблема, с которой придется столкнуться - это несовместимость версий, поскольку библиотека WiimoteLib была написана под использование с MSRS 1.0, а самая свежая версия - 1.5. Проблема решается просто, снова из командной строки:

dssProjectMigration "D:\wiimote\291133_WiimoteLib\WiimoteCS\WiimoteMSRS"

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

Теперь библиотека совместима с версией 1.5 Robotics Studio, и можно перекомпилировать ее: открываем файл Wiimote.sln из студии, жмем Build, и затем закрываем проект - больше он нам не потребуется.

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

В появившемся окне выбираем вкладку .NET и ищем «Wiimote.Y2007.M06.Proxy» (каждый раз при создании подобных связей - необходимо выбирать сервисы типа Proxy).

Также следует добавить ссылку на «RoboticsCommon.Proxy».

Наконец, для упрощения записи, в начало файла WiimoteNxt.cs потребуется добавить примерно такие директивы «using»:

using wiimote = WiimoteLib.Proxy;
using drive = Microsoft.Robotics.Services.Drive.Proxy;

Благодаря этим двум нехитрым строчкам, мы сможем обращаться к нашим библиотекам максимально просто, поскольку это - алиасы для namespace-ов (область имен, т.е. все имена идентификаторов уникальны в пределах одной такой области). Drive означает двигатель, через этот namespace мы будем обращаться к моторам; область имен wiimote, как нетрудно догадаться - отвечает за хранение классов для манипуляций с нашим одноименным чудо-пультом.

Подписка на оповещения Wiimote

Для того, чтобы управлять роботом с использованием Wiimote, естественно, нужно как-то получать входные данные. Механизм считывания данных прост и реализуется с помощью подписки на оповещения, которые рассылает библиотека WiimoteLib. Давайте попробуем подписать наш веб-сервис, который будет принимать оповещения библиотеки...

Прежде чем начать, следует учесть, что принятые оповещения нужно где-то хранить - для этого прекрасно подойдут существующий в Robotics Studio специальный класс объектов - «порт».

// порт Wiimote (со специальным атрибутом Partner)
[Partner("wiimote", Contract = wiimote.Contract.Identifier, CreationPolicy = PartnerCreationPolicy.UseExistingOrCreate)]
private wiimote.WiimoteOperations _wiiPort = new wiimote.WiimoteOperations();

// порт для оповещений
private wiimote.WiimoteOperations _wiiNotify = new wiimote.WiimoteOperations();

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

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

Об атрибутах можно почитать, например, на сайте GotDotNet.ru.

В данном случае с помощью атрибута мы просто указали, что создаваемый порт будет взаимодействовать с веб-сервисом wiimote.

Теперь у нас есть порты, давайте подпишемся на оповещения. Во-первых, в метод Start() после строчки base.Start() следует добавить вот такой код:

_wiiPort.Subscribe(_wiiNotify);

Это означает, что главный порт - _wiiPort - будет пересылать оповещения порту _wiiNotify. Чтобы активировать прием на порту _wiiNotify, добавим еще одну строку:

Activate(
    Arbiter.Receive(true,
                                            _wiiNotify, wiimoteChangedHandler));

wiimoteChangedHandler - это имя еще пока не созданного метода обработчика оповещений. Создадим его:

//wiimote notifications handler
void wiimoteChangedHandler(wiimote.WiimoteChanged wiimoteChanged)
{

}

Все, мы готовы приступить к созданию кода для управления моторами.

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

Обращение к моторам осуществляется, как вы помните, через область имен drive. По аналогии с тем, что мы делали для wiimote, создаем порт для управления моторами (для оповещений нам порт не нужен, т.к. наши простые моторы не имеют обратной связи):

// Точно также, создаем порт с атрибутом Partner
[Partner("drive", Contract = drive.Contract.Identifier, CreationPolicy = PartnerCreationPolicy.UseExistingOrCreate)]
private drive.DriveOperations _drivePort = new drive.DriveOperations();

Теперь вставим в обработчик оповещений от wiimote код для отсылки управляющих сигналов нашим моторам. Это достаточно просто:

void wiimoteChangedHandler(wiimote.WiimoteChanged wiimoteChanged)
{
    //для простоты дальнейшего горизонтального управления, меняем друг с другом X и Y
    float x = -wiimoteChanged.Body.AccelState.Y;
    float y = wiimoteChanged.Body.AccelState.X;

    //создаем управляющий сигнал для мотора
    drive.SetDrivePowerRequest request = new drive.SetDrivePowerRequest();
    //кстати, есть конструктор, который сразу же позволяет задать скорости, вот так:
    //drive.SetDrivePowerRequest request = new drive.SetDrivePowerRequest(leftSpeed, rightSpeed);
    // Здесь же мы зададим скорости вручную, вычислив их как разность координат:
    request.LeftWheelPower = y + x;
    request.RightWheelPower = y - x;
    //собственно, отсылаем наш управляющий сигнал!
    _drivePort.SetDrivePower(request);
}

Собственно, почти все.

Запускаем наш сервис

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

Файл манифеста можно указать следующим образом через командную строку:

dsshost -port:50000 -tcpport:50001 -manifest:"wiimoteNxt/wiimoteNxt.manifest.xml" -m:"samples/config/Lego.NXT.Tribot.manifest.xml"

Также можно указать файл манифеста в свойствах проекта - это может потребоваться при отладке:

Варианты командной строки для других роботов:

  • Lego NXT robot (Tribot или любой другой робот с двумя отдельно управляемыми моторами): "samples\config\LEGO.NXT.TriBot.manifest.xml"
  • Tribot - симуляция: "samples\config\LEGO.NXT.TriBot.simulation.manifest.xml"
  • BOE-Bot: "samples\config\Parallax.BoeBot.Drive.manifest.xml"
  • iRobot: "samples\config\iRobot.manifest.xml"
  • iRobot Create - симуляция: "samples\config\IRobot.Create.Simulation.xml"

Весь проект можно скачать с сайта Альберто Биетти.

воскресенье, 6 апреля 2008 г.

Программирование в Palm OS

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

Хороший обзор возможностей программирования в Palm OS представлен в статье «Операционная система PalmOS для программиста» на CitForum.

Ознакомительная статья по CodeWarrior имеется на Ладошках. Там же, в колонке справа внизу - еще много статей по Palm OS. Читаем!

Много хороших ссылок в данном направлении дано на OpenNet. В частности, оттуда узнал, что даже интерпретатор Perl пытались в свое время сделать для Palm OS. Я лично Perl обожаю - насколько это вообще можно сказать, Perl - мой любимый язык программирования. И с Linux/Unix системами знаком очень близко, однако в качестве десктопа предпочитаю все же Windows. Но, не будем отдаляться от темы...

Еще один очень полезный ресурс по Palm OS расположился на Исходниках. Что может быть лучше, нежели чем иметь перед глазами готовые примеры? Ничего! Правда, большинство представленных исходников написаны под PRC-tools (для Linux/Unix систем), но приспособить их решения под CodeWarrior - дело пяти минут. Помимо исходников, данный сайт предлагает такие очень полезные вещи, как, например, SDK для Palm-ов, Sony CLIE и др. устройств и компонентов, с которыми можно работать в Palm OS. SDK я себе скачал первым делом!

Вообще, о текущем прогрессе... Оказывается, все-таки стрелки в UML-диаграммах я расставлять правильно не умею :) В частности, использование («use») иежду классами должно быть направлено в прямо противоположную сторону. Так что, пришлось полчаса поразгребать сгенерированный на основе UML код, чтобы он скомпилировался...

Как Вы уже поняли, я занят собственно написанием кода. Есть успехи: написал весь пакет CommPort, немного кода уже есть и в RobotMain. Уже сейчас проект нормально компилируется, умеет опрашивать COM-порт, и т.д. В данный момент занимаюсь проработкой модуля DBConnect (сохранение и загрузка данных из PDB-файла). Времени все это занимает не очень много, но у меня много и нету - как всегда, работа и семья съедают это время очень проворно :)

Помимо кода, занимаюсь также подбором моторов для робота (на сегодняшний день наиболее перспективной считаю возможность применения шаговых двигателей от старых матричных принтеров, которых мне подарили аж целых 5 штук...), тестированием этих моторов, подготовкой редукторов, и т.п. Также занимаюсь механикой шасси - готова, в принципе, схема креплений лыж к телу робота, однако мне эта схема на сегодняшний момент не нравится - конструкция страдает «болтанкой». Так что, придется оси удлинять и сажать на подшипники. Позже расскажу в подробностях, и с фотографиями, в чем там дело.

И еще одна не слишком, конечно, приятная новость, состоит в том, что, судя по всему, RoboNews.info загнулся окончательно. Уже больше месяца сайт не рожает новостей, ну, что же делать... Я создателям сразу говорил, что на энтузиазме они долго не протянут.

Зато пришла заявка в каталог Robotics.Ru: Робототехника в России - просится туда сайт Roboto.Ru, на первый взгляд мне понравился, да и контент уникальный. Буду пытаться связаться с владельцами, договориться о сотрудничестве... :)

суббота, 23 февраля 2008 г.

Еще о Microsoft Robotics Studio

Не совсем прав был я, говоря, что хороших материалов по Robotics Studio в природе не существует.

Заполняя свой каталог робототехнических сайтов, обнаружил блог Евгения Марченкова, разработчика из Microsoft, и серию статей в нем - о Robotics Studio! Статьи достаточно занимательные, вот собственно ссылки:

Статьи были опубликованы еще летом прошлого года, так что почему я их не нашел раньше - остается большой загадкой. Впрочем, лучше поздно, чем никогда :)

среда, 6 февраля 2008 г.

Robotics Studio Maze Simulator

Продолжая тему Microsoft Robotics Studio, и ее симуляционной среды, нашел неплохой инструмент для редактирования мира той самой симуляционной среды - Microsoft Robotics Studio Maze Simulator.
Если вкратце - он может формировать местность симуляционного мира, принимая на вход обычный монохромный графический файлик. Вот что получается в итоге:

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

Более продвинутые пользователи Robotics Studio продолжают создавать своеобразные шедевры, например, вот оцените - виртуальный музей:

понедельник, 14 января 2008 г.

RoboRealm. Машинное зрение.

Для начала, хочу сообщить, что вот уже 6 дней мой сайт о том, как сделать робота, имеет ежесуточную посещаемость более 80 человек. За 14 дней января, общее количество уникальных посетителей превысило это же количество за весь ноябрь.

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

Таким людям очень рекомендую ознакомиться с парой рекомендаций от Маула. Ибо я человек терпимый, но кнопку «Пометить как спамера» никто не отменял...

Что же касается e-mail, иногда бывает, что отписываешься человеку, и не получаешь от него более ничего. Это, конечно, тоже не слишком приятно...

Но, хватит о грустном! Вот на затравку: не так давно раскопал один занимательный блог - dxdt.ru. Очень много интересного, на технические темы, причем, больше половины - про роботов.

И, наконец, к теме собственно сообщения. Совершенно случайно обнаружил программный комплекс, реализующий функции машинного зрения и управления роботами на основе распознанных образов - RoboRealm (официальный сайт - на английском).
Это тоже софт, тоже для создания роботов, тоже в основном для программирования роботов-конструкторов. Раз уж я писал про Robotics Studio, что очень близко, то считаю своим долгом закачать и исследовать также и RoboRealm.

Вот, например, видео, с демонстрацией того, что может RoboRealm:

Кстати, нашел немного информации о RoboRealm и на русском языке: на робофоруме и на отдельном сайте о RoboRealm.

Более подробно расскажу после того, как познакомлюсь с этой программкой поближе.

среда, 9 января 2008 г.

Microsoft Robotics Studio: первое знакомство

На сайте Microsoft информация о Robotics Studio очень поверхностна, а страничка на русском языке - вообще, изобилует неработоспособными ссылками (на сегодняшний день).
Полезный материал о Robotics Studio - мне удалось найти в виде видеозаписи 9го канала, где Павел Хижняк, один из разработчиков Robotics Studio, по-русски и очень доступно демонстрирует возможности Robotics Studio.
Видеозапись весит 69Мб, и доступна для скачивания на сайте GotDotNet.Ru - очень рекомендую ознакомиться, если, конечно, Ваш интернет-канал позволит это сделать.
Также, существует еще видеозапись + презентация в формате PowerPoint 2007 на сайте Платформа 2008, общим весом 8Мб, правда, информации там гораздо меньше...

В любом случае, надеюсь, не менее полезным будет мой собственный опыт знакомства и работы с Robotics Studio, изложенный ниже.

Для начала, проясним, что это вообще такое. Как не трудно догадаться, Microsoft Robotics Studio - это система, специально созданная для разработки программного обеспечения для роботов. Причем, в основном, для «конструкторов» роботов (т.е. заготовок из модулей, которые Вы можете собирать в домашних условиях и перепрограммировать на свой вкус) - таких как iRobot Create, LEGO Mindstorm, и т.д.

Инсталляционный пакет представляет из себя exe-файл, который весит всего 82Мб. Его можно преспокойно скачать с microsoft.com. Процесс установки прошел очень гладко. Замечу, что, желательно, кроме Robotics Studio установить еще .NET 2 и DirectX, иначе система будет работать не в полную силу. В частности, DirectX требуется для симуляционной 3D-среды, которую я подробно опишу позже.

Вообще, разработчики Robotics Studio - молодцы. Они правильно выделили современные проблемы роботостроения и пошли по пути популяризации этого прекрасного направления науки и техники. Теперь многие вещи, ранее доступные лишь профессиональным роботостроителям, отдающим робототехнике огромное количество личного времени - доступны даже любителям. А раз уж даже Microsoft активно ведет линию робототехники (вспомните еще, например, робота WiMo, о котором я писал в статье «Роботы и КПК»), то и уважаемым читателям рекомендую эту линию не оставлять!

Возвращаясь к нашим баранам: помимо того, что компоненты Robotics Studio прекрасно и автоматически интегрируются в среду разработки Visual Studio, этот продукт содержит два основных модуля, призванных помочь робототехникам-любителям, таким как я, например. Это модули - Visual Programming Language (VPL, визуальный язык программирования) и симуляционная среда.

Язык VPL обеспечивает возможность программирования роботов визуальными методами. Диаграммы VPL кодируются с помощью XML-схем и представляют, на мой взгляд, одну из очень немногих удачных попыток создания полностью визуального языка программирования. Конечно, базовые навыки алгоритмического мышления все равно потребуются, но зато совсем необязательно знать синтаксис C#, или, например, что такое анонимные делегаты. Согласитесь, это очень важный шаг! Ведь многие робототехники - очень посредственные программисты, и облегчить их труд - прекрасная идея.

Второй важный модуль Robotics Studio - симуляционная среда. Она реализует поистине классную идею, а именно - о том, что для программирования роботов Вам сами роботы, в принципе, и не нужны! Симуляционная среда является графической 3D-моделью, отображающей действия роботов, и объекты, которые роботов окружают. Например, если в модели присутствует шарик, то Вы можете подогнать робота к шарику и откатить этот шарик куда-нибудь. Физические моменты настолько глубоко продуманы, что становится возможным даже моделирование переворотов роботов, отрыва роботов от земли, столкновения объектов - все что угодно. Одним из примеров использования симуляционной среды является моделирование ринга сумо-роботов (которые стараются вытолкнуть друг друга за пределы ринга). Эта симуляция поставляется в виде аддона, который можно скачать там же, где и саму Robotics Studio.

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

VPL описывает в основном некоторые модули робота, и их связи друг с другом. Модулями робота могут быть разнообразные датчики (расстояния, касания, света и т.д.), веб-камера, устройство GPS-навигации (кстати говоря, производимое компанией Microsoft, что еще раз говорит о серьезности намерений мирового софтверного гиганта в отношении робототехники), моторы и сервоприводы, динамики, светодиоды, различные индикаторы, дисплеи и тому подобные устройства. Кроме того, модулями в Robotic Studio могут выступать специальные диалоговые окошки, например, для ручного дистанционного управления роботом.

Связи между модулями являются некоторыми алгоритмическими конструкциями, иногда со сложной структурой. Они могут включать разнообразные ветвления, условия, даже циклы, а также работу с данными, работу с переменными и т.д. Наиболее часто основанием для создания связи служит «нотификация» (оповещение о событии) в каком-либо из модулей датчиков. Обработка связей результируется в подаче напряжения на тот или иной двигатель, проигрывании звукового сообщения, световой сигнализации - в общем, все довольно стандартно и соответствует логике работы любого робота.

Здесь, кстати, возникает естественный вопрос: «Если связей и модулей много, то как же все это поместится на диаграмме?» Microsoft с легкостью решила этот вопрос, введя понятия Activity, так сказать составного действия, а проще - блока. Activity - это отдельная диаграмма, которая имеет «входы» и «выходы», и отображается на родительской диаграмме единственным элементом, с соответствующим количеством входных и выходных точек, к которым можно присоединять линии связей. Идея простая и логичная.

Применительно к VPL также обязательно необходимо сказать о манифестах. Манифесты - это своеобразные драйверы низкого уровня, или, с другой стороны - конфигурации той или иной программы VPL. Идея состоит в том, что одна и та же программа, в принципе, может выполняться на различных роботах, несмотря на то, что на низком уровне управление реализуется неодинаково. Благодаря манифестам, чтобы перенести программу VPL с одного железа робота на другое - нужно всего-то выбрать манифесты соответствующего робота для основных модулей диаграммы. Тем же самым образом - с помощью специальных «Simulation»-манифестов - реализуется перенос программы в среду симуляции. Несколько манифестов - для наиболее популярных существующих конструкторов роботов - присутствует в базовой поставке Robotic Studio. Также есть все возможности для создания собственных манифестов.

Перейдем, наконец, к примерам. В качестве задачи я выбрал создание простейшего робота, способного объезжать препятствия. У этого робота - два датчика касания, и два мотора: мотор поворота и мотор движения. Этого же самого робота я описывал в своей статье о RoboML.

Давайте попробуем запрограммировать такого робота с помощью Microsoft Robotics Studio, и запустить его симуляцию в какой-нибудь подходящей симуляционной среде.

Открываем среду VPL, видим слева список модулей робота. Добавляем на диаграмму два модуля GenericMotor, один модуль GenericContactSensors и один модуль Timer - он потребуется для реализации отъезда назад на небольшое расстояние при объезде препятствий.

Теперь нам нужно определиться, что будет происходить при смене показаний датчиков. Для этого добавляем модуль условия (if-then-else) на диаграмму, и создаем нотификацию на Replace от датчиков касания. Нотификация (оповещение о событии) создается очень просто. На любом модуле в диаграмме есть квадратики слева, и кружочек с квадратиком - справа. Это своеобразные входы и выходы данного модуля (выход для события обозначается кружочком). Если перетащить выход одного модуля ко входу другого, между ними образуется связь.

Уточню еще один неочевидный момент - содержимое блока if-then-else. Здесь Вам очень помогут раскрывающиеся списки с подсказками, которые появляются при попытке набрать что-либо в поле условия. У меня условий было два, и записывались они так: Sensors[0].Pressed и Sensors[1].Pressed. Иными словами, сработал ли первый датчик (левый), или второй (правый). Количество датчиков и соответствие номеров датчиков их положению - определяется в зависимости от выбранного манифеста, для робота, которого мы будем использовать.

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

Итоговый вид диаграммы:

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

Но зато, я бросил взгляд на «внутренности» получившейся диаграммы. Это, конечно же, XML-файл. Было очень интересно сравнить практический и работающий XML для описания роботов от Microsoft - с теоретическим и не имеющим практических реализаций RoboML.
Представляю фрагмент XML-кода от Microsoft:

<Connections>
  <Connection>
    <Name>link</Name> 
    <To>program.activity.Start.__use__0.snippet.snippet.join.TargetPower.sink</To> 
    <From>program.activity.Start.__use__0.snippet.snippet.expr.source</From> 
  </Connection>
  <Connection>
    <Name>link0</Name> 
    <To>program.activity.Start.__use__0.snippet.snippet.expr.sink</To> 
    <From>program.activity.Start.__use__0.snippet.snippet.noop.source</From> 
  </Connection>
</Connections>

Здесь представлено всего лишь описание двух связей...

Мусора, конечно, гораздо больше, чем в RoboML. Но в практических реализациях - без этого никуда. Судите сами, компиляторы, какими бы они ни были оптимизирующими, генерируют неоптимальный код. На ассемблере я бы написал намного более практичное со всех точек зрения решение для практически любой задачи. Но на ассемблере писать долго - а на языке программирования высокого уровня - быстро.

Анализируя XML, я понял, что сравнивать RoboML и Microsoft Robotics Studio XML сложно, поскольку они описывают, в принципе, одно и то же - но с разных сторон. XML от Microsoft гораздо более практичен, приближен к деталям, к реализации. И весьма ограничен - вся диаграмма записывается в виде заранее жестко предопределенных блоков (их можно создавать самостоятельно, но исключительно). В то же время, RoboML - абстрактен, даже роботов он описывает не алгоритмическими конструкциями (например if-then-else), а математическим языком.

Подводя итог первого знакомства с Robotics Studio, признаю, что мне, честно сказать, идея Microsoft очень сильно импонирует. Давно пора было создать специализированную среду разработки для роботов, надеюсь, это упростит задачу многим любителям робототехники в воплощении их проектов.

Продолжение следует...

среда, 26 декабря 2007 г.

Меня полюбил Гугель

Во-первых, хочется сказать, чем я занимался все это время... А занимался я, помимо подготовки к праздникам, еще и написанием очередной статьи, которую наконец-то закончил и выложил на основной сайт - читаем: «Алгоритм поиска пути для роботов». Вкратце: описано, как реализовать алгоритм поиска пути по заранее известной карте местности (квартиры, дома). Приведены особенности использования алгоритма в робототехнике. Рассмотрен пример работающей программы, выложена сама программа и ее исходные коды.

Кстати, работаю над созданием еще одной статьи, про Robotics Studio - никак не могу дописать, из-за этой предновогодней суеты...

Но это все собственно не совсем то, о чем я хотел написать это сообщение!
Все дело в том, открою вам секрет, что меня (а точнее мой сайт про то, как сделать робота) полюбил Google!

Во-первых, после произведенных исправлений и их переиндексации, значительно улучшились позиции моего сайта по требуемым запросам. Восстановилась посещаемость - до 55-75 человек в сутки. Общее количество посетителей давно обогнало прошлый месяц, и сейчас перевалило за 1300 уникальных человек. И самое главное - буквально недавно сайт вылез на пятое место и на Google.Ru, и на Google.Com - по запросу робот(!).

Лично мое мнение о причинах такой любви - очень простое. Google любит Blogger, а у меня на Blogger'e - этот блог, в котором почти в каждом посте есть ссылки на основной сайт. Кстати, сам блог я сегодня обнаружил на второй странице по запросу робототехника, плюс к тому, он еще на первом месте, например, по запросам робот кпк и блог робототехника, и в топе по некоторым другим запросам, например, секс с роботами и блог роботы. Думаю и дальше стараться захватывать с помощью блога максимум низкочастотных запросов, что будет для уважаемых читателей, безусловно, весьма полезно - так как появится множество новых статей.

Что касается Яндекса - Яндекс любит ya.ru. Из всех зеркал этого блога, несмотря на то, что в каждом таком зеркале есть ссылки на оригинал сообщения - тем не менее, в поиске Яндекс показывает insiderobot.ya.ru - и чаще, и выше, чем любые другие зеркала или этот блог.

Кстати о зеркалах. RSS-зеркала - это, конечно, хорошо, но есть некоторые тонкости. Например, если Вы не дай бог измените какое-то свое сообщение уже после публикации - оно сдублируется на зеркале и его придется удалять. Например, в feedburner-е я добавил опцию, которая позволяет к каждому сообщению присоединять некоторую подпись, и в этой подписи вбил ссылку на свой сайт. Что ж Вы думаете? Правильно! На зеркала все записи сдублировались, датировались неправильно, вдобавок - пришли как-то вразнобой. С программной точки зрения это вполне логично, хотя если немного подумать головой, вполне можно придумать более интересный алгоритм... В общем, я уже давно никому не рекомендую менять свои публикации после того, как они уже попали на зеркала.

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

Это, безусловно, дало хорошие результаты, например, запрос как сделать робота в Яндексе выдавил мой сайт на первое место, да и в Google - уже в топе (google.ru - 4, google.com - 5), но гугл, он ведь всегда медленнее меняет место сайта...

Но самое интересное заключается вот в чем:
Я совершенно случайно заглянул в старый запрос создание робота, и с превеликим удивлением обнаружил свой сайт, уже обновленный - без слова «создание» в заголовке, - на первом месте в Яндексе и Google.com(!), и на третьем месте - на Google.ru. При этом вообще слово «создание» встречается в тексте первой страницы 2 раза, анкоров с этим словом - отсилы 2-3 штуки...

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