четверг, 30 декабря 2010 г.

Памятка для будущих победителей состязаний по программированию Lego-роботов

Участие в соревнованиях по программированию Lego-роботов один из увлекательнейших этапов при изучении робототехники. Это не только командная работа, дух состязания и радость победы, но и возможность почувствовать себя вовлеченным в разработку Проекта, подобным тем, что имеют место быть на настоящих предприятиях, исследовательских институтах, R&D центрах.
Ведь Lego-проект для участия в соревнованиях по этапам работы над ним ничем отличается от реальных проектов. И тот и другой имеют стадии получения и уточнения деталей задания, продумывание структуры и взаимодействия отдельных частей проекта, включая конструкцию и программную начинку, затем, идет непосредственно реализация, проверка на работоспособность (тестирование) и, наконец, сдача проекта – участие в соревнованиях.

Для того, чтобы выступать на соревнованиях, демонстрируя отличные результаты, определенно, нужны стремление к победе и определенный склад характера. Тем не менее, это далеко не все. Важно помнить, что это командная работа, и разобщенность членов команды может и приведет к победе, но для этого придется затратить очень, ОЧЕНЬ много усилий.

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


I. Безусловно, чем больше вы участвуете в состязаниях, тем больше у вас опыта, тем быстрее вы начинаете ориентироваться в заданиях каждого следующего состязания. Но это не значит, что если у вас за спиной только одно-два или вообще ни одного состязания, вы не можете обладать опытом. Опыт можно нарабатывать даже без участия в состязаниях:
  1. Задолго до получения задания состязаний, можно придумывать свои собственные задания. Посмотрите на окружающие вас вещи, на действия, которые с ними чаще всего делаете. Можно ли поместить робота в подобные (хоть и упрощенные) условия и придумать программу, которая бы управляла этим роботом для выполнения тех же действий, что и делаете вы. Если у вас есть любимый вид спорта, можете попробовать сделать робота, играющего в него. Не ставьте перед собой сразу сложные задачи, начните с простых – припарковаться между двух стоящих книжек, не уронив их, перенести кубик, шарик или карандаш из одного места в другое, выкинуть мусор. Потом переходите к сложным - открыть несколько книжек, забраться по ступенькам. Полигоны для вашего робота вы можете создавать из подручных материалов: детские кубики, конструкторы, изолента, картонные коробки, книги.
    Важно помнить, что важно не самое задание, а возможность его решить.
  2. Задания можно также брать из предыдущих соревнований. Они легко находятся в Интернете. Если вы занимаетесь в большой группе в школе или кружке, изготовление полигонов для таких заданий не должно быть большой проблемой. Но если у вас «домашняя» команда, вы можете опять же воспользоваться окружающими предметами для сооружения трассы-полигона.
  3. Найдите в Интернете ролики с решением всевозможных задач предыдущих состязаний. Внимательно просмотрите и изучите поведения робота в них. Обдумайте, какие приемы использовали его разработчики для достижения результата. Задайте себе вопрос: владеете ли вы такими же приемами? Не ищите только ролики, в которых робот успешно решает задачу – изучайте также ролики, где роботы не могут выполнить задание по каким-либо причинам. Важно знать и помнить эти причины. "Дурак учится на своих ошибках, а умный – на чужих".
  4. Изучайте конструктопедии и инструкций по сборке роботов (любых: подвижных, стационарных, с подвижными частями). Например, "Tora no Maki", nxtprograms.com. Вам даже подойдут инструкции по сборке моделей серии Lego Technic. Рассматривайте соединительные узлы, способы крепежа и сопряжения деталей. Какие конструкции собраны жестко, а какие нет? Как жесткость собранной конструкции влияет на работу всего механизма или отдельной его части? Каким образом закреплены шестерни относительно друг друга. Как передается энергия от ее генераторов (сервомоторов, ручного привода) к другим частям робота? Как собраны подвижные узлы? Какие бывают колесные базы? Как собираются манипуляторы?
  5. Собирайте и свои механизмы. Знайте, сколько и каких деталей нужно для сборки того или иного узла. Сколько времени уходит на его сборку? Ваши руки должны быть знакомы во всеми деталями, из которых вы будете потом собирать вашего робота. Развитая мышечная память сослужит вам в будущем хорошую службу.
  6. Изучайте конструкции языка программирования, на котором вы будет составлять программу для вашего робота. Лучше если вы будет знать несколько языков, понимать из достоинства и недостатки, чтобы уже по заданию ориентироваться, какой язык лучше применить для решения конкретного задания.
  7. Изучайте готовые программы или их части. Их можно найти, например, на nxtprograms.com. Смотрите не только на то, как они оформлены, но и постарайтесь понять, что именно этот код делает, почему автор решил реализовать это именно таким образом, какие у этого кода есть недостатки – когда он не будет работать, обрабатываются ли в нем какие-то специальные случаи, которые иначе могли бы привести к невозможности решения задачи роботом. Во-первых, этим вы приобретаете навыки чтения и понимания чужого кода. Это важное умение, когда вы составляете программы в команде. Во-вторых, вы формируете у себя базу знаний того, какие типичные решения существуют для решения той или иной задачи: вывод на экран, движение вдоль линии, выход из лабиринта. Так же вы начнете отличать хорошие решения от плохих. Начнете в своих программах продумывать их надежность и, возможно, даже оптимизировать их по скорости выполнения.
  8. Накапливайте базу готовых программ, точнее их частей Вы уже, наверное, заметили, что некоторые куски программ, кочуют из одной реализации робота в другую: вывод на экран отладочных сообщений, плавный запуск двигателей, калибровка сенсора, движение вдоль стены и т.п. Выделяйте такие блоки в отдельные подпрограммы. Можете даже заранее отвести отдельное время для того, чтобы предусмотреть всевозможные условия в каких будет использоваться этот код – и изменять его поведение с помощью входных параметров подпрограммы. Например, в подпрограмме вывода числа на экран в качестве параметров могут быть координаты вывода числа, сопроводительная подпись, флаг, очищать ли экран. Чем больше готовых маленьких подпрограмм у вас будет, тем быстрее вы сможете потом решать большую задачу – вы не будете отвлекаться на реализацию стандартных сервисных функций.

