Летаем на пингвинах... (виртурилка, Raspberry Pi ... etc) где все в одном флаконе
Периодически люди пытались. Читал… любопытно… Решил доработать в меру разумения. Итак, суть идеи: чтобы иметь видео и управление через один IP канал (WiFi, 3/4G etc) не хватает готовой управляющей программы на земле и стабилизатора полета на борту. В принципе, и то и другое уже как бы существует и называется MultiwiiConfJoystick ну и собственно Multiwii… Чтобы подружить все вместе через пигвина я лично сделал - так:
На земле , Вин-машина с джойстиком(я использовал геймпад) и указанной выше программой. На машину ставится подходящий эмулятор com-порта умеющий пробрасывать его по TCP/UDP куда то вдаль по сети(лично пробовал две разных программы с разным результатом).
На небе - любая пингвин-плата на ARM (тут уж кто во что) я лично использовал плату от планшета с A10 на борту. Это не лучший выбор из за отсутствия адекватного аппаратного сжатия видео, но “за неимением горничной…” В этом смысле виртурилки и малины думаю лучше будут- из за их склонности к FullHD. Если как у меня - то используется камера которая сама умеет жать аппаратно хотя бы mjpeg (обычная копеечная вэбка). Минусы - ширина канала(неэффективный алгоритм сжатия)… лаги… ну и собственно качество “видео”(640х480 не завораживает). Плюсы - очевидны(халява).
А теперь главная фишка “проекта” - к бортовому Linux подключается любая мультивии плата. Дешево так и сердито… 😉 Подключается она через СВОБОДНЫЙ com(при наличии оного) на пигвин-плате или через USB конвертер (при отсутствии оного, как у меня - я воспользовался встроенным в Arduino Nano FT232-конвертером) “СВОБОДНЫЙ” в контексте затеи означает - “не используемый по сериал-консоль пингвина”
Далее на Linux тоже запускается редиректор TCP|UDP в tty (т.е. com;))… тут выбор поболе чем в окнах, (я лично использовал - socat). Для моего Linaro он встал просто из пакетов. На экзотике типа виртурилки может придется собрать из исходников.
Для тестов запускаем socat в терминал-сессии на избранные нами порт, протокол, tty (на этом этапе лучше с ключом -v чтобы видеть что кому и куда шлется) ессно предварительно подключив к этому tty мультвию. Затем коннектимся к пингвину виндовым редиректором с вин машины (например через WiFi) . Запускаем на ней МултивииКонфДжойстик выбираем виртуальный ком созданный виндовым-редиректором, жмем “START”.
Если ничего не провтыкали с настройками (обоих концов) наблюдаем как на графиках начинает бежать статистика, а при кручении джойстика самолет машет крылами😒… там конечно есть нюансы, но в принципе все работает
Плюсы такого решения - быстрота получения результата, освобода в выборе платы пингвина, относительно предсказуемость поведения аппарата в воздухе (мультивия настраивается заранее и отдельно от всего обычным способом), можно управлять любым типом ЛА. Минусы - линукс катается почти пассажиром(ну разве что видео жмет) а самолетом рулит дохлый контроллер на меге. Не эстетично… Ну эстеты могут копить деньги на БиглБоне Блэк и ждать допиливания под него Linux порта Ардупилота.
как то так…
ЗЫ
Поскольку не все вин редиректоры оказались одинаково хороши(а хорошие оказались платными:)),и обещанный открытый код МультвииКонфДжойстика автор так и не опубликовал, по ряду причин пришлось родить свою версию подобной программы(тоже на основе обычного MultiwiiConf) но с менее кривой(имхо) поддержкой джойстика и уже встроенной работой через UDP (не нужен отдельный редиректор). Тестируем… вот… её… Лаги в канала управления - вроде как упали до разумного()незаметного на глаз) уровня. Кнопки геймпада эмулируют недостающие аналоговые стики… плавно… а не как у бельгийца… лепота…
Извиняюсь за некоторую жаргонность и поверхностность описания процесса настройки, но полагаю что любой и каждый в описанном направлении экспериментировать не станет, а те кто морально готовы к таким экспериментам не требуют рассусоливания процесса до конкретных команд.
В качестве иллюстрации только приведу наиболее ключевые настройки чтобы не ходить часами по граблям
запуск socat для связи через UDP для работы через порт 5555 c Multiwii подключенной к ttyUSB0
socat -b512 UDP-LISTEN:5555,fork,reuseaddr FILE:/dev/ttyUSB0,b115200,raw,echo=0,crlf,nonblock
для работы через UDP здесь существенный (имхо) параметр -b512 … это что то вроде размера кадра(в байтах) который socat пытается накопить прежде чем отослать (ну так я во всяком случае воспринял логику происходящего) если делать этот -b поменьше то снижаются задержки в обмене командами (в теории) но при и b < 128 начинаются проблемы в работе через UDP (при связи через TCP я снижал это b до -b32 там все работало а через UDP … увы не очень.) если -b убрать то размер кадра по умолчанию будет 8192. оптимум имхо лежит где то в пределах до 1500 (т.е. размер стандартного ethernet пакета)
и не все виндовые редиректоры умеют через UDP
для связи через TCP (при прочих почти равных)соответственно
socat -b64 TCP-LISTEN:5555,fork,reuseaddr FILE:/dev/ttyUSB0,b115200,raw,echo=0,crlf,nonblock
общие идеи процесса - тут:
en.wikipedia.org/wiki/COM_port_redirector
из перечисленного в Вики под виндой пробовал:
- HW-VSP3
www.hw-group.com/products/hw_vsp/index_en.html
бесплатный но в предлагаемой конфигурации работает фигово (похоже из-за крошечных размеров своих буферов)
2)TCP-com
pcmicro.com
намного он получше у меня работал(там размер буферов регулируется + UDP режим у него есть и сама программа намного стабильнее) но стоит он денег, я пользовал 30 дневную trial
пробовать остальные перечисленные в Вики варианты не возбраняется 😉 может еще что работать будет, хотя я после серии экспериментов таки решил от виндового редиректора избавится и переписал MultiwiiConf для работы напрямую через UDP, но пока это Under Construction, готовой сборки не делал и запускаю свою версия через Processing IDE
а обычный МултиВииДжойстик, брать - тут:
www.multiwii.be/multiwiijoystick
из перечисленного в Вики под виндой пробовал
А не логичнее бы вообще уйти от винды и осесть под пингвином? Чего не хватает?
винда - потому что нет полной ясности с поддержкой джойстика из под Processinga под Linux(в интересном мне варианте) для используемой мной джойстиковой библиотеке. Библиотека lджойстика кстати иная чем у автора MultiwiiConfJoystick использована. Потому и конфигуратор джойстика не столь унылым вышел как там ). И вроде заявлено что библиотека кросс-платформенная На интел-Linux думаю оно заработает… но пока не пробовал Строго говоря, я о существовании Процессинга узнал то неделю назад … пока в код не полез. До этого думал что ОНО все на обычной Яве было написано и страшно дивился со стильного готического интерфейса , который без обновления до последних OpenGL драйверов жить не может и не хочет.
Вот если бы это все заработало на ARM-пингвине тогда поинтересней бы было… в плане компактности станции управление… устройство стало бы носимым… но тогда нужны исходники сошной части той библиотеки (читай - сишной) а где ж их взять… да и тогда уж логичней на андроиде что то лепить а другой круг вопросов возникает…
ЗЫ
lда и для быстрой материализации чувственных образов винда удобнее… если бы надо было лепить продаваемую систему или переходить на иную аппаратную платформу то в пингвине на земле был бы смысл… тот или иной… а так… я его слепила из того что было…😒
С андроидом оно может и логичнее, но скорее всего очень многого не хватать будет, а писать с нуля то, что пользовать будут 100 человек, никто не станет…
с пингвином под арм свои нюансы, где главный - сборка сборки под конкретную аппаратную часть… особенно геморно будет с поддержкой экрана и тача … или хотя бы экрана… а если на внешний монитор выводить смысл компактности уходит…
в теории можно сделать нечто наподобие любимых всеми самопальных шлемов только вместо колхозного тв экрана использовать полноценный планшет на те же 7 - дюймов…прошитый пингвином… но тогда мултивииконф заслонит собой все небо своей дикой красотой))))
Круто. Я как раз ковыряюсь с beaglebone black. Сегодня поставил на него ubuntu. Через udev при втыкании 4g модема на борту появляется интернет. Жду заказанные сенсоры для стабилизации полета.
Еще посматриваю в сторону ROS. Для arm тут как раз раздолье. Тема очень интересная.
ну я с тех пор еще видеолинк в стандартный мультивииконф добавил для полного комбайна чтобы видео на землю по UDP слал, а на пингвине крутится mjpeg-streamer тоже немного мною переписаный в дневнике есть фото где ОНО само на себя смотрит
а ROS - мутная какая то да и навскидку большая часть ее наработок мне показалась малополезной для летающего робота… там все их фишки вокруг моделирования кинематики крутятся а какая у леталки кинематика - никакой… SLAM тоже малополезен из за колоссальной глубины пространства у всего летающего (в сравнении со всем ползающим) плюс она далеко не RT пока ОНО допрет что надо было делать самолет метров на 30 улетит от точки когда надо было ЭТО делать… а если “ЭТО” было скажем облететь препятствие…тооо ответ очевиден 😒 ну вот смысл в таком компьютерном зрении ?! а что еще от ROSa использовать можно пока не придумал.
Обновлю тему.
Офегенно…суть ясна,насколько вафля 100mw пробивает без патчей (ЛА-оператор)?
Были такие же мысли гнать сжатое видео по udp,а на ЛА только управляющие сигналы (с пульта,планшета,джостика,чего угодно).
Думаю подобное будет дешевле чем мутить для поиграца DJI комплекты и им подобные.
ЛА:
Нужны WiFi модули 100mw и более.(100-300$)
Расбери на борту или что то аналогичное.(70-300$)
Обмен 2.4 udp
Земля:
Планшет или иное устройство
На выходе качественное видео,целая лаборатория/автономный робот.
Минусы,дальность и возможно лаги видео,управления.
Офегенно…суть ясна,насколько вафля 100mw пробивает без патчей (ЛА-оператор)?
По земле полкилометра нормально, до 1км уже с провалами.
Нужны WiFi модули 100mw и более.
Как вариант - ТД - 800mW
С вафлей есть вариант и покруче, например микротиковская БС на 1,6 ватта правда к ней только через езернет и еще у нее корпус металлический как пишется… если тяжелый раздевать ее придется но с такой станцией на борту есть уже куда развернуться для более экономных можно и убикуити на 800 милливатт(но там тоже езернет) ну или альфовский усб адаптер(любимый моряками))… там пол ватта… были еше тплинковские на пол ватта усб когда то их как грязи было но сейчас сняты с производства… только по сусекам наскрести можно…
Из последних экспериментов:
На одной стороне Ubiquiti PicoStation 2-HP на другой D-link dwl-2100ap c h/w хаком.
Обе точки выдают ~400мВт.
Антенны - сосиськи.
1200м по земле - линк стабильный, картинка есть. В воздух пока не поднимал.
Все проблемы начнутся в движении ( полете). На одной стороне ( в воздухе) www.ubnt.com/airmax/rocketm с двумя штырями л\4 .Просто кабель со штырем и распушеной оплеткой в качестве противовеса. На земле вот эта хренька -www.ubnt.com/airmax/powerbridgem. Дальность 10 км. Особо упрямый ( обученный) товарищ наводил патч по светодиодам на задней стенке. Луч 6 градусов. Провалов не было, но идея признана несостоятельной. С 900 мгц РОКЕТАМИ все вообще плохо. Сигнал -60-65 Дбм, а дальность метров 300. Трахались три недели…
У литовцев есть вот такой девайс. Плата 10х10см стоимостью 55 вечно-загнивающих. Там 1000мВт 5Гигагерц на плате. Этот диаппазон в движении будет лучше. Держал ее на выставке MUM в Москве, еще тогда появилась мысль на коптер поставить для HDвидеолинка.
Для облегчения веса можно отпаять эти тяжелые Ethernet разъемы на малинке и на mikrotik, спаять например LVDS шлейфом от старого ноутбука или монитора
Провалов не было, но идея признана несостоятельной.
Почему? Трекер есть, если ограничится небольшим расстоянием в 1-2км то мне кажется вполне можно использовать для реальных полётов.
Там 1000мВт 5Гигагерц на плате.
Меряли? А то у того Picostation, что у меня, реальная мощность ровно в два раза ниже заявленной.
ля облегчения веса можно отпаять эти тяжелые Ethernet разъемы на малинке
На малине не выйдет, разъём с встроенным трансформатором. Микротик не проверял.
спаять например LVDS шлейфом
Мышинный кабель тоже неплох.
Почему? Трекер есть, если ограничится небольшим расстоянием в 1-2км то мне кажется вполне можно использовать для реальных полётов.
Задача стояла в 15-20 км. Вся эта техника должна быть “прибита на забор” или на мачту на доме. Тогда все , что обещано производителем - получается на ура. Для работы в движении - COFDM, но там цены даже не смешные.
“Главным преимуществом метода передачи COFDM является использование многократных отражений излучаемых сигналов от строений, стен и т. п. с коррекцией возникающих при приёме искажений и ошибок.Обеспечение как устойчивого приёма, так и проведения трансляций в движении и т. д.”- украдено у WIKI. Производитель даже макс. скорость движения указывает.
Меряли? А то у того Picostation, что у меня, реальная мощность ровно в два раза ниже заявленной.
Нет не измерял. Не могу сказать.
На малине не выйдет, разъём с встроенным трансформатором. Микротик не проверял.
На микротике там тупой разъем, транс отдельно припаян на фото просматривается, а вот незнал про малинку, сейчас даже взглянул на свой beaglebone black там тоже со встроенным трансом. Ну хоть с одной стороны припаять мышиный кабель а с другой обжать. Антенну можно сделать как у пользователя ekf
Просто кабель со штырем и распущенной оплеткой в качестве противовеса.
Имхо нужны клевера, в качестве антенн, тогда часть “проблем движения” снимется, во всяком случае ва-фай экспериментаторы писали что с клеверами леталось явно лучше несмотря на их меньшее усиление…
касательно “преимуществ в небе” 5 Ггц над 2.4Ггц очень спорно имхо, ну во всяком случае для такой конфигурации (дуплекс), в небе может это и не плохо но надо же и с земли на этой частоте передавать а вот тут уже все кисло… ну разве если только недалеко и высоко
по поводу мощностей пикостейшн… для ряда стран мощность передачи у таких штук искусственно ограничена профайлом настроек для страны… не буду утверждать что в убикуити ИМЕННО так(хотя вероятность чуть больше половины) но в некоторых других изделиях так делалось чтоб не нарушать местное законодательство… так что мы тогда в настройках выбирали мексику или еще какую нибудь дикую сомали в надежде что там никто ничего не ограничивает… но правда ТОЧНО мерять результат было нечем… еще для улучшения качества вай-фай связи помогает ограничение ширина канала до 20 Мгц (автоматом там обычно 20/40) на дальних линках широкий канал теряет свои скоростные преимущества но сигнал/шум в узком будет лучше
В попытке оживить прошлогоднюю тему хочу задать несколько вопросов!
Есть мысли построить автономный дрон, на базе Bixler3, который будет пролетать по маршрут и возвращаться на место взлета или в заданную точку, благо современный софт это позволяет! При этом видео должно транслироваться на землю.
Планируемая аппаратная платформа :
собственно сам дрон - бикслер 3
в качестве платформы для обработки видео (хочется full HD) выбрал Raspberry Pi Model A+, к ней видео передатчик на 500mW.
в качестве автопилота вторую малину и плату Navio+ (www.emlid.com/shop/navio-plus/ ссылка не является рекламой).
видео будет передаваться по радиоканалу видеопередатчиком с первой Raspberry pi и телеметрию.
также к малине, которая с автопилотом, подключить 3g модем, для резервирования данных телеметрии и корректировки маршрута полета в случае необходимости.
Как лучше осуществить передачу видеосигнала на расстояние более 2х км?
Просьба не забрасывать “помидорами”, самолет и необходимое железо уже заказано и едет.
P.S. Про все предыдущие попытки постройки автономного дрона уже прочитал.
В моем случае основным критерием является безопасность полетов!!
Есть мысли построить автономный дрон, на базе Bixler3
В эту тушку две малины + wifi+усилитель… Вы вес и объём хоть прикинули?