Вопросы по iNav
Бах - дизарм. Кирпичом об землю.
Какое значение имеет у Вас параметр disarm_kill_switch ?
То есть в этом канале, который отведен на дизарм, появляется соответствующее значение?
Да, именно так.
При этом причина дизарма будет написана на итоговом экране OSD - disarmed by switch.
Еще одна причина - настройки фейлсейфа, но вы их проверяли и коптер возвращался, значит дело не в них.
Проблема именно в “шуме” каналов, где могут кратковременно появляться странные значения.
Я правда не совсем понимаю логику обработки таких значений. При обрыве связи SBUS должен четко давать понять, что связи именно нет, а не слать какую-то фигню. Возможно, это происходит в какой-то пограничной ситуации, когда связь очень плохая, но обрыва еще нет, и данные в канале просто искажаются. Но у меня такое произошло на расстоянии 50 метров в прямой видимости, а до этого отлетал на километр нормально, так что нельзя сказать, что связь была плохой.
Кроме того, на днях я словил еще более странный глюк, когда при стоящем на земле не заармленном коптере я включил на пульте режим ALTHOLD, а коптер внезапно заармился сам по себе и рванул вверх на нулевом газе, хотя переключатель арма не включался. Это еще более опасная ситуация.
Поэтому на данный момент у меня есть 2 теории.
- Где-то в обработке SBUS есть баг.
- Все приемники с таким поведением были XM+. На X4RSB например никогда ничего не глючило. Возможно, проблема в этих приемниках.
Как бороться, я пока не знаю. Можно сделать немного больше таймаут на дизарм, а также максимально расширить область действия ползунка ARM, чтобы возможные случайные глюки не приводили к выходу из этой области. Но это все полумеры.
Он, наверное, знает. Но молчит. Точнее, пишет на непонятном пока мне языке. Пока не освоил перевод данных, которые он пишет, в программу, показывающую наглядные графики. И темы такой что-то здесь не нашел.
Так выложите лог, вам скажут что, когда и почему. А то без логов начинаются теории, догадки и домыслы.
Чтобы внезапно при арме не порезало, ставится двухэтапный арм.
Проблемы со связью решаются настройками в аппаратуре и полетнике режимов и Failsafe.
А то без логов начинаются теории, догадки и домыслы.
В логе будет написано, что дизарм сделан переключателем. И как это поможет?
А чтобы внезапно при арме не порезало, ставится двухэтапный арм.
Это в Бетафлайте.
В логе будет написано, что дизарм сделан переключателем.
Опять гадание. Пусть выложит, тогда посмотрим.
Это в Бетафлайте.
Это в аппаратуре. Логический переключатель от трех условий.
Это в аппаратуре. Логический переключатель от трех условий.
А то, что в аппаратуре, может помочь только от случайного арма оператором. Со стороны прошивки остается по-прежнему один канал, в котором или есть арм, или его нет. От глюка в канале это не спасет.
От глюка в канале это не спасет.
Глюки в канале кто-то кроме вас еще наблюдал?
Повесьте ненавистный вами XM+ на UART на несколько часов и ответьте себе сами может такое быть или нет.
Глюки в канале кто-то кроме вас еще наблюдал?
Да, и по этому поводу даже есть материалы в гугле.
Повесьте ненавистный вами XM+ на UART на несколько часов и ответьте себе сами может такое быть или нет.
С чего вы решили, что он мне ненавистный? Зачем общаться в таком тоне, я вам что-то плохое сделал?
Да, и по этому поводу даже есть материалы в гугле.
Будьте любезны ссылку.
С чего вы решили, что он мне ненавистный?
На основании того, что
Все приемники с таким поведением были XM+
я вам что-то плохое сделал?
Вопросы личного характера отправляйте в личку, тут тема про айнав.
Будьте любезны ссылку.
Вот здесь есть упоминание видео от Pawel Spychalski насчет corrupted packet
www.rcgroups.com/forums/showthread.php?3097948-iNa…
IIRC Pawel Spychalski talks about this in his Youtube chats about Inav 2.0 - that you get a corrupted packet sent from the tx to the rx in which the PWM value of the “arm” channel is below the disarm threshold and it disarms the plane. One of the things Inav 2.0 is supposed to do is require a couple hundred milliseconds of disarm signal before the FC reacts to the signal.
Видео ищите сами, у меня ютуб закрыт.
На основании того, что
Все приемники с таким поведением были XM+
И что? При чем тут ненависть?
Вопросы личного характера отправляйте в личку, тут тема про айнав.
Странно, что вы в теме про айнав пишете о моей ненависти к приемникам XM+, не правда ли?
А вот тут пишут, что глюки в SBUS просто-таки обязаны быть при его реализации
github.com/iNavFlight/inav/issues/2827
SBUS issues are:
- No CRC, thus there is no way for inav code to make sure that what it has received/decoded is actually valid channel data
- The packet start marker is a single byte that also can occur in the payload
- There is no sure way to surely detect packet end for inav code, some SBUS receivers send different fixed bytes, some send whatever other stuff (telemetry or something). SBUS is just reverse-engineered, there is no clear knowledge about what the end byte does
К своему большому удивлению обнаружил, что disarm_kill_switch был включен.
Но я его выключал и никогда больше не трогал.
А после проверки фэйлсэйва в поле даже к компу не подключал.
Как эта настройка могла самопроизвольно измениться?
Это , кстати, второй замеченный мной случай самопроизвольного изменения настроек.
Скорее всего крэш произошел по этой причине.
Другая подозрительная штука у меня берет начало от глюка прошивки пульта FLYSKYi6.
С родной прошивкой настройка фэйлсэйва проходила нормально.
Как только залил прошивку на 10 каналов, при настройке фэйлсэйва на канал газа, другие некоторые каналы тоже изменяют свои значения.
В частности 9 канал, на котором у меня настроен арминг в диапазоне 1500-2000, при фэйлсэйве дает значение 1350.
Но контроллер засекает ненормальные значения в канале газа и сразу же включает режим фэлсэйва, не обращая внимания на показания других каналов, в том числе и 9-го. Дизарма не случается. По крайней мере дома и в испытательных полетах возле себя, когда я выключаю передатчик.
Но здесь, конечно, таится потенциальная угроза.
Как будет это все работать, когда связь управления будет исчезать не одномоментно, а постепенно?
А на счет логов. Я не умею их преобразовывать в читабельный вид. Там много кракозябр, а в конце: EяEnd of log (disarm reason:4)
Это, как я понимаю, DISARM_SWITCH
можно отключить дизарм совсем.
можно отключить дизарм совсем.
То есть он при подключении батареи сразу армиться будет? Тогда если подсоединить батарею при выключенном передатчике, он сразу бешено вращать моторами станет?
Или стик газа случайно двинешь. Пальцы пообрубает.
сделайте арм на стике и не нужно будет голову ломать кто дизармит, аппаратура или полётник ))
Это , кстати, второй замеченный мной случай самопроизвольного изменения настроек.
не подключались к какойнить софтине типа езгуи на смартфоне?
Логи не нужно смотреть блокнотом, нужно смотрелкой логов 😉
сделайте арм на стике и не нужно будет голову ломать кто дизармит, аппаратура или полётник ))
Так это тоже какая-то комбинация сигналов. Почему она не может случиться?
К тому же калибровку можно непроизвольносбить, шевеля в дизарме стиками.
не подключались к какойнить софтине типа езгуи на смартфоне?
Нет, ничего не делал.
Логи не нужно смотреть блокнотом, нужно смотрелкой логов 😉
Просветите, какими программами и где их взять.
За два года ни разу никакие калибровки стиками не сбил. Арм одним стиком происходит. Посмотрите документацию или просто загуглите (если здесь не получается по теме) комбинацию стиков 😉
Смотрелка логов там же где и конфигуратор и сами прошивки - на гетхабе в разделе айнав.
ссылки тоже есть в теме.
То есть он при подключении батареи сразу армиться будет? Тогда если подсоединить батарею при выключенном передатчике, он сразу бешено вращать моторами станет?
Или стик газа случайно двинешь. Пальцы пообрубает.
Нет.
Арм сработает штатно, со всеми проверками, а отключение арма - только сдергиванием батареи.
Арм одним стиком происходит
Да только арм стиком тоже выпилили (или собираются выпилить).
В целом проблема именно в незащищенности 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.
Непосредственное внесение помех на приемник или кабель между приемником и контроллером.
Ионизирующее излучение еще бывает, если чисто теоретически, но тут вы вряд ли подстрахуетесь.