Автопилот iNav полёты с GPS

Talentfrei

Я был одним из первых кто обкатывал iNav. Костя резал текст везде где можно но и безопасность должна была подниматься. И портов у F3 больше. Если вы думаете что вы умнее то пишите, у меня лежит F1 …

barsx
Talentfrei:

Я был одним из первых кто обкатывал iNav. Костя резал текст везде где можно но и безопасность должна была подниматься. И портов у F3 больше. Если вы думаете что вы умнее то пишите, у меня лежит F1 …

Я недавно заглядывал в код айнава и честно говоря ужасался. Расчёт идентичных параметров в цикле, деления на константы вместо умножений на обратные и т.д. Вам для чего портов мало на F1?

Talentfrei
barsx:

Вам для чего портов мало на F1?

Для SBUS, IBUS

SkyPlayer
barsx:

Вам для чего портов мало на F1?

Посчитайте на пальчиках:

  1. SBUS
  2. SPort
  3. GPS
  4. SmartAudio
  5. Bluetooth или радиомодем
SkyPlayer
SkyPlayer:

Посчитайте на пальчиках:

  1. SBUS
  2. SPort
  3. GPS
  4. SmartAudio
  5. Bluetooth или радиомодем

Совсем забыл! В F1-контроллерах же нет OSD, так что один из UART-ов уходит под MWOSD.
В принципе, SBUS можно заменить на PPM (для крыла не так принципиальна скорость и точность управления, хотя количество каналов сразу падает до 8, что неудобно, например, при настройке в полёте - автотрим, автотюн, подкрутка PIFF-ов), но всё равно получаем:

  1. OSD
  2. GPS
  3. телеметрия (SPort). В принципе, можно обойтись только дальнобойным модемом, но всё равно удобно, когда есть голосовая озвучка событий с аппы.
  4. заливка маршрутов и их контроль. Для первого - Bluetooth, для второго - уже только радиомодем. Конечно, можно лить по USB, но в поле с этим ковыряться попросту неудобно.
  5. управление видеопередатчиком (SmartAudio). Тоже, в принципе, можно обойтись, если не запаковывать видеопередатчик слишком глубоко и иметь доступ к его кнопке, но это опять “прогиб”.
    Upd: глянул по релизам - поддержка управления видеопередатчиком появилась только в 1.8, так что F1 тут вообще пролетают мимо.

Итого по минимуму (жертвуя удобством) - PPM плюс 3хUART (GPS, OSD, телеметрия или BT или радиомодем), в принципе, Naze32 может даже 4хUART (2 аппаратных и 2 софтовых), но один из аппаратных запараллелен с USB, что неудобно. На CC3D 2 аппаратных и 1 софтовый (но USB от порта “развязан”), то есть “совсем по минимуму”.
На Omnibus F3 - встроенное OSD (не нужен порт и 100% совместимость по экранным настройкам), и 3 аппаратных порта (USB отдельно).
На Omnibus F4 Pro v2 - встроенное OSD, 3 аппаратных порта и 1 софтовый, USB отдельно.

Talentfrei

Да можно вообще от всего отказаться!))) Поставить компас перед камерой и лети!!!)))

barsx

На STM32 программный UART реализовывается без проблем. Портов можно сделать сколько надо. Хоть инвертированные хоть обычные. И плюс стандартные. В чём проблема?

Talentfrei:

Да можно вообще от всего отказаться!))) Поставить компас перед камерой и лети!!!)))

Я в основном без телеметрии летаю. Верный показатель что пора чесать на базу - регуль вошёл в режим мягкой отсечки. С ориентацией в пространстве тоже проблем нету - опыт есть и на крайний случай RTL можно включить. Зачем порты? 😃

z0rgvin
barsx:

Я недавно заглядывал в код айнава и честно говоря ужасался. Расчёт идентичных параметров в цикле, деления на константы вместо умножений на обратные и т.д. Вам для чего портов мало на F1?

Прошу прощения, что влезаю, но:

  1. STM32F1хх имеют ядро Cortex-M3, в котором есть аппаратное деление. Да, деление занимает до 12 циклов против 1-2 для умножения, но приведение к обратным константам увеличивает вероятность ошибки и снижает читаемость кода. Если константы должны рассчитываться в программе, а не на этапе компиляции (а пользователю ведь удобнее видеть более понятные значения, поэтому так и будет), то на организацию расчета придется потратить некоторое количество флэш-памяти, которой как раз и не хватает.
  2. Все одинаковые действия желательно выполнять в циклах, чтобы не было дублирования кода. Затраты на организацию цикла малы.
    Дублирование кода приведет к тому, что при необходимости правки человек (не факт, что именно он писал этот кусов в первый раз) поправит не везде и результат будет отличаться от ожидаемого.
  3. Лучше перейти на больший контроллер, чем ужимать код. Трудозатраты на “ужатие” огромны, снижается читаемость и “редактируемость”, но все равно довольно быстро опять упрешься в ограничение.
  4. Это бесплатный проект. Пусть они делают так, как делают, если это приведет к большей надежности, более быстрой разработке, меньшим трудозатратам. Да, нам придется несколько больше потратиться на полетный контроллер, но на фоне остального разница довольно небольшая.
