Movimiento Motores

Construcción de Robots a Bajo Costo

Movimiento de MotoresAnálisis y Desarrollo de Rutinas de Motores

Germán López y Santiago Margnihttp://www.fing.edu.uy/~pgconrob

[email protected]

TutoresIng. Gonzalo Tejera.Ing. Carlos Martinez.

Universidad de la República Oriental del UruguayFacultad de Ingeniería

Proyecto de Grado 2003

mailto:[email protected]

http://www.fing.edu.uy/~pgconrob

Movimiento de Motores Proyecto de Grado 2003 Página 2 de 24

ResumenEl presente documento muestra cronológicamente los avances en la construcción de las rutinas de movimiento de los motores y el módulo que gestiona el desplazamiento (módulo MOTOR) del robot o Unidad en el marco del proyecto de grado: Construcción de Robots a Bajo Costo. Esto significa que existen diseños o interpretaciones que fueron cambiando y el documento las refleja según el diseño inicial, su evolución y el porque de los cambios.

El documento resume el seudo código de las rutinas de aceleración, como evolucionaron, la forma de comunicación del módulo, tipos de mensajes que recibe el módulo y sus reacciones a estos.

Página 2 de 24


Tabla de Contenido

INTRODUCCIÓN 6

DEFINICIONES 7INS 7ACEL 7VELZERO 7VELACTUAL 7VELNUEVA 7TIEMPOPASO 7TIEMPOACEL 7

SEUDOCÓDIGO 8

PROGRAMA PRINCIPAL 8RUTINAS 8DESCRIPCIÓN GENERAL 9

MOVIMIENTOS ADELANTE O ATRÁS 10

PRIMERA VERSIÓN 10

MIGRACIÓN DE PROGRAMAS EN ASSEMBLER AL LENGUAJE C 11

RAZONES PARA LLEVAR A CABO LA MIGRACIÓN 11PROBLEMAS QUE ACARREA LA MIGRACIÓN 11SOLUCIÓN AL PROBLEMA DE LOS TIEMPOS 11MÁS DE UN MOTOR 12

ESQUEMA DE FUNCIONAMIENTO 13

PROBLEMAS QUE TIENE ESTE DISEÑO 14DESCRIPCIÓN DEL PROBLEMA 14

SOLUCIÓN AL PROBLEMA Y NUEVO DISEÑO 16

NUEVAS DEFINCIONES 16VEL_ACTUAL 16DIR_ACTUAL 16VEL_NUEVA 16VEL_OBJETIVO 16DIR_OBJETIVO 16VELZERO 16DESCRIPCIÓN DEL FUNCIONAMIENTO 16SEUDOCÓDIGO 17RUTINA MODIFICADA 17

Página 3 de 24


MENSAJES 18

ELECCIÓN DEL PIC PARA EL MÓDULO MOTOR 19

TORQUE Y MOVIMIENTO 20

CANTIDAD DE PASOS DE LOS MOTORES UTILIZADOS 20UTILIZACIÓN DE DISTINTOS TORQUES 20PRIMERA FORMA DE ENERGIZAR UN MOTOR 21SEGUNDA FORMA DE ENERGIZAR UN MOTOR 21TERCERA FORMA DE ENERGIZAR UN MOTOR 21CUARTA FORMA DE ENERGIZAR UN MOTOR 22TRANSMISIÓN DE POTENCIA AL PISO 23RUEDA EN EL EJE DEL MOTOR 23POLEA DEL MOTOR A LA RUEDA 23

Bibliografía y Referencias 24

Índice de Figuras

FIGURA 1: MAPEO DE VELOCIDADES.............................................................................10FIGURA 2: SDL PARA GESTIÓN DE VELOCIDADES............................................................13FIGURA 3: COMPLEMENTO DE SDL PARA GESTIÓN DE VELOCIDADES...................................14FIGURA 4: RUEDA MONTADA EN EL EJE DEL MOTOR.........................................................23FIGURA 5: RUEDA UNIDA AL MOTOR POR UNA POLEA.......................................................23

Índice de Tablas

TABLA 1: FORMA DE ENERGIZAR DOS BOBINAS POR PASO EN SECUENCIA NORMAL.................21TABLA 2: FORMA DE ENERGIZAR LAS BOBINAS DE UN MOTOR DE PASO EN SECUENCIA TIPO WAVE

