Платформа на RaspberryPi

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

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

Постепенно сформулировались хотелки:
— главной задачей было получить массу практического опыта именно в embedded linux, но минимум хардвара и пайки;
— естественно он должен был быть интересным;
— решаемым без лютого задротства;
— не содержать микроконтроллеров 🙂
— применение одноплатника должно было быть оправданным;
— по возможности, это должно было быть то, чего нельзя купить готовым.

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

Итак, проекты строго поделились на группы:
1. Прикрути к raspberrypi вентилятор/сделай корпус/приклей радиатор … и т.п.
2. То что можно сделать на микроконтроллере;
3. Интересные 🙂
4. Неинтересные лично мне.

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

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

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

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

Управлять сервами через микроконтроллер очень просто, соблазн был велик, но задача была не юзать мк, ибо нужно было приобретать опыт, а не использовать имеющийся. Поэтому начал с самого простого, нашел на али микросхему pca9685 и начал ее курение. Это 16 канальный pwm драйвер, с управлением по i2c.

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

После того, как сервы закрутились, сразу же возник вопрос дистанционного управления, были варианты с радиоканалом, bluetooth и wifi. Так как планировалось передавать видео по wifi, то логичным показалось и управление по тому же каналу, заодно решил подтянуть знания по UDP. Кроме того, захотелось чтобы все это работало через QT, поэтому набросал простую форму.

Как оказалось с UDP, никаких проблем нет, все завелось сходу. Указываешь сокет отправителя.

socket->bind(QHostAddress::Broadcast, 2215);

и получателя, шлешь данные

socket->writeDatagram(Data, QHostAddress::Broadcast, SERVO_UDP_PORT);

Со стороны машинки, решил юзать консольное приложение, также на Qt. Просто слушаешь порт.

QObject::connect(udpSocket, SIGNAL(readyRead()), this, SLOT(processPendingDatagrams()));
udpSocket->bind(QHostAddress::Any, 2250);

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

И окончательно добили меня моторы, которые оказались на редкость слабыми. Как бы это не звучало странно, но конструкция оказалась слегка увесистой. Эксперименты с моторчиками показали что ШИМом их регулировать бесполезно. Чтобы платформа хотя бы сдвинулась с места нужно крутить на полном газу всеми четырьмя моторами. Колеса оказались кривыми, поэтому ровно ехать невозможно.

После этого, не понимая что же делать с этим дальше, платформа провалялась пару месяцев, но недавно, снова нашло вдохновение и я решил продолжить. Последовало ковыряние камеры и gstreamer. Собственно получение видео с камеры, кодирование в h264 и трансляция через RTP реализовано через командную строку, интеграцией с Qt пока не занимался. примеры приводил в предыдущей статье. На комповой стороне изначально думалось, смотреть видео на QT форме, но пока этот вопрос тоже решил отложить, поэтому остановился на просмотре через VLC. Задержка при этом около 5 секунд, но есть мнение, что это проблема VLC. Пока эта часть не приоритетная, поэтому тоже не тестил.

Еще одной проблемой оказалось, что камера у меня USB, при разрешении HD и частоте в 30 кадров, проц захлебывается, даже не смотря на то что у меня вторая малина, поэтому урезал видеопоток до 320х240@10fps, проц стал грузиться на 35-40%. Гугление привело мысли, что проблема именно в использовании USB. Пока тоже не копал глубоко, но есть мнение что единственным способ разгрузить проц это использование CSI камеры, но тогда встает вопрос со шлейфом, в общем тоже пока под вопросом.

Ну и на закуску. Решил прикрутить джойстик для управления сервоприводами. Благо в линуксе это делается очень просто. Открываем /dev/input/js* и читаем. По факту очень залипательная штука получилась, никак не оторваться 🙂 Комповую часть можно посмотреть на гитхабе

Итог: камера снимает в 320х240 при частоте 10fps, видео кодируется в h264 и передается по ethernet кабелю. На приемной стороне просмотр с задержкой в 5с через VLC. На комповой стороне тестовая приложуха, для управления положением камеры, работает через UDP. Поворачивать можно либо через кнопочки на форме, либо джойстиком. На моторы забил, жду гусеничную платформу.

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