вторник, 29 апреля 2008 г.

Новости о роботах

Этот выпуск серии «Интернет о роботах» хочется посвятить, прежде всего, сайту Roboto.Ru.

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

Вообще, уже был такой сайт. Это проект, в котором и я принимал участие - Robonews.info, но он, к сожалению, загнулся. Не хватило у его создателей энтузиазма... Жаль, очень жаль! Но - есть в интернете новая кровь. Почти каждую неделю, а иногда - и каждый день, - появляются в поисковках новые, интересные сайты. Некоторые из них проходят мои очень серьезные фильтры, и попадают в каталог «Robotics.Ru. Робототехника в России», который я веду, а заодно - мне на заметку. Roboto.Ru - один из таких сайтов.

Создатель Roboto.Ru, молодой человек по имени Михаил, планирует также поддерживать на базе своего сайта хороший робототехнический форум. Пока что форум не слишком популярен - ведь сайт появился совсем недавно - но он весьма удобен. А грамотная подборка новостей - вполне может привлечь на этот форум знающих людей. Ведь на самом деле, ныне наиболее популярный форум по робототехнике, Roboforum.Ru - был зарегистрирован всего лишь 4 года назад! Когда я делал своего первого самодельного робота (вроде бы, совсем недавно) - форум РобоКлуба был единственным серьезным форумом по робототехнике в Рунете... Интерес к робототехнике растет с каждым годом, и конкуренция между несколькими тематическими форумами - это совсем неплохо.

Что касается новостной части сайта, на Roboto.Ru собраны не только переводные англоязычные материалы, хотя их, конечно, большинство. Лично мне очень интересны достижения - пусть и скромные! - отечественных робототехников. Например, помните, я тут недавно обсуждал шасси шаробота? Михаил нашел другой материал по этой теме: Шаробот - удачный дебют студентов из Ижевска. И еще одна очень интересная статья, которую я не могу обойти своим вниманием - История робота ASIMO. Очень интересно было посмотреть на историю развития очень серьезной японской разработки, и на много хороших мыслей она меня натолкнула. Надеюсь, в ближайшем будущем разместить здесь навеянный данной статьей материал...

Напоследок, хочется заметить, что новостных робототехнических сайтов - огромное множество. Но почти все из них - просто перепечатывают материалы из более мощных новостных источников - с сайтов membrana.ru, cnews.ru, ixbt.ru и т.д. Поэтому лично я очень ценю новостные сайты, которые занимаются сбором новостей самостоятельно, перерабатывают или хотя бы переводят эти новости, готовят на их основе уникальные статьи. Сделать Copy-Past - занятие двухминутное. А изложить собственный взгляд на вещи - многим просто не под силу!

пятница, 25 апреля 2008 г.

И снова: необычные роботы

Помните, я писал про пчел-киборгов? Не так давно обнаружил интересную статью на сайте 3D News - Робот-муха готовится стать разведчиком. В принципе, суть та же, с киборгами даже попроще будет (как мне кажется). Тот же микро-девайс, летающий, с функцией подглядывания... Но суть даже не в этом! Самое интересное - это то, что мы снова обнаруживаем интерес от DARPA. Похоже, DARPA взялось очень серьезно за тему миниатюрных разведчиков. Очень может быть, где-то в военных лабораториях США такие микро-шпионы уже вполне дееспособны...

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

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

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

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

Еще одну ссылку, на очень красивых роботов-медуз - подсказал Александр aka Fric Geger, за что ему, собственно, "+1" :)

четверг, 24 апреля 2008 г.

Определение. Что такое робот

Вот какое определение можно найти на сайте Wikipedia: Робот (от чешск. robota) — электромеханическое, пневматическое, гидравлическое устройство или их комбинация, предназначенное для замены человека в промышленности, опасных средах и др. Принятый сейчас во всём мире термин был изобретён чешским писателем Карелом Чапеком и его братом Йозефом и впервые использован в пьесе Чапека «Р.У.Р.» («Россумские универсальные роботы», 1921). До появления настоящих роботов считалось само собой разумеющимся, что роботы будут похожи на людей. Промышленные роботы никогда не бывают похожи на людей, если при проектировании это не ставилось в качестве главной задачи.