DRIVE...............................................................................................................21TABLA 3: FORMA DE ENERGIZAR LAS BOBINAS DE UN MOTOR DE PASO EN SECUENCIA TIPO MEDIO

PASO................................................................................................................21TABLA 4: INTENTO DE GENERAR UNA FORMA INTERMEDIA ENERGIZANDO UNA Y DOS BOBINAS

ALTERNADAS......................................................................................................22

Página 4 de 24


Índice de Algoritmos

ALGORITMO 1: MAIN DE CONTROL DE UN MOTOR..............................................................8ALGORITMO 2: RUTINA DE CONTOL Y PASO......................................................................8ALGORITMO 3: CONTROL Y ACTUALIZACIÓN DE VELOCIDAD:................................................8ALGORITMO 4: SETEO DE NUEVA VELOCIDAD...................................................................9ALGORITMO 5: NUEVA RUTINA CONTROLOYDOYPASO()...................................................17

Página 5 de 24


IntroducciónPara establecer la forma en que se comportan los motores se tomarán algunas consideraciones, en función de las pruebas que se hagan y los motores que se utilicen.

Desde el inicio se sabe que distintos motores tendrán distintas características, por ejemplo diferente aceleración, velocidades finales, etc. En el desarrollo del software se contemplarán estas diferencias generando un diseño y una programación para soportar el intercambio de motores con distintas prestaciones.

Para empezar, se debe determinar en que momentos se realizará cada acción. Si bien el tiempo es un continuo será necesario discretizarlo en función de un factor del tiempo de ejecución de una instrucción en el microcontrolador que lleva el control de los motores. Además hay que considerar que un cambio brusco de velocidad del motor provocaría que patine, que la propia inercia del robot venza la fuerza del motor o que el éste pierda el equilibrio, así que habrá que determinar una aceleración máxima.

Inicialmente es necesario elegir que tipo de motor se utilizará, como el proyecto tiene por principio el bajo costo, es prioritario reutilizar partes de equipos que ya no funcionan, obsoletos o en desuso, por lo tanto se intentará utilizar motores de disqueteras, discos duros, impresoras, etc. La mayoría de estos equipos tienen dos tipos de motores, de corriente continua y de paso (ver documento Motores y Sensores [LM2004A]).

Se eligieron motores de paso dado que se pueden controlar con más precisión (es posible detenerlos en un paso determinado). Para marcar un paso hay que energizar sus bobinas de la manera adecuada y para hacer que se muevan hay que energizarlas siguiendo los patrones correctos, en la medida en que se varíen los tiempos de espera entre los distintos pasos, se van obteniendo distintas velocidades. Si bien es posible hacer casi lo mismo con un servo (acelerar, desacelerar), no se puede detener el motor en un paso particular. Esto no es imprescindible para el fútbol de robots pero el control más fino genera un atractivo académico extra.

De lo anterior se desprende que será necesario controlar constantemente la forma en que están energizadas las bobinas del motor de paso, así que se utilizará un controlador para esta tarea, quien será responsable de mantener las velocidades que se le indiquen. Este controlador será un PIC de microchip de gama media (luego y por otras razones se llegará a la definición del modelo de PIC a utilizar).

Otro punto importante es la modularización, es decir enfrentar los distintos puntos del proyecto de forma tal de lograr soluciones independientes, con alta cohesión y bajo acoplamiento.

Esta implementación indica que la Unidad será movida por 2 ruedas, con un motor asociado a cada una y velocidades independientes para poder doblar, recibirá ordenes que le marcan la velocidad por rueda. Sin embargo esta es una implementación que responde al modelo diseñado, en lo conceptual una Unidad tiene un módulo que gestiona su desplazamiento (módulo MOTOR), por lo tanto si se intenta cambiar las ruedas por patas, esto parece a priori muy factible solo cambiando el módulo MOTOR y reinterpretando los mensajes de velocidad que se reciben.

Si bien separar en módulos cohesivos permite bajar el acoplamiento en la Unidad, en particular no es claro modularizar dentro del propio módulo MOTOR, dado que si se tienen uno o varios motores siempre habrá que cambiar tanto la electrónica interna del módulo como los programas, debido a las características de los componentes que se están

Página 6 de 24


utilizando (cuatro bits de un puerto por motor en el PIC, y programas que tratan independientemente cada motor).

