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

baychi
DVE:

А что, уже есть солнечные батареи, способные отдавать хотя бы 10А в сумме

При площади СБ 70-80 кв.дм. - реально взять 100 Вт. Вес самих СБ при этом порядка 400 грамм.

Stas#

А если видео будет ЧБ, то поток раза в 2.5-3 упадет.

wkaktuz
Stas#:

А если видео будет ЧБ, то поток раза в 2.5-3 упадет.

Совершенно верно!

baychi
Stas#:

если видео будет ЧБ, то поток раза в 2.5-3 упадет

Боюсь, что нет. Процентов на 30% тока. 😦

levteros
DVE:

А что, уже есть солнечные батареи, способные отдавать хотя бы 10А в сумме для непрерывной работы двигателя?

Уже давно все есть. Пока правда в организациях с бездонными бюджетами. Но самолеты, висящие в небе на солнечных батареях несколько месяцев опробованы года 2-3 назад точно.
http://www.pvresources.com/en/helios.php

Кстати. В большой авиации есть масса идей, которые уже реализованы в габаритах FY-20A во всякого рода автопилотах/ОСД/комбайнах.

Многие вполне доступны на коммерческой основе. Например http://www.micropilot.com/ готовый пилот с базовой станцией для картографических планеров. Прилетает “к ногам”. Полет ограничен фантазией и бензином в баке.

И еще - тема отчасти для отдельной ветки.
Сугубо случайно наткнулся на ОСД с акселерометрами, и выходом на модем. (если правильно понял). Вещь похоже неопробованная. http://www.thesiliconhorizon.com/motion.htm
По сабжу Можно, к примеру, летать по “виду сверху” c google Earth.

Топикстартеру респект.

Stas#
baychi:

Боюсь, что нет. Процентов на 30% тока. 😦

Провел эксперимент. Фото 6 мп в цвете с компресией JPEG весит 2.3 мб, а тоже фото после перевода в ЧБ и сохранения в JPEG уже 750 кб.
Автор применяет MJPEG, т.к. это кодек без межкадровой компресии и соотв. с минимальным лагом. Кадры внутри секвенции жмуться по JPEG алгоритму.

Например http://www.micropilot.com/ готовый пилот с базовой станцией для картографических планеров. Прилетает “к ногам”. Полет ограничен фантазией и бензином в баке.

А вы цену видели micropilot.com/products-mp2028-autopilots.htm

blade
wkaktuz:

Такие идеи зарубать нельзя, Я уже давно над этим думаю и есть уже некоторые результаты.

Эти идеи регулярно появляются то тут то там 😦
Только авторы (почему то) идеями и ограничиваются…
А нет, чтобы взять да поставить реальный модем на реальный самолёт (разгрохав при этом штук пять) да и доложить всем: так мол и так, вот сделал, испытал, вот видео…
Ясно, что тут и затраты денег и затраты труда потребуются, а не только языком почесать.
А то очередной вечный дрыгатель получается.

baychi
Stas#:

Фото 6 мп в цвете с компресией JPEG весит 2.3 мб, а тоже фото после перевода в ЧБ и сохранения в JPEG уже 750 кб.

Чем сохраняли, какой формат JPEG? И пробывали ли сохранить ту-же фотку в цвете? Я к тому, что обычно открыв исходную фотку с фотика, а затем сохранив ее, мы получим файл уменьшеного размера. Проделал такой-же эксперимент. При исходной фотке 2 мб, сохраненная в ч/б весила 350 кб, а в цвете - 400.

Stas#:

Автор применяет MJPEG, т.к. это кодек без межкадровой компресии и соотв. с минимальным лагом

Так на нем и надо было проверять. У Вас есть такой или похожий кодек? Проверьте пожалуйста.
Кстати, использование более продвинутых форматов типа mpeg2 или H.264 значительно снизило бы требования к потоку. Какой минимальный лаг там возможен?

baychi
Android1:

Увидедь бы как оно работает decima.ru/video/mobile.html

Примерно так: Частота кадров (SQCIF: 128x96 точек), max (кадр/сек)5
😃

Stas#

Причем оно запоминает видео у себя в буфере, а потом гонит по сети.

Чем сохраняли, какой формат JPEG? И пробывали ли сохранить ту-же фотку в цвете? Я к тому, что обычно открыв исходную фотку с фотика, а затем сохранив ее, мы получим файл уменьшеного размера. Проделал такой-же эксперимент. При исходной фотке 2 мб, сохраненная в ч/б весила 350 кб, а в цвете - 400.

Согласен. Мой первый опыт неудачен. Сделал по вашей методике. Получил соотв. 370 кб в цвете и 320 в ЧБ. Во 2-м опыте использовал ФШ ЦС 4. Параметры компрессии одинаковы для цвета и ч/б.

Так на нем и надо было проверять. У Вас есть такой или похожий кодек? Проверьте пожалуйста.
Кстати, использование более продвинутых форматов типа mpeg2 или H.264 значительно снизило бы требования к потоку. Какой минимальный лаг там возможен?

МЖПЕГ кодека в системе нет, но думаю, что опыт будет аналогичен сохранению фото в ФШ.
МПЕГ 2 в том виде как используется на ДВД имеет длину макроблока 12 кадров, т.е. лаг 1/2с.
У Н.264 и того больше. Лень копаться, но там вообще секунды.
Вся прелесть кодеков с межкадровой компрессией в уменьшении потока без потери качества. Если в них уменьшить длину макроблока, то возрастет качество видео, но и битрейт.
Можно попробовать использовать что-то из AVC кодеков, как на проф. видео. Там есть варианты без межкадровой компрессии, но за счет сжатия на основе вейвлет-преобразования они легче по потоку, чем МЖПЕГ. Только процесорные ресурсы нужны большие для компрессии или апаратный кодек.

РД00
KIR2142:

Вы когда-нибудь играли в современный шутер или симулятор при пингах околок 200?

Летал при задержке от объектива до очков 200 мс. Не бог весть какая беда.

VRV

Самому интересна тема передачи видео в реальном времени, правда задачи чуть иные.
Передовал по udp протоколу сжатые картинки, т.к. любой кодек, сжимающий в поток использует буфер, и даже 0.5 задержки неприятны. Кстати не работает ваша ссылка на проектик - перезалейте если не трудно.
Вы нашли какойто бесплатный кодек mjpeg или пользуетесь интерфейсом VLC ?

По сути проекта задумка реализуема. На сегодня сам пользуюсь моб инетом от Утел (сеть 3g). Более менее стабильная скорость потока около 30 кбит/сек., что может обеспечит поток до 15 кадров правда низкого разрешения. При передаче mjpeg 640х480 врядли фпс будет больше 3. Но вроде как уже сейчас действуют сети 3.5G и грядут 4 поколение, как раз и заточеное под передачу данных. (в теории для 3 поколения 3мбит\сек, для 3.5 - 7 мбит\сек).

Stas#

Может кто-то объяснить суть показанного на видео постом выше?

Korogodsky
VRV:

Кстати не работает ваша ссылка на проектик - перезалейте если не трудно. Вы нашли какойто бесплатный кодек mjpeg или пользуетесь интерфейсом VLC ?

rapidshare.com/files/441261204/EXE.7z
Все что связано с видео идет через VLC. Передачу команд управления можно оптимизировать, сейчас каждая команда отправляется отдельной датаграммой, их можно склеивать (всего их сейчас 24) и отправлять одной строкой. И в обратном направлении с борта на базу данные (не видео, пока только текущий IP) слишком часто идут.Программу не дорабатываю, жду серво-контроллер и занимаюсь механической частью авто (я выше писал что испытания буду проводить на наземном ТС). ЛА буду делать, думаю, не раньше будущей осени, остановился на летающем крыле с одним импеллером и двумя управляемыми соплами, еще ничего не чертил.

VRV

Не совсем понял назначение файлов в проекте(какой из них отвечает за захват и передачу видео), к тому же файл IPFPVBoard.vshost.exe вызывает ошибку.
Какая у вас получилась нагрузка на сеть/цп при трансляции VGA видео и при какой частоте кадров?

Korogodsky
VRV:

Не совсем понял назначение файлов в проекте(какой из них отвечает за захват и передачу видео), к тому же файл IPFPVBoard.vshost.exe вызывает ошибку. Какая у вас получилась нагрузка на сеть/цп при трансляции VGA видео и при какой частоте кадров?

libvlc.dll, libvlccore.dll, папка plugins - это VLC
В IPFPVBase - JoystickInterface.dll - библиотека для работы с джойстиком.

В проекте используется .NET Framework 2.0, если он отстутствует - это не обрабатывается, ошибка в IPFPVBoard возможно из-за этого. Если .NET 2.0 установлен попробуйте настроить исключение в Брандмауэре или временно отключите его. Напишите пожалуйста о результате. Буду исправлять ошибки.

Нагрузка на процессор 2.4GHz 6600, при запуске каждого из модулей не более 10%, про нагрузку на сеть сейчас ответить не смогу, видео-битрейт вы можете устанавливать сами.

Stas#

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

Хотя и офтоп, но “летабельность” данной схемы даже без ФПВ под сомнением.

Korogodsky
Stas#:

Хотя и офтоп, но “летабельность” данной схемы даже без ФПВ под сомнением.

Не могли бы вкратце пояснить?

Stas#

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