Беспроводная передача видео в full HD
Увы, кроме Си, ничем не владею…
меньше секунды ?
Да вы что… Кажется в районе 50-100мс… Как-нибудь проверю, уточню. От разрешения практически не зависит, проверял правда до 720p, дальше старенький ноут не справлялся. Вывод был- конечно не для активного пилотажа, но вполне…
туда управление - назад видео, и вообще понять насколько это возможно и какими средствами
Никаких проблем, вопрос только в дальности WiFi соединения… И тут уже давно намечено пока одно приемлимое решение- ubiquiti.
И тут уже давно намечено пока одно приемлимое решение
А что с broadcast?
Это другой уровень, туда не лез (только до стека IP)… Кстати, еще объективных оценок по его преимуществу относительно обычного WiFi-коннекта в реале не видел. (видимо оно есть, но сколько в граммах?..)
Это другой уровень, туда не лез
В идеале надо в ядро линукса драйвер ставить… Но к сожалению даже для “народной” игрушки типа raspberry доступ к видеоядру засекречен…
Квадрокоптер c Pixhawk на борту. На планшете установлена QGroundcontrol с поддержкой Gstreamer. Передаю по wi-fi как видео, так и телеметрию. Gstreamer прост в настройке и отлично справляется со своей задачей – картинка в разрешении HD идёт с минимальным лагом.
Экспериментировал с FullHD – лаг на том же уровне, но существенно уменьшается дальность уверенного приёма сигнала: появляются артефакты и т.д. Антенны – клеверы с алиэкспресс.
Перепробовал весь модельный ряд малины – остановился на 2B+ и точках Ubiquiti Bullet M5. Единственное, вытащил пулю из корпуса и перепаял разъём для антенны с N-type на SMA, чтобы уменьшить вес модуля. Крепёж распечатал на 3d принтере, получилось вполне эстетично. Дальность уверенной передачи HD-видео с китайскими клеверами – порядка 500-600 м при отсутствии препятствий.
О достоинствах и недостатках: видеть качественную картинку непосредственно в QGroundcontrol – несомненный плюс для любителей pixhawk/apm. Переключение с карт на видео происходит одним касанием. Команды отправляются без проблем. Настройка происходит без танцев с бубном, несмотря на присутствие Linux. Процесс настройки соединения Raspberry и Pixhawk по разъёму телеметрии подробно и с картинками описан в нете. Недостатки для себя отметил следующие: вес малины, точки доступа, модуля камеры, шлейфа, антенны и крепежа – около 200 грамм. Не самоё бюджетное, но вполне надёжное решение для полётов по камере на небольшие расстояния.
Может стоило бы эту башенку под брюхом центральной чести коптера разместить? Профиль конструкции бы уменьшился, что положительно бы сказалось на аэродинамическом сопротивлении и прибавило бы время полета.
Дальность уверенной передачи HD-видео с китайскими клеверами – порядка 500-600 м при отсутствии препятствий.
При переходе на WIFI Broadcast получите вдвое большее расстояние не той же мощности.
точки доступа,
Точка доступа зачем ? (она отдельная что ль?), ведь на малине ее можно легко организовать …
Точка доступа зачем ? (она отдельная что ль?), ведь на малине ее можно легко организовать …
Мост построен на двух Ubiquiti Bullet M5. Одна пуля (точка доступа) - на земле, вторая (клиент) – на коптере. Пуля, установленная на коптере соединена витой парой с Raspberry Pi. К наземной точке по wi-fi подключён планшет с установленной QGroundcontrol.
У меня есть система, построенная на свистке, но мне она не очень нравится. У малины весьма ограничен набор предустановленных дров под свистки на 5 ГГц. Приходится собирать дрова самостоятельно или искать на гитхабе готовые решения. Во-вторых, запуск точки доступа на малине дополнительно нагружает систему. При передаче изображения в разрешении HD, передаче телеметрии по Mavlink и работе малины в режиме точке доступа я боролся с лагом видео. Хотя, может я что-то криво настроил…
Точка доступа зачем ? (она отдельная что ль?), ведь на малине ее можно легко организовать …
Raspberry Pi Zero v1.3 со свистком asus usb-ac51. Тоже рабочая схема, будет стоять на f450
У меня пока результаты опытов “так себе”…
Задержку видео можно сделать минимальную без особых заморочек (либо связка raspivid->socat->udp, либо вместо socat-a свой примитивный сервер на СИ с сокетами), правда это испытано только на столе, хотя помехи и сбои всеравно периодически дают непредсказуемый лаг картинки…
А вот при двунаправленной связи, которую и хотелось в принципе, тормоза уже неприемлимые (опасные для ЛА)…
Соответственно делаю вывод: “нахаляву” этот номер не пройдет, либо надо лезть в дебри линукса, что скорей всего закончится полным отказом от него… как такового , либо управлять “луноходом” и не париться… (тоже круто, кстати)
У меня пока результаты опытов “так себе”…
Задержку видео можно сделать минимальную без особых заморочек (либо связка raspivid->socat->udp, либо вместо socat-a свой примитивный сервер на СИ с сокетами), правда это испытано только на столе, хотя помехи и сбои всеравно периодически дают непредсказуемый лаг картинки…
А вот при двунаправленной связи, которую и хотелось в принципе, тормоза уже неприемлимые (опасные для ЛА)…
Соответственно делаю вывод: “нахаляву” этот номер не пройдет, либо надо лезть в дебри линукса, что скорей всего закончится полным отказом от него… как такового , либо управлять “луноходом” и не париться… (тоже круто, кстати)
Олег, мне кажется, сравнение с луноходом несколько преувеличенно 😃 Задержка при двусторонней связи не превышает 150-200мс. Визуально это сопоставимо с лайтбриджем на фантомах, а они как то летают… Я согласен, что для полёта на гоночном дроне между деревьев это неприемлемо, но для спокойных FPV полётов на аппаратах 450 размера и более - вполне терпимо. Мой вариант с точками Ubiquiti сводится к установке Gstreamer’а на Raspberry Pi и настройке моста между двумя пулями. Причём двусторонняя связь позволяет отправлять команды и настройки с планшета на дрон прямо в полёте
последняя реализации у dji та что на мавике работает пошустрее чем 150-200мс
сравнение с луноходом несколько преувеличенно
Тогда сразу вопрос: у Вас не выскакивают периодически (непредсказуемо) “провалы” в связи ?
Тут вопрос даже не в самом сбое , а в том как быстро система из них способна восстановиться, или не-восстановиться… короче говоря в надёжности.
сопоставимо с лайтбриджем на фантомах
Ну там наверно не так примитивно сделано, наверно люди поработали, возможно пожертвовали задержкой в угоду надежности… (ИМХО)
Тогда сразу вопрос: у Вас не выскакивают периодически (непредсказуемо) “провалы” в связи ?
Тут вопрос даже не в самом сбое , а в том как быстро система из них способна восстановиться, или не-восстановиться… короче говоря в надёжности.
Ну там наверно не так примитивно сделано, наверно люди поработали, возможно пожертвовали задержкой в угоду надежности… (ИМХО)
Олег, непредсказуемых провалов пока не было. Были лаги и артефакты, вызванные конкретными причинами: наводки на шлейф камеры и 100% загрузка процессора Raspberry Pi. Причины были вылечены. Сейчас наиболее вероятен сбой, связанный с потерей wi-fi соединения (препятствие/дальность), но в этом случае точки Ubiquiti быстро друг друга находят
Именно для предсказуемости результата, я разбивал поток на кадры сразу в малине и передавал их пронумерованными в отдельных пакетах. Не приходит один кадр- появляются небольшие артефакты до следующего ключевого кадра. Частоту передачи ключевых кадров можно задавать в raspivid, и для динамической картинки ее можно делать довольно частой, без серьезного увеличения трафика (размеры дельта-кадров соизмеримы с ключевыми). Кроме того, с таким потоком легче и надежнее работать на приеме: более-менее равномерно приходящие пакеты надежнее принимаются в потоке Win (в принципе без потерь даже на слабой машине при надежном линке, а сколько вопросов по этому поводу задают…), ну и Source Filter заметно упрощается.
я разбивал поток на кадры сразу в малине
Чет пока не получается у меня из raspivid-a найти “кадровые метки”, ерунда какая то лезет… Вроде ищу последовательность байт 0х00 0х00 0х00 0х01 типа начало заголовка NALU… , а результат какой то странный (явно не правильный).
Где то в потоке что то не то, что пишут, хотя есть программа SecialVH264.exe, она вроде всё находит как надо и заголовки и блоки… короче разбираться надо… читать матбазу на H.264
я разбивал поток на кадры сразу в малине
Разобрался я с H.264… легче не стало…
Делаю так: читаю в буфер два кадра (что б начало и конец полюбому попадало в него) это ~200 Кб, нахожу начало и конец, считаю количество байт, отправляю по воздуху 1 найденный кадр, результат - суммарная задержка ~ 0.3-0.4 секунды…
Не знаю как у Вас получается быстрее (?)… вроде всё до безобразия оптимально и написано на Си… и на приеме тормозить не может, там еще всё проще - кадр из приемного буфера сразу в mpvplayer с аппаратным ускорением (у меня)…
Что я делаю не так ?
fpv.blue обещают в конце января свой хд линк выпустить. 900-1.2частота задержка 50мс дальность 7км очень заманчиво.
fpv.blue обещают в конце января свой хд линк выпустить. 900-1.2частота задержка 50мс дальность 7км очень заманчиво.
Они с мая прошлого года обещают. Обещанного три года ждут как говорится 😁
НУ летом они типа анонсировали, и говорят не хотим сырой продукт выпускать, выпустим как только допилим. Но ведь хочется верить.))