Вопросы по iNav
сделайте арм на стике и не нужно будет голову ломать кто дизармит, аппаратура или полётник ))
Это , кстати, второй замеченный мной случай самопроизвольного изменения настроек.
не подключались к какойнить софтине типа езгуи на смартфоне?
Логи не нужно смотреть блокнотом, нужно смотрелкой логов 😉
сделайте арм на стике и не нужно будет голову ломать кто дизармит, аппаратура или полётник ))
Так это тоже какая-то комбинация сигналов. Почему она не может случиться?
К тому же калибровку можно непроизвольносбить, шевеля в дизарме стиками.
не подключались к какойнить софтине типа езгуи на смартфоне?
Нет, ничего не делал.
Логи не нужно смотреть блокнотом, нужно смотрелкой логов 😉
Просветите, какими программами и где их взять.
За два года ни разу никакие калибровки стиками не сбил. Арм одним стиком происходит. Посмотрите документацию или просто загуглите (если здесь не получается по теме) комбинацию стиков 😉
Смотрелка логов там же где и конфигуратор и сами прошивки - на гетхабе в разделе айнав.
ссылки тоже есть в теме.
То есть он при подключении батареи сразу армиться будет? Тогда если подсоединить батарею при выключенном передатчике, он сразу бешено вращать моторами станет?
Или стик газа случайно двинешь. Пальцы пообрубает.
Нет.
Арм сработает штатно, со всеми проверками, а отключение арма - только сдергиванием батареи.
Арм одним стиком происходит
Да только арм стиком тоже выпилили (или собираются выпилить).
В целом проблема именно в незащищенности SBUS-протокола. Как я понял, они даже толком не знают его спецификации и делают реверс-инжиниринг.
А тайминг чтения пакетов подбирают на коленке.
Проблема в том, что байт, который считается заголовком пакета, может присутствовать в данных самого пакета.
А это уже плохо. Если тайминг чтения байтов собьется, то байт внутри пакета может быть воспринят как заголовок пакета, и тогда начнется чтение пакетов с этого байта, что приведет к полному хаосу.
Поэтому ни стиками, ни чем-то другим полностью исключить глюки невозможно. Любой испорченный пакет может создать такую ситуацию в каналах, что прошивка подумает, будто ее дизармят.
Вопрос, почему портятся пакеты. Передача идет не протоколом S-BUS, т.е. приемник должен сначала принять радиосигнал, а потом преобразовать его в S-BUS и отдать контроллеру. Если преобразование выполняется на приемнике, то очевидно, что от качества сигнала это не зависит. Но возможно, зависит от качества электроники приемника и действующих на него внешних помех от других устройств.
Таким образом, встает вопрос о необходимости экранирования приемника и сигнальных проводов.
Как я понял, они даже толком не знают его спецификации и делают реверс-инжиниринг.
Неправильно поняли. Рассуждение об SBUS имеет смысл применительно к аппаратуре Futaba.
Полетные контроллеры и приемники общаются на протоколе ну очень похожем на SBUS. Зато ни для Betaflight, ни для FrSky не является секретом как он работает.
Видимо это хотели сказать в статье, ссылку на которую вы давали.
Дело в другом, вы дали кучу ссылок на ошибки в приемниках FrSky, а у товарища вообще FlySky, а там совсем другая история с каналами и файлсейфами.
Я поэтому и пишу: выкладывайте логи аварий, а то тут уже в такие дебри залезли, а там тупо две цифры в пульте поменять.
Неправильно поняли. Рассуждение об SBUS имеет смысл применительно к аппаратуре Futaba. Полетные контроллеры и приемники общаются на протоколе ну очень похожем на SBUS. Зато ни для Betaflight, ни для FrSky не является секретом как он работает.
Нет, речь о разработчиках CleanFlight, т.к. код заимствован оттуда.
Вот в этой ветке, например, разработчики именно что занимаются реверс-инжинирингом S-BUS.
github.com/cleanflight/cleanflight/issues/590
В исходном коде main/rx/sbus.c тоже есть строчки типа
case 0x24: // Unknown SBUS2 data
case 0x34: // Unknown SBUS2 data
Что свидетельствует о недоступности полной спецификации протокола для разработчиков.
И например из-за некоторых багов была зарезана поддержка приемников RadioLink и еще какого-то, потому что они “не соответствуют спецификации”, эталоном которой взята Futaba.
у товарища вообще FlySky, а там совсем другая история с каналами и файлсейфами.
Согласен. Одни приемники шлют No Pulses, другие устанавливают каналы в какие-то значения и т.п.
В каждом конкретном случае проблема может быть найдена в конфигурации приемника или полетника (kill_switch и т.д.) и на этом можно считать ее решенной.
Однако, меня тревожит более общая, глобальная картина.
Люди неоднократно сообщают, что у них дизармятся в воздухе коптеры, когда
- они не трогали никаких выключателей
- условий для фейлсейфа не было
Какой бы ни стоял приемник и какие бы ни были настройки фейлсейфа, в данных условиях этим настройкам просто не на что срабатывать, т.к. полет происходит штатно. Откуда же берется дизарм в канале?
Предположения: - Криво реализованный S-BUS протокол в прошивке. Какие-то необычные пакеты или джиттер сбивают его с толку и привет.
- Непосредственное внесение помех на приемник или кабель между приемником и контроллером. Исходя из того, что контрольных сумм в протоколе нет, полностью исключить искажение пакетов нельзя.
- Все это фигня, существуют такие конкретные настройки для приемника, которые полностью исключают дизарм в воздухе. То есть каждый случай дизарма - это просто спорадический фейлсейф + неправильно сконфигурированный приемник.
Вот и хотелось бы понять, как с этим дальше жить и что можно сделать, чтобы подстраховаться от этих проблем, даже если они чисто теоретические.
Люди неоднократно сообщают, что у них дизармятся в воздухе коптеры
С первым выложенным логом все гремлины разбегаются.
Криво реализованный S-BUS протокол в прошивке
Что там реализовывать, обычный UART.
Непосредственное внесение помех на приемник или кабель между приемником и контроллером.
Ионизирующее излучение еще бывает, если чисто теоретически, но тут вы вряд ли подстрахуетесь.
сделайте арм на стике
вроде как убран в 2+ айнаве, типа небезопасно. Хотя имхо можно было бы оставить, включая через кли на свой страх и риск - экономится канал, что для нас, флайскайников, важно )
отключение арма - только сдергиванием батареи
у меня по дефолту настроено так: пока газ в 0 не уберешь, не задизармится. Поэтому уже моторы перебирал, и траву выковыривал из таких глубоких мест…
Находил настройку эту, подумал… и оставил как есть. Привык с дизармом сразу газ в ноль.
Надо собирать qczek, он не глючит так, а если связь теряет - выставляет значения, прописанные вами при настройке приемника.
Что там реализовывать, обычный UART.
UART это транспортный уровень. Пакет S-BUS это 25 байт с различной информацией, которые надо разбирать. Читать следующий пакет или нет, решает не UART, а прошивка на основе полученных данных.
а если связь теряет - выставляет значения, прописанные вами при настройке приемника.
ну это практически все приемники умеют.
проблема в том, что это не спасает.
Пока про глюки с непонятными значениями канала в qczek не слышал. А зная, что меньше 1500 значение не упадет, арм настраивается исходя из этого.
я ж выкладывал видео с самолетом словившем дизарм за 3 км от дома на qczek
я ж выкладывал видео с самолетом словившем дизарм за 3 км от дома на qczek
by switch?
Настройка канала по дефолту в приемнике или выше? С настройкой режима в айнав согласовано?
К своему большому удивлению обнаружил, что disarm_kill_switch был включен. Но я его выключал и никогда больше не трогал. А после проверки фэйлсэйва в поле даже к компу не подключал. Как эта настройка могла самопроизвольно измениться?
У меня была путаница с этим связанная, при переходе к новому конфигуратору. В версии 1.8 был выключатель.
Начиная с 1.9 переключатель убрали. Осталось возможным выключать disarm_kill_switch только через CLI. Я этого не сделал, думая, что выключил переключатель. Вскоре словил дизарм, упал и сразу же разобрался. 😃
Я летаю с Таранисом. При использовании встроенного модуля на 2.4ГГц, довольно часто замечал по логам проскакивание случайных кратковременных переключений полётных режимов и команд на дизарм. Практически это всегда происходило при полёте вблизи жилых многоэтажек, там уровень радиопомех очень большой. Обычно режим переключается меньше чем на секунду, коптер успевает только дёрнуться. Дизарм же видно только по логу, продолжительность команды та же, но он полётником игнорируется, т.к. я не делаю сейчас газ меньше 11%. Внешне такой дизарм никак не заметно. После перехода с Таранисом на внешний модуль R9M с частотой 915МГц, число подобных сработок сократилось на порядок. У меня сохранены все видео и логи полётов, но жаль тратить время на поиски. В качестве примера покажу как недавно произошло самопроизвольное переключение полётного режима из Англ в Акро. Неприятность произошла опять около многоэтажек. Длительность ложной команды была продолжительной - 1.5сек, коптер успел сделать флип.
Не советую делать арм-дизарм с помощью стика. Я пробовал. Однажды в полёте зарулился и сам задизармился. Аппарат упал. Преимуществ в такой коммутации нет. Со стиком необходимо выполнить 2 условия - газ и яв. С тумблером тоже - газ и тумблер.
Надо собирать qczek, он не глючит так, а если связь теряет - выставляет значения, прописанные вами при настройке приемника.
Это ведь только для PPM актуально, а PPM как протокол довольно медленный и не особо надёжный.
Да и сама QLRS относительно медленная на фоне других LRS на лоре (R9, CRSF)
Пользую sbus на входе и выходе, при отключении передатчика с приемника поступают настроенные мною значения.
Были 1000 по трем каналам позиционирования, поставил 1500 - середину, работает.
Проблем с управлением по скорости пока не видел. Радиус 30 метров, это да)
Запалил какой то модуль. Ждёт на почте 100мвт, и надеюсь из двух 1вт какой то да живой.
Буду добивать лору любыми силами, понравилась очень. Но скорее придется на 868 уехать.
с приемника поступают настроенные мною значения
Хм
И эти значения видны во вкладке Receiver в конфигураторе при светящемся красном парашюте, я правильно понимаю?
Да.
Я ещё до первых взлетов, когда разбирался с настройками, думал что теоретически может быть ситуация, когда fs ещё не обнаружен, а значения каналов не способствуют равномерному зависанию или приходит дизарм. Поэтому настроил значения так, что коптер зависает с газом висения в энжл.
Там же две задержки до обнаружения фс - у Лоры и у полетника.
Да.
Интересно получается.
Знаю, что некоторые полётники перестают считать данные от приемника валидными, как только он начинает слать флаги “frame lost” и “failsafe active”, и по большому счёту это логичное поведение.
Я думал, что айнав поступает так же, но получается что нет…
думал что теоретически может быть ситуация, когда fs ещё не обнаружен, а значения каналов не способствуют равномерному зависанию или приходит дизарм
Может, вполне. Если прошивкописатели накосячат с ПО приемника и не поднимут вовремя флаги.
Поэтому я предпочитаю переводить приемник в режим No Pulses в случае F/S.
Ну я точно уверен, что видел во вкладке “ресивер” дефолтные значения - 1000. А когда на лоре прописал свои - появились они.
При этом файлсейф срабатывал, и приемник игнорил эти значения. Но до срабатывания была задержка. Возможно, ее хватает для дизарма.
Ну я точно уверен, что видел во вкладке “ресивер” дефолтные значения - 1000. А когда на лоре прописал свои - появились они.
Всё верно. Глянул исходники – там прямым текстом написано, что айнав продолжает использовать значения с приемника несмотря на failsafe.
Но до срабатывания была задержка.
Это скорее всего была задержка айнава. Failsafe Stage 2 с красным парашютиком и возвратом домой активируется не сразу, полётник даёт шанс приемнику снова поймать связь, чтобы фэйлсэйфы не происходили из-за кратковременных отвалов связи.