Вопросы по iNav
Проверьте, во вкладке Receiver, что у вас канал Yaw при центральном положении стика имеет значение 1500 плюс-минус yaw_deadband. Скорее всего, он “вылез”
Алексей, ваш диагноз верный. Отрегулировал диапазон 1000-2000 и центр 1500 по всем каналам и коптер не узнать- висит на месте, никуда не дёргается. Правда подгонял на самой аппе ( САБ тримерами и крайними положениями). Не совсем понял, почему вы написали костыли, но получилось.
Ну и конечно же большое спасибо Константину и всем, кто помогал осваивать с нуля данную прошивку- Сегодня первый раз за три недели коптер стабильно возвращался домой, висел и это пять раз подряд! После замены штатного компаса на ПК и установки GPS ( Neo8 вместо Neo7), нет ни малейшего намёка на улёт, унитаз и тп. Настройки Пидов не менял, как в дефолте. Появилась уверенность в успешном завершении полёта, а это самое главное.
Есть ещё вопрос к Константину: едут мозги SP Rasing F4 EVO и для него PDB c OSD SP racing F3 OSD. Прошивки от Clinfligt есть и на ПК и на OSD. A как с INAV?
Есть ещё вопрос к Константину: едут мозги SP Rasing F4 EVO и для него PDB c OSD SP racing F3 OSD. Прошивки от Clinfligt есть и на ПК и на OSD. A как с INAV?
В работе. У меня плата SPRF4 EVO лежит, руки не доходят код допилить. SPRF3 OSD вероятнее всего с INAV работать нормально не будет, все вопросы к Доминику, он занимается поддержкой этой платы.
вопрос: имеел ли смысл ставить на самолет датчик воздушной скорости (трубку пито) ? оно его кроме как на ОСД еще как-то использует ?
Есть. Поддержка воздушной скорости развивается, в 1.8 будет уже полезна.
Вопрос к Константину:
- Режим HEADING HOLD для летающих крыльев будет?
- Режим HEADING HOLD для летающих крыльев будет?
Будет. Не могу пока сказать когда, но не раньше чем появится полноценная поддержка датчика воздушной скорости.
Не совсем понял, почему вы написали костыли, но получилось.
Костыли - потому что это подгонка только под один сетап (точнее, под связку приёмник+ПК). Если моделей несколько - то на других погрешности каналов вполне могут быть другие (другой рабочий день на китайском заводике, другая смена после другого сорта рисового пива и т.п.). Потому лучше нестроить аппу так, чтобы по её индикаторам каналы работали верно, потом убрать “огрехи” калибровкой каналов приёмников в ПК - тогда каналы будут работать без перекосов на всех моделях, подключенных к аппе, а субтриммеры остаются “оперативным резервом” для подстройки в поле (ну если вдруг аппа от качества или возраста будет “плыть” в течение лётного дня). Крайние точки на аппе я вообще без необходимости (например, при настройке положения газа для RadioFS) не трогаю.
Проведу аналогию с врдупилотом - там в конфигураторе есть вкладка Radio Calibrate, которая проделывает ровно всё то же самое (определение значений каналов для крайних и центральных положений стиков) и ровно с той же целью.
имею два квадрика под аправлением айнава. 1 на раме тбс дискавери (1.6.1), 2 вортекс 280 (1.7.1) вообщем проблема такая. во вкладке где меняются срость движения в гпс режиме и скороподъемность. у обоих изменил величины в большую сторону(и поставил одинаковые величины у обоих) так как сток слишком медленный по мне. так вот если на прошивке 1.6.1 реакция изменлась на всех величинах которые я поменял(т.е. если я дал тапку в пол то он ринулся вверх на пределе своей ВМГ, то же самое и со снижением, если газ в нуле, то и практически свободное падение со стабилизацией)(меня так устраивает)(ну и само собой скорость движения в автопилоте увеличил до 45кмч) , то на 1.7.1 скорости движения по горизонтали автопилота поменялись,а скороподьемность и спуск не поменялись. точнее величины поменялись но скорость осталось медленной как и была. т.е. на вортексе(1.7.1) в гпс режиме практически не возможно летать в гпс режиме с такими скоростями набора и спуска высоты. понятно что в гпс я на нем летаю только при возврате домой, а все остальное время в акро. но как бы уже надо бы дискавери шить что нибудь посвежее, а тут такие ньюансы. так как для дискавери как раз основной режим полета это гпс, так как квадрик с подвесом. в чем причина такого поведения?
в чем причина такого поведения?
Нужны текущие настройки для версии 1.7.1 и логи полета с попыткой резкого подъема/спуска.
Константин, очень хорошо что началась поддержка полетника Matek f405 osd. так как по мне единственный достойный кандидат на ф4 с нормальным количеством уартов. так вот у него нет и2ц шины, а значит пока не годится для использования мультиротора. в следующем релизе прошивки поддержку и2ц допилят? т.е. есть ли смысл себе на будущее его брать? и еще на сайте матек есть обновленная версия его. только уже в качестве AIO. вот на ней видно что есть пятаки шины и2ц. т.е. на ней уже полноценно работает и2ц в текущей версии проршивки? или пока еще нет?
сейчас пойду логов наснимаю )
Константин, очень хорошо что началась поддержка полетника Matek f405 osd. так как по мне единственный достойный кандидат на ф4 с нормальным количеством уартов. так вот у него нет и2ц шины, а значит пока не годится для использования мультиротора. в следующем релизе прошивки поддержку и2ц допилят? т.е. есть ли смысл себе на будущее его брать? и еще на сайте матек есть обновленная версия его. только уже в качестве AIO. вот на ней видно что есть пятаки шины и2ц. т.е. на ней уже полноценно работает и2ц в текущей версии проршивки? или пока еще нет?
Матек в версии 1.7.2 не работает корректно, плохо протестировали 😦
Поддержка I2C уже реализована, в следующей версии будет полноценная. Скорее всего в августе будет 1.7.3 (багфиксы по итогам 1.7.2).
Да, кстати, всем кто пользуется платами F1 (CC3D, NAZE32) - следующая версия (1.7.3 или 1.8) будет последней, пригодной для этих плат. Надо двигаться дальше.
yadi.sk/d/ihA_8l8C3LJejE вот пока дамп. по миксеру чтоб не пугались) квадрокоптер, полетник спрейсинг. но мот оры перенесены с 5го по 8 выводы. так как 1е 4ре выхода запороты при не аккуратой пайке. сейчас пойду логи снимать, а потом еще пол час ны выгрузку из полетника.
yadi.sk/d/ihA_8l8C3LJejE вот пока дамп. по миксеру чтоб не пугались) квадрокоптер, полетник спрейсинг. но мот оры перенесены с 5го по 8 выводы. так как 1е 4ре выхода запороты при не аккуратой пайке. сейчас пойду логи снимать, а потом еще пол час ны выгрузку из полетника.
Ок, жду. Посмотрю сегодня-завтра.
добавил. посмотрел логи. по логам мне показалось что вроде адекватно. сейчас пойду еще раз подлетну и выложу логи вместе с видео с курсовой для более полной картины
C минимосд вообще никаких проблем. Хоть MAVLink, хоть LTM, хоть MSP. На ОСД шить прошивку ScarabOSD (она же MWOSD), настраивать по мануалу к ОСД.
Кстати, про MWOSD - у меня все работает адекватно, за исключением высоты. Несколько раз наблюдал, как OSD показывает высоту в районе -350 или -650 метров на протяжении всего полета, дизарм вроде-как тоже ситуацию не меняет. При чем, высота при подъеме/спуске меняется относительно этого значения. Это все в режиме ALTHOLD, сам режим работает абсолютно корректно, т.е., барометр, вроде как, работает штатно. EzGUI тоже проговаривал вполне адекватную высоту (правда, это было в разных полетах). Плюс один раз летал - -600 метров, отлетал АКБ, поставил другой (по сути, перезагрузился) - высота стала практически нормальной (метров на 5 в минус). В логах вроде таких неадекватных высот не видел. Куда можно покопать?
Да, кстати, всем кто пользуется платами F1 (CC3D, NAZE32) - следующая версия (1.7.3 или 1.8) будет последней, пригодной для этих плат. Надо двигаться дальше.
Будем поминать старичков добрым словом) А когда планируется поддержка Omnibus F7 с двумя гирами?
вообщем по логам. добавил видео с курсовой. его нужно соотносить с файлом логов “logs2”
Да, есть глюк.
Кстати, есть ещё один глюк, имеющий отношение к LED_STRIP. Если изменять какие-нибудь настройки через OSD (Omnibus F3), а потом сохранить их (SAVE-REBOOT), то запомнится ОТКЛЮЧЕННАЯ опция LED_STRIP. Если зайти в меню FEATURES и включить её, а потом выйти с сохранением, то опция включится. При этом текущее состояние опции при вхождении в соответствующий раздел OSD отображается корректно.
Параметр nav_disarm_on_landing контролирует поведение после посадки.
Экспериментально выяснил, что эта опция не работает при арминге по тумблеру, а лишь при арминге со стика. Точнее, судя по двойному писку после посадки, выполняется попытка дизарма, но оказывается “перебита” включенным режимом ARM. Может, всё же менять статус арминга режимом ARM только при СМЕНЕ (включении или отключении) этого режима? То есть для арминга после авто-дизарма нужно будет перекинуть тумблер арминга в положение disarm и потом снова в arm. Тогда для арминга по тумблеру работал бы и auto_disarm_delay.
Вопрос в первую очередь к Константину, но может еще кто сможет “погадать на кофейной гуще” …
от чего могла быть предпринята попытка к бегству, если судя по ОСД ничего в датчиках не поменялось и причин вроде бы небыло (видео всего 30сек, оставил только относящееся к вопросу):
от чего могла быть предпринята попытка к бегству
Обычно навигацию “вертит” при сбое компаса. Кстати, его показаний я у вас на OSD не увидел.
Ну а подрыв по высоте - это логи надо смотреть. Хотя, судя по вопросу, вы их вряд ли писали.
Решил переделать 180-й гоночный квадрик под неспешные полёты с iNav. Нужен только AltHold без PosHold. В наличии есть барометр BMP280. Подскажите вменяемый ПК для iNav со встроенной OSD и I2C для барометра.
Подскажите вменяемый ПК для iNav со встроенной OSD и I2C для барометра.
Omnibus F3 - барометр уже встроен, для полноценной навигации GPS цепляется по UART (их 2 свободных, UART3 занят под SBUS), компас - по I2C.
У полётников с OSD на базе F4 что с барометром что с выводом I2C - печалька. Исключение составляют те же аирботовские омнибасы, но в Pro-версиях на плату малоосмысленно впихнут датчик тока, отчего пинауты “распиханы куда попало”. “Не Pro” разведен нормально, но почему-то его Али и Банггуд клонировать не хотят, а официалы просят за него больше $40 за версию с барометром.
Omnibus F3 - барометр уже встроен
Такой? И по моторам вопрос: сейчас стоят на 2700kv, но думаю поставить менее оборотистые. Есть 1100kv пойдут ли они на 210 (не 180, ошибся постом выше) раму или надо 1800-2300?