Управление через интернет
Эм ну тогда клиентской ))
Кстати там на плате 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 полет сделать. 😃
А обратку от бортового ЖПС вы уже сделали?
А обратку от бортового ЖПС вы уже сделали?
Это еще не сделал. Сделаю отправку точек на борт и “текущих” координат с борта на базу (по нажатию кнопки) и возьмусь за обработку данных с GPS модуля (его еще купить нужно).
Там есть режим полета на “самолете”(в том числе с креном). Вот туда бы координаты передавать.
Korogodsky не дай теме умереть
Korogodsky не дай теме умереть
Я снова в строю! Был небольшой творческий кризис. 😃 Устраню некоторую кривизну программы (кое-что было сделано не совсем правильно) и возьмусь за GPS приемник. С GoogleEarth все более-менее понятно.
Сейчас с бортовой части можно передавать координаты по нажатию кнопки, на базовой части на карте показывается полученная точка и отмечается маркером.
Что думаете на счет таких GPS приемников:
market.yandex.ru/model.xml?hid=294661&modelid=9860…
pleer.ru/_27591.html
Что думаете на счет таких GP
Похоже оба 1 Гц-овые. 😦 В полете нужно 5 или 10 Гц, иначе совсем грустно.
Вот кстати, я так и не понял, действительно ли в 5/10 герцовых уменьшается задержка в определении координат/высоты до 200/100ms? Или это всего лишь софтовая интерполяция/экстрополяция?
И как проверить не соображу… Но на вскидку, в моем 5гц модуле похоже не соответствует 200мс (особенно заметно по изменению высоты)…
действительно ли в 5/10 герцовых уменьшается задержка в определении координат/высоты до 200/100ms?
Координаты и курс похоже действительно ускорены. А высота в простых GPS считается по остаточному принципу. Если прием затруднен или спутников недостаточно, высота может надолго замирать. Особенно это “приятно” при резких эволюциях модели, типа штопора. Модель уже на/в земле, а по GPS - еще большой запас высоты. 😃