Управление через интернет
Интересно почему они выбрали MJPEG, а не просто JPEG…
Вполне стандартный и примитивный видео кодер. Хотя, слово примитивный я бы не стал относить к JPEG 😃
MJPEG - всего навсего еще один формат для потоковой передачи видео (Motion JPEG).
ЗЫ: Меня что то тоже тема зацепила, интереса ради попробовал собрать библиотеку mediastreamer2 с поддержкой видео. Под Win32 собрать эту штуку - реальный секас 😃 зато, в совокупности с библиотекой ffmpeg можно воспользоваться практически любым кодеком для кодирования/декодирования видео и передачи его по RTP.
Хотелось бы еще заметить, что задача передачи потоковой информации в режиме, максимально приближенному к realtime’у, не столь проста как кажется и передачей голых UDP пакетов с данными тут не обойдешься. Сеть и протокол UDP не дает никакой гарантии доставки пакетов до конечной точки, также не гарантируется доставка UDP пакетов в том порядке в котором они были посланы, временные задержки между пакетами могут плавать и разительно отличаться от той частоты с которой они были посланы. Именно по этому был разработан протокол RTP который исправляет все “недостатки” передачи UDP пакетов по сети, разумеется кроме гарантии доставки до конечной точки.
Использование временных меток в протоколе позволяет корректно обрабатывать их принимающей стороной, отбрасывать слишком старые, буферизировать новые и выдавать пользователю информацию в режиме реального времени.
Доделал собственный захват картинки с вебки через v4l2 драйвер, и сжатие ее в памяти при помощи libjpeg сегодня попробую сделать отправку через UDP.
Очередной велосипед 😃 ну не понимаю я зачем писать что то свое, когда можно изучить то, что уже есть и прекрасно работает.
Если кому интересно как завести mediastreamer2 под win - могу написать туториал.
Если кому интересно как завести mediastreamer2 под win - могу написать туториал.
Интересно! Но не обещаю что сразу начну разбираться с mediastreamer2, сейчас вечерами разбираюсь с GoogleEarth 😃
Кстати что думаете на счет использования GoogleEarth для этого проекта? Тогда для работы программы будет необходима установка GoogleEarth.
Кстати что думаете на счет использования GoogleEarth для этого проекта? Тогда для работы программы будет необходима установка GoogleEarth.
Честно говоря, я ни бум бум в этом Earth. А каким местом его хотите прикрутить, как использовать ?
Вобщем, поскольку работа у меня немного связана с VoIP, по большей части с voice, но видео тоже захотелось попробовать. Вобщем, сляпал на скорую руку peer2peer прогу для передачи видео на основе исходов и примеров mediastreamer’a. Используемый кодек H.263, библиотеку mediastreamer собрал без поддержки directshow и directsound, так что вся отрисовка - софтварная посему и тормоза.
Весь релиз выкладывать не буду, слишком много мегабутесов кодеки весят.
Сами кодеки (dll) можете скачать тут.
Распаковываете скачанный 7z архив, из директории bin копируете все dll файлы в папочку где находится ‘rtpvideo’.
Релиз сборка rtpvideo прилагается. Как пользоваться - читаем readme.txt.
А каким местом его хотите прикрутить, как использовать ?
GoogleEarth можно использовать в своих приложениях для отображения текущего местоположения по GPS координатам и создания путевых точек.
Релиз сборка rtpvideo прилагается.
Ок, попробую.
GoogleEarth имхо требуется онлайн, и приличный трафик. Там конечно что-то как-то кэшируется, не разбирался. Но для своей рабочей станции использую jpeg-и из этой проги с координатной привязкой и свой движок изобретаю помаленьку. А то ведь фиг его знает- чужая прога потемки… а мне ведь надо еще и гарантировано видео успевать писать без дропов. И все на слабеньком ноуте…
Интересная тема. Но все-таки не очень понятно, зачем управлять по видео(и мучиться с его передачей в реалтайм), если это можно делать по телеметрии, а видео транслировать уже просто для интереса/дополнительного контроля.
Насчет проги гугла - там есть 3д режим “полетов”, если научиться передавать в него данные с телеметрии, можно “летать” по 3д карте, а не по видео. При этом важно, что в самой программе можно будет дорисовать полигонами ключевые объекты и сложные места полета, которых нет на изображении или нет в 3д(деревья/здания/линии ЛЭП), в идеале создав полную функциональную копию места полетов в 3д.
Нужно только будет решить вопрос с максимально точным определением высоты модели для нормального взлета/посадки/облета препятствий.
Но все-таки не очень понятно, зачем управлять по видео
Мне интересней иметь возможность управления и наблюдения с борта реалтайм, чем просто смотреть на точку на экране и льющийся поток цифр.
В Гугл Земля, насколько я понял можно еще получать высоту точки над уровнем моря, что тоже может быть интересным, вот только вопрос как надежно определить высоту, на которой летит модель… (P.S. про холмы, постройки, кусты - это я все понимаю 😃)
вот только вопрос как надежно определить высоту, на которой летит модель…
Бародатчик + ультразвуковой дальномер
Высота в Гугл Ирф весьма примерна. Я бына нее не расчитывал. Определение высоты эхолокацией не годится. Во первых я сомневаюсь, что этот метод приемлим для расстояний больше 5-10м, а во вторых звук распространяется относительно медленно, а модель летит быстро. Пока посланный к земеле импульс вернется обратно модель может улетет от этой точки. Это если даже есть эхолотные дальномеры на большое расстояние (50-100м). Тут надо мерить радтовысотомером. Ну может лазерный пойдет.
Насколько я знаю, для моделей кроме бародатчика и/или GPS, других способов измерения высоты пока не придумали.
Может что-то еще и есть, но или небюджетно, или некомпактно. “Малогабаритный авиационный радиовысотомер” судя по Гуглу, весит килограмм.
Очередной велосипед ну не понимаю я зачем писать что то свое, когда можно изучить то, что уже есть и прекрасно работает.
Велосипед делаю потому, что оно должно потом работать на плате ARM9.
Если кому интересно как завести mediastreamer2 под win - могу написать туториал.
А вот это можно, в личку пожалуиста.
Велосипед делаю потому, что оно должно потом работать на плате ARM9.
А в чем проблема то ?
Я понимаю так, что на ARM’e будут трудиться нано пингвины из серии uClinux или чего то подобного.
Если не использовать операционку на ARM’e, то стопудово сразу налетаете на грабли в плане реализации сетевого драйвера, с этой проблемой я уже сталкивался, но только на платформе blackfin.
Под linux все исходы mediastreamer’a прекрасно собираются, также, не будет проблем со сборкой необходимых видеокодеков из библиотеки ffmpeg (там кстати есть кое какие порты для всяких DSP и ARM в том числе, которые как раз используют всякие SIMD команды конкретного процессора). Так что, я пока не вижу ни малейшей причины писать что то свое.
Предвижу лишь долгий и нудный секас по сборке и настройке всего этого тряхомудия 😃
Если не использовать операционку на ARM’e, то стопудово сразу налетаете на грабли в плане реализации сетевого драйвера, с этой проблемой я уже сталкивался, но только на платформе blackfin.
Однозначно будут нанопингвины. Писать самому с нуля ОС вещь утомительная и крайне глупая. И Я не уверен в возможностях оборудования поэтому заранее продумываю все варианты, архитектуру опять же изучаю. Железо будет через 3 недели примерно, посммотрю что оно может, тогда и буду окончательно решение думать.
А пока пишу модуль который сможет использовать в качестве серверной части программу Максима. Все меньше самому писать.
На а собрать готовое решение это проще всего, успеется.
качестве серверной части
Я уже затрудняюсь сказать, что считать серверной частью. 😃 Вроде как модель - это сервер. 😃
Я тут разместил на форме базовой части панель с GoogleEarth, но там еще целая куча вопросов, пока просто Земля крутится и можно координаты вручную задавать и по нажатию кнопки перемещается в заданную точку, маркером только точку еще не отмечает, разбираться надо.
PS
С 3D режимом в Гугл Земля представляется интересная забава - параллельно в 2х соседних панелях включить реалтайм видео с камеры и 3D в Earth. 😃
Эм ну тогда клиентской ))
Кстати там на плате 32 порта ввода/вывода которыми можно программно дергать. Думаю не буду покупать отдельный модуль для управления сервами. Лучше на этих портах через опторазвязку буду реализовывать контроль сервами и ШИМ для движков. Но это уже по приходу железа. Тут работа подвернулась времени вобще лишнего нет.
А пока пишу модуль который сможет использовать в качестве серверной части программу Максима. Все меньше самому писать.
А что хоть за сервер и что он будет делать ?
В моем понимаии проблемы архитектура системы должна работать следующим образом:
Серверная часть будет расположена на самолете. TCP сервер IMHO следует использовать на базе JSON RPC. К данному серверу конектится клиент c земли и производит необходимые настройки на стороне сервера для организации peer2peer соединения.
Далее открываются необходимые RTP каналы передачи данных:
- Видео канал (воздух-земля).
- канал управления (земля-воздух)
- канал телеметрии (воздух-земля)
В логике работы софта - ничего сложно нет, если пользоваться существующими библиотеками предназначенными для организации VoIP.
ЗЫ: кто нить может потестировать мой пример с передачей видео по беспроводной сети. У меня просто нет оборудования.
Впринципе, если качество не устроит, то можно попробовать прикрутить к системе плагин с поддержкой кодека H.264.
Лучше на этих портах через опторазвязку буду реализовывать контроль сервами и ШИМ для движков.
Фиг вам 😃
GPIO порты - это вещь соблазнительная, но, мне даже под нанопингвинами из ядра не удалось обеспечить выдерживание необходимых временных интервалов. При этом я писал ядерный драйвер и вкомпиливал его в само ядро операционки. Так что, вариант с реализацией ШИМ на GPIO не прокатит, фронты будут плавать, т.к. время реакции системы вам никто не гарантирует, даже если ШИМ будет формироваться самописным драйвером.
Выходом из данной ситуации является - соединение микроконтроллера с ARM’ом: сам микроконтроллер будет формировать ШИМ на линиях в соответствии с управляющими кодами, засылаемыми на него со стороны ARM’a по SPI. При этом нам не нужно будет заботиться о выдерживании временных интервалов.
Плюс ко всему вам не удастся реализовать ШИМ параллельно на нескольких линиях порта GPIO. Почему, это можно просто прикинуть: длительность импульса которую вам необходимо сгенерировать составляет от 1000 до 2000 мкС, ну вводим дискретизацию например 10 бит, т.е. временной интервал в 1000мкС разбиваем на 1024, таким образом, получаем необходимую нам точность около 1 мкС. С одной микросекундой даже нанопингвины не справятся, какие бы они realtime пропатченные не были.
Плюс ко всему - эта процедура будет жрать не детски ресурсы проца на постоянное генерирование ШИМ сигнала.
Так что, выход один: соединяем через SPI или UART ARM и микроконтроллер и всю грязную работу по формированию ШИМ для сервоприводов возлагаем на него.
А может посмотреть в сторону QNX? Её вроде сейчас на шару раздают.
А может посмотреть в сторону QNX? Её вроде сейчас на шару раздают.
QNX может обеспечить лишь только гарантированное время реакции.
Вот краткий ликбез по QNX.
Гарантированное время реакции системы куда более 1 мкс…
вот здесь это грамотно описано
Менее 10 мкс - Только ОСРВ, но даже они могут быть бессильны – это граница выбора между схемным и программным решениями
Фиг вам
GPIO порты - это вещь соблазнительная, но, мне даже под нанопингвинами из ядра не удалось обеспечить выдерживание необходимых временных интервалов. При этом я писал ядерный драйвер и вкомпиливал его в само ядро операционки.С одной микросекундой даже нанопингвины не справятся, какие бы они realtime пропатченные не были.
А ведь правы. Упустил из виду что тут многозадачная операционка для которой микросекунда это много.
Думал использовать вот такой алгоритм требует мало системных ресурсов, на тиньках работало.
Но менее требовательный к таймингам ШИМ например для двигателя с обратной связью через датчик оборотов все еще подумать можно.
Хотя 25 баксов за отдельный модуль управления сервами с интерфейсом RS232 не сверх деньги, его надо заказывать и ждать пока приедет =(
Думал использовать вот такой алгоритм требует мало системных ресурсов, на тиньках работало.
Ага, видел, автор - реальный avr джедай 😃
Неужели в системе не найдется ни одного аппаратного таймера на прерывание которого можно обработчик повесить…
В S3C2440A 5 аппаратных таймеров, надеюсь нанопингвины хоть один мне помучать оставят… И фиг с небольшим дрейфом из за других прерываний…
Ладно посмотрим, померим…
* в грусти ушел читать даташит…
В S3C2440A 5 аппаратных таймеров, надеюсь нанопингвины хоть один мне помучать оставят… И фиг с небольшим дрейфом из за других прерываний…
тост должен быть кратким, как выстрел, а то времени на отдых не останется (С) “Особенности национальной охоты”, а если этим злоупотреблять - то до охоты дело не дойдет 😃
Таймер с разрешением в 1 мкс - это означает, что управление в user mode никогда не вернется. Проц будет наглухо торчать в обработчике прерывания (это в лучшем случае, в худшем - нанопингвины выйдут на забастовку с плакатом “кернел в панике” 😃) и тупо тратить свои ресурсы на его обработку, какой бы короткой она ни была. Помимо всего прочего нам как бы надо пакеты по сети принимать и обрабатывать, ну еще так, про между прочим видео сжимать в реальном режиме времени. Так что, чем реже будут происходить прерывания тем свободнее “дышать” системе.
Совсем другое дело, если имеется возможность организации аппаратного ШИМ, по типу как в AVR, причем, прерывания в данном случае нам уже будут не нужны, проц в таком случае будет самостоятельно ногами дергать. Только, я сомневаюсь в наличии данной фичи в ARM’e, да и кол-во аппаратных ШИМ каналов обычно ограничено.
Так что, нечего голову ломать и пробовать смысла нет, нужно просто немножко логически порассуждать.
Ответил в личку чтобы не засорять чужую тему.
Ответил в личку чтобы не засорять чужую тему.
Тут жеж общественное место, можно писать все что угодно, главное чтобы соответствовало теме.
Добавил Google Earth, можно ставить метки на карте.