Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
С удовольствием почитаю этот цикл. Спасибо) всегда не хватает чего-то большего, чем «включать свет на балконе, когда темнеет при помощи Arduino, сервера на Amazon и десяти датчиков»
С нетерпением буду ждать продолжения!
Я как раз занимаюсь подобным проектом
Я как раз занимаюсь подобным проектом
А производительности RPi хватает для того, чтобы хоть как-то осмысленно анализировать видеопоток?
ну на видео примеры — тут смотря какой видеопоток конечно и какие алгоритмы — для полноценного прям анализа в full hd реалтайм видео конечно не хватит, но для езды по линии в разрешении 80 на 60 вполне хватает получать 50-60 фпс с обработкой — чего в принципе достаточно — можно разметку распознавать, радиус кривизны поворота рассчитывать, знаки всякие и прочее. Вообще далее хотелось бы конечно использовать что то вроде Jetson TK1 — но это уже другой уровень — как по габаритам, так и по порогу вхождения — мой вариант это такой эволюционный переход от миганий лампочками к компьютерному зрению
Спасибо за ответ. Хочется съязвить про то что линии в офисе рисовать затруднительно, но для этого надо свое что-нибудь закодить сначала.
А с анализом видеопотока на персоналке сталкивались? Очень интересно, что можно сделать в эту сторону.
А с анализом видеопотока на персоналке сталкивались? Очень интересно, что можно сделать в эту сторону.
Ну на пк нет проблем — по тому же вайфаю налаживается соединение, прокидывается видеопоток и анализируется на мощной машине-конкурс крок с квадрокоптерами ребята так и выиграли, но это все же не совсем полноценный робот получается-у полноценного все на борту должно быть-тогда уж ставьте платформу побольше и движки, чтоб ноут за собой возила) Единственное — диапазон 2,4 ГГц может быть загажен и ФПС может проседать или вообще соединение отваливаться, кроме того расстояние ограничено. Если вы соберетесь участвовать в каких либо конкурсах-много где запрещено вычислять удаленно-это же все взаимосвязано внутрь вам больше вычислительной мощности-больше плата, кулер, больше потребление, габариты, механика более мощная, цена-так что лично я считаю подобные штуки жульничеством-робот должен быть автономен
Прожорливость Raspberry Pi, на мой взгляд и исходя из моего опыта, делает ее игрушкой во всех автономных системах.
Поиграться для собственного удовольствия и развития — да. Использовать в тиражируемых решения — нет.
Для простых задач, как езда по линии и прочее, малина сильна избыточна. Для более менее сложных, как обработка видео в реальном времени — слишком слабая.
Например, мои эксперименты с выделением линии лазера (для 3D сканера) и предварительной обработкой с формированием множества точек и запись их в файл на SD + управление шаговыми двигателями, показали, что производительности Raspberry Pi со стандартным Linux и USB камерой нужного разрешения для этого недостаточно.
STM32F4… справляется с этой задачей гарантированно и контролируемо (без использования OS вообще и OEM модулем камеры с прямым управлением), пусть это занимает 80% ресурсов.
Потребление и сравнивать смешно.
Что касается обработки в реальном времени…
Попытка сделать управление ЧПУ станка на Raspberry Pi то же провалилась. И, насколько я знаю, никто до живого варианта для Raspberry ее не довел. (формирование Step/dir последовательности из g-code файла, попытками адаптации LinuxCNC)
А дохленький STM32F103 с этим справляется без проблем и с большим запасом. Работает успешно у меня на станке.
Впрочем это даже на ATMega некоторые энтузиасты делают (хотя я этого извращения не понимаю).
Поиграться для собственного удовольствия и развития — да. Использовать в тиражируемых решения — нет.
Для простых задач, как езда по линии и прочее, малина сильна избыточна. Для более менее сложных, как обработка видео в реальном времени — слишком слабая.
Например, мои эксперименты с выделением линии лазера (для 3D сканера) и предварительной обработкой с формированием множества точек и запись их в файл на SD + управление шаговыми двигателями, показали, что производительности Raspberry Pi со стандартным Linux и USB камерой нужного разрешения для этого недостаточно.
STM32F4… справляется с этой задачей гарантированно и контролируемо (без использования OS вообще и OEM модулем камеры с прямым управлением), пусть это занимает 80% ресурсов.
Потребление и сравнивать смешно.
Что касается обработки в реальном времени…
Попытка сделать управление ЧПУ станка на Raspberry Pi то же провалилась. И, насколько я знаю, никто до живого варианта для Raspberry ее не довел. (формирование Step/dir последовательности из g-code файла, попытками адаптации LinuxCNC)
А дохленький STM32F103 с этим справляется без проблем и с большим запасом. Работает успешно у меня на станке.
Впрочем это даже на ATMega некоторые энтузиасты делают (хотя я этого извращения не понимаю).
Вот уж не думал, что кто то будет даже сравнивать производительность гигагерцового компьютера с gpu и 512 МБ оперативки с 72 мегагерцовым RISC микроконтроллером, но и придёт к выводу, что микроконтроллер производительней! У меня когнитивный дисонанс-если чисто по житейски-не вдаваясь в подробности архитектуры-что больше миллиард или 100 миллионов? Почему же тогда в телефонах и компьютерах не стоят f4? Вы либо что то не так программируете, либо не отличаете время реакции от производительности. Про избыточность для езды по линии-довольно голословно — смотря с какой скоростью и по какой линии ехать. Ну и вообще — утверждать, что платформа плохая потому что что то у вас на ней не получилось не очень корректно, здорово бы было тимлиду говорить-«я не сделал, потому что это невозможно и вообще ваш c++ тот ещё кал». На промышленное решение не претендуют платформа изначально позиционируется для обучения — тут важна цена и доступность информации
начал писать длинный комментарий (в фоне… на работе я). Случайно закрыл страницу и снова набивать его не буду.
Вы меня поняли не так. Вопрос не в сравнении производительности проца.
Суть моего комментария — пихать всюду малину можно только из соображений «попробовать» и «поиграться».
Задача: Обработка 1200x800 кадров с выделением красной и зеленой линии лазера + управление шаговым двигателем 4096 шагов на 360 градусов. Запись сырой информации (координаты точек на кадр в int16_t) на SD.
Raspberry PI. USB камера, запись в файл на SD. библиотека ffmpg. Код на C++.
Время обработки кадра + запись на SD — от 100 до 800ms. В среднем 300ms.
STM407 (168Мгц, кстати). OEM камеры MT9D111. запись на SD в DMA режиме с фиксированной таблицей FAT (ну один файл большого размера на всю карту как бы). Код на C++ без OS.
Время обработки кадра + запись на SD всегда 200ms. Правда ни на что больше производительности бы не хватило.
Про потребление в автономе даже сравнивать нет смысла.
Конечно же, если бы надо было делать промышленный вариант, то выбрал бы что ни будь побыстрее чем специализированный STM контроллер. А может быть и нет. Вопрос стоимости и достаточности.
А роботами я много экспериментировал.
Да и с малиной то же.
Вы меня поняли не так. Вопрос не в сравнении производительности проца.
Суть моего комментария — пихать всюду малину можно только из соображений «попробовать» и «поиграться».
Задача: Обработка 1200x800 кадров с выделением красной и зеленой линии лазера + управление шаговым двигателем 4096 шагов на 360 градусов. Запись сырой информации (координаты точек на кадр в int16_t) на SD.
Raspberry PI. USB камера, запись в файл на SD. библиотека ffmpg. Код на C++.
Время обработки кадра + запись на SD — от 100 до 800ms. В среднем 300ms.
STM407 (168Мгц, кстати). OEM камеры MT9D111. запись на SD в DMA режиме с фиксированной таблицей FAT (ну один файл большого размера на всю карту как бы). Код на C++ без OS.
Время обработки кадра + запись на SD всегда 200ms. Правда ни на что больше производительности бы не хватило.
Про потребление в автономе даже сравнивать нет смысла.
Конечно же, если бы надо было делать промышленный вариант, то выбрал бы что ни будь побыстрее чем специализированный STM контроллер. А может быть и нет. Вопрос стоимости и достаточности.
А роботами я много экспериментировал.
Да и с малиной то же.
Моторчики без энкодеров?
У меня большая проблема заставить такую платформу ехать прямо, моторы крутят с разной скоростью.
У меня большая проблема заставить такую платформу ехать прямо, моторы крутят с разной скоростью.
Я покупал похоже что такую же платформу робота, она комплектуется дисками энкодеров
я поставил энкодеры, завел их на прерывания.
Застрял на алгоритме компенсации, хотчеться посмотреть как у других сделано.
Застрял на алгоритме компенсации, хотчеться посмотреть как у других сделано.
Для синхронизации вращения колес, в обработчиках прерывания можете использовать следующий код
void MotorL() // обработка внешнего прерывания левое колесо
{
course--;
if(course > 0) { robot_left; }else{ robot_right;}
}
void MotorR() // обработка внешнего прерывания правое колесо
{
course++;
if(course < 0){ robot_right; }else{ robot_left;}
}
Производительности ардуины(атмега328, 16мГц) вполне хватает реализовать 2-х канальный ПИД регулятор, но для этого как уже сказали выше нужны энкодеры на моторах.
При наличии ПИД регуляторов, телега может ехать ровно. Проверено ровно на такой же схеме.
При наличии ПИД регуляторов, телега может ехать ровно. Проверено ровно на такой же схеме.
в планах кстати еще запилить статью по расчету коэффициентов ПИД регулятора в Matlab на основе мат модели двигателя — там есть довольно мощный инструмент — была бы хорошая мат модель системы — для робота в целом пока коэффициенты методом тыка подбираю, а вот мат модель движка легко сделать и померить параметры
А можно по-подробнее про разницу ШИМ для сервы между Arduino и Raspberry. Пробовали ли использовать ServoBlaster?
ну если чисто сам шим можно реализовать одним из методов, используя аудио ЦАП, то быстро обновлять и реагировать мы уже не сможем — квант времени операционной системы не позволит — допустим то же выравнивание по энкодеру, сбор информации с датчиков — это операции в общем то несложные, но требующие регулярного и частого снятия данных — килогерцы/десятки килогерц. С операционной системой без лютого шаманства и задротства это сделать проблематично, а если и сделать — это может занять слишком большой ресурс — поэтому вычислительно не очень затратные вещи, но требующие быстрой реакции перенесены на ардуино
Про чтение GPIO входов или не дай бог аналоговых входов речи не идет, тут все ясно. Если задача только управлять позицией сервопривода (или передавать сигнал на модельный регулятор двигателя), будет ли разница? Я просто пытаюсь понять, выиграю ли я что-нибудь, переведя управление на Arduino, или это будет шило на мыло.
ну если односторонняя связь и задача стоит в том, чтобы просто периодически выставлять ШИМ — можно обойтись и без ардуины, но как только захотите повесить какие то датчики — выровнять скорости вращения движков там, расстояние и прочее — столкнетесь с сложностями — поскольку на робота их скорей всего захочется повесить — используется связка такая
ок, спасибо. Arduino у меня и так висит на ком порте как раз для датчиков. А проблем с движками у меня нету видимо из-за того, что я использую не motor shield, а одинаковые модельные регуляторы для коллекторных двигателей. В качестве бонуса такого подхода два импульсных преобразователя на 5 вольт сразу из коробки.
Скажите пожалуйста.
У Вас такая платформа?
Хочу приобрести себе для отладки алгоритма навигации в помещении
У Вас такая платформа?
Хочу приобрести себе для отладки алгоритма навигации в помещении
Предложу заменить на web-камеру и применить способ, описанный в моём блоге, по подключению камеры к raspberry pi и получению картинки на java
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Робот на RaspberryPi, Arduino и RaspiCam + OpenCV. Часть 1 Обзорная