flybrain. передатчик + приемник + автопилот. powered by stm32
победивших глюки в I2C для STM
Я не думаю, что это глюк STM. Это скорее всего мои тараканы. Вчера убрал все прерывания и тупо по сигналу готовности читал данные с гиры. После чтения давал гарантированную паузу в 10 млс чтобы уж точно состояние STOP было принято. Глюки вроде перестал ловить. Ждал несколько часов, но все в порядке. Так что, скорее всего это мои кривые ручки 😃
Ну пусть не глюк будет, пусть код неустойчивый… Теперь источник помех к линииям притыкать и смотреть - не зависнет ли рекомендовалось 😃
Ну пусть не глюк будет, пусть код неустойчивый…
Нет, это не наш стиль 😉
короче небольшой отчетец.
Падения шины I2C имеют место таки быть. Иногда может раза 2 в минуту глукнуть. А иногда час лежит в тесте и хоть ты тресни, все как часы работает. А самое поганое, что отладчиком отловить такое почти нереально. Запустишь и сидишь ждешь когда оно там разродится…
Сейчас в тестах я непрерывно опрашиваю гиру с частотой 400Hz, Аксель с частотой 50Hz, компас с частотой 15Hz, Давление с вычислением частоты примерно 25Hz, термометр пока даже не пробовал, он пока неактуален.
Выяснены интересные “квази” зависимости глюка I2C:
-
дома этот глюк происходит существенно реже, чем на компе на работе. Здесь я грешу только на питание через USB. Однако контроллер точно не пересбрасывается, и устройства тоже не пересбрасываются, это совершенно точно. Может какая-то помеха рушит I2C. Попробую приподнять и улучшить на плате что-нибудь на эту тему. Может вообще прямо реально запитаю от независимого аккумулятора
-
Сейчас все работает на частоте 400кГц. В STM можно регулировать Duty Cycle , это длительность high и low уровня на шине Ш2С. Можно отношение 1:2 поставить , а можно 9:16. Так вот если я ставлю 9:16 падения раз 5 чаще чем когда я ставлю 1:2. Причем я считал длительности в nsec, оно при любом раскладе в ДШ укладывается.
-
Чаще всего жопа наступает, когда я даю повторный рестарт для чтения байтов. И судя по всему устройство пропускает сигнал рестарта. пробовал STOP затем START , тогда оно пропускает STOP. Это я вообще понимать отказываюсь.
Короче без логического анализатора хрен поймешь, что там происходит. Когда будет не лень, подключу отдельную STMку на эту шину и запишу физику сигналов прямо в риал тайме.
Из хорошего. Я весь мозг сломал при написании алгоритма, как восстанавливать на лету зависшую I2C шину. Результат - вот уже лежит несколько часов, работает, пишет что 5 раз свалилось и восстанавливалось, но все продолжает работать. Гыыы…
Теперь я понимаю, почему
Вроде встречал на форуме людей победивших глюки в I2C для STM. Но кодом не поделились
Я этих людей теперь хорошо понимаю.
Короче результат полностью положительный, тьфу три раза… Теперь, пожалуй, пофиг на сбои I2C, Главное, что в результате имеем непрерывно работающие датчики и само восстанавливающуюся шину I2C в случае чего.
Из печального то, что изначально красивый структурированный по классам код, пока я искал лекарство против I2C, превратился, в кусок непотребного дерьма. Придется это дело на выходных все в порядок приводить и оптимизировать.
И еще, меня печалит странный сдвиг нуля в показаниях магнитометра. Реально оси отдают от +20 до -600 примерно, и где-то между этими показаниями прячется ноль. Никак такого не ожидал. У гиры и акселя такого не наблюдаю. И еще раз в пару секунд с магнитометра может проскакивает значение ну нереальное просто. Например X= -15325 вдруг ни с того ни с сего. Откуда такое на шкале в 2 Гауса? У этого прибора вся шкала от -1024 до + 1024 для 2ух гаусов. Такое ощущение, что магнитная перегрузка. Но в принципе радует то, что такие вещи не чаще 1 раза в сек, и они вообщем-то легко отбрасываются.
Например X= -15325 вдруг ни с того ни с сего. Откуда такое на шкале в 2 Гауса? У этого прибора вся шкала от -1024 до + 1024 для 2ух гаусов.
боюсь вмешиваться, не такой я и программист, но - 15325(10) это 1100010000100011(2), очень симметрично. и если разделить ее по центру (не скажу пополам) то в получится 100011(2) что равно 35(10). а какие другие значения обычно бывают?
принципе радует то, что такие вещи не чаще 1 раза в сек
не вижу повода радоваться в принципе, пока не ясна причина и как далеко она может иметь свое действие
а какие другие значения обычно бывают?
разные, главное, что они переваливают за мин-макс диапазон, и явно не достоверны в этот момент.
пока не ясна причина и как далеко она может иметь свое действие
да, пока не ясна, но это надо визуализацию вектора сделать, иначе там вообще ничего не понятно. Ноль далеко смещен и я не понимаю на вскидку, правильно оно кажет на север или нет. Но оно что-то кажет и примерно, если плату положить, засечь, потом покрутить и опять так же положить, то значения возвращаются к исходным. То есть, явно что-то примерно правильно работает.
Есть радостное известие. Глюк I2C побежден. проблема была не в софте, а в харде. Питание через диод шотки не канает. На нем падает 0,3 В. А если еще USB отдает не 5В, а 4,7В, то вообще наступает трындец. Короче диод убрал, питане стабильное 3,3В на всех устройствах. Уже 6 часов работает сегодня без перерыва с замкнутым диодом, ни разу I2C не глюкнула. Все работает как часы.
вот такие пироги. 😉 но припарку программную для восстановления I2C на лету все равно в код добавлю на всякий случай.
P.S. Из Китая едет передатчик с видеокамерой NTSC. Буду теперь OSD готовить. Кстати у народа в основном какие камеры? PAL или NTSC ???
Питание через диод шотки не канает. На нем падает 0,3 В. А если еще USB отдает не 5В, а 4,7В, то вообще наступает трындец.
Странно. Сам проц и перферия все равно 3.3 В кушает. Хорошая LDO-шка должна от 4 В работать. Может все-же на электролитах слишком съэкономили?
Кстати у народа в основном какие камеры? PAL или NTSC ???
PAL всречается намного чаще. Но все правильные OSD автоматически поддерживают оба стандарта.
Может все-же на электролитах слишком съэкономили?
На LDO падает 0,9.
Нет. дело не в электролитах. Достаточно замкнуть диод на моей схеме. 3В недостаточно, нужно 3,3В. Тогда зависоны исчезают. В результате теперь я имею проблему как сохранить универсальное питание, чтобы и от USB и от борта работало. Либо питание до диода поднимать на 0.3, но таких готовых стабилизаторов нет, либо… х.з. Короче, предложения есть так чтобы тотально печатку не переделывать? Была мысль вместо диода воткунуть резюк ом на 5 чтобы выровнять потенциал питания, если одновременно и борт включен и USB воткнуто. Но чего-то мне это кажется кривовато.
Но все правильные OSD автоматически поддерживают оба стандарта
Блин, ну у меня PAL только с фотика есть. Или придется старый VHS видик реанимировать для тестов, не знаю жив ли зараза.
Достаточно замкнуть диод на моей схеме. 3В недостаточно, нужно 3,3В.
Как-же у других работает? У copterControl, например, тоже питание от USB. До 4.0 В на входном разъеме работу гарантируют.
В качестве LDO там LP2985-3.3 catalog.gaw.ru/index.php?page=component_detail&id=…
ну у меня PAL только с фотика есть
Сделайте пока для NTSC, все равно ведь еще не серийное изделие. 😃
. Кстати у народа в основном какие камеры? PAL или NTSC ???
Ну пал вроде как.
Я тут в Нижнем буду. Вы АлексСнег пива пьйоте?
У copterControl, например, тоже питание от USB. До 4.0 В на входном разъеме работу гарантируют.
Я просто констатирую факт. Может L3G4200D проблемы испытывает на границе 3В. Ведь в принципе именно она вешает шину. Процу по фиг, акселю по фиг, барометру так же по фиг. Ну вот есть факт неоспоримый. Я конечно попробую еще запендюрить емкостей после диода побольше, но это позже. слава Богу все сейчас работает железобетонно, я на ночь оставлял. Думаю это достаточный тест по надежности. Можно пока дальше двигаться.
У LP2985-3.3 падение 0,3 вольта, а у той, что я поставил, падение 0,9. Ну ладно, это все мелочевка. Главное понятно в чем проблема. Никто ведь не говорил, что прототип без недостатков. В серийной печатке сделаем работу над ошибками.
Вы АлексСнег пива пьйоте
Пьйом. тока надо заранее предупредить, а то я за рулем не пью 😃 Руль надо заранее дома оставить.
Небольшой отчетец.
Портировал код DCM алгоритма от МегаПирата на свою платформу. Поигрался, в принципе работает. Вижу недостатки. Задал вопросы в теме Олега. Ответит - хорошо, не ответит - ничего страшного. Пока буду реализовывать EKF, чтобы в живую сравнить два алгоритма. А потом еще третий добавлю с кватернионами. Если вычислительной мощи хватит, то все три алгоритма оставлю, буду на ходу выбирать какой правду показывает, по тому и корректироваться в полете. Но даже сейчас Roll и Pitch вполне себе хорошо правду показывают, если без фанатичных перегрузок платформу механически трясти. Если прилагать усилия сбить горизонт, то оно конечно сбивается - соответствующие вопросы задал в другой теме.
PS: проблема I2C за все это время так ни разу и не выплывала. Можно считать этот глюк окончательно побежденным.
Пока буду реализовывать EKF, чтобы
Готовый EKF для Кортекса можно взять у OpenPilotа. Советую так-же посмотреть Мардж.
вот от сюда что ли?
link
Я не пойму что там за язык. matlb что ли?
В любом случае, у меня уже заработал EKF. Ща исследовать буду.
вот от сюда что ли? link
Нет, я имел в виду Си-шные исходники. Открытые и скачиваемые через Git: wiki.openpilot.org/display/…/Building+on+Windows
В любом случае, у меня уже заработал EKF
Тогда - удачи!
Но даже сейчас Roll и Pitch вполне себе хорошо правду показывают, если без фанатичных перегрузок платформу механически трясти
не покажете?
Нет, я имел в виду Си-шные исходники.
Ой! Как там все мутно 😦
Реализация на кватернионах с непонятной функцией предсказания. Я пока кватернионы не реализовал, сейчас чисто на углах Эйлера работает, и работает отменно. Может потом этим займусь, сейчас визуализацию сравнения EKF и DCM делаю.
не покажете?
Покажу. Как раз пишу софтину, чтобы два уровня горизонта на экране монитора сравнить. Если сегодня закончу, дома засниму видео ролик, покажу.
Если сегодня закончу, дома засниму видео ролик, покажу.
Жду посмотреть.
вот первое видео моего EKF работает только гира и только аксель. Время одного цикла EKF занимает примерно 50мкс Вот для сравнения алгоритм DCM
Любопытно. Не ожидал такой разницы от ЕКF, без комплексирования с GPS/компас.
Есть еще алгоритм Мардж: varesano.net/…/initial-implementation-9-domdof-mar…
Предлагаю определиться с терминологией. “алгоритм DCM” - что под этим подразумевается? DCM в общем виде, как и кватернионы - описание поворота. Разницы по принципу применения- нет, и тот и другой метод описывает поворот, только вычислительные затраты немного отличаются, и точность при одинаковой разрядности, но в нашем случае точности метода не принципиальна- неидеальность датчиков сильно “перевешивает”.
Следует , вероятно говорить о методе коррекции гироскопов.
В случае " EKF" также, вероятно, имеет место какое- либо описание поворота на основе интегрирования угловых скоростей, и какой-то метод коррекции, адаптивный в зависимости от величины угловых скоростей и ускорений и предыдущего состояния системы.
“Алгоритм DCM” также имеет метод описания поворота ( очевидно, DCM) и метод коррекции. Обычно в качестве корректирующего метода применяют ПИ регулятор.
Опишите, что именно вы используете в разных случаях (если представляете, как работают примененные вами алгоритмы). Тогда можно что- либо посоветовать, да и остальным участникам будет , надеюсь, понятнее.
По поведению платформы в случае “алгоритма DCM” общем виде видно, что при околонулевых угловых скоростях имеет место колебательный затухающий процесс. То есть система коррекции имеет колебательный характер (причем декремент затухания слишком мал), а желательно иметь апериодический. Также кажется, что при движении вправо- влево платы происходит “зашкаливание” акселерометров.