Это что, определение?! Бред, а не определение. Как можно в определении вообще писать "и т.д."? Ни один формальный документ не допускает использования этой конструкции... Обрезав частности, можно сказать, что "робот - это устройство, предназначенное для замены человека". Но под это определение подходит даже кухонный комбайн, поэтому смысла в таком определении - ровно ноль.

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

В основном это:

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

Очень важной характеристикой таких роботов является наличие механической части.

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

Путаница в определениях была всегда и всегда есть. Но я не думаю что из-за этого нужно разводить панику. Определения - это дело чиновников, бюрократов, юристов... Мы - люди. Мы и так знаем, интуитивно, что есть что. Мы с вами прекрасно знаем, что такое хорошо и что такое плохо - ни один свод законов этого не может определить всеобъемлюще... А знаете ли вы, что например ни один словарь в мире - не дал еще точного определения обычному слову "информация"? Говорят - информация это данные. Смотрим определение слова данные? - правильно, внаглую пишут: данные - это информация. Почитайте любой словарь! Мне об этом впервые сказал профессор, доктор технических наук, заведующий кафедрой Вычислительной Техники нашего университета... Я даже не поленился проверить.

В общем, определения - это ограниченность. Это - тупик. Не советую в него залезать :)

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

Саморепликация. Роботы, которые сами себя воспроизводят

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

Проектов по созданию самореплицирующихся роботов - сколько угодно. Не так давно Интернет отгремел сообщениями о роботе Lego, который научился собирать из готовых деталей себе подобных. Еще один интересный шаг в этом направлении - сделала интернациональная команда проекта RepRap (лидер и основатель проекта - Адриан Боуэр - родом из Великобритании). RepRap (REPlicating RAPid prototyper) - это проект по созданию машины (станка), которая бы могла воспроизводить себя, а также делать другие какие-то машины. Причем, все это должно быть максимально дешево :)

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

Более того, проект простой. И в определенной степени успешный. На сегодняшний день RepRap умеет изготавливать полный комплект деталей для собственного воспроизводства (правда, собирать их пока не умеет). Принцип действия основан на технологии принтеров, или координатных станков (что в определенной степени одно и то же на самом деле). Более подробно читайте здесь: http://reprap.org/bin/view/Main/WebHome.

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

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

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

Недорогие запчасти

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

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

    Стоимость машинки - немаленькая, около 5 тыс. рублей. Однако и сама она достаточно большая, примерно 1.2м длиной, и 35-40 см шириной - т.е., вполне достаточна для изготовления робота даже на основе не самого легкого ноутбука...
  3. Изготовление дубликатов шестерней - прекрасный способ изготовления шестерней. Шестерни всегда очень часто требуются, и обычно в контексте их дублирования. Ведь всегда очень сложно найти два одинаковых редуктора. А так, потратив около 100 рублей, мы получаем материала на несколько десятков шестерней, которые могут быть отлиты по любым образцам.
  4. Где взять моторы? Это очень частый вопрос, возникающий при проектировании ходовой части робота. Изготовление редукторов вроде бы достаточно решаемая проблема (благодаря ссылке в предыдущем пункте), а вот где взять моторы - вопрос пока не решенный. Впрочем, все не так уж и плохо! Традиционный метод получения моторов - выламывание их откуда-нибудь. Сейчас наиболее популярны три способа: а) моторчики из игрушечных моделек; б) моторы из автомобиля (от стеклоподъемников, стеклоочистителей, регуляторов фар и т.п.); в) шаговые моторы из принтеров.

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

Несколько из перечисленных выше ссылок указывает на РобоФорум. Это активный форум робототехников России, если Вы увлекаетесь роботами - очень рекомендую этот форум посетить. Там можно найти много интересных и уникальных практических решений. Одним из перспективнейших направлений работы ребят является создание Wiki по материалам форума. Это очень важное и хорошее начинание, т.к. темы форума все таки сами по себе мало структурированы, а wiki эту ситуацию, бесспорно, исправит.

