flybrain. передатчик + приемник + автопилот. powered by stm32
Не лень такие посты писать?
Алекс, не будьте так жестоки!😦 На улице такой дубак!😵 Бедный, полумертвый тролль… Ему же много не надо. Он отогреется и уйдет. 😃
Я вон синичек тоже жалею… Подкидываю им семечек. А подзадержусь если, так они в окошко долбят, мол ты чё жаба, в теплом доме и полстакана семечек бедным синицам не найдешь?
Барометр вроде заработал. Высоту показывает правильно, значит ласты не склеил, когда я его неправильно запаял. Несколько быстрых тестов показывают, что изменение на 0,5м дает расчет по барометру в районе 40 см +/- еще 10см. Расчеты сделал полностью во float значениях. Повторные измерения через несколько минут в той же точке высоты, далеко уходят от предыдущих, где-то +/- 2м. Но если рассматривать значения в пределах нескольких секунд, то дрейф совсем не большой. Температура конечно никак не соответствует окружающей среде, оно меряет что-то там внутри у себя от балды, для того чтобы ввести коррекцию в полином расчета давления. Результаты конечно еще очень сырые и предварительные. Надо будет накапливать и усреднять, а может и фильтрануть каким-нибудь фильтром. Ну это потом, главное, что барометр работает и исправен и на коротких временных интервалах все правдоподобно, а далее математика покажет. Осталось вобщем-то компас только запустить. В ближайшее время займусь эти делом.
Вопрос к знатокам I2C.
Короче задрала проблема, когда slave закушивает шину и SDA давит в 0. Случается спонтанно. Иной раз минут через 5 после запуска, а иногда часами можно ждать и так не вылезает. Судя по логам внутрисхемного отладчика такое происходит, когда слэйв не распознал в цепочке чтения NACK флаг, либо STOP. Соответственно на следующей попытке запустить I2C транзакцию, микроконтроллер валится с ошибкой Ardbitration Lost. И далее уже ничего не помогает. Slave держит SDA в нуле и все тут, только питание пересбрасывать. Вопрос, какие предложения будут по борьбе с этим делом? Сейчас акромя сброса питания всех слэйв устройств вижу только один выход - переключить ножку SCL контроллера в режим выхода с открытым стоком и тактировать до тех пор пока слэйв не отпустит SDA. Как отпустит, слать STOP. Затем еще пару импульсов на SCL для профилактики и мониторинга SDA. Если SDA не уйдет в ноль, значит вроде как отпустило. Какие еще варианты?
задрала проблема, когда slave закушивает шину и SDA давит в 0. Случается спонтанно. Иной раз минут через 5 после запуска, а иногда часами можно ждать и так не вылезает.
С одним и тем-же слейвом вылазит или с любым? Скорость уменьшать не пробывали (если это возможно)?
Или аппаратно шаманить: подвеску менять или 100 Ом на вход проца?
вижу только один выход - переключить ножку SCL контроллера в режим выхода с открытым стоком и тактировать до тех пор пока слэйв не отпустит SDA.
Да. Или переходить к полностью программному формирования I2C. Сам всегда генерил И2Ц программно (не на STMке), поэтому подобных затыков никогда не видел.
С одним и тем-же слейвом вылазит или с любым?
Пока вроде только с гирой такая шняга. Аксель не выказывает такого поведения.
Скорость уменьшать не пробывали (если это возможно)?
Уменьшал до 100кГц. Проявляется существенно меньше. Ждать глюка приходится часами, но он все равно как-нибудь вылезет.
Подвеску не менял. Сейчас стоит 4,7кОм. Наверно попробую увеличить до 10к. Но слабо верится, что в этом проблема.
А 100ом резюк чем поможет? Только тау цепи поднимет, вообще все переглючится.
Есть у меня еще мысль, что где-то в коде START лезет, еще до того как STOP отработал. Буду пытаться локализовать через глобальный запрет прерываний и критические секции. Если таковой мой косяк имеет место, то я его отловлю.
Я, кстати на Меге32 строил синтезаторы частоты на TSA5511. Там I2C. Потеря арбитража вылезала и там иногда. Но там обращение происходит только по нажатой кнопке переключения частоты, а здесь 400 раз в секунду.
Ну ладно, погружаюсь дальше в отлавливание глюков. Пока все датчики не заработают как часы, двигаться дальше не буду.
Пока вроде только с гирой такая шняга.
Может быть конкретный экземпляр мудрит? Попробуйте исключить такие подозрения.
Вроде встречал на форуме людей победивших глюки в I2C для STM. Но кодом не поделились 😉) Если победите - не уподобляйтесь им !
победивших глюки в 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 делаю.
не покажете?
Покажу. Как раз пишу софтину, чтобы два уровня горизонта на экране монитора сравнить. Если сегодня закончу, дома засниму видео ролик, покажу.
Если сегодня закончу, дома засниму видео ролик, покажу.
Жду посмотреть.