fpv.md

OpenIPC Wiki

Оглавление

Использование OpenIPC как бюджетного видеолинка для FPV систем

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

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

Было предложено взять бюджетный SBC Raspberry Pi, подключить к нему камеру по MIPI интерфейсу и USB WiFi донгл с числа рекомендуемых, а с другой стороны на приемнике - аналогичный WiFi модуль с HDMI монитором. При этом вместо традиционного для передачи видео с низкой задержкой протокола UDP был использован протокол более низкого уровня для гибкого управления данными: управлением шириной полосы, мощностью передатчика и возможностью восстановления данных, если пакет при отправке был частично поврежден. Одной из технических проблем являтся то, что не каждый WiFi адаптер способен работать в таком низкоуровневом режиме, более того: практически всегда приходится устанавливать специальные драйверы, которые существуют только под Linux.

Приемник в этом режиме работает в так называемом monitor mode, когда он принимает и передает операционной системе каждый пакет заданного WiFi канала, где затем решается что с ним делать дальше: декодировать или отбросить. WiFi адаптер передатчика должен работать в injection mode, когда ядро операционной системы фактически не участвует в формировании сетевых пакетов, предписанной сетевой моделью ISO. Часть адаптеров поддерживает оба режима, некоторые из них - только какой-то один, поэтому могут стоять только на стороне передатчика или приемника.

Проект был назван Wifibroadcast, его идеи получили дальнейшее развитие в проекте EZ-WifiBroadcast, после чего новая команда разработчиков переписала исходный код с нуля в самом популярном на сегодняшний день проекте OpenHD. Кроме того в процессе эволюции появились независимые проекты WFB-ng и Ruby (последний с закрытым исходным кодом).

Революция от OpenIPC

Классический сетап в проекте OpenHD (и других похожих проектов) состоит из MIPI- или USB- камеры, подключенной к Raspberry Pi и Jetson Nano, которые выступают видеоэнкодером и роутером воздушной системы и в свою очередь соединены с WiFi адаптером по USB и с полетным контроллером по UART. Наземная станция обычно состоит из такого же WiFi адаптера, роутера и высококонтрастного монитора или очков.

Иногда MIPI- или USB- камера меняется на IP-камеру, которая и мощнее (имеет свой собственный аппаратный энкодер) и стоит дешевле при аналогичных характеристиках. Большинство современных видеокамер являются типовыми embedded устройствами с Linux на борту (но значительно скромнее в размерах RAM и флеш памяти по сравнению с Raspberry и Jetson), что позволяет перекомпилировать и запускать на них практически любое переносимое ПО.

В процессе работы с данной технологией возникла идея об упрощении полетной системы и переноса всего необходимого ПО непосредственно на IP-камеру. Технически FPV прошивка проекта OpenIPC представляет собой специальную сборку с двумя типами драйверов популярных WiFi адаптеров, стримера Majestic (который выполняет роль GStreamer в классической схеме на системе-передатчике) и WFB-ng.

Преимущества

• Снижается стоимость системы (IP камера с поддержкой H.265 против аналога на Jetson Nano с MIPI камерой)
• Снижается общее потребление и увеличивается надежность системы за счет упрощения схемы
• Снижается задержка передачи видео: на наших Glass-to-Glass тестах мы получали для 1080p@60 задержку около 80ms (на среднебюджетных камерах), и для 720p@60 около 60 ms и 1080p@30 около 100 ms (для самых бюджетных камер)
• Появляется возможность тюнинга аппаратного энкодера, например более частого формирования I кадра (специфика сильно зависит от вендора IP камеры)
• Сообществом накоплен огромный опыт ремонта IP камер, что позволяет еще более удешевить стоимость эксплуатации системы

Недостатки

