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. Используете ли вы в своей разработке эту наиважнейшую для стереозрения технологию?
Спрашиваю не для прикола, а поиска истины для. В камерах может возникнуть рассогласование на полкадра или более, что может поставить жирный крест на стерео. В камерах со строчным переносом к этому добавится рваность (ступенчатость) самих кадров.

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

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

Realizator писал(а):У камер синхронизированы PLL клоки.

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

Realizator писал(а):Если коротко - максимальный разброс между захватами кадров в районе единиц миллисекунд.

При 30 кадрах в секунду полная длительность одного кадра равна 33 мс. Если, допустим, рассинхрон равен 5 мс, то это одна шестая часть кадра. Длительность строк при самом простейшем разрешении может составлять всего десятки микросекунд. Представьте голову робота или курсовую камеру дрона, который резко поворачивает влево или вправо. Допустим, что если камеры очень хорошие и мы полностью пренебрегаем смазом и изломом кадров, то рассинхрон 5 мс приводит к тому, что левый и правый камерные модули будут показывать две совершенно разные области пространства, т.к. за 5 мс = 5000 мкс и длительности каждой строки в десятки микросекунд камера может повернуть на большой угол.

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

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

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

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

Realizator писал(а):

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

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

Вы удивитесь, но я тоже практик.
Я когда-то делал макет системы телеприсутствия:

Там видно, что при передаче возникает большая задержка во всех звеньях системы. Для преодоления основных проблем этого макета я перешел на FPGA и добился некоторых положительных результатов.
Я делал и стереозрение на FPGA с одним из стереоалгоритмов на ее борту. Для реализации не хватило собственных финансов. Поэтому работы приостановил. Да, это, возможно, несколько подороже, чем у вас, но, я предполагаю, что это самый нижний уровень по ценам для оборудования, которое полностью должно выполнять поставленные задачи.
Камерные модули с FSIN и кадровым переносом стоят подороже, чем со строчным, но не радикально. Использовать же IMX и Jetson - это делу не поможет.
Вместо ROS я использую самописную систему MOS, которая в разы менее латентна и может быть полностью реализована не только на ПК, МК, но и на FPGA.

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

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

FPGA я гонял через полмира до своего эхо-сервера и обратно по UDP, подключив 3G модемный модуль, с моим простеньким и шустреньким самодельным протоколом.

Realizator писал(а):Для нас задержки критичны при трансляции стереовидео пилоту - время реакции борта на команды пилота

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

Realizator писал(а):А компьютерное зрение мы предполагаем все-же на борту, в качестве полетного ассистента его использовать.

Т.е. кроме собственно восстановления 3D картины, вашему пилотному ассистенту потребуется понять, что он видит и принимать какие-то решения, начиная с простейших рекомендаций? Ведь стереозрение нужно не для того, чтобы оно просто было.Я занимаюсь агентами с онтологическим представлением мира. Правда, ввиду многих врЕменных ограничений, они пока не могут работать в жестком реалтайме. Хотя макет реалтаймовского движка для них, который можно разместить в FPGA, я сделал.