Специальные цены   новые товары
Закрытая тема
Страница 3 из 10 ПерваяПервая 1 2 3 4 5 ... ПоследняяПоследняя
Показано с 81 по 120 из 387

Управление через интернет

Тема раздела Полеты по камере, телеметрия в категории Cамолёты - Общий; Сообщение от cstrike или об этом http://www.microdrones.com/en_mc_videos.php 5 видео сверху именно...

  1. #81

    Регистрация
    13.02.2010
    Адрес
    Liepaja,LV
    Возраст
    46
    Сообщений
    1,191
    Цитата Сообщение от cstrike Посмотреть сообщение
    или об этом http://www.microdrones.com/en_mc_videos.php 5 видео сверху
    именно

  2.  
  3. #82

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Пришел серво-контроллер, завтра продолжу разработку программы. Пока поигрался с утилитой от производителя, работает платка, крутит серву.

  4. #83

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Встроил в программу поддержку серво-контроллера Pololu 24 канала. Проверил работу с сервомашинками и регулятором оборотов с бесколлекторным электродвигателем. В общем все почти готово. Осталось все баги отловить и оптимизировать. Завтра оплачу Йоту и посмотрю как с ней работает, в последние месяца полтора запускал оба модуля программы локально на одном компьютере.

  5. #84

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Сделал кое-какие доработки в интерфейсе, теперь можно изменять режим срабатывания при нажатии клавиш клавиатуры "нажал-отпустил" и "нажал-нажал", ползунки можно перемещать мышкой без джойстика, задавать количество активных каналов управления, появилась возможность делать изменение размера передаваемой видео-картинки, т.е. если камера выдает 640х480, можно сделать ресайз например до 640х320, получится "широкоформатный" режим, предположительно таким образом можно снизить битрейт, последние сделанные настройки теперь сохраняются.


    Нажмите на изображение для увеличения
