Вопросы по iNav
может мне кто либо объяснить, почему так поведение кардинально отличается? Я хочу такое поведение и в альтхолде.
Возможно, вы в аппе не можете удержать газ в “коридоре висения альтхолда” (alt_hold_deadband, по умолчанию 50). Судя по видео, у вас FlySky, а у него точность стиков не особо хорошая. В конце полёта по точкам полётник держит высоту, игнорируя канал газа, а как только переключаетесь в альтхолд - уже смотрит по этому каналу, хотите вы снижаться, висеть или подниматься. В общем, попробуйте увеличить alt_hold_deadband, например, до 100.
я специально для этого в осд вывел отображение уровня газа. и по нему выставлял 50 процентов. в этот раз прямо по осд не целился. но я вас уверяю, если целится ситуация такая же. а вот в безветрие висит.
я специально для этого в осд вывел отображение уровня газа. и по нему выставлял 50 процентов. в этот раз прямо по осд не целился. но я вас уверяю, если целится ситуация такая же. а вот в безветрие висит.
Я не знаю как реализован газ висения в INav, но у меня он разный на 3S и 4S акумуляторах. на 3s 70%, на 4s 40-45%. и флайскай не такой уж кривой, чтоб на нем нельзя было попасть в газ висения. У меня все ровненько висит, и даже всякие вкусности делает с флайскаем. Правда флайскай моденный сильно на дальность + 10 каналов. Я думаю проблема все же в чем то другом (верояно в корявом барометре?).
вот что у меня на флайскай вышло. Первая половина видео - посхолд и стаб, вторая - управление с EZGUI (follow me, wang и orbit)
Правда флайскай моденный сильно на дальность
Это как? Про 10каналов знкю, сам юзаю. Есть еще мод для расширеной телеметрии по айбус, правда это надо не только аппу шть но и приемник
Конфиг не обязателен, INAV сам сконфигурирует модуль как нужно.
Кстати. Айнав только ublox-модули умеет конфигурить?
Имею пару модулей (PA6C и GMS G9) на чипе MT3333 от медиатека, их айнав не конфигурит. Бодрейт и апдэйт рейт остаются дефолтными (9600 / 1 Гц).
Рейты оптимальные я выставил, может стоит еще что-то изменить?
Протокол NMEA.
Он же будет дизармить при арминге с тумблера?
Да, будет.
В свежевышедшем iNAV 1.7.2 на таргете OMNIBUS перестал работать LED STRIP.
Да, есть глюк. Уже пофиксено, но нужно протестировать. У меня OMNIBUS F3 платы нет. github.com/iNavFlight/inav/pull/1924
Возможно, вы в аппе не можете удержать газ в “коридоре висения альтхолда” (alt_hold_deadband, по умолчанию 50). Судя по видео, у вас FlySky, а у него точность стиков не особо хорошая. В конце полёта по точкам полётник держит высоту, игнорируя канал газа, а как только переключаетесь в альтхолд - уже смотрит по этому каналу, хотите вы снижаться, висеть или подниматься. В общем, попробуйте увеличить alt_hold_deadband, например, до 100.
Согласен, вероятнее всего проблема именно тут. Раз в миссии или RTH держит высоту корректно - значит AltHold сам по себе работает правильно.
Имею пару модулей (PA6C и GMS G9) на чипе MT3333 от медиатека, их айнав не конфигурит. Бодрейт и апдэйт рейт остаются дефолтными (9600 / 1 Гц).
Поддержка MTK уже в ветке development. В следующем релизе будет.
C I2C надеюсь разобрались. У м8n чип такой же что стоит на СП Ф3, так что скорее всего сразу заведется при первом же подключении.
Но не забудьте про ориентацию, на m8n компас припаян снизу платы (перевернут), так что в INAV надо будет обязательно поставить верную ориентацию. У меня с похожим модулем вышло Flip 270.
Спасибо за подсказки и советы. Саму схему пробовал аккуратно отщелкнуть- не получилось, видимо научились Китайцы паять. А феном немного нагрел и пинцетом с небольшим усилием стянул с посадочного места. С 12С тоже без проблем- видимо угадал с первого раза и все заработало. Компас перевернул в настройках, но не угадал с направлением. Подключаю к компьютеру через телеметрию и видимо показания компаса с задержкой приходят. Посмотрел, вроде совпадают, откалибровал и в небо. Спутники отлично ловит, а вот унитаз был небольшой. После посадки заметил, что курс на 90 гр отличается от фактического. Сегодня поиграюсь с настройками и позже отпишусь и видео выложу. Самому интересно, как поменялось поведение коптера после замены штатного компаса на выносной.
Заметил, что у меня коптер после взлёта и в полёте всегда медленно разворачивает по часовой стрелке ( по Yaw) и мне переодически приходится его стиком радера поправлять. Это в режиме Stab, Acro, не навигационных. Вопрос, как его оттримировать? Нашёл на схеме диаграмму команд, но там нет триммирования по Yaw.
Полагаю, что проблема не в полётнике. Что за модуль в аппе? DJT или XJT?
Если DJT, то взять что-либо с приёмника X-серии не получится, кроме уровня сигнала.
Весело получается: в теме по аппе сказали, проблема точно не в аппе иди в тему с полетником, а от сюда туда посылают… 😁
Если по теме, то в аппе стоит модуль XJT.
Вопрос:как правильно включить софт сериал? Может у меня тут проблема.
Уже пофиксено, но нужно протестировать. У меня OMNIBUS F3 платы нет. github.com/iNavFlight/inav/pull/1924
Скачал этот реф, пересобрал - LED заработал, спасибо.
Заметил, что у меня коптер после взлёта и в полёте всегда медленно разворачивает по часовой стрелке ( по Yaw) и мне переодически приходится его стиком радера поправлять
Проверьте, во вкладке Receiver, что у вас канал Yaw при центральном положении стика имеет значение 1500 плюс-минус yaw_deadband. Скорее всего, он “вылез” - вот коптер и крутит. Поправить командой rxrange для канала 2 либо перекалибровкой стиков аппы.
Я обычно делаю так:
- проверяю по экрану аппы, что каналы подпружиненных стиков нормально становятся в середины при отпущенных стиках. Если это не так - перекалибровываю стики. Можно, конечно, триммировать, но это “костыли”.
- в CLI делаю rxrange reset, а потом проверяю вкладку receiver в конфигураторе - какие значения канала ch (chMin и chMax) отображаются по крайних отклонениях соответствующего стика, далее rxrange ch chMin chMaх и save.
- снова иду во вкладку Receiver - проверяю крайние точки (должны стать 1000-2000) и ЦЕНТР. Если он “дрожит” не вокруг 1500, а смещён - начинаю подбирать границы в rxrange (обычно в сторону уменьшения chMax и/или увеличения chMin) так, чтобы сместить “среднюю точку” к требуемым 1500.
- Отмечаю размах “дрожи” канала вокруг 1500, после чего выставляю deadband для ролла-питча, и yaw_deadband для ява так, чтобы максимальное отклонение “дрожи” канала от 1500 не превышало значения соответствующего deadband (обычно +1+2).
Для следующей модели (другого приёмника + полётника) пункт 1 пропускаем.
Вопрос:как правильно включить софт сериал? Может у меня тут проблема.
может стоить сперва всё настроить на реальном uart что б исключить проблему виртуального порта, а уж когда всё заработает то и мучить софтсериал. не знаю как у вас в аппе, а на тараньке телеметрийные датчики нужно добавлять на экран, сами по себе эти данные не появляются
может стоить сперва всё настроить на реальном uart что б исключить проблему виртуального порта, а уж когда всё заработает то и мучить софтсериал.
Чуть позже попробую с реальным uart.
не знаю как у вас в аппе, а на тараньке телеметрийные датчики нужно добавлять на экран, сами по себе эти данные не появляются
А какие тут датчики? На сколько я понимаю в smartport приемника должна полится телеметрийная информация от полетного контроллера, передатчик (который стоит в аппаратуре) должен принять этот поток, а аппаратура вывести эти значения на экране телеметрии. (экран в tyrniga 9x настраивается, но пока туда ничего не прилетало)
А какие тут датчики? На сколько я понимаю в smartport приемника должна полится телеметрийная информация от полетного контроллера, передатчик (который стоит в аппаратуре) должен принять этот поток, а аппаратура вывести эти значения на экране телеметрии. (экран в tyrniga 9x настраивается, но пока туда ничего не прилетало)
В Smartport ничего не льется. Приемник сам опрашивает сенсоры, которые запрашивает аппаратура. Возможно сочетание Smartport и Турнига вообще не работает. Советую сначала проверить на настоящем Smartport-сенсоре.
В Smartport ничего не льется. Приемник сам опрашивает сенсоры, которые запрашивает аппаратура. Возможно сочетание Smartport и Турнига вообще не работает. Советую сначала проверить на настоящем Smartport-сенсоре.
Если так, то БАСТА ничего не получиться, т.к. Турнига может только принимать информацию т.к. для работы телеметрии там устанавливается инвертор (как правило на транзисторе, хотя у меня сделано на микросхеме 74HC14).
Я тут задумался, а что если рядом поставить ещё один, но на работу в обратную сторону… только он должен быть подключен не к MOSI а к MISO. Очень интересно, нужно будет попробовать!
Если так, то БАСТА ничего не получиться, т.к. Турнига может только принимать информацию т.к. для работы телеметрии там устанавливается инвертор (как правило на транзисторе, хотя у меня сделано на микросхеме 74HC14).
А вы не путаете Smartport и FrSky Telemetry? Это разные вещи.
FrSky Telemetry - это именно телеметрия (для модулей DJT и приемников D8), ПК сам будет слать данные.
А SmartPort - это двунаправленный протокол (для модулей XJT и приемников D16), приемник сам опрашивает датчики на шине и отправляет данные аппаратуре.
😵 Все запутался! 😁
Начну сначала.
- Если Турнига в которой стоит модуль XJT (там на 5-м контакте есть уже сигнал FrSky протокола S.PORT, но напрямую к процессору его подключить нельзя, сигнал надо инвертировать). Сигнал инвертирован и отдан процессору аппаратуры. Теперь процессор аппаратуры в курсе о уровне связи.
- Есть приемник X4R который управляет полетным контроллером по S.Bus и SmartPort которого соединен с uart полётника.
Вооооот. Так будет работать? Кто в данном случае является инициализатором начала действий с телеметрией (аппаратура, приемник X4R или полетник)?
Участков обмена данными у нас два: Полетник - X4R и XJT - аппаратура.
- Есть приемник X4R который управляет полетным контроллером по S.Bus и SmartPort которого соединен с uart полётника.
Тут проблем нет, должно работать на процессорах F3 без проблем на любых уартах.
- Если Турнига в которой стоит модуль XJT (там на 5-м контакте есть уже сигнал FrSky протокола S.PORT, но напрямую к процессору его подключить нельзя, сигнал надо инвертировать). Сигнал инвертирован и отдан процессору аппаратуры. Теперь процессор аппаратуры в курсе о уровне связи.
А вот тут может быть проблема. Как я уже говорил, S.Port - штука двунаправленная. Насчет того, кто инициатор обмена - модуль или аппаратура - не уверен, но что-то мне подсказывает, что аппаратура.
Можно на выходе S.PORT модуля XJT посмотреть осциллографом, там вообще что-нибудь есть?
Участков обмена данными у нас два: Полетник - X4R и XJT - аппаратура.
Тут проблем нет, должно работать на процессорах F3 без проблем на любых уартах.
правильно ли я нашел на просторох интернета, что необходимо соеденить TX+RX+SmatrPort?
А вот тут может быть проблема. Как я уже говорил, S.Port - штука двунаправленная. Насчет того, кто инициатор обмена - модуль или аппаратура - не уверен, но что-то мне подсказывает, что аппаратура.
Можно на выходе S.PORT модуля XJT посмотреть осциллографом, там вообще что-нибудь есть?
К сожалению осциллографа не имею 😦
К сожалению осциллографа не имею
А вот это зря. Это ключевой момент. Если XJT не выдает телеметрию без запроса - это одно, а если XJT что-то выдает, но турнига этого не понимает - это совсем другое.
правильно ли я нашел на просторох интернета, что необходимо соеденить TX+RX+SmatrPort?
В общем - да, но без защитного диода между TX и S.Port можно пожечь процессор в аппаратуре.
В общем - да, но без защитного диода между TX и S.Port можно пожечь процессор в аппаратуре.
вопрос был про TX+RX+SmatrPort на моделе, т.е. TX+RX полетного контроллера соединяем с SmatrPort приемника
вопрос был про TX+RX+SmatrPort на моделе, т.е. TX+RX полетного контроллера соединяем с SmatrPort приемника
Если софтсериал - то да. Но S.Port на софтсериале заведется стабильно только на F4 и быстрее
Если софтсериал - то да. Но S.Port на софтсериале заведется стабильно только на F4 и быстрее
а если не софт сериал, то как быть?