суббота, 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"

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

пятница, 18 апреля 2008 г.

Космический бюджет

Вот, бывают же радости в жизни. Сегодня у меня родился племянник :)...

А если по теме, то хочется привести краткую подборку ссылок, наталкивающую на некоторые мысли - в отношении бюджетирования космических программ в России.

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

Ни для кого не секрет, что космический бюджет у России - сравнительно крохотный. Он меньше аналогичного бюджета США в 20-25 раз (!). Например, в 2008 году на основную графу космического бюджета - «Исследование и использование космического пространства», запланировано выделить 10,7 миллиардов рублей. Правда, РосКосмос получает деньги обычно не только через эту графу, и в среднем общая сумма получается примерно в два раза больше. Но даже 20 миллиардов рублей - это очень мало.

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

Чтобы понять, насколько ничтожна эта сумма, следует прежде всего обратить внимание на задачи Федерального Космического Агентства. Это и обучение космонавтов, и запуски в космос спутников, и изготовление этих спутников, и исследования в области космических технологий. Полный перечень этих задач, достаточно конкретный, можно найти на сайте РосКосмоса.

Интересно почитать:

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

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

День космонавтики

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

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

Впрочем, США преуспели в космосе намного больше. Причина? Думаю, очень простая: они богаче :) И - осторожнее. Наверное, именно поэтому именно их марсоходы до сих пор бороздят просторы Красной Планеты. Кстати! Совсем скоро, в мае этого года (25го мая, если точнее), очередной их марсоход достигнет Марса. Это Phoenix Mars Lander - он призван исследовать полярные области Марса. Пару дней назад господа из NASA как раз корректировали его курс. Целятся ученые в самое крупное скопление льда в северной полярной шапке Марса.

Еще одна новость - состоит в том, что выложили наконец-то цветные фотографии Фобоса, крупнейшего естественного спутника Марса (впрочем, в диаметре он имеет всего лишь 22 км), в высоком разрешении, сделанные аппаратом Mars Reconnaisance Orbiter с расстояния 6800 км от него.

Что касается Луны, не так давно - около месяца назад - потратил наверное около 3х дней, чтобы полностью, с увлечением, прочесть книгу (на самом деле это серия статей) под названием «Лунная афера», от главного редактора газеты «Дуэль» Юрия Игнатьевича Мухина. Никак до конца не мог принять ничью сторону, но склоняюсь, впрочем, к мысли, что все-таки американцы на Луну летали. Советую почитать, очень уж интересные и подробные разгорелись дебаты... Скачать книгу «Лунная афера» в текстовом представлении, запакованную, можно с моего сайта (zip-архив, ~300кб).

Кстати, вот еще любопытное - карта передвижения астронавтов Апполона-11 по Луне - наложенная на футбольное поле :) (взято отсюда):

Что еще интересного можно сказать в День Космонавтики 2008 года? Вообще говоря, об этом дне очень много пишут. Самое интересное:

четверг, 10 апреля 2008 г.

Робот-повар готовит пищу

А на работе все загруженнее и загруженнее! Прям-таки не знаю что и предпринять :( И если в блог еще иногда написать удается, то уж роботом совершенно некогда заняться. К тому же, болею, и особого здоровья на это тоже нет.

Вчера беседовали с одним молодым человеком по имени Александр (ака Alf) в ICQ по поводу его идеи создания робота для приготовления пищи... Этакого робота-повара :) Беседа получилась, как ни странно, весьма интересная, и вкратце хочу озвучить ее итоги здесь.

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

  1. Хранилище для яиц, либо приспособление, которое позволяло бы достать яйцо из холодильника.
  2. Наклонный желоб или туннель (трубка), для доставки яйца к сковородке.
  3. Устройство для разбиения яйца.
  4. Устройство для освобождения внутренностей яйца от скорлупы.
  5. Приспособление для утилизации скорлупы.
  6. Механизм для включения/выключения/регулировки силы нагрева кухонной плиты.
  7. Датчик контроля: света/дыма/тепла - для подачи экстренного сигнала или/и самостоятельного выключения плиты.
  8. Устройство для подачи подсолнечного масла и его хранилище.
  9. .

