roboforum.ru

Всем привет!

Сегодня я бы хотел рассказать вам о нашей новой железке на базе Raspberry Pi Compute Module, предназначенной для компьютерного зрения и установки на роботов и дронов. По сути это «умная» стереокамера - она поддерживает работу с двумя камерами одновременно, имеет в качестве «сердца» настоящую малину и, самое важное – работает со стандартной версией Raspbian.
Вот как выглядит собранное решение, с установленными двумя камерами и Pi Compute модулем.



Устройство работает со стоковой версией Raspbian. Вам нужно только скопировать наш файлик dtblob.bin для того, чтобы включить поддержку двух камер.

Это означает, что вы можете использовать привычные raspivid, raspistill и другие утилиты для работы с изображениями и видео.

Для справки, поддержка режима стерео появилась в Raspbian аж в 2014 году, одновременно с выходом первой версии Raspberry Pi Compute. Вы можете посмотреть историю разработки поддержки стереорежима на форуме Raspberry.

Перед описанием технических деталей позвольте показать вам несколько реальных примеров работы устройства.


1. Захват изображения

Код (bash):

Код: Выделить всё • Развернуть

raspistill -3d sbs -w 1280 -h 480 -o 1.jpg

и вы получаете следующее:



Вы можете скачать оригинальное захваченное изображение вот тут.


2. Захват видео

Код:

Код: Выделить всё • Развернуть

raspivid -3d sbs -w 1280 -h 480 -o 1.h264

и вы получаете следующее:



Вы можете скачать оригинальный видеофайл (конвертирован в mp4) по этой ссылке.


3. Использование Python и OpenCV для построения карты глубин



В этом случае я использовал слегка модифицированный код из предыдущего проекта 3Dberry (https://github.com/realizator/3dberry-turorial).

Для получения этих картинок и видео мы использовали вот такую пару камер:



Для установки на дронов чаще используем широкоугольные (160 градусов), вот такие:



Теперь чуть подробнее про саму железку

Короткий обзор на YouTube: https://www.youtube.com/watch?v=g-iuJxtXlCA

[youtube]https://www.youtube.com/watch?v=g-iuJxtXlCA[/youtube]

Технические детали


Вид спереди:




Вид сверху:




Основные характеристики:


Размеры: 90x40 mm
Камеры: 2 x CSI 15 lanes cable
GPIO: 40 classic Raspberry PI GPIO
USB: 2 x USB type A, 1 USB on a pins
Ethernet: RJ45
Память: Micro SD (for CM3 Lite), у остальных NAND (flash)
Монитор: HDMI out
Питание: 5V DC
Поддерживаемые малины: Raspberry Pi Compute Module 3, Raspberry Pi CM 3 Lite, Raspberry Pi CM 1
Типы поддерживаемых камер: Raspberry Pi camera OV5647, Raspberry Pi camera Sony IMX 219, HDMI In (одиночный режим)
Для прошивки NAND: MicroUSB connector
Выключатель питания: Да-да, это он. Больше никаких втыканий-вытыканий MicroUSB провода для ребута по питанию!


Немножко истории

Вообще затея сама появилась еще в 2015 году. Первая версия родилась в конце 2015 года. У нашей команды есть "пунктик" на удаленном управлении разными механическими штуковинами, поэтому в первом релизе на борту был установлен дополнительный чип, дававший нам 16 PWM выходов - для руления сервами, моторчиками и прочими полезностями.



К тому моменту на рынке была только первая версия Compute модуля, на борту которой стоял старый процессор от самой первой распберри. Железка прекрасно справлялась с захватом, сжатием и стримом видео, но в конце концов мы уперлись именно в процессор. Например, её уже не хватало для одновременно стрима h264 пилоту и RTMP стрима на сервер. А для роботостроителей основной хотелкой стало построение карты пространства по карте глубин и SLAM - тут процессора не хватало совсем.



У тут на тебе - выходит версия Compute Module 3. Они сразу "перепрыгнули" с первой версии на третью, поставив процессор от третьей Raspberry. Теперь его мощности уже было достаточно, чтобы что-то обсчитывать на лету.

Однако оказалось что поколения вроде как и совместимы, а вроде как и не очень. Тот факт, что Compute Module 3 был на миллиметр шире нас не смутил. А вот требования к питанию серьезно поменялись.

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

Что исправлено во втором поколении


Добавили поддержку Compute Module 3

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

Развернули модуль "чипами от платы"

В первой версии перепутали тип разъема SoDIMM на плате, в результате компьют-модуль вставал чипами "к мамке". На Compute Module 1 это проблем не вызывало - проц грелся слабо, и узкого места между платами ему хватало для нормлаьного охлаждения. С третьим такой фокус бы не прокатил, поэтому мы "перевернули" коннектор, что повлекло за собой переразводку всей платы с чистого листа.

Штатная поддержка MicroSD

Первый компьют-модуль по умолчанию имел встроенную FLASH на борту и с микросд работать не умел. Мы попытались привесить туда MicroSD как второй накопитель, но столкнулись с большим головняком по его поддержке. Общение с кернельщиками на малиновом форуме показало, что проблема непростая (при загрузке модуль рандомно выбирал NAND или MicroSD для бута). В итоге на текущей ревизии мы сделали разводку как на референсной devboard от малины. Если Compute Module <b>Lite</b> - без встроенной NAND - работаем с микросд как в обычной малине. Если версия не Lite или первый модуль - микросд недоступна.

Переместили коннекторы камер наверх и разнесли на 65 мм

В первой версии коннекторы были направлены вдоль плоскости платы. Мелочь, но после множества установок в корпуса выяснилось несколько проблем.

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

Убрали чип и дополнительные 16 PWM

Проанализировав множество последних проектов поняли, что фича эта неактуальна. Чаще всего хватает и программных PWM малины.

Добавили выключатель питания

Те кто хоть немного работал с малиной понимают о чем речь

Добавили третий USB на пинах сбоку

В наших малиновых проектах нам часто нужны USB донглы на борту. Если их втыкать в разъемы на плате - имеем торчащий далеко наружу модуль. Попытка воспользоваться USB удлинителем еще больше усугубляет проблему. Оставался один вариант - пайка проводками напрямую к малине. Добавленные нами боковые пины позволяют сделать простой удлинитель и расположить USB донгл (чаще WiFi или 4G) прямо вдоль платы, и всё это хозяйство прекрасно помещается в компактный корпус.

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

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

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

Виктор Казаринов писал(а):В качественных устройствах допускается рассогласование всего на несколько пикселов относительно начала кадра.

Согласен. Можно сделать решение на Jetson и взять парочку соняшных IMX с глобальным затвором, получится отличная индустриальная стереокамера, просто разница в цене будет примерно раз в 20.
Мы больше практики, чем теоретики. Задача со стримом стереовидео пилоту у нас решена, теперь будем реализовывать ROS на борту и активно тестировать избегание препятствий. Сначала на земле, потом в воздухе. Думаю на этих тестах как раз и получится выяснить предел возможностей.

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