II. Неважно каким образом вы получили задание – для действительного ли оно соревнования, или вы придумали его сами, подход к решению задач будет один и тот же. Вдобавок ко всему, решение задачи в команде требует определенного навыка:
  1. Команда – единство нескольких людей. Примите за правило регулярно обсуждать различные этапы решения задачи вместе. Желательно, вдали от компьютера – это позволит не отвлекаться и сосредоточиться на обсуждении. Обсуждайте все:
    • первоначальную постановку задачи – сформируете единое понимание как задачи в целом, так и отдельных нюансов
    • как общую конструкцию робота так и технические моменты – особенно это важно, если у вас команда делиться на программистов и конструкторов – нужно решить, что возможно реализовать программно, а что проще сделать с применением конструкторских приемчиков. Плюс, все должны понимать ограничения конструкции и программы, чтобы небыло потом внезапных неприятных открытий
    • программную начинку робота – все должны представлять как работает программа, на каком языке она написана, какие приемчики и трюки в ней используются. Вдруг одному члену команды придется подменять другого по болезни - общее понимание программы, значительно увеличит возмозможность такой подмены
    • возникающие проблемы – про это многие забывают, но это очень важно. Быстрое решение возникающих вопросов и проблем – вот залог победы. А скорости решения можно только добиться совместными усилиями. "Одна голова хорошо, а две лучше".
    В обсуждениях не тратьте время на пустую болтовню. Назначьте кого-нибудь внутри команды – пусть следит, что обсуждение все еще имеет смысл, а не пустая трата времени. Он же может быть судьей в возможных спорах – пусть команда заранее согласиться, что при особенно рьяном споре последнее слово будет за ним.
  2. При любом обсуждении внутри команды нужно следовать простым правилам:
    • Внимательно слушайте идеи других. Позвольте им договорить до конца, не перебивайте. Даже если сама по себе идея может и не "выстрелит", то она может навести вас на нужные мысли
    • Ясно и внятно рассказывайте другим о своих идеях. Чем четче вы представляете, о чем говорите, тем быстрее вашу идею поймут другие. В ходе своего рассказа не ленитесь рисовать схемы и диаграммы
    • Продумайте вопрос, прежде, чем задать его. Хорошо заданный вопрос – половина ответа. Возможно, в ходе формулировки вопроса, вы уже сами найдете ответ.
  3. В случаях большой команды разделитесь по зонам ответственности. Пусть у вас будет один-два конструктора и несколько программистов.Для конструкторов можно разделить единую конструкцию на блоки: один собирает колесную базу и продумывает движение, другой занимается обдумыванием конструкции манипулятора. В "программистской" части вашей команды можно сделать аналогичное деление. Разделите программу на блоки: блок ответственный за движение, блок ответственный за реакцию на изменение окружающих условий и т.п. Но помните, в случае разделения вопрос обсуждения всего и вся становится наиболее острым. При слабом взаимодействии членов "разделенной" команды будет ОЧЕНЬ трудно достигнуть готового результата быстро. Неплохой идеей является выявить явного "архитектора" в команде, помимо определения базовых требований к программе и конструкции, пусть он будет коммуникационным ядром в вашей команде – на него ложится задача обеспечения каждого члена команды информацией о других блоках.

