Управление через интернет
Но все-таки не очень понятно, зачем управлять по видео
Мне интересней иметь возможность управления и наблюдения с борта реалтайм, чем просто смотреть на точку на экране и льющийся поток цифр.
В Гугл Земля, насколько я понял можно еще получать высоту точки над уровнем моря, что тоже может быть интересным, вот только вопрос как надежно определить высоту, на которой летит модель… (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, можно ставить метки на карте.
Сейчас можно добавлять и удалять метки, задавать высоту с которой смотрим, угол наклона и азимут.
Жаль в Google Earth нельзя задавать угол крена, так бы можно было вообще 3D полет сделать. 😃
А обратку от бортового ЖПС вы уже сделали?