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

Stas#

Импелеры обладают худшей энерговооруженостью (отношение тяги к весу мотоустановки), чем традиционный пропелер. Т.е. модель тяжелеет, а тяги мало.Если на них еще навесить управление вектором тяги, то КПД упадет и того более. Кроме того, насколько я знаю, управление вектором тяги делается для улучшения маневренности, а не как способ основного управления. Возможно его даже недостаточно без традиционных рулей, а соотв. зачем оно надо - не знаю. Идем дальше. ЛК не самая устойчивая модель, а под ФПВ в идеале самовырвнивающийся планер, т.к. иначе надо или сильно надеятся на АП или им (самиком) постояно рулить. В случе управления через инет рулит постоянно сложно из-за лагов. Да и вероятность с 1-го захода написать программу хорошего АП на комп тоже сомнительна.

VRV

NET 2.0 установлен, но ошибка осталась, файрвол отключен 😦

Korogodsky

-Stas-

Спасибо! Посмотрим, я еще ничего не расчитывал.

VRV:

NET 2.0 установлен, но ошибка осталась, файрвол отключен

Какая у вас операционная система. Я пробовал запускать на XP, Vista, Win 7. Ошибка при запуске появляется, т.е. IPFPVBoard вообще не запускается?
IPFPVBase без ошибок запускается?

r1000

Думал о такой штуке годика три назад. Практика показала, что стоит забить. Собственно реализация:
Wi-Fi роутер на самолете. К нему подключается через LAN IP-camera и arduino с этой Ethernet платкой.
По WiFi соединяюсь с роутером (который в самолете должен был быть). Зная ip ардуины - передаю на нее последовательно данные об отклонениях серв/оборотах двигателя, ардуина, выдает полученные параметры на PWM выходы, к которым подключены сервы (тут все совсем просто в реализации). Картинку с тоже камеры тоже получить не проблема, зная IP камеры. Собственно на компьютере я все организовал используя python и библиотеку pygame - замечательная вещь которая легко обрабатывает данные с джойстика/клавиатуры, и рисует картинки на экране. До установки на самолет дело не дошло, так как удаление роутера на 20 метров настолько снижало скорость передачи и без того идущего с задержкой видео, что это уже было не приемлемо (до 5-и секунд), но, теоритически, если снабдить аппарат стабилизатором, то скорость передачи видео уже не будет столь критична, а данные телеметрии может передавать та же ардуинка. Соответственно вай-фай роутер можно заменить на обычный проводной, но с поддержкой USB куда воткнуть WiMax или 3G модем со статическим внешним IP. Да, и данные нужно передавать по UDP, а не TCP, так как пакеты не будут буферизироваться и забивать трафик. Но для реалтайм управления данные технологии не подходят (точнее для передачи видео).

Да, и еще - IP-камера при проводном соединении давала задержку порядка 0.3-0.5 секунды, так что дело было именно в беспроводном соединении. И самое главное - а зачем оно вам, на батарейках? Современные недорогие системы для FPV позволяют улетать на десяток и более километров, но дальность тут уже ограничивается батареей (зачастую). А ваша система будет кушать столько, что вы и на 5-ть километров не улетите.

mejnkun
r1000:

А ваша система будет кушать столько, что вы и на 5-ть километров не улетите

замечу-EeePC потребляет без дисплея 40Вт на стандартной батарее с W7 и подклю4еным модемом huawei E150 тарабанит до 5 ч. в приделах крупного европейского города через винамп передавали киношку задержка до 1сек, скорость загрузка ниже 1мб не опускалась, отдача-0.6. переход через соты не замечался.сети WCDMA /HSDPA вне пределов городов EDGE там видео не идет. с российскими городами всё хуже на порядок,то густо то пусто.
П.С. идея очень хорошая, сам бы хотел леталку управляемую по сети, но у самого не хватает времени на такой проект,а на рускоязычных форумах только воду ступой толкут по етому поводу.подожду пока буржуи в продажу пустят готовые комплекты…впрочем уже есть…

r1000:

Современные недорогие системы для FPV позволяют улетать на десяток и более километров

при условии отдачи в ефир 10-20 вт.каково гадить,а потом возмущаться што ефир загажен.много раз сталкивался -кто то поставит АР с усилителем себе под видео а вокруге WiFi валиться-модели нестого не ссего пдают

mejnkun

видел на пиндосских форумах видео про квадрик там дублированая система и где то на ютубе.искал через гугл gsm model control и всё такое щас пока искать нет возможности сижу в роуминге на модеме

Stas#

Есть готовый квадрик, кот. рулится ЯМобилкой. Наверно речь о нем.

Korogodsky

Пришел серво-контроллер, завтра продолжу разработку программы. Пока поигрался с утилитой от производителя, работает платка, крутит серву.

Korogodsky

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

Korogodsky

Сделал кое-какие доработки в интерфейсе, теперь можно изменять режим срабатывания при нажатии клавиш клавиатуры “нажал-отпустил” и “нажал-нажал”, ползунки можно перемещать мышкой без джойстика, задавать количество активных каналов управления, появилась возможность делать изменение размера передаваемой видео-картинки, т.е. если камера выдает 640х480, можно сделать ресайз например до 640х320, получится “широкоформатный” режим, предположительно таким образом можно снизить битрейт, последние сделанные настройки теперь сохраняются.

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

Korogodsky
SGordon:

ну когда же уже c Ядой;-)

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

Korogodsky

Попробовал я как с Yotoй все работает, как и ожидалось реакция управления вполне удовлетворительная, а вот видео никуда не годится, нужно переделывать, буду пробовать запасной вариант - передачу отдельных JPEG кадров по UDP. Так что обещанного видео на выходных не будет 😦

SGordon

интересно, быстрей чем луноход будет? Сколько секунд до луны и обратно шел сигнал, 2?

UncleSam

Хм интересно, а если все же попробовать сформулировать требования к системе

  1. Работа без “лагов”.

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

  1. Аппаратура позволяющая организовать стабильный и быстрый IP радиоканал

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

  1. Механизм управления сервами

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

  1. Наличие датчиков ориентации в пространстве.

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

Korogodsky

UncleSam, спасибо за ценную информацию!

SGordon:

интересно, быстрей чем луноход будет?

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

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

UncleSam
Korogodsky:

UncleSam, спасибо за ценную информацию!

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

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

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

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

Korogodsky
UncleSam:

разрезать весь кадр на области, каждая из которых при сжатии гарантированно займет места не больше 1400 байт

Почему 1400 байт? Максимальный размер датаграммы - 64Кб, я пробовал передавать JPEG размером около 50Кб. Проблема в том, что в 64Кб нужно уложить 1 секунду видео, потому как Yota больше не потянет, по моим замерам выходило 300-500Кбит/сек.