• Из-за ограниченных ресурсов (установленной оперативной и постоянной памяти) большинство модных языков программирования (таких как Java, Python, NodeJS) камера не потянет. Если любите писать на этих языках (или хотите портировать ПО, написанное на этих языках на камеру), то придется искать решения. Замена флеш памяти на более емкую принесет радость в дом Golang и Rust разработчиков.
• Придется немного паять, чтобы доработать до ума сверхбюджетные платы, но уверен, что в мире FPV никого этим не испугать
• В большинстве систем версия ядра Linux ограничена вендором IP камеры из-за того, что часть модулей поставляются в бинарном виде. Доработка драйверов ядра новых WiFi адаптеров или специфической периферии может потребовать значительного времени.
• На бюджетных камерах (для которых в первую очередь разрабатывалась FPV прошивка) очень ограниченные ресурсы, поэтому на момент написания этого текста возможностей запуска нейронных сетей нет. Ситуация должна измениться в ближайшем будущем.

Ингредиенты

• IP-камера. Учитывая популярность среди FPV сообщества модели VEYE 307, мы рекомендуем приобрести плату IVG-G2S IP камеры производства компании XiongMai с точно таким же сенсором IMX307, но по более приятной цене (или еще более приятной, если есть возможность покупки на Taobao, например, через посредника). При заказе платы укажите, фокусное расстояние объектива, который установит продавец под ваш заказ (больше фокусное расстояние - больше увеличение, но меньше угол обзора). В дальнейшем объектив можно поменять на другой с такой же резьбой, либо сразу купить несколько моделей на выбор (стандартом в мире видеонаблюдения считается 3.6мм). Плата IP-камеры питается от 12V (фактически достаточно 5V, если не использовать ее как видеокамеру вместе с подсветкой) и для начальных тестов желательно взять сразу совмещенный кабель питание-Ethernet, который бывает двух типов: 12V с подключением блока питания через джек и активный PoE 48V (выбирайте в зависимости от возможностей вашего сетевого коммутатора).

• WiFi адаптер. В настоящий момент FPV прошивка поддерживает два типа драйверов для чипов RT8812au и AR9271 (но в принципе никто не мешает добавить другие адаптеры). Крайне рекомендуется с обоих сторон линка использовать одинаковые адаптеры (более того, брать их из одной партии парами) и использовать только 5GHz частоты с связи с полной перегрузкой 2.4GHz. Прошивка протестирована с двумя адаптерами на RT8812au и AR9271 (последний упомянутый чип работает только на частоте 2.4GHz).

• UART-USB адаптер на 3.3V. Обратите внимание, что использование 5V адаптера может сжечь вашу камеру. Не покупайте/не используйте адаптеры на базе PL2303, хотя и стоят они дешевле, они не будут работать с данным SoC. Указанный в предыдущем пункте программатор умеет работать UART адаптером, поэтому если он есть, то отдельный можно не покупать.

• Коннекторы с разъемами типа JST 1.25 в конфигурации 3 Pin и 8 Pin для подключения к UART порту камеры и замены штатного кабеля питания-Ethernet в полетном варианте.

Опционально:

• Микросхема SPI NOR флеш памяти от 16 мегабайт и выше на замену стандартной 8 мегабайтовой. Рекомендуем W25Q128FVIQ или любую другую совместимую с прошивкой (новые модули также могут быть добавлены в проект по ID микросхемы). Обратите внимание, что на рынке представлено очень много подделок под Winbond и необходимо тщательно выбирать продавца.

• Программатор SPI NOR для флеш памяти. В принципе можно обойтись без него средствами проекта burn, который позволяет заливать систему в пустой/убитый флеш (см. раздел Заливка образа на пустую флеш с помощью burn). Обратите внимание, что хотя у многих программаторов есть в комплекте "прищепка", снимать дамп/программировать флеш память напрямую на плате категорически нельзя, из-за того, что программатор кроме микросхемы будет питать также всю остальную плату (есть вариант подрезать VCC ногу).

• Радиаторы на SoC приветствуются (как обычно не установлены производителем из-за удешевления).

• Светосильный объектив F0.95 (другие варианты раз и два) для полного раскрытия возможностей сенсора Sony IMX307 и приятных полетов ночью.