На взгляд - сложновато. Однако, рассмотрим каждый пункт подробно.

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

Желоб (или трубка) также нужен наклонный, заканчивающийся около воронки.

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

По задумке, скорлупа должна остаться в воронке, а яйцо - вытечь на сковородку.

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

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

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

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

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

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

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

А вот видео робота, который готовит шарики из осьминога (само блюдо конечно отвратительно, но робот зато оправдывает все надежды):

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

Проекты и идеи по робототехнике

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

Александр (aka Fric Geger) делает систему 3D-моделирования для тестирования роботов, наподобие Microsoft Robotics Studio Simulation Environment, а также разрабатывает язык описания для этой среды. Все это делается в рамках дипломного проекта. В качестве основы для языка описания взят RoboML. К этому языку будут добавлены средства для описания физики мира и для описания поведения робота. Насчет физики все, в принципе, понятно. Масса, материал, специальные типы объектов (оси, пружины и т.п.) - и задача решена. Намного сложнее решить вопрос с программным поведением. Для этого Александр планирует создать специальный скриптовый язык.

Павел (aka sypper-pit) работает системным администратором, и ему пришла мысль создания робота, который мог бы частично заменить его в серверной: перезагрузить сервер, посмотреть на причину ошибки. В принципе, задача эта решается и другим способом: к кнопкам Reset подводим проводные выключатели, которые подключаем к LPT-порту отдельного старенького компьютера, который в свою очередь соединяется с интернетом через а) резервный канал б) линию от миниАТС (для экстренного dial-up подключения). Плюс к тому же компу прикручиваем веб-камеру, которая смотрит на экран KVM. Ну и наконец, реализовать электронное переключение KVM... На этом, в общих чертах, задача решена. Но робот, безусловно - намного интереснее, хотя и сложнее. Ведь необходимо предусмотреть не только мобильность робота, но еще и наличие у него хотя бы простейшего манипулятора, ну и камеры - естественно...

Леонид Иванов решил использовать дисплей мобильного телефона в качестве информационного дисплея, и подключить его - к обычной видеокарточке. Подключение к компьютеру LCD от старенького Sony Ericsson через LPT-порт описано например на сайте «Rifer» (там же есть ПО). Вот обсуждение на форуме по этой же теме. Почитать очень интересно.
Конечно, можно совсем не подключать LCD к роботу, по большому счету оно редко когда пригодится. Для управления и тестирования, в частности, можно использовать следующую систему:

  • Вставляем карточку Wi-Fi в нашу материнку
  • Размещаем точку доступа в помещении с роботом
  • Соединяем точку доступа со стационарным компьютером или ноутбуком
  • Используем со стационарного компьютера средства удаленного управления по сети - это может быть Radmin, DameWare или просто терминальный доступ (штатная утилита Windows mstsc.exe - "Подключение к удаленному рабочему столу").

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

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

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

воскресенье, 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, на первый взгляд мне понравился, да и контент уникальный. Буду пытаться связаться с владельцами, договориться о сотрудничестве... :)

вторник, 1 апреля 2008 г.

Проектирование робота. Диаграмма классов

В рамках серии статей «Изготовление аналога марсохода ПрОП-М».

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

  • Диаграммы прецедентов
  • Диаграммы состояний
  • Диаграммы развертывания

Вкратце пройдусь по процессу проектирования:

Общий принцип - начинаем НЕ снизу!!, а «сверху». А там, наверху, у нас один единственный класс, с одним единственным экземпляром - это сам по себе Robot (буду называть его объект Robot). Само собой, здесь должна быть инициализация и финализация - пусть это будут процедуры Initialize() и Finalize(). Также этот объект (исходя из псевдооднозадачной модели Palm) обязательно должен содержать в себе метод, реализующий главный цикл программы. Так его и назовем: MainLoop(). В этом цикле программа должна опрашивать датчики, управлять моторами, принимать команды управления. Кроме того, одним из важнейших свойств робота будет являться его состояние (свойство State). А любая система, поведение которой основано на принципе перехода между состояниями (механизм конечных автоматов, подробно я описывал их в своей статье «Роботы и искусственный интеллект»), должна содержать метод перехода в следующее состояние, в зависимости от текущего состояния и состояния внешней среды. Назовем этот метод SwitchState().

