Реализация марсохода. Диаграмма развертывания

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

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

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

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

От механическо-электронной основы робота зависят способы и возможности реализации программной части.

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

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

1. Двигательная система
2. Система датчиков
3. Система управления

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

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

Система управления, напомню, должна обеспечивать следующие возможности: ведение логов состояний и выдача их по запросу, дистанционное проводное управление роботом, автономный объезд препятствий. Ограничения при выборе реализации системы управления: соблюдение заявленного общего веса марсохода в 4.5 кг, и указанных размеров - 22х25х4см. Компьютер в качестве системы управления отбрасываем сразу - слишком громоздко. Есть, правда, вариант с mini-ITX, такая карточка бы в наш корпус влезла, но карточки mini-ITX у меня нет, а я поставил задачу обойтись имеющимися средствами. Конечно, почти идеально подошел бы для описанных функций микроконтроллер. Он, помимо всего прочего, имеет больше всего шансов пережить креш-тесты. Однако, микроконтроллера у меня тоже нет. Зато, есть КПК Palm m505...

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

• Минимум - 2 кнопки в бампере, 2 кнопки для датчиков обратной связи, итого 4 датчика (4 входящих бинарных сигнала); 2 мотора, каждый может вращаться в двух направлениях - итого 4 исходящих бинарных сигнала.
• Максимум - 2 кнопки в бампере, 4 кнопки и две ИК-пары для датчиков обратной связи, термометр, датчик давления, 4 фотодатчика, фотокамера (управляющие исходящие сигналы на включение/выключение/съемку + сложный входящий сигнал на получение фотографии), видеокамера (аналогично фотокамере), 4 управляющих исходящих бинарных сигнала для моторов.
• Ожидаемо - 2 кнопки в бампере, 4 кнопки для датчиков обратной связи, фотокамера, 4 управляющих исходящих бинарных сигнала для моторов.

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

На КПК Palm, и на многих других КПК, в том числе и современных - реализован, как минимум частично, интерфейс RS232, обеспечивающий последовательную передачу данных. Программно COM-порт на Palm управляется достаточно тривиально, почти как на компьютере. Это - как раз то, что нам и нужно!

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

Такие схемы есть в готовом виде, например, комплект PPRK (Palm Pilot Robot Kit) использует одну из них - SV203. Но здесь важно вовремя остановиться! Наша цель - всего лишь построить диаграмму развертывания, а в детали реализации углубляться можно бесконечно...

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

Вот диаграмма, которая получилась у меня:

Пакет «Система управления»:

Пакет «Двигательная система»:

Пакет «Система датчиков»:

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

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