Создание собственной системы стабилизации
кстати… кан да кан… в физ реализации - это всего-лиш RS485 перевернутый А и В, ну и более скоростной. на физ уровне любые микрухи 485-го с каном на ура работают - а их найти не проблема вообще
Ога, польщен.
😉
Где есть?
Я имел ввиду что единственная ресурсоемкая задача для которой нужен FPU это какой-нибудь большой Калман.
За фриртос респект. Однако код местами кажется очень знакомым. Ну и ладно.
Да, и еще, чем обусловлен выбор пик32? Неужто он сделает стм32ф4?
Это сложилось исторически. Делали с коллегой мелкий модуль на ARM Cortex M3 Stellaris www.oshec.org/projects/ucpumod-v1/wiki потратили на него кучу времени и денег, а потом внезапно выясняется что проц снимают с производства хотя ему от силы 3 года. На форуме TI был эпичнейший срач по этому поводу. Поэтому стал смотреть в сторону микроконтроллерных фирм которые выпускают свои МК оооочень длительное время. А тут еще платку на попробовать подарили на этом проце, вот и начал.
Надо подумать как это в 64ноги втиснуть.
надо подумать куда можно зайти в своих изысканиях: UFBGA169 - ultra thin fine pitch ball grid array 7 x 7 mm, 0.6 mm
корпус как 64-х лапый, а лап 169, но плата минимум 6 слоёв 😦
корпус как 64-х лапый, а лап 169, но плата минимум 6 слоёв
Это заманчиво, но не надёжно. К тому же надо тогда сразу с пайкой заказывать
Это слово такое магическое…
сейчас уже 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-й провод, и это “сырые” данные…
ты не переживай, мелкоплата с полным фаршем будет )))