• Зум объектив 2.8-12мм. Обратите внимание, что в комплекте идет устаревшая плата IP камеры на базе HiSilicon 3516EV100, которую также можно перепрошить на OpenIPC. Так как плата, управляющая моторами, общается с основной платой через UART, то придется творчески решить вопрос с мультиплексированием двух UART портов или выводом нераспаянных контактов.

• FPC разъем на 16 pin для более качественной пайки подключения к USB адаптеру и соответствующий кабель.

Имеется два варианта использования прошивки OpenIPC на рассматриваемой плате: с заменой флеш памяти на более емкую (для установки собственных программ) и без замены (это проще, но в таком случае дальнейшие возможности расширения новой системы будут сильно ограничены). Далее рассматриваются по шагам оба этих варианта:

Установка на камеру (общее начало)

• Подключите кабель к камере и проверьте, что она работает (IP адрес по-умолчанию 192.168.1.10, ссылка для VLC "rtsp://192.168.1.10/user=admin&password=&channel=0&stream=0").
• Припаяйте трехпроводной разъем UART к свободным площадкам на плате камеры

• Подключите UART-USB адаптер к компьютеру (скорость порта 115200N1, управление потоком отключено, адаптер должен быть переведен в режим 3.3V, а не 5V) и проверьте, что при включении камеры идет вывод данных и вы можете прервать загрузку через Ctrl-C (работают обе RX и TX линии).

Установка на камеру (вариант без пайки флеш)

• Скачайте, распакуйте архив и запустите программу IP Cam DMS (английская версия), которая позволяет управлять камерой по протоколу производителя камеры.
• Скачайте специальный архив и проведите обновление прошивки, которое фактически сделает бесшовный переход с оригинальной прошивки на OpenIPC.

Установка на камеру (вариант с заменой флеш)

• Выключите камеру, отпаяйте оригинальную 8 мегабайтную SPI NOR флеш микросхему и сделайте на всякий случай ее дамп с помощью программатора. Отпаивать микросхему желательно феном, но если очень хочется можно воспользоваться обычным паяльником как предлагает Alexey Tolstov или вот так. После выпайки микросхемы площадки нужно хорошо очистить от остатков припоя куском медного кабеля. При работе феном желательно снять объектив и изолировать остальные компоненты, особенно пластиковые разъемы каптоновой лентой (на крайний случай фольгой от шоколадки). Ни в коем случае не используйте сплав Розе. Если не очень дружите с пальником, то проще зайти в ближайший сервис по ремонту мобильных телефонов и показать мастеру часть этой инструкции.

• Залейте U-Boot в новую 16 мегабайтную флеш (в начало памяти) и припаяйте его на плату. Проверьте, что U-Boot запускается и вы попадаете в строку приглашения.
• На рабочей станции установите TFTP сервер, скачайте и распакуйте в каталог архив с FPV прошивкой
• Дайте команды в U-Boot (где 192.168.1.17 - это ваш TFTP сервер, а 192.168.1.33 временно присвоенный адрес камере):

  setenv ipaddr 192.168.1.33; setenv serverip 192.168.1.17; saveenv
  run setnor16m
  #
  run uknor16m; run urnor16m

Установка на камеру (общее окончание)

• После загрузки системы, проверьте, что она получила IP адрес через Ethernet (на нее можно зайти по SSH через root@<IP адрес камеры> без пароля). Используя современную операционную систему и имя openipc.local можно найти камеру внутри локальной сети без знания ее IP адреса.
• Припаяйте к USB площадкам GND, DP и DM (USB 5V питание подключать к плате не нужно из-за высокого потребления энергии адаптером), а также отдельно 5V и GND для питания WiFi адаптера (возможно через дополнительный DC-DC преобразователь в зависимости от вашей схемы). USB провод, который подходит к плате, необходимо зафиксировать стяжкой во избежание отрыва пятаков на контактной площадке:

• Проверьте, что после загрузки через команду lsusb появилось новое устройство
• Проверьте, что команда free -m выдает не менее 34 мегабайт системного RAM (остальное отведено под видеопамять), в противном случае вам прямо во время полета может придти OOM killer (исправляется через fw_printenv bootargs / fw_setenv с коррекцией osmem=40M):

