Полетные режимы вашего квадрика и направление на экране аппы
4refr0nt, THR и AIL всегда включены, наверное это неправильно.
9X, м128, v1.1.117
Прочитайте это
Наконец вчера смог выгулять своего питомца.😁
Экран,очень помог.😃
Правда в полете надписи мелковаты,чтоб на миг глянуть,что да как.Приходиться сосредотачиваться.
Из своих наблюдений.
Бортовое питание наверно лучше скинуть вниз отдельно,под радар.Сверху слева стока всяких питаний ,не успеваю понять,где на аппе,где на пульте.
И походу индикация бортовухи не совсем правильно работает,в начале показал,что акк разряжен,а под конец наоборот полный.Но это со слов напарника.
Да Виктор,не можете чуть подробней описать индикацию самого радара.Что-то недопонял…Что означают полоски кружечки?
Из ненужны параметров для меня.
Высота жпса.
Так и не понял,что показывает полоска под хдоп?
в полете надписи мелковаты,чтоб на миг глянуть,что да как.Приходиться сосредотачиваться.
Да, я так же думаю. Только как найти компромисс между набором отображаемых параметров и размерами шрифтов?
И походу индикация бортовухи не совсем правильно работает,в начале показал,что акк разряжен,а под конец наоборот полный.Но это со слов напарника.
Оставшийся заряд аккумулятора, ток и напряжение ардуине выдает APM. Ардуина отправляет его в пульт в неизменном виде. У меня неоригинальный PowerModule. Я его калибрую в MP при подключенном акке: Initial Setup -> Optional Hardware -> Battery Monitor: указываю свою емкость акка, измеренные тестером напряжение и ток, а MP сам выставляет Voltage Divider и Amps per Volt. Далее все работает примерно так: когда подключаете акк, APM считает, что тот полностью заряжен. Выдает вам на пульт напряжение с учетом дивайдера, рассчитаного при калибровке. Далее, под нагрузкой, считает ток и время - получаются амперчасы, которые он вычитает из введенной емкости акка. Поэтому если отключить/подключить разряженный акк - будет каша. Если нет PowerModule то эти данные, скорее всего, вообще не имеют смысла. Не могу точно сказать, как APM в этом случае считает. Без PowerModule ориентируйтесь по напряжению CPU.
Да Викор,не можете чуть подробней описать индикацию самого радара.Что-то недопонял…Что означают полоски кружечки?
На радаре три указателя: большой, маленький в одну полоску и маленький в три полоски.
Большой указатель показывает направление носа по компасу. До арминга направление соответствует обычному компасу (север вверху). После арминга работает как в SIMPLE режиме, т.е. вверху уже не север, а то положение, в котором находились до арминга, т.е. в точке взлета. Теоретически, чтобы вслепую вернуть коптер, который уже не видно куда повернут носом, нужно по пульту дать ему направление точно “на юг” и аппарат должен лететь в направлении к точке взлета и появится в зоне уверенной видимости. Вся затея с этой телеметрией мною задумывалась именно ради этого, а потом уже “обрасла” остальным.
Маленький указатель в одну линию - направление на текущий WP. Имеет смысл, если летаете по заранее спланированному маршруту в MP. Отдается в том виде, как его выдает APM.
Маленький указатель в три линии - направление домой. Находится в стадии тестирования, жду отзывов. Рассчитывается как и расстояние “до дома” по разнице текущих GPS координат и точки взлета (алгоритм тот же, что и в различных OSD).
Так и не понял,что показывает полоска под хдоп?
Это что-то типа “сердцебиения”. Индикатор приема данных. Заполнение этой полоски обратно пропорционально времени, прошедшему с момента приема последнего пакета данных телеметрии.
Полоска почти полностью заполнена - все ок, данные приходят. Не заполнена - превышено время ожидания, т.е. либо FrSky модуль не передает данные, либо ардуина. Попробуйте на земпле, когда все уже подключено и работает, сбросить ардуину кнопкой, при этом отслеживайте показания на аппе, вот тогда сразу все понятно станет.
Спасибо! Все работает четко, включая питание и иллюминацию (добавил все используемые режимы), только временные параметры мне кажется не соответствуют, но это не существенно.
По паттернам, кстати, замечание - длина паттерны должна быть одинакова для всех четырех каналов настраиваемого режима
как найти компромисс между набором отображаемых параметров и размерами шрифтов?
Может размер радара уменьшить?
“CPU” - нужен ли?
Индикатор приема данных
Не расточительно отдавать под него 4 пикселя?
Сверху слева стока всяких питаний
да, не разберешься… я бы напряжение пульта вообще убрал
Еще хотелось бы стрелочку на радаре более “сглаженную”, если не трудно 😃
я бы напряжение пульта вообще убрал
это напряжение в этом месте на всех страницах телеметрии. Из стандартной er9x. Переключаясь между экранами телеметрии вы всегда видите напряжение аппы в этом месте. Вот я и не взял на себя смелость это изменить. Тем кто привык, что напряжение аппы в этом месте, по другому покажется нелогичным. Так что попробуйте привыкнуть.
Еще хотелось бы стрелочку на радаре более “сглаженную”, если не трудно 😃
Если у вас версия для 64 меги, то сгладить можно, но нам не хватает памяти меги для подключения библиотеки расчета синусов и косинусов. А вырезать что-то другое ради красивости стрелок будет не очень разумно. Сейчас в этой версии углы считаются с точностью до 15 градусов. Синусы рассчитаны вручную и берутся из табличных значений. Поэтому, да, выглядит не очень.
Если у вас версия для 128 меги, то менее ломанную линию сделать невозможно - мы ограничены разрешением экрана. Правда есть вариант с использованием более красивых, заранее прорисованных не линий, а стрелок, но боюсь, мы опять будем расточительно расходовать все виды памяти меги (оперативки там тоже впритык). Хотя, быть может, готовые стрелки займут меньший размер, чем math библиотека. Кстати такой способ используется в OSD. Если кто-нибудь нарисует 16 или, хотя бы, 12 стрелок для радара (его размер 47х47) и они получатся симпатичней простых линий, то я постараюсь их запихать в существующий код.
Спасибо! Все работает четко, включая питание и иллюминацию (добавил все используемые режимы)
Поделитесь, пожалуйста, опытом по иллюминации. Какие режимы как у вас мигают.
Конечно!
//****************************************STAB***********************************************************
char REAR_STAB[] PROGMEM = "0100000000"; // левый передний
char LEFT_STAB[] PROGMEM = "1000000000"; // левый задний
char RIGHT_STAB[] PROGMEM = "0100000000"; // правый передний
char FRONT_STAB[] PROGMEM = "1000000000"; // правый задний
//****************************************ALTHOLD******************************************************
char REAR_AHOLD[] PROGMEM = "1000000000";
char LEFT_AHOLD[] PROGMEM = "1000000000";
char RIGHT_AHOLD[] PROGMEM = "1000000000";
char FRONT_AHOLD[] PROGMEM = "1000000000";
//****************************************RTL***********************************************************
char REAR_RTL[] PROGMEM = "1000000000";
char LEFT_RTL[] PROGMEM = "0100000000";
char RIGHT_RTL[] PROGMEM = "1000000000";
char FRONT_RTL[] PROGMEM = "0100000000";
//*****************************************LOITER*********************************************************
char REAR_LOITER[] PROGMEM = "1010100000";
char LEFT_LOITER[] PROGMEM = "1010100000";
char RIGHT_LOITER[] PROGMEM = "1010100000";
char FRONT_LOITER[] PROGMEM = "1010100000";
//******************************************AUTO*********************************************************
char REAR_AUTO[] PROGMEM = "1010000000";
char LEFT_AUTO[] PROGMEM = "1010000000";
char RIGHT_AUTO[] PROGMEM = "1010000000";
char FRONT_AUTO[] PROGMEM = "1010000000";
//******************************************LAND********************************************************
char REAR_LAND[] PROGMEM = "101000000000";
char LEFT_LAND[] PROGMEM = "101000000000";
char RIGHT_LAND[] PROGMEM = "000010100000";
char FRONT_LAND[] PROGMEM = "000010100000";
//****************************************OTHER***********************************************************
char REAR_OTHER[] PROGMEM = "0";
char LEFT_OTHER[] PROGMEM = "0";
char RIGHT_OTHER[] PROGMEM = "0";
char FRONT_OTHER[] PROGMEM = "0";
char *left[] PROGMEM = {LEFT_STAB, LEFT_AHOLD, LEFT_RTL, LEFT_LOITER, LEFT_AUTO, LEFT_LAND, LEFT_OTHER};
char *right[] PROGMEM = {RIGHT_STAB, RIGHT_AHOLD, RIGHT_RTL, RIGHT_LOITER, RIGHT_AUTO, RIGHT_LAND, RIGHT_OTHER};
char *front[] PROGMEM = {FRONT_STAB, FRONT_AHOLD, FRONT_RTL, FRONT_LOITER, FRONT_AUTO, FRONT_LAND, FRONT_OTHER};
char *rear[] PROGMEM = {REAR_STAB, REAR_AHOLD, REAR_RTL, REAR_LOITER, REAR_AUTO, REAR_LAND, REAR_OTHER};
Настроил только используемые мною режимы (ниже закомментированы коды всех режимов, можно по аналогии донастроить)
switch(last_mode) {
case 0: // STAB
index = 0;
break;
case 2: // AltHold
index = 1;
break;
case 6: // RTL
index = 2;
break;
case 5: // LOITER
index = 3;
break;
case 3: // AUTO
index = 4;
break;
case 9: // LAND
index = 5;
break;
default: // other
index = 6;
break;
}
/*
0 Stabilize
1 Acro
2 AltHold
3 Auto
4 Guided
5 Loiter
6 RTL
7 Circle
9 Land
10 OF_Loiter
11 Drift
13 Sport
16 PosHold
*/
Светодиоды подключил через ULN2803 по типовой схеме навесным монтажем, без ПП
Еще у меня есть идея вот такого развития проекта:
В турнигу устанавливаем ардуино про мини, которая выступает как коммутатор, на нее принимаем данные телеметрии с модуля FrSky, затем отдаем в пульт (чтобы получилось как сейчас) и такой же поток данных отдаем на блютус модуль который коннектится со смартфоном на андроиде. На смартфоне прога типа AndroPilot, только наша и заточенная на нашу телеметрию и с возможностью отображения на картах гугл положения нашего квадрика.
Надо подумать, как еще можно использовать ардуину в пульте (звуковой мод?)
Прошу отписаться о том, кто что думает обо всем этом.
Как то так получилось, что я пропустил этот проект.
Буду сдувать 64 проц, ставить 128, покупать Ардуину и наверстывать упущенное. Черезвычайно полезное дополнение к Турниге и Ардукоптеру.
Автору ОГРОМНАЯ БЛАГОДАРНОСТЬ!
По поводу отображения на андропланшете телеметрии и положения, ИМХО очень полезно, 3DR радио в основном использую для отслеживания положения на местности и телеметрии при полете в автомиссии,
можно было бы отказаться от радиомодемов.
можно было бы отказаться от радиомодемов.
Не торопитесь. Да и зачем нам уже устаревший блютус - сейчас время wifi!
Как насчет такой идеи:
APM -> 3DR radio Air module -> 3DR radio Ground module -> Компьютер с MissionPlanner -> (WiFi link) -> 9X
Потребуется такая доработка 9X: arduino + esp8266 (купить ESP8266 здесь, а описание тут)
Штатных апп с wifi на борту вроде еще не делают? Тогда будем первыми. Ну если и делают, то денег они точно стоят “немеряно”.
Передавать можно не телеметрию, а вообще просто “снимок экрана” аппы и алармы. Что-то вроде вещания ч/б видео с компьютера на аппу. Смартфон или планшет тоже можно коннектить по wifi.
Пока заказал себе парочку 8266. Жду когда приедут.
Потребуется такая доработка 9X: arduino + esp8266 (купить ESP8266 здесь, а описание тут)
Ух ты,век живи век читай.:)Спасибо за инфу у меня уже стоит синезуб на фриске.
Обновил описание проекта, переработал инструкцию
code.google.com/p/er9x-frsky-mavlink/…/Russian
Потребуется такая доработка 9X: arduino + esp8266
Не думаю что это хорошая идея (2.4MHz + 2.4MHz), мешаться друг другу будут. При включенно пульте у жены на ноуте отваливается WiFi, а мне вот все равно, я проводом привязан 😃
Замечательный проект! Слежу. Весьма интересно, но мне больше по подсветке, так как направление квадрика вижу через 3DR на планшете прикрепленном к пульту. Позволю несколько мыслей.
-
Сделать подсветку на борту в зависимости от напряжения питания, например
От 10,8 вольт = 3,6 В на ячейку мигает два раза
три раза от 10,2 вольт = 3,4 В на ячейку
четыре раза от 9,9 вольт = 3,3 В на ячейку
и от 9,6 V = 3,2 В на ячейку мигает очень часто - пора садиться. Такой алгоритм подсмотрел у одного немца. И даже модуль у него заказал. Было бы удобно запрограммировать. -
На Таранисе будет ли работать? Думаю, что в ближайшее время будет происходить массовый переход на него с Турниг (и в барахолке тюнингованных здорово прибавилось 😃 ).
В турнигу устанавливаем ардуино про мини, которая выступает как коммутатор, на нее принимаем данные телеметрии с модуля FrSky, затем отдаем в пульт (чтобы получилось как сейчас) и такой же поток данных отдаем на блютус модуль который коннектится со смартфоном на андроиде.
- Можно ли будет подключить 3DR модем в этот модуль и отдавать данные на DroidPlanner по BT? Через OTG разъем не всегда удобно с ним общаться. Или USB удлинитель городить или ставить в неудобное место.
Да и зачем нам уже устаревший блютус - сейчас время wifi! Как насчет такой идеи: APM -> 3DR radio Air module -> 3DR radio Ground module -> Компьютер с MissionPlanner -> (WiFi link) -> 9X
Все же BT предпочтительней. WIFI сильно будет шумить в 2.4 и та же Валкера вообще сделала на новом Скауте BT модуль управления с планшета.
Может что-то уже обсуждалось и я пропустил?
Может уже обсуждалось и я что-то пропустил?
Нет, нет. Это как раз в процессе обсуждения и важно каждое аргументированное мнение, чтобы совместными усилиями сделать что-то полезное многим.
Для размышления: и WiFi и Bluetooth работают в одном частотном диапазоне 2,4 Ггц
Вы правы, но используя один и тот же частотный диапазон, в ВТ предусмотрено применение технологии расширения спектра сигнала путем скачкообразной перестройки рабочей частоты (Frequency-Hopping Spread Spectrum — FHSS) или более новая AFH (Adaptive Frequency Hopping). Поэтому соответствующие устройства работают не на отдельных частотных каналах, а во всем ISM-диапазоне 2,4 ГГц. Вместо того чтобы все время передавать и принимать сигнал на какой-либо определенной частоте, устройство Bluetooth “скачет” по разным частотам примерно 1600 раз в секунду (FHSS), что делает оборудование помехоустойчивым. Таким образом, соответствующие этой спецификации устройства могут мирно “сосуществовать” с другим радиооборудованием диапазона 2,4 ГГц.
Ну а плюс WIFi, конечно, в большей дальнобойности, которая в данном случае не нужна.
WiFi работает по схожему принципу: OFDM (мультиплексирование с ортогональным делением частот) 802.11ag и DSSS (прямая последовательность с разнесением сигнала по широкому диапазону) на 802.11bg
Так что тут вопрос скорее не в том, какой стандарт более помехоустойчив, а в том что реально будет надежно работать рядом с мощным FrSky передатчиком. Bluetooth вроде как проверили уже - работает. Вполне может оказаться, что и WiFi так же стабильно будет работать. Этого особо никто раньше не делал исключительно из-за отсутствия на рынке недорогих WiFi решений. А у WiFi все таки потенциал больше, хотя бы потому, что он есть во всех современных устройствах (телефоны, планшеты, ноутбуки), а блютус встречается все реже реже.
Тут уж Вам решать как руководителю проекта 😃
C какой стороны яйцо разбивать — не сильно важно. По сути проекта может завести в несущественные обсуждения. Как-то сложилось, что BT используется для коннектов в шаговой доступности и с большей персонализацией, а WIFI все же подальше и пообщественней. У них разные зоны комфорта. И в булочную мы же на танке не ездим 😎.
Блютус проще спарить. Для WiFi шаги уже значительно сложнее. Кто-то должен быть точкой доступа, кто-то DHCP сервером (не руками же адреса назначать), ну и т.д.
Тут уж Вам решать как руководителю проекта 😃
Да, ну, здесь все равны. Вернее так: побеждает здесь аргументация.
Если про меня, то себе я уже заказал пару eps8266, так что куда-нить их все равно пристрою. Пока вижу два варианта: wifi термометр с реле на обогреватель в теплицу, а второй в турнигу.
Блютус проще спарить. Для WiFi шаги уже значительно сложнее. Кто-то должен быть точкой доступа, кто-то DHCP сервером (не руками же адреса назначать), ну и т.д.
Вижу это даже гораздо сложнее: нужен вариант WiFi Direct для поля и коннект через роутер, когда дома.
Кто-нибудь сможет потестить такой вариант?
Конвертировать mavlink->FrSky не в воздухе, а на земле.
APM -> 3DR radio AIR -> 3DR radio ground -> Arduino -> 9X
D6 можно не подключать. Но на будущее может пригодится.
Нашу ардуину ставим не на квадрике, а в аппу. Принимаем mavlink по радиоканалу и конвертируем в FrSky протокол уже на земле. Аппе отдаем FrSky поток. Аппа будет думать, что данные ей шлет телеметрийный модуль FrSky и будет все отображать на экране.
Прошивка аппы - наша, прошивка ардуины тоже. Никаких модификаций в прошивках не требуется вроде. Единственный подводный камень: правильно подключить 3DR radio ground module - нужно взять TX и RX до USB. Возможно придется физически отключить FTDI на 3DR (наверное можно убрать пару резисторов)
Питание и землю я не нарисовал, они подразумеваются. Вопрос только в энергопотреблении: выдержит ли стабилизатор питания на аппе такую нагрузку? Можно запитать 3DR пока отдельно. Ардуину лучше запитать прямо от акка, чтобы она не мешала при перепрошивки аппы.
Преимущества такого решения: не требуются модули с телеметрией FrSky.
Недостатки: нужен hardware mod 3DR и аппы.
Обсудим?