Управление через интернет
Есть готовый квадрик, кот. рулится ЯМобилкой. Наверно речь о нем.
или об этом www.microdrones.com/en_mc_videos.php 5 видео сверху
или об этом www.microdrones.com/en_mc_videos.php 5 видео сверху
именно
Пришел серво-контроллер, завтра продолжу разработку программы. Пока поигрался с утилитой от производителя, работает платка, крутит серву.
Встроил в программу поддержку серво-контроллера Pololu 24 канала. Проверил работу с сервомашинками и регулятором оборотов с бесколлекторным электродвигателем. В общем все почти готово. Осталось все баги отловить и оптимизировать. Завтра оплачу Йоту и посмотрю как с ней работает, в последние месяца полтора запускал оба модуля программы локально на одном компьютере.
Сделал кое-какие доработки в интерфейсе, теперь можно изменять режим срабатывания при нажатии клавиш клавиатуры “нажал-отпустил” и “нажал-нажал”, ползунки можно перемещать мышкой без джойстика, задавать количество активных каналов управления, появилась возможность делать изменение размера передаваемой видео-картинки, т.е. если камера выдает 640х480, можно сделать ресайз например до 640х320, получится “широкоформатный” режим, предположительно таким образом можно снизить битрейт, последние сделанные настройки теперь сохраняются.
С Yotой еще не тестировал.
ну когда же уже c Ядой;-)
ну когда же уже c Ядой;-)
Думаю на следующих выходных сделаю демо видео. Пока разрываюсь между sofware и hardware, параллельно думаю как сделать электро-стартер на авто 1/8 масштаба, некоторое продвижение уже есть, нужно мотор-редуктор закрепить понадежнее 😃 хомуты нужно выточить, и сам мотор-редуктор придется видимо с другим передаточным числом заказывать - чтобы побыстрей крутил. А на счет Yotы - с управлением больших проблем не предвидится, правда будет некоторая неплавность перемещения серво, из-за дискретности “выплевывания” команд с базы, проблемы ожидаются с видео, задержка будет довольно существенная, но я с этим по-тихоньку смиряюсь (сейчас почитываю тему про FY-21AP).
Попробовал я как с Yotoй все работает, как и ожидалось реакция управления вполне удовлетворительная, а вот видео никуда не годится, нужно переделывать, буду пробовать запасной вариант - передачу отдельных JPEG кадров по UDP. Так что обещанного видео на выходных не будет 😦
интересно, быстрей чем луноход будет? Сколько секунд до луны и обратно шел сигнал, 2?
Хм интересно, а если все же попробовать сформулировать требования к системе
- Работа без “лагов”.
Использование быстрой ЭВМ на борту позволяет снизить задержку вызываемую сжатием сигнала (у IP камеры все же другие задачи и задержка там обычное дело).
Передача сжатого видио через UDP позволит максимально сократить задержку.
Использование операционной системы реального времени или приближенной к таковой (сразу отметаем Windows да и в принципе все системы с графикой в приоритете, нам кино юзерам показывать не надо).
Linux без графики и лишних рюшечек обеспечит достаточное быстродействие.
- Аппаратура позволяющая организовать стабильный и быстрый IP радиоканал
Как человек пробрасывавший WiFi на 12 километров могу сказать усилитель сигнала и направленная антенна творят чудеса.
(правда на земле придется использовать систему автоматического позиционирования антенны)
- Механизм управления сервами
Сейчас их много делают для любителей роботов есть из чего выбрать.
- Наличие датчиков ориентации в пространстве.
Опять же их хватает и гироскопы и GPS.
в сухом остатке имеем примерно следующую систему
Имеем на борту
Wifi модуль с интерфейсом USB для этой платы $37.99
USB 2.0 хаб $1
Трехосевой компас , трехосевой гироскоп, трехосевой акселерометр в одной плате интерфейс USB.
$142,5
Датчик GPS с интерфейсом Serial TTL $59,95
32 канальная аппаратура управления сервами c интерфейсом Serial TTL $39,95
Наземная станция
Направленная сетевая карта - антенна, усиление 38.5dBm $165.05
8 канальная аппаратура управления сервами (для позиционирования направленной антенны на земле) $19.95
Все указанные устройства прекрасно работают с Linux и имеют либо драйвера под него либо открытую архитектуру.
Такая система по сути способна обеспечить не просто телеметрию - это оборудование для полностью автономного полета и.т.д.
Итого цена за все $591,41
Суммарное энергопотребление аппаратуры на борту порядка 500мА. Многовато, но жить можно.
В общем если это все собрать и разработать соответствующее ПО то будет счастье. Смотря на шедевры которые разрабатывают участники форума я не сомневаюсь, что это достижимо, но имхо тут нужна команда.
Один пишет систему позиционирования антенны на ЛА, другой сжатие и передачу картинки и.т.д. Одному человеку думаю все это не осилить.
Может интересующийся народ соберется и сделает Open Sorce проект сделали же ребята открытую платформу для разработки роботов 😁
UncleSam, спасибо за ценную информацию!
интересно, быстрей чем луноход будет?
Сервы реагируют очень хорошо, меня полностью устраивает скорость реакции, замеров не производил, но там может миллисекунд 200. Видео посредством библиотек VLC в MJPEG передается очень плохо, дело не в задержках, а в потерях пакетов, не видно ничего кроме сплошных сбоев.
Добавлю: причина предположительно в том, что VLC разбивает каждый кадр на разные пакеты и отправляет кадр по-кусочкам, при этом после прохождения по UDP, пакеты приходят не в том порядке, в котором отправлялись, и кадр склеивается не правильно. Плюс еще потери пакетов.
UncleSam, спасибо за ценную информацию!
Сервы реагируют очень хорошо, меня полностью устраивает скорость реакции, замеров не производил, но там может миллисекунд 200. Видео посредством библиотек VLC в MJPEG передается очень плохо, дело не в задержках, а в потерях пакетов, не видно ничего кроме сплошных сбоев.
Добавлю: причина предположительно в том, что VLC разбивает каждый кадр на разные пакеты и отправляет кадр по-кусочкам, при этом после прохождения по UDP, пакеты приходят не в том порядке, в котором отправлялись, и кадр склеивается не правильно. Плюс еще потери пакетов.
Скорее всего проблема именно в потере пакетов.
Картинка упаковывается, затем разбивается на блоки максимум 1500 байт и передается. При потере одного пакета или при их перестановке картинку собрать не получится.
Думаю обычные кодеки тут не подойдут нужно делать что то свое.
Имхо необходимо программно контролировать своевременность и порядок доставки пакетов.
Например разрезать весь кадр на области, каждая из которых при сжатии гарантированно займет места не больше 1400 байт, добавить туда информацию о номере кадра и местоположении области в кадре. Получится всю информацию о конкретной области упаковать. Таким образом умещаем все в одну датаграмму, потеря которой не затронет остальную картинку и перестановка пакетов местами не скажется.
При получении такой датаграммы, мы знаем номер кадра к которому она относится и местоположение данных.
Если датаграмма устарела (кадр уже показан) убиваем ее сразу.
Если кадр еще не показан распаковываем данные в соответствующее место кадра. Если какая либо область кадра не была обновлена (датаграмма утеряна), подставляем данные из предыдущего кадра. (Можно организовать небольшой буфер максимум 2-3 кадра).
Используя черезстрочную развертку для 640х480 можно передавать кадры 320х480, качество ухудшится незначительно, уменьшим видеопоток вдвое (в телевизоре именно так все работает).
В общем для видео рулит оптимизация под конкретную задачу и отказ от стандартных кодеков.
разрезать весь кадр на области, каждая из которых при сжатии гарантированно займет места не больше 1400 байт
Почему 1400 байт? Максимальный размер датаграммы - 64Кб, я пробовал передавать JPEG размером около 50Кб. Проблема в том, что в 64Кб нужно уложить 1 секунду видео, потому как Yota больше не потянет, по моим замерам выходило 300-500Кбит/сек.
Получилось передать видео отдельными JPEGами, идет без потерь пакетов. Теперь нужно поработать над снижением битрейта, т.к. через несколько секунд начинает накапливаться задержка и продолжает расти, может у кого-то будут мысли как это побороть?
Почему 1400 байт? Максимальный размер датаграммы - 64Кб, я пробовал передавать JPEG размером около 50Кб. Проблема в том, что в 64Кб нужно уложить 1 секунду видео, потому как Yota больше не потянет, по моим замерам выходило 300-500Кбит/сек.
Это вы можете сделать датаграмму размером 64k, в реальности у всех систем передачи есть параметр MTU - максимальная длина передаваемого кадра, для ethernet - 1500 байт, для GPRS -1400, для DSL - 1492, для WiFi - 1500. (На самом деле тут все сильно зависит от оборудования).
Все что длиннее будет разбито на блоки такой длины, либо непосредственно вашим компьютером (информация разбивается на пакеты c длиной MTU вашей системы), либо транзитным оборудованием (фрагментация пакетов).
Засада в том, что если пакет фрагментирован, он не будет передан с сетевого уровня операционной системы на уровень приложений до тех пор, пока не придут все кадры и система не сможет из них собрать полный пакет. В результате один задержавшийся пакет создает задержку для всех остальных, а один потерянный пакет гробит всю датаграмму, так как она не может быть верно собрана. В общем таким образом поучаете минимум лишнюю задержку.
Лучше изначально закладывать передачу блоками по 1400-1450 байт.
Теперь нужно поработать над снижением битрейта, т.к. через несколько секунд начинает накапливаться задержка и продолжает расти, может у кого-то будут мысли как это побороть?
Попробуй черезстрочную развертку - уменьшишь битрейт 2 раза при той же частоте кадров. Правда получишь расческу при резких поворотах камеры, но с ней можно бороться фильтрами.
Подумай над возможностью синхронизации видео путем пропуска кадров.
В общем за работу респект и уважуха.
интересно, быстрей чем луноход будет? Сколько секунд до луны и обратно шел сигнал, 2?
В луноходе минимальный лаг был 2.5с - это время сигнала туда-сюда. На практике лаг был 10-15с, т.к. там использовалось малокадровое телевидение с переменной частотой кадров, кот. зависила от к-ва приема.
Использование быстрой ЭВМ на борту позволяет снизить задержку вызываемую сжатием сигнала (у IP камеры все же другие задачи и задержка там обычное дело).
Тут дело не в ресурсах ЦПУ, а в технологии сжатия. Задержка вызвана применением межкадровой компрессии с большой длиной блока. иначе надо будет очень большой поток.
Попробуй черезстрочную развертку - уменьшишь битрейт 2 раза при той же частоте кадров. Правда получишь расческу при резких поворотах камеры, но с ней можно бороться фильтрами.
Так можно и отображение черезстрочно организовать. Сначала 1 полувину растра, а потом вторую. Как в ТВ. А вообще, если не вредничать, то картинки 320х240 вполне достаточно. Вспомните как раньше смотрели фильмы на VCD.
Такие мысли по оптимизации:
- Отправка кадров по таймеру 60-80 миллисекунд (во вчерашней эксперементальной программе - отправка нон-стоп)
- Отправка кадров порциями по 2-3 секунды до поступания команды на отправку следующей порции с базы
2.1 Команда с базы на отправку следующей порции кадров при опустошении очереди - Проверка времени отправки кадра на борту и отбрасывание устаревших кадров перед отправкой
- Снижение качества JPEG для уменьшения битрейта (разрешение, % качества JPEG, уменьшение количества цветов, черезстрочность, “широкоформатный” режим)
Когда-то баловался передачей видео по сети DirectShow+UDP. Тестовая программулька где-то осталась в BCB, если хотите (ну там кодеками поиграться…) могу поискать, скинуть с исходниками.
Когда-то баловался передачей видео по сети DirectShow+UDP.
Какие у вас были результаты? Какого FPS удалось добиться, при каком разрешении? Какая задержка была, насколько пригодно для FPV в реальном времени?
DirectShow+UDP
Я сейчас тоже использую эту связку и приятно удивлен скоростью, если с VLC при передаче видео с компа на самого себя уже возникала задержка около секунды, то тут ее практически нет.
Проект начинался для видеоконференции в локалке, но умер не родившись по независившим от меня причинам… В приципе комп-комп все работало дуплексом без проблем в 100мб-сетке (ну еще бы… 😃). От разрешения и выбранного кодека изменялась только загрузка сети. Задержки в большей степени зависили от кодека и его настроек… У Вас несравнимо более сложная задача и по требованиям к задержке, и по ширине да еще и нестабильности канала…