понедельник, 29 ноября 2010 г.

Lego механизмы: балансирующий мотоцикл




Наверное, многие глядя на колеса из набора Lego Mindstorms (особенно 1.0) подумывали: "Хм... А что было бы неплохо собрать что-то типа мотоцикла". И самое интересное, что многие собирали. Кто с двигателями, кто без. И лишь действительно упорные заставляли его двигаться.
А как вам идея, чтобы мотоцикл не только двигался на двух колесах, но и удерживал самостоятельно равновесие?
И в этом нет ничего невозможного!



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

NXT-G: плавное движение робота

Данный материал является продолжением советов по использованию блоков Move и Motor, а также является трансформированным переводом недавно опубликовонной статьи на legoleaguecoaching.org.

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

Lego механизмы: электронный кодовый замок

Если у вас есть секреты, можете попробовать доверить их хранение Lego Mindstorms роботу.

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



Сам сайт electricbricks.com интересен также тем, что авторы пишут каждую статью сразу на двух языках: на родном испанском и международном английском.

суббота, 27 ноября 2010 г.

Lego Mindstorms в стратосфере

А вы знаете, что в честь 10-летия с начала продаж Lego Mindstorms в 2008 году, группы энтузиастов, студентов и школьников разных стран запускали исследовательские лаборатории на основе Lego Mindstorms в стратосферу.

Проект назывался H.A.L.E. - High Altitude LEGO Extravaganza. В нем приняли участие команды из США, Тайваня, Люксембурга, Швеции и Дании.
В итоге, 9 капсул запускались на двух метеологических зондах. Оба зонда, достигнув высоты примерно в 30 км., лопнули, после чего капсулы благополучно достигли земли на парашюте.
Помимо фото и видео съемки, капсулы выполняли с помощью Lego Mindstorms такие исследования как анализ загрязнения воздуха, измерения сил притяжения и содержания озона, изучали влияние факторов, меняющихся во время полета, на зефир и т.п.
Хочется порадоваться за ребят, что им предоставилась возможность поучаствовать в уникальном эксперименте. А так же хочеться надеяться, что подобные исследования будут происходить регулярно.
Сейчас же нам оставлена возможность поучаствовать в эксперименте виртуально:

Или даже поднявшись на максимальную высоту вместе с проектом H.A.L.E. (за секунды до разрушения метеозондов) посмотреть, как выглядит наша планета оттуда:

пятница, 26 ноября 2010 г.

Автоматизированное поле для игры в Робо-футбол.

Взято с thenxtstep.blogspot.com.

Mario Ferrari и Daniele Benedettelli объединили свои усилия и создали на основе Lego Mindstorms NXT полностью автоматизированное поле для игры в Робо-футбол. Он само ведет учет забитых голов и разыгрывает мячик.

Кстати, на этом поле они продемонстировали замечательных роботов, которые довольно сильно играют в футбол.

Алгоритмы: движение вдоль стены

Не правда ли программа, заданная в качестве задачки на понимание NXT-G в этом посте, похожа на программы, поясняющие движение вдоль линии, в этом?




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

Если быть более точным, то в задаче робот поворачивает вправо, если расстояние на сенсоре меньше 14 см. и влево, если расстояние на сенсоре больше 16 см. Сложно представить, для чего может понадобиться такое движение, если сенсор смотрит вперед или назад. Но многое встает на свои места, если предположить, что сенсор установлен на одном из бортов робота и смотрит в сторону.



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



Кстати, этот вариант ответа (движение вдоль стены) тоже был среди ответов, которые были присланы после публикации задачи.

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

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

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

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

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

Решение этой проблемы, традиционно, не одно. Оно может быть как программным, так и конструкторским. Например, можно не фиксировать датчик жестко, а поставить его на мотор.

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


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

Фестиваль робототехники СФУ

Сибирский Федеральный Университет организовывает Фестиваль робототехники. Помимо научно-технической выставки и конференции в программе фестиваля анонсированы состязания Lego-роботов.


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

Следует отметить, что задания для состязаний очень интересные, с ними можно ознакомиться здесь и здесь.

среда, 24 ноября 2010 г.

Как роботы играют в футбол?

Известно, что одним из состязаний на Международной Робототехнической Олимпиаде 2010 был Робо-футбол.




Лего-преподаватель Graeme Faulkner помогал одной из школ готовиться к данному состязанию. В итоге он решил поделиться с интернет-сообществом своими мыслями, относительно того, как можно запрограммировать робота для участия в данном виде спорта: Fun with Robot Soccer (на английском).
Он умышленно не выкладывает подробных инструкций относительно конструкции и конечной программы - он оставляет за вами финальное решение.