III. Как уже говорилось, решение задачи – маленький (или не очень) программно-конструкторский проект. Поэтому к нему применимы все те же правила разработки, что и к реальным проектам, которые мы можем встретить в жизни:
  1. Начинайте с простой конструкции и соответствующей ей простой программы. Получение готового робота, способного выполнять задание на ранних этапах разработки, очень важно. В «большом» мире это называют прототип. Пусть он будет не оптимален, пусть он будет решать задачу медленно, только при определенных условиях и с большими ограничениями – ничего страшного, на то он и прототип. Программистам это поможет уже на данном этапе оттачивать основные этапы программы, не дожидаясь, когда конструкторы придумают «идеальный» механизм. Конструкторам прототип обеспечит общее видение конструкции, то, что она принципиально возможна. После создания прототипа и те и другие начнут понимать, на что именно нужно в следующей версии обратить дополнительное внимание, что же вообще возможно опустить.
    Отнеситесь к данному пункту серьезно – лучше получить робота выполняющего все задание целиком хоть и медленно, чем робота со сложной конструкцией, но выполняющего только половину из всего задания. Это связано с тем, что большинство состязаний оценивают время выполнения задания, в то время как невыполненное задание, чаще всего, вообще перестает иметь смысл при выявлении победителя.
  2. От простых конструкций переходите к более сложным, учитывая преимущества и недостатки предыдущих. Попробуйте в каждой "итерации" изменения конструкции производить только небольшие изменения предыдущей модели. Старайтесь избегать глобального пересмотра всей концепции целиком, иначе ее переработка внесет значительные задержки. Примите за правило, что после каждого такого изменения робот в целом должен оставаться таким же работоспособным, как и прежде.
  3. Тоже самое относится и к программам – старайтесь не писать ее каждый раз заново. Разделите программу на маленькие блоки. Каждый блок должен быть ответственен только за определенное действие/реакцию робота, но должен делать это исключительно хорошо. Желательно, чтобы блоки были не сильно зависимы от результатов выполнения предыдущих. Теперь, даже если необходимо доработать программу – изменяется (или вообще заменяется) только один блок – остальные не трогаются, большая часть программы остается работоспособной.
  4. Поскольку очередное внесение изменений в конструкцию и/или программу может занять довольно значительное время, заранее определите момент во времени, после которого можно считать, что данное изменение не подходит для решения задачи, поскольку на его доработку тратиться слишком много сил. Иначе вы так и будете пытаться улучшить работу текущей конструкции, но так и не сможете заставить ее работать за отведенное время.
  5. Сделайте еще три-четыре попытки, после того как робот выполнил задание полностью и без ошибок (даже маленьких) первый раз. Достижение результата должно быть на 100% воспроизводимым, только тогда вы можете быть уверенными, что задание решено. Если робот сделал все верно только один раз, такой результата мог быть достигнут по случайности.
  6. Фиксируйте успешные результаты.
    • Перед началом каждой "итерации", измените имя файла с кодом вашей программы так, чтобы старая версия всегда сохранялась. Имеет смысл прямо в имени файла указывать новую версию. Например, linefollower_001.rbt и linefollower_002.rbt.
    • Также сохраняйте инструкции по сборке текущей версии вашего робота. Для этого можете использовать как фотоаппарат, так и программы типа Lego Digital Designer. Если ваш инструмент – фотоаппарат, то начните разборку робота и фотографируйте каждый этап разборки, особенно уделяя внимание критическим местам в конструкции. Просто поставив фотографии в обратном порядке, вы получите инструкции по сборке.
    Следование перечисленным выше шагам приведет к тому, что в случае неудачного изменения в программе или конструкции, вы всегда сможете откатиться назад, когда еще все работало.
  7. Даже если вы уверены, что робот (и его программа) полностью готов и решает задачу полностью, но у вас еще есть время до самого состязания – подумайте что еще можно улучшить в конструкции и программе.
    • Например, устроители состязаний часто оставляют за собой возможность, что-то изменить или добавить к уже сформулированному заданию (добавить еще одно препятствие, изменить порядок прохождения этапов, ужесточить требования к выполнению задания) – постарайтесь предусмотреть возможные изменения задачи
    • На каких этапах может ваш робот сбиться с выполнения задачи по какой-нибудь причине (сработала вспышка фотоаппарата, у полигона не оказалось окружающих его бордюров, или наоборот оказались)? Продумайте "плохие" варианты и защититесь от них
    • Сделайте поведение вашего робота детерминированным. Т.е. не полагайтесь на случайные факторы. Если робот повернулся на определенное количество градусов, как вы можете гарантировать, что это точно то количество, которое вы ожидаете? Если робот двигается к определенному этапу, какие особенности полигона вы используете, чтобы убедиться в правильном направлении движения и то, что вы не проехали еще нужное место? Обрабатываете ли вы варианты возможного застревания в определенном месте полигона, сможет ли ваш робот сам выбраться из такого положения?

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

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

Комментариев нет:

Отправить комментарий

Related Posts Plugin for WordPress, Blogger...