Для хранения правил перехода между состояниями, сведений о самих состояниях, а также информации о смене состояний (лог) - можно использовать базу данных. Удобно создать интерфейсы к каждой таблице нашей БД в виде отдельной связки класс + коллекция. Таким образом, получаем следующие классы "данных" (исходя из требуемых функций системы):

  1. State + StateCollection - описания состояний (в основном используется только для отображения лога)
  2. ExternalEvent + ExternalEventCollection - описания внешних событий, из-за которых может быть инициирован переход между состояниями.
  3. StateLink + StateLinkCollection - связи между состояниями (правила перехода)
  4. StateChange + StateChangeCollection - лог состояний

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

Каждый из перечисленных классов будет содержать свойства, дублирующие поля соответствующей таблицы данных (т.о. класс=строка таблицы). Коллекция будет описывать все строки таблицы. Также, коллекция должна содержать методы для заполнения себя данными из БД, для загрузки этих данных обратно в БД, и для обработки этих данных - например, поиска нужной строки по какому-либо из полей.

Для порядка, все классы для связи с базой данных поместим в отдельный пакет - DB, и проставим связи между классами, вот что получилось у меня:

Кстати, еще одну связку коллекция + класс можно создать для хранения настроек программы, но это необязательно...

В объекте Robot целесообразно разместить экземпляры всех трех описанных коллекций для быстрого доступа к ним.

Как я уже упомянул, объект верхнего уровня Robot взаимодействует в основном с датчиками и двигательной системой. Также необходимо предусмотреть связь с устройством управления (в данном случае под устройством управления я понимаю графический интерфейс Palm-приложения), имеющую право на жизнь ради тонкой быстрой настройки и тестирования.

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

Модель взаимодействия с этими классами с точки зрения объекта Robot достаточно примитивна - каждый внешний класс имеет свойство State; Robot вызывает метод Work() каждого из классов, тот по определенным правилам изменяет свое свойство State, и далее Robot использует это свойство как один из факторов, влияющих на изменение его собственного свойства State...

Экземпляры классов объявлены внутри объекта Robot. Нетрудно догадаться, что каждый из описываемых классов использует тот же самый механизм конечных автоматов, и те же самые вспомогательные классы для работы с DB.

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

Согласно требованиям диаграммы прецедентов, двигательная система должна выполнять следующие основные функции (в скобках приведены названия соответствующих методов):

  • Движение на заданное число шагов вперед (GoForward)
  • Движение на заданное число шагов назад (GoBackward)
  • Поворот на заданный угол (Turn)
  • Поворот на заданный угол и движение вперед (TurnAndGoForward)
  • Поворот на заданный угол и движение назад (TurnAndGoBackward)
  • Остановка

Внутри класса двигательной системы есть два объекта класса Motor - и все управление происходит с помощью этих объектов. Они, кстати, тоже имеют собственное состояние (State)... Классы Motor и Sensor оба описывают внешние устройства, поэтому наследуют от абстрактного класса ExternalDevice. Единственным свойством этого класса является ExternalID - идентификатор внешнего устройства, которым управляет конкретный класс. Для реализации связи с последовательным портом имеется еще два класса - высокоуровневый (CommDispatcher) и низкоуровневый (CommDriver).

Итоговая диаграмма:

Пакет RobotMain:

Пакет CommPort:

В общем-то, на этом работа закончена. Осталось лишь упомянуть, что я использовал для разработки диаграммы инструмент Enterprise Architect 7.0 от компании Sparx Systems, и этот неплохой в принципе инструмент (30-тидневная версия доступна бесплатно) позволяет, как, впрочем, и другие среды разработки UML, генерировать заготовку кода согласно представленной диаграммы классов. Получается вот такой симпатичный списочек файлов:

А это, собственно, означает, что скоро, очень скоро, по-тихоньку будет появляться и собственно код!

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