Прошивки CleanFlight/BetaFlight для полетников
Подскажите, почему так странно PID_P работает, как будто лесенкой.
И еще rcCommand так редко обновляется, это нормально?
Прошивка BF 2.8 RC2 + Multishot 14.6 looptime=250 spr3
почему так странно PID_P
У меня так же было , откатился на 2.7.1
У меня так же было , откатился на 2.7.1
проверил на 2.7.1. тоже также
И еще rcCommand так редко обновляется, это нормально?
У вас RC deadband не включен случаем?
У вас RC deadband не включен случаем?
У меня должно быть все по дефолту, я поменял только Fast_PWM=Multishot, Looptime=250, Motor_PWM_Rate=16000.
Но ща гляну Deadband.
Да может быть еще это по тому что подключено по PPM ?
Т.е. I2C где-то в 9 раз медленнее, если все правильно понял. Я так понял что дело не в шине а в том что процессор не может быстро работать с шиной I2C. программно долго обрабатывает считывание, а так он не только этим занимается, то приходится жертвовать частотой считывания данных из MPU.
Так что шина I2C должно хватать за глаза.…
SPI - на “медленных” контроллерах пока понты. ИМХО.
К слову о понтах. Борис посчитал время вычисления PID Rewrite контроллера на разных мозгах:
1 F3 SPI 70us
2 F1 CC3D 166us
3 F3 I2C 190us
4 F1 I2C 230us
(www.rcgroups.com/forums/showpost.php?p=34724577&po…)
Выходит, что второе место у F1 c SPI. 😃
I2c шина - именно она и есть самое узкое место. Она вносит примерно 130 микросекунд задержки по сравнениюс SPI (www.rcgroups.com/forums/showpost.php?p=34698233&po…).
Ведь после того как данные посчитаны гироскопом, их же ещё надо передеть в контроллер. И эта передача и есть узкое место. I2c передаёт информацию по капле, а SPI струйкой (елси проводить аналогии). Поэтому, даже если процессор и ничем не занят, он всё равно получит данные с i2c на 130 микросекунд позже (пока ему там накапает). 😃
Павел
[QUOTE=nppc;6414074]К слову о понтах. Борис посчитал время вычисления PID Rewrite контроллера на разных мозгах:
1 F3 SPI 70us
2 F1 CC3D 166us
3 F3 I2C 190us
4 F1 I2C 230us
Спасибо за информацию.Никто не спорит о том какая шина быстрее.Тут ключевое, если контроллер ничего не делает, а он все время что-то делает,вот когда временем “делать” можно будет пренебречь,мы и будем говорить, что контроллер упирается в шину.Тем более это 8битный pid-контроллер,который будет чаще оперировать одинаковыми цифрами из-за небольшой точности.
Только я не совсем понимаю зачем так часто считывать показания гироскопа. Чтобы pid-регулятор чаще управлял медленными моторами?Мало считывать данные, их нужно ещё и обработать,и выработать управляющее воздействие.
Борис недавно приводил список ПК с SPI (www.rcgroups.com/forums/showpost.php?p=34695503&po…)
Colibri Race
Lux Race
Motolab Cyclone
SPRACINGF3EVO
DOGE
CC3D (this is F1 board though…performs slightly better than i2c F3 board on rewrite)
Alienflight
это исчерпывающий список или есть еще варианты?
какая шина у всяких клонов SPRACING с БГ?
как онаять какая версия протокола у каждого конкретного ПК? например X-Racer F303? ведь производители эту инфу не выкладывают
по версии гиры? тогда какие модели используют какую шину?
Андрей, вы немного не так представляете себе работу прошивки BetaFlight (не помню, Cleanflight уже работает по схеме Бетафлайта или нет…).
Так вот, процессы обработки различных событий разделены т.н. task scheduler-ом. Например, опрос гироскопов запускается каждые 250мкс., расчёт PID-ов каждые 500мкс, SBUS каждые 1000мкс и т.д.
Поэтому управление моторами не обязательно будет происходить после каждого опроса гироскопа. А вот, чтобы получать более точные данные гироскопа, нам нужно его опрашивать как можно чаще. вот и получается, в моём примере мы имеем уже два значения гироскопа, усредненных до одного, чтобы использовать его в расчётк PID.
Павел.
Ну я предполагал,что разные задачи с разной периодичностью вызываются. Я вот не пойму, раз управление осуществляется не с такой же периодичностью, то зачем тогда контроллеру эти данные, чисто для усреднения выходит(если так то это странно). Если только контроллер не считывает вместо угла, угловую скорость. Ну, да ,нужно еще разобраться кто производит интегрирование угловой скорости контроллер или микросхема гироскопа. В прошивке применяется BiQuad фильтр(
), разве что для его работы. Нужно посмотреть с какой реально периодичностью запускается цикл опроса гироскопа.
Если считывать как можно быстрее , то можно получить ВЧ составляющую(вибрации). Поэтому нужно считывать без фанатизма. Максимальная частота считывания должна быть в два раза больше чем макисальная частота считываемого сигнала. Как мы можем получить большую точность, чем позволяет микросхема-гироскоп.
прошился 2.7.1 с 2.4.0, пиды прижились те же, loop был 500, поставил 375. Коптер стал оочень мягкий в управлении. как будто рЭйты стали ниже. рЭйты на 2.4.0 были 0.75, а в 2.7.1 выше единици не подниаются. Это нормально или нет? раньше вроде больше единици ставились. И стало сильно трусить на спуске.
Если считывать как можно быстрее , то можно получить ВЧ составляющую(вибрации).
Если считывать в 10 раз медленнее, то можно попасть на крайне противоположные пики этих вибраций и вообще не понимать, что происходит.
Если считывать в 10 раз медленнее, то можно попасть на крайне противоположные пики этих вибраций и вообще не понимать, что происходит.
Кто нибудь измерял мах частоту этих вибраций, может они мин в два раза медленнее чем частота считывания по i2c. Если эта частота вибраций выше , то поставить демпфер и забить на SPI))))
Андрей, если вы владете английским, то почитайте вот эту ветку: www.rcgroups.com/forums/showthread.php?t=2533601
Там люди уже неоднократно поднимали ваши вопросы и есть много мнений, утверждений и тестов по поводу целесообразности ускорения луптайма, скорости управления моторами и т.д.
Павел
Edit: Из всего что я там подчерпнул, могу сказать, что с увеличением быстродействия контроллера (быстрый опрос датчиков, быстрая передача сигнала в ESC и т.д.) ухудшений в работе контроллера не наблюдалось, но некоторые замечали даже улучшение характеристик работы контроллера.
Это как (ещё одна аналогия) слушать музыку на 128кбит или 512 кбит. 😃 Чем чище сигнал с гироскопа, тем адекватней (предсказуемей) работают фильтры и другие алгоритмы контроллера.
Коллеги, а какая частота у PPM-сигнала? Я насчитал 50-60 герц всего. И какая у SBUS ?
Сейчас наблюдаю гребенку в пидах именно из за низкой частоты PPM
Правильно! PPM усредняется по двум значениям, вот оттуда и такая задержка. SBUS примерно в два раза быстрее.
В своё время Борис просто сказал не обращать на эту пилу внимания. (github.com/borisbstyle/betaflight/issues/266) 😃
Павел
Edit: Из всего что я там подчерпнул, могу сказать, что с увеличением быстродействия контроллера (быстрый опрос датчиков, быстрая передача сигнала в ESC и т.д.) ухудшений в работе контроллера не наблюдалось, но некоторые замечали даже улучшение характеристик работы контроллера.
Это как (ещё одна аналогия) слушать музыку на 128кбит или 512 кбит. 😃 Чем чище сигнал с гироскопа, тем адекватней (предсказуемей) работают фильтры и другие алгоритмы контроллера.
Ага, спасибо за ссылку, почитаю. Да, на счет музыки. Зачем платить больше за 512к, если 128к нормльно играет и большинство людей даже разницы не заметят(речь идет о разумной необходимости). А, смысл считывать шумные данные с mu-6500 по SPI, если лучше считать более точные данные но с меньшей скоростью по i2C mu-6050. Я тоже думаю, что все в комплексе даст лучший результат, нежели гнаться только за SPI.
Зачем платить больше за 512к, если 128к нормльно играет и большинство людей даже разницы не заметят
Очень даже заметно и долго непривыкшему уху сложно это слушать.
смысл считывать шумные данные с mu-6500 по SPI
Это всё равно лучше, чем считывать тоже, но медленно. Понакупили уже этих плат - надо как то пользоваться. Это как из cc3d уже все соки до последней капли выжимают.
Наверно этот вопрос заслуживает отдельной ветки и… тесты… тесты… Как показала практика, теория не всегда ею поддерживается.
Павел
Ага, нужны реальные тесты. Я вот купил F3 с гиро 6050 и не парюсь.