А давайте обсудим Arducopter - APM
Если вы не в состоянии отыскать на сайте разработчика beta и latest версии прошивок
Для тех, кто не только в танке, но и люк заварил: rcopen.com/forum/f123/topic233564/31238
И кстати на версии 4.1.0 гпс работает на скорости 230400 и если потом залить айнав то гпс не будет работать т.к. будет стартовать на скорости 230400 и чтобы заработал на 115200 нужно прошить арду 4.0.4 и запустить дождаться определения гпс или подключить к компу гпс через уарт и настроить скорость на 115200
И кстати на версии 4.1.0 гпс работает на скорости 230400
Малоосмысленная настройка, ИМХО - от GPS просто нет столько траффика чтобы такую скорость врубать, так как сам GPS чаще 10Гц не сможет пересчитывать координаты. Зато устойчивость линка понизится - не у всех же там спецкабель с правильным экранированием, чаще всего тупо 4 проводка, свитых в косичку.
Есть ветка master branch в ней всегда текущее состояние а есть brunch 4.0.4 4.0.3 и т.д. И никогда ветка мастер не станет 4.0.4 - для нее есть отдельная ветка куда попадут коммиты только для версии 4.0.4 не более. А по вашим рассуждениям можно сделать вывод что в версию 4.0.4 могут попасть изменения или доп. функции из версии 4.1.х - нет такого - ибо для этого версии и существуют чтобы можно было четко знать что в версии 4.1.0 к примеру появилась функция такая то и ее нету в 4.0.4
По факту там довольно мутно, так как в мастере есть коммиты, к примеру, правки ReliseNotes.txt с пометкой “Copter 4.0.4-rc1(2,3)”, в то же время аналогичные коммиты есть в brunch “Copter-4.0”. Для Plane - аналогично. Зачастую в актуальной релизной ветке лежит старый релизнотс, в котором попросту нет описания свежего релиза, а актуальный релизнотс лежит только в мастере. То есть что-то как-то из мастера в бранчи переносится, но довольно “неаккуратно” - по логу и графу ревизий это хорошо видно (нет “связок”), но сути дела это не меняет - формальная версия найтбилда 4.1.0-dev установлена с момента первого релиза 4.0.0 (чтобы быть “выше”), но с тех пор куча всего из мастера (помним про найтбилды 4.1.0-dev из его исходников) переехало в релизные ветки Copter-4.0 и plane4.0 в процессе выпуска релизов 4.0.х. То есть, как я и написал, то, что формально было “одним из” 4.1.0-dev, в итоге оказывалось релизом 4.0.х.
Обновил прошивку, по десять раз залил сохраненные параметры. На некоторые параметры ругнулся, что readonly. И после манипуляций требует еще раз произвести калибровку акселя и компаса. После каждой прошивки надо по новой калибровать? Как в айнаве нельзя перенести настройки?
Readonly:
stat_bootcnt
stat_flttime
stat_reset
stat_runtime
А данные параметры пропущены:
compass_exp_did
compass_exp_did2
compass_exp_did3
compass_primary
Обновил прошивку, по десять раз залил сохраненные параметры.
Я обычно заливаю дважды:
- Открываю вкладку full parameters tree, гружу параметры из файла, сохраняю и ПЕРЕЧИТЫВАЮ.
- Открываю вкладку full parameters list - и повторяю предыдущие действия.
Потом пробегаюсь по вкладкам OSD и проверяю, что всё прочиталось корректно. В айнаве таких заморочек нет 😃
На некоторые параметры ругнулся, что readonly.
Readonly:
stat_bootcnt
stat_flttime
stat_reset
stat_runtime
Это нормально - типа, нефиг “счётчик скручивать” 😁
А данные параметры пропущены:
compass_exp_did
compass_exp_did2
compass_exp_did3
compass_primary
Видимо, появились в новой версии. Хотя я что-то не нахожу их описания даже в dev-документации
Так я залил и list и tree по несколько раз.
Значения INS_ACCOFFS, INS_ACCSCAL и INS_GYROFFS не нулевые по всем осям, но все равно требует калибровки.
Из всего что понравилось в арду это как он возвращает квад в горизонтальное положение - четко так и без дерганий… на этом пока все 😃 надо на айнаве бы такого добиться
надо на айнаве бы такого добиться
На арду есть автотюн, а на айнаве вручную надо крутить пиды.
Так я залил и list и tree по несколько раз.
Значения INS_ACCOFFS, INS_ACCSCAL и INS_GYROFFS не нулевые по всем осям, но все равно требует калибровки.
Произвел калибровку по новой и потом вбил старые значения. Больше сообщений о калибровки акселя не появляются.
Сигнал sbus на пине sbus так я и не завел а завелся только через пин ppm причем это делается я так понял через декодирование быстрым таймером… ну да ладно…
В ходе попыток разобраться почему у меня таки не работает RC input на HGLRC F4 WING (таргет omnibusf4v6) поковырял ardupilot\libraries\AP_HAL_ChibiOS\hwdef\omnibusf4v6\hwdef.dat - и с обалдением выяснил, что SBus предполагается заводить через LED pin!
# LED strip output pad used for RC input
# timer 4 is free (not used for pwm)
PB6 TIM4_CH1 TIM4 RCININT PULLDOWN LOW
Они что - и вправду разбирают SBus-пакеты “руками” по таймеру, а не аппаратно?!!
Получается, что RX4 тупо теряется - его особо ни к чему не применишь, был бы TX - можно было бы через полудуплекс FPort завести, хотя там один фиг инвертор мешать будет.
В ходе попыток разобраться почему у меня таки не работает RC input на HGLRC F4 WING (таргет omnibusf4v6) поковырял ardupilot\libraries\AP_HAL_ChibiOS\hwdef\omnibusf4v6\hwdef.dat - и с обалдением выяснил, что SBus предполагается заводить через LED pin!
# LED strip output pad used for RC input # timer 4 is free (not used for pwm) PB6 TIM4_CH1 TIM4 RCININT PULLDOWN LOWОни что - и вправду разбирают SBus-пакеты “руками” по таймеру, а не аппаратно?!!
Получается, что RX4 тупо теряется - его особо ни к чему не применишь, был бы TX - можно было бы через полудуплекс FPort завести, хотя там один фиг инвертор мешать будет.
Да декодится с помощью таймера 😄 Видимо это было удобно в один пин засунуть ppm sbus ibus и все что захочешь а потом вываливаются какие нибудь задержки…
И при этом нужен пин с таймером видимо led для этого подошёл…
Почему теряется? Можно все настроить через hwdef есть такая штука как ALT(1) 1 это номер чисто можно и ALT(2) а затем указываем в арду номер и пины буду меняться в зависимости от того что прописано в hwdef. Ссылку на конфиг этот - я гляну?
Видимо это было удобно в один пин засунуть ppm sbus ibus и все что захочешь а потом вываливаются какие нибудь задержки…
А потом адепты арду задвигают тут про “надёжность и вылизанность кода” в сравнении с “сырой поделкой iNAV” 😁
Почему теряется? Можно все настроить через hwdef есть такая штука как ALT(1) 1 это номер чисто можно и ALT(2) а затем указываем в арду номер и пины буду меняться в зависимости от того что прописано в hwdef.
Такой фокус я видел в конфигах, но просто что можно повесить на “одноногий” UART с “внешним” однонаправленным инвертором на входе (стандартное схемное решение для Sbus на полётниках с F4)?
Ссылку на конфиг этот - я гляну?
Мануал на полётник: cdn.shopify.com/…/HGLRC_F4_WING_1e1aa46f-a91f-4301…
Конфиг арду: github.com/ArduPilot/ardupilot/…/omnibusf4v6
Конфиг iNAV: github.com/iNavFlight/inav/tree/…/FIREWORKSV2
А потом адепты арду задвигают тут про “надёжность и вылизанность кода” в сравнении с “сырой поделкой iNAV” 😁
Такой фокус я видел в конфигах, но просто что можно повесить на “одноногий” UART с “внешним” однонаправленным инвертором на входе (стандартное схемное решение для Sbus на полётниках с F4)?
Мануал на полётник: cdn.shopify.com/…/HGLRC_F4_WING_1e1aa46f-a91f-4301…
Конфиг арду: github.com/ArduPilot/ardupilot/…/omnibusf4v6
Конфиг iNAV: github.com/iNavFlight/inav/tree/…/FIREWORKSV2
Чёт по докам написано что uart6 для sbus , uart4 не инвертированный должен и он не теряется в арду - rx можно юзать теряется uart 6 rx т.к. pb6 становится для rx input…
Опять же uart6 включен в конфиге - инвертор я так понял не отключаемый… можно поставить ещё один инвертор и будет норм 😃
Чёт по докам написано что uart6 для sbus
Да, это я уже что-то запутался. 😃 Там действительно выведен пин RC (RX6_inverted) и TX6, то есть UART6 можно задействовать под FPort (TX6 в режиме полудуплекса)
Для тех кто смотрим в книгу и видит фигу, какой параметр менять, чтобы коптер плавнее тормозил, а не резко при отпускании стиков:
LOIT_BRK_ACCEL: max acceleration in cm/s/s while braking (i.e. pilot has moved sticks to center). Higher values will stop the vehicle more quickly
или
LOIT_BRK_JERK: max change in acceleration in cm/s/s/s while braking. Higher numbers will make the vehicle reach the maximum braking angle more quickly, lower numbers will cause smoother braking
Для тех кто смотрим в книгу и видит фигу, какой параметр менять, чтобы коптер плавнее тормозил, а не резко при отпускании стиков:
LOIT_BRK_ACCEL: max acceleration in cm/s/s while braking (i.e. pilot has moved sticks to center). Higher values will stop the vehicle more quickly
или
LOIT_BRK_JERK: max change in acceleration in cm/s/s/s while braking. Higher numbers will make the vehicle reach the maximum braking angle more quickly, lower numbers will cause smoother braking
Ага я ж писал про один из них… вообщем все в Вики есть… читать только надо
Так какой параметр менять?
Так какой параметр менять?
Они друг друга дополняют - 1 - максимальное ускорение при торможении а 2 это насколько быстро достичь угла торможения…
Видимо первый управляет скоростью моторов а 2 углом - это как бы на авто 1 - газ в пол а второй руль до конца в сторону))
1 - throttle
2 - pitch/roll angle
Имхо…
Ладно, буду оба занижать и смотреть что получилось.
Я правильно понял, что после каждой новой прошивки надо по новой калибровать аксель и компас? А то прыгать с 5 килограммами не очень приятно. А еще на айнав гонят.
Вы сюда постебаться заходите? Две страницы говна на вентилятор.
Вы сюда постебаться заходите? Две страницы говна на вентилятор.
Так напиши, где я ошибаюсь? Что еще нужно чтобы перенести настройки?