понедельник, 22 ноября 2010 г.

Стартанули занятия в лицее №82

После проведенной презентации в 82ом лицее, меньше, чем за месяц набралось почти два десятка желающих изучать робототехнику вместе с Lego Mindstorms NXT.

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

Lego механизмы: дельта-роботы

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



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



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

воскресенье, 21 ноября 2010 г.

Международная робототехническая олимпиада 2010

Многие, кто интересуется состязаниями Лего-роботов, знают, что в этом году 5-7 ноября в Филиппинах проходила World Robotics Olympiad 2010.

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

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

Вот некоторые из них:



Также на оффициальном сайте олимпиады доступны списки победителей (если у кого, список недоступен, можно попробовать также по этой ссылке)

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

Место Младшая группа Средняя группа Старшая группа
1 Корея Малазия Тайланд
2 Филиппины Малазия Тайвань
3 Тайвань Тайланд Индия
4 Малазия Китай Индия
5 Филиппины Тайвань Китай
6 Россия Тайвань Перу
7 Тайвань Филиппины Япония
8 Тайвань Филиппины Япония

Из таблицы видно, что наиболее успешно выступили команды из Малазии, Тайваня и Тайланда.

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

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

Тем же кого тема Международных робототехнических олимпиад заинтересовала могут в этом году уже начать готовиться - все, что для этого нужно: желание победить, конструктор Lego Mindstorms NXT и светлая голова.

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

Также вы можете найти много интересных роликов о роботах, участвовавших в международных олимпиадах, если зайдете на сайт YouTube и наберете слово "wro"

Алгоритмы: черно-белое движение

Сенсор освещенности (или цветовой сенсор) из набора Lego Mindstorms NXT, один из наиболее используемых сенсоров при конструировании и программировании Lego-роботов.

По внутреннему устройству, он не такой сложный как сенсор расстояния. Основным элементом в нем является светочувствительный элемент (фоторезистор или фототранзистор).

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

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

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


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


Перед началом программирования, необходимо провести калибровку сенсора освещенности. После чего, измерить, что показывает сенсор на разных частях картыс ветлой и темной части карты. Пусть после калибровки, показания сенсора будут 10% на темной стороне и 90% процентов на светлой. Следовательно, условием, когда можно рассматривать, что робот уже на темной стороне – значение на сенсоре стало меньше 30%.

Тогда программа может быть сформулирована следующим образом:
1. Начать движение прямо (поскольку неизвестно, сколько нужно проехать работу до темной области, нужно задать "бесконечное" движение)
2. Ехать до тех пор, пока значение на сенсоре не станет меньше 30%.
3. Остановиться.

На NXT-G программа будет выглядеть, следующим образом:


Давайте, усложним программу, чтобы робот возвращался еще и назад, на белую область. Условием, что робот уже на светлой стороне, являются показания сенсора большие 70%.
1. Начать движение прямо
2. Ехать до тех пор, пока значение на сенсоре не станет меньше 30%.
3. Остановиться.
4. Начать движение назад.
5. Ехать до тех пор, пока значение на сенсоре не станет больше 70%.
6. Остановиться.



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


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

А насколько изменится программа, если условие задачи еще немного изменится? Допустим, карта теперь также состоит из двух частей: темной и светлой, но размеры этих частей увеличились и роботу теперь нужно добраться от одного края карты, до другого, совершая движения "ёлочкой".


Видно, что характер самого движения не изменился – робот опять должен двигаться поочередно из области одного цвета в другой. Однако, изменилось направление движения, раньше робот у нас ездил вперед и назад, сейчас же движение должно быть все время вперед, только меняется направление поворота. Итак, программа должна состоять из следующих действий:
1. Начать поворот налево.
2. Ехать до тех пор, пока значение на сенсоре не станет меньше 30%.
3. Остановиться.
4. Начать поворот направо.
5. Ехать до тех пор, пока значение на сенсоре не станет больше 70%.
6. Остановиться.
7. Повторить действия, начиная с шага 1.



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

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


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

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



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

Естественно, приведенная выше реализация небезупречна. Основной ее недостаток – итоговая скорость движения робота вдоль линии. Можно сказать, что эта реализация базовая – с нее стоит начать изучение этого сложного алгоритма. К тому же, она позволяет довольно быстро (маленькое количество действий в программе) и с минимальным количеством деталей (два мотора и один светочувствительный сенсор) показать, на что способен робот.

пятница, 19 ноября 2010 г.

Валли, Manty и другие роботы Жени Лосицкого