barsx
z0rgvin:

Пусть они делают так, как делают, если это приведет к большей надежности, более быстрой разработке, меньшим трудозатратам.

И к тому что некоторые контроллеры можно выкинуть…
К сожалению сейчас всё больше программистов следуют вашей логике. Именно поэтому мы имеем тормоза в интерфейсе на андроидах 7+ с 16 ядерными процессорами и дохрена оперативки (по сравнению с компами 20 летней давности). И причём на этих компах субъективно тормозов было меньше. Действительно, зачем использовать умножение если деление всего-то в 12 раз медленнее.

z0rgvin:

Трудозатраты на “ужатие” огромны, снижается читаемость и “редактируемость”.

Если есть привычка сразу оптимизировать свой код, то таких проблем не возникает. Другой вопрос что в опенсорсных проектах из кода всё равно потом сделают так, чтобы всё было красиво, но в 99% случаев это увеличит тормоза выполнения программы. Да, некоторые “обороты” оказываются неудобочитаемыми, но позволяют уменьшить издевательство над стеком.

Talentfrei

Я возможно повторяюсь и бываю навязчив, вам никто не мешает это доказать. Мой контроллер лежит и ждёт…

bumer520

Парни я понимаю ,что прогресс стремится в перёд и ни кто не будет поддерживать немного устаревающий проект,я с моделизмом сейчас время от времени,(работа,семья,стройка ещё много чего) вообще не удаётся быть в курсе всех новинок и всего что связано с моделизмом. Я практически тоже в первых рядах был по пользованию cc3d, отлётал на нём на коптере просто замечательно,потом перерыв ,захожу а тут уже новинки попёрли,заказал себе F4 V2 который был благополучно установлен на квадрик и СДОХ так практически и не взлетев .Поэтому решил поставить cc3d пока на крыло и пролетать с ним ,а квадрик подождёт. И вот тут засада не могу разобраться в настройках,не могу понять почему задействован рудер,он нахрен там не нужен, а как отключить не знаю.

Роман_С_А
bumer520:

,заказал себе F4 V2

Лежит такой же,ждёт своего часа.Много пишут что дохнет.Но чаще вроде от батарей 4S.В каком то видео от Юлиана,вроде было про то как частично порешать проблему с “вылетами” этих полётников.Якобы впаивается конденсатор,довольно большой в какое то место на плате,я так и не усмотрел куда,что бы при подключении силового разьёма от аккума, убрать так называемый “щелчок” импульс.Который частенько пробивает эти полётники.На ЦЦ3Д таких заморочек не возникает конечно.

Fisher15
bumer520:

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

Любопытно. У меня три крыла на айнаве, ни одно крыло на шевеление стика рудера на аппе не реагирует. Если рудер вас напрягает в пидах - поставьте там для него везде нули…

z0rgvin
barsx:

И к тому что некоторые контроллеры можно выкинуть…
К сожалению сейчас всё больше программистов следуют вашей логике. Именно поэтому мы имеем тормоза в интерфейсе на андроидах 7+ с 16 ядерными процессорами и дохрена оперативки (по сравнению с компами 20 летней давности). И причём на этих компах субъективно тормозов было меньше.

Там приоритетом почему-то является красивость интерфейса (гладкость границ, анимации при переходах по меню и прочее), из этого и проистекает то, что теперь недостаточно просто нарисовать новое меню, надо нарисовать еще 100 промежуточных состояний для анимации и сделать это очень быстро.

Я думаю иначе: если оптимизация займет много времени, то весьма разумно взять контроллер “побольше”. Тем более, что за этот контроллер платить другим. 😃

К сожалению, просто перепаять чип на этой же плате с F3 на F4 нельзя.

Мне доводилось ужимать код. Запаяли контроллеры на партию изделий без учета того, что в программу надо внести дополнения (порядка 1000 плат). А в контроллере и так было 99% флэш-памяти занято.
Неделя вместо 1 дня и в итоге оно в контроллер влезло. Но пришлось переписать значительную часть и оно ну почти влезло. Чтобы совсем влезло, понадобилось еще порыться в disassebmly listing’е, чтобы найти, где и что можно еще поурезать.
Стоило ли оно в данном случае? Да. Стоит ли этот подход применять везде? Нет, так как слишком затратно.

barsx:

Действительно, зачем использовать умножение если деление всего-то в 12 раз медленнее.

Видимо я недостаточно подробно объяснил.

  1. Хорошо, используем умножение на обратное значение.
    Во энергонезависимой памяти хранится прямая константа (так как именно в этом виде она разумна и именно в этом виде показывается пользователю), но используется ее обратное значение, которое должно быть либо рассчитано при запуске, либо тоже храниться и пересчитываться при изменении этой константы.
    Организация процесса расчета занимает флэш-память. Да, ерунда, но в сумме набежит. Плюс мы используем дефицитный ресурс, которым в данном случае является не производительность, а флэш-память.

  2. Ну и проблема не в скорости, а в недостатке флэш-памяти. 😉
    “F3 boards are not recommended since their flash space is almost full and they are likely to not receive all features on the next release.”