DefinicionesSe explicitan definiciones de términos que se utilizarán en las secciones posteriores (algunas de estas definiciones cambian en secciones siguientes según cómo evolucionaron las rutinas).

INS

Mínimo tiempo necesario que debe transcurrir entre un paso y el siguiente. Será la unidad de tiempo para el motor.

Acel

Mínimo tiempo (en INS) necesario para que se pueda volver a incrementar (o decrementar) en una unidad la velocidad.

VelZero

Es la velocidad del motor detenido.

VelActual

Velocidad en la que se encuentra andando el motor (de 0 a VelZero son velocidades negativas, VelZero es que el motor esta parado, desde VelZero en adelante son velocidades positivas).

VelNueva

Velocidad a la que el motor debe llegar lo antes posible.

TiempoPaso

Contador que indica cuanto tiempo falta para dar el siguiente paso (en INS), depende directamente de la velocidad.

TiempoAcel

Contador que indica cuanto tiempo falta para el siguiente cambio de velociad (en INS).

Página 7 de 24


SeudocódigoEl seudo que estará ejecutando el PIC de control de un motor será el siguiente (versión inicial). Este seudo está pensado para implementarse en Assembler por lo tanto aparecen comentarios como complemento a las instrucciones, esto es para evidenciar que si bien las ramas del código generado serán funcionalmente distintas en cuanto a tiempo de ejecución deberán ser iguales.

Programa PrincipalMientras (true)

ControloYDoyPaso()

ControloYActualizoVelocidad()

CompletoTiempoINS()

End

Algoritmo 1: Main de control de un motor.

Rutinas// Si es tiempo de dar un paso se da sino espera (esto determina la velocidad).ControloYDoyPaso()

Si (TiempoPaso=0)TiempoPaso=VelActualDoyPaso()

SinoTiempoPaso=TiempoPaso – 1// NADA. Completo instrucciones.

EndEnd

Algoritmo 2: Rutina de contol y paso.

// Si cumpli con el tiempo mínimo para la aceleración cambia la velocidad.ControloYActualizoVelocidad()

Si (VelActual<>VelNueva)Si (TiempoAcel = 0)

VelActual=SetNuevaVel()Si (VelActual<>VelNueva)

TiempoAcel=AcelEnd

SinoTiempoAcel=TiempoAcel – 1// NADA. Completo instrucciones.

EndSino

// NADA. Completo instrucciones.End

EndAlgoritmo 3: Control y actualización de velocidad:

Página 8 de 24


// Aumenta o disminuye en una unidad la velocidad.SetNuevaVel()

Si (VelActual>VelNueva)VelActual=VelActual – 1

SinoVelActual=VelActual + 1

EndEnd

Algoritmo 4: Seteo de nueva velocidad.

DoyPaso() setea los pines adecuados del microcontrolador para poner el motor en el siguiente paso.

CompletoTiempoINS() rutina que ejecuta instrucciones NOC hasta que se complete un INS, será además la encargada de acomodar los gastos de instrucciones extra en interrupciones.

Descripción GeneralEl código estará corriendo continuamente pero será interrumpido cuando llegue información de un cambio de velocidad. La rutina que atiende la interrupción carga la variable VelNueva y deja una indicación de que se ejecutó la rutina para que CompletoTiempoINS() la tenga en cuenta.

En general los distintos caminos de las subrutinas tendrán los mismos tamaños y estos serán conocidos, por lo tanto tendrán un tiempo de ejecución predecible.

Página 9 de 24


Movimientos Adelante o Atrás

Primera VersiónSe define como una visión interna de las velocidades un byte que puede contener valores entre 0 y 255, y como interfase con el mundo un conjunto de velocidades que van desde un mínimo (-20 en el ejemplo) hasta un máximo (235) pasando por 0, en números enteros.

Figura 1: Mapeo de Velocidades.

Internamente se define un punto en el intervalo [0, 255] que se considera el punto de parada (VelZero), es decir si la velocidad interna del motor es VelZero entonces el motor no avanza otro paso hasta que su VelActual deje de ser VelZero.

Si es necesario por alguna razón tener más velocidades negativas o menos, basta con mover el VelZero, es decir, reubicar el cero en el intervalo y obtener más velocidades negativas y menos positivas en la interfase con el mundo.

