Полетные режимы вашего квадрика и направление на экране аппы
в полете надписи мелковаты,чтоб на миг глянуть,что да как.Приходиться сосредотачиваться.
Да, я так же думаю. Только как найти компромисс между набором отображаемых параметров и размерами шрифтов?
И походу индикация бортовухи не совсем правильно работает,в начале показал,что акк разряжен,а под конец наоборот полный.Но это со слов напарника.
Оставшийся заряд аккумулятора, ток и напряжение ардуине выдает 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 и аппы.
Обсудим?
А если на земле использовать такой же модуль что и в воздухе, то и отпаивать ничего не надо.
APM -> 3DR radio AIR -> 3DR radio ground -> Arduino -> 9X
Интересная идея,правда все равно прийдется еще модем покупать,а если все время дергать с компа на пульт,то идея плохая.