barsx:

Если есть привычка сразу оптимизировать свой код, то таких проблем не возникает. Другой вопрос что в опенсорсных проектах из кода всё равно потом сделают так, чтобы всё было красиво, но в 99% случаев это увеличит тормоза выполнения программы. Да, некоторые “обороты” оказываются неудобочитаемыми, но позволяют уменьшить издевательство над стеком.

Вот именно, что придется кому-то разобраться, переделать и т.д.
Очень грубо: можно потратить 1 час времени и написать код, который оптимален на 90%.
А можно потратить 10 часов времени и написать код, который оптимален на 95%.
При текущем подходе в любом случае придет ограничение памяти контроллера. Пусть оно придет несколько позднее, но на отодвигание этого срока будет потрачено много времени.
Подход ради сохранения поддержки F3 никто менять не будет.

Придется остаться на старых версиях. Они ведь рабочие.

PS у самого 3 полетника на F3 лежат. 😦

barsx
Talentfrei:

Я возможно повторяюсь и бываю навязчив, вам никто не мешает это доказать. Мой контроллер лежит и ждёт…

Разогнался уже так что бегу и падаю.

z0rgvin, в целом я с вами полностью согласен. Проблема в том, что в айнав патаются засунуть всё что только можно. Причём в одной прошивке весь комплекс и для коптеров и для самолётов. С точки зрения миксов и стабилизации разницы никакой. Отличия только в логике полёта и параметрах. Если из коптерной прошивки убрать самолётную логику и наоборот, то всё станет гораздо проще. Те же АПМ если взять, то там вообще древнющий процессор по сравнению с F3, однако свои функции выполняет отлично (правда после длительной прелюдии с настройками).

Talentfrei
barsx:

Разогнался уже так что бегу и падаю.

Поэтому и считаю это пустой болтовнёй

SVA_sar

Никто не замечал такой казус? Иногда крыло реагирует на стики с какими то задержками. После перезагрузки или с другой батарейкой все плавно и четко. Как-то на уровне ощущений. Описать даже не могу. У меня два аппарата и на обоих я такую картину замечаю. Как-будто INAV тормозить начинает. Я такое замечал и на 1.7.3 и на 1.9.1. Может я придираюсь, но от ощущения, что в каждом полете разное поведение, отделаться не могу.

z0rgvin
barsx:

z0rgvin, в целом я с вами полностью согласен. Проблема в том, что в айнав патаются засунуть всё что только можно. Причём в одной прошивке весь комплекс и для коптеров и для самолётов. С точки зрения миксов и стабилизации разницы никакой. Отличия только в логике полёта и параметрах. Если из коптерной прошивки убрать самолётную логику и наоборот, то всё станет гораздо проще. Те же АПМ если взять, то там вообще древнющий процессор по сравнению с F3, однако свои функции выполняет отлично (правда после длительной прелюдии с настройками).

Согласен.
Может быть и произойдет такое, что разделят. Будем надеяться.

SVA_sar:

Никто не замечал такой казус? Иногда крыло реагирует на стики с какими то задержками. После перезагрузки или с другой батарейкой все плавно и четко. Как-то на уровне ощущений. Описать даже не могу. У меня два аппарата и на обоих я такую картину замечаю. Как-будто INAV тормозить начинает. Я такое замечал и на 1.7.3 и на 1.9.1. Может я придираюсь, но от ощущения, что в каждом полете разное поведение, отделаться не могу.

Eсть такая штука, как TPA, которая уменьшает ПИДы при увеличении газа (раз уж тут тема про INAV). Вполне может быть, что по мере разряда аккумулятора вы увеличиваете газ и попадаете при той же скорости в область, где ПИДы уже значительно уменьшились. Сильно меньшие ПИДы при той же скорости - более вялая реакция аппарата.
А может быть ПИДы, кроме того, изначально еще маловаты.

У меня похожие ощущения были, когда тяги со стороны кабанчиков подклинивали.

Все имхо, я не спец.

RcDan

нав-лаунч просто замечательная фича. Пользуюсь теперь на постоянке. Вообще, возможности инав радуют сильно.

И в нынешнем состоянии сложно найти реальных конкурентов.

bumer520

Друзья по хобби,с рудером разобрался,всё работает как надо,возник другой вопрос,подключено cc3d + minimosd,osd прошит по видео по инстукции Юлиана, так вот в конфигураторе inav жпс показывает 8 спутников ,а вот osd ноль спутников и ещё поставил арминг на переключатель ,если сама плата видит спутники то должен происходить арминг ,а его нет и не работает горизонт ну и вообще всё что связано с навигацией, может нужно в конфигураторе что то включить или поставить нужные значения.

RcDan
bumer520:

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

set nav_extra_arming_safety = OFF