Прошивки CleanFlight/BetaFlight для полетников
Это вообще не для этого. Работает только 4 выхода на двигатели. Но можно FEATURE SERVO включить управление сервами подвеса. Но там свои проблемы: выходы серво 1 и 2, т.е. двигатели надо переносить на 3-6 выходы.
это в общем то понятно. в меню клинфлайта есть в закладке Configuration в окне Other features есть пункт CHANNEL_FORWARDING. по идее позволяет AUX пробросить на серву. … вот только как это настраивается найти не смог.
У меня SP f3 при включении servo tilt и CHANNEL_FORWARDING у меня тилт работает на 7 и 8 выходах. Даже удается заставить его одновременно реагировать на AUX канал. Но все это на уровне шаманства без четкого понимания правил. вот тут народ пишет что все работает,
мне пока не удалось понять как все настраивать. мне нужен чистый проброс без микса гиро-акселей.
Нужно мне это для активации пищалки на матековской ПДБ. Поскольку в качестве приемника Спектрум сателит то напрямую с приемника подать сигнал не получается. Заранее спасибо.
Друзья, посоветуйте контроллер максимально адаптированный под bf прошивку. Я так понял, что Naze32 имеет компас, барометр и умеет измерять напряжение, может лучше её?
Друзья, посоветуйте контроллер максимально адаптированный под bf прошивку. Я так понял, что Naze32 имеет компас, барометр и умеет измерять напряжение, может лучше её?
“Лучше” не измеряется гирляндой датчиков. Актуальный пк сечас это проц f3 и гира на spi.
мне нужен чистый проброс без микса гиро-акселей
Если приёмник x4r-sb, то надо его просто прошить и будет на нём выходы 9 и 10 каналов.
Решил эту проблему следующим образом:
cli ввожу команду
set gyro_sync_denom = 2 и looptime становится 250 и всё работает.
А вот если менять через меню cleanflight и устанавливать looptime 250 при том, что в cli я не менял gyro_sync_denom и он остался по умолчанию 4, то Акселерометр перестает работать.Конечно хотелось бы чтоб всё работало без cli. Но пока только так. Может кто подскажет в чем здесь проблема? или это баг такой?
Всё правильно. У вас полётный контроллер с медленным i2c гироскопом. Поэтому на быстрых лупах (250 для i2c это уже быстро) автоматом отключаются не критичные датчики (гироскоп включен всегда).
Если вы не желаете c CLI работать, то ставьте луптайм по-медленнее (или по умолчанию).
Контроллеры типа CC3D и другие с SPI гироском/акселем лучше работают на более быстрых луптаймах.
Павел
проц f3
Это sp racing f3? на бэнгуде 2 ревизии, акро и люкс, какая предпочтительней
Это sp racing f3? на бэнгуде 2 ревизии, акро и люкс, какая предпочтительней
Акро берите, как и все, доп датчики из люкса все равно не нужны.
Всё правильно. У вас полётный контроллер с медленным i2c гироскопом. Поэтому на быстрых лупах (250 для i2c это уже быстро) автоматом отключаются не критичные датчики (гироскоп включен всегда).
Если вы не желаете c CLI работать, то ставьте луптайм по-медленнее (или по умолчанию).
Контроллеры типа CC3D и другие с SPI гироском/акселем лучше работают на более быстрых луптаймах.Павел
Я вот не понял только почему на sprf3 медленный протокол с гироскопом/акселем. Странно это. Но я так для экспериментов ради, а так меня устраивает полностью и 500 луптайм
К сожалению этот вопрос не ко мне, а к разработчикам платы sprf3. Почему они использовали MPU6050 вместо MPU6000? Наверно из-за того, что i2c шина требует всего 2 пина, когда SPI требует минимум 3, а реально и того больше. А SPI шина в разы быстрее шины i2c. Вот поэтому и приходится контроллеру дольше “ждать” данных с гироскопа по i2c.
Хотя в ветке про RaceFlight RS2K говорил, что знает как считывать i2c на скорости 8кгц, но на практике пока никто ещё этого не сделал (вроде как нет смысла, всё равно данные не смогут поступать с такой скоростью по i2c).
Павел
направьте где то затупил. прошил 2.71 (была 1.12) теперь не могу прошить регули(пчёлы) через контролер . откатил назад всё ок. прошил реги бихели 14.6 . залил 2.71 и опять нет контакта.
направьте где то затупил. прошил 2.71 (была 1.12) теперь не могу прошить регули(пчёлы) через контролер . откатил назад всё ок. прошил реги бихели 14.6 . залил 2.71 и опять нет контакта.
Какую версию BLHeliSuite используете? Скорее всего дело в ней.
BLHeliSuite используете?
версия 16.0 . попробую все сначала. может скачалось что с косяком(инет на модеме-как черепаха) и ещё в 2.71 нужно прописывать set use_multishot = ON
Нет, в 2.7.1 Нужно писать:
set fast_pwm_protocol = ONESHOT125 (или что вам там нужно).
С банггуда кто-нибудь заказывал мозг CK racing F3?
Я неделю назад его импульсивно заказал, а вот сейчас только заметил что там 6050 гиря, соответственно подключение по i2c, или есть надежда на СПИ? Есть ли способ проверить?
скачал по новой и прошил. всё заработало. пойду пробовать.
Нет, в 2.7.1 Нужно писать: set fast_pwm_protocol = ONESHOT125
проверил в GLI уже всё включено.
Зачищать МГТФ надо зажигалкой. Неэстетично, но эффективно.
Мало того, что не эстетично, так еще и вредно. МГТФ при этом выделяет фосген, слыхали о такой няке?
Можно делать только под хорошей вытяжкой, а лучше все же приноровиться ножичком: аккуратно и безопасно 😃
К сожалению этот вопрос не ко мне, а к разработчикам платы sprf3. Почему они использовали MPU6050 вместо MPU6000? Наверно из-за того, что i2c шина требует всего 2 пина, когда SPI требует минимум 3, а реально и того больше. А SPI шина в разы быстрее шины i2c. Вот поэтому и приходится контроллеру дольше “ждать” данных с гироскопа по i2c.
Хотя в ветке про RaceFlight RS2K говорил, что знает как считывать i2c на скорости 8кгц, но на практике пока никто ещё этого не сделал (вроде как нет смысла, всё равно данные не смогут поступать с такой скоростью по i2c).
Павел
Шина I2C большинства акселерометров и гироскопов работает на частоте 100 КГц, примерно 0.01мкс. А у Вас время прогона программы 500мс. Даже если по прерываниям реализовать опрос , то скорости этой шины с головой.
400kHz Fast Mode I2C for communicating with all registers
1MHz SPI serial interface for communicating with all registers (MPU-6000 only)
20MHz SPI serial interface for reading sensor and interrupt registers (MPU-6000 only)
SPI - на “медленных” контроллерах пока понты. ИМХО.
Шина I2C большинства акселерометров и гироскопов работает на частоте 100 КГц
Я не помню точно даташит mpu6050, давно читал. Но вряд ли там данные считываются без команды от мк - “читаем данные с такого то регистра”, причем регистров наверняка два. Плюс за один такт можно передать 1 бит команды или данных насколько я понимаю, спецификацию i2c тоже давно читал ))
проверил в GLI уже всё включено.
Вы меня извините, может вы опечатались. Не GLI, а CLI - сокращение от Command Line Interface (интерфейс командной строки). Ну просто очень глаз режет.
Шина I2C большинства акселерометров и гироскопов работает на частоте 100 КГц, примерно 0.01мкс. А у Вас время прогона программы 500мс. Даже если по прерываниям реализовать опрос , то скорости этой шины с головой.
400kHz Fast Mode I2C for communicating with all registers
1MHz SPI serial interface for communicating with all registers (MPU-6000 only)
20MHz SPI serial interface for reading sensor and interrupt registers (MPU-6000 only)
SPI - на “медленных” контроллерах пока понты. ИМХО.
Посмотрел по даташиту на MPU-6000 и MPU-6050 www.cdiweb.com/…/MPU-6050_DataSheet_V3 4.pdf#page1… выходит что интерфейс I2C в MPU-6050 тактовая частота 400кГц и время данных 0,9 микросекунд, а у интерфейса SPI в MPU-6000 - 1МГц и длина данных 0,1 микросекунда. Т.е. I2C где-то в 9 раз медленнее, если все правильно понял. Я так понял что дело не в шине а в том что процессор не может быстро работать с шиной I2C. программно долго обрабатывает считывание, а так он не только этим занимается, то приходится жертвовать частотой считывания данных из MPU.
Так что шина I2C должно хватать за глаза. Но наверное в процессоре нужен аппаратный контролер шины, а не заниматься программной обработкой. Надо будет посмотреть по исходники как работа идёт с MPU-6050. Может я много ещё не знаю.
Посмотрел по даташиту на MPU-6000 и MPU-6050 www.cdiweb.com/…/MPU-6050_DataSheet_V3 4.pdf#page1… выходит что интерфейс I2C в MPU-6050 тактовая частота 400кГц и время данных 0,9 микросекунд, а у интерфейса SPI в MPU-6000 - 1МГц и длина данных 0,1 микросекунда. Т.е. I2C где-то в 9 раз медленнее, если все правильно понял. Я так понял что дело не в шине а в том что процессор не может быстро работать с шиной I2C. программно долго обрабатывает считывание, а так он не только этим занимается, то приходится жертвовать частотой считывания данных из MPU.
Так что шина I2C должно хватать за глаза. Но наверное в процессоре нужен аппаратный контролер шины, а не заниматься программной обработкой. Надо будет посмотреть по исходники как работа идёт с MPU-6050. Может я много ещё не знаю.[/QUOTE]
Все верно, еще фильтрация , отработка ПИД-регулятора…Так , что я не думаю , что I2C не узкое место. Тем более , что контроллер будет делать с этой информацией, если использовать ее не может ввиду того, что даже раскрутить пропеллер мгновенно не может.Да и положение квадрика не так уж быстро меняется.
Все верно, еще фильтрация , отработка ПИД-регулятора…Так , что я не думаю , что I2C не узкое место.
А ещё входной PPM или SBUS расшифровать. Короче у процессора работы хватает.