root@openipc-gk7205v200:~# free -m
              total        used        free      shared  buff/cache   available
Mem:             34          21           2           0           9           9
Swap:             0           0           0

Проверка работы наземной станции (на десктопе)

• Подключите второй адаптер к десктопу и скомпилируйте драйвер, который работает в режиме мониторинга (см. соответствующую документацию проекта) и при необходимости загрузите его через insmod
• Активируйте интерфейс (в данном примере wlan0 и укажите канал (в данном примере 14):

sudo ip link set wlan0 down
sudo iw wlan0 set monitor control
sudo iwconfig wlan0 channel 14
sudo ip link set wlan0 up

• Убедитесь, что на камере и десктопе на WiFi адаптерах установлена одинаковая частота через команду iwconfig, при необходимости смените частоту через редактирование конфига /etc/wfb.conf на камере (параметр channel) или командой sudo iwconfig <имя_адаптера> channel <номер> на десктопе.
• Скомпилируйте из исходного кода WFB-ng, обязательно используйте бранч stable, скопируйте ключ ./etс/gs.key с IP-камеры на десктоп и запустите прием sudo ./wfb_rx -p 0 -u 5600 -K gs.key -i 7669206 wlan0
• Проверьте, что в консоли вывод

32168228	PKT	0:0:0:0:0:0
32169229	PKT	0:0:0:0:0:0
32170230	PKT	0:0:0:0:0:0
32171231	PKT	0:0:0:0:0:0
32172232	PKT	0:0:0:0:0:0
32173233	PKT	0:0:0:0:0:0

сменится на

32178236	ANT	1	282:-54:-52:-50
32178236	ANT	0	282:-48:-46:-44
32178236	PKT	283:0:283:2:0:0
32179236	ANT	1	244:-54:-52:-50
32179236	ANT	0	244:-48:-45:-44
32179236	PKT	245:0:245:0:0:0
32180236	ANT	1	250:-54:-52:-50
32180236	ANT	0	250:-48:-45:-44

• Запустите Gstreamer gst-launch-1.0 -vvv udpsrc port=5600 ! application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! h264parse ! queue ! avdec_h264 ! autovideosink sync=false -e и проверьте качество изображения

Развитие наземной станции, телеметрия

Предполагается, что на машине под Linux установлен wfb-ng по инструкции с quick-start-using-ubuntu. В последующих примерах используется Хubuntu 18.04 LTS и wfb-ng 22.09.

• Запустите wfb-ng, запустите консоль wfb-cli:

sudo systemctl restart wifibroadcast@gs
wfb-cli gs

• Убедитесь, что идут пакеты видео. Здесь же можно видеть значения RSSI антенн WiFi адаптера:

Если значение recv остается нулем, а значение d_err растет - скорее всего, не совпадают ключи камеры и наземной станции. Убедитесь, что /etc/gs.key скопирован на наземную станцию. Если никаких пакетов нет - убедитесь, что channel=xx в /etc/wfb.conf на камере и wifi_channel=xx в /etc/wifibroadcast.cfg на земле имеют одинаковые значения. Для диапазона 5.8 ГГц адаптера RTL8812AU рекомендуется использовать каналы 60 и выше.

• Настройте полетный контроллер под ArduPilot на выдачу телеметрии в формате mavlink1 на скорости 115200 на, например, порту Serial1. В случае односторонней телеметрии (только вниз) убедитесь, что ПК выдает требуемый телеметрический поток по умолчанию, без соединения с наземной станцией. Это выполняется через установку параметров SR1_xxx, см. mavlink SR_ parameters.
• Соедините Serial1 ПК c UART камеры, rx на tx, tx на rx. В случае современных ПК на STM32F4/7 уровни напряжения совпадают (3.3В), в случае 5В APM потребуется преобразование уровней. Тонкость - загрузчик U-Boot камеры на загрузке останавливается, получив на вход UART любые байты. ПК должен начать выдавать телеметрию c задержкой на несколько секунд, через установку параметра TELEM_DELAY. На столе проще предусмотреть разрыв в линии от ПК к камере.
• На камере в файле /etc/datalink.conf установите параметр telemetry=true , в файле /etc/telemetry.conf - параметр one_way=true для односторонней или one_way=false для двустронней телеметрии соответственно. Простейший способ правки файлов на камере - Shell Link в Midnight Commander:

• Перезапустите камеру и сервис wfb-ng. В wfb-cli должен появиться второй поток данных - телеметрия:

• Установите QGroundControl. Здесь используется версия 4.0.11 из-за некорректной работы последних версий с видео в 18.04 LTS. Новые Comm Links создавать не нужно. QGC должен увидеть соединение с ПК и отображать входной поток телеметрии:

В случае двусторонней телеметрии QGC должен загрузить параметры, позволять их менять, позволять переключать полетные режимы, загружать и выгружать миссии:

Видно, что QGS также уже отображает видео. Задержка в 4.0.11 довольно значительна из-за чисто программной обработки потока, разумно пробовать современные версии под Ubuntu 20.04 и новее.

Траблшутинг

• Через команду sudo tcpdump -i wlan0 на десктопе без запуска WFG-ng вы можете проверить, что передатчик действительно отправляет пакеты в эфир:

Заливка образа на пустую флеш с помощью burn (если нет программатора)

Запускаем burn при выключенной плате:

./burn --chip gk7205v200 --file=u-boot-gk7205v200-universal.bin -d ; screen -L /dev/ttyUSB0 115200

включаем питание платы и ждем заливки U-Boot и появления командной строки. Далее выполяем следующие команды, где 192.168.0.8 - адрес TFTP сервера и 192.168.0.200 - временный адрес IP камеры.

setenv ipaddr 192.168.0.200
setenv serverip 192.168.0.8

sf probe 0; sf lock 0
mw.b 0x42000000 ff 1000000; tftpboot 0x42000000 u-boot-gk7205v200-universal.bin; sf probe 0
sf erase 0x0 0x50000; sf write 0x42000000 0x0 ${filesize}
reset

run setnor16m

setenv ipaddr 192.168.0.200
setenv serverip 192.168.0.8

run uknor16m ; run urnor16m

saveenv
reset

Дальнейшие доработки

Разработка платы-адаптера

Учитывая, что по тексту выше мы дорабатывали плату от обычной бюджетной камеры видеонаблюдения и монтаж USB коннектора производился без заводских разъемов, напрашивается вариант сделать дополнительную специальную плату (похожую на плату со встроенным WiFi адаптером), на которой будут выведены разъемы для USB (возможно с дополнительным хабом) и SD карты. Это позволит передавать видео в эфир с минимальной задержкой в 720p, одновременно записывая оригинал в 1080p для последующей публикации на YouTube). Если у вас есть возможность разработать такую плату и поделиться схемой с сообществом, мы будем очень признательны.

