Полетные режимы вашего квадрика и направление на экране аппы

4refr0nt
Freepooh:

я бы напряжение пульта вообще убрал

это напряжение в этом месте на всех страницах телеметрии. Из стандартной er9x. Переключаясь между экранами телеметрии вы всегда видите напряжение аппы в этом месте. Вот я и не взял на себя смелость это изменить. Тем кто привык, что напряжение аппы в этом месте, по другому покажется нелогичным. Так что попробуйте привыкнуть.

Freepooh:

Еще хотелось бы стрелочку на радаре более “сглаженную”, если не трудно 😃

Если у вас версия для 64 меги, то сгладить можно, но нам не хватает памяти меги для подключения библиотеки расчета синусов и косинусов. А вырезать что-то другое ради красивости стрелок будет не очень разумно. Сейчас в этой версии углы считаются с точностью до 15 градусов. Синусы рассчитаны вручную и берутся из табличных значений. Поэтому, да, выглядит не очень.

Если у вас версия для 128 меги, то менее ломанную линию сделать невозможно - мы ограничены разрешением экрана. Правда есть вариант с использованием более красивых, заранее прорисованных не линий, а стрелок, но боюсь, мы опять будем расточительно расходовать все виды памяти меги (оперативки там тоже впритык). Хотя, быть может, готовые стрелки займут меньший размер, чем math библиотека. Кстати такой способ используется в OSD. Если кто-нибудь нарисует 16 или, хотя бы, 12 стрелок для радара (его размер 47х47) и они получатся симпатичней простых линий, то я постараюсь их запихать в существующий код.

4refr0nt
Freepooh:

Спасибо! Все работает четко, включая питание и иллюминацию (добавил все используемые режимы)

Поделитесь, пожалуйста, опытом по иллюминации. Какие режимы как у вас мигают.

Freepooh

Конечно!

//****************************************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 по типовой схеме навесным монтажем, без ПП

NARAJANA
4refr0nt:

Еще у меня есть идея вот такого развития проекта:

В турнигу устанавливаем ардуино про мини, которая выступает как коммутатор, на нее принимаем данные телеметрии с модуля FrSky, затем отдаем в пульт (чтобы получилось как сейчас) и такой же поток данных отдаем на блютус модуль который коннектится со смартфоном на андроиде. На смартфоне прога типа AndroPilot, только наша и заточенная на нашу телеметрию и с возможностью отображения на картах гугл положения нашего квадрика.
Надо подумать, как еще можно использовать ардуину в пульте (звуковой мод?)
Прошу отписаться о том, кто что думает обо всем этом.

Как то так получилось, что я пропустил этот проект.
Буду сдувать 64 проц, ставить 128, покупать Ардуину и наверстывать упущенное. Черезвычайно полезное дополнение к Турниге и Ардукоптеру.
Автору ОГРОМНАЯ БЛАГОДАРНОСТЬ!
По поводу отображения на андропланшете телеметрии и положения, ИМХО очень полезно, 3DR радио в основном использую для отслеживания положения на местности и телеметрии при полете в автомиссии,
можно было бы отказаться от радиомодемов.

4refr0nt
NARAJANA:

можно было бы отказаться от радиомодемов.

Не торопитесь. Да и зачем нам уже устаревший блютус - сейчас время wifi!
Как насчет такой идеи:

APM -> 3DR radio Air module -> 3DR radio Ground module -> Компьютер с MissionPlanner -> (WiFi link) -> 9X

Потребуется такая доработка 9X: arduino + esp8266 (купить ESP8266 здесь, а описание тут)

Штатных апп с wifi на борту вроде еще не делают? Тогда будем первыми. Ну если и делают, то денег они точно стоят “немеряно”.

Передавать можно не телеметрию, а вообще просто “снимок экрана” аппы и алармы. Что-то вроде вещания ч/б видео с компьютера на аппу. Смартфон или планшет тоже можно коннектить по wifi.

Пока заказал себе парочку 8266. Жду когда приедут.

HATUUL
4refr0nt:

Потребуется такая доработка 9X: arduino + esp8266 (купить ESP8266 здесь, а описание тут)

Ух ты,век живи век читай.:)Спасибо за инфу у меня уже стоит синезуб на фриске.

strizhmax
4refr0nt:

Потребуется такая доработка 9X: arduino + esp8266

Не думаю что это хорошая идея (2.4MHz + 2.4MHz), мешаться друг другу будут. При включенно пульте у жены на ноуте отваливается WiFi, а мне вот все равно, я проводом привязан 😃

NetWood

Замечательный проект! Слежу. Весьма интересно, но мне больше по подсветке, так как направление квадрика вижу через 3DR на планшете прикрепленном к пульту. Позволю несколько мыслей.

  1. Сделать подсветку на борту в зависимости от напряжения питания, например
    От 10,8 вольт = 3,6 В на ячейку мигает два раза
    три раза от 10,2 вольт = 3,4 В на ячейку
    четыре раза от 9,9 вольт = 3,3 В на ячейку
    и от 9,6 V = 3,2 В на ячейку мигает очень часто - пора садиться. Такой алгоритм подсмотрел у одного немца. И даже модуль у него заказал. Было бы удобно запрограммировать.

  2. На Таранисе будет ли работать? Думаю, что в ближайшее время будет происходить массовый переход на него с Турниг (и в барахолке тюнингованных здорово прибавилось 😃 ).

