Перейти к содержанию
    

гироскоп mpu6050 и i2c lockup- виснет i2c

mpu6050 (6 осевой гироскоп) на гиростабилизированной платформе - все работает как часы, пока не подключен мотор. Когда подключен мотор - виснет i2c, может сразу, может через минуту, ну через 10 минут точно. Симптоматика - clk встает в 1, sda в 0, и так зависает или через некоторое время передает шум. Дело, видимо, в 6050 - инет полон жалоб на 6050 при любых контроллерах, от ардуино до эдисонов. Сижу гадаю - или забить на mpu6050 и взять что еще, но у 6050 бортовой вычислитель, что экономит кучу ресурсов мк, а других я такой фичи не видел. Какая- то наводка, это точно, при одних моторах виснет сразу, при других - через минуту, обвешивал кондерами как дикобраза, проверял перепроверял signal ground? делал даже полную опторазвязку, причем отдельные блоки питания для моторов и для мк с imu - все точно также.

Помогите кто чем может.

 

Вот хороший пример плача Ярославны, показатель что не я один такой :

 

I've tried two devices (though both from the same manufacturer/class of devices, MPU6050 and MPU9250), I've tried all the different I²C speed settings, I've tried running the polling loop at a lower frequency (slowing it down with usleep()), I've tried to not do any setup or self-testing or calibration and just getting the values, I've tried both I²C buses, I've tried a couple of different level converters... Not sure what else I can tell you; it's my experience that it doesn't really matter what you do or what steps are taken---the I²C bus will eventually freeze on 2.1, at least with the devices I've tried and polling in a loop the way I am.

I threw weeks of testing on this with a bunch of different software approaches (from as barebones as possible to thoroughly scanning the datasheets to configure each register that seemed relevant to optimise the chances of things working) and hardware wiring/configurations (hence the different level converters and plain resistive voltage dividers, two different IMUs that do the same thing, two different Edisons on two different mini breakout boards, different breadboards in case of dodgy internals to eventually soldering things thoroughly on prototype boards) and it just didn't matter. Turns out the problem was seemingly in the Edison kernel/drivers themselves. Ugh.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если делали разные изолирванные блоки питания для двигателя и MCU и все равно зависало, то это просто наводки.

Закрывайте MCU в металлическую коробку, а на все провода выходящие из нее, включая питание фильтры.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если делали разные изолирванные блоки питания для двигателя и MCU и все равно зависало, то это просто наводки.

Закрывайте MCU в металлическую коробку, а на все провода выходящие из нее, включая питание фильтры.

это я держу как крайний случай, конечно. Заварить в миллиметровую сталь, это я могу.

Больное место в моем случае- i2c. Часы по i2c , например, на том же контроллере не сбоят, а mpu6050 встает, когда под ним включаю самый дешевый мотор. Самый дешевый мотор в моем случае - и самый помехоизлучающий.

На консерваторию посматриваю - может есть в 6050 и его клонах какой тайный регистр?

Штука очень распостраненная, может кто побеждал уже вышеозначенные грабли?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Штука очень распостраненная, может кто побеждал уже вышеозначенные грабли?

Как вариант - поставить watchdog, подцепить его на какой-нибудь сигнал исчезающий при зависании и передергивать питание, или просто передергивать по команде от центральной системы. Но в общем случае это костыли, лучше всё-таки экранировать гироскоп.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как вариант - поставить watchdog, подцепить его на какой-нибудь сигнал исчезающий при зависании и передергивать питание, или просто передергивать по команде от центральной системы. Но в общем случае это костыли, лучше всё-таки экранировать гироскоп.

это понятно, спасибо.

Специфика же в том, что любая периферия (часы, память , да что угодно) по i2c работает сутками - кроме mpu6050, который при нахождении вблизи одного из моторов (самого излучающего, видимо) завешивает i2c. Так что у меня осталось два выхода - сделать на другом гироскопе (что геморно, ибо придется всю математику кватернионов на мк писать), либо решить -таки проблему этого зловредного модуля. У меня уж и провода по 3 мм от мк до imu, и все что можно - вешает, собака.

По передергиванию питания - тут достаточно передернуть шину clk, но это будет низкий класс, костыль. Гироскоп он тем и хорошо, что каждые 10 мс дает отсчет, если поползет периодичность, то нужно будет пид корректировать и прочие тонкости поползут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Симптоматика - clk встает в 1, sda в 0, и так зависает
Если я правильно понял описание, MPU6050 является I2C-slave. Состояние SCL=1, SDA=0 вполне законно для I2C, копайте программу вашего мастера - именно он должен продолжить дергать SCL.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...