FAQ

Сколько потребляет камера во время своей работы?

Потребление зависит от того, включен ли сенсор (который сам по себе является одним из больших потребителей) и по нашим замерам составляет 1.7W в активном режиме и y 1.1W при выключенном сенсоре (но работающей основной системе). Отсюда можно сделать вывод, что при необходимости можно программно выключать/включать стример, чтобы еще больше уменьшить потребление системы, в те моменты когда это необходимо.

Дополнительно стоит рассмотреть:

• Возможность программного выключения Ethernet адаптера через N минут после старта системы (составив работу сразу после старта для возможности смены настроек и отладки)
• Перевести все неиспользуемые GPIO в input режим
• Свериться с даташитом и отключить с помощью регистров все неиспользуемые функциональные блоки чипа

Поддерживается ли WDR?

Для полноценной работы WDR на IP камерах как основной чип так и сенсор оба должны поддерживать одинаковый стандарт WDR (их существует несколько типов). При этом обычно сенсор начинает работать на двойной частоте (например, 60FPS вместо 30FPS), делая один кадр с длинной выдержкой, второй - с короткой. Далее ISP (Image Signal Processor) аппаратно производит склейку из двух кадров одного, взяв темные участки с кадра с длинной выдержкой и светлые - с короткой, формируя изображение с расширенным цветовым диапазоном. К сожалению, для получения WDR изображения вся система должна работать как минимум в два раза быстрее (или говоря по-другому иметь больше транзисторов, делая в два раза больше работы в момент времени), поэтому в процессоре Goke V200 этого режима нет. Если вам принципиальна поддержка WDR, рассмотрите возможность использования следующей в линейке процессоров V300, который также поддерживается проектом.