4refr0nt:

В турнигу устанавливаем ардуино про мини, которая выступает как коммутатор, на нее принимаем данные телеметрии с модуля FrSky, затем отдаем в пульт (чтобы получилось как сейчас) и такой же поток данных отдаем на блютус модуль который коннектится со смартфоном на андроиде.

  1. Можно ли будет подключить 3DR модем в этот модуль и отдавать данные на DroidPlanner по BT? Через OTG разъем не всегда удобно с ним общаться. Или USB удлинитель городить или ставить в неудобное место.
4refr0nt:

Да и зачем нам уже устаревший блютус - сейчас время wifi! Как насчет такой идеи: APM -> 3DR radio Air module -> 3DR radio Ground module -> Компьютер с MissionPlanner -> (WiFi link) -> 9X

Все же BT предпочтительней. WIFI сильно будет шумить в 2.4 и та же Валкера вообще сделала на новом Скауте BT модуль управления с планшета.

Может что-то уже обсуждалось и я пропустил?

4refr0nt
NetWood:

Может уже обсуждалось и я что-то пропустил?

Нет, нет. Это как раз в процессе обсуждения и важно каждое аргументированное мнение, чтобы совместными усилиями сделать что-то полезное многим.

4refr0nt

Для размышления: и WiFi и Bluetooth работают в одном частотном диапазоне 2,4 Ггц, мощность (у устройств для наших целей) тоже одинаковая - до 100 мВт (20 дБм).

NetWood
4refr0nt:

Для размышления: и WiFi и Bluetooth работают в одном частотном диапазоне 2,4 Ггц

Вы правы, но используя один и тот же частотный диапазон, в ВТ предусмотрено применение технологии расширения спектра сигнала путем скачкообразной перестройки рабочей частоты (Frequency-Hopping Spread Spectrum — FHSS) или более новая AFH (Adaptive Frequency Hopping). Поэтому соответствующие устройства работают не на отдельных частотных каналах, а во всем ISM-диапазоне 2,4 ГГц. Вместо того чтобы все время передавать и принимать сигнал на какой-либо определенной частоте, устройство Bluetooth “скачет” по разным частотам примерно 1600 раз в секунду (FHSS), что делает оборудование помехоустойчивым. Таким образом, соответствующие этой спецификации устройства могут мирно “сосуществовать” с другим радиооборудованием диапазона 2,4 ГГц.

Ну а плюс WIFi, конечно, в большей дальнобойности, которая в данном случае не нужна.

4refr0nt

WiFi работает по схожему принципу: OFDM (мультиплексирование с ортогональным делением частот) 802.11ag и DSSS (прямая последовательность с разнесением сигнала по широкому диапазону) на 802.11bg

Так что тут вопрос скорее не в том, какой стандарт более помехоустойчив, а в том что реально будет надежно работать рядом с мощным FrSky передатчиком. Bluetooth вроде как проверили уже - работает. Вполне может оказаться, что и WiFi так же стабильно будет работать. Этого особо никто раньше не делал исключительно из-за отсутствия на рынке недорогих WiFi решений. А у WiFi все таки потенциал больше, хотя бы потому, что он есть во всех современных устройствах (телефоны, планшеты, ноутбуки), а блютус встречается все реже реже.

NetWood

Тут уж Вам решать как руководителю проекта 😃
C какой стороны яйцо разбивать — не сильно важно. По сути проекта может завести в несущественные обсуждения. Как-то сложилось, что BT используется для коннектов в шаговой доступности и с большей персонализацией, а WIFI все же подальше и пообщественней. У них разные зоны комфорта. И в булочную мы же на танке не ездим 😎.

strizhmax

Блютус проще спарить. Для WiFi шаги уже значительно сложнее. Кто-то должен быть точкой доступа, кто-то DHCP сервером (не руками же адреса назначать), ну и т.д.

4refr0nt
NetWood:

Тут уж Вам решать как руководителю проекта 😃

Да, ну, здесь все равны. Вернее так: побеждает здесь аргументация.
Если про меня, то себе я уже заказал пару eps8266, так что куда-нить их все равно пристрою. Пока вижу два варианта: wifi термометр с реле на обогреватель в теплицу, а второй в турнигу.

strizhmax:

Блютус проще спарить. Для WiFi шаги уже значительно сложнее. Кто-то должен быть точкой доступа, кто-то DHCP сервером (не руками же адреса назначать), ну и т.д.

Вижу это даже гораздо сложнее: нужен вариант WiFi Direct для поля и коннект через роутер, когда дома.

4refr0nt

Кто-нибудь сможет потестить такой вариант?
Конвертировать 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 и аппы.

Обсудим?

innd

А если на земле использовать такой же модуль что и в воздухе, то и отпаивать ничего не надо.

HATUUL
4refr0nt:

APM -> 3DR radio AIR -> 3DR radio ground -> Arduino -> 9X

Интересная идея,правда все равно прийдется еще модем покупать,а если все время дергать с компа на пульт,то идея плохая.

Freepooh
4refr0nt:

Обсудим?

По-мне так нет необходимости.
К тому же с дополнительными потребителями придется на пульте и питание переделать на импульсное.

evgbog

Если есть 3DR телеметрия, тогда уж проще на ноутбуке смотреть. А то схема больно сложная получается.