Beaglebone Black - ¿El motor de CC hace que el ADC se cuelgue?

Estoy trabajando en un proyecto de frenado regenerativo con un motor de corriente continua. Mi Beaglebone Black impulsa un pequeño motor de CC con un controlador de motor TB6612FNG de Sparkfun ( hoja de datos ):

Esquema del controlador de motor BBB

Todo funciona bien, excepto que, a veces, cuando conduzco el motor de un lado a otro y trato de leer un canal ADC, mi programa se cuelga (ni siquiera puedo Ctrl-Z) y dos minutos más tarde obtengo un seguimiento de la pila del módulo del núcleo del núcleo dmesg:

[  840.290177] INFO: task drive_motor:656 blocked for more than 120 seconds.
[  840.297231]       Tainted: G           O    4.1.12-bone-rt-r16 #3
[  840.312263] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.322102] drive_motor    D c065b9b7     0   656    606 0x00000001
[  840.328856] [<c065b9b7>] (__schedule) from [<c065bc11>] (schedule+0x35/0x90)
[  840.340345] [<c065bc11>] (schedule) from [<bf86416f>] (am335x_tsc_se_set_once+0x8e/0xcc [ti_am335x_tscadc])
[  840.352180] [<bf86416f>] (am335x_tsc_se_set_once [ti_am335x_tscadc]) from [<bf8873bb>] (tiadc_read_raw+0x86/0x118 [ti_am335x_adc])
[  840.365891] [<bf8873bb>] (tiadc_read_raw [ti_am335x_adc]) from [<bf86fa4b>] (iio_read_channel_info+0x52/0x54 [industrialio])
[  840.379287] [<bf86fa4b>] (iio_read_channel_info [industrialio]) from [<c041c3eb>] (dev_attr_show+0x13/0x34)
[  840.391418] [<c041c3eb>] (dev_attr_show) from [<c0173907>] (sysfs_kf_seq_show+0x63/0xb0)
[  840.401550] [<c0173907>] (sysfs_kf_seq_show) from [<c013d4c3>] (seq_read+0x157/0x300)
[  840.411700] [<c013d4c3>] (seq_read) from [<c0124c2d>] (__vfs_read+0x19/0x88)
[  840.420677] [<c0124c2d>] (__vfs_read) from [<c01251c1>] (vfs_read+0x55/0xf4)
[  840.429580] [<c01251c1>] (vfs_read) from [<c01258cd>] (SyS_read+0x31/0x6c)
[  840.438240] [<c01258cd>] (SyS_read) from [<c000e821>] (ret_fast_syscall+0x1/0x4c)

Puedo reproducir el problema ejecutando un programa que impulsa el motor al 100% del ciclo de trabajo e invierte la dirección cada segundo, y lee el ADC:

set pwm to 100%
while true:
   read ADC
   switch direction of motor
   sleep for 1 second

(Mi código real es C puro y usa este código C debajo de la biblioteca Adafruit BBIO Python para leer los ADC y también usa el módulo kernel PWM de Saad Ahmad ).

La resistencia de la bobina del motor es de 2,5 ohmios y lo conduzco con una batería de 6 V, por lo que la corriente de bloqueo es de 2,4 A, lo que parece estar (algo) dentro de las especificaciones del controlador del motor .

El programa no se bloquea si elimino la llamada para leer el ADC, y no se bloquea si desconecto la batería.

Significativamente, no se bloquea si conduzco el motor en un ciclo de trabajo bajo (como 20%) en lugar de un ciclo de trabajo alto (como 80% - 100%). Esto sugiere que las corrientes del motor se están abriendo paso de alguna manera en el Beaglebone y arruinando los ADC.

El programa se bloquea independientemente de si conecto tierra analógica (AGND) a la tierra del sistema Beaglebone (GND) (la línea rosa en la imagen). Cuando están desconectados, la función "máxima" de mi DMM mide un pico de 70 mV entre ellos cuando el motor cambia de dirección.

Como muestra la imagen, el terminal negativo de la batería está conectado a "GND" en el lado derecho del controlador del motor. El programa se cuelga en esta configuración. Además, el programa también se cuelga si conecto el controlador de motor del lado derecho "GND" a su lado izquierdo "GND". Mi sensación es que estos deben permanecer desconectados debido a las grandes corrientes a través de la batería.

Hay un condensador de 0,1 uF entre los terminales del motor. Mi medidor LCR de mierda dice que la inductancia del motor es de 1 mH. No he colocado ningún otro condensador en el circuito.

He disfrutado estas publicaciones muy informativas de Phil Frost , SunnyBoyNY y supercat .

Mi conjetura es que los cambios repentinos en la dirección del motor hacen que los picos de corriente excedan el límite de 3A establecido en la hoja de datos del controlador , abrumando la capacidad del controlador del motor para aislar el lado del Beaglebone del lado del motor y dejando que la corriente se filtre en el Beaglebone y arruine algunos voltaje del que dependen los ADC.

Realmente apreciaría los pensamientos de la comunidad sobre esto.

  1. ¿Es esta una conclusión razonable?
  2. ¿Se supone que el controlador del motor debe aislar el lado del motor del lado del Beaglebone?
  3. ¿Hay un controlador de motor más apropiado que debería usar?
¿Cómo mide su 3.3 V en un osciloscopio justo antes/durante este evento?
@winny, déjame ver si puedo conseguir un alcance decente y te lo haré saber. El pin Vcc del controlador está conectado al riel de 3.3V del BB. ¿Estás pensando que el exceso de corriente se está filtrando a través del pin Vcc? Pensé que era una referencia para las entradas del controlador, ¿es incorrecto?
No es realmente actual, pero el desacoplamiento insuficiente conduce a una caída de voltaje en un área de caída de tensión desconocida.
Me apuñaló el mismo problema cuando desconecté un motor paso a paso en vivo. ¡Gracias por documentar tu problema!

Respuestas (1)

Me complace informar que "solucionamos" el problema ayer colocando dos tapas de 1uF entre los terminales del motor y la carcasa del motor:

ingrese la descripción de la imagen aquí

El límite amarillo "104" (0.1uF) ya estaba allí; el motor se envía con él soldado previamente a los terminales del motor.

Esto es lo que realmente parece:

ingrese la descripción de la imagen aquí

Otro truco que usamos, aunque no solucionó el problema, fue ejecutar los dos puentes H en el TB6612FNG en paralelo, así:

ingrese la descripción de la imagen aquí

De esta manera, los puentes comparten la corriente, por lo que debería haber sido útil si hubiéramos sobrecargado el controlador.

Esta técnica fue recomendada por esta nota de aplicación:

http://www.nxp.com/files/analog/doc/app_note/AN4833.pdf

y este ejemplo, que utiliza el controlador de motor L298:

http://www.st.com/resource/en/datasheet/l298.pdf