La ventaja de esta definición es que es compatible con la idea de aceleración y desaceleración que se especificó anteriormente, no requiere cambios, es fácil de implementar dado que solo se controla la VelActual contra la VelZero, si son iguales no se mueve el motor, si una es mayor que la otra se avanza o retrocede al siguiente o anterior paso del motor. Además se reestructura la cantidad de velocidades positiva y negativas solo moviendo el valor de VelZero.

Página 10 de 24


Migración de Programas en Assembler al Lenguaje CSe decidió intentar escribir el programa que controla los motores en el lenguaje C en lugar de Assembler como se estaba haciendo hasta ahora. Las razones y los problemas que esto ocasionó se describen en las siguientes secciones.

Razones para llevar a cabo la MigraciónEl código del control de motores es casi el más viejo y podría decirse que el más maduro, fue el que sirvió para hacer muchas de las pruebas y permitió hacer las primeras armas en la programación de los microcontroladores PIC. Escribir el programa en Assembler fue un problema inicialmente pero se ha alcanzado un aceptable grado de estabilidad, así que surge el cuestionamiento de porque migrarlo, la respuesta es el I2C. Se prevé que será necesario mantener las cosas lo más simples posibles para encarar el bus y el PICC Lite cuenta con algunas bibliotecas que podrían simplificar el trabajo en la comunicación.

Tal vez está demás mencionar que para hacer las pruebas es mucho más fácil escribir unas pocas líneas en C que unas no tan pocas líneas en Assembler. Tener el código de movimiento armado en C es más fácil de mantener y entender. Cuando se escribe código en Assembler, no es fácil al rever el fuente que se escribió dos meses antes, aunque sea solo para cambiar una salida porque se quiere agregar un LED. La única técnica que ayuda son muchos comentarios en el código pero de todas formas es incomparable a utilizar un compilador C.

Problemas que Acarrea la MigraciónClaro que haber decidido la migración automáticamente agrega el problema de la gestión de los tiempos. En Assembler, los tiempos están muy controlados dado que se pueden calcular exactamente contando instrucciones (de hecho los programas iniciales de prueba tienen todas las ejecuciones posibles del código con caminos de igual cantidad de instrucciones).

En un microcontrolador PIC utilizando, por ejemplo, un cristal externo que marca los pulsos de reloj a 20MHz, se puede deducir el tiempo de un pulso de reloj, además se sabe que ejecutar una instrucción común necesita 4 ciclos de reloj, a esto se agrega que algunas instrucciones particulares demoran 2 instrucciones comunes. En definitiva, para todos los casos se conoce la cantidad exacta de ciclos de reloj que insume la ejecución de un pedazo de código.

En C no se conoce que cantidad y tipo de instrucciones generará el compilador, por lo que contar instrucciones está fuera de discusión.

Solución al Problema de los TiemposEl problema de los tiempos esta dado por a la necesidad de saber cuanto tiempo pasa entre paso y paso de un motor para gestionar su velocidad.

Para llegar a la solución se debe tener en cuenta que quienes pueden manejar tiempos en un PIC son los timers (por un detalle del manejo de timers referirse al documento Programación de Microcontroladores [LM2004B]), además cuando desbordan provocan una

Página 11 de 24


interrupción. Lo que se hará será programar las mismas rutinas de movimiento, con las mismas ideas en el código asociado a la interrupción por un timer en particular.

También los mensajes al llegar o enviarse (cada byte) provocan interrupciones, así que la rutina que atiende las interrupciones será compleja. Por un detalle del manejo de interrupciones en un microcontrolador PIC referirse al documento Programación de Microcontroladores [LM2004B].

Por otro lado existe una situación que hay que contemplar en particular (también se detectó un problema parecido en Assembler), y es que pasa si ocurre una interrupción cuando se está atendiendo otra. El código que atiende las interrupciones no es reentrante por lo que no será interrumpido por otra interrupción, así que al salir de la rutina el PIC volverá a entrar automáticamente a la rutina de interrupción hasta que no queden banderas de interrupción arriba.

De todas formas, podría pasar que al atender una interrupción de mensaje o de timer en ese momento ocurra una nueva interrupción de otra fuente, si ocurre esta situación los motores podrían dar un paso unas micronésimas de segundo más tarde de lo debido (esto es imperceptible), y el paso siguiente se dará en forma adecuada porque el timer en realidad no se detuvo, solo se atendió apenas tarde. Atendiendo a estas situaciones, los códigos se harán los más cortos posible.