Приятно было обнаружить среди просторов интернета сайт питерского школьника Евгения Лосицкого, на котором он публикует своих роботов, собранных на основе Lego Mindstorms NXT. На сайте Женя выкладывает не только фотографии своих изделий, но и видео-ролики, один из которых был даже опубликован на довольно известном иностранном блоге посвященном Lego Tinkernology



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

Lego механизмы: собираем шагающего робота

Damien Kee - австралийский преподаватель по программированию Lego-роботов и автор нескольких книг посвященных этой теме.

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

Lego механизмы: какой оно формы?

Одного из поклонников Lego Mindstorms - Phillipe "Philo" Hurbain (кстати, он же один из авторов книги Extreme NXT: Extending the LEGO Mindstorms NXT to the Next Level) не покидает идея сделать сканнер на основе этого конструктора. Причем это не должен быть просто сканнер - он должен иметь дело с трехмерными объектами.

Сначала им был собран сканнер на основе линейного привода (Linear Actuator). Линейный привод преобразует вращащееся движение мотора в линейное (вперед-назад).

Благодаря ему NXT 3D Scanner как бы ощупывает предметы, после чего данные обрабатываются специальной программой, которая уже позволяет взглянуть на полученный результат.



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

Установка, собранная на базе Lego Mindstorms удерживает лазер и камеру, а также ответственна за вращение сканируемого объекта.

Непосредственно за сканирование отвечает программное обеспечение DAVID-laserscanner.
В целом автор отмечает значительное увеличение скорости сканирования:

Больше технических деталей об этом сканере можно найти на сайте автора.

Кстати, этот сканнер можно было видеть на видео с LEGOWORLD 2010.

четверг, 18 ноября 2010 г.

Робот для состязаний: выполняем разворот

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

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

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

Критерий первый. Скорость выполнения разворота.

Если рассматривать одного и того же робота, то скорость разворота двумя моторами будет быстрее.
Это связано с тем, что в случае с разворотом одним колесом, колесу нужно проехать большее расстояние (в 2 раза)

чем при развороте двумя колесами

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

Критерий второй. Точность выполнения разворота.

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

Критерий третий. Пространство разворота.

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

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

среда, 17 ноября 2010 г.

Робот для состязаний: колесная база робота

Частично навеяно мыслями из статьи на legoleaguecoaching.org

Очевидно, что данных сообщений на данную тематику будет несколько, так что это только начало.

Широкая или узкая колесная база?

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

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

Можно провести небольшой эксперимент. Пусть к NXT блоку к портам "B" и "C" подключены два мотора. Также пусть есть программа, которая запускает моторы для поворота на некоторое количество градусов, после чего проверяет на сколько они реально провернулись и выводит на экран это число вместе с относительной ошибкой поворота (в процентах) для каждого мотора.
Например, "45-0.0 49-8.8", показывает, что один двигатель повернулся на 45 градусов, относительная ошибка поворота 0.0%, в то время как второй двигатель повернулся на 49 градусов и ошибка поворота (от 45 градусов) составляет 8.8%.
Вот, что такая программа может вывести:




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

Стоит отдельно пояснить, что такое относительная ошибка поворота и на что она повлияет при движении, а конкретно при выполнении поворота всем роботом целиком.

Допустим, что было расчитано, что для того чтобы проехать 10 см., колесо должно провернуться на 180 градусов. Если мы говорим, что относительная ошибка поворота - 5%, т.е. двигатель повернулся на 189 или на 171 градус, то для робота это значит, что он проедет не 10 см, а 11 см. или 9 см.

Так что же произойдет в этом случае во время поворота всего робота?
Следующие объяснения в виде изображений должны пролить свет на ответ.




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

Для сравнения и ответа на вопрос "Широкая или узкая колесная база?" можно взглянуть на следующие схемы:




Очевидно, что при расширении колесной базы колесу робота нужно проехать большее расстояние чтобы выполнить поворот. Например, теперь роботу нужно повернуть колесо на 160 градусов. При абсолютной ошибке в 4 градуса, относительная ошибка уменьшится до 2.5%. Т.е. робот после поворота будет гораздо ближе к предполагаемому направлению движения.

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

приручаем Солнце и ветер вместе с Lego

Известный факт, что одно из направлений, в котором следует компания Lego, - образовательные наборы. Можно сказать, что Lego Mindstorms и Lego WeDo - идеи родившиеся как раз в ходе поиска новых продуктов, направленных на обучение.

Не так давно (в сентябре) компания Lego презентавала новый образовательный набор под названием "Возобнавляемая энергия" (9688 – Renewable Energies).



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





При использовании этого набора совместно с Lego Mindstorms NXT и последней версией среды NXT-G, включающей в себя сбор данных (data logging) лабаратория, как инструментарий для исследования, значительно увеличивает свои возможности:




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



Или собрать и запрограммировать робота, автоматически следящего движением Солнца для получения максимального количества энергии:

вторник, 16 ноября 2010 г.

В начале большого пути...

Начали проявляться первые результаты того, что НИИТ заявил себя как учебно-тренировочная база.

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

понедельник, 15 ноября 2010 г.

NXT-G: какая кнопка на NXT блоке нажата?

То что NXT-G предоставляет возможность получать состояние кнопок расположенных на NXT блоке ни для кого не секрет.




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




Но иногда возникает необходимость узнать, а нажата вообще какая-нибудь кнопка, если да, то какая? Например, когда с помошью одного NXT блока, посредством Bluetooth, выполняется управление роботом, оснащенным другим NXT блоком: нажатие на левую кнопку вызывает поворот налево, а на правую - поворо направо.
Базовый блок "NXT Buttons" не позволяет это сделать за один запрос. Следовательно, необходимо такую функциональность реализовать.

Если попытаться составить алгоритм выяснения состояния кнопок, то он может выглядеть следующим образом:
1. Опросить состояние левой кнопки, если она нажата перейти к пункту 5
2. Опросить состояние правой кнопки, если она нажата перейти к пункту 5
3. Опросить состояние средней кнопки, если она нажата перейти к пункту 5
4. Если ни одна из кнопок не нажата, вернуть это состояние в основную программу
5. Вернуть в основную программу какая кнопка нажата.

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

Дело в том, что NXT-G уже оперирует цифрами 1, 2 и 3 для того, чтобы обозначить кнопки на NXT блоке.
1 - Right
2 - Left
3 - Select
Поэтому, удобно, чтобы реализация алгоритма описанного выше, тоже использовала эти значения. Тогда, пусть она возвращает
1 - если нажата правая кнопка,
2 - если нажата левая кнопка,
3 - если нажата средняя кнопка.
В дополнение, необходим число, которым можно было бы закодировать состояние, что никакая кнопка не нажата. Пусть таким числом будет "0".

Теперь, для последовательного опроса кнопок, можно воспользоваться фактом, что при программировании блока "NXT Buttons" через канал данных передается код кнопки, состояние которой необходимо узнать. Поскольку кнопок всего три, можно опрашивать их в цикле: сначал кнопку с кодом 1 (правую), затем кнопку с кодом 2 (левую) и т.д. Как только найдено, что какая-то кнопка нажата, дальнейший обход по циклу не имеет смысла, поэтому он завершается.
Также нужно помнить, что счетчик цикла начинается с нуля, в то время как для опроса необходимо работать с номерами от "1".

Итак, опрос состояния кнопок:


Поскольку, цикл завершается по любому из условий: "нажатая кнопка обнаружена" или "все три кнопки опрошены", то такое составное условие будет выглядеть так:


Хотя каждая итерация цикла и выполняется довольно быстро, вполне вероятно событие, что конкретная кнопка была нажата только между двумя соседними опросами ее состояния, т.е. на момент самого опроса она не зажата. Это поведение совпадает с шаблоном состояния Bumped. Следовательно, каждую кнопку нужно проверять на два состояния - номер кнопки возвращается если кнопка зажата (Pressed) или нажата (Bumped).


Теперь нужно получить номер нажатой кнопки или "0", если ни одна кнопка не нажата. Очевидно, что нужно выяснить по какому условию произошел выход из цикла: по достижению конца всех допустимых итерация (выполнено все три итерации цикла) или же по выявлению нажатой кнопки. Поскольку на момент завершения цикла одно из этих условий уже Истина (True), можно это использовать для определения, что возвращается как результат алгоритма: "0" или номер кнопки.


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


Целиком содержимое нового блока будет выглядеть следующим образом:


В таком виде его можно использовать, например, чтобы перемещать фигурку по экрану:

- В цикле опрашивается не была ли нажата какая-то кнопка.
- Если нажата левая кнопка (третья вкладка), уменьшаем Xcoord, ответственный за координату Х, перемещаемой фигуры

- Если нажата правая кнопка (вторая вкладка), увеличиваем Xcoord
- Возрващаемые значения "0" (первая вкладка) и "3" (четвертая вкладка) игнорируются - значение Xcoord не изменяется.
Важно также отметить, что Xcoord изменяется только тогда, когда фигура находится все еще в зоне видимости на экране. Т.е. координата Х не должна принимать слишком маленьких и слишком больших значений.
Related Posts Plugin for WordPress, Blogger...