Создание собственной системы стабилизации
Это слово такое магическое…
сейчас уже AEKF “модно” 😃
видел несколько работ… вот одна из свежих researchgate.net/…/260542040_A_Real-Time_Adaptive_…
алгоритм тяжелее “обычного” EKF примерно в два раза (см.TABLE III)… на STM32F4 за 4.5мс просчитывается… от тока сорцов там нет )))
но не надёжно. К тому же надо тогда сразу с пайкой заказывать
согласен, что ненадежно, а запаять не проблема, лижбы трафарет был…
сейчас уже AEKF “модно”
Привеет! Как погода в КанадЕ?
Всего одна буква, а уже в два раза тяжелее… В первую очередь надо определиться, что нужен АДАПТИВНЫЙ фильтр, а не что-то где кучу параметров нужно подбирать с шаманским бубном )))
от тока сорцов там нет
И правильно, а то очередной аффтар “с нуля” все напишет “почитав диссеры” и будет потом возмущатся, мол лагает.
Сколько стоит регуль?
Не могу сказать. Мне он вышел по цене деталей. Но ни как не та цена, которую хотят за регули с КАН. Даже не могу сказать почему они столько стоят. К тому же везде закрытый протокол. Я и Андрей пошли другим путем, но всему свое время.
А что это будет?
USB->CAN, надо чем-то шину мониторить, баги отлавливать. Ну и прицепом вывели USART/I2C/SPI.
Шикарная идея для мелких - счетверенный регуль на КАНе со встроенным БЕКом, но вроде как в в одном СТМ32 всего 2 таймера с аппартной блокировкой выхода (
Нужен таймер с 6ю PWM выходами, а таких 1 на весь проц. Это уже обсуждалось. Так что нужно будет 4ре проца.
кстати… кан да кан… в физ реализации - это всего-лиш RS485 перевернутый А и В, ну и более скоростной. на физ уровне любые микрухи 485-го с каном на ура работают - а их найти не проблема вообще
При цене драйвера CAN в 50 центов в SOIC-8, не думаю что это хорошая идея.
вот у меня тоже, хочу imu отдельно, но со своим процем…
Я вот себе на пробу так сделал (f103+bmx055), но отказался… передавать данные между процами не понравилось,
медленно получается…
передавать данные между процами не понравилось,
медленно получается…
Почему и через что? У меня мысль процем иму посчитать всё сложить и дать прерывание на готовность данных, и забрать их процем полётника по SPI все скопом через ПДП…
а для чего делить на разные процы, чтобы если что поменять “основной”?
по SPI все скопом через ПДП
У меня свободного SPI не получилось оставить…, передавал через USART уже готовые углы в градусах, всего восемь байт, если не “задирать” скорость (для надежности) то ~2 милиСек получается… в принципе нормально…
НО нарисовалась проблема с калибровкой магнитометра: - ему надо как то передавать команду в IMU “откалиброваться” а затем “нормальный режим”… короче не всЁ так просто с этой затеей +еще плата+ дополнительные провода (которые я очень не люблю), выигрыш отдельного IMU показался мне очень сомнительным (?)… в итоге пересадил датчик к основному процу и успокоился…
чтобы если что поменять “основной”?
это одно, второе - IMU на вынос - отдельно от основного… за одно можно резервировать горячим резервированием… у меня раз тут компас сам по себе отвалился, хорошо не в полёте, а при тестах до этого коптер немного попинали, так что вообще удивительно, что мосх там цел остался…
за одно можно резервировать горячим резервированием
может есть смысл тогда все дублировать или хотя бы 2 комплекта датчиков на разные “интерфейсные шины”? а то как-то по моему не очень красиво с N кол-вом IMU со своим процом + 1 основной
И вообще я отказался от “моноплаты” в пользу “этажерки”:
будет еще и OSD четвертым этажом, полный фарш… (50х50),
на одной плате не реально такое ЛУТом сделать.
Нужен таймер с 6ю PWM выходами, а таких 1 на весь проц. Это уже обсуждалось. Так что нужно будет 4ре проца.
Я 2 таймера насчитал.
Даже не могу сказать почему они столько стоят.
Вот это и мешает широкому внедрению.
передавать данные между процами не понравилось,
медленно получается…
Нормально получается, расчеты датчиков в кватернион прямо на месте, остальное в жирной и тупой (103го хватит) многоножке.
У меня свободного SPI не получилось оставить…, передавал через USART уже готовые углы в градусах, всего восемь байт, если не “задирать” скорость (для надежности) то ~2 милиСек получается… в принципе нормально…
НО нарисовалась проблема с калибровкой магнитометра: - ему надо как то передавать команду в IMU “откалиброваться” а затем “нормальный режим”… короче не всЁ так просто с этой затеей +еще плата+ дополнительные провода (которые я очень не люблю), выигрыш отдельного IMU показался мне очень сомнительным (?)… в итоге пересадил датчик к основному процу и успокоился…
УАРТ не то, нужен синхронный скоростной интерфейс. Типа так
У меня мысль процем иму посчитать всё сложить и дать прерывание на готовность данных, и забрать их процем полётника по SPI все скопом через ПДП…
По сути получишь данные прямо из ячеек памяти на основной плате.
2 комплекта датчиков на разные “интерфейсные шины”
Imu поддерживает Usart, SPI, CAN, i2c в той же F4BY есть все эти интерфейсы наружу - проблемы не вижу…
Я 2 таймера насчитал.
дык нада лап побольше )))
Вообще кончено с точки зрения программиста (калман-программиста;) ) два проца это хорошо, тяжкую ИНС в маленький, интерфейсы в большой. Но вот мне кажется для наших приложений и мозгов и надёжности одного проца хватает выше головы.
за одно можно резервировать горячим резервированием… у меня раз тут компас сам по себе отвалился, хорошо не в полёте, а при тестах до этого коптер немного попинали, так что вообще удивительно, что мосх там цел остался…
Для наших применений считаю дикой блажью. Непропай питалова обнуляет все хитроумные алгоритмы резервирования.
дык нада лап побольше )))
Это зачем?
тут тенденции именно к выносному imu - модно нынче (А2 например), а где смысл кучу проводов тянуть от просто-датчиков? нужен какой-то общий интерфейс - раз, можно посчитать сразу - два…
тут тенденции именно к выносному imu - модно нынче (А2 например)
Ну до А2 я никогда не дорасту… финансово ))))
а где смысл кучу проводов тянуть от просто-датчиков? нужен какой-то общий интерфейс - раз, можно посчитать сразу - два…
тут есть над чем подумать, но вот та же МПУшка-комбайн даст все датчики кроме барика по 6-проводам (это вместе с питанием), барик можно рядом с процом. Внешнему процу тоже надо 6 проводов, только плата будет больше и тяжелей (а основная будет такой же), и жрать лестричество проц будет.
Плюс получается только в программировании. ятд.
ты забыл про AIO и прочие поделки, которым можно подарить вторую жизнь, сгрузив всю “тяжелую” математику в IMU )))
вместе с питанием 8 - mosi, miso, clk, cs, int, +, -, а если ещё баро -9-й провод, и это “сырые” данные…
ты не переживай, мелкоплата с полным фаршем будет )))
ты забыл про AIO и прочие поделки, которым можно подарить вторую жизнь, сгрузив всю “тяжелую” математику в IMU )))
Не вижу смысла тянуть их за хвост, т.к. сам по себе сверхнадежный датчик положения не придаст этим поделкам нового функционала.
вместе с питанием 8 - mosi, miso, clk, cs, int, +, -, а если ещё баро -9-й провод, и это “сырые” данные…
Да, про сигнал готовности я забыл, но где ты 8 насчитал? +5В (+3.3), 3 шт -SPI, + CS, +INT, земля: итого 7.
ты не переживай, мелкоплата с полным фаршем будет )))
Да я не переживаю )) под мелкий надо простую плату с мелкими разъемами. Про многоплатный я так, фантазирую )
земля: итого 7
ну да))
с барометром 8, а если посмотреть на тот же А2, тогда can - 4…
так же можно и в одной коробке с полётником на супер-пуппер секретном подвесе из двухстороннего скотча, запакованную в мю-метал (достаточно люминия:) ) и с подогревом (постоянная температура - модуль Пелье)…
можно продолжать:). Чёт я уже нафантазировал))) но эти мысли у многих ходят - почему их не собрать в кучу?
Не вижу смысла тянуть их за хвост
зато знаешь их сколько ))) и использовать их как шимовыдаватель - светодиодоморгатель - самое то )))
тут тенденции именно к выносному imu - модно нынче
Несомненно, есть в этой тенденции свои плюсы, например легкая заменяемость на более совершенную модель, да и сточки зрения домашнего изготовления, всегда легче отлаживать и доводить “до ума” модульные поделки…
(а то - не понравилось что то в одной части - переделывать всё заново…), к тому же такие модули вообще могут изобретать разные люди, надо только о ЕДИНОМ протоколе обмена договориться…
К минусам отнесу именно необходимость создания ЭТОГО двустороннего протокола обмена, что несколько усложняет общую задачу…
народ тут вот что по 9250
Auxiliary master I
2
C bus for reading data from external sensors (e.g. pressure sensor)
блин, а возмёт ли оно ms5611? в свои регистры - может - фиг, там 24 бита если не ошибаюсь… хотя там 24 свободных регистра для внешних устройств - надо пробовать…
MPU9250_EXT_SENS_DATA_00 0x49
MPU9250_EXT_SENS_DATA_01 0x4A
MPU9250_EXT_SENS_DATA_02 0x4B
MPU9250_EXT_SENS_DATA_03 0x4C
MPU9250_EXT_SENS_DATA_04 0x4D
MPU9250_EXT_SENS_DATA_05 0x4E
MPU9250_EXT_SENS_DATA_06 0x4F
MPU9250_EXT_SENS_DATA_07 0x50
MPU9250_EXT_SENS_DATA_08 0x51
MPU9250_EXT_SENS_DATA_09 0x52
MPU9250_EXT_SENS_DATA_10 0x53
MPU9250_EXT_SENS_DATA_11 0x54
MPU9250_EXT_SENS_DATA_12 0x55
MPU9250_EXT_SENS_DATA_13 0x56
MPU9250_EXT_SENS_DATA_14 0x57
MPU9250_EXT_SENS_DATA_15 0x58
MPU9250_EXT_SENS_DATA_16 0x59
MPU9250_EXT_SENS_DATA_17 0x5A
MPU9250_EXT_SENS_DATA_18 0x5B
MPU9250_EXT_SENS_DATA_19 0x5C
MPU9250_EXT_SENS_DATA_20 0x5D
MPU9250_EXT_SENS_DATA_21 0x5E
MPU9250_EXT_SENS_DATA_22 0x5F
MPU9250_EXT_SENS_DATA_23 0x60
короче всё придумано до нас 😦
SmartIMU
STM32F401 - 48 лап, FPU, амнистия, ранняя пенсия, харчи халявные…
MPU9250 - SPI
MS5611 - SPI
github.com/Hom-Wang/SmartIMU
можно ставить на квадрик - 4 выхода шим точно есть…
там герберы есть, так что если кто-то захочет повторить - легко…
CAN - нет…