Как и сообщалось, EVO 4G получат официальное обновление до Froyo 3 августа. Поэтому, если у вас на руках этот девайс можете проверять обновление уже сейчас. Для заметки, если вы уже получили обновление, о котором раньше сообщали HTC, то компания сейчас работает над доработками.
Поэтому не стоит расстраиваться, у вас еще есть возможность получить новое обновление.
Источник: [...]

28 мая 2010 – Компания Mio, ведущий поставщик персональных GPS-систем, представляет готовое картографическое решение – карты Европы на носителе MicroSD™ для навигационных систем серии Mio Moov S.
Лето – долгожданный сезон отпусков. Кто-то приобретает путевки на морские пляжи или заснеженные горные вершины и летит самолетом в вожделенный рай, а кто-то не ищет легких путей и [...]

Продолжаю серию статей про 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, однако эта статья потребовала настолько глобальной переделки, что я ее полностью переписал, полностью сам разобрался в коде, адаптировал его под стандартную сумо-арену, ну и т.д. Очень надеюсь, что следующую статью Дмитрия я смогу выложить в менее «отредактированном» варианте

На написание данного поста меня сподвигла очень любопытная статейка на 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)	Нет	Нет
Система реального времени	Нет	Нет	Нет	Нет	Да