Вопросы по iNav
Константин, скажите, а когда добавиться/вернётся поддержка led_strip?
Константин, скажите, а когда добавиться/вернётся поддержка led_strip?
Вероятно, в версии 1.2, возможно в промежуточной 1.1.2.
До конца месяца будет релиз-кандидат 1.1.2-RC, в него войдут изменения:
- PID-контроллеры Multiwii Rewrite и Luxfloat будут заменены новым контроллером FP-PID
- GPS больше не будет принимать от модуля и отдавать Конфигуратору информацию о спутниках
- Изменения в планировщике задач для оптимизации производительности
- Буферизация последовательных портов (более быстрый USB на CC3D и Sparky)
- Много мелких исправлений
Новый PID-контроллер и упрощение GPS-кода должно освободить достаточно места для LEDSTRIP в сборке для Naze32
GPS больше не будет принимать от модуля и отдавать Конфигуратору информацию о спутниках
Т.е. не будет возможности контролировать качество приема GPS?
Т.е. не будет возможности контролировать качество приема GPS?
Совершенно верно. Сбор этой информации от GPS-а сильно влияет на задержку данных о позиции (и занимает достаточно много места в прошивке). После фикса в любом случае будет доступно количество спутников, по которым фикс сделан.
будет доступно количество спутников
Это не очень полезная информация. Нужно знать HDOP для определения степени доверия данным GPS. Иначе можно улететь “в китай”. И при 5-6 спутниках бывает высокий HDOP.
Это не очень полезная информация. Нужно знать HDOP для определения степени доверия данным GPS. Иначе можно улететь “в китай”. И при 5-6 спутниках бывает высокий HDOP.
HDOP будет, правда в форме EPV - абсолютная погреность позиции.
HDOP будет, правда в форме EPV - абсолютная погреность позиции.
Форм пойдет и такая. Этого будет достаточно. Остальные подробности про спутники действительно не нужны.
Форм пойдет и такая. Этого будет достаточно. Остальные подробности про спутники действительно не нужны.
Поскольку спутников у нас теперь не будет, HDOP будет сообщаться как сигнал первого спутника (пока конфигуратор не научится показывать его как надо):
Совершенно верно. Сбор этой информации от GPS-а сильно влияет на задержку данных о позиции
на сколько это увеличивает задержку? по логам смотрели?
на сколько это увеличивает задержку? по логам смотрели?
Сообщение NAV-SVINFO занимает 200-300 байт, на скорости порта 57600 это пол-секунды сверх задержки, которую сам GPS вносит. Еще проблема в том, что эта задержка непостоянная, а джиттер еще хуже чем просто задержка.
Константин, скажите, а когда добавиться/вернётся поддержка led_strip?
Ура, LED_STRIP вернулся на Naze32!
Но ничего не достается даром (об этом ниже).
Выложил самую новую “тестовую” сборку. Шить с полным стиранием, конфигурировать заново, тюнинг тоже заново. Особое внимание следует обратить на вкладку “Modes”.
Изменения:
- FP-PID GitHub #96
- GPS теперь без информации о спутниках. HDOP сообщается в качестве уровня сигнала первого спутника
- Таймаут GPS при активации RTH. Теперь если GPS потерялся при активации возврата аварийная посадка срабатывает не сразу, а только через nav_position_timeout секунд после потери GPS-а. GitHub #113
- Буферизация Serial-портов. (более быстрый USB VCP на CC3D)
- Оптимизирован планировщик (в теории меньше джиттер)
- Улучшен алгоритм защиты от арминга без GPS на самолетах без магнитометра
- LED_STRIP вернулся на Naze32
- Теперь поддерживается только Naze32 Rev4 и новее
- Naze32 теперь умеет работать только с Ublox GPS (никаких NMEA, NAZA или I2C)
Внимание - многие изменения не тестировались или тестировались слабо.
вариант с газом после восстановления связи после fail-save не имплементили?
чтобы если ручка газа ниже, чем была запомнена на момент FS - оставлять значение FS до того, как ручное значение не станет выше либо равно
вариант с газом после восстановления связи после fail-save не имплементили?
чтобы если ручка газа ниже, чем была запомнена на момент FS - оставлять значение FS до того, как ручное значение не станет выше либо равно
А для чего такая логика может быть нужна?
А для чего такая логика может быть нужна?
причина №2 в топ-5 причин крашей дронов - что при возврате коптера\самолета после утери связи ручка газа остается внизу после дёрганий и пониманий, что связь пропала.
а когда связь восстанавливается - моторы глушаться и дрон весело падает на землю.
Сообщение NAV-SVINFO занимает 200-300 байт, на скорости порта 57600 это пол-секунды сверх задержки, которую сам GPS вносит. Еще проблема в том, что эта задержка непостоянная, а джиттер еще хуже чем просто задержка.
вы наверное про бинарный ublox протокол, т.к. в случае с NMEA все просто. GGA фрейм содержит все что надо, т.е. и координаты и кол-во спутников, тип фикса и HDOP…
а плавающая задержка, да, это самое зло 😃 т.к. не понятно куда считать…
Пытался флашен Flip32, не идёт …
вы наверное про бинарный ublox протокол, т.к. в случае с NMEA все просто. GGA фрейм содержит все что надо, т.е. и координаты и кол-во спутников, тип фикса и HDOP…
а плавающая задержка, да, это самое зло 😃 т.к. не понятно куда считать…
Я про детальную информацию о спутниках - фрейм GSV, коих может быть больше даже одного подряд
Пытался флашен Flip32, не идёт …
Рекомендацию выполнили?
Шить с полным стиранием
Моя Naze32 Rev5 прошилась на “раз-два”
причина №2 в топ-5 причин крашей дронов - что при возврате коптера\самолета после утери связи ручка газа остается внизу после дёрганий и пониманий, что связь пропала.
а когда связь восстанавливается - моторы глушаться и дрон весело падает на землю.
Интересная мысль, тут нужно подумать о реализации. Благодарю за идею.
Здравствуйте, у меня вопрос относительно работы барометра и полётных режимов. Сначала барометр - после подключения аккумулятора к коптеру до момента взлёта проходит какое-то время, (в среднем около минуты) за это время высота по барометру успевает уплыть на 1,5-2м в минуса и в чём собственно вопрос : при арминге высота в 0 как я понял не сбрасыватеся? Потому что телеметрия после арминга продожает показывать всё те же -1.5м и лёгкое движение стика газа заставляет коптер бешено набрать эти 1.5м которые он думает провалился. Так вот это только у меня так или я что-то делаю не правильно?
Теперь полётные режимы - в CF были режими HORIZON и BARO и их комбинацией можно было было выбирать просто 2D фикс по горизонту или + ещё стабилизацию по высоте или только стабилизацию высоты, в INAV, BARO исчез, если ставлю режим HORIZON, то blacBox потом показывает режим HORIZON|BARO, т.е. получается что в iNAV , нельзя использовать чистый режим HORIZON без удержания высоты?
за это время высота по барометру успевает уплыть на 1,5-2м в минуса и в чём собственно вопрос : при арминге высота в 0 как я понял не сбрасыватеся
Нет, не сбрасыватеся.
лёгкое движение стика газа заставляет коптер бешено набрать эти 1.5м которые он думает провалился. Так вот это только у меня так или я что-то делаю не правильно?
Взлетаете в режиме удержания высоты? Тогда не удивительно, “целевая” высота запоминается при активации режима удержания высоты, а не при арминге. Об этом я не подумал, приделаю сброс целевой высоты/позиции при арминге.
blacBox потом показывает режим HORIZON|BARO
Почему нельзя, можно, не активировать ALTHOLD и все. BARO в Blackbox - это и есть ALTHOLD.
Если пробуете на “тестовой” сборке, то в ней нашелся глюк с режимами. Исправляю, скоро выложу новую тестовую сборку.
Пристарелые народные mtk3329/3339 и ublox-ы определенно от 500мс и выше. Хотя я пытался бегать стометровки по полю уже полтора-два года назад
Сегодня прислали лог, по которому задержка данных между акселем и GPS очевидно близка к секунде 😃
Однозначно надо переделывать компенсацию задержки.
У меня всегда стоит Full chip erase.
Я старым вариантом очень доволен, а в новом косяки есть… Поэтому подожду пока.
Есчо раз, огромное спасибо Константин!