Можно ли вместо WiFi использовать LTE адаптер?

Можно, но потребуется модификация прошивки. Рекомендуем вопрос по адаптации конкректного оборудования задавать в официальной группе.

Можно ли подключить SD карту для записи видео?

Можно. Фотография от подписчика:

Таблица распиновки вспомогательного разъема:

Какую дополнительную периферию еще можно подключить?

Исходя из распиновки нераспаянного FC разъема, показанного выше, видно, что он используется для дополнительных плат расширения с WiFi (по USB) и SD картой. Неиспользуемые пины можно переназначить следующим образом:

Функция	Дополнительно
SD_CLK	GPIO32
SD_CMD	GPIO33
SD_DATA0	GPIO34
SD_DATA1	GPIO35
SD_DATA2	GPIO36
SD_DATA3	GPIO37
ALARM2_GPIO82
KEY_SET
BAT
ALARM_OUT

D/N (day/night) можно использовать только как входящий GPIO15 (из-за установленного транзистора). Слева от него на том же разъеме находится GND и GPIO16 (который можно использовать как GPIO в двухстороннем режиме или PWM порт).

На разъеме питание-сеть имеются два GPIO (ETH_STA - GPIO14, ETH_ACT - GPIO12), которые обычно используются для отображения активного физического подключения Ethernet и активности при передачи данных. Их также можно использовать для обычные двусторонние GPIO, причем GPIO12 возможно перевести в режим UART2_RXD и реализовать дополнительный одностронний UART порт (только на прием данных). На этой плате на данных контактах установлены резисторы 330Ом, но это не должно повлиять на работу UART.

Учитывая, что корпус SoC выполнен в формате QFN88, имеется возможность припаяться тонким проводом практически к любой ножке микросхемы и задействовать дополнительные порты. Распиновка чипа и фотография реальной платы без чипа представлены ниже:

Обратите внимание, что такое решение далеко от промышленного (в идеале нужно изготовить собственную плату) и если его не избежать, рекомендуется спиливание корпуса чипа для более надежного контакта.

Можно ли использовать другую IP камеру?

Если у вас есть скиллы продвинутого пользователя Linux, то вы можете присоединиться к нашему проекту и адаптировать FPV прошивку под любой процессор, поддерживаемый OpenIPC. В большинстве случаев навыки программирования не требуются (либо вы получите их естественным путем в процессе знакомства и изучения системы).

Как еще больше можно уменьшить задержку передачи видео?

Чтобы получить минимально возможную задержку, в нашей прошивке используется режим низкой задержки (low latency), который имеется в процессорах HiSilicon/Goke. При этом конкретные значения зависят от модели SoC, сенсора, его разрешения, текущая выдержка кадра и даже нагрев чипа в процессе работы. Основную лепту в задержку вносит FPS системы (60FPS без всякого тюнинга будет лучше 30FPS с максимально выкрученными настройками), поэтому если вам важна низкая задержка обратите внимание на более дорогое железо. Для получения еще меньшей задержки возможно отключения промежуточных блоков за счет ухудшения качества картинки либо перехода на более современные чипсеты.

У нашей команды есть большой опыт передачи медиаинформации с низкой задержкой (на ряде проектов были достигнуты цифры задержки в 45ms). Если вас интересуют коммерческие услуги (консалтинг, разработка аппаратного и программного обеспечения, реверс-инжиниринг) свяжитесь с нами.