Название: IPFPV.jpg
Просмотров: 82
Размер:	73.5 Кб
ID:	453240

    С Yotой еще не тестировал.

  6.  
  7. #85

    Регистрация
    01.03.2006
    Адрес
    Киров
    Возраст
    44
    Сообщений
    1,585
    Записей в дневнике
    1
    ну когда же уже c Ядой;-)

  8. #86

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от SGordon Посмотреть сообщение
    ну когда же уже c Ядой;-)

    Думаю на следующих выходных сделаю демо видео. Пока разрываюсь между sofware и hardware, параллельно думаю как сделать электро-стартер на авто 1/8 масштаба, некоторое продвижение уже есть, нужно мотор-редуктор закрепить понадежнее хомуты нужно выточить, и сам мотор-редуктор придется видимо с другим передаточным числом заказывать - чтобы побыстрей крутил. А на счет Yotы - с управлением больших проблем не предвидится, правда будет некоторая неплавность перемещения серво, из-за дискретности "выплевывания" команд с базы, проблемы ожидаются с видео, задержка будет довольно существенная, но я с этим по-тихоньку смиряюсь (сейчас почитываю тему про FY-21AP).

  9. #87

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Попробовал я как с Yotoй все работает, как и ожидалось реакция управления вполне удовлетворительная, а вот видео никуда не годится, нужно переделывать, буду пробовать запасной вариант - передачу отдельных JPEG кадров по UDP. Так что обещанного видео на выходных не будет

  10.  
  11. #88

    Регистрация
    01.03.2006
    Адрес
    Киров
    Возраст
    44
    Сообщений
    1,585
    Записей в дневнике
    1
    интересно, быстрей чем луноход будет? Сколько секунд до луны и обратно шел сигнал, 2?

  12. #89
    Давно не был
    Регистрация
    18.01.2011
    Адрес
    Хабаровск
    Возраст
    35
    Сообщений
    23
    Хм интересно, а если все же попробовать сформулировать требования к системе

    1. Работа без "лагов".
    Использование быстрой ЭВМ на борту позволяет снизить задержку вызываемую сжатием сигнала (у IP камеры все же другие задачи и задержка там обычное дело).
    Передача сжатого видио через UDP позволит максимально сократить задержку.
    Использование операционной системы реального времени или приближенной к таковой (сразу отметаем Windows да и в принципе все системы с графикой в приоритете, нам кино юзерам показывать не надо).
    Linux без графики и лишних рюшечек обеспечит достаточное быстродействие.

    2. Аппаратура позволяющая организовать стабильный и быстрый IP радиоканал
    Как человек пробрасывавший WiFi на 12 километров могу сказать усилитель сигнала и направленная антенна творят чудеса.
    (правда на земле придется использовать систему автоматического позиционирования антенны)

    3. Механизм управления сервами
    Сейчас их много делают для любителей роботов есть из чего выбрать.

    4. Наличие датчиков ориентации в пространстве.
    Опять же их хватает и гироскопы и GPS.

    в сухом остатке имеем примерно следующую систему

    Имеем на борту

    Бортовой компьютер ARM920T 532MHz, SDRAM 64Mbyte, 128M Flash, USB, LAN, 3 serial TTL, 10x10 cm (без экрана) $99

    Камера курсовая (интегрируется в вышеуказанную плату скорость обработки выше чем через USB или отдельную IP камеру) $ 18,52

    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 проект сделали же ребята открытую платформу для разработки роботов

  13. #90

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    UncleSam, спасибо за ценную информацию!


    Цитата Сообщение от SGordon Посмотреть сообщение
    интересно, быстрей чем луноход будет?
    Сервы реагируют очень хорошо, меня полностью устраивает скорость реакции, замеров не производил, но там может миллисекунд 200. Видео посредством библиотек VLC в MJPEG передается очень плохо, дело не в задержках, а в потерях пакетов, не видно ничего кроме сплошных сбоев.


    Добавлю: причина предположительно в том, что VLC разбивает каждый кадр на разные пакеты и отправляет кадр по-кусочкам, при этом после прохождения по UDP, пакеты приходят не в том порядке, в котором отправлялись, и кадр склеивается не правильно. Плюс еще потери пакетов.
    Последний раз редактировалось Korogodsky; 19.01.2011 в 13:15.

  14. #91
    Давно не был
    Регистрация
    18.01.2011
    Адрес
    Хабаровск
    Возраст
    35
    Сообщений
    23
    Цитата Сообщение от Korogodsky Посмотреть сообщение
    UncleSam, спасибо за ценную информацию!



    Сервы реагируют очень хорошо, меня полностью устраивает скорость реакции, замеров не производил, но там может миллисекунд 200. Видео посредством библиотек VLC в MJPEG передается очень плохо, дело не в задержках, а в потерях пакетов, не видно ничего кроме сплошных сбоев.


    Добавлю: причина предположительно в том, что VLC разбивает каждый кадр на разные пакеты и отправляет кадр по-кусочкам, при этом после прохождения по UDP, пакеты приходят не в том порядке, в котором отправлялись, и кадр склеивается не правильно. Плюс еще потери пакетов.
    Скорее всего проблема именно в потере пакетов.
    Картинка упаковывается, затем разбивается на блоки максимум 1500 байт и передается. При потере одного пакета или при их перестановке картинку собрать не получится.
    Думаю обычные кодеки тут не подойдут нужно делать что то свое.

    Имхо необходимо программно контролировать своевременность и порядок доставки пакетов.
    Например разрезать весь кадр на области, каждая из которых при сжатии гарантированно займет места не больше 1400 байт, добавить туда информацию о номере кадра и местоположении области в кадре. Получится всю информацию о конкретной области упаковать. Таким образом умещаем все в одну датаграмму, потеря которой не затронет остальную картинку и перестановка пакетов местами не скажется.
    При получении такой датаграммы, мы знаем номер кадра к которому она относится и местоположение данных.
    Если датаграмма устарела (кадр уже показан) убиваем ее сразу.
    Если кадр еще не показан распаковываем данные в соответствующее место кадра. Если какая либо область кадра не была обновлена (датаграмма утеряна), подставляем данные из предыдущего кадра. (Можно организовать небольшой буфер максимум 2-3 кадра).
    Используя черезстрочную развертку для 640х480 можно передавать кадры 320х480, качество ухудшится незначительно, уменьшим видеопоток вдвое (в телевизоре именно так все работает).
    В общем для видео рулит оптимизация под конкретную задачу и отказ от стандартных кодеков.
    Последний раз редактировалось UncleSam; 19.01.2011 в 16:46. Причина: Решил дополнить.

  15. #92

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от UncleSam Посмотреть сообщение
    разрезать весь кадр на области, каждая из которых при сжатии гарантированно займет места не больше 1400 байт
    Почему 1400 байт? Максимальный размер датаграммы - 64Кб, я пробовал передавать JPEG размером около 50Кб. Проблема в том, что в 64Кб нужно уложить 1 секунду видео, потому как Yota больше не потянет, по моим замерам выходило 300-500Кбит/сек.

  16. #93

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Получилось передать видео отдельными JPEGами, идет без потерь пакетов. Теперь нужно поработать над снижением битрейта, т.к. через несколько секунд начинает накапливаться задержка и продолжает расти, может у кого-то будут мысли как это побороть?

  17. #94
    Давно не был
    Регистрация
    18.01.2011
    Адрес
    Хабаровск
    Возраст
    35
    Сообщений
    23
    Цитата Сообщение от Korogodsky Посмотреть сообщение
    Почему 1400 байт? Максимальный размер датаграммы - 64Кб, я пробовал передавать JPEG размером около 50Кб. Проблема в том, что в 64Кб нужно уложить 1 секунду видео, потому как Yota больше не потянет, по моим замерам выходило 300-500Кбит/сек.
    Это вы можете сделать датаграмму размером 64k, в реальности у всех систем передачи есть параметр MTU - максимальная длина передаваемого кадра, для ethernet - 1500 байт, для GPRS -1400, для DSL - 1492, для WiFi - 1500. (На самом деле тут все сильно зависит от оборудования).
    Все что длиннее будет разбито на блоки такой длины, либо непосредственно вашим компьютером (информация разбивается на пакеты c длиной MTU вашей системы), либо транзитным оборудованием (фрагментация пакетов).
    Засада в том, что если пакет фрагментирован, он не будет передан с сетевого уровня операционной системы на уровень приложений до тех пор, пока не придут все кадры и система не сможет из них собрать полный пакет. В результате один задержавшийся пакет создает задержку для всех остальных, а один потерянный пакет гробит всю датаграмму, так как она не может быть верно собрана. В общем таким образом поучаете минимум лишнюю задержку.
    Лучше изначально закладывать передачу блоками по 1400-1450 байт.

    Цитата Сообщение от Korogodsky Посмотреть сообщение
    Теперь нужно поработать над снижением битрейта, т.к. через несколько секунд начинает накапливаться задержка и продолжает расти, может у кого-то будут мысли как это побороть?
    Попробуй черезстрочную развертку - уменьшишь битрейт 2 раза при той же частоте кадров. Правда получишь расческу при резких поворотах камеры, но с ней можно бороться фильтрами.
    Подумай над возможностью синхронизации видео путем пропуска кадров.

    В общем за работу респект и уважуха.

  18. #95
    Давно не был
    Регистрация
    26.08.2009
    Адрес
    Одесса
    Возраст
    34
    Сообщений
    254
    интересно, быстрей чем луноход будет? Сколько секунд до луны и обратно шел сигнал, 2?
    В луноходе минимальный лаг был 2.5с - это время сигнала туда-сюда. На практике лаг был 10-15с, т.к. там использовалось малокадровое телевидение с переменной частотой кадров, кот. зависила от к-ва приема.

    Использование быстрой ЭВМ на борту позволяет снизить задержку вызываемую сжатием сигнала (у IP камеры все же другие задачи и задержка там обычное дело).
    Тут дело не в ресурсах ЦПУ, а в технологии сжатия. Задержка вызвана применением межкадровой компрессии с большой длиной блока. иначе надо будет очень большой поток.
    Попробуй черезстрочную развертку - уменьшишь битрейт 2 раза при той же частоте кадров. Правда получишь расческу при резких поворотах камеры, но с ней можно бороться фильтрами.
    Так можно и отображение черезстрочно организовать. Сначала 1 полувину растра, а потом вторую. Как в ТВ. А вообще, если не вредничать, то картинки 320х240 вполне достаточно. Вспомните как раньше смотрели фильмы на VCD.
    Последний раз редактировалось -Stas-; 20.01.2011 в 12:36.

  19. #96

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Такие мысли по оптимизации:
    1. Отправка кадров по таймеру 60-80 миллисекунд (во вчерашней эксперементальной программе - отправка нон-стоп)
    2. Отправка кадров порциями по 2-3 секунды до поступания команды на отправку следующей порции с базы
    2.1 Команда с базы на отправку следующей порции кадров при опустошении очереди
    3. Проверка времени отправки кадра на борту и отбрасывание устаревших кадров перед отправкой
    4. Снижение качества JPEG для уменьшения битрейта (разрешение, % качества JPEG, уменьшение количества цветов, черезстрочность, "широкоформатный" режим)

  20. #97
    msv
    msv на форуме

    Регистрация
    05.03.2008
    Адрес
    Новокузнецк
    Возраст
    55
    Сообщений
    2,367
    Когда-то баловался передачей видео по сети DirectShow+UDP. Тестовая программулька где-то осталась в BCB, если хотите (ну там кодеками поиграться..) могу поискать, скинуть с исходниками.

  21. #98

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от msv Посмотреть сообщение
    Когда-то баловался передачей видео по сети DirectShow+UDP.
    Какие у вас были результаты? Какого FPS удалось добиться, при каком разрешении? Какая задержка была, насколько пригодно для FPV в реальном времени?

    Цитата Сообщение от msv Посмотреть сообщение
    DirectShow+UDP
    Я сейчас тоже использую эту связку и приятно удивлен скоростью, если с VLC при передаче видео с компа на самого себя уже возникала задержка около секунды, то тут ее практически нет.
    Последний раз редактировалось Korogodsky; 20.01.2011 в 22:42.

  22. #99
    msv
    msv на форуме

    Регистрация
    05.03.2008
    Адрес
    Новокузнецк
    Возраст
    55
    Сообщений
    2,367
    Проект начинался для видеоконференции в локалке, но умер не родившись по независившим от меня причинам.. В приципе комп-комп все работало дуплексом без проблем в 100мб-сетке (ну еще бы.. ). От разрешения и выбранного кодека изменялась только загрузка сети. Задержки в большей степени зависили от кодека и его настроек.. У Вас несравнимо более сложная задача и по требованиям к задержке, и по ширине да еще и нестабильности канала..

  23. #100

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от msv Посмотреть сообщение
    От разрешения и выбранного кодека изменялась только загрузка сети
    Я так понял с кодеками для этой задачи связываться вообще не стоит.


    Цитата Сообщение от msv Посмотреть сообщение
    сложная задача и по требованиям к задержке, и по ширине да еще и нестабильности канала

    Вчера поигрался с качеством JPEG, погонял видео с вэбкамеры через Yotу, в общем есть неплохие шансы на более-менее успешное завершение проекта.

  24. #101

    Регистрация
    20.01.2011
    Адрес
    Одинцово
    Возраст
    28
    Сообщений
    5
    Цитата Сообщение от Korogodsky Посмотреть сообщение
    Я так понял с кодеками для этой задачи связываться вообще не стоит.
    почему же не стоит? ведь есть всякие интернет телефоны, тот же googletalk и skype. они довольно быстро передают видео по узким каналам. а jpeg-и слать с каждым кадром - слишком хороший канал нужен для приличного качества

  25. #102

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от loigray Посмотреть сообщение
    тот же googletalk и skype
    Было бы интересно узнать какие кодеки они используют.

    Цитата Сообщение от loigray Посмотреть сообщение
    а jpeg-и слать с каждым кадром - слишком хороший канал нужен для приличного качества
    По моим экспериментам качество изображения получается приемлемое для управления (на мой взгляд), я еще не весь потенциал оптимизации использовал Наслаждаться 1080p 60fps, конечно не выйдет, но оценить курс куда лететь/ехать/ползти/бежать и т.д. и т.п. можно. До начала практических работ c JPEGом, мне эта тема казалась вообще бесперспективной, но на практике все оказалось не так плохо. То "видео" из JPEGов, которое я вчера передавал, временами было очень близко к реальному времени, но с периодическими достаточно частыми подвисаниями на 1-2 секунды. Кстати не исключено что skype использует что-то такое.

  26. #103
    Давно не был
    Регистрация
    18.01.2011
    Адрес
    Хабаровск
    Возраст
    35
    Сообщений
    23
    Цитата Сообщение от loigray Посмотреть сообщение
    почему же не стоит? ведь есть всякие интернет телефоны, тот же googletalk и skype. они довольно быстро передают видео по узким каналам. а jpeg-и слать с каждым кадром - слишком хороший канал нужен для приличного качества
    -Stas- прав, здесь есть противоречие, для того чтобы добиться максимального качества при минимальном битрейте почти все кодеки (и скайп с гуглом тоже) используют межкадровую компрессию, сжимают не отдельные кадры, а блоки по 5-10 кадров. Для этого им необходим буфер из нескольких кадров, в результате задержка. В видеоконференции задаржка 0,5 - 0,7с ничего не значит. в FPV она критична.
    Думаю действительно стоит отказаться от стандартных кодеков и пробовать сделать что то самому.

  27. #104

    Регистрация
    20.01.2011
    Адрес
    Одинцово
    Возраст
    28
    Сообщений
    5
    Цитата Сообщение от Korogodsky Посмотреть сообщение
    Было бы интересно узнать какие кодеки они используют.
    скайп испллььзует вроде как vp7
    гуглтолк h264 и h263, хотя оне с недавных пор 264 невзлюбили, перестают поддерживать и заменяют на vp8. скорее всего по политическим пичинам.
    лучше всего использовать h263 - он разрабатывался специально для передачи по слабым каналам. 264 конечно лучше, но он проц сильно грузить будет при кодировании, а дял бортового компа это критично.

    и ещё. видеопоток стоит предавать конечно по udp. для преодаления nat можно использовать протокол stun. но данные надо бы завернуть в какой нибудь предназначеный для этих целей протокльчек. по уму - в rtp. не будет проблем с неправильным порядком пришедших пакетов, и совместно с используемым вместе с ним протоколом контроля передачи можно будет регулировать параметры кодека - фреймрейт, размер гоп структуры, разрешение, чтобы видео при проседании канала не замирало, а просто ухудшало качество, и потом восстанавливалось при улучшении связи

    да, и програмиовать бэкэнд, по крайней мере, лучше на каком нить другом языке. умные люди такое делают на си. ленивые на с++. а на языках с jit и garbage collector только смелые экспериментаторы

    это хорошо, конечно что канала у ёты для передачи jpeg-ов хватает, и возможно для эксперементов этого достаточно. но если смотреть на будующее, то так дела не делаются - не слать же в bmp всё, раз канал позволяет надо расчитывать что мобильный инет не такая надёжная штука, и не везе стабильно работает. и лучше стремиться к максимальному качеству изображения при доступной ширене канала

    Цитата Сообщение от UncleSam Посмотреть сообщение
    -Stas- прав, здесь есть противоречие, для того чтобы добиться максимального качества при минимальном битрейте почти все кодеки (и скайп с гуглом тоже) используют межкадровую компрессию, сжимают не отдельные кадры, а блоки по 5-10 кадров. Для этого им необходим буфер из нескольких кадров, в результате задержка. В видеоконференции задаржка 0,5 - 0,7с ничего не значит. в FPV она критична.
    Думаю действительно стоит отказаться от стандартных кодеков и пробовать сделать что то самому.
    дык любой кодек может использовать только i-фреймы если даже гоп-структуру зделать размером 4 кадра всё равно будет ощутимый прирост в степени сжатия, и это всего 100 милисекунд, а данные доступны для отправки раньше прихода следующего ключевого кадра. задержка не в этом. в цепочке передачи видео от камеры, через интернет, до монитора довольно много всяких буверов, в которых задержка накапривается, я в принципе представляю себе где там что и как, но, как мне кажется, слать жпеги - всё равно не лучший вариант
    да. лаги в любом случае будут. и использовать инет для fvp, там где, полсекунды играют критическую роль, мне кажется, не самое грамотное решение. другое дело поставить это на большой самолётик, с автопилотом, летающим по вейпоинтам, а видио использовать для контроля полёта.
    Последний раз редактировалось loigray; 21.01.2011 в 15:22.

  28. #105

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от loigray Посмотреть сообщение
    любой кодек может использовать только i-фреймы если даже гоп-структуру зделать размером 4 кадра всё равно будет ощутимый прирост в степени сжатия, и это всего 100 милисекунд, а данные доступны для отправки раньше прихода следующего ключевого кадра.
    Будет хорошо, если Вы реализуете небольшую программу передающую видео в "реальном" времени с вэбкамеры через интернет с использованием кодека.

  29. #106
    msv
    msv на форуме

    Регистрация
    05.03.2008
    Адрес
    Новокузнецк
    Возраст
    55
    Сообщений
    2,367
    Так если Вы уже пользуете DirectShow стройте граф с любыми кодеками, установленными в системе.. Даже проще чем самому в jpeg перегонять..

  30. #107

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от msv Посмотреть сообщение
    Так если Вы уже пользуете DirectShow стройте граф с любыми кодеками, установленными в системе.. Даже проще чем самому в jpeg перегонять..
    Возможно... Я в сторону использования кодеков там не смотрел, и если loigray в этом не плохо разбирается, я не против доверить это ему. А я пока посмотрю что там с jpeg может получиться.

  31. #108

    Регистрация
    20.01.2011
    Адрес
    Одинцово
    Возраст
    28
    Сообщений
    5
    Цитата Сообщение от Korogodsky Посмотреть сообщение
    Будет хорошо, если Вы реализуете небольшую программу передающую видео в "реальном" времени с вэбкамеры через интернет с использованием кодека.
    как раз подумывал над этим. тоже хочу себе самолётик с интернетом
    жаль времени сейчас совсем нет
    ведь если всё делать по уму то не такая уж и небольшая, в плане объёма исходников, програмка получится.

    мабуть начну в следующие выходные. я уже примерно себе представляю как это должно работать. делать планирую на qt, изначально под линупс, но кросплатформено. винды у меня нет. беден. так что если появятся обладатели маков и компов с виндой, желающих присоединиться - велком

  32. #109

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от loigray Посмотреть сообщение
    если даже гоп-структуру зделать размером 4 кадра всё равно будет ощутимый прирост в степени сжатия, и это всего 100 милисекунд

    Цитата Сообщение от loigray Посмотреть сообщение
    то так дела не делаются - не слать же в bmp всё, раз канал позволяет
    Тут получается дилемма - забить канал под завязку либо сэкономить немного времени. Делайте, а там посмотрим что лучше, выбор - это есть хорошо! В конце концов это может быть переключатель в финальном релизе.

    Добавка:
    С кодеками - 1% потерь и вы не увидите изображения, пока не придет следующий блок, и опять картинка будет видна пока не потеряется пакет. UDP+Yota=потери, такая формула получена эмпирическим путем
    C jpeg каждый кадр идет одним куском, при сбое теряем только один кадр, если в секунду один кадр из 20 или 15 будет теряться мы этого даже не заметим.
    Парируйте!
    Последний раз редактировалось Korogodsky; 21.01.2011 в 16:46.

  33. #110

    Регистрация
    20.01.2011
    Адрес
    Одинцово
    Возраст
    28
    Сообщений
    5
    Цитата Сообщение от Korogodsky Посмотреть сообщение
    С кодеками - 1% потерь и вы не увидите изображения, пока не придет следующий блок, и опять картинка будет видна пока не потеряется пакет. UDP+Yota=потери, такая формула получена эмпирическим путем
    C jpeg каждый кадр идет одним куском, при сбое теряем только один кадр, если в секунду один кадр из 20 или 15 будет теряться мы этого даже не заметим.
    Парируйте!
    jpeg не идёт одним куском, если он больше mtu, (обычно 1500 байт)

    а при сжатии видео 263 кодком, если пропадёт пакет из ключевого кадра то на экране будет небольшой артефакт размером с макроблок, в котором лежал пропавший пакет, длительностью gop_size*frame_duration. а так как ключевые кадры редки, то вероятность этого небольшая. если пропадёт пакет из b-frame или p-frame то артефакта вообще не заметите, его длительность будет frame_duration. в вашем случае неудачный результат скорее всего был связан не с невозможностью передачи сжатого видео через udp, а скорее, не в обиду будет сказано, с неумением это делать. возможно там не всё так просто как может показаться на первый взгляд, но совершенно не означает что невозможно. я видел как такое работает у других с минимальными задержками и без разрушения картинки. значит это возможно

  34. #111
    Давно не был
    Регистрация
    26.08.2009
    Адрес
    Одесса
    Возраст
    34
    Сообщений
    254
    Ну так уже писали про это. Выигрываем в потоке (его минимизация), проигрываем в лаге и надежности. Проигрываем в потоке - уменьшаем лаг и надежность. 3-го не дано. Или надо использовать кодек с переменной длиной блока и постоянно контролировать линк. Тогда, пока линк хороший, удлиняем GOP, уменьшаем сжатие и улучшаем к-во. А как линк ухудшился, то укорачиваем GOP вплоть до перехода только к i-кадрам (кодек должен это поддерживать) и снижая к-во самого кадра добиваемся хоть какой-то видимости. Оперировать надо длиной GOP, частотой кадров и их разрешением. Примерно так, но а аналоге, работали с луноходом. Ну и мое ИМХО, если Йота дает 300 кб/с, то делать видео больше 320х240х15 fps нет смысла изначально.

  35. #112

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от -Stas- Посмотреть сообщение
    пока линк хороший, удлиняем GOP, уменьшаем сжатие и улучшаем к-во. А как линк ухудшился, то укорачиваем GOP вплоть до перехода только к i-кадрам
    Если я все правильно понял - при улучшении качества связи - увеличиваем задержку видео? А при ухудшении линка начинаем сокращать блоки вплоть до перехода к "JPEGам". Если учесть, что Yota, а тем более 3G дает линк "критически малого уровня", то мы и будем сидеть все время на тех самых JPEGах, но с минимальными задержками. При этом немножко увеличим трафик, за счет того что там еще прибавляет кодек к JPEGам.

  36. #113

    Регистрация
    20.01.2011
    Адрес
    Одинцово
    Возраст
    28
    Сообщений
    5
    Цитата Сообщение от -Stas- Посмотреть сообщение
    если Йота дает 300 кб/с, то делать видео больше 320х240х15 fps нет смысла изначально.
    да, примерно так. но я всё равно верую в светлое будущее мобильного интернета. вдруг ёта лте в Маскве подымит - вот тогда будет счастье
    а начинать делать систему управления самолётиком через инет можно сейчас - как раз к тому времени будет готово :)

    Цитата Сообщение от Korogodsky Посмотреть сообщение
    Если я все правильно понял - при улучшении качества связи - увеличиваем задержку видео?
    да не, зачем увеличивать задержку. не вдаваясь в подробности - просто крутим параметры кодека, так чтобы при ухудшении связи терялось качество картинки, при улучшении соответственно улучшалось :) а задержку стараться соблюдать минимальную. есть такое слово rtcp - используется совместно с rtp. чует качество связи, там кол-во потереных пакетов, ждитеры, и всё такое - с его помощью, можно информировать источник о том что надо поменять параметры кодирования. но это уже детали. можно вообще без всякого rtcp делать - просто задать минимально приемлемое качество изображения для кодека, с заведомо подходящим битрейтом и всё
    Последний раз редактировалось loigray; 21.01.2011 в 19:25.

  37. #114
    Давно не был
    Регистрация
    26.08.2009
    Адрес
    Одесса
    Возраст
    34
    Сообщений
    254
    Если я все правильно понял - при улучшении качества связи - увеличиваем задержку видео?
    Ну да, но улучшаем к-во. Может это и не лучшая идея. Я изначально исхожу из того, что объект управления довольно автономен (есть АП для самика, а если машинка, то она медленно едет). Все равно не идет речь о реальном управлении. Тут скорее некий командный режим. Почитайте как управляют всякими марсоходами и т.п.
    Кстати, можно попробовать использовать ЖПЕГ 2000. Он лучше жмет. Ну и многопроходное кодирование. Тогда кадр будет вначале отображаться как-бы полосками, но уже что-то видно, а по мере поступления пакетов будет дополнятся до полной картинки.

  38. #115

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    На выходных удалось получить кое-какие результаты. Встроил передачу видео посредством JPEG в программу. Такого "ужаса" как с передачей MJPEG через VLC не наблюдается. Сделал крутилку для регулирования качества jpeg вручную, с базы значение передается на борт, и борт понижает качество изображения. Видео приближенного к реальному времени удается добиться при довольно низком качестве картинки. Не знаю возможно ли будет управлять самолетом в ручном режиме с таким изображением. Еще нужно сделать режим автоматического понижения/повышения качества.

    Мне нравится идея с черезстрочным выводом. А что если черезстрочный вывод сделать и по горизонтали и по вертикали? Тогда по идее размер изображения должен уменьшиться в 4 раза?



    PS
    Чтобы вы получше представляли как это выглядит: дерево можно разглядеть и сказать что это дерево, предполагаю что можно будет разглядеть поле для посадки (изначальная задача), но вот понять какая высота травы - врядли. Впринципе можно сделать передачу качественного снимка местности по нажатию кнопки - присмотрел место для посадки, получил фотографию, оценил - не подходит место (трава высокая), полетел искать дальше.
    Последний раз редактировалось Korogodsky; 24.01.2011 в 12:21.

  39. #116
    Давно не был
    Регистрация
    26.08.2009
    Адрес
    Одесса
    Возраст
    34
    Сообщений
    254
    Такой БПЛА надежнее садить на парашуте.

  40. #117

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от -Stas- Посмотреть сообщение
    Такой БПЛА надежнее садить на парашуте.
    Я понимаю, да, на парашюте проще всего реализовать, но не лежит душа к такому способу приземления "не красиво" это!
    Еще вариант реализации посадочного режима: по нажатию кнопки открывается два окна - в одном показывается видео в реальном времени с низким разрешением, а во втором 1 раз в 2-3 секунды обновляется изображение 640х480 размером 50-60Кб. На время передачи "качественных" кадров, видео в реальном времени будет останавливаться, эксперименты показывают что на 1 секунду.

  41. #118
    Давно не был
    Регистрация
    26.08.2009
    Адрес
    Одесса
    Возраст
    34
    Сообщений
    254
    Даже для большой авиации подбор плошадок с воздуха сложная задача. На это одельный допуск пилоту дается. А вы хотите это по видеокартинке сделать.

  42. #119

    Регистрация
    14.12.2009
    Адрес
    Москва
    Возраст
    38
    Сообщений
    269
    Цитата Сообщение от -Stas- Посмотреть сообщение
    Даже для большой авиации подбор плошадок с воздуха сложная задача. На это одельный допуск пилоту дается. А вы хотите это по видеокартинке сделать.
    Задача сложная, я не спорю, но все-таки это самолет без людей на борту, опасность он представляет для тех кто на земле находится, реально можно не заметить человека на поле. Думаю на таком ЛА не должно быть пропеллеров выступающих за корпус, и посадочная скорость должна быть минимальной в идеале вертикальное приземление.

  43. #120
    Давно не был
    Регистрация
    18.01.2011
    Адрес
    Хабаровск
    Возраст
    35
    Сообщений
    23
    Цитата Сообщение от -Stas- Посмотреть сообщение
    Даже для большой авиации подбор плошадок с воздуха сложная задача. На это одельный допуск пилоту дается. А вы хотите это по видеокартинке сделать.
    Ну посадка пассажирского ЛА и РУ модели это немного разные вещи. Думаю нет ничего невозможного.

    Уважаемый топикстартер, можно видео с десктопа, хотелось хотя бы приблизительно оценить качество.

Закрытая тема

Похожие темы

  1. банковская карта для оплаты через интернет магзин
    от sawaer в разделе Магазины, интернет-торговля
    Ответов: 151
    Последнее сообщение: 22.07.2012, 21:00
  2. Покупка аппаратуры Futaba 8FG (2.4Ghz, >10000р.) через интернет
    от legotron в разделе Магазины, интернет-торговля
    Ответов: 18
    Последнее сообщение: 16.09.2010, 18:52
  3. Прошу помощи в подборе драйвера для управления ШД EM 257
    от Sims в разделе Драйверы и контроллеры для CNC
    Ответов: 3
    Последнее сообщение: 09.09.2010, 19:57
  4. Аппаратура управление через компьютер
    от Gitenkof в разделе Аппаратура радиоуправления
    Ответов: 14
    Последнее сообщение: 08.09.2010, 14:34
  5. Дорога в небо
    от octopus в разделе Новичкам
    Ответов: 19
    Последнее сообщение: 22.06.2010, 15:38

Метки этой темы

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения