Activity
Слежу за это замечательно темой, столько идей здесь собрано - от управления по интернету к моделям с вертикальным взлетом, RC машинкам, нейронным сетям, искусственному интеллекту и даже собственному автопилоту.
осталось всего ничего, спросить на форуме равняется ли угол отклонения РУ углу между курсом и целевым направлением
Я смотрю вам нравится потыкать людей, буквально смакуете чужие ошибки… Будьте добрее к людям. Помогать можно и без злого сарказма.
Да, порой автора немного несет, вертикальный взлет, искусственный интеллект, явно за областью объявленной задачи, да и автопилот пока рано.
Пусть модель для начала полетит. Но говорить об этом так как вы - губить идею. А здравые идеи тут все таки проскакивают.
ЗЫ. Как насчет нанотоплива кстати? Тоже вроде нужная штука для полетов на дальний расстояния.
Зря иронизируете 😃 нейронная сеть действительно способна довольно эффективно рулить самолетом даже используя в качестве железа ПК. И это гораздо проще чем научить ее ходить используя 6 ног.
Но вот в чем я с вами согласен это совсем отдельная тема явно выходящая за рамки проекта.
(Думаю для эффективной разработки этой идеи, может понадобиться усилие научного коллектива. Одна наработка и выборка обучающих данных займет пару месяцев.)
Не стоит углубляться в фантазии не имея синицы в руках.
Максим, я бы пока на вашем месте не стал заморачиваться на искусственный интеллект.
У нас конечно простейший случай для нейронной сети
входов будет штук 10 - 3 координаты текущие, 3 координаты конечные, текущие скорость, крен, тангаж, рысканье (возможно стоит еще добавить последнюю корректировку курса чтобы ввести обратную связь избегая ухода системы в колебания)
выходов четыре - руль высоты, руль направления, элероны, тяга двигателя.
Реализуется на стандартных библиотеках на раз.
Это единственный плюс, теперь минусы.
Главное отличие нейронной сети от алгоритмов в том, что система не дает 100% результат. Ты никогда не сможешь сказать почему система сделала так или иначе, допустим обучил ты систему (что уже маловероятно не угробив самолет), будет она у тебя нормально летать 99 полетов из 100. В этом одном случае выявить какую либо ошибку ты не сможешь никак. Целые научные коллективы бьются над технологиями обучения нейронных сетей 😦
Под каждый новый самолет систему придется переучивать, тут нельзя просто коэффициенты на рулевые плоскости подобрать и в небо.
Я предлагаю отложить ИИ, до тех пор пока не сделаешь и оттестируешь обычный автопилот или хотя бы систему стабилизации способную удержать самолет при рулении нейронной сети. После того как реализуешь автопилот классический у тебя появится большее понимание как должна работать система.
Хотя если подумать действительно можно снять а затем скормить сети логи пары тройки собственных полетов из точки в точку, лучше прохождение по нескольким точкам. Это будет проще реализации обычного автопилота, научит сеть нормальным режимам полета, но что она будет делать в ситуации которой ее не учили - непредсказуемо.
Вобщем мое личное мнение. не стоит распыляться это все можно сделать потом.
Не за горами уже тот день когда можно будет начать делать автопилот. И, т.к. я пока весьма смутно представляю себе алгоритм автопилота, хотелось бы на эту тему тоже что-то услышать, прям по пунктам - как это работает.
Для начала вот это.
www.airwar.ru/breo/pnk/pnk4.html
и это =)
www.google.ru/search?aq=f&sourceid=chrome&ie=UTF-8…
Если очень простым языком, знаем конечную точку, куда летим, знаем наше положение в пространстве (данные от GPS) из этих данных вычисляем необходимый нам вектор направления на конечную точку.
Знаем вектор нашего текущего движения и положение в пространстве (данные от гироскопов и акселерометров) высчитываем корректировку курса (вычитаем вектора), умножаем на определенный коэффициент (для каждого самолета свой), получившиеся значения проверяем на предельные значения способные убить полет при необходимости ограничиваем, и подаем на управляющие плоскости.
Получаем новую порцию данных от GPS и гироскопов, повторяем все заново.
Вроде все просто, но тут есть несколько засад. Если коэффициент можно не подбирать для каждой модели, а динамически вычислять отслеживая реакцию модели на изменение положения управляющих плоскостей, то что делать с остальным не ясно.
Знать свое положение в пространстве жизненно необходимо, причем не только конкретную точку в небе, но и вектор движения, (тангаж, рысканье), крен ты при всем желании из GPS не вытянешь. Нужна гироплатформа, а те что есть в доступном ценовом сегменте сильно дрейфуют, и что с этим делать не совсем понятно, пытаться корректировать гироскопы через акселерометры и магнитный компас разве что. Либо обойтись пироголовами. имхо зная только GPS не вытянешь даже самостабилизирующийся самик.
Приятно видеть что тема по тихоньку, но движется.
Правда успел два раза работу сменить, каркас дома построить, и крышей накрыть, а тут Максим систему телеуправления вполне работающую уже в апреле, только на машинку поставил.
Медленно, но желаю удачи, сейчас осень наступит больше времени свободного будет. Почаще пиши об успехах.
Ответил в личку чтобы не засорять чужую тему.
Неужели в системе не найдется ни одного аппаратного таймера на прерывание которого можно обработчик повесить…
В S3C2440A 5 аппаратных таймеров, надеюсь нанопингвины хоть один мне помучать оставят… И фиг с небольшим дрейфом из за других прерываний…
Ладно посмотрим, померим…
* в грусти ушел читать даташит…
Фиг вам
GPIO порты - это вещь соблазнительная, но, мне даже под нанопингвинами из ядра не удалось обеспечить выдерживание необходимых временных интервалов. При этом я писал ядерный драйвер и вкомпиливал его в само ядро операционки.С одной микросекундой даже нанопингвины не справятся, какие бы они realtime пропатченные не были.
А ведь правы. Упустил из виду что тут многозадачная операционка для которой микросекунда это много.
Думал использовать вот такой алгоритм требует мало системных ресурсов, на тиньках работало.
Но менее требовательный к таймингам ШИМ например для двигателя с обратной связью через датчик оборотов все еще подумать можно.
Хотя 25 баксов за отдельный модуль управления сервами с интерфейсом RS232 не сверх деньги, его надо заказывать и ждать пока приедет =(
Эм ну тогда клиентской ))
Кстати там на плате 32 порта ввода/вывода которыми можно программно дергать. Думаю не буду покупать отдельный модуль для управления сервами. Лучше на этих портах через опторазвязку буду реализовывать контроль сервами и ШИМ для движков. Но это уже по приходу железа. Тут работа подвернулась времени вобще лишнего нет.
Если не использовать операционку на ARM’e, то стопудово сразу налетаете на грабли в плане реализации сетевого драйвера, с этой проблемой я уже сталкивался, но только на платформе blackfin.
Однозначно будут нанопингвины. Писать самому с нуля ОС вещь утомительная и крайне глупая. И Я не уверен в возможностях оборудования поэтому заранее продумываю все варианты, архитектуру опять же изучаю. Железо будет через 3 недели примерно, посммотрю что оно может, тогда и буду окончательно решение думать.
А пока пишу модуль который сможет использовать в качестве серверной части программу Максима. Все меньше самому писать.
На а собрать готовое решение это проще всего, успеется.
Очередной велосипед ну не понимаю я зачем писать что то свое, когда можно изучить то, что уже есть и прекрасно работает.
Велосипед делаю потому, что оно должно потом работать на плате ARM9.
Если кому интересно как завести mediastreamer2 под win - могу написать туториал.
А вот это можно, в личку пожалуиста.
Меня все время не отпускает мысль, что мы не первые думаем над этой проблемой, и скорее всего до нас были и те кто разбирается в вопросе лучше нас. Может поискать в интернете готовые методы снижения битрейта видеопотока без межкадровой компрессии?
Уже пробовали сравнивая объем сжатого статичного файла. Разница не больше 20%.
У меня при использовании серого от 30% до 50% размер уменьшается. Так что смысл имеет.
Уважаемый товарищ Легион, заканчивайте тролить и уйдите пожалуйста из темы, ваше мнение тут все поняли и приняли.
Здесь ОБСУЖДАЮТСЯ конкретные идеи, разработки и предложения, а Вам правило “критикуя - предлагай” похоже не знакомо.
Доделал собственный захват картинки с вебки через v4l2 драйвер, и сжатие ее в памяти при помощи libjpeg сегодня попробую сделать отправку через UDP. По идее обработка чуть шустрее должна получиться. Максим выложите пожалуйста формат команд для управления качеством картинки. Попробуем совместимым модуль сделать. =)
А полукадры на рисунке не должны быть в два раза меньше по высоте???
JPEG наверное это скушает, но скажем если взять два абсолютно одинаковых кадра, на одном повыкидывать все четные пиксели (т.е. сделать ресайз), затем его сжать (с потерями!). Потом во втором кадре повыкидывать все нечетные пиксели (ресайз), сжать. После получаем кадр “сложением” из двух. И этот результирующий кадр не будет попиксельно равен исходному. И вот интересно насколько изменится картинка.
Если взять один кадр, сжать Jpeg а затем обратно распаковать будет ли он попиксельно равен оригиналу?
А Дмитрий прав, если подумать таким образом мы избавляемся от расчески, но и вносим дополнительное размытие в картинку, Jpeg уменьшает контрастность соседних пикселей в пределах блока 8х8. Выходит обычные полукадры чересстрочной развертки лучше?
Кстати согласен и с тем, что 5 кадров крайне мало, минимум на котором я не ощущаю явный дискомфорт - 14-17 кадров все что ниже воспринимается как лаги и слайдшоу.
Если я все правильно понял, из рисунка получается что полукадры должны быть в два раза меньше по высоте, а это и выходит черезстрочная развертка по горизонтали и вертикали, или нет???
А какая собственно разница по какой оси сдвигать пиксели по высоте или по ширине? Это видимо только вопрос вкуса.
Нет кадры не должны быть меньше по высоте, представьте что серые пиксели это кубики на столе и вы их сдвигаете например влево, кадр уменьшится только в 2 раза. Думаю идею с такой разверткой можно оставить.слишком много мороки с ней а результаты скорее всего будут скромны.
Я думаю это будет происходить мгновенно - повыкидывать через один пиксель из битмэпа.
Нет, нет, смысл не в том чтобы просто выкинуть каждый второй пиксель в битмепе, а затем все это сжать. Ясно что в этом случае будет фигня. Смысл в том, чтобы из битмэпа полного кадра вытащить каждый второй пиксель и сгенерировать из этого битмэп полукадра, получим то же изображение сжатое в два раза по одной из осей, - jpeg скушает. Затем после получения jpeg и его раскодирования, на финальном битмэпе заменить точки также в шахматном порядке.
А при подготовке следующего кадра выбирать другие пиксели и заменять на финальном битмэпе другие пиксели. Надеюсь не очень сумбурно обьяснил
На фото передача на самого себя, через удаленный комп (пинг до которого ~12 мс) задержка больше на 0,1 сек. Но это используя HTTP и браузер в качестве клиента.
Если одна шабашка мимо пролетит и будет свободное время, попробую сварганить передачу на UDP с выводом программой через OpenGL. О результатах доложусь.
А вот со скростью похоже ошибочка сейчас пришел домой посмотрел на скрины, ну мало как то 85 кБ/с, это похоже скорость не в килобитах, а в килобайтах, соответсвенно это 680 кб/с? Приду на работу проверю точно. Просмотрел я это как то. (кстати я использовал 24 кадра в секунду).
Так что соответственно вопрос о чересстрочной развертке остается в силе. Кстати делать чересстрочку и по горизонтали и по вертикали не советую, получается что кадр полностью обновится только через 4 четвертькадра, при 20 четвертькадрах это 0,2 секунды многовато как то. Может лучше полукадрами но не чересстрочной разверткой а в шахматном порядке пиксели слать, это сразу сгладит расческу оставив полное обновление картинки за 2 полукадра.
Вопрос в том насколько увеличит время обработки такая выборка, стоит ли овчинка выделки в конце концов можем прийти к тому от чего пытаемся уйти - увеличим задержку =(
Поиграл сегодня с видео в Linux купил для этого дела самую дешевую USB 1.1 вэбку за 599 рублей.
Для передачи использовал motion в режиме 320х240 jpeg сжатого с качеством 20%. Передавал через HTTP поверх TCP.
Для отображения использовал браузер Crome постоянно перезагружающий картинку.
В целом результаты таковы.
в 320х240
при сжатии 20% передаваемый поток 85 кб/c задержка 0.3 сек (0,4 на соседнем компьютере)
при сжатии 50% передаваемый поток 120 кб/c задержка 0.3 сек (0,4 на соседнем компьютере)
В обоих случаях качество картинки довольно удовлетворительное. Похоже на обычный аналог переданный через эфир.
В принципе летать сложно но можно.
Думаю в сторону следующих улучшений.
Передача через UDP.
Своя программа для просмотра картинки с отрисовкой через OpenGL.
Даже для большой авиации подбор плошадок с воздуха сложная задача. На это одельный допуск пилоту дается. А вы хотите это по видеокартинке сделать.
Ну посадка пассажирского ЛА и РУ модели это немного разные вещи. Думаю нет ничего невозможного.
Уважаемый топикстартер, можно видео с десктопа, хотелось хотя бы приблизительно оценить качество.
почему же не стоит? ведь есть всякие интернет телефоны, тот же googletalk и skype. они довольно быстро передают видео по узким каналам. а jpeg-и слать с каждым кадром - слишком хороший канал нужен для приличного качества
-Stas- прав, здесь есть противоречие, для того чтобы добиться максимального качества при минимальном битрейте почти все кодеки (и скайп с гуглом тоже) используют межкадровую компрессию, сжимают не отдельные кадры, а блоки по 5-10 кадров. Для этого им необходим буфер из нескольких кадров, в результате задержка. В видеоконференции задаржка 0,5 - 0,7с ничего не значит. в FPV она критична.
Думаю действительно стоит отказаться от стандартных кодеков и пробовать сделать что то самому.
Почему 1400 байт? Максимальный размер датаграммы - 64Кб, я пробовал передавать JPEG размером около 50Кб. Проблема в том, что в 64Кб нужно уложить 1 секунду видео, потому как Yota больше не потянет, по моим замерам выходило 300-500Кбит/сек.
Это вы можете сделать датаграмму размером 64k, в реальности у всех систем передачи есть параметр MTU - максимальная длина передаваемого кадра, для ethernet - 1500 байт, для GPRS -1400, для DSL - 1492, для WiFi - 1500. (На самом деле тут все сильно зависит от оборудования).
Все что длиннее будет разбито на блоки такой длины, либо непосредственно вашим компьютером (информация разбивается на пакеты c длиной MTU вашей системы), либо транзитным оборудованием (фрагментация пакетов).
Засада в том, что если пакет фрагментирован, он не будет передан с сетевого уровня операционной системы на уровень приложений до тех пор, пока не придут все кадры и система не сможет из них собрать полный пакет. В результате один задержавшийся пакет создает задержку для всех остальных, а один потерянный пакет гробит всю датаграмму, так как она не может быть верно собрана. В общем таким образом поучаете минимум лишнюю задержку.
Лучше изначально закладывать передачу блоками по 1400-1450 байт.
Теперь нужно поработать над снижением битрейта, т.к. через несколько секунд начинает накапливаться задержка и продолжает расти, может у кого-то будут мысли как это побороть?
Попробуй черезстрочную развертку - уменьшишь битрейт 2 раза при той же частоте кадров. Правда получишь расческу при резких поворотах камеры, но с ней можно бороться фильтрами.
Подумай над возможностью синхронизации видео путем пропуска кадров.
В общем за работу респект и уважуха.
UncleSam, спасибо за ценную информацию!
Сервы реагируют очень хорошо, меня полностью устраивает скорость реакции, замеров не производил, но там может миллисекунд 200. Видео посредством библиотек VLC в MJPEG передается очень плохо, дело не в задержках, а в потерях пакетов, не видно ничего кроме сплошных сбоев.
Добавлю: причина предположительно в том, что VLC разбивает каждый кадр на разные пакеты и отправляет кадр по-кусочкам, при этом после прохождения по UDP, пакеты приходят не в том порядке, в котором отправлялись, и кадр склеивается не правильно. Плюс еще потери пакетов.
Скорее всего проблема именно в потере пакетов.
Картинка упаковывается, затем разбивается на блоки максимум 1500 байт и передается. При потере одного пакета или при их перестановке картинку собрать не получится.
Думаю обычные кодеки тут не подойдут нужно делать что то свое.
Имхо необходимо программно контролировать своевременность и порядок доставки пакетов.
Например разрезать весь кадр на области, каждая из которых при сжатии гарантированно займет места не больше 1400 байт, добавить туда информацию о номере кадра и местоположении области в кадре. Получится всю информацию о конкретной области упаковать. Таким образом умещаем все в одну датаграмму, потеря которой не затронет остальную картинку и перестановка пакетов местами не скажется.
При получении такой датаграммы, мы знаем номер кадра к которому она относится и местоположение данных.
Если датаграмма устарела (кадр уже показан) убиваем ее сразу.
Если кадр еще не показан распаковываем данные в соответствующее место кадра. Если какая либо область кадра не была обновлена (датаграмма утеряна), подставляем данные из предыдущего кадра. (Можно организовать небольшой буфер максимум 2-3 кадра).
Используя черезстрочную развертку для 640х480 можно передавать кадры 320х480, качество ухудшится незначительно, уменьшим видеопоток вдвое (в телевизоре именно так все работает).
В общем для видео рулит оптимизация под конкретную задачу и отказ от стандартных кодеков.
Хм интересно, а если все же попробовать сформулировать требования к системе
- Работа без “лагов”.
Использование быстрой ЭВМ на борту позволяет снизить задержку вызываемую сжатием сигнала (у IP камеры все же другие задачи и задержка там обычное дело).
Передача сжатого видио через UDP позволит максимально сократить задержку.
Использование операционной системы реального времени или приближенной к таковой (сразу отметаем Windows да и в принципе все системы с графикой в приоритете, нам кино юзерам показывать не надо).
Linux без графики и лишних рюшечек обеспечит достаточное быстродействие.
- Аппаратура позволяющая организовать стабильный и быстрый IP радиоканал
Как человек пробрасывавший WiFi на 12 километров могу сказать усилитель сигнала и направленная антенна творят чудеса.
(правда на земле придется использовать систему автоматического позиционирования антенны)
- Механизм управления сервами
Сейчас их много делают для любителей роботов есть из чего выбрать.
- Наличие датчиков ориентации в пространстве.
Опять же их хватает и гироскопы и GPS.
в сухом остатке имеем примерно следующую систему
Имеем на борту
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 проект сделали же ребята открытую платформу для разработки роботов 😁