Más de un MotorEl control de motores tiene a su cargo mantener andando los motores de la Unidad y hacer que estos aceleren si es necesario. Además de recibir mensajes que le indican las nuevas velocidades.

Si bien esta es una definición bastante genérica, la realidad indica que con la electrónica que se está usando no se podrán poner una cantidad arbitraria de motores, así que el código mantendrá la cantidad de motores fija, inclusive teniendo conjuntos de variables fijas para cada motor. Poner un motor más será dificultoso, aunque se programe en C, dado que habrá que hacer la parte de código del nuevo motor.

La justificación para esta forma de programación, en principio tan desprolija, es el propio compilador C, se pretende que el código que genere sea lo más lineal posible y no genere código demás en situaciones que no es fundamental. Por ejemplo no se usan vectores porque cuando se compila, el compilador utiliza el registro de indirección para llegar a donde debe, y el código compilado tiende a ser más grande del necesario y por lo tanto generar caminos de ejecución largos. Esto va en contra de tratar de hacer que las rutinas sean lo más cortas posibles. En general se ha evitado el pasaje de parámetros y se han utilizado variables globales, además de utilizar tipos de variables que el compilador pueda mapear directamente a un byte.

Página 12 de 24


Esquema de FuncionamientoEn esta sección se muestran los diagramas SDL para la gestión de velocidades.

Figura 2: SDL para gestión de velocidades.

Página 13 de 24


Figura 3: Complemento de SDL para gestión de velocidades.

Aclaración: Esta máquina muestra que el módulo responde luego de recibir un mensaje. Esto se cambió de modo de dar más generalidad al intercambio de mensajes y agregado de módulos a la Unidad. En la versión final el módulo MOTOR no envía un mensaje de respuesta a menos que se lo soliciten (ver máquina de estados del I2C, más adelante).Se mantiene la figura de la máquina de estados para mostrar la idea inicial y porque ejemplifica el esquema de velocidades utilizado hasta este momento.

Problemas que tiene este DiseñoIncomprensiblemente algunos errores enormes pasan desapercibidos durante mucho tiempo, el diseño de las rutinas de movimiento de motores es un ejemplo... En papel todo parecía cerrar hasta que además de leer se pretende que las cosas funcionen. Cuando se estaba realizando la implementación de la parada y el movimiento hacia atrás fue evidente de que la actual implementación no funcionaba.

Descripción del Problema

Para entender el problema hay que tener presente que en el programa las velocidades son valores de tiempo, cuanto tiempo espera un motor entre paso y paso, es decir cuando un robot se mueve con alta velocidad, internamente la velocidad es baja (pasa poco tiempo entre un paso y el siguiente). Un ejemploSi la velocidad (internamente al módulo MOTOR en lo que sigue) es 100 esto significa que se deben esperar 100 INS para que se pueda avanzar otro paso, esto es bastante lento, acelerando se llega a una velocidad de 22, ahora hay que esperar solo 22 INS para dar otro

Página 14 de 24


paso, esto es bastante más rápido. Siguiendo el ejemplo, y teniendo el VelZero=21, el siguiente paso parará el motor instantáneamente. Esto es justo lo que NO se quiere, la Unidad va muy rápido y los motores se detienen de golpe con todos los problemas de inercia que esto significa. Además la siguiente velocidad (20) es de las que van para atrás, así que el motor empezaría a caminar hacia atrás esperando solo 20 INS entre pasos, iría muy rápido desde su estado anterior que era detenido... De hacerse así no habría ningún tipo de aceleración o desaceleración, esto está muy lejos del objetivo.

El primer cambio candidato a solución es: dar vuelta el byte y poner a VelZero=180, tomando los valores mayores a 180 como velocidades negativas.

Otra vez problemas, estando en velocidades positivas y con la unidad siempre caminando hacia delante todo anda bien, inclusive la unidad puede detenerse y volver a acelerar, sin embargo cuando tenga que ir para atrás lo hará muy lentamente en todos los casos, tendrá al menos una espera de 181 INS entre sus pasos (y esta es su máxima velocidad hacia atrás...).

El verdadero problema es que se están mezclando en una sola variable dos conceptos: módulo y dirección de la velocidad.

Página 15 de 24


Solución al Problema y Nuevo DiseñoA partir de ahora se establecerán una dirección de movimiento y una velocidad. Además se agrega un nuevo concepto de velocidad_objetivo y dirección_objetivo.

Nuevas Definciones

Vel_Actual

Velocidad que tiene actualmente el motor. Cantidad de INS que se espera antes de dar un paso.

Dir_Actual

Dirección actual, hacia donde esta girando el motor.

Vel_Nueva

Velocidad que debe alcanzar la rutina de aceleración localmente.

Vel_Objetivo

Velocidad a la que tiene que llegar el motor, cargada por un mensaje.

Dir_Objetivo

Dirección a la que tiene que llegar el motor, cargada por un mensaje.

VelZero

Valor especial de velocidad, cuando un motor llega a este valor se detiene, es el valor más grande que puede alcanzar una velocidad.

Descripción del funcionamientoPara entender el nuevo funcionamiento se propone el siguiente ejemplo:

Se supone que un motor se esta moviendo con velocidad.Vel_Actual= 30 Dir_Actual=1Vel_Nueva=30 (hacia delante) la velocidad del motor se encuentra estable.

Llega un mensaje que indica que la nueva velocidad tiene un valor de 40 y es hacia atrás, Vel_Objetivo=40 Dir_Objetivo=0.

Para alcanzar una velocidad de 40 en el sentido opuesto, primero hay que desacelerar hasta VelZero, por lo tanto se setea la Vel_Nueva con el valor VelZero.

Cuando la rutina que mantiene la velocidad del motor detecta que la velocidad actual es VelZero, se cambia la Dir_Actual por la Dir_Objetivo y como valor de Vel_Nueva se pone el valor de la Vel_Objetivo. Así que el motor comienza a acelerar ahora en la nueva dirección.

Página 16 de 24


Esto se traduce como un motor que se puso más lento, llegó a parar y luego arrancó para atrás. El tiempo que demora todo este proceso depende de la constante ACEL que marca los mínimos tiempos de aceleración posibles.

SeudoCódigoDel seudo código anterior cambia la rutina ControloYDoyPaso()

Rutina modificadaControloYDoyPaso()

TiempoPaso--Si (TiempoPaso=0)

TiempoPaso=VelActualSi (VelActual != VelZero)

DoyPaso()End

SinoSi (VelObjetivo != VelZero){

DirActual = DirObjetivo;VelNueva = VelObjetivo;

EndEnd

EndAlgoritmo 5: Nueva rutina ControloYDoyPaso().

Página 17 de 24


MensajesEn esta sección se describen los mensajes, las interpretaciones de los valores recibidos y los tipos de mensaje.

Un mensaje para el módulo MOTOR consta de 2 bytes que son recibidos por I2C. El primer byte tiene en sus 5 bits menos significativos el tipo del mensaje y en los 8 bits del segundo byte está el dato.

Por un detalle de la mensajería que maneja el módulo MOTOR referirse al documento Protocolos de Comunicación [LM2004C].

Página 18 de 24


Elección del PIC para el módulo MOTOREl primer diseño del módulo MOTOR se pensó con un microcontrolador PIC 16F628, que para controlar 2 motores de paso de 4 cables parecía más que suficiente, de hecho lo es.

Cuando se necesito integrar el controlador de motores al bus I2C (que es quien lo comunica con el módulo COMM) fue que el PIC 16F628 dejó de ser útil por no contar con facilidades para el manejo del bus. Una opción era cumplir con el protocolo I2C (eléctricamente) utilizando este PIC, pero esto es un problema en sí mismo. La solución fue crecer en el modelo de microcontrolador a uno que tuviera integrado el manejo del bus I2C. El PIC 16F877A se convirtió en un candidato ya que cuenta con el manejo del bus tanto en el rol de MASTER como en el rol de SLAVE.

Al utilizar los 16F877A se tiene todo lo que se necesita, dado que tienen manejo de I2C, mayor cantidad de puertos, los mismos timers e interrupciones, el problema fue la escasez. Para el proyecto se necesitaban para el módulo COMM (por poder ser MASTER del bus I2C) y para el módulo ER (por la cantidad de pines). De lo que sí se disponía era de 3 PIC 16F876A que no estaban siendo utilizados y estos cuentan con las mismas características del 16F877A excepto que tienen menos pines, lo que no era un problema en el módulo MOTOR.

Por estas razones, se decidió que los módulos SLAVE en el I2C, tanto el módulo MOTOR como el módulo SENSOR sean controlados por microcontroladores PIC 16F876A.

Esta decisión no tuvo ninguna contraindicación, los programas se compilaron sin necesidad de modificarlos, y se cargaron solo cambiando el modelo en el programa cargador, sin problemas. Claro que fue necesario construir un circuito programador nuevo porque el PIC 16F876A tiene menos pines y otra disposición (es más angosto) que el PIC 16F877A y más pines que el PIC 16F628, por lo que hubo que improvisar zócalos para que los soporten (problema mínimo comparado con la ganancia obtenida).

Página 19 de 24


Torque y MovimientoDado que una premisa de construcción es la reutilización, los motores de paso utilizados en la Unidad fueron obtenidos de impresoras, lo que lleva a que no son los óptimos.

Estos motores seguramente tienen características óptimas para mover un carro o desplazar una hoja pero no son demasiado fuertes ni rápidos como para mover un robot de la mejor manera. Además es necesario considerar el consumo, para energizarlos es necesario contar con una batería con el amperaje adecuado, esto condiciona el peso de la Unidad y contribuye al funcionamiento subóptimo de los motores.

De todas formas los motores logran mover la Unidad, y dado que el programa que corre en el microcontrolador del módulo MOTOR ha sido diseñado para el cambio, siempre es posible cambiar los motores con poco impacto.

Por otro lado la forma de comandar o energizar los motores de paso se describe en sus hojas de datos, lamentablemente los motores conseguidos no tienen indicado modelo o algún dato como encontrar sus hojas de datos, así que se siguieron los estándares planteados en el documento Motores y Sensores en Robótica [LM2004A].

Cantidad de Pasos de los Motores UtilizadosLos motores utilizados tienen 24 pasos. Es fundamental que los 2 motores tengan la misma cantidad de pasos para que sea posible regular la velocidad. El programa de control se basa en mantener las velocidades teniendo en cuenta tiempo entre pasos, una vuelta con distinta cantidad de pasos a una misma velocidad en el programa significaría distinta velocidad real.

Tener 24 pasos significa que cuando un motor da un paso avanza 15 grados, esta es la justificación de porque la Unidad parece arrancar dando sacudidas, esta sensación cesa una vez en movimiento.

Utilización de Distintos TorquesDebido a que la fuerza y velocidad de los motores se planteó como un problema, se intentaron utilizar distintas formas de energizar los motores, para obtener mas torque, o más fuerza al trancar un paso.

Existen dos variables a considerar : Una es la velocidad con la que se puede pasar de un paso al siguiente; está

determinada por la velocidad en que se estabilizan las bobinas luego de ser energizadas.

La fuerza con que una o varias bobinas mantienen un paso.

Intentando mover estas variables y de acuerdo a datos de otros drivers encontrados, se establecieron distintas formas de avanzar en los pasos.

Página 20 de 24


Primera Forma de Energizar un Motor

Secuencia normal [LM2004A], se energizan dos bobinas a la vez, esta forma supone una mayor fuerza en la posición del paso y una mayor demora entre pasos. El motor alcanzará menores velocidades pero será mas fuerte (para subidas o bajadas controladas).

Paso 4 cables para energizar bobinas1 0 0 1 12 0 1 1 03 1 1 0 04 1 0 0 1

Tabla 1: Forma de energizar dos bobinas por paso en secuencia normal.

Segunda Forma de Energizar un Motor

Secuencia del tipo wave drive [LM2004A], se energiza una bobina por paso. Esta forma supone una menor fuerza en la posición del paso y una menor demora entre pasos. El motor alcanzará mayores velocidades pero no será tan fuerte como el anterior (ideal para un motor en movimiento si el torque que logra con una única bobina energizada por paso es suficiente).

Paso 4 cables para energizar bobinas1 0 0 0 12 0 0 1 03 0 1 0 04 1 0 0 0Tabla 2: Forma de energizar las bobinas de un motor de paso en secuencia

tipo wave drive.

Tercera Forma de Energizar un Motor

Secuencia del tipo medio paso [LM2004A]. Con este tipo de secuencia no se notaron grandes diferencias. Más bien, complicaba el arranque de la Unidad, quedando detenida en varias ocasiones.

Paso 4 cables para energizar bobinas1 0 0 0 12 1 0 0 13 1 0 0 04 1 1 0 05 0 1 0 06 0 1 1 07 0 0 1 08 0 0 1 1Tabla 3: Forma de energizar las bobinas de un motor de paso en secuencia

tipo medio paso.

Página 21 de 24


Cuarta forma de energizar un motor

Se intentó una cuarta forma de controlar el motor haciendo un híbrido de las anteriores, suponiendo que se estaría en una situación intermedia. Si bien fue un absoluto fracaso, se muestra como ejemplo de una forma que no funcionó.

Paso 4 cables para energizar bobinas1 0 0 1 12 0 1 0 03 1 0 0 14 0 0 1 05 1 1 0 06 0 0 0 17 0 1 1 08 1 0 0 0

Tabla 4: Intento de generar una forma intermedia energizando una y dos bobinas alternadas.

En la implementación actual de la Unidad, se utilizan las dos primeras formas para energizar los motores. Existe un limite de velocidad entre la utilización de una u otra forma, cuando la unidad debe moverse rápidamente se utiliza la segunda forma y cuando las velocidades son más lentas la primera.

Página 22 de 24


Transmisión de Potencia al PisoOtro intento de atacar el problema de la fuerza fue cambiar la forma de la transmisión de potencia al piso, es decir cambiar la forma en que el motor mueve las ruedas.

Rueda en el Eje del Motor

La forma inicial de asociar la rueda al motor fue directa. Se montó cada rueda sobre el eje del motor y esto hacía que solo se dependiera del tamaño de la rueda.

Figura 4: Rueda montada en el eje del motor.

Polea del Motor a la RuedaEn la implementación definitiva se optó por dejar un piñón en el eje del motor y transmitir la potencia a la rueda del robot mediante una polea. Esto tiene la ventaja de multiplicar la potencia.

Figura 5: Rueda unida al motor por una polea.

Página 23 de 24


Bibliografía y Referencias[VEH2000] Vehicles. Experiments in Synthetic Psychology.

Valentino Braitenberg.[HOJ2004A] Hoja de datos del 16F628.[HOJ2004B] Hoja de datos del 16F876A[HOJ2004C] Hoja de datos del 16F877A

Manual de PIC C[MIC2004] http://Microchip.com

Confirmada la existencia de la página al 30/05/2004[MIC2000] Microbótica primera edición 2000

José María Angulo UsateguiSusana Romero YesaIgnacio Angulo Martinez

[IMP1998] Implementación de un sistema de desarrollo utilizando lo microcontroladores PIC, Universidad de Guadalajara,1998 .Manuel Fernando Campos CerdaRamiro Castañeda PérezArturo César Contreras Torres

[MMP2003] Manual de MicroContoladores PIC. Diseñado para los amigos de Picislatina. Documento facilitado por el instructor del curso : MicroControladores PIC 2003.

[MEL2004] micro-bot (de Reynolds) http://www.melabs.com/products/renbot.htmConfirmada la existencia de la página al 30/05/2004

[PAR2004] robots y videos de Parallax inc. http://www.parallax.com/html_pages/robotics/index.asp Confirmada la existencia de la página al 30/05/2004

[MSE2004] Picbot de microsystems engineering. http://www.msebilbao.com/tienda/default.phpConfirmada la existencia de la página al 30/05/2004

[K-T2004] Khepera. http://www.k-team.comConfirmada la existencia de la página al 30/05/2004

[LEG2004] cybermaster y mindstorm http://www.lego.com/engConfirmada la existencia de la página al 30/05/2004

[LM2004A] Motores y Sensores en Robótica. Documentación asociada al proyecto, descripción de funcionamiento de motores y sensores. Santiago Margni – Germán López (2004)

[LM2004B] Programación de microcontroladores. Documentación asociada al proyecto, reseña de puntos importantes en la programación de microcontroladores PIC. Germán López - Santiago Margni (2004)

[LM2004C] Protocolos de comunicación. Documentación asociada al proyecto, descripción cronológica del análisis y diseño de los protocolos utilizados. Germán López - Santiago Margni (2004)

Página 24 de 24

http://www.lego.com/eng

http://www.k-team.com/

http://www.msebilbao.com/tienda/default.php

http://www.parallax.com/html_pages/robotics/index.asp

http://www.melabs.com/products/renbot.htm

http://Microchip.com/

Movimiento Motores

Documents

Transcript of Movimiento Motores