diseño y construcción de una plataforma robótica polivalente para eurobot

UNIVERSIDAD DE VALLADOLID

ESCUELA DE INGENIERÍAS INDUSTRIALES

PROYECTO FIN DE CARRERA

INGENIERO INDUSTRIAL

DISEÑO Y CONSTRUCCIÓN DE UNA PLATAFORMA ROBÓTICA MÓVIL PARA LA COMPETICIÓN

EUROBOT

AUTOR: Vicente Izcara Autillo

DIRECTOR: Eduardo Zalama Casanova

Departamento de Ingeniería de Sistemas y Automática

AGRADECIMIENTOS Quiero dedicarle este trabajo a mis padres. Ellos han sido mi luz y mi guía. A mis hermanos, y al resto de mi familia. A mis amigos. A mi novia, porque haces que todo sea más fácil estando a mi lado. Y muy especialmente quiero dar gracias a Dios por todos ellos, y porque ha querido que este día llegue y podamos verlo. Sara: no te olvidamos.

Izcara Autillo, Vicente

Contenido III

RESUMEN DEL PROYECTO Con este proyecto se pretende diseñar y construir una plataforma robótica móvil

orientada a la participación en la competición de robótica EUROBOT.

Se estudiarán las necesidades más generales para proponer una arquitectura versátil que

pueda adaptarse a necesidades más concretas.

Los trabajos se centrarán en el desarrollo de los sistemas que permitirán el movimiento

del robot, abarcando tanto la integración de equipos comerciales como el desarrollo de

sistemas a medida.

Se construirá un prototipo y se realizarán pruebas de funcionamiento.

Por último, se extraerán conclusiones de los trabajos realizados y se apuntarán las líneas a

seguir en futuros desarrollos.

Índice I

Escuela de Ingenierías Industriales. Universidad de Valladolid

ÍNDICE DE CONTENIDO

Glosario .................................................................................................... 5

1. Introducción. Objetivos y Justificación .......................................... 6

1.1. El campeonato de robótica EUROBOT ............................................................. 6

1.2. AMUVA y el proyecto “Equipo AMUVA-EUROBOT”.......................................... 7

1.3. Punto de partida ................................................................................................. 9

1.4. Especificaciones .............................................................................................. 10 1.4.1. Capacidad de abandonar la salida y anotar un punto .............................. 11 1.4.2. Cumplir las especificaciones técnicas ...................................................... 11 1.4.3. Funcionamiento seguro ............................................................................ 11

1.5. Objetivos .......................................................................................................... 12

1.6. Estructura de la memoria ................................................................................. 12

2. Arquitectura del Robot ................................................................... 15

2.1. Arquitecturas de descomposición funcional ..................................................... 16 2.1.1. Arquitecturas PPA .................................................................................... 16 2.1.2. Arquitecturas basadas en pizarra ............................................................ 18

2.2. Arquitecturas reactivas .................................................................................... 19

2.3. Arquitecturas híbridas ...................................................................................... 21

2.4. Arquitectura propuesta para este proyecto robótico ........................................ 22 2.4.1. Niveles de la arquitectura de control ........................................................ 25

3. Arquitectura Física y Diseño Mecánico ........................................ 31

3.1. Arquitectura física ............................................................................................ 31 3.1.1. Plataforma móvil ...................................................................................... 32

3.2. Configuración de vehículos con ruedas ........................................................... 35 3.2.1. Configuración Ackerman o “tipo coche” ................................................... 35 3.2.2. Configuración tipo triciclo ......................................................................... 36 3.2.3. Tracción diferencial .................................................................................. 37 3.2.4. Configuración con ruedas o pistas deslizantes (Skid Steer) .................... 38 3.2.5. Configuración de ruedas síncronas ......................................................... 39 3.2.6. Tracción omnidireccional ......................................................................... 40 3.2.7. Configuración elegida. Justificación ......................................................... 41

3.3. Diseño mecánico de la plataforma móvil ......................................................... 42 3.3.1. Bastidor .................................................................................................... 45 3.3.2. Conjunto encóder- motor- reductora ........................................................ 50

4. Arquitectura y Diseño Electrónico ................................................ 55

4.1. Introducción ..................................................................................................... 55

II Diseño y Construcción de una Plataforma Robótica Móvil para la Competición EUROBOT.


4.2. Sistema de control de alto nivel ....................................................................... 56

4.3. Sistema electrónico de control de movimiento ................................................ 58 4.3.1. Introducción al modelo de sistema de control de movimiento. ............... 58

4.3.1.1. Navegación ..................................................................................... 59 4.3.1.2. Posicionamiento .............................................................................. 61

4.3.2. Placa electrónica de control de tracción .................................................. 63 4.3.2.1. Diseño ............................................................................................. 63 4.3.2.2. Construcción de la placa ................................................................. 66 4.3.2.3. Uso y configuración hardware de la placa ..................................... 69

4.3.3. Placa electrónica de potencia .................................................................. 76 4.3.4. Placa de accionamientos ......................................................................... 79 4.3.5. Alimentación. Baterías Li-Po .................................................................... 82 4.3.6. Conexiones y cableado. ........................................................................... 84

5. Diseño Software. ............................................................................. 87

5.1. Elección del microcontrolador .......................................................................... 87 5.1.1. Microcontroladores Microchip PIC ........................................................... 87 5.1.2. Elección de la familia. La familia PIC33F ................................................. 88 5.1.3. Elección del dispositivo. dsPIC33FJ64MC802 ......................................... 90

5.2. Creación de proyectos y aplicaciones con el dsPIC ........................................ 91 5.2.1. Lenguajes de programación. El lenguaje C ............................................. 91 5.2.2. Herramientas de desarrollo. El compilador MPLAB C para dsPIC .......... 93 5.2.3. Elementos de un proyecto ....................................................................... 94

5.3. Configuración del dsPIC33FJ64MC802 ........................................................... 97 5.3.1. Hoja de características del dispositivo ..................................................... 97 5.3.2. Arquitectura del dsPIC33FJ64MC802 ...................................................... 98

5.3.2.1. Motor DSP ...................................................................................... 98 5.3.2.2. Características MCU especiales ...................................................... 99

5.3.3. Características especiales. Registros de configuración ......................... 101 5.3.4. Configuración del oscilador .................................................................... 103 5.3.5. Configuración de entradas y salidas del dispositivo .............................. 106 5.3.6. Módulo de conteo Timer 1 ..................................................................... 108 5.3.7. Selección de patillas para uso por periféricos (PPS) ............................. 109

5.3.7.1. Mapeo de entradas a periféricos ................................................... 110 5.3.7.2. Mapeo de salidas de periféricos .................................................... 111

5.3.8. Módulo PWM para control de motores. .................................................. 111 5.3.9. Módulo de interacción con encóder de cuadratura QEI ......................... 119

5.3.9.1. Descricpción del módulo .............................................................. 119 5.3.9.2. Configuración del módulo para la aplicación ............................... 124

5.3.10. Puerto de comunicación serie UART ..................................................... 126 5.3.10.1. Descripción del módulo ................................................................ 126 5.3.10.2. Configuración del módulo para la aplicación ............................... 130

5.3.11. Controlador de interrupciones ................................................................ 131 5.3.11.1. Descripción del módulo ................................................................ 131 5.3.11.2. Configuración de las interrupciones ............................................. 134

5.4. Programa de control del robot ....................................................................... 135 5.4.1. Rutina principal ...................................................................................... 136 5.4.2. Rutina de recepción y administración de comandos recibidos .............. 138

5.4.2.1. Comando de orden de movimiento: MOV.................................... 140

Contenido III

Escuela de Ingenierías Industriales – Universidad de Valladolid

5.4.2.2. Comando para establecer el valor de variables o parámetros del sistema: SET ..................................................................................................... 140 5.4.2.3. Comando para extraer el valor de variabes o parámetros: ASK ... 141 5.4.2.4. Comandos para establecer modos de funcionamiento: ................. 141 5.4.2.5. Comandos para componer trayectorias básicas: ........................... 142

5.4.3. Rutinas de ejecución de órdenes de movimiento. Control de posición y velocidad. ............................................................................................................... 142

5.4.3.1. Algoritmo de control de velocidad ............................................... 146

6. Resultados Experimentales ......................................................... 151

6.1. Robot real vs Robot 3D .................................................................................. 151

6.2. Validación del diseño electrónico y configuración de periféricos. .................. 154 6.2.1. Pruebas en placa de prototipos ............................................................. 154 6.2.2. Prueba de los sistemas del robot. .......................................................... 157

6.3. Pruebas de movimiento. Ajuste de los algoritmos de control de posición y velocidad .................................................................................................................... 158

6.3.1. Respuesta en lazo abierto. Caracterización del sistema ....................... 158 6.3.1.1. Respuesta escalón con mecánicas en vacío .................................. 161 6.3.1.2. Respuesta escalón con mecánicas en carga .................................. 164 6.3.1.3. Conclusiones y caracterización en lazo abierto ............................ 166

6.3.2. Ajuste de PID para control de velocidad ................................................ 169

7. Estudio Económico....................................................................... 185

7.1. Costes directos .............................................................................................. 185 7.1.1. Costes en materias primas y componentes ........................................... 185 7.1.2. Costes de amortización de equipos y herramientas. ............................. 187 7.1.3. Costes de software y licencias. .............................................................. 187 7.1.4. Costes por mano de obra empleada ...................................................... 187

7.2. Costes indirectos ........................................................................................... 190

7.3. Costes totales del proyecto ............................................................................ 190

8. Conclusiones y Trabajos Futuros ............................................... 191

ANEXOS ................................................................................................ 195

CÓDIGO FUENTE ................................................................................. 197

ÍNDICE DE ILUSTRACIONES .............................................................. 243

ÍNDICE DE TABLAS ............................................................................. 247

ÍNDICE DE ECUACIONES .................................................................... 249

REFERENCIAS ..................................................................................... 251

IV Diseño y Construcción de una Plataforma Robótica Móvil para la Competición EUROBOT.


Glosario 5

Escuela de Ingenierías Industriales. Universidad de Valladolid

Glosario

CIR Centro Instantáneo de Rotación

PFC Proyecto fin de carrera

PPA Percepción, planificación, acción

SPA Sense, plan, act

SRI Standford Research Institute

PWM Pulse width modulation

SBC Single board computer

PMDCM Permanent magnets direct current motor

THT Thru hole technology

SMT Surface mount technology

LDO Low drop-out

FET Field effect transistor

PWM Pulse width modulation

DSC Digital signal controller

MIPS Millones de instrucciones por Segundo

RAM Random Access Memory

UART Universal Asynchronous Receiver Transmitter

CSV Comma Separated Values

GDB GNU Debug

6 Diseño y Construcción de una Plataforma Robótica Móvil para la Competición EUROBOT


1. Introducción. Objetivos y Justificación

1.1. El campeonato de robótica EUROBOT

EUROBOT [1] es una competición de robótica amateur (no profesional) para

equipos formados por participantes de hasta 30 años de edad.

La primera edición tuvo lugar en 1998, surgida al amparo del gran éxito de la

copa de Francia de robótica. Fue creado por la asociación de promoción de la

ciencia y tecnología Planète Sciences [2], la productora televisiva VM Group y la

ciudad donde se celebró la primera edición, La Ferté Bernard. Rápidamente

adquirió un carácter internacional, de modo que para coordinar su organización se

fundó la asociación EUROBOT.

El objetivo de la asociación es promover el interés por la robótica y animar a

los participantes a poner en práctica conocimientos científico-técnicos. Más que una

competición, se pretende que sea una oportunidad para aplicar la imaginación,

adquirir y aplicar conocimientos

Además de la competición, en fechas anteriores tiene lugar la “International

Conference on Research and Education in Robotics” un congreso orientado a la

difusión de los trabajos de investigación en robótica móvil educativa, y que procura

una gran oportunidad para que los participantes en el concurso tengan constancia

de los últimos trabajos en esta materia.

Cada país puede estar representado por un máximo de tres equipos en la fase

final. Los países con más de 3 equipos inscritos deben realizar una competición

nacional previa para seleccionar a los dos mejores, y una tercera plaza que será

entregada en base a criterios no necesariamente competitivos.

Introducción. Objetivos y Justificación 7


En España, esta prueba de clasificación es la Copa de España de Robots,

celebrada en la Universidad de Alcalá de Henares de forma conjunta con la

competición Alcabot - Hispabot [3].

Aunque la competición se ha venido celebrando en Europa, está abierta a

equipos de otros continentes. Muy representativo de la vocación del concurso es el

hecho de que los equipos internacionales acceden directamente a la final europea.

Las competiciones nacionales en general están abiertas a participantes de otros

países, y se anima a participar en cuantas más competiciones, mejor, de cara a

perfeccionar y poner a prueba los robots.

El perfil de los participantes es el de jóvenes integrantes de clubs de ciencias,

estudiantes de carreras técnicas universitarias o aficionados a la tecnología, que

encuentran en esta competición un terreno donde desarrollar sus inquietudes,

realizar sus proyectos fin de carrera, aprender y divertirse.

1.2. AMUVA y el proyecto “Equipo AMUVA-EUROBOT”

La Asociación de Microbótica de la Universidad de Valladolid (AMUVA) [4]

surgió en 2002 en la ETSII de Valladolid como resultado del interés de un grupo de

alumnos de dicha escuela por la micro-robótica (microbótica), con intención de

compartir conocimientos, experiencias, y trabajar en equipo en esta área, como

afición paralela a sus estudios.

Pronto se desarrollaron distintas actividades para dar a conocer tanto la

microbótica como a la propia asociación, teniendo un gran éxito de participantes de

entre los cuales surgió un importante número de socios.

Una de ellas fueron las” Primeras jornadas de iniciación a la microbótica”, en

las que profesores y alumnos con conocimientos impartieron una serie de charlas

orientadas a crear una base teórica de conocimiento sobre los distintos aspectos

que confluyen en el diseño de un microbot, tales como sensores, actuadores o

microcontroladores. Esta actividad sigue siendo parte del programa de la

asociación.



La actividad más importante que se puso en marcha fue el campeonato de

robótica ROBOLID [5] en 2003, actividad estrella de la asociación y que en 2011 ha

visto su novena edición con más de 100 robots inscritos, siendo un referente ya

veterano a nivel nacional.

Actualmente ROBOLID es un evento con formato de dos días en el que se

celebran competiciones, conferencias y exhibiciones de robótica, con objetivos

educativos en un ambiente lúdico.

Algunas de las competiciones son estándar y se celebran también en otros

eventos nacionales: sumo, minisumo, rastreadores y velocistas.

La prueba de programación de microcontroladores es original y única en

ROBOLID.

En general los robots presentados son proyectos personales o de equipos de

varias personas, y para desarrollarlos bastan conocimientos básicos en mecánica,

electrónica y programación.

Después de que algunos miembros de AMUVA hubieran adquirido

experiencias muy positivas en este tipo de robots, surgió el deseo de abordar

proyectos robóticos más ambiciosos. Así, en 2004 dos de ellos decidieron diseñar y

construir un robot para participar en EUROBOT, siendo éste su proyecto fin de

carrera y consiguiendo un gran resultado.

En años siguientes se planteó la formación de un equipo en AMUVA para

participar de nuevo en esta competición.

Los resultados no fueron los esperados y este proyecto se canceló en 2006.

Desde entonces se ha planteado retomarlo en varias ocasiones, hasta que en

2011 se han dado las circunstancias adecuadas:

AMUVA cuenta con un grupo estable de socios activos con

experiencia en distintas competiciones, de formación multidisciplinar

(ingeniería industrial, de telecomunicación, electrónica…) y con

interés en sacar adelante el proyecto.

Algunos socios han concluido sus estudios y trabajan en sectores

afines a la robótica, aportando experiencia y estabilidad al grupo.

Otros, inmersos en sus estudios, desean aprender en este campo y



se plantean realizar su PFC, pudiendo en estas circunstancias

asumir mayores responsabilidades.

La asociación ha alcanzado un nivel de madurez suficiente, y

dispone de formas para financiar y apoyar el proyecto.

Por todo esto, unido al interés personal del autor en el éxito de la iniciativa, se

decide comenzar con el soporte técnico al proyecto “Equipo AMUVA-EUROBOT” en

el presente proyecto fin de carrera.

1.3. Punto de partida Se asume que se parte de cero en lo que a reaprovechar equipos, medios o

desarrollos se refiere: el material que se conserva está obsoleto, deteriorado, o no

se dispone de documentación que haga viable su reutilización.

Ser conscientes de esta circunstancia es en sí un activo, pues los trabajos que

se emprenden deben evitar los errores pasados aprovechando las experiencias

propias y observadas en equipos ya consolidados:

Las recomendaciones que se desprenden son:

Desarrollar sistemas robustos, reutilizables y suficientemente

documentados para que puedan formar parte de los activos que

encuentren futuros participantes.

Plantear el conjunto, así como cada uno de los sistemas, desde un

enfoque de mínimos: la primera exigencia al robot es homologar,

para lo que a sus sistemas, debe exigírsele las prestaciones más

básicas que puedan abordarse con garantías.

Ser conscientes de los objetivos inmediatos y siguientes, de modo

que se trabaje en el presente con vistas al futuro.

Puesto que es un hecho que en torno al desarrollo del robot surgen

oportunidades y retos paralelos, otra premisa que se plantea es:

Trabajar con idea de conjunto, como oportunidad de desarrollar

habilidades generales más allá de la robótica (comunicación, trabajo



en equipo, diseño gráfico, herramientas software o project

management ).

Desarrollar un buen soporte hardware y software es la base de un sistema

robótico fiable con posibilidades de crecer y abordar retos más exigentes.

Los complejos sistemas con que compiten los equipos consolidados son el

fruto de numerosas evoluciones, y hay que ser conscientes de que será necesario

recorrer un camino para alcanzar ese nivel.

1.4. Especificaciones La prueba que se plantea en EUROBOT cambia cada año. Así, aspectos como

el número de robots permitidos, elementos que se deben manipular, zonas del

tablero de juego y otros cambian cada año.

Sin embargo, sí se mantienen algunos elementos importantes como

especificaciones de diseño: dimensiones de los robots, alojamiento de balizas para

posicionamiento y exigencias de seguridad, que en muchos casos se actualizan

año a año a través de un foro muy activo.

Estudiando las misiones que se debían completar en distintos años, también se

encuentran elementos comunes en estrategias de juego básicas.

Todo ello permite abordar esta fase del diseño conducente a diseñar y

construir sistemas útiles para una participación genérica en EUROBOT.

Siendo común a las bases de la mayoría de las ediciones, citando literalmente

lo que se indica en la pasada edición de 2011, para la homologación se exige:

Capacidad de abandonar la zona de comienzo y anotar un punto.

Cumplir las especificaciones técnicas.

Demostrar un funcionamiento seguro.



1.4.1. Capacidad de abandonar la salida y anotar un punto

Abandonar la zona de salida suele ser una maniobra simple que puede realizar

cualquier sistema de tracción (avanzar, girar hacia un lado, etc.).

A pesar del distinto formato que la competición adquiere cada año, y que suele

requerir manipuladores óptimos específicos, en la mayoría de las ocasiones el

robot sería capaz de puntuar realizando secuencias de movimiento controladas, con

las que desplace objetos por simple empuje, o por situarse en determinadas áreas

del terreno de juego. Esta capacidad de realizar movimientos controlados le habilita

para abandonar la zona de comienzo. Luego es condición necesaria, y suele ser

suficiente.

1.4.2. Cumplir las especificaciones técnicas

Las especificaciones técnicas van desde dimensiones hasta valores máximos

de ciertas magnitudes, y su conocimiento y comprensión son imprescindibles en

cualquier área de trabajo del proyecto.

1.4.3. Funcionamiento seguro

Es exigencia en todos los casos que el robot no represente un peligro ni para

las personas ni para otros robots en su funcionamiento. Muchas de las

especificaciones técnicas van encaminadas a este objetivo: limitaciones de voltaje,

de presión, restricción de uso de equipos potencialmente peligrosos para la salud

de las personas, medidas de seguridad pasivas o de emergencia… En lo referente

a su funcionamiento en los partidos, la seguridad se concreta en la exigencia de

que el robot sea capaz de evitar colisiones con el robot oponente.



1.5. Objetivos

En el presente proyecto fin de carrera, se pretende emprender el camino a la

participación en la competición EUROBOT dentro del proyecto organizativo y de

actividades de la Asociación de Microbótica de la Universidad de Valladolid

(AMUVa).

Los esfuerzos se van a centrar en:

Estudiar y proponer una arquitectura robótica adecuada.

Diseñar y construir una plataforma capaz de soportar el futuro

conjunto y las necesidades de movimiento.

Diseñar una placa electrónica basada en microcontrolador que

soporte el control del movimiento, a bajo nivel, así como otras

funciones básicas.

Estudiar y documentar las posibilidades que ofrece un

microcontrolador dsPIC33F como núcleo de la placa de control.

Abordar la configuración del microcontrolador en un modo suficiente

para que quede disponible de forma inmediata a algoritmos de

control.

Extraer conclusiones y lecciones aprendidas del trabajo realizado y

avanzar líneas de trabajo con las que continuar la labor.

Todo ello teniendo en cuenta la austeridad de medios y presupuesto

con que se cuenta.

1.6. Estructura de la memoria En los capítulos sucesivos se desarrolla el diseño y la construcción de los

sistemas que forman la plataforma robótica.

En el segundo capítulo se plantean distintos enfoques para el problema desde

la teoría de arquitectura robótica.



En el capítulo tres se analizan las consideraciones sobre forma y dimensiones

de los componentes que forman el robot para plantear una arquitectura física y

llevar a cabo el diseño mecánico. Se plantean distintas alternativas para vehículos

con ruedas y se razona la elección realizada.

Se describen los requisitos para los motores del robot, y se diseñan las piezas

necesarias para servir de armazón al conjunto.

En el cuarto capítulo se aborda la arquitectura de los sistemas electrónicos que

controlan el funcionamiento del robot y se desarrolla el diseño y construcción de

todo el sistema de tracción del robot,

En el capítulo cinco se presenta la elección de un microcontrolador adecuado a

la tarea de gestionar el control de tracción del robot. La adaptación a sus funciones

específicas en esta aplicación se realiza mediante la configuración de sus

periféricos, que son descritos al objeto de servir de guía para el desarrollo de

aplicaciones utilizando el robot como soporte. El gobierno del microcontrolador se

encarga a un programa de control, para el que se explican las herramientas de

desarrollo y el lenguaje de programación utilizado.

En el sexto capítulo se comienza por exponer las pruebas realizadas sobre

prototipos de los sistemas diseñados, y se continúa con la descripción de los

ajustes y pruebas sobre el robot ya construido. Se hace hincapié en los ajustes

realizados para mejorar su desempeño en el movimiento.

En el capítulo siete se hace un estudio económico para valorar los recursos

materiales y humanos que han sido necesarios para llevar a cabo este proyecto.

En el capítulo ocho se concluye la memoria con las conclusiones sobre los

trabajos realizados y se apuntan las líneas de interés para futuros desarrollos.

Arquitectura del Robot 15


2. Arquitectura del Robot Se desea elaborar el modelo de un robot móvil autónomo para desarrollar una

serie de funciones habituales, en este caso para la competición EUROBOT, sin

pérdida de generalidad.

Resulta intuitivo que, para cumplir unos objetivos previamente marcados, será

necesario que el robot adquiera información del entorno, la procese y lleve a cabo

acciones tales como movimientos, manipulación de objetos, y síntesis de

información.

Por tanto, los elementos básicos que lo hacen posible se podrán clasificar en:

Sensores: todo elemento o sistema cuyo papel es captar información

del estado físico del entorno o del propio robot.

Actuadores: aquellos elementos de los que el sistema robótico

dispone para modificar el plano físico.

Unidad de control: elemento que toma decisiones en base a unas

órdenes (objetivos) y a la información recibida de los sensores, y las

materializa en el plano físico gracias a los actuadores.

La unidad de control podría ser de muy diversa naturaleza (sistema neumático,

electromecánico, electrónico). Sin embargo, por sus superiores prestaciones el

sistema de control suele recaer en medios electrónicos.

Asumiendo por tanto un sistema de control electrónico, existe la opción de

implementar las funciones de control por medios hardware o software ( la función

de control se implementa sobre un soporte genérico gracias a un programa

específico).

En la actualidad para cualquier sistema con una cierta complejidad resulta

ventajoso implementar el control por software sobre un dispositivo programable

(FPGA, microprocesador, microcontrolador), abstrayendo buena parte de la capa

física de los componentes electrónicos gracias al código.

Se incidirá en esto en el apartado dedicado a la arquitectura hardware.



En este punto, queda claro que para la aplicación que nos ocupa, será el

software o código quien determine cómo se dispone de los recursos del sistema

para llevar a cabo las tareas.

Dependiendo de la complejidad del diseño, será necesario abordar el problema

en niveles de abstracción que lo hagan más manejable. La arquitectura de control

establecerá un sistema jerárquico de estos niveles sobre los que se implementará

el código de control.

A lo largo de la historia de la robótica se han seguido tres corrientes

principales:

Arquitecturas de descomposición funcional (o deliberativas).

Arquitecturas reactivas

Arquitecturas híbridas

En realidad, cada corriente se divide en un número amplio de arquitecturas de

distinta naturaleza, y podrían hacerse otras muchas clasificaciones. Se expondrán a

grandes rasgos de forma que se ilustre la elección de una arquitectura adecuada

para el robot que nos ocupa.

Aunque en cualquier época se han aplicado soluciones basadas en todas ellas,

cada arquitectura ha predominado en un determinado momento según el estado de

la técnica. Aquí se exponen de forma casi cronológica, coincidiendo con la

evolución del grado de madurez sobre las ideas más intuitivas.

2.1. Arquitecturas de descomposición funcional

2.1.1. Arquitecturas PPA

Los primeros enfoques en la arquitectura del control fueron bastante intuitivos y

se basaron en el concepto de bucle PPA (Percepción, Planificación, Acción), SPA

(Sense, Plan, Act) en literatura inglesa.

Se basa en dividir todo el sistema en tres módulos que, por analogía con los

elementos funcionales básicos antes descritos, realizan tareas de percepción,



procesamiento (o planificación) y acción. Mediante un sencillo bucle puede hacerse

que el robot transforme las percepciones en actos, utilizando únicamente estos tres

módulos, según se representa en la Ilustración 1.

El módulo de percepción obtiene los datos de los sensores, y los procesa, para

darlos en formato adecuado para el módulo de procesamiento. Por tanto este

módulo transforma los datos de entrada (transforma su dominio o filtra datos

indeseados) y crea un canal de comunicación entre la CPU y los sensores.

El módulo de procesamiento recibe los datos del módulo de percepción y los

procesa en concordancia con los objetivos programados. Su salida será una serie

de órdenes para el módulo de acción.

Finalmente, el módulo de acción ejecuta las órdenes recibidas desde el módulo

de procesamiento, accediendo directamente a los actuadores del robot, creando un

canal de comunicación entre éstos y la CPU o adecuando niveles de señal.

Ilustración 1. Arquitectura sensor-control-actuador

El precursor de esta arquitectura fue el robot Shakey [6], desarrollado entre

1966 y 1972 en el SRI (Standford Research Institute). Es considerado el primer

robot capaz de actuar en base a razonamientos (frente a órdenes puras).



2.1.2. Arquitecturas basadas en pizarra

Los sistemas de pizarra han demostrado ser muy prácticos en el diseño de

arquitecturas de control de robots móviles, aunque en general las soluciones más

prácticas son las híbridas que combinan estas ideas con conceptos de otras

arquitecturas.

Entre los trabajos realizados con arquitectura basada en pizarra destacan los

trabajos que desde 1985 viene realizando el investigador Hayes-Roth [7].

Básicamente, un sistema de pizarra consta de tres elementos: la pizarra

propiamente dicha, los agentes que utilizan la pizarra, y un módulo de planificación

de los accesos a la pizarra.

Ilustración 2. Esquema básico de arquitectura basada en pizarra

La pizarra es una memoria compartida a la cual tienen acceso varios procesos

(los agentes), coordinados por medio de un proceso especial (planificador). Sobre

la pizarra se almacena toda la información sensorial que, en muchos casos, pasará

previamente por un módulo de percepción que realizará una fusión sensorial.

En esta fusión sensorial se combina la información de distintos sensores,

dándoles prioridad allí donde son más efectivos.



Los sistemas de pizarra facilitan el trabajo de varias tareas en paralelo, pero

tiene inconvenientes como el cuello de botella que supone la pizarra en sí misma.

2.2. Arquitecturas reactivas Las arquitecturas deliberativas tenían una latencia enorme, muy poco

adecuadas para sistemas que tuvieran que adaptarse rápidamente a cambios en el

entorno, o simplemente desenvolverse en entornos desconocidos. Difícilmente se

podían abordar obstáculos móviles, en otras palabras, reaccionar.

El origen de la incapacidad de esta arquitectura era la cognición como

intermediaria entre la percepción y la acción.

En 1987, Brooks [8] propone una visión radicalmente diferente, al introducir el

concepto de arquitectura reactiva, defendiendo que es posible simular un

comportamiento inteligente sin necesidad de tener un modelo del entorno.

Brooks basó sus ideas en la observación del comportamiento de los insectos,

quienes sin disponer de complejos modelos del mundo que les rodea, actúan en

cada momento movidos por los estímulos que reciben del exterior a través de sus

sentidos.

Extrapolando esto a la arquitectura de control, supone que en cada momento,

sólo un módulo tome el control, por lo que, al ser módulos muy sencillos, la

respuesta podrá ser rápida.

La decisión de qué módulo toma el control no la realiza ningún proceso

planificador, sino que estará preestablecida (de igual modo que, por ejemplo, los

actos reflejos se imponen a los voluntarios al desencadenarse).

Las arquitecturas de descomposición funcional se basaban en una división

vertical del problema de control. Dicha división define comportamientos o capas de

competencia que son incapaces de controlar al robot por sí solas.



Ilustración 3. Competencias verticales de arquitecturas clásicas

Cabe resaltar que los sistemas clásicos trabajan de forma secuencial.

La llamada Arquitectura Subsumption propuesta por Brooks [8] está compuesta

por niveles de comportamiento con entradas y salidas, cada uno de los cuales es

considerado como una capa de la arquitectura. Propone un enfoque horizontal que

difiere del enfoque vertical clásico.

Ilustración 4. Enfoque horizontal de la arquitectura Subsumption

Es importante resaltar que estas capas trabajan de forma independiente y

paralela. Las capas superiores definen comportamientos más complejos que las de



abajo, de modo que las superiores pueden “subsumir” (inhibir o suprimir) datos de

capas inferiores.

Ilustración 5. Capas de comportamiento de la arquitectura Subsumption

2.3. Arquitecturas híbridas Las arquitecturas reactivas solucionan muchos de los problemas inherentes a

las arquitecturas deliberativas, pero también introducen nuevos inconvenientes

importantes.

Conviene por ello recapitular sobre los principales pros y contras de las

soluciones vistas:

La arquitectura PPA tiene a su favor el que utiliza modelos de alto nivel,

adecuado para algoritmos complejos. Como principal inconveniente es su dificultad

para reaccionar ante cambios bruscos del entorno. El entorno puede cambiar en el

relativamente largo tiempo que requiere planificar acciones a partir de la

información recibida.

Las arquitecturas de pizarra introducen el procesamiento en paralelo (más

rápido), pero el acceso a memoria compartida es un cuello de botella.

Por último, las arquitecturas reactivas permiten una capacidad de reacción muy

rápida, y son necesarios diseños hardware y software más sencillos. Por el



contrario, al no disponer de modelos del entorno limita mucho la funcionalidad del

robot para tareas que requieran cognición. Su diseño es además difícil de modificar.

Teniendo en cuenta todo esto, las arquitecturas más generalizadas

actualmente son aquellas que utilizan una solución híbrida, tomando lo mejor de

cada opción.

La solución reactiva se ha mostrado eficaz ante cambios repentinos del

entorno, por lo que sus ideas suelen estar presentes en cualquier solución híbrida,

como base, teniendo por encima otras capas con modelos del entorno y algoritmos

de planificación de alto nivel.

2.4. Arquitectura propuesta para este proyecto robótico

La arquitectura no juega un papel importante para robots que realizan tareas

simples, entendido como las que pueden ejecutarse de forma atómica.

Sin embargo, es muy importante para robots que van a realizar tareas

complejas.

Estudiar las diferentes arquitecturas de control que se han propuesto a lo largo

de la historia es una herramienta potente de cara a plantearse cómo abordar la

arquitectura del robot para mejor satisfacer objetivos. En general la mejor opción es

dividir en tareas simples que se coordinan de cierta manera.

Para mejor comprensión de las implicaciones de la arquitectura de control, se

plantea un caso representativo de nuestro robot satisfaciendo sus objetivos al

cumplir estas dos tareas:

Posicionarse en las inmediaciones de un objeto

No colisionar con obstáculos

Parte de una posición cualquiera, y dispone de una red sensorial y de

actuadores suficientes para abordar las tareas. En el recorrido natural entre su

origen y destino hay un obstáculo.



Enfocando el problema con una arquitectura de control deliberativa, puede

plantearse esta explicación coherente de sucesos:

El sistema sensorial detecta el objeto al que debe aproximarse. La tarea

“detección de objeto” se puede interpretar como un procesado de la información de

los sensores, contraste con unos patrones, y aceptación o rechazo de la

información como representativa del fenómeno “presencia de objeto”. Del mismo

modo, la tarea “detección de obstáculo” hace lo propio con otra naturaleza de

objetos.

Estas tareas no tienen mando sobre la tracción. La tarea “navegación” es

informada por “detección de objeto”, y paralelamente por “detección de obstáculo” y

en base a la información que toma (en exclusiva o de forma compartida) de los

sensores, y en base a su modelo del entorno o mapa, genera una trayectoria,

dando órdenes pertinentes a la tarea “tracción”, quien lo convierte en comandos de

bajo nivel de velocidad y giro de las ruedas.

Este bucle se repite de forma indefinida, de forma que las tareas globales se

realizan mediante ejecución secuencial de otras.

Por tanto, para cada paso que da el robot hacia su objetivo de alcanzar el

objeto, hay una etapa de adquisición de información, procesado junto al modelo del

entorno, y finalmente orden de movimiento.

Esto puede permitir alcanzar los objetivos. Pero se observan varias

debilidades:

Entre el instante de adquisición de información y el de orden de

movimiento, media un tiempo de procesamiento del entorno, de

patrones y otros que exige capacidad de computación.

El sistema no podrá reaccionar ante cambios producidos en ese

período de procesamiento, luego será vulnerable en la medida del

tamaño de ese período.

Las fortalezas del modelo serán:

Puesto que se trabaja con un modelo del entorno, las decisiones

pueden ser “óptimas”: elabora la trayectoria más corta teniendo en



cuenta el obstáculo. Además en cada instante sólo se ejecuta una

tarea, Una sucesión secuencial de tareas es sencilla de programar y

consume pocos recursos.

Como alternativa desde el enfoque de una arquitectura reactiva, el

desarrollo del control podría ser como sigue:

Las tareas “detección de objeto” y “detección de obstáculo” implementan las

dos tareas básicas del robot.

La tarea “detección de objeto” se vale de la información de los sensores para

ordenar a los motores comandos de movimiento que conduzcan al robot hacia el

objeto. “Muévete hacia allí”.

Paralelamente la tarea “detección de obstáculo” se vale de la misma (pizarra) u

otra información para ordenar a los motores esquivar el objeto. “Apártate de ahí,

moviéndote hacia allá”

Por tanto ambas tareas son suficientes para comandar los motores, y por ello

pueden entrar en conflicto. El conflicto se puede resolver de distintas manera, la

más sencilla un “todo para el vencedor”, por ejemplo, priorizando la seguridad de la

tarea detección de obstáculos que, una vez completada, devuelve el control a

“detección de objeto”.

Las fortalezas de esta arquitectura son evidentes: en todo instante se está

ejecutando tanto la tarea de seguridad como la de objetivo final, en base a

procedimientos sencillos y rápidos. La velocidad de respuesta frente a cambios es

muy rápida.

No se necesita generar un modelo del entorno, y en ese sentido se necesitan

menos recursos.

Sin embargo aparecen otras debilidades: al no disponerse de un modelo del

entorno, no se planifica, y las decisiones no serán necesariamente óptimas.

Además de que las tareas se ejecutan de forma concurrente (en paralelo), y eso

supone en general la figura de un planificador y despachador de tareas (un sistema

operativo), por lo que la programación será más compleja o cuanto menos, habrá

que subir de nivel de abstracción.



Lo ideal parece disponer de la optimización que proporciona el modelo

deliberativo junto a la capacidad de respuesta del reactivo. Y eso es lo que se

va a plantear: un modelo híbrido con rasgos específicos de algunas

arquitecturas básicas según un escalonamiento por niveles de abstracción.

2.4.1. Niveles de la arquitectura de control

Al referirnos en este apartado a los niveles de la arquitectura de control, lo

hacemos con intención de planificar lo que será el sistema robótico completo, para

pasar a desarrollar como entregables de este proyecto, sistemas correspondientes

al más bajo nivel (niveles físico y reactivo).

Comenzando por el nivel físico como el responsable de las tareas más

básicas, al más bajo nivel, se irán implementando tareas más complejas, primero

en un nivel reactivo, responsable de la respuesta del robot a estímulos que

requieren respuesta en tiempo real (por ejemplo, todas las tareas relativas a

seguridad, movimiento del robot, detección de obstáculos o de hitos y tareas

específicas desempeñadas por manipuladores o herramientas).

Por encima, en un nivel deliberativo se gestionarán las tareas de navegación

del robot sobre el tablero de juego.

Por último, en el nivel superior de control, se gestionará la planificación global

de tareas y la estrategia de juego, a través de un secuenciador.

Entre estos niveles se deben crear otros de enlace que relacionen los objetos

creados en un nivel de abstracción con los del nivel siguiente.

Entre el nivel físico y el reactivo, existirá una capa software a bajo nivel que

relacione los componentes físicos con los comportamientos reactivos. Como

ejemplo, puede citarse la configuración del módulo PWM del microcontrolador, el

controlador de interrupciones y los sensores de presencia cercana para que ante el

estímulo de detección de un obstáculo la acción inmediata sea la detección del

robot.

Otra de las tareas que deben implementarse al más bajo nivel es la gestión del

giro de los motores que soportan la tracción del robot, de modo que resulte algo

transparente a los niveles superiores, por analogía a como ocurre en las personas



la acción de desplazarse: a pesar de ser un acto voluntario, el movimiento de las

piernas es casi “automático”.

En el nivel deliberativo será necesario desarrollar en el robot estructuras más

complejas:

Modelo de sí mismo.

Modelo del entorno (espacio de juego) en el que el robot desarrollará

sus funciones: zonas, elementos de juego, obstáculos, etc.

Modelo del oponente (agente móvil). Las bases de la prueba se

preveen alojamientos para un sistema de balizas que permitan

localizarse a uno mismo y al contrario. El modelo del oponente

puede partir de uno estático simple (posición), crecer hacia otro

dinámico (añadiendo su dirección de movimiento) e incluso estimar

su estado o estrategia de juego.

Base de datos de conocimiento y aprendizaje: el modelo del entorno

debe ser dinámico y aprovechar la información que se capture. En

este punto cobra especial interés la arquitectura de pizarra, en el

que los distintos bloques anotan en una memoria común la

información que capturan, que será luego seleccionada por otros

según prioridades.

Se implementará la tarea de navegación deliberativa, entendida como el

procesamiento de la información de localización del robot y de localización del

destino para definir trayectorias de recorrido.

Para trabajar de forma eficiente en este nivel lo adecuado sería hacerlo a alto

nivel de abstracción, con tareas concurrentes, para lo que será necesario un

sistema operativo de soporte.

Por último, un secuenciador será quien al más alto nivel planifique la ejecución

de la estrategia de juego, determinando cuáles deben ser las tareas activas en cada

etapa, y marque su comienzo y su fin.

En la siguiente gráfico se pretende resumir la naturaleza de la arquitectura que

se va a adoptar. El desarrollo y concreción de los niveles se irá realizando a medida



que el robot vaya creciendo, de modo que los niveles más básicos serán los que

primero se desarrollen mientras los niveles superiores sólo se presentan de forma

somera.



NIVEL

DE ABSTRACCIÓN

NIVEL FÍSICO - Chásis del conjunto y estructura mecánica - Sensores y actuadores - CPU y periféricos - Sistema de alimentación - Sistema de conexiones internas y con el exterior

NIVEL REACTIVO - Conductas reactivas - Mecanismos de coordinación - Lectura de sensores - Integrador de órdenes

NIVEL DELIBERATIVO - Sistema operativo - Sistema de comunicaciones - Modelo del entorno - Modelo de sí mismo - Navegación - Aprendizaje de conceptos

NIVEL SECUENCIAL - Gestión de la estrategia general - Planificación de necesidades - Secuenciación de etapas - Aprendizaje de alto nivel (procedimientos)

SUBNIVEL DE ENLACE

SUBNIVEL DE ENLACE

SUBNIVEL DE ENLACE

ARQUITECTURA DEL ROBOT

Arquitectura Física y Diseño Mecánico 31


3. Arquitectura Física y Diseño Mecánico

3.1. Arquitectura física Definir la arquitectura física del sistema consiste en fijar las especificaciones

en cuanto a:

Tamaño

Organización de los bloques en el volumen asignado

Principio de funcionamiento

Elección de materiales

Diseño de los componentes físicos.

teniendo en cuenta los aspectos mecánicos del robot y las interrelaciones

mecánicas de esos componentes.

Para las especificaciones de cualquier bloque físico, deben tomarse en

cuenta:

Función

Señales de control

Tamaño y peso

Consumo de energía

Organización espacial en el robot.

Para definir la arquitectura física de un robot, deben tomarse en cuenta las

condiciones del ambiente de operación impuesto por la aplicación del robot ya que

restringe o impide la utilización de ciertos fenómenos físicos para los mecanismos



de actuación, así como la captura y el almacenamiento de energía (y determina en

qué medida podrá autoabastecerse). En este caso, las normas previenen que el

espacio de juego es un medio con condiciones de ambiente no reguladas.

La arquitectura física del robot permite identificar los sistemas

electromecánicos necesarios para lograr las funciones deseadas. Entre los

parámetros típicos especificados para sistemas electromecánicos, se incluyen

fuerzas, desplazamientos, potencia, eficiencia o velocidades. También, es de vital

importancia considerar el costo de fabricación o adquisición de los sistemas y la

viabilidad de su fabricación o montaje con los procesos disponibles.

3.1.1. Plataforma móvil

Del mismo modo que en el resto de niveles de diseño, se pretende crear un

conjunto suficientemente versátil como para servir de soporte a una participación

genérica en EUROBOT. Será una tarea posterior, y que excede los objetivos de

este proyecto, el adaptar los sistemas a una determinada prueba anual y dotarlo de

herramientas para satisfacer tareas específicas.

Se pretende diseñar modularmente teniendo en cuenta las necesidades más

habituales tanto en el ámbito mecánico como en placas electrónicas y sistemas

auxiliares.

Una plataforma móvil servirá de base a todo el conjunto. En ella estará anclado

el sistema de tracción así como la estructura que sirva de soporte para los demás

bloques del robot.

Llegados a este punto es necesario definir la forma en que se dotará de

movimiento al robot.

Hay numerosas alternativas, de entre las que pueden citarse:

Tracción ápoda: imita la forma de moverse de seres reptantes. Un

proyecto interesante de este tipo es el robot-gusano cube [9].

Tracción n-poda: basado en un cierto número de patas, par en

general, que se mueven individualmente según una secuencia de

movimientos. Dentro de los de dos patas se encuentran los

humanoides, que imitan la forma humana. A partir de cuatro patas el

problema de la inestabilidad se consigue resolver con el concepto de



triángulo de estabilidad, encontrando interesantes proyectos de

fuente abierta como R4P[10], siendo frecuentes los robots

hexápodos para aplicaciones en los que el entorno es irregular. Un

ejemplo de este tipo es el del robot Melanie III [11].

Tracción mediante ruedas o cadenas: Existen diseños muy variados

también dentro de estas familias.

De entre los tipos expuestos, se descarta el uso de robots ápodos por

las restricciones que impone su fisonomía.

En cuanto a los robots con patas, aunque es extremadamente

infrecuente, sí ha habido ya en Eurobot casos de equipos que han

utilizado esta configuración, como el equipo francés XD [12]

participante en la edición EUROBOT 2011, desplegando estrategias

muy originales gracias a su modelo híbrido de patas con ruedas.

Ilustración 6. Robot XD Eurobot 2011

Los robots que utilizan patas para su desplazamiento, pueden presentar

problemas añadidos para mantener la estabilidad en movimiento, por lo que a

pesar de ser una opción atractiva, se descarta en base a la premisa de sencillez

que se ha adoptado.

Por último, los robots que se desplazan gracias al giro de sus ruedas o

cadenas son los más frecuentes debido a que son más sencillos de diseñar,

construir y controlar.

Por esta razón, encajan mejor con los objetivos que aquí se pretende alcanzar,

y se ha optado por este sistema.



En cuanto a la configuración espacial, es algo que suele variar año tras año,

pero como es lógico, en el nivel más cercano al suelo se encontrará la bancada

para el eje de las ruedas, unidas de forma directa o con una transmisión a los

motores. En la zona baja suele ser necesario disponer de espacio para albergar

mecanismos o manipuladores de los objetos de juego. En este aspecto es

conveniente prever flexibilidad en esta zona, y situar los bloques menos exigentes

en cuanto a su ubicación (placas electrónicas, sistemas auxiliares y alimentación)

en niveles superiores. Pero por otro lado, en pos de la estabilidad de la máquina,

habrá que encontrar un compromiso porque conviene que el centro de gravedad

quede lo más centrado y cercano al suelo que se pueda.

En cuanto al tamaño en planta, para las ediciones con un sólo robot las bases

exigen un perímetro menor de 1200 mm, que se puede extender hasta los 1400

mm si se decide desplegar apéndices.

Ilustración 7. Dimensiones en planta según normativa

Respecto a la altura y la organización de los bloques en el volumen asignado,

se imponen condiciones con objeto de permitir la ubicación e impedir la

perturbación de un sistema de balizas:



Ilustración 8. Altura permitida según normativa

3.2. Configuración de vehículos con ruedas

Los vehículos con ruedas son la solución más simple para conseguir movilidad

en vehículos sobre terrenos regulares, firmes y con buena adherencia, condiciones

que cumple el terreno de juego de la competición.

Partiendo de esta base común, las diferentes configuraciones que pueden

adoptar las ruedas confieren capacidades muy distintas a los vehículos que las

incorporan.13

3.2.1. Configuración Ackerman o “tipo coche”

Es la utilizada en los automóviles y vehículos de cuatro ruedas convencionales.

Se basa en dos ruedas traseras (tractoras o no) que giran en un eje

perpendicular a la dirección longitudinal del vehículo, mientras que la dirección

recae sobre las ruedas delanteras, que pueden orientar su eje de giro.

Para eliminar el deslizamiento que provocan los sobrevirajes de la plataforma,

la rueda delantera interior gira un ángulo ligeramente superior a la rueda exterior,

de forma tal que los ejes de prolongación de las ruedas delanteras (directrices) se

cortan en el CIR (centro instantáneo de rotación), que se sitúa en la prolongación

del eje de las ruedas traseras (en general, motrices).

Leyenda

1. Baliza fija LxWxH: 80x80x160 mm

2. Baliza móvil LxWxH 80x80x80 mm 3. Mástil: área bajo el soporte de baliza móvil



Las trayectorias que trazan los centros de las ruedas en ausencia de

deslizamiento son circunferencias concéntricas en el CIR.

En los vehículos con configuración Ackerman, se presentan dos ángulos de

giro, uno en cada rueda directriz, por lo que para simplificar el diseño mecánico y el

control se suele unificar este ángulo. Esto introduce una inconsistencia en el

modelo pues existirá necesariamente deslizamiento, por lo que para minimizar sus

consecuencias, estos vehículos adoptan radios de giro mayores que en otras

configuraciones, en detrimento de la maniobrabilidad.

Ilustración 9. Configuración Ackerman

3.2.2. Configuración tipo triciclo

Este sistema de locomoción se basa en una rueda delantera que sirve tanto

para la tracción como para el direccionamiento, mientras el eje trasero cuenta con

dos ruedas laterales que giran libremente.

La maniobrabilidad es mayor que en la configuración Ackerman debido a tener

una única rueda de dirección, pero puede tener mayores problemas de estabilidad y

de pérdida de adherencia.



Ilustración 10. Configuración tipo triciclo

3.2.3. Tracción diferencial

En esta configuración el direccionamiento se consigue gracias a la diferencia

de velocidad de las ruedas tractoras laterales.

Dos ruedas paralelas montadas en un mismo eje son propulsadas de forma

independiente, de modo que la velocidad del centro de cada rueda sea siempre

paralela a la rueda y proporcional (siendo el radio el factor de proporcionalidad) a la

velocidad de giro de esa rueda.

Por tanto, el Centro Instantáneo de Rotación (CIR) del vehículo se encuentra

siempre sobre la dirección del eje de las ruedas, a una distancia del centro del eje

que depende exclusivamente de la velocidad absoluta de los centros de las ruedas.

El vehículo con esta configuración de sus ruedas puede cambiar de orientación sin

desplazarse (girando sobre sí mismo), pero no puede desplazarse en la dirección

del eje de las ruedas.

Las velocidades de giro de estas ruedas serán los parámetros de control.

Para conferir estabilidad al conjunto se suelen proveer apoyos adicionales

como ruedas locas.

El modelado cinemático de esta configuración es sencillo y fácil de controlar,

por lo que de forma directa o con algunas modificaciones es muy utilizado.



Ilustración 11. Configuración diferencial

3.2.4. Configuración con ruedas o pistas deslizantes (Skid Steer)

Se disponen varias ruedas en cada lado del vehículo que actúan de forma

simultánea, ya sea directamente o bien solidarizadas por bandas deslizantes

(cadenas). El movimiento será el resultado de combinar las velocidades de las

ruedas de la izquierda con las de la derecha.

Se utiliza especialmente para movimiento sobre terrenos irregulares o con

menor adherencia, lo que por otro lado permite el deslizamiento lateral de las

ruedas para lograr el giro del vehículo, con buen rendimiento.

En la ilustración Ilustración 12 se muestra el aspecto típico de esta

configuración.



Ilustración 12. Robot AURIGA, universidad de Málaga

3.2.5. Configuración de ruedas síncronas

Consiste en la actuación simultánea de todas las ruedas, que giran a la vez en

torno a su eje y se orientan en una misma dirección gracias a un mecanismo de giro

en el eje vertical.

Las configuración más típica es la de tres ruedas que se acoplan en los

vértices de un triángulo equilátero, bajo una plataforma cilíndrica.

La principal ventaja de este sistema es que permite que el robot se desplace

en cualquier dirección.

Ilustración 13. Configuración de ruedas síncronas



3.2.6. Tracción omnidireccional

Este sistema de tracción se basa en la utilización de tres ruedas directrices y

motrices. En esta configuración el móvil dispone de tres grados de libertad, por lo

que se puede realizar cualquier movimiento en el plano, y posicionarse en

cualquier posición en cualquier orientación. No presenta limitaciones cinemáticas.

Esto se consigue gracias a un tipo particular de ruedas que gracias a unas

hileras de rodillos pueden trasladarse en dirección perpendicular a la de rodadura.

Así, gracias al giro a velocidades independientes de tres ruedas cuya

orientación difiere 120º se puede obtener cualquier movimiento.

Ilustración 14.Rueda sueca u omnidireccional

Ilustración 15. Robot omnidireccional



3.2.7. Configuración elegida. Justificación

Una vez descritas las configuraciones más habituales para la plataforma móvil

de un vehículo con ruedas, se procede a valorar las distintas opciones y elegir una

de ellas.

En primer lugar, respecto a las exigencias impuestas por el terreno de juego,

puesto que es una superficie lisa, firme y con buena adherencia, en la que no hay

que transitar por obstáculos, no será necesario utilizar orugas ni un número elevado

de ruedas.

Las tareas típicas que deben realizarse incluyen recoger, transportar y

depositar objetos mediante manipuladores que requieren que el robot aborde el

objeto a una distancia corta y en una orientación determinadas. Por ello, se

necesita que la configuración permita una elevada maniobrabilidad, siendo muy

recomendable que el vehículo pueda rotar sobre su centro.

Teniendo esto en cuenta, se descartan las configuraciones Ackerman y tipo

triciclo.

La configuración de ruedas síncronas permitiría trasladarse en cualquier

dirección, pero no permite el giro sobre sí mismo, y por tanto exigiría que para

orientar un manipulador éste estuviera montado sobre una plataforma giratoria “tipo

torreta”, lo que supone una complicación no deseable y es descartada también.

Hasta este punto, cumplen requisitos las configuraciones diferencial, skid-steer

de varias ruedas y la tracción omnidireccional.

Esta última es la más maniobrera pues permite teóricamente tanto el giro sobre

sí mismo del vehículo (spin) como el movimiento en cualquier dirección para

cualquier orientación del vehículo. Sin embargo, la cinemática es más complicada,

ya que el movimiento se consigue con 3 grados de libertad (tres motores que giran

independientemente), exige ruedas especiales y una ubicación de estas muy

concreta en la base del vehículo.

Por el contrario, la configuración diferencial no permite más que el movimiento

en la dirección en que el robot está orientado, y necesita apoyos auxiliares (como

ruedas locas, patines, bolas de castor…) pues con dos ruedas la plataforma no

sería intrínsecamente estable. Pero su cinemática con dos grados de libertad es

sencilla y la ubicación de sus ruedas es fácil de modificar.



La configuración skid-steer de varias ruedas es una variante de la diferencial

que por presentar cuatro o más ruedas no requiere los citados apoyos auxiliares.

No será rigurosamente válido el sencillo modelo cinemático de la diferencial puesto

que para que exista el giro es imprescindible el deslizamiento de las ruedas, pero sí

puede establecerse un modelo diferencial aproximado. Además, aunque supone

una dificultad para el giro, el que disponga de varias ruedas paralelas en cada lado

del vehículo lo hace más robusto en la descripción de trayectorias rectilíneas que la

configuración diferencial con una rueda por lado.

En definitiva, se adoptará una configuración skid-steer de cuatro ruedas,

con dos ruedas paralelas en cada lado, y se utilizará un modelo cinemático

diferencial aproximado, conscientes de que no se cumple la hipótesis de no

deslizamiento de las ruedas en el giro, pero que puede ser una aproximación

razonable que habrá que validar experimentalmente.

3.3. Diseño mecánico de la plataforma móvil

Llegado este punto se ha concretado ya la configuración de la plataforma

móvil, con dos bloques paralelos de dos ruedas cada uno. En el modelo cinemático

diferencial aproximado que se pretende utilizar, se tienen dos grados de libertad: i

y d , que representan el ángulo girado por la rueda ideal equivalente del lado

izquierdo y derecho respectivamente. Al implementar el sistema real con dos

ruedas por lado, además de realizar las transformaciones geométricas pertinentes,

será necesario accionar las dos ruedas de cada lado de forma solidaria entre sí.

Vamos a considerar que, a efectos de sincronismo de ambas ruedas, el hecho

de que estén montadas sobre ejes rígidamente amarrados a un bastidor y que

pueden considerarse sólidos rígidos, junto a una hipótesis de que no hay

deslizamiento de las ruedas sobre el suelo en dirección tangencial a ellas, asegura

que ruedas de idéntico radio se moverán a la misma velocidad angular.



Esta será una restricción cinemática, de modo que no depende de la

naturaleza del accionamiento de las ruedas.

Nótese que la hipótesis de no deslizamiento en dirección tangencial a las

ruedas no implica que sí pueda haberlo en dirección perpendicular a su plano en el

punto de apoyo, y que de hecho lo habrá necesariamente para lograr giros.

Podemos optar por accionar las dos ruedas de un bloque con un único motor

que entregará todo el par y potencia necesarios, o accionar cada rueda con un

motor, de modo que serán necesarios varios motores que podrán dar sólo una

fracción del par y la potencia (por tanto, podrán ser menores).

Con intención de crear una mecánica muy modular y versátil, se decide utilizar

un motor para accionar cada una de las dos ruedas de un mismo bloque. Esto tiene

el inconveniente de necesitar más motores, pero ventajas como que puede

utilizarse una tracción mecánica escalable, según las exigencias de la competición

de cada año.

Por aclarar este punto, es necesario hacer constar que, en general:

la duración de los partidos y las dimensiones de la pista de juego

cada año son similares.

El número de desplazamientos y su dimensión característica,

aunque muy dependientes de la estrategia de juego, también son

análogos.

Las dimensiones permitidas para el robot son también similares (por

lo que su masa a priori no tiene porqué ser muy distinta unos años u

otros).

Sin embargo, el tamaño, y sobre todo, el peso de la carga y

manipuladores que tenga que portar el robot es muy variable.

Por todo esto puede concluirse que la velocidad objetivo con que el robot

pueda desempeñar sus movimientos no varía de unos años a otros (en general, el

tiempo es limitante, y la velocidad deberá ser suficiente). Por tanto, la velocidad

máxima de giro de las ruedas necesaria no variará demasiado de unos años a

otros. Pero la carga que portará la plataforma sí será menos homogénea entre

distintos años, por lo que para lograr aceleraciones del mismo orden unos y otros

años, el par entregado a las ruedas será muy dependiente de esta carga, y esto



puede traducirse en que a mayor carga, mayor par necesario, lo que según las

curvas típicas de los motores CC que se van a utilizar, corresponde con

velocidades menores.

Podría utilizarse un único motor capaz de cumplir en las situaciones más

exigentes, que trabaje de forma holgada y por tanto a una velocidad objetivo poco

sensible a cambios de par demandado. Como alternativa, se plantea la utilización

de una tracción mediante motores “menores” idénticos en paralelo, que girarán a

velocidades solidarias y que entregarán un par equivalente a la suma de sus pares.

En general, la asociación de motores en paralelo dará una curva par-velocidad

más rígida, esto es, en el sistema equivalente la velocidad será menos sensible al

par demandado por la carga.

Teniendo todo esto en consideración, se ha diseñado un sistema mecánico

para la plataforma móvil que está formada por los siguientes componentes básicos:

Bastidor

Motores-encóder

Transmisiones

Ejes, ruedas y rodamientos.

Piezas de unión desmontable, separadores y auxiliares

La figura a continuación es una recreación tridimensional de la mecánica

diseñada:



Ilustración 16. Plataforma robótica diseñada

Estos elementos están agrupados en cuatro bloques, dos por cada lado,

completamente modulares, de modo que pueden instalarse de forma fácil y rápida

mediante uniones desmontables sobre una plataforma o estructura específicamente

diseñada para la prueba de cada año.

3.3.1. Bastidor

El bastidor está formado por un conjunto de piezas cuya misión es servir de

soporte al resto de componentes, determinando por tanto la geometría y

configuración espacial del conjunto.

Se deseaba diseñar un sistema mecánico lo más versátil posible, de modo que

permitiese adaptarse a las necesidades de cada año de forma sencilla y rápida.

Debía ser robusto para el buen funcionamiento de las transmisiones, y a la vez

permitir pequeños ajustes para optimizar el conjunto. Y todo ello con el menor peso

posible, ya que esto penaliza el desempeño de la tracción.

A estas consideraciones se unieron otras “de mundo real” tales como la

disponibilidad del material con que se fabricase así como de los medios de

fabricación requeridos, y todo ello a un precio asequible, y por ello se decidió

diseñar piezas planas en aluminio de 3mm de espesor para ser cortadas por láser.



El aluminio [14] es un metal plateado muy utilizado tanto en estado puro como

aleado, tan sólo superado por las aleaciones ferrosas.

Respecto a sus propiedades mecánicas cabe destacar que en estado puro es

un metal blando y de una baja resistencia mecánica (límite elástico de 160-200

MPa), por lo que no es adecuado para aplicaciones estructurales. Sin embargo, a

través de su aleación admite tratamientos que mejoran notablemente sus

propiedades, hasta alcanzar valores que pueden alcanzar los 500 MPa. Y sobre

todo, destaca por su baja densidad (aprox. 2700 kg/m3), lo que lo hace

especialmente interesante en aplicaciones móviles en las que el peso penaliza en

consumo energético.

Las chapas de aluminio se obtienen en muy diversos grosores por laminación,

y mediante control numérico, son cortadas con precisión por un haz láser de alta

energía, consiguiendo acabados de calidad a precios asequibles.

Finalmente se diseñó para el bastidor un conjunto formado por cuatro piezas

distintas que se muestran a continuación:

Pieza P3

En el centro de la pieza, en un orificio circular, va encajado un rodamiento de

bolas. Los tres orificios circulares que lo rodean sirven para alojar tornillos o

separadores. El cuarto orificio sirve para alojar el tornillo que mantiene la pieza P5

paralela en un cierto ángulo.

Las dos pestañas inferiores deben doblarse para quedar a 90º, dejando

sobresalir la pestaña central. Con estos elementos la pieza puede amarrarse

firmemente perpendicular a un soporte.



Ilustración 17. Pieza P3

Pieza P4

Esta pieza se sitúa entre las piezas P3 y P5 para separarlas, alojando en su

interior las tuercas correspondientes, quedando dichas tuercas estrechamente

circunscritas por la circunferencia interior, de manera que no pueden aflojarse sin

retirar esta pieza.


Pieza P5

La pieza P5 se sitúa pegada a la pieza P4. Permite el paso a su través del eje

de la rueda, en distintas posiciones angulares, quedando fija gracias a un pasador a

través del rasurado circular y de otro tornillo pasador para el que será necesario

realizar un taladro en el lado simétrico del del rasurado, según la posición angular

en que se desee fijar.

Las ranuras superiores permiten su fijación a la pieza P6 mediante tornillos y

tuercas, formando un conjunto de longitud variable.




Pieza P6

A esta pieza va atornillado el frontal de la reductora del conjunto motor-

reductora-encóder, en varias posiciones, de manera que como el eje de salida de

dicha reductora es excéntrico, permitirá que la altura total del conjunto (regulable

por deslizamiento de las piezas P5 y P6) varíe para una única distancia entre ejes.




Ilustración 21. Bloque motor

Ilustración 22. Vista explosionada de un bloque motor



3.3.2. Conjunto encóder- motor- reductora

Los motores constituyen el núcleo del sistema mecánico. Realizan la

transformación de energía almacenada en energía mecánica útil para dotar de

movimiento al robot.

Dependiendo de la forma de energía que el motor convierte en movimiento,

existen motores térmicos, eléctricos, neumáticos y de otros tipos.

Las bases prohíben expresamente la utilización de motores de combustión,

que generan gases y humos, ya que la competición se desarrolla en un espacio

interior.

Se hace mención expresa a limitaciones de presión que pueden albergar

depósitos de aire comprimido, así como de energía almacenada de esta manera, de

modo que es una posibilidad de cara al accionamiento puntual de actuadores, si

bien se descarta el uso de estos motores para tracción y serán motores eléctricos

los que accionen la mecánica.

Dentro de los motores eléctricos hay nuevamente numerosos tipos. Tendremos

una primera clasificación según si funcionan alimentados con corriente continua o

alterna.

El robot pretende ser un sistema autónomo, por lo que dispondrá de un

sistema de almacenamiento de energía en baterías electroquímicas. Por tanto, la

tensión y corriente disponibles de forma inmediata serán continuas, y por

simplicidad utilizaremos motores de corriente continua.

Motor de corriente continua

Los motores de corriente continua, en lo sucesivo motores CC (ó DC en

literatura inglesa) fueron los primeros motores eléctricos en utilizarse, y han sido

predominantes en sistemas de tracción hasta que en tiempos recientes los sistemas

electrónicos de conmutación han permitido la regulación eficaz de los motores de

alterna, en general más baratos y fáciles de mantener.



Ilustración 23. Esquema de un motor de corriente contínua. Fuente:[15]

Los motores de corriente continua son máquinas eléctricas con dos circuitos

eléctricos (inductor e inducido) entre los que media un circuito magnético. Para las

pequeñas dimensiones y potencia de esta aplicación, en vez de un circuito eléctrico

inductor se utilizan imanes permanentes para crear el campo magnético de

excitación.

Normalmente los imanes se ubican en el estator. Es necesario conducir la

corriente al inducido, en el rotor, lo que se consigue gracias a la conmutación de un

sistema de escobillas y delgas, cuyo inevitable deterioro es causante de muchos de

los inconvenientes de estos motores.

Los motores CC de imanes permanentes presentan como principales ventajas:

Sencillez constructiva

Facilidad de regulación de velocidad (basta variar la tensión de

alimentación).

Inversión del sentido de giro invirtiendo la polaridad

Funcionan como generador al aplicarles un par en el eje.

Como principales inconvenientes cabe citar:

No se tiene un control inherente de la posición del eje, por lo que

debe crearse un servosistema para movimientos de precisión.

La conmutación de las escobillas produce un deterioro rápido de sus

prestaciones e introduce mucho ruido eléctrico en la red de

alimentación.



Otro inconveniente que en realidad es común a casi todos los motores

eléctricos es que en su funcionamiento normal, el motor CC entrega la potencia a

un régimen de varios miles de revoluciones por minuto y par bajo. Sin embargo

para aplicaciones típicas de tracción, es necesario entregar a las ruedas un par más

elevado a una velocidad varios órdenes de magnitud menor, para lo que se utiliza

una caja reductora.

Elección del motor CC

Se asume que el método óptimo para la selección de un conjunto motor CC –

reductora, consiste en:

1. Determinar las condiciones de funcionamiento: velocidad típica

de giro y par que se debe entregar a la salida de la reductora,

tensión nominal de funcionamiento y corriente consumida.

2. Seleccionar la relación de transmisión adecuada para

transformar la velocidad de salida de la reductora en una velocidad

en el eje del motor cercana a la velocidad de máximo rendimiento /

máxima potencia (según criterio de mínimo consumo energético o

mejores prestaciones del motor). Obtenemos también el par que

debe entregar el motor en esas condiciones.

3. Seleccionar una familia de motores en el entorno de la velocidad

prescrita, y un tamaño de motor que satisfaga la demanda de

par/potencia.

Una vez satisfecho esto, quedaría encontrar un encóder accesorio para este

motor, y los accesorios que puedan necesitarse para sujetarlo / unirlo al conjunto.

La realidad es que los catálogos estructurados y completos suelen estar

formados por motores de alta calidad y coste. Como los fondos de que se dispone

para desarrollar el robot no permiten ese nivel de coste, se ha seleccionado de

entre las referencias asequibles, un conjunto que pueda satisfacer las necesidades.

Estas referencias proceden de portales de venta de componentes para modelismo,

microbótica, subastas online, o similares.



El producto elegido ha sido el motor con reductora 29:1 37Dx52L mm con

encóder de 64 CPR comercializado por Pololu [16].

Las características indicadas por el fabricante son:

- Velocidad en eje de reductora: 350RPM a 12V y 300mA (giro libre)

- En bloqueo a 12 V par de 8Kg cm y 5A.

El eje de la reductora es de 6mm de diámetro, con terminación rebajada “en D”

para facilitar el montaje de ruedas mediante un casquillo con tornillos prisioneros.

Se realizan varias pruebas para caracterizar el motor. Se comprueba que la

reductora es en realidad 30:1

En cuanto al encóder incorporado, consiste en una rueda imantada solidaria a

una prolongación del eje del motor por la parte trasera del conjunto. EL canto de

dicha rueda se encuentra próximo a un encapsulado con dos conmutadores de

efecto hall, de modo que cada vuelta de esta rueda supone 64 transiciones de

estado. Por tanto, 1920 pulsos o transiciones por cada vuelta del eje de la

reductora.

El cableado del encóder tiene las siguientes funciones:

Rojo Alimentación motor

Negro Masa motor

Azul Alimentación Vcc (3,5-20 V)

Verde Masa encóder

Amarillo Salida encóder canal A

Blanco Salida encóder canal B

Aunque el fabricante no proporciona más información de este equipo se ha

identificado el encapsulado como equivalente al integrado 3425 de Allegro, que está

descontinuado y ha sido sustituido por el A1230. El esquema eléctrico

recomendado para este componente es el siguiente:



Ilustración 24. Esquema circuito encóder motor

Arquitectura y Diseño Electrónico 55


4. Arquitectura y Diseño Electrónico

4.1. Introducción El funcionamiento del robot consistirá en la ejecución de distintas tareas,

estructuradas según el modelo de arquitectura robótica.

Estas tareas llevan asociado un flujo de información que, en el caso que nos

ocupa, es gestionado por sistemas de computación electrónicos. En estos sistemas

la información es gestionada en forma de señales eléctricas, y la forma en que el

flujo de información es conducido y procesado por los sistemas electrónicos es a lo

que nos referimos como arquitectura electrónica.

La arquitectura electrónica debe estructurar los sistemas electrónicos para que

cumplan sus tareas de acuerdo con la arquitectura robótica, según la cual

particularizamos varios niveles de abstracción para las tareas. Desde el punto de

vista de los requisitos que las tareas imponen a los sistemas electrónicos que las

gestionan:

1. Las tareas de bajo nivel suelen ser tareas simples

(computacionalmente hablando), ligadas al manejo de las señales

físicas de sensores y actuadores, con requerimientos de tiempo

crítico. Son tareas específicas al dispositivo.

Los sistemas basados en microcontrolador son una buena elección para

satisfacer estas exigencias.

2. Las tareas de alto nivel suelen ser computacionalmente exigentes.

Son tareas generales, que no se implementan sobre los recursos

físicos de la máquina, y por tanto más portables. No manejan

señales físicas sino datos, y suelen implementarse como procesos

concurrentes.

Los sistemas tipo PC proporcionan un buen soporte para este tipo de tareas.



En base a estas consideraciones, el marco de referencia para la estructura

electrónica será el de un sistema tipo PC (arquitectura Von Neuman) que soportará

el control de alto nivel, mientras el control de bajo nivel es realizado por

subsistemas basados en microcontrolador (arquitectura Harvard) y dotados de los

periféricos específicos para la tarea que desarrollan. La comunicación entre el

sistema principal y los demás subsistemas se realizará gracias a puertos de

comunicaciones.

4.2. Sistema de control de alto nivel Para el futuro desarrollo de este proyecto robótico, se plantea el uso de un

sistema de propósito general (tipo PC). Estos sistemas no están ideados para

manipular directamente las señales físicas habituales de sensores y actuadores,

sino que suelen ser necesarios módulos de E/S.

La particularización a la aplicación de control se realiza a través de un

programa o software, que corre sobre un sistema operativo y que es el que gestiona

los recursos físicos de la computadora. Aquí radica la principal ventaja en el uso de

estos sistemas: el diseño de la aplicación de control se limita a programar, y las

aplicaciones son más fácilmente reutilizables para distintos sistemas.

Existen importantes proyectos abiertos de aplicaciones para robótica como

PlayerStage [17] u otros para tecnologías afines como la visión artificial: OpenCV

[18]

Además, el precio de un sistema tipo PC es cada vez más económico, y la

potencia de computación creciente incluso en equipos de pequeñas dimensiones.

Existen numerosos ejemplos de robots comandados por PC, ya sea con el PC

integrado en la estructura del robot o con comunicación cableada o inalámbrica.



Ilustración 25. Robot Edubot (CARTIF)

Una alternativa muy adecuada es el uso de los llamados SBC u ordenadores

embebidos, que permiten una gran versatilidad gracias a sus reducidas

dimensiones y variedad de formatos:

Ilustración 26. Distintos formatos de placa de ordenador embebido

El precio de estos sistemas está bajando drásticamente, y se están

desarrollando proyectos muy atractivos como Raspberry Pi [19], un ordenador



embebido por menos de 30$, que está suponiendo una revolución en el mundo de

la microbótica:

Ilustración 27. Ordenador embebido Raspberry Pi

4.3. Sistema electrónico de control de movimiento

4.3.1. Introducción al modelo de sistema de control de movimiento.

Para poder realizar con éxito las tareas que exige la competición, es necesario

que el robot tenga buenas cualidades para el movimiento.



Además de una mecánica adecuada, esto consiste en que el sistema de

control principal, en función de los lances del juego, pueda ordenar a un sistema de

navegación que proceda para que el robot se desplace y alcance una posición y

orientación determinadas, mientras un sistema de posicionamiento mantiene

actualizado un registro accesible con la posición y/o orientación del robot.

Existen multitud de métodos de navegación y de posicionamiento. Entre los de

navegación tenemos los deliberativos, como la planificación de trayectorias. Entre

los reactivos, el seguimiento de señales o rastros. Para posicionamiento, la

orientación por campos o líneas de flujo, el mapeo, y otras técnicas.

Esta plataforma, en su concepción versátil, debe servir de soporte para los

sistemas que se incorporan y también a los que previsiblemente puedan llegar a

incorporarse:

4.3.1.1. Navegación

La misión genérica de un sistema de navegación es dar al sistema de control

de tracción las órdenes de movimiento que corresponda. Una posible forma de dar

soporte a esta función es proveer comandos de movimiento en términos de

velocidad de desplazamiento tangencial y de rotación del centro de masas del

robot como sólido rígido.

A partir de los movimientos simples que pueden ordenarse a través de estos

comandos, se pueden obtener trayectorias complejas.

Los comandos en velocidad tangencial y de rotación del centro de masas

deben ser traducidos a órdenes sobre las variables de control del sistema de

tracción, que son las velocidades de giro de las ruedas i y d .

El sistema de control de tracción se ocupa de que la salida real, velocidad de

giro de las ruedas, siga la referencia que se ha ordenado. Para ello, se plantea un

lazo de control realimentado para cada uno de los dos bloques de motores

(izquierdo y derecho):

Los bloques funcionales del lazo de control de velocidad son:

1. Comparador: Su misión es obtener la señal instantánea de error

existente entre la referencia y la salida del sistema.



2. Controlador del motor: procesa la señal de error presente y

pasada para elaborar una orden sobre el actuador (motor).

3. Amplificador: La señal de control procedente del controlador no

tiene la potencia necesaria para alimentar directamente los

actuadores, por lo que es necesario una etapa intermedia.

4. Actuador: Es el encargado de producir las señales físicas sobre la

planta para cambiar su estado.

5. Planta: Es el sistema físico que desea controlarse. Reacciona

ante las acciones presentes y pasadas de los actuadores para dar

lugar a una señal de salida.

6. Sensor: Mide la señal de salida de la planta u otras relacionadas a

partir de las que pueda estimarse.

En el caso que nos ocupa, estos bloques conceptuales se particularizan

físicamente del siguiente modo:

1. Las funciones de comparador, controlador del motor y procesamiento de

la señal del sensor para estimar la velocidad son llevadas a cabo por un

microcontrolador.

2. Como actuadores se tiene los motores de corriente continua de imanes

permanentes (PMDCM en terminología inglesa).

3. La planta está formada por todos los elementos mecánicamente

acoplados a la rueda cuya velocidad angular se desea controlar. El

modelo dinámico equivalente depende de aspectos geométricos, de las

cargas inerciales y angulares y también del punto de funcionamiento del

sistema, por lo que resultaría muy complejo encontrar su expresión

analítica. Para los objetivos de este proyecto, será suficiente tener en

consideración el modelo dinámico del motor de corriente continua,

respecto del cual, todo lo que está mecánicamente acoplado al eje

puede reducirse en cada instante a una carga dinámica.

4. El sensor utilizado será el encóder de cuadratura. No mide velocidades,

sino que permite determinar desplazamientos angulares y sentido de

giro, todo ello en dominio discreto. La velocidad media en un período de

tiempo puede estimarse como el cociente entre el desplazamiento



angular y el tiempo transcurrido, y tendrá valor discreto en períodos

discretos.

4.3.1.2. Posicionamiento

Pero el sistema de control superior planifica los movimientos sobre la

referencia fija al terreno de juego, y puede necesitar conocer la posición y

orientación en que se encuentra el móvil sobre el terreno de juego, por

ejemplo, para valorar las posibles estrategias a seguir, y calcular

trayectorias. Para poder traducir las órdenes nativas (en coordenadas

globales) a coordenadas locales al robot, es imprescindible que conozca su

orientación.

Partiendo de una posición absoluta conocida, el sistema de control del robot

puede estimar la posición y orientación en que se encuentra en cada

momento, si dispone de un modelo geométrico del robot. Pero además, con

la medida del ángulo girado por cada rueda en períodos infinitesimales, se

puede implementar un sistema odométrico de posicionamiento: Este sistema

puede proveer de realimentación en posición.

Por su propia naturaleza, estos métodos de posicionamiento incrementales

van acumulando error en cada iteración, de modo que si no se actualiza la

posición y orientación absolutas del robot, de forma fiel, por ejemplo,

mediante un sistema de balizas, el error acumulado desvirtuará los cálculos

al cabo de algunas iteraciones. Por eso, un sistema de posicionamiento

absoluto es muy conveniente, habida cuenta de que en las bases de la

competición se habilitan medios para posibilitar su uso, y previsiblemente se

incorporará en un futuro a los sistemas desarrollados en este proyecto.

El sistema de posicionamiento se implementa sobre el microcontrolador, que

es quien maneja directamente las señales de los encóder solidarios a las

ruedas.

Las variables de estado que reflejan la posición del robot son sus coordenadas

absolutas sobre el terreno de juego y su orientación: Xg, Yg, φ.



La relación entre las variables globales, en el sistema de referencia natural del

espacio de juego, y las locales, en el sistema de coordenadas solidario al robot, es

geométrica.

El modelo del sistema debe establecer la relación existente entre unas y otras:

El sistema de control superior será el encargado de determinar qué

movimientos debe hacer el robot, descomponerlos en otros más simples y dar las

órdenes al sistema de tracción para que se efectúen los movimientos infinitesimales

necesarios en cada instante.

El movimiento instantáneo del robot se describe en términos de variables

cinemáticas: desplazamientos, velocidades y aceleraciones del robot, y estas

variables se relacionan a través de la geometría con las variables cinemáticas

directamente vinculadas a los motores (giro, velocidad angular y aceleración

angular de cada motor), en las ecuaciones cinemáticas.

Por otro lado, las ecuaciones dinámicas permiten relacionar las variables

cinemáticas con la causa que las origina (fuerzas y pares), y que son variables

físicas dependientes de los actuadores (en este caso, motores de corriente

continua).

Por tanto, el sistema electrónico de tracción debe gestionar estas variables y

demandar a los motores las acciones necesarias para satisfacer órdenes que recibe

del sistema de control suprior en términos de variables de movimiento. El alcance

de las órdenes que sea capaz de seguir, así como la bondad con que lo haga,

determinarán los movimientos que se puedan conseguir.



Ilustración 28. Diagrama de bloques del posicionamiento por odometría

4.3.2. Placa electrónica de control de tracción

Como principal componente del sistema electrónico de control de tracción se

diseña y construye una placa que sirva de soporte para los siguientes elementos:

- Fuente de alimentación a 5V.

- Fuente de alimentación a 3,3V.

- Microcontrolador. Acondicionamiento de señales de entrada/salida y

circuitería específica recomendada por el fabricante.

- Puerto de comunicación con adaptación al nivel de 3,3V del puerto

UART del micro.

4.3.2.1. Diseño

Todo el proceso de diseño se ha realizado utilizando el software Proteus, que

proporciona dos aplicaciones específicas para confeccionar el esquema (Proteus

ISIS) y la disposición a nivel físico (Proteus ARES).

En la primera etapa se diseña el esquema funcional con los componentes

electrónicos y sus conexiones. Para ello se pueden agrupar por sistemas, sin que la



disposición en el esquema corresponda con la disposición física final que tendrán

en la placa.

El entorno ISIS proporciona librerías con los componentes más frecuentes, que

permiten su particularización en cada caso mediante parámetros. Además,

proporciona un entorno de simulación muy potente para circuitos analógicos y

digitales. En este último caso, se pueden correr los programas precompilados para

el microcontrolador y comprobar el funcionamiento completo de un circuito basado

en microprocesador, simulando entradas, salidas y señales.

Algunos componentes utilizados en la placa diseñada no estaban presentes en

las librerías, por lo que fue necesario crearlos.

Ilustración 29. Entorno de desarrollo Proteus ISIS

Una vez obtenido el esquema funcional para los circuitos y componentes de la

placa (ver Anexo: esquemas y planos), será necesario obtener su diseño físico.

Para ello, se transfieren al entorno ARES los componentes del esquema

funcional, así como la netlist o tabla de nodos del esquema, siendo cada nodo un

conjunto de terminales que están eléctricamente en contacto. En ARES se asigna a

cada elemento del esquema un encapsulado caracterizando su forma y

dimensiones.



A continuación deben ubicarse en el espacio de la placa: aunque esta

operación puede hacerse en modo automático, resulta más conveniente en este

caso colocar y orientar los componentes manualmente.

Una vez obtenida una primera disposición espacial, se procede al rutado,

consistente en disponer las pistas de cobre que unirán entre sí los terminales de los

componentes según la tabla de nodos. Se plantea un rutado a doble cara, ya que el

número de conexiones es importante. En este proceso debe tenerse en cuenta la

forma en que se va a fabricar la placa, para determinar anchura de pistas

razonables, separaciones y holguras acordes con las posibilidades reales de la

técnica de fabricación.

Como se plantea una fabricación con medios poco tecnológicos, se descarta

utilizar anchuras y holguras demasiado finas, que en la práctica puedan resultar

inalcanzables.

El proceso de rutado sí conviene hacerlo en modo automático, ya que existen

gran cantidad de combinaciones posibles, que el ordenador puede computar en

muy poco tiempo para dar una solución aceptable. Esta solución propuesta debe

ser revisada y modificada, en un proceso iterativo que puede llevar a recolocar

algunos componentes, volver a ejecutar el rutado y realizar cambios concretos,

hasta que se llegue a una solución aceptable.

En este caso, tras algunas iteraciones se consiguió obtener una placa a doble

cara de 10x10cm muy compacta.

La aplicación ARES provee un visualizador 3D para las placas diseñadas, que

resulta muy útil para conocer el aspecto y la forma que tendrá el conjunto antes de

ser fabricado, especialmente si se hace por medios manuales.



Ilustración 30. Placa electrónica de control de tracción

4.3.2.2. Construcción de la placa

Para la fabricación de la placa electrónica diseñada es necesario en primer

lugar obtener la PCB (placa de circuito impreso), sobre la que se soldarán los

componentes electrónicos.

Esta placa está compuesta por un material de soporte, generalmente de

baquelita o fibra de vidrio, de 1,5mm de espesor, en cuyas caras se dispone una

lámina de cobre de 35 micras de espesor, de la que se elimina material hasta

formar las pistas conductoras.

El procedimiento utilizado ha sido el revelado-ataque químico, que es un

procedimiento adecuado para elaboración de prototipos y tiradas cortas con medios

muy limitados. Se parte de una placa fotosensible positiva a doble cara que,

además del soporte y la lámina de cobre en las dos caras, tiene sobre éstas una

película de emulsión fotosensible. El procedimiento que se siguió para obtener la

placa es el siguiente:

1. Elaboración de fotolitos.

La película fotosensible forma una capa que protege el cobre, y que por tanto

debe ser eliminada para atacarlo químicamente. Como en un proceso de revelado

fotográfico, la emulsión fotosensible reacciona frente a la luz ultravioleta, formando

un compuesto soluble fácil de retirar, y dejando al cobre expuesto para ser atacado.



Para proteger la emulsión allí donde no debe ser revelada, se utiliza un fotolito,

que es una impresión sobre lámina transparente, de las pistas que deben quedar en

cobre. La tinta debe quedar en contacto con la emulsión (para evitar la proyección

de sombras), por lo que se imprime una imagen especular. Debe ponerse atención

en que las dimensiones del fotolito, una vez impreso, sean las correctas.

Como se va a revelar a doble cara, es necesario que ambos fotolitos

mantengan una posición relativa correcta durante todo el proceso. Para lograrlo, se

fijan a un bastidor externo del mismo grosor que la placa virgen y que permita

introducirla entre las dos láminas transparentes.

2. Exposición a la luz.

La placa protegida por los fotolitos es expuesta a la luz, protegida por los

fotolitos, durante un tiempo adecuado, que varía según la placa utilizada.

3. Revelado.

Una vez insolada, la placa se introduce en una solución de sosa hasta que se

desprende la emulsión de las zonas expuestas a la luz.

4. Ataque químico.

La placa es atacada por una solución corrosiva de ácido clorhídrico y peróxido

de hidrógeno en agua. Allí donde el cobre no tiene capa protectora, es retirado en el

proceso, quedando solamente las pistas y elementos deseados.

Ilustración 31. PCB para placa de control de tracción



Una vez obtenida la PCB para la placa electrónica, habrá que montar los

componentes sobre ella.

Se han utilizado componentes en distintos encapsulados correspondientes a

dos tecnologías de montaje:

- THT (tecnología “a través de agujero”). Los componentes tienen

patillas que se introducen por agujeros en la placa y son soldadas a

las pistas, en la cara opuesta a donde se encuentra el componente.

Es una tecnología clásica, asociada a encapsulados más grandes,

más sencillo de montar a mano pero más caro por el importante

inconveniente de tener que hacer los agujeros.

- SMT (tecnología de montaje superficial). Los componentes se

sueldan directamente sobre una prolongación de las pistas, en la

misma cara en que se encuentra el componente. Es una tecnología

más reciente, que industrialmente ha desbancado a la THT por

permitir la miniaturización y resultar más barata. Tiene el

inconveniente de que las operaciones manuales con encapsulados

correspondientes a esta tecnología son difíciles y requieren de

destreza y herramientas específicas.

En el diseño de esta placa se han utilizado componentes de ambos tipos:

- Se ha utilizado SMT para componentes relativamente simples de

manipular y poco susceptibles de tener que reemplazarse en la

placa, tales como las resistencias, condensadores, transistores,

diodos, LEDs y reguladores de tensión.

- Se ha utilizado THT para componentes sensibles o susceptibles de

estropearse (microcontrolador) así como en los terminales,

conectores y otros componentes que requieren una unión más

fuerte o soportan esfuerzos mecánicos.

Antes de proceder al taladrado es conveniente eliminar una laca coloreada que

protege el cobre, y aplicar un estañado que la reemplace y facilite el posterior

soldado de los componentes.



Ilustración 32. Decapado de la PCB

A continuación los componentes se van colocando y soldando. Se comienza

por los de perfil más bajo (montaje superficial). Han sido elegidos en encapsulados

que permitan su soldadura a mano (1206 y 0805) utilizando pinzas, soldador con

punta fina y estaño de calidad (con plata). A continuación se procede con los

componentes más grandes y de perfil más alto, procurando terminar con los

conectores, terminales y otros componentes más robustos.

Será necesario realizar puentes entre las dos caras (uniones para que una

pista continúe su trazado en otra cara) y prestar atención en los componentes THT

allí donde según el rutado confeccionado, un agujero deba dar continuidad a una

pista por dos caras. No se han utilizado remaches que garanticen esta continuidad

por no disponer de medios, y en su lugar, se ha procurado soldar la patilla del

componente por las dos caras.

Es imprescindible realizar una validación sistemática de la placa, comprobando

continuidad en todas las pistas y uniones, así como la ausencia de defectos tales

como cortocircuitos entre pistas y cortes.

4.3.2.3. Uso y configuración hardware de la placa

Una vez montada la placa, es necesario realizar un ajuste preliminar de

algunos componentes, tales como resistencias variables, así como la colocación de



jumpers (fundas que cortocircuitan los terminales en los que se insertan),

permitiendo variar la configuración física de los circuitos.

En la placa construida pueden encontrarse los siguientes bloques de

elementos:

Ilustración 33. Descripción de la placa de control de tracción.

Terminales de alimentación – bypass

Se ha dispuesto dos pares de bornas ajustables con tornillo para recibir la

alimentación de la placa, y simplificar la conexión en cascada con otras placas.

La tensión máxima de alimentación es de 15 V, correspondiente a la máxima

tensión de los reguladores.



Adaptación de señal de los encóders

La placa ofrece terminales para la conexión de dos encóder de cuadratura.

Estos terminales proporcionan alimentación a 5V y permiten ajustar los pulsos de

señal al nivel de tensión admitido por el microcontrolador mediante unos

potenciómetros que actúan como divisor de tensión. Estos potenciómetros de 5K

Ohm deben ser ajustados con los encóder conectados.

Conexión con etapa de potencia

La placa proporciona dos canales independientes para el mando de motores

de corriente contínua. Para cada uno de los canales, se proveen señales de

activación del canal, gobierno del sentido de giro (A, B), el tiempo activo PWM (duty

cycle), así como entrada para el monitoreo de la corriente.

El nivel de tensión del microcontrolador es de 3,3V, pero se utilizan como

salidas algunas patillas capaces de funcionar como salida en colector abierto, de

modo que con resistencias de pull-up se consiguen un nivel lógico de 5V según se

demanda en la mayoría de etapas de potencia comerciales. Esta configuración no

es adecuada si la impedancia de entrada en la etapa de potencia no es elevada.

Divisor de tensión

Se dispone en la placa de un divisor de tensión fácilmente conectable a una de

las entradas analógicas del micro para funciones como monitoreo de la tensión de

las baterías del sistema.

Entrada / salida universal

El microcontrolador que gobierna la placa funciona alimentado a 3,3V. A

pesar de que cada vez hay más dispositivos compatibles, contrasta con el más

frecuente nivel lógico a 5V. Algunas de sus patillas están preparadas para poder

proporcionar como salidas este nivel. Para manejar entradas a nivel de 5V será

necesario realizar una adaptación de niveles.



Se ha elegido RB5, una de las patillas tolerantes a salidas 5V como

entrada/salida libre, y se proporciona un circuito configurable que permite la

adaptación para distintos niveles tanto como entrada como salida.

Ilustración 34. Entrada/salida universal

Las configuraciones posibles de la entrada/salida universal son como sigue:

Ilustración 35. Configuraciones posibles de la entrada/salida universal



Leds testigo de entrada / salida del puerto

Para facilitar el desarrollo de aplicaciones con la placa se dispone de leds

testigo que permiten conocer visualmente el estado en que se encuentran las

patillas disponibles del micro. La corriente que pueden entregar las salidas del

micro es muy limitada, por lo que los leds son alimentados desde transistores de

amplificación.

Conexión ICSP

La placa incorpora circuitería para la programación serie del microcontrolador

mediante el protocolo propietario de microchip ICSP (In circuit serial programming).

A través de 5 terminales conectados en la placa a las correspondientes patillas

del micro se tiene un modo de programación que facilita notablemente la labor de

desarrollo, ya que no será necesario extraer el micro de su zócalo para

programarlo.

Además, gracias al dispositivo hardware PicKit 3 se puede realizar depuración

en circuito: ejecutar el programa paso a paso, comprobando la respuesta en la

aplicación, en tiempo real, con las señales reales, y detectar puntos conflictivos.

Ilustración 36. Conector ICSP y jumpers para configuración de la placa

Se han dispuesto unos jumpers para seleccionar el terminal que enlaza con

las patillas en el micro, dependiendo de si se utiliza la funcionalidad ICSP o se

desea disponer de la patilla para otras aplicaciones.



Para más información sobre el uso de ICSP puede consultarse el documento

PicKit3 User Guide de Microchip.

Adaptador UART a USB/radio

El microcontrolador dispone de dos puertos UART para la comunicación serie

con el exterior. Este es el puerto elegido para la comunicación del sistema de

control de tracción con el sistema de control superior, que podrá estar

implementado sobre un PC, SBC u otro circuito electrónico.

A nivel físico este puerto requiere al menos de tres canales para una

comunicación bidireccional: RX, TX y GND. Adicionalmente pueden utilizarse las

señales hardware de control de flujo RTS y CTS.

Los niveles para estas señales en el microcontrolador deben ser compatibles

con 3,3V por lo que no es posible su conexión directa con la mayoría de

dispositivos electrónicos, que utilizan nivel de 5V. En particular, no se puede

conectar al terminal USB que es actualmente el más utilizado en los PC.

Para salvar este obstáculo, en las labores de desarrollo se utiliza un adaptador

entre la UART del micro y el puerto USB del PC.

En la etapa de diseño de la placa se consideró el adaptador CP2102 USB a

serie, de POLOLU. Para su conexión a la placa se dispone de un zócalo.

Ilustración 37. Adaptador USB / serie CP2102, zócalo y jumpers para configuración de la placa

Con este adaptador es necesario utilizar una conexión cableada al PC, que

resulta incómoda para la fase de pruebas de movimiento de la plataforma robótica.

Así que se buscó una alternativa que eliminase la conexión cableada.



La solución elegida fue el módulo Wixel de Pololu

Ilustración 38. Módulo inalámbrico wixel

El Wixel es un módulo programable de propósito general que dispone de

conexión USB y radio a 2,4 GHz. El núcleo del módulo es el microcontrolador de

Texas Instruments TI CC2511F32, con 29KB de flash y 4KB de RAM. Puede

utilizarse para distintas aplicaciones, de las que se destacan 3 por su interés para

este proyecto.

1. Como adaptador USB-serie (cableado): permite

reemplazar el adaptador CP2102 para el que inicialmente

fue diseñada la placa.

2. Como adaptador USB-radio 2,4GHz: conectado al puerto

USB del PC, crea un nodo inalámbrico de

emisión/recepción para la comunicación con otros módulos

wixel.

3. Como adaptador serie-radio 2,4GHz permite recibir las

señales de radio enviadas desde el PC a través de su

nodo inalámbrico wixel , tales como comandos u órdenes,

y responder con parámetros de funcionamiento de la



aplicación en que se instala, en este caso, el sistema de

control de tracción del robot.

Fuente de tensión 5V y 3,3 V

La placa incorpora dos reguladores de tensión LDO (low drop-out) de alta

eficiencia: REG104FA-3,3 y REG104FA-5 de Texas Instruments. Estos integrados

tienen una excelente respuesta transitoria y permiten la habilitación o

deshabilitación de su salida mediante una patilla, que se ha aprovechado en el

circuito de la placa.

4.3.3. Placa electrónica de potencia

Las señales de gobierno sobre los motores generadas desde la placa de

control de tracción deben ser amplificadas en potencia para poder alimentar los

bloques de motores a ambos lados del robot.

Para la selección de la etapa de potencia deben tenerse en cuenta las

necesidades de los motores:

- Tensión nominal de alimentación: 12 V

- Corriente nominal: 500 mA a 12 V.

- Corriente de cortocircuito: 5A en bloqueo.

Ilustración 39. Reguladores de tensión: esquema y posición de jumpers para su habilitación.



La corriente de cortocircuito no es la más desfavorable que se prevee, puesto

que para lograr un frenado muy rápido de los motores puede tener que recurrirse a

la inversión de polaridad. Es una acción muy desaconsejable desde el punto de

vista de la vida útil del motor, por lo que como precaución se estima en una

corriente un 20% sobre la de bloqueo: 6 amperios.

Cada lado de la plataforma cuenta con dos motores en paralelo, por lo que las

necesidades sobre la placa quedan:

- Tensión nominal: 12V.

- Corriente nominal: 1A por canal.

- Corriente de pico: 12 A por canal.

Para satisfacer estas necesidades se ha elegido la Dual VNH2SP30 de Pololu.

Se trata de una placa portadora para el integrado VNH2SP30 [20] de ST

microelectronics, que incorpora los principales elementos que el fabricante

recomienda la página 8 de su hoja de características, incluyendo resistencias de

limitación de corriente y de pull-up, así como un transistor FET para la protección de

la batería. Puede revisarse el esquema al final de este documento, en la sección

de planos y esquemas.

Ilustración 40. Placa de potencia Dual VNH2SP30 de Pololu



El circuito integrado VNH2SP30 es un driver para motores con configuración

de puente H, orientado al sector de la automoción.

Algunas de sus principales características son las siguientes:

Nivel de tensión de señales lógicas 5 VTensión suministrada Vcc 5,5-16 V

Máxima corriente de pico 30 A

Resistencia en el MOSFET 19 mOhmn

Frecuencia PWM máxima 20 KHz

Monitor de corriente 0,13 V/A

Nivel de corte por sobretensión 16V min (19 típico)

Tiempo de sobrecalentamiento a 20A (*) 35 s

Tiempo de sobrecalentamiento a 15A (*) 150 s

Corriente operación ininterrumpida (*) 14 A Tabla 1. Prestaciones del VNH2SP30

La estructura de puente en H completo con transistores MOSFET permite

controlar tanto la velocidad como el sentido de giro de los motores de corriente

continua. Activando selectivamente los transistores, se crean dos circuitos para la

corriente, que recorre el motor en uno u otro sentido y consecuentemente variando

su sentido de giro.

Además, variando el tiempo efectivo de conexión del motor a la alimentación,

se modifica la tensión promedio y con ella la velocidad de giro, en la técnica

conocida como PWM.

A partir del esquema de conexión recomendado por el fabricante, e

implementado en la placa de potencia, se pueden ordenar distintos estados para el

motor.



Ilustración 41. Circuito de aplicación típica para VNH2SP30. Datasheet pag. 8

TABLA DE VERDAD EN FUNCIONAMIENTO NORMAL

IN A IN B OUT A OUT B CS Modo operación 1 1 H H Alta impedancia Frenado a Vcc 1 0 H L Is= Iout/K Giro horario 0 1 L H Is=Iout/K Giro antihorario 0 0 L L Alta impedancia Frenado a GND

Leyenda: H: Nivel alto de tensión Is: intensidad de monitoreo de corriente IN: Entrada L: Nivel bajo de tensión CS: monitoreo de corriente OUT: salida

4.3.4. Placa de accionamientos

El sistema eléctrico del robot está formado por dos circuitos eléctricos cuya

alimentación es independiente. Por un lado, un circuito alimenta desde una batería

de 7,2V cargas eléctricas y electrónicas de baja potencia. Por otro, lado los

sistemas electromecánicos (motores principalmente) son alimentados a 12V por un

circuito diseñado para más potencia.

Por razones operativas es necesario poder interrumpir la alimentación general

del robot, y muy conveniente poder hacerlo de forma independiente para los dos

circuitos.



Para satisfacer esta necesidad se ha diseñado una placa electrónica de

accionamientos con las siguientes características:

- Se utilizan relés para el accionamiento e interruptores manuales para

el mando. Esto permite trasladar fácilmente mediante cableado de

señal los interruptores a una ubicación en la periferia del robot donde

sea cómoda su manipulación, dejando la placa electrónica en el

interior de la máquina.

- Se integran leds testigo para monitorear desde el exterior el estado

de marcha o paro de los sistemas.

- El sistema así diseñado permitiría a la electrónica de control tomar el

mando del circuito de potencia, e interrumpir la alimentación de los

motores por ejemplo ante estado de baja carga de las baterías u

otras condiciones de falta.

- Se integran en esta placa las conexiones a los terminales de las

baterías Li-po para su carga, ya que se encontrarán ubicadas en el

interior del robot y resultaría engorrosa su extracción para cargarlas.

El diseño del esquema de la placa se ha realizado utilizando Proteus-ISIS.

Puede encontrarse al final de este documento, en la sección de planos y esquemas.

Se ha utilizado el motor de simulación para comprobar la bondad del diseño y

estimar las corrientes que circulan por las distintas ramas.

Para el trazado de las pistas y el diseño de la PCB se ha utilizado el entorno

Proteus-ARES, seleccionando los encapsulados para cada componente, y

dimensionando la anchura de pista de acuerdo con la corriente eléctrica que debe

transportar.



Ilustración 42. Placa de accionamientos en el entorno software Proteus-ARES

Para la construcción se han seguido pasos análogos a los que se describieron

en la placa de control de tracción. También en este caso se ha utilizado placa FR4

a doble cara, pero todos los componentes son de montaje en agujero (tecnología

THT).

Ilustración 43. Placa de accionamientos, mandos y terminales de carga



4.3.5. Alimentación. Baterías Li-Po

La normativa de la competición EUROBOT exige la instalación de un

interruptor general que en caso de accionamiento, interrumpa la alimentación de

todos los sistemas en el robot. Para ello se ha instalado uno con poder de corte

suficiente de doble acción (DPST), que actúa sobre los dos circuitos (electrónica y

potencia).

De entre los distintos tipos de baterías recargables que podrían utilizarse para

la alimentación del robot, se ha optado por utilizar las de polímero de litio,

conocidas como Li-po.

Las baterías Li-po son una tecnología reciente que se caracteriza por tener una

densidad energética (Energía acumulada / Masa de la batería) así como una tasa

de descarga (Corriente que pueden aportar por unidad de energía acumulada) muy

superiores al de otras tecnologías tradicionales (Plomo, Ni-MH, Ni-Cd) por lo que su

uso se ha extendido rápidamente en aplicaciones móviles.

La celda elemental de Li-po tiene una tensión nominal de 3,7 V por lo que para

conseguir tensiones mayores se asocian varias celdas en serie.

Características de una batería Li-po

- Tensión nominal: (será un múltiplo de 3,7 V), que suele

representarse seguido de la letra S (serie).

- Capacidad nominal: es la energía almacenada. Se expresa como

producto de una corriente que agotaría la capacidad en el plazo de

una hora (A*Hora). Para conseguir baterías de capacidad elevada

se recurre a la asociación en paralelo de un número de celdas, que

se representa seguido de la letra P (paralelo).

- Tasa de descarga: Corriente máxima que la batería puede

suministrar sin dañarse. Se expresa como un múltiplo de la

capacidad, (10C, 25C). Está directamente relacionado con la calidad

de la batería: una mayor capacidad de descarga está asociada a

menor resistencia interna en la batería, que por efecto joule produce

calentamiento y deterioro de las celdas si se superan los 60ºC.



Normas de uso, transporte y manipulación de las baterías Li-po

El principal inconveniente de estas baterías es que presentan riesgo de

explosión en caso de que el compuesto de litio entre en contacto con el aire.

Además de por causas externas, esto puede ocurrir por un uso inapropiado: el

polímero puede liberar gases que hinchan la cubierta y pueden reventarla, con las

consecuencias antes descritas.

Para evitar que esto ocurra deben seguirse estrictas normas de uso, transporte

y manipulación:

- El rango de descarga de las baterías va desde los 4,2 V hasta los

3V. En caso de almacenamiento prolongado, es recomendable que

se haga a la tensión nominal de 3,7 V.

- No debe superarse la tasa de descarga máxima, ni cargarse a una

tasa superior a 1C.

- La asociación serie y paralelo es delicada. No deben asociarse

baterías de distinta capacidad. La carga debe hacerse de forma

balanceada, es decir: el resultado debe ser que todas las celdas

terminen el proceso a la misma tensión. Para ello, las baterías Li-po

presentan dos conjuntos de cables: uno de dos cables “gruesos” que

da acceso a los terminales de la asociación en serie de las celdas;

el otro da acceso a los terminales de cada una de las celdas,

haciendo posible su monitoreo y carga selectiva.

- Las baterías nunca deben superar los 60º C, por lo que deben

instalarse lejos de fuentes de calor o prestarse atención si se

confinan en espacios de difícil refrigeración.

- Para su transporte deben utilizarse bolsas reforzadas de protección.



Ilustración 44. Batería Li-po de potencia con circuito monitor de tensión

Aplicación de las baterías Li-po en el robot

Para este proyecto se utilizan dos baterías Li-po:

1. Batería para electrónica y señal 2S 1P 1250mAH 15C

2. Batería para circuito de potencia: 3S 1P 4000mAH 15C

Para proteger los circuitos así como las propias baterías en caso de

cortocircuitos o sobrecorrientes peligrosas se incorporan fusibles:

1. Para el circuito de alimentación de electrónica, el nivel de riesgo para la

electrónica está lejos del nivel de riesgo para la batería. Se utiliza un

fusible de 3 amperios.

2. Para el circuito de potencia, ante una situación de falta en los motores

podría ponerse en riesgo la batería, por lo que se utiliza un fusible a 25

amperios.

4.3.6. Conexiones y cableado.

La conexión entre los distintos elementos se realiza mediante cables

multifilares de cobre o aluminio y dimensionados según la corriente que deban

transportar. Las longitudes son pequeñas y no se consideran caídas de tensión.



Para los conductores de potencia, se utilizan principalmente cables de cobre

de 1mm2 de sección, excepto en las conexiones de las baterías, donde las

secciones alcanzan los 2 mm2 .

Los terminales de los cables van pre-estañados y atornillados a bornas, salvo

en los cables de portafusibles, donde se crimpan fast-on bandera de 6,3 mm.

Los cables de señal entre placas electrónicas son de secciones reducidas, van

identificados por colores, y terminan en terminales soldados.

La Tabla 2 recoge los cables utilizados con sus principales características.

Tabla 2. Cables eléctricos

Cable Inicio FinLongitud

(cm)Seccion

AWGSección

mm2Color Nota Extremo 1 Extremo 2

1 Bat7- Interrupt1A 10 17 1 marrón Fusible 3A Libre Faston 6,3 bandera2 Interrupt1B PC_bat_7- 18 17 1 marrón Libre Faston 6,3 bandera3 Bat7+ PC_bat_7+ 5 1,5 rojo Integrado bat Libre Inserto bat4 Bat12- Interrupt2A 10 14 2 marrón Fusible 25A Libre Faston 6,3 bandera5 Interrupt2B PC_bat_12- 11 17 1 marrón Libre Faston 6,3 bandera6 Bat 12+ PC_bat_12+ 12 14 2 rojo Libre Inserto bat7 Cargador 12- PC_carga_12- 5 0,5 negro Alta flexib. Libre libre8 Cargador 12+ PC_carga_12+ 5 0,5 rojo Alta flexib. Libre libre9 Cargador 7- PC_carga_7- 5 0,5 negro Alta flexib. Libre libre

10 Cargador 7+ PC_carga_7+ 5 0,5 rojo Alta flexib. Libre libre11 PC_salida_12+ PP_Vin+ 20 14 2 azul LIbre libre12 PC_salida_12- PP_Vin- 20 14 2 marrón Libre libre13 Out_1A_PP 1A_regleta 5 1 azul Libre libre14 Out_1B_PP 1B_regleta 5 1 marrón Libre libre15 Out_2A_PP 2A_regleta 5 1 azul Libre libre16 Out_2B_PP 2B_regleta 5 1 marrón Libre libre17 1A_regleta 1A_bis 5 1 azul Libre libre18 1B_regleta 1B_bis 5 1 marrón Libre libre19 2A_regleta 2A_bis 5 1 azul Libre libre20 2B_regleta 2B_bis 5 1 marrón Libre libre21 PC_salida_7+ PCT_Vcc 10 0,5 rojo Alta flexib. Libre Libre22 PC_salida_7- PCT_Vss 10 0,5 negro Alta flexib. Libre libre23 1A_regleta Motor 1 - 15 1 azul Libre libre24 1B_regleta Motor 1 + 15 1 marrón Libre libre25 1A_regleta Motor 2 - 15 1 azul Libre libre26 1B_regleta Motor 2 + 15 1 marrón Libre libre27 2A_regleta Motor 3 + 30 1 marrón Libre libre28 2B_regleta Motor 3 - 30 1 azul Libre libre29 2A_regleta Motor 4 + 40 1 marrón Libre libre30 2B_regleta Motor 4 - 40 1 azul Libre libre31 PC_motores PP_señal 35 28 gris Cable bus 15v Hembra esp Hembra esp.

Resultados Experimentales 87


5. Diseño Software. El núcleo del sistema electrónico de control de tracción es un microcontrolador.

Este dispositivo reúne en un circuito integrado un microprocesador, memorias y

periféricos cuya adaptación a la tarea específica que deben realizar ya no se realiza

mediante conexiones hechas por el usuario, sino que se realizan a través del

código de un programa.

Para esto es necesario conocer el dispositivo a nivel físico, pero también el

lenguaje de programación para configurarlo y asignarle tareas, así como otras

herramientas para convertir el programa en un código que sea comprensible para la

máquina.

Estos programas realizados desde un entorno de desarrollo en el PC son

cargados en el microcontrolador y depurados en el circuito mediante herramientas

hardware de desarrollo.

En este capítulo se describen estos procesos y se documentan las labores

realizadas para elegir un microcontrolador, configurarlo y crear un entorno listo

para prestar servicio a las aplicaciones que se van a realizar.

5.1. Elección del microcontrolador

5.1.1. Microcontroladores Microchip PIC

Existen numerosos fabricantes de microcontroladores válidos para la aplicación

que se está llevando a cabo. Sin embargo, la búsqueda del dispositivo adecuado se

centra en uno: Microchip Technology Inc [21].

La principal razón es la familiaridad del autor del trabajo con los dispositivos de

este fabricante. Las principales ventajas de recurrir a Microchip para este proyecto

son:

- Se proporciona abundante información, documentación y ejemplos

para descargar en su página web.



- Es un fabricante conocido y utilizado por una amplia comunidad de

desarrolladores, lo que facilita el intercambio de información y

recursos.

- Microchip envía gratuitamente muestras de la mayoría de sus

productos, en cantidad suficiente para diseñar y construir prototipos.

Se tiene así acceso a todo su catálogo, que es muy extenso, y se

puede optar por el dispositivo más adecuado sin que la disponibilidad

sea un problema, cosa que sí ocurriría si hubiera que adquirirlo en

comercios de electrónica.

En caso de tener que adquirirse, el coste del microcontrolador no es

representativo en el coste total del proyecto, mientras que en el tiempo de

desarrollo sí afectan decisivamente las demás circunstancias expuestas.

La elección del microcontrolador se realiza en dos pasos:

1. Elección de la familia.

2. Elección del microcontrolador.

5.1.2. Elección de la familia. La familia PIC33F

Los microcontroladores de Microchip se agrupan en familias según el número

de bits de su arquitectura de datos: 8, 16 ó 32.

Desde la web del fabricante se proporciona un motor de selección de

dispositivos según la aplicación. En este caso corresponde a control de motores,

para lo que se recomiendan familias de 8 y 16 bits. Dentro de la segunda se

encuentran la familia PIC24 y los DSC (controladores digitales de señal), integrada

por las familias PIC30 y PIC33.

Los DSC son dispositivos que añaden a la tradicional arquitectura de un

microcontrolador, recursos propios de DSP´s (procesadores digitales de señal), lo

que los convierte en una opción muy atractiva para aplicaciones de control.



Ilustración 45. Diagrama de la familia dsPIC. Fuente: web de Microchip (www.microchip.com)

Las principales características de esta familia son:

- Núcleo DSC

- Hasta 40/70 MIPS (millones de instrucciones por segundo), a 3,3V.

- Desde 12 hasta 536KB de memoria Flash, hasta 30KB de RAM.

- Base de tiempos dedicada para hasta 8 salidas PWM de control de

motores.

- Hasta 2 módulos QEI para la gestión de encóder de cuadratura.

- Hasta 2 comparadores con 20 nanosegundos de tiempo de

respuesta.



- Amplificadores operacionales integrados.

- Hasta 16 canales de conversor A/D de 10 bits de resolución a 1,1

MSPS

- Conversor A/D de 12 bits de resolución.

- Hasta 8 canales PWM estándar.

- Periféricos de comunicación incluyendo UART, SPI, I2C y CAN

- Encapsulados de entre 20 y 100 pines.

En el momento de realizar la selección sólo estaban disponibles los dsPIC30F

y dsPIC33F. Estos últimos agrupaban los dispositivos más potentes, de cara a una

aplicación general, y además para la aplicación de control de motores de un robot,

los dos módulos QEI presentes en su arquitectura son un periférico muy

conveniente.

Por estas razones se pasó a concretar un dispositivo de la familia dsPIC33F.

5.1.3. Elección del dispositivo. dsPIC33FJ64MC802

Dentro de la familia PIC33F se seleccionó un microcontrolador con buenas

propiedades para la aplicación de control de tracción. A la ya comentada de

disponer de dos módulos QEI se impuso la de estar disponible en un encapsulado

DIL-PDIP para poder integrarse en la tarjeta electrónica pinchando en un zócalo de

dimensiones fácilmente manejables.

El número de patillas (y con ellas, de entradas y salidas) no es tan elevado

como en los encapsulados SMD (28 frente a 44 hasta 128), pero son suficientes

para la aplicación. Esta condición la cumple el dsPIC33FJ64MC802.

Se resumen a continuación las principales características, de este dispositivo:



Tabla 3. Resumen de características del dsPIC33FJ64MC802 de Microchip

Pin

es r

em

ap

eab

les

Tim

er d

e 16

bit

s

Cap

tura

de

en

trad

a

PW

M e

stá

nd

ar

(ou

tpu

t co

mp

are

)

PW

M p

ara

con

tro

l de

mo

tore

s

(Can

ale

s) (

1)

QE

I (In

terf

az

par

a en

cod

er d

e c

uad

ratu

ra)

UA

RT

SP

I

EC

AN

Inte

rru

pc

ion

es e

xte

rna

s

28 64 16 16 5 4 4 6, 2 2 2 2 1 3 1 1 1 6 1/0 2 21 SDIP

dsPIC33FJ64MC802

Co

mp

ara

do

r an

aló

gic

o (

2ca

nal

es /

Re

cula

do

r d

e v

olt

aje)

Pu

ert

o p

ara

lelo

de

8b

its

(L

íne

as

de

d

ire

cció

n)

Pa

tilla

s d

e en

tra

da

/ sa

lida

En

cap

su

lad

o

RT

CC

(R

elo

j y

ca

len

da

rio

)

I2C

Ge

ner

ado

r C

RC

AD

C 1

0 b

its

/ 12

bit

s (

can

ales

)Periféricos remapeablesP

atil

las

Mem

ori

a F

lash

de

pro

gra

ma

(Kb

yte)

RA

M (

Kb

yte

)

5.2. Creación de proyectos y aplicaciones con el dsPIC

5.2.1. Lenguajes de programación. El lenguaje C

Para la programación del microcontrolador es necesario utilizar un lenguaje de

programación: se utilizan fundamentalmente dos lenguajes en distintos niveles de

abstracción:

- Bajo nivel: ENSAMBLADOR.

Se caracteriza porque sus instrucciones tienen un equivalente inmediato en

código máquina, el único que el procesador realmente comprende, de manera que

la programación se hace a través de una interacción directa con el nivel físico.

- Alto nivel: LENGUAJE C

Se trata de un lenguaje de alto nivel normalizado muy extendido que resulta

cercano a la lógica del programador.

Puesto que no es un lenguaje directamente comprensible para el procesador,

un programa intermedio (compilador) debe traducir de C a ensamblador, de modo

que el grado de optimización del código final obtenido depende mucho de dicho

compilador, afectando al consumo de memoria y a la velocidad de ejecución de los

programas.

El lenguaje C presenta ventajas importantes a la hora de realizar una

aplicación:



- Mayor facilidad de programación. El lenguaje C dispone de un

conjunto de operadores, datos y comandos que le confieren, al

mismo tiempo, potencia y facilidad de programación, lo que permite

un tiempo de desarrollo de programas mucho menor que con el

lenguaje Ensamblador.

- Portabilidad entre sistemas. Con el lenguaje C se asegura la

portabilidad entre diferentes plataformas hardware o software, lo que

quiere decir, por ejemplo, que un algoritmo implementado en C en

una plataforma con Linux puede ser adaptado, prácticamente sin

modificaciones, a un PIC. Esto permite el aprovechamiento de

numerosos algoritmos que se encuentran ya disponibles para otras

plataformas diferentes a los PIC. El Ensamblador, por el contrario, ya

se ha indicado que es fuertemente dependiente del hardware, por lo

que no permite su adaptación de una plataforma a otra distinta.

- Desarrollo de programas estructurados. El lenguaje C permite

desarrollar programas estructurados en funciones, bloques o

procedimientos, lo que proporciona una compartimentación del

código. Por el contrario, el Ensamblador no es un lenguaje

estructurado, lo que lleva a que los programas desarrollados en

ensamblador sean lineales, con el inconveniente que esto implica en

lo que se refiere a claridad del código escrito.

- Fácil mantenimiento de los programas. Por ser un lenguaje de

compresión relativamente fácil.

Aunque el desarrollo de programas para microcontroladores es posible

realizarlo totalmente en ensamblador, la utilización del lenguaje C supone una

alternativa muy interesante por su rapidez, facilidad, y portabilidad, sin que esto

signifique sustituir completamente al ensamblador: en casos en los que se necesita

crear partes de código sujetas a determinadas restricciones ( reducido número de

instrucciones, alta velocidad de ejecución, uso de hardware específico…) se puede

implementar esa parte de código directamente en ensamblador dentro de un

programa en C, consiguiendo de este modo un código mucho más eficiente.

Por todas estas razones en lo sucesivo será el lenguaje al que nos refiramos

por defecto en el desarrollo de aplicaciones con el pic.



5.2.2. Herramientas de desarrollo. El compilador MPLAB C para dsPIC

Microchip proporciona un conjunto de herramientas para el desarrollo de

aplicaciones en lenguaje C. Entre ellas se encuentra el compilador “MPLAB C para

dsPIC DSCs” que es gratuito en su versión de evaluación (la de menor optimización

de código generado).

Además del propio compilador, se proporcionan las “Librerías de herramientas

del lenguaje” (16-Bit Language Tools Libraries) [22] consistentes en:

- Librería estándar de C

Incorpora la mayoría de funciones normalizadas ANSI-C.

- Librería DSP

Está formada por un conjunto de funciones de procesamiento digital de

señal orientadas a su ejecución en los dsPIC30F/33F.

- Librería matemática de punto fijo

Provee un juego de funciones optimizadas para las aplicaciones más

comunes de procesamiento de señal, permitiendo ahorros de tiempo

importantes frente a funciones equivalentes codificadas en C. Las

aplicaciones típicas van desde el control de motores, control digital de

energía, pasando por el procesamiento digital de señales, hasta el

control en tiempo real utilizando formatos de datos fraccionales. Los

formatos presentes en la librería son el Q15 (1.15) y el Q16 (15,16).

- Librería matemática de coma flotante

Se trata de la versión compilada, compatible con IEEE-754 de la librería

matemática de C <math.h> incluyendo funciones aritméticas y

trigonométricas de simple (32bits) y doble precisión (64 bits).

Para comenzar en el desarrollo de aplicaciones en C, Microchip proporciona un

documento de referencia, 16-Bits Language Tools Getting Started [23],

(“Comenzando con las herramientas de lenguaje para 16bits”).

El entorno de desarrollo para estas herramientas es el software MPLAB IDE,

que puede descargarse gratuitamente desde la página de Microchip.



Ilustración 46. Logo del entorno de desarrollo MPLAB IDE de Microchip

Son muy recomendables las siguientes lecturas complementarias:

- MPLAB® Assembler, Linker and Utilities for PIC24 MCUs and

dsPIC® DSCs User’s Guide (DS51317) [24]

- MPLAB C Compiler for PIC24 MCUs and dsPIC® DSCs User’s

Guide (DS51284) [25]

- Documentación específica sobre el dispositivo: hojas de

características del dispositivo, de su familia así como el manual de

referencia para el programador.

5.2.3. Elementos de un proyecto

El capítulo 2 de [23] desarrolla el tutorial “Cómo crear un proyecto”. Un

proyecto en MPLAB está formado por algunos o todos los siguientes archivos:

- Archivo de código fuente: En él o ellos se especifica el dispositivo

sobre el que se va a programar, indicándose los archivos de

cabecera, librerías y objetos que deben incluirse en el proyecto. Se

configura el dispositivo y se implementan los procedimientos que

darán lugar a la funcionalidad que se pretende del dispositivo.

- Archivos de cabeceras: Estos archivos desarrollan los términos que

se usan a nivel software para referirse al hardware de la máquina,



por ejemplo, indicando a qué posición de la memoria de datos se

refiere el registro de configuración de un periférico.

- Archivos de objetos: Estos archivos pueden ser de muchos tipos,

por ejemplo fracciones de código pre-compilada que puede

insertarse directamente en el código final.

- Archivos de librerías: archivos en los que se definen funciones para

facilitar procedimientos de cualquier tipo: desde la configuración del

dispositivo hasta otras para desempeñar funcionalidades.

- Script de unión (Linker script) : comprueba que en las rutas

indicadas existen los ficheros a los que se va a hacer referencia en el

proyecto. Define las regiones de memoria y tamaño de los mapas

según el dispositivo del que se trate (*gld para C30; *lkr para asm).

- Otros archivos

Ilustración 47. Estructura de archivos de un proyecto en MPLAB

En la guía de uso del compilador [25] se describe el flujo de datos a través de

las herramientas de desarrollo sofware:



Ilustración 48. Flujo de datos a través de las herramientas software. Tabla 1-1 de la guía de uso del compilador.

La principal diferencia del compilador MPLAB C con el lenguaje C estándar

está en la utilización de archivos de soporte para el dispositivo.

Estos archivos son:

- Archivo de cabecera, (*.h). Define los registros con funciones

especiales (SFR) disponibles para un dispositivo. La sintaxis típica

es:

Si el registro tiene bits individuales, habrá también una estructura definida para

ese SFR y su nombre será como el del SFR pero seguido de ‘bits’.

#include <p33fj64mc802.h>



- Archivo “linker”: los archivos de cabecera nombran los SFR para un

dispositivo, pero no indican su dirección en el mapa de memoria,

labor que se realiza a través de este archivo de externsión *.gld.

5.3. Configuración del dsPIC33FJ64MC802

5.3.1. Hoja de características del dispositivo

Una vez revisada la documentación de carácter general a la que se hace

referencia en el apartado anterior puede abordarse la realización de aplicaciones

específicas con el microcontrolador seleccionado.

Para ello el primer paso será familiarizarse con sus características, y

configurarlo para que los recursos físicos disponibles presten el servicio adecuado

a la aplicación que se desea implementar.

El documento de referencia fundamental es el datasheet u hoja de

características del dispositivo, en el que en general se agrupan varios modelos que

/* CORCON: CPU Mode control Register */ extern volatile unsigned int CORCON __attribute__((__near__)); typedef struct tagCORCONBITS unsigned IF :1; /* Integer/Fractional mode */ unsigned RND :1; /* Rounding mode */ unsigned PSV :1; /* Program Space Visibility enable */ unsigned IPL3 :1; unsigned ACCSAT :1; /* Acc saturation mode */ unsigned SATDW :1; /* Data space wr saturation enable */ unsigned SATB :1; /* Acc B saturation enable */ unsigned SATA :1; /* Acc A saturation enable */ unsigned DL :3; /* DO loop nesting level status */ unsigned :4; CORCONBITS; extern volatile CORCONBITS CORCONbits __attribute__((__near__));



comparten las mismas características. Para el dsPIC33FJ64MC802 el documento

es el DS70291E [26].

Las hojas de características no son un manual para la iniciación o el

aprendizaje en el desarrollo de aplicaciones con el dispositivo, sino una descripción

estructurada del mismo.

Comienza describiendo las principales características y encapsulados

disponibles, así como funciones de las patillas en cada uno de ellos. A

continuación, en cada capítulo se desarrolla un tema de forma general,

comenzando siempre por referenciar hacia fuentes de información más específicas

sobre ese tema, y a otros capítulos relacionados.

Los temas de referencia específicos se encuentran agrupados en el “Manual

de referencia para la familia dsPIC33F” (dsPIC33F Family Reference Manual) [27].

Son hasta 45 secciones distribuidas en 6 partes. Se hará mención específica de las

que sean de aplicación para este proyecto.

5.3.2. Arquitectura del dsPIC33FJ64MC802

El microcontrolador PIC tiene una arquitectura Harvard modificada, con un

juego de instrucciones mejorado que incluye soporte para procesamiento digital de

señal, como se muestra en la Tabla 4.

La CPU tiene una palabra de instrucción de 24 bits.

Todas las instrucciones se ejecutan en un solo ciclo, con la excepción de las

que cambian el flujo de programa.

Se dispone de 16 registros de trabajo de 16 bits, el último de los cuales (W15)

funciona como puntero de pila software para interrupciones y llamadas a rutinas.

Hay dos clases de instrucción: las de tipo MCU (tipo microcontrolador) y las

DSP (de procesamiento digital)

5.3.2.1. Motor DSP

Está formado por un multiplicador de alta velocidad de 17 bits por 17 bits, una

ALU de 40 bits, dos acumuladores de 40 bits y un desplazador (barrel shifter)

bidireccional de 40 bits.



La principal instrucción de un DSP es la MAC (multiplicación y acumulación).

Gracias a la arquitectura de doble bus (X, Y), se puede coger dos datos de áreas

diferenciadas de la memoria, mientras se multiplican dos registros de trabajo W y se

acumula el resultado, todo en el mismo ciclo.

YXAAMAC :

Ecuación 1. Multiplicación MAC

5.3.2.2. Características MCU especiales

La ALU MCU comparte con el motor DSP el multiplicador de 17x17 bits de un

solo ciclo. Utilizado para la multiplicación de números de 16 bits por 16 bits permite

multiplicaciones con signo mixtas.

El pic soporta divisiones 16/16 y 32/16 bits, tanto fraccionarias como enteras,

que se ejecutan con operaciones iterativas, dentro de un bucle REPEAT, resultando

un tiempo de ejecución de sólo 19 ciclos de instrucción.

También el desplazador es compartido entre el motor DSP y la ALU MCU.



Tabla 4. Diagrama de bloques del dsPIC33FJ64MC802. Fuente: Figura 1-1 DS70291E pag.16



5.3.3. Características especiales. Registros de configuración

Existen una serie de registros de los que depende el funcionamiento de las

características especiales del dispositivo. Estos se encuentran ubicados en una

zona de la memoria de programa sólo accesible en la etapa de grabación, y

pueden dejarse indicados en el código del programa.

Para este dispositivo son:

- Bits de configuración para las memorias Flash y RAM:

o _FBS(x)

o _FGS(x)

- Bits de configuración para la selección de oscilador:

o _FOSCSEL(x)

o _FOSC(x)

- Bits de configuración para el “perro guardián”:

o _FWDT(x)

- Bits para otras funciones generales como asignación de patillas a

periféricos, reset, JTAG, ICSP, etc.

o _FPOR(x)

o _FICD(x)

Donde (x) re refiere a las opciones de configuración, que pueden ser macros

predefinidas en los archivos de cabecera (*.h ó *.inc). Se instala por defecto en:

C:\Archivos de programa\Microchip\mplabc30\v3.25\support\dsPIC33F\h

Como ejemplo se reproduce lo que puede encontrarse para _FOSCSEL:



En las aplicaciones de este programa se utiliza la siguiente configuración:

// Configuracion proteccion flash y ram _FBS(BWRP_WRPROTECT_OFF) // Sin proteccion de escritura _FGS(GCP_OFF) // Sin protección de código // Seleccion del oscilador: _FOSCSEL( FNOSC_FRCPLL & IESO_OFF ) // Fast RC oscillator w/ divide and PLL, two speed off _FOSC(FCKSM_CSDCMD & OSCIOFNC_ON & POSCMD_NONE & IOL1WAY_OFF ) //Clock switch disable, OSC2 digital I/O, Primary oscilator disabled, Allow multiple //reconfig for PeriPortSelect // Configuracion del watch dog _FWDT(FWDTEN_OFF) // Watchdog disabled // Configuraciones generales: I2C, JTAG.. _FPOR(PWMPIN_ON & HPOL_ON & LPOL_ON & FPWRT_PWR1) // PWM Module pins controlled IO port, Active High PWMH y PWML, Power on reset disab _FICD( ICS_PGD1 & JTAGEN_OFF ) // ICD communication channel on PGC1 y PGD1, JTAG port OFF

;----- FOSCSEL (0xf80006) -------------------------------------------------- ; ; Las siguientes posibilidades están disponibles para FOSCSEL: ; ; Oscillator Source Selection: ; FNOSC_FRC Oscilador rápido RC ; FNOSC_FRCPLL Oscilador FRC con PLL ; FNOSC_PRI Oscilador primario (XT, HS, EC) ; FNOSC_PRIPLL Oscilador primario (XT, HS, EC)con PLL ; FNOSC_SOSC Oscilador secundario ; FNOSC_LPRC Oscilador bajo consumo ; FNOSC_FRCDIV16 Oscilador FRC con division por 16 ; FNOSC_LPRCDIVN Oscilador FRC bajo consumo con division por N ; ; Configuración de oscilador a dos velocidades: ; IESO_OFF Deshabilitado ; IESO_ON Habilitado .equiv FNOSC_FRC, 0xFFF8 ; FRC .equiv FNOSC_FRCPLL, 0xFFF9 ; FRC con division y PLL .equiv FNOSC_PRI, 0xFFFA ; Oscilador primario (XT, HS, EC) .equiv FNOSC_PRIPLL, 0xFFFB ; Oscilador prim. (XT, HS, EC) w/ PLL .equiv FNOSC_SOSC, 0xFFFC ; Oscilador secundario .equiv FNOSC_LPRC, 0xFFFD ; Oscilador RC bajo consumo .equiv FNOSC_FRCDIV16, 0xFFFE ; FRC div 16 .equiv FNOSC_LPRCDIVN, 0xFFFF ; FRC bajo consumo con division por N

.equiv IESO_OFF, 0xFF7F ; Deshabilitado .equiv IESO_ON, 0xFFFF ; Habilitado



5.3.4. Configuración del oscilador

El oscilador es el sistema responsable de generar los pulsos que marcan el

funcionamiento de todo el microcontrolador. Por ello hacerlo “latir” es el primer paso

que debe darse.

Se permiten 12 opciones como reloj del sistema. Pueden utilizarse dos señales

de reloj, dando lugar a un reloj primario y a otro secundario.

La señal para el reloj primario puede proceder:

- Del exterior, XT (cristal entre 3 y 10 MHz) o de alta velocidad, HS (entre 10

y 40 MHz) a través de las patillas OSC1 y OSC2,

- Del propio dsPIC, de un oscilador interno rápido RC (FRC) a 7,37 MHz.

En ambos casos puede configurarse un PLL para obtener frecuencias mayores

o bien un ajuste diferente.

La señal para el reloj secundario puede ser externa LP a 32,768 KHz a través

de las patillas SOSC1 y SOSC2 ó interna LPRC a la misma frecuencia, y puede

utilizarse para el “perro guardián” (WDT) y el “monitor de fallo seguro” FSCM.

Ilustración 49. Diagrama de bloques del oscilador. Fuente: figura 9-1 de DS70291E pag. 146



De entre las distintas opciones que el dispositivo permite, resultan

especialmente interesantes dos:

- Cristal de cuarzo externo.

La generación de pulsos mediante circuitería externa tiene como principal

ventaja la utilización de componentes estables y calibrados en valores conocidos.

En particular, se trataría de incorporar entre las patillas 13 CLKI) y 14 (CLKO) un

cristal de cuarzo oscilando a una frecuencia conocida, de entre 3 y 10 MHz para

modo XT y entre 10 y 40 MHz para modo HS. Debe interponerse entre ambas

patillas una resistencia externa de 1 MΩ

La principal desventaja es la dedicación de dos patillas y la necesidad de

componentes externos.

Hay una complicación más: si se utiliza el PLL interno para aumentar la

frecuencia del oscilador, sus características de arranque imponen que el oscilador

externo sea de una frecuencia igual ó inferior a 8MHz. En otro caso, debe

arrancarse con el oscilador interno y a continuación cambiarse al modo de oscilador

externo.

Precisamente por ello el oscilador interno FRC es de una frecuencia

ligeramente inferior a los 8 MHz (en concreto 7,3728MHz).

- Oscilador interno FRC

Este oscilador se basa en la resonancia de un circuito RC. No está calibrado

por el fabricante, pero se permiten ajustes por software haciéndolo suficiente para

aplicaciones sin exigencias estrictas de sincronización.

Por otro lado, utilizar los recursos internos simplifica la circuitería y deja

disponibles las dos patillas del oscilador externo para otros usos.

Por estas razones se opta por este oscilador en las aplicaciones del proyecto.

En el arranque del micro, el oscilador es determinado desde los registros de

configuración. Posteriormente puede cambiarse la fuente de reloj hacia lo que se

seleccione en el registro de control del oscilador: OSCCON, aunque no se hará en

las aplicaciones del proyecto.



La señal del oscilador es conducida a la entrada del PLL con el deseo de

aumentar la frecuencia. Si se deseara disminuir la frecuencia del sistema, también

se dispone de un prescaler que tomaría pulsos uno de tantos.

Para configurar el lazo PLL es necesario recurrir a la información adicional

aportada en el documento “Section 39. Oscillator (Part III)” (DS70216) que forma

parte de [27]. Básicamente consiste en asignar valores de ganancias a los distintos

bloques que forman el lazo, comprobando iterativamente que los valores de ciertos

parámetros se encuentran siempre en rangos permitidos.

Los registros implicados son: CLKDIV, PLLFBD y OSCTUN.

Según la ecuación 9-2 de las hojas de características:

21 NN

MFinFosc

Ecuación 2. Frecuencia de oscilador

Para los valores calculados: Fin= 7,37MHz; M=65; N1=3; N2=2, se tiene que

Fosc=79,84MHz.

Teniendo en cuenta la ecuación 9-3 en la que Fcy= Fosc/2. Por tanto la

frecuencia de instrucciones del sistema es Fcy= 39,92 MIPS.

Ilustración 50. Esquema de configuración del oscilador con PLL



5.3.5. Configuración de entradas y salidas del dispositivo

De las 28 patillas del dsPIC en encapsulado PDIP, 15 pueden asignarse a los

puertos de entrada y salida.

En general, los puertos se encuentran multiplexados con señales de los

periféricos, y será el multiplexor el encargado de asignar el control de las señales

de la patilla a unos u otros. Cuando un periférico está habilitado y utilizando una

patilla, el uso de la misma como salida de uso general se encuentra deshabilitado.

Cada patilla de un puerto tiene tres registros asociados a su funcionamiento

como entrada/salida digital:

- TRISx determina si la patilla será una salida o una entrada.

- LATx almacena el valor actual del bit en el puerto.

- PORTx es un camino a leer el valor de la patilla en el puerto y a

escribir el LATx.

Ilustración 51. Estructura típica de un puerto que comparte patilla con un periférico. Fuente: Figura 1.1 de DS70291E



Algunas patillas pueden configurarse individualmente como salidas “colector

abierto”, lo que permite proporcionar un nivel alto de hasta 5V utilizando una

resistencia pull-up externa. Estas aparecen marcadas con sombra en la Ilustración

52.

Algunas patillas pueden funcionar como entradas analógicas para los

conversores A/D. Esta funcionalidad, que es citada como ANx, se configura desde

el registro AD1PCFGL y las patillas que la tienen vienen como analógicas por

defecto.

Existe la posibilidad de generar interrupciones por cambio en el valor de las

patillas de entrada y salida. Esta prestación se cita como CNx, y se configura desde

los registros CNEN1 y CNEN2. Las patillas CNx incorporan una resistencia pull-up

débil que puede utilizarse en algunas aplicaciones.

Tabla 5. Asignación de patillas del dsPIC por sistemas

Patilla Nombre Función ppal. Sistema Func. Alternativa 1 Sistema alt.

1 MCLR/Vpp Reset CIRCUITERÍA PIC Vpp ICSP2 AN0 CS 1 CONTROL MOTOR IZDA.3 AN1 CS 2 CONTROL MOTOR DCHA.4 PGED1/RP0 PGED1 ICSP RX (UART 1) UART 15 PGEC1/RP1 PGEC1 ICSP TX (UART 1) UART 16 RB2/RP2 TX (UART1) UART 1 RTS UART 17 RB3/RP3 RX (UART 1) UART 1 CTS UART 18 Vss CIRCUITERÍA PIC9 CLKI/RA2 Puerto LIBRE CLKI Reloj externo10 CLKO/RA3 Puerto LIBRE CLKO Reloj externo11 RB4 Puerto LIBRE12 RA4 Puerto LIBRE13 Vdd CIRCUITERÍA PIC14 RB5 Puerto LIBRE15 RB6 2A CONTROL MOTOR DCHA.16 RB7 2B CONTROL MOTOR DCHA.17 PWM2H1 2PWM CONTROL MOTOR DCHA.18 RB9 1A CONTROL MOTOR IZDA.19 Vss CIRCUITERÍA PIC20 Vcap CIRCUITERÍA PIC21 PWM1H3 1PWM CONTROL MOTOR IZDA.22 RB11 1B CONTROL MOTOR IZDA.23 RB12 QEI1A ENCÓDER IZDA.24 RB13 QEI1B ENCÓDER IZDA.25 RB14 QEI2A ENCÓDER DCHA.26 RB15 QEI2B ENCÓDER DCHA.27 Avss CIRCUITERÍA PIC28 Avdd CIRCUITERÍA PIC

ASIGNACIÓN DE FUNCIONES A PATILLAS DE MICRO dsPIC33FJ64MC802



Ilustración 52. Funciones asignadas a las patillas del dsPIC

5.3.6. Módulo de conteo Timer 1

Se trata de un timer de 16 bits, que puede usarse como contador de tiempo

real, de intervalos libres o como simple contador de pulsos.

En la aplicación de control del robot, se utiliza durante la ejecución de una

orden de movimiento para generar interrupciones periódicas en cuya rutina de

atención de interrupción se sitúa el código responsable de determinar la velocidad

base, realizar los cálculos cinemáticos y el control de velocidad, para establecer el

accionamiento de los motores.

Ilustración 53. Diagrama de bloques del Timer 1. Fuente: Figura 12.1 de DS70291



El modo de funcionamiento se selecciona con los bits TCS, TGATE y TSYNC.

Para establecer el modo “Timer”: TCS=0, TGATE =0 y TSYNC indiferente.

El timer arranca al activar el bit TON (TON=1).

El grupo de bits TCKPS<1:0> configuran el pre-escalado de entrada para el

módulo. Son potencias de 2.

Como se justifica en el apartado 5.4.3.1, se utiliza un período de interrupción

de 25ms, que equivalen a un millón de ciclos del reloj del sistema, por lo que el

producto del prescaler por el acumulador debe dar una cifra cercana a esa

cantidad.

Se encuentra que con un pre-escalado de 1:64 y un valor de 15625 cuentas en

el acumulador PR1 se alcanzan el número de ciclos de forma exacta.

Esto es: TCKPS= 10; PR1= 15625.

El código de configuración del módulo es:

La rutina de atención a la interrupción tiene como declaración la siguiente:

void __attribute__((__interrupt__)) _T1Interrupt (void)

5.3.7. Selección de patillas para uso por periféricos (PPS)

Existe una funcionalidad del dsPIC que aumenta mucho su versatilidad al

permitir al desarrollador amoldar el micro a la aplicación en vez de amoldar la

aplicación al micro. Se trata de la selección de patillas para periféricos, PPS.

void InitTMR1(void) TMR1 = 0; // Reset timer counter T1CONbits.TON = 0; // Apagando el timer 1 T1CONbits.TSIDL = 0; // El modulo continua durante modo sleep T1CONbits.TGATE = 0; // Gated timer accumulation disabled T1CONbits.TCS = 0; // se usa Tcy como fuente de reloj T1CONbits.TCKPS = 2; // Tcy / 64 as input clock PR1 = 15625; // Período de interrupción de 25ms con prescaler de 64 IFS0bits.T1IF = 0; // Bajar bandera de interrupción por TMR1 IEC0bits.T1IE = 1; // Habilitando interrupcion por TMR1 T1CONbits.TON = 1; // Encendiendo TMR1 return;



Consiste en configurar el mapa de patillas asignadas a las entradas y salidas

de periféricos por vía software. Las patillas que pueden ser remapeadas son citadas

como RPx.

Esta acción puede hacerse en tiempo de ejecución, y por ser crítica, para evitar

daños la operación requiere seguir una secuencia de desbloqueo de un cerrojo,

previo y posterior a la escritura del registro que controla el direccionamiento.

5.3.7.1. Mapeo de entradas a periféricos

El mapeo del entradas a periféricos se realiza en base al periférico.

Un registro de control asociado a cada periférico determina la patilla a la que

están vinculadas sus entradas: RPINRX. Cada registro contiene campos de 5bits,

de manera que en esos 5 bits se apunta la patilla RPx a la que va ligado.

Como ejemplo, el mapeo de la entrada RX al periférico UART1: la señal de

entrada U1RX es tomada por el periférico de la patilla que se indica en los bits de

configuración U1RXR<4:0> del registro RPINR18 (Ver tabla 11-1 del datasheet para

todas las opciones).

Ilustración 54. Multiplexado de la entrada U1RX del periférico UART desde distintas patillas del micro. Fuente: Figura 11-2 de DS70291E



5.3.7.2. Mapeo de salidas de periféricos

A diferencia de las entradas, las salidas de periféricos se mapean en base a la

patilla de salida. Los registros RPORx, contienen campos de 5 bits asociados a

cada una de las 16 patillas RPx, de modo que esos 5 bits determinan el periférico

conectado a dicha patilla. El juego 00000 en el registro de una patilla permite

mantenerla desasociada de cualquier periférico.

Como ejemplo, el mapeo de la salida TX del periférico UART1: se conduce

hasta la patilla RPn la salida de periférico indicada por los bits RPnR<4:0>, 00011

para TX de UART1 (ver tabla 11-2 de DS70291 para todas las opciones).

Ilustración 55. Multiplexado de una patilla de salida desde varios periféricos. Fuente: Figura 11-3 de DS70291E

5.3.8. Módulo PWM para control de motores.

La modulación de anchura de pulso (PWM) es una técnica utilizada para variar

la alimentación de una carga mediante la variación del tiempo efectivo que ésta



permanece activada, gracias a la conmutación de alta frecuencia con dispositivos

electrónicos.

Aplicada sobre la estructura de puente H de la etapa de potencia del robot,

permite variar la velocidad de giro de los motores en ambas direcciones.

El dsPIC33FJ64MC802 incorpora un módulo hardware orientado a la

generación de las señales PWM que tiene las siguientes características de interés:

- Hasta 6 canales de hasta 16 bits de resolución, con tres generadores

independientes de tiempo activo (duty cycle).

- Disparo del conversor A/D dependiente de la operación PWM.

- Modos de operación “alineación al centro” o “alineación con el

flanco”.

- Frecuencia PWM con reloj del sistema a 40MIPS de 40KHz con

resolución de 11 bits en modo alineado con el flanco.

Para una descripción detallada del módulo es necesario recurrir al documento

“Section 14. Motor Control PWM” (DS70187) de [27] (Family Reference Manual).



Ilustración 56. Diagrama de bloques del módulo PWM de 6 canales (PWM1). Fuente: figura 16-1 de DS70291

El bloque funcional “PWM Time Base” se ocupa de generar el período de la

señal PWM.

El módulo utiliza un contador de pulsos o TIMER de 15 bits, PxTMR al que

llegan los pulsos de reloj tras ser pre-escalados (uno de tantos). La lógica se

encarga de comparar este valor con el del registro en el que se carga el número de

pulsos correspondientes a un período deseado PxTPER y al igualarse, se pone a 0



el valor en el contador y se genera la señal correspondiente a un nuevo pulso

PWM.

Los parámetros definitorios de la señal PWM son:

- Período: determina la duración total de cada señal elemental.

- “Duty Cycle” o período activo: parte activa de la señal elemental.

Se desea generar una señal PWM a una frecuencia en el entorno de 10KHz,

esto es, con un período aproximado de 1/10000 = 100 microsegundos.

Oscilando a 40 MIPS el período del oscilador principal es de 0,025

microsegundos. Por tanto, el período deseado supone 4000 pulsos del oscilador

principal.

MÁXIMA RESOLUCIÓN DEL PWM PARA CONDICIONES DE

FUNCIONAMIENTO

La resolución máxima que puede alcanzarse depende de la frecuencia de

trabajo del oscilador y de la frecuencia de la señal que se desea generar.

Según la ecuación 14.3 en la página 14 de [27]:

PWM

CY

F

FionPWMresolut

2log 2

Ecuación 3. Resolución de módulo PWM

Luego

max1210

402log

3

6

2 bitse

eionPWMresolut

El registro PxTMR es de 15 bits, por lo que sin pre-escalado, podrían

abarcarse hasta 32767 ciclos de reloj, luego 0,819 milisegundos. Esto podría ser

suficiente para trabajar a 10KHz, pero no para frecuencias PWM menores, por lo

que resulta aconsejable interponer un pre-escalado:

- PS 1:16



Permite un período máximo de: 0,025 us* 16*2^15= 13,107 ms

Y una precisión de: 0,025 us* 16 = 0,4 us

- PS 1:4

Permite un período máximo de: 0,025 us*4*2^15= 3,2768 ms

Y una precisión de: 0,025us*4=0,1us

Resulta ventajoso elegir el prescaler de 1:4 porque permite más resolución en

la señal PWM generada. Esto se consigue cargando el valor binario 01 al registro

PTCKPS<1:0>.

CONFIGURACIÓN DEL PERÍODO:

El período de la señal PWM se determina configurando el número de cuentas

de la base de tiempos, en el registro PTPER<14:0>

Para este caso, deseando una frecuencia de 10 KHz, utilizando la ecuación 14-

1 de [27]:

1Pr_

escalerPxTMRF

FPxTPER

PWM

CY

Ecuación 4. Configuración del período PWM

99914310

640

e

ePXTPER

El contador PxTPER se incrementa en una unidad cada 0,1 us.



CONFIGURACIÓN DEL CICLO ACTIVO (DUTY CYCLE)

Ilustración 57. Resolución y sincronismo según PxTMR y PxDCY en modo "Free running" y

prescaler 1:1. Fuente: Figura 14-15 de Family Reference Manual.

Ilustración 58. Lógica de comparación del ciclo activo (Duty Cycle). Fuente: figura 14-16 de

Family Reference Manual.

El objetivo del circuito lógico asociado al DCy es generar en el instante

programado un flanco. Para ello, se comparan los registros PxTMR (15 bits), timer

del módulo PWM con los 15 bits más significativos <15:1> del registro PxDCy, que

almacena el valor programado para el período activo, de modo que se genera un

flanco cuando ambos son iguales.



El utilizar los 15 bits más significativos implica dividir por dos el valor del

registro completo. Por tanto, por resumirlo de forma sencilla, el valor que debe

cargarse en el registro PxDCy <15:0> debe ser el doble del valor que debe alcanzar

el timer en el su conteo: PxTMR<14:0>.

El valor máximo que alcanza el timer PWM es el que determina el período

PxTPER. Para un ciclo activo del 100% del período de la señal PWM, se cargará en

PxDCy el doble de PxTPER. De forma proporcional entre ese valor y 0 se

consiguen períodos activos entre el 100% y el 0%.

Para los ajustes de configuración del módulo PWM que se incorporan al código

de las aplicaciones con el robot, es conveniente comprobar la señal de salida

esperada. Se utiliza la simulación con MPLAB SIM, que forma parte del entorno de

desarrollo MPLAB

Simulación 1:

P1TPER= 999 (T= 0,1 ms) P2TPER=999 (T2 =0,1ms)

P1DC3=500 (DC=25%) P2DC1=999 (DC2 =50%)

0,0 2000,0 4000,0 6000,0 8000,0 10000,0 12000,0 14000,0 16000,0 18000,0 20000,0 22000,0 24000,0

PWM1H3

PWM2H1

4006

Ilustración 59. Simulación con MPLABSIM de señales PWM para la configuración realizada.



DISPARO DE EVENTOS ESPECIALES

El módulo tiene circuitería para provocar disparos ante eventos especiales

(Special Event Trigger), de una nueva conversión analógico digital en el módulo

ADC. Esto es muy útil para crear lazos de control realimentados.

Esta circuitería compara el valor del contador PxTMR (en base al cual se

genera el período de la señal PWM) con el valor del registro PxSECMP, para

activarse cuando se igualan. Un post-escalado hace que sólo se genere un disparo

una de tantas veces que la comparación resulte positiva. Este post-escalado se

configura en los bits SEVOPS <3:0> del registro PWMxCON2.

Puede ajustarse el punto exacto en el que se fuerza la conversión A/D. El

post-escalado sólo da opciones potencias de 2, por lo que la versatilidad es

limitada.

INTERRUPCIÓN POR DESBORDAMIENTO DEL CONTADOR

La generación de interrupciones en los módulos PWM depende del modo de

operación seleccionado para la base de tiempos (bits PTMOD del registro

PxTCON<1:0>) y del post-escalado seleccionado (con los bits PTOPS del registro

PxTCON<7:4>).

En modo de funcionamiento “free running”, cada vez que el contador de la

base de tiempos PxTMR, alcanza el valor consignado en el registro PxTPER, es

puesto a cero. Se produce en ese instante una solicitud de interrupción. El contador

continúa contando en sentido ascendente.

Se dispone de un post-escalado para que sólo se produzca interrupción en una

de tantas.



5.3.9. Módulo de interacción con encóder de cuadratura QEI

5.3.9.1. Descricpción del módulo

El QEI consiste en un decodificador (máquina de estados) de las señales

típicas procedentes de un encóder incremental (QEA, QEB, INDX), un contador y

un comparador.

Además tiene filtros digitales para las señales y permite disparar interrupciones

ante eventos programados.

Para conocer los detalles de su funcionamiento puede recurrirse al documento

”Section 15. Quadrature Encoder Interface (QEI)” (DS70208) de [27] (Family

Reference Manual).

El módulo QEI incluye:

- Tres entradas QEA, QEB, INDX.

- Filtros digitales programables para las entradas.

- Un decodificador que proporciona pulsos y dirección al

contador.

- Contador de 16bits (0-65000) (POSxCNT)

- Bit testigo de sentido de conteo.

- X2 X4 divisor de escala.

- Dos modos de reset del contador de posición:

o por valor máximo (MAXxCNT)

o por señal del INDEX

- Modo de contador/timer de 16 bit de propósito general

- Generación de interrupciones por el módulo QEI o por

eventos del contador.



Ilustración 60. Diagrama de bloques simplificado de un módulo QEI. Fuente: figura 15-2 de DS70208.

Registros de control y estado:

- QEIxCON: Control del módulo y flags de estado. 0-65000

- DFLTxCON: Configuración del filtro digital

- POSxCNT: Permite la lectura o escritura del contador de

posición.

- MAXxCNT: Mantiene el valor que es comparado con

POSxCNT.

Ilustración 61. Modelo para el programador del QEI



Tabla 6. Registro QEIxCON de configuración del QEI. Fuernte: Registro 15-1 de DS70208

- Bit 15 CNTERR: Bit monitor de error de conteo (1 si un error ha ocurrido).

Sólo si QEIM<2:0>= 110 ó 100

- Bit 14 No implementado. Leído como 0.

- Bit 13 QEISIDL: Parada en modo “idle”, si puesto a 1. Si puesto a 0, continúa.

- Bit 12 INDEX: estado de la patilla “índice”.

- Bit 11 UPDN: bit monitor de dirección de conteo.

- Bit 10-8 QEIM<2:0>

- Bit 7 SWAPAB: Las entradas A y B están intercambiadas (0: no; 1: sí).

- Bit 6 PCDOUT: Habilita el control de la salida por el monitor de dirección de

conteo, de modo que si el bit está activo, la patilla muestra esa salida. Si inactivo, la

patilla tendrá su funcionamiento por defecto.

- Bit 5 TQGATE: bit que habilita el uso del contador de posición como contador

de tiempo.

- Bit 4-3 TQCKPS <1:0> prescaler para la entrada del contador de tiempo (una

de tantas):

111 = QEI habilitado (modo x4) con contador de posición puesto a cero al igualar MAXxCNT 101 = QEI habilitado (modo x2) con contador de posición puesto a cero al igualar MAXxCNT

1 = dirección de contador de posición es positiva (+) 0 = dirección de contador de posición es negativa (-) (Sólo lectura si QEIM <2:0> = 1xx) (Lectura / escritura cuando QEIM<2:0> = 001)



- Bit 2 POSRES: habilitación de puesta a cero para el contador de posición

- Bit 1 TQCS: bit de selección de fuente de pulsos para el contador de tiempo

- Bit 0 UDSRC: bit de control de la dirección del contador de posición

Tabla 7. Registro DFLTxCON de control del filtro digital para QEI. Fuente: registro 15-2 de DS70208.

- Bit 15-11 No implementado.

- Bit 10-9 IMV<1:0> bits de coincidencia para reset por índice. Permite

concretar el estado de las señales QEAx y QEBx para producirse la puesta a cero

al activarse la señal de índice.

- Bit 8 CEID: habilitación de interrupción por error de conteo (1: deshabilitado;

0: activado).

1 = el estado de la patilla QEBx define la dirección de conteo 0 = el bit de control / estado UPDN define la dirección de conteo para POSxCNT

1 = reloj externo en la patilla QEAx (en el flanco de subida) 0 = reloj interno (Tcy)

1 = Pulsos de índice ponen a cero el contador de posición 0 = Pulsos de índice no ponen a cero el contador de posición

11 = 1:256 valor de pre-escalado 10 = 1:64 valor de pre-escalado 01 = 1:8 valor de pre-escalado 00 = 1:1 valor de pre-escalado



- Bit 7 QEOUT: habilitación de salida de filtro digital (1: habilitado; 0:

desactivado).

- Bit 6-4 QECK <2:0> selección del divisor de reloj para el filtro digital:

- Bit 3-0 No implementado

Contador ascendente / descendente de pulsos de posición POSxCNT

Es un registro de 16 bits que admite lectura y escritura. En el modo de

funcionamiento a máxima precisión del QEI (x4), tenemos 64cuentas por revolución

del eje motor. La distancia recorrida correspondiente al máximo de pulsos que el

POSxCNT puede contar es:

- (65536 cuentas/64cpr (motor) *29 rev.motor/ rev.rueda )* pi*9,8cm=

1087,12 cm

Otras magnitudes derivadas:

- 1856 pulsos encoder / vuelta de rueda

- 30,788 cm / vuelta de rueda

- 0,0166 cm/pulso del encóder

Por lo que para desplazamientos simples no será necesario reiniciar el

contador (bastará poner a cero al principio y que la rutina correspondiente se ocupe

de ponerlo a cero al terminar la maniobra).

Uso de MAXxCNT para resetear el contador de posición POSxCNT

En la aplicación de control del robot, los módulos QEI son configurados en

modo x4 (QEIM <2:0> =111). El reset por pulso de índice no es utilizado, y el

contador de posición es reseteado por coincidencia con valores predeterminados

alto y bajo:

111 = 1:256 divisor de reloj para QEAx/QEBx/INDXx 110 = 1:128 divisor de reloj para QEAx/QEBx/INDXx … 000 = 1:1 divisor de reloj para QEAx/QEBx/INDXx



- Si el encóder evoluciona en sentido creciente (esto es, la fase A

adelanta a la fase B), y el valor en el registro POSxCNT alcanza el valor

en registro MAXxCNT, POSxCNT es puesto a 0 en el siguiente pulso de

cuadratura que incremente POSxCNT. Ocurre entonces una

interrupción.

- Si el encóder evoluciona en sentido decreciente (fase B adelanta a fase

A), y el valor en POSxCNT desciende hasta 0, se carga en el registro

POSxCNT el valor en MAXxCNT en el siguiente pulso que decremente

el contador, y en ese instante se produce una interrupción.

Por tanto, para fijar el límite de movimientos hacia delante, el número de pulsos

de recorrido se cargará en MAXxCNT y se pondrá a 0 el contador de posición. Por

el contrario, para movimientos hacia atrás, se cargará el número de pulsos de

recorrido en POSxCNT y el fin del movimiento vendrá dado por la interrupción al

alcanzar el valor 0. El valor de MAXxCNT se establecerá en uno mayor que el de

POSxCNT de partida.

5.3.9.2. Configuración del módulo para la aplicación

Para realizar la configuración de este modulo hardware, se siguen las

indicaciones que se hacen en el documento Measuring Speed and Position with the

QEI Module (DS93002A) [28].

Los encóder utilizados en este proyecto, tienen las siguientes características:

- 2 Canales (A, B) sin pulso índice.

- 64 CPR máximo, contando flancos de subida y bajada (modo x4).

- Valor lógico 1 equivale a Vcc aproximadamente.

Es recomendable filtrar la señal de salida de los encóder para eliminar ruido

de alta frecuencia (glitches).



Ilustración 62. Propagación de señal a través de filtro. Fuente: Figura 4 DS93002A

Como se aprecia en la ilustración, el filtrado de la señal introduce un pequeño

retraso. El filtrado consiste en que no se toman en cuenta cambios que no se

mantengan durante tres flancos de subida del reloj. Por ello, se adapta la señal del

reloj principal con un divisor (toma una de tantas), de modo que la señal a la salida

del divisor tenga una duración menor a un tercio de la mínima señal del encóder.

Para el cálculo del filtro, es necesario obtener la duración del pulso mínimo. Se

considera la Ecuación 1 de [28], en la que el pulso mínimo se calcula a partir de la

resolución del encóder y la velocidad máxima del motor.

- Resolución: 16 flancos ascendentes por vuelta del motor/canal.

- Velocidad máxima del motor: 5100rpm a 12V. Tomo por seguridad

6000rpm.

uscprrpm

segPULSEMIN 5,312

326000

60_

Ecuación 5. Tamaño de pulso de encóder mínimo

Debe utilizarse un divisor de pulsos que puede calcularse con la ecuación 2 de

[28]:

opulsofiltrpulsosFcyumips

DIVFILTER /4,41663

sec5,312*40_

Ecuación 6. Ajuste de filtro software para módulo QEI



Como el máximo divisor es de uno cada 255, con este filtrado pasa-bajos se

rechaza ruido de tiempo característico inferior a 19,125us (frecuencia mayor de

26,143 KHz).

Se selecciona el modo X4 para aprovechar toda la resolución que permite el

módulo, de modo que el contador de posición evoluciona en cada flanco de las

señales QEA o QEB, alcanzando las 64 cuentas por vuelta del eje motor.

Ilustración 63. Señales del encóder en modo x4. Fuente: figura 5 de DS93002A.

5.3.10. Puerto de comunicación serie UART

5.3.10.1. Descripción del módulo

El dsPIC incorpora dos módulos UART (emisor-receptor asíncrono universal).

Se destina uno de ellos a la comunicación para el gobierno de la placa de control de

tracción desde el exterior.

La UART del dsPIC es un sistema “full duplex” (permite comunicación

bidireccional) capaz de comunicar con interfaces RS232, RS484, LIN 2.0 presentes

en numerosos sistemas digitales.

Las características más importantes son:

- full duplex con transmisión de 8 ó 9 bits de datos a través de UxTX y

UxRX

- opciones de paridad: par, impar o sin paridad, para datos de 8 bits.



- uno o dos bits de parada

- posibilidad de control hardware de flujo a través de UxCTS (activa a

nivel bajo) y UxRTS (activa a nivel bajo)

- Generador de baud rate con prescaler de 16 bits.

- Baud rate de 10Mbps hasta 38bps a 40 MIPS.

- Buffer de 4 datos FIFO tanto para recepción como para envío

- Detección de errores.

- Posibilidad de generar interrupción por recepción y envío.

- Interrupción independiente para cada fuente de error

- Modo “loopback” para depuración (salida conducida a entrada).

- Soporte para otras funciones.

Para conocer en detalle el funcionamiento y manejo del módulo es necesario

recurrir al documento “Section 17. UART (DS70188)” de[27] (Family Reference

Manual).

Ilustración 64. Diagrama de bloques simplificado de puerto UART. Fuente: figura 17-1 de DS70188D



Registros de control y estado:

- UxMODE: registro que controla el modo de funcionamiento

o Habilitación / deshabilitación del módulo

o Habilitación de la función “loopback”

o Habilitación de las patillas de control de flujo.

o Selección del baudrate.

o Selecciona el número de bits por dato, paridad y bits de

parada.

- UxSTA: registro de control y estado de la UART.

o Habilitación, deshabilitación y modo de interrupciones de

envío y recepción.

- UxRXREG: registro que almacena el dato recibido.

- UxTXREG: registro que almacena el dato que va a ser transmitido.

- UxBRG: registro que almacena el baudrate de la comunicación.

Tabla 8. Registro UxMODE. Fuente: registro 17-1 de DS70188D

- Bit 15 UARTEN: Bit de habilitación del módulo (1: habilitado; 0:

deshabilitado).

- Bit 11 RTSMD: selección de modo para la patilla UxRTS (1: modo simplex; 0:

modo control de flujo).



- Bit 9-8 UEN<1:0>: modo de funcionamiento de las patillas asociadas al

módulo.

- Bit 6 LPBACK: Habilitación de modo loopback (1: activo; 0: inactivo).

- Bit 2-1 PDSEL <1:0>: selección formato de datos y paridad.

Tabla 9. Registro UxSTA de control y estado de UART . Fuente: registro 20-2 de DS70291E

- Bit 15-13 UTXISEL <1:0>: selección de modos de interrupción en transmisión

- Bit 10 UTXEN: habilitación de la transmisión. NUNCA ANTES DE

HABILITAR UARTEN. (1: transmisión habilitada; 0: inactivo, con patillas bajo

control del puerto).

- Bit 9 UTXBF: Bit monitor de estado “buffer de transmisión completo”. Es de

sólo lectura. (1: buffer lleno).

11 = No usado. 10 = Interrupción al transferirse carácter al registro intermedio, y quedar el buffer vacío. 01 = Interrupción al transmitirse el último caracter. 00 = Interrupción al transferirse carácter al registro intermedio, quedando al menos

11 = Datos de 9 bit sin paridad. 10 = Datos de 8 bit paridad par. 01 = Datos de 8 bit paridad impar. 00 = Datos de 8 bit sin paridad.

11 = Sólo UxCTS deshabilitado, BCLKx habilitado 10 = Todas las señales habilitadas. 01 = Sólo UxCTS deshabilitado, UxRTS habilitado 00 = Hablitadas UxRX y UxTXSeñales de control de flujo deshabilitadas.



- Bit 8 TMRT: Bit monitor de estado “registro de desplazamiento para

transmisión vacío”.

- Bit 7-6 URXISEL <1:0>: selección de modo de interrupción en recepción:

- Bit 0 URXDA: bit monitor del estado “espacio disponible en el buffer para

recibir un dato”, (1: el buffer tiene datos pero uno más puede ser recibido; 0: el

buffer de recepción está vacío).

5.3.10.2. Configuración del módulo para la aplicación

Es necesario determinar el valor que cargar en el registro UxBRG para la

generación del baud rate adecuado. No se tienen exigencias de comunicación

críticas, por lo que para esta aplicación se configurará el puerto UART en

condiciones habituales:

- Baud rate= 9600 baudios.

- Datos de 8 bits. Sin paridad

- Un bit de parada.

Se utiliza a ecuación 17-1 de DS70188D para el cálculo de UxBRG:

25116

9600/40000000 UxBRG

Ecuación 7. Cálculo del generador de tasa de bits

Se utilizarán como referencia los ejemplos de código 17-2 y 17-3 de

DS70188D.

11 = Interrupción ante recepción que deja el buffer de recepción lleno (tiene 4 caracteres). 10 = Interrupción ante recepción que deja el buffer con 3 caracteres. 0x = Interrupción cualquier carácter es recibido y transferido desde UxRSR al buffer.

1 = Registro de desplazamiento y buffer de transmisión vacíos (la última transmisión se completó). 0 = Registro de desplazamiento para transmisión no-vacío. Una transmisión está en curso o parada.



5.3.11. Controlador de interrupciones

5.3.11.1. Descripción del módulo

El mecanismo de las interrupciones hace posible la coordinación de tareas

hardware llevadas a cabo por periféricos, y tareas software en ejecución dentro de

la CPU, permitiendo la atención a eventos de forma síncrona.

El controlador de interrupciones reduce las numerosas señales de solicitud de

interrupción de los distintos periféricos a una única señal de interrupción de la CPU.

El controlador de interrupciones tiene las siguientes características:

- Hasta ocho excepciones del procesador y traps software.

- Ocho niveles de prioridad seleccionables por el usuario.

- Tabla de vectores de interrupción (IVT) con hasta 118

vectores.

- Un único vector para cada fuente de interrupción o excepción.

- Prioridad fija dentro de cada nivel de prioridad seleccionado

por el usuario.

- Tabla alternativa de vectores de interrupción, usada para

depuración.

- Latencia fija tanto para entrada como para salida de una

interrupción.

Tabla de vectores de interrupción

La tabla de vectores de interrupción reside en la memoria de programa,

comenzando en la posición 000004h. Contiene 126 vectores, siendo 8 para traps,

no enmascarables, y 118 para las distintas fuentes de interrupción.

Cada vector está formado por 24 bits, en los que se almacena la dirección de

programa donde comienza la rutina de atención a la interrupción asociada (ISR).

Los vectores son priorizados en base a su prioridad natural, que se refleja en

su posición en la tabla: direcciones más bajas tienen más prioridad.



Es conveniente que las posiciones no utilizadas de las tablas lleven a una

rutina por defecto, en general con una orden de RESET.

Ilustración 65. Tabla de vectores de interrupción. Fuente: figura 7-1 de DS70291E

Tabla alternativa de vectores:

El acceso a dicha tabla, que se encuentra contigua en la memoria de

programa, es regulado por el bit de control ALTIVT (INTCON2<15>).

Esto es de utilidad en depuración: se pueden implementar rutinas distintas que

las de ejecución (por ejemplo, simple monitoreo en vez de ejecución de acciones).



Si no se requiere su uso, conviene cargar las mismas rutinas para la tabla

alternativa que para la principal.

Registros de control y estado de las interrupciones

Se utilizan un total de 30 registros relativos al controlador de interrupciones:

- INTCON1, INTCON2: Gobiernan las funciones globales de

control de interrupción.

- IFSx: Contienen todas las banderas de solicitud de

interrupción. Cada fuente de interrupción tiene un bit de

estado, que es activado por el periférico correspondiente o

anulado por software.

- IECx: Contienen los bits de habilitación de interrupciones

- IPCx: Contienen la designación de nivel de prioridad para

cada fuente de interrupción.(entre 8 posibles niveles).

- INTTREG: Contiene el número de vector de interrupción que

está siendo atendido (VECNUM<6:0>) y el nivel de prioridad

actual de la CPU (ILR<3:0>), que es el de la interrupción en

curso.

- Aunque no son parte específica del hardware de control de

interrupciones, hay además dos registros que determinan el

comportamiento de las interrupciones:

- SR: Registro de estado de la CPU, contiene los bits IPL<2:0>

que indican el nivel de prioridad actual de la CPU. Este

registro puede ser escrito para cambiar dicho nivel.

- CORCON: Contiene el bit IPL <3> que junto a los IPL <2:0>

determina el nivel de prioridad de la CPU, pero es un bit de

sólo lectura, de modo que las trap no sean enmascarables.



5.3.11.2. Configuración de las interrupciones

Una interrupción se ejecuta si se cumplen las siguientes 3 condiciones:

1. Se encuentra habilitada su fuente.

2. Se produce la circunstancia de activación de su bandera.

3. El nivel de prioridad de la CPU es igual o menor al de la fuente de

interrupción

En ese caso el controlador de interrupciones carga en el contador de programa

la dirección donde se encuentra la rutina de atención de la interrupción. Dicha

dirección está almacenada en el vector de interrupción correspondiente.

Por tanto, en la planificación de estados del sistema que se desea controlar,

debe asociarse cada estado a un nivel de prioridad de la CPU, de modo que sólo se

ejecuten aquellas interrupciones más prioritarias.

Los pasos que deben seguirse para cada fuente de interrupción son:

1. Crear la rutina de atención a la interrupción.

Esto depende fuertemente del lenguaje y compilador utilizado.

Para el compilador C30, se trata de una función etiquetada con el atributo de

interrupción -interrupt-, de modo que el compilador carga la dirección de esta

función en el vector correspondiente de la tabla de vectores de interrupción.

Cuando se produce la interrupción, el controlador de interrupciones carga en el

registro INTTREG el número de vector de interrupción para la solicitud entrante,

VECNUM <6:0> y su nivel de prioridad: ILR<3:0>.

Dentro de la rutina, como mínimo debe restablecerse el bit testigo de

interrupción, en el registro IFSx.

void __attribute__((interrupt, no_auto_psv)) _QEI1Interrupt(void) IFS3bits.QEI1IF=0; // Restablece el flag



2. Indicar el nivel de prioridad que le asignamos, escribiendo el registro

IPCx. Por defecto, ante un reset, las interrupciones de usuario se

cargan con nivel 4.

3. Restablecer el bit testigo correspondiente a la interrupción: IFSx.

4. Habilitar la interrupción en el registro IECx.

Con carácter general, si se desean deshabilitar las interrupciones anidadas, se

pone a uno el bit NSTDIS (INTCON<15>).

Tabla 10. Interrupciones utilizadas en las aplicaciones de control del robot

Num. Vector

Dirección IVT Dirección AIVT Fuente de Interrupción

1 0x000006 0x000106 Fallo del oscilador 4 0x00000C 0x000106 Error matemático 11 0x00001A 0x00011A T1- Timer 1 15 0x000022 0x000122 T2- Timer 2 16 0x000024 0x000124 T3- Timer 3 19 0x00002A 0x00012A U1RX- UART1 Receptor 20 0x00002C 0x00012C U1TX- UART2 Transmisor 27 0x00003A 0x00013A Int. Notificación de cambio

66 0x000088 0x000188 QEI1- Position Counter

Compare

83 0x0000AA 0x0001AA QEI2- Position Counter

Compare

5.4. Programa de control del robot Es el responsable de llevar a cabo de forma autónoma las tareas asignadas,

disponiendo para ello de los recursos físicos de la máquina.

El programa se estructura en rutinas y funciones que desempeñan labores

específicas.



5.4.1. Rutina principal

La rutina principal se ocupa, en primer lugar, de ejecutar las funciones de

configuración de los periféricos y habilita las comunicaciones con el exterior.

Crea las estructuras de datos sobre las que trabajarán las demás rutinas e

inicializa las variables del sistema.

A continuación entra en un bucle infinito que se ocupa de secuenciar la

ejecución de las órdenes de movimiento. Mientras no haya órdenes en la cola o

mientras estas se ejecutan, la rutina principal permanece en estados de espera. Si

está activado el registro de datos, al término de cada orden de movimiento envía

dichos datos por el puerto de comunicaciones en formato CSV (valores separados

por coma).



Ilustración 66. Diagrama de flujo rutina principal



5.4.2. Rutina de recepción y administración de comandos recibidos

Esta rutina se ejecuta de forma asíncrona como interrupción por recepción de

caracteres por el puerto UART.

La rutina tiene que componer los mensajes recibidos a partir de sus caracteres

sueltos. Una vez recibido un mensaje coherente, procede a su decodificación en los

paquetes de datos que lo forma.



Ilustración 67. Rutina de interrupción por recepción de caracteres en UART1



Los mensajes tienen una estructura definida, basada en el modelo GDB [29]:

- comienzan por el carácter ‘$’

- un comando especifica el tipo de mensaje del que se trata

- opcionalmente, dentro de un par de corchetes, y separados por coma,

se tienen campos correspondientes a valores de parámetros o variables

a los que el comando hace referencia.

- el mensaje termina con el carácter ‘#’.

Los tipos de comandos que se han habilitado son:

5.4.2.1. Comando de orden de movimiento: MOV.

Va seguido de combinaciones del valor de algunas variables a partir de las que

puede componerse cualquier trayectoria simple. Las opciones disponibles son:

- MOV[V,Fipunto,S,x,x]

- MOV[0,Fipunto,0,Fi,x]

Tabla 11. Comando orden de movimiento

Campo Tipo Unidad Min MaxV int mm/s -1500 1500Fipunto int grados/s -360 360S int mm -9999 9999Fi int grados -9999 9999t

COMANDO ORDEN DE MOVIMIENTO

$MOV[V,Fipunto,S,Fi,t]#

No implementado

La gestión de este tipo de orden continúa componiendo una orden de

movimiento y cargándola en la cola FIFO de órdenes.

5.4.2.2. Comando para establecer el valor de variables o parámetros del sistema: SET

Este va seguido de corchetes, en cuyo interior se introduce en primer lugar una

cadena de caracteres con el nombre de la variable, seguido por el valor. Las

opciones soportadas se muestran en la Tabla 12. Comando anotar variables



Tabla 12. Comando anotar variables

Var Tipo Unidad Min MaxKp_i float - 0 9,99Ki_i float - 0 9,99Kd_i float - 0 9,99Kp_d float - 0 9,99Ki_d float - 0 9,99Kd_d float - 0 9,99A_mmps float mm/s^2 -2000 2000

COMANDO ANOTAR VARIABLES

$SET[Var,Valor]#

5.4.2.3. Comando para extraer el valor de variabes o parámetros: ASK

El comando va seguido del nombre de la variable, entre corchetes. Son

soportadas las mismas variables que para SET.

Tabla 13. Comando extraer variables

COMANDO EXTRAER VARIABLES

$ASK[Var]#

Mismas opciones que para anotar variables

5.4.2.4. Comandos para establecer modos de funcionamiento:

Mediante estos comandos se habilitan o deshabilitan funcionalidades del

programa, tales como el control en lazo cerrado de velocidad o el registro y envío

de las variables cinemáticas muestreadas.

Tabla 14. Comandos de modo

COMANDOS DE MODO

$CTRL ON# Activa la rutina de control

Desactiva la rutina de control

Activa el registro de datos

Desactiva el registro de datos

Muestra mensaje presentación

$CTRL OFF#

$LOG ON#

$LOG OFF#

$WHO#



5.4.2.5. Comandos para componer trayectorias básicas:

El comando SQR compone una trayectoria cuadrada a partir de órdenes de

giro y desplazamiento recto. Esta trayectoria es útil para calibrar los

desplazamientos del robot.

El comando CIR compone una trayectoria en forma de círculo, que resulta de

utilidad entre otros para calibrar el factor de deslizamiento de las ruedas.

Tabla 15. Comandos trayectoria básica

Campo Tipo Unidad Min MaxVsqr int mm/s -1500 1500Fipunto_sqr int grados/s -360 360lado int mm -9999 9999

Campo Tipo Unidad Min MaxVcir int mm/s -1500 1500radio_cir int mm -9999 9999

COMANDOS TRAYECTORIA BÁSICA

$SQR[Vsqr,Fipunto_sqr,lado]#

$CIR[Vcir,radio_cir]#

Al término de esta rutina el flujo del programa vuelve a la rutina principal.

5.4.3. Rutinas de ejecución de órdenes de movimiento. Control de posición y velocidad.

Este conjunto de funciones realizan todas las etapas necesarias para convertir

una orden de movimiento en una trayectoria real del robot.

El proceso comienza con la llamada desde la función main a la función

ejecutar_ORDEN_MOV. Se extrae de la cola de órdenes la siguiente orden de

movimiento almacenada.

Esta orden debe ser interpretada para caracterizar el tipo de movimiento al que

corresponde (curvo general o de spin).

La planificación del movimiento para cada lado de motores (izquierdo y

derecho) consiste en general en dividir el recorrido en tres tramos correspondientes

a:



- Tramo 1: aceleración constante hasta alcanzar la velocidad consignada.

- Tramo 2: mantenimiento de la velocidad de consigna.

- Tramo 3: deceleración constante hasta la total parada en el instante en

que se ha recorrido la longitud total de consigna.

Esto corresponde a un perfil de velocidad de consigna con forma de trapecio.

Ilustración 68. Segmentos del perfil de velocidades en el control de posición.

Si la longitud del recorrido no fuese suficiente como para que se alcance la

velocidad de consigna antes de la mitad del recorrido, el perfil de velocidades

planificado sería triangular.

Una vez que se ha planificado el movimiento, comienza su ejecución y se

habilitan dos fuentes de interrupción: una interrupción periódica cada período de

muestreo, y la interrupción por conteo de pulsos de encóder:

- La rutina de interrupción periódica (generada por el desbordamiento del

Timer 1) es la responsable de crear el perfil de velocidad base, según el

tramo de trayectoria de velocidad en que se encuentre la rueda, de

realizar los cálculos cinemáticos y ejecutar la rutina de control de

velocidad, para obtener el valor de accionamiento de los motores y

cargarlo en el registro que gobierna el tiempo activo de PWM.



Ilustración 69. Rutina de interrupción periódica por Timer 1



- La rutina de interrupción por recorrido es la responsable de secuenciar

los tramos del perfil de velocidades, y de determinar el fin del

movimiento sin más retraso que la latencia en la atención de la propia

interrupción.

Ilustración 70. Rutina de interrupción QEI por pulsos de encóder

Rutina de control de velocidad.

Uno de los objetivos que se persiguen en el diseño de la plataforma móvil es

que sea capaz de realizar con fidelidad las órdenes de movimiento que recibe.

Las órdenes de velocidad lineal y angular del robot son descompuestas en

órdenes de velocidad de giro para los motores. El seguimiento instantáneo de

estas referencias afecta no sólo a las verdaderas velocidades lineal y angular del

robot, sino lo que es más importante, a la propia trayectoria que describe.



Por eso resulta de gran importancia que el desempeño sea bueno.

Los resultados experimentales demuestran que ambos lados de ruedas no

siguen del mismo modo una misma consigna de velocidad, como corresponde a la

naturaleza no idéntica de los motores, a pequeños errores en la construcción de la

mecánica, y otras razones. Esto podría compensarse en lazo abierto mediante

calibración inicial, pero no los cambios que en la salida del sistema puedan

ocasionar variaciones de los ajustes, de la carga, así como otras perturbaciones

posibles.

5.4.3.1. Algoritmo de control de velocidad

Para mejorar el desempeño en el movimiento se implementa un algoritmo de

control de velocidad en lazo cerrado PID a cada bloque de ruedas (izquierdo y

derecho). Este algoritmo es el más utilizado porque aunque no siempre sea el

óptimo, resulta sencillo de comprender y ajustar.

Ilustración 71. Implementación del algoritmo PID.

El código del algoritmo puede implementarse directamente en lenguaje C,

utilizando aritmética de coma flotante con las funciones de C estándar.



Sin embargo, la librería para dsp de Microchip proporciona funciones para

implementar este algoritmo de control, escritas en lenguaje compilador, y que hacen

uso extensivo de las instrucciones para DSP del microcontrolador, siendo mucho

más eficientes en tiempo de ejecución. Estas funciones se proporcionan en el

archivo pid.s y son llamadas desde el código en C. Para su utilización deben

incluirse en el proyecto software los siguientes archivos de librería proporcionados

por Microchip:

- libc-coff.a

- libdsp-coff.a

- libq-coff.a

- libq-dsp-coff.a

Dichas funciones utilizan aritmética de coma fija en formato Q15 (Q1.15), en el

que el rango de las variables es [-1, (2-15-1)], por lo que las variables enteras o de

coma flotante de 16 bits deben escalarse a un valor dentro de ese rango

previamente a su conversión a la representación Q15.

Ilustración 72. Representación de 16 bits en coma fija Q15

Las funciones proporcionadas en la librería se describen a continuación:



Las funciones utilizan la estructura de datos definida en dsp.h como tPID . En

esta estructura se pasan por referencia (mediante punteros) las variables básicas

para el algoritmo.

Microchip proporciona código de ejemplo para estas funciones en el

documento CE019 [30].

Las variables cinemáticas de los bloques izquierdo y derecho calculadas por el

programa del robot se encuentran agrupadas en estructuras de datos definidas

como :

typedef struct fractional * abcCoefficients ; /* Puntero a los coeficientes que se encuentran en el espacio de memoria X, estos coeficientes se derivan de los valores de las ganancias PID : Kp , Ki y Kd */ fractional * controlHistory ; /* Puntero a las 3 ultimas muestras de velocidad almacenadas en el espacio de memoria Y, la primera es la mas reciente; No, historial de error actual (duplicado) y anterior*/ fractional controlOutput ; /* Salida del regulador PID */ fractional measuredOutput ; /* Valor medido de la respuesta del sistema */ fractional controlReference ; /* Referencia del sistema */ tPID ;

extern void PIDCoeffCalc ( fractional * kCoeffs , tPID *controller ); /* Deriva los coeficientes ABC usando las ganacias del PID: Kp , Ki y Kd. Necesita un array que contenga los valores Kp , Ki y Kd en secuencia y el puntero a la estructura de datos tPID */ extern void PIDInit ( tPID * controller ); /* Limpia las variables de estado del PID y la salida de las muestras . Necesita el puntero a la estructura de datos tPID */ extern fractional * PID ( tPID * controller ); /* Calcula la accion de control PID . Necesita el puntero a la estructura de datos tPID */



Las variables cinemáticas del robot se almacenan en la estructura definida

como:

Elección del período de muestreo

Para el control en tiempo discreto debe elegirse un período de muestreo que,

según la regla de Nyquist debe corresponder a una frecuencia al menos doble de la

más rápida del sistema que se desea controlar. En la práctica, se suele tomae tal

que el transitorio tenga entre 4 y 8 puntos muestreados.

Para un motor con reductora del tipo a los utilizados, el tiempo característico

del polo rápido está en algunos milisegundos, mientras el del polo dominante suele

estar en las decenas o cientos de milisegundos

Tener en cuenta al polo rápido exigiría que el bucle de control tenga un período

de muestreo del orden de los milisegundos. El microcontrolador tiene una velocidad

typedef struct float V; float V_1; float Fipunto; float A; cinematica_robot;

typedef struct

int posicion; //Cuentas de QEI absolutas

int posicion_1; //Cuentas anterior

float S; //Recorrido mm

float V; //Velocidad mmps

float V_1; //Velocidad anterior

float A; //Aceleracion

cinematica;



de procesamiento suficiente para poder llevarlo a cabo. Sin embargo, la resolución

del encóder es baja, de sólo 64 cuentas por vuelta del motor. Algunos datos

relativos al orden de magnitud de la resolución del encóder:

- 64 cuentas por revolución del motor

- 1920 cuentas por revolución de la rueda

- 0,1875 º de rueda, equivalen a una distancia lineal de 0,1472mm

Como el cálculo de la velocidad se realiza por diferencia en el contador de

pulsos en dos períodos sucesivos, la resolución en la velocidad calculada depende

de las cuentas por período.

Se realizan algunas valoraciones.

Para un período de un milisegundo, se tiene:

- A máxima velocidad (350 rpm de reductora, 10500 rpm eje motor), esto

son 11,2 cuentas ( redondeo por defecto a 11 cuentas). Se percibirían

sólo 11 peldaños de velocidad, lo que da una resolución muy pequeña,

y errores relativos de truncado muy importantes.

- A velocidad de funcionamiento del 50% de la nominal, se tendrían 5,6

cuentas, truncadas a 5.

Luego con un período de muestreo de un milisegundo, la resolución resulta

insuficiente.

Por eso aunque se corra el riesgo de no controlar la dinámica rápida del motor,

interesa imponer un tiempo de muestreo superior que permita más resolución en la

medida de la velocidad.

Se plantea un nuevo tiempo de muestreo de 25 milisegundos. Para este

período se tendrá:

- A máxima velocidad del motor (10500 rpm), 280 cuentas efectivas.

- A velocidad del motor del 50% del máximo, 140 cuentas efectivas.

- A una tensión del 10% de la máxima, por debajo de la cual el sistema

no arranca, 28 cuentas.

Por tanto parece razonable para el objeto que se persigue.

Esta hipótesis se valida experimentalmente, como se describe en el Capítulo 6.



6. Resultados Experimentales En este capítulo se exponen los resultados del proceso de diseño mecánico,

electrónico y software, así como las pruebas de funcionamiento y algoritmos de

control que se han implementado para mejorar el desempeño del robot.

6.1. Robot real vs Robot 3D Las ilustraciones siguientes permiten comparar los resultados con los diseños.

Ilustración 73. Vista lateral del modelo 3D del robot

Ilustración 74. Vista lateral del robot



Ilustración 75. Vista isométrica del robot

Ilustración 76. Imagen isométrica del modelo



Ilustración 77. Vista en planta del modelo 3D del robot.

Ilustración 78. Vista en planta del robot.



6.2. Validación del diseño electrónico y configuración de periféricos.

6.2.1. Pruebas en placa de prototipos

Los sistemas eléctricos y electrónicos del robot fueron diseñados en base a la

información proporcionada en las hojas de características de los distintos

componentes.

Tanto a nivel de placa electrónica como de interacción entre sistemas es

conveniente validar los diseños asegurando el correcto funcionamiento, en una

etapa previa a la fabricación de las placas finales, a tiempo de realizar

modificaciones o ajustes que después serían más costosos.

Para efectuar estos ensayos se recurre a la utilización de un equipo de

prototipado “universal trainer” de Microsistems Engineering sobre el que se

construyen los circuitos con los componentes que se utilizarán en la placa definitiva.

Se pretende:

- Configurar el oscilador del microcontrolador.

- Configurar los puertos y comprobar el funcionamiento de las salidas

en dos condiciones: funcionando como salida digital y como open

drain.

- Evaluar el funcionamiento de los periféricos PWM y QEI de control

de motores.

- Familiarizarse con las herramientas software, crear un proyecto,

compilarlo y grabarlo mediante el dispositivo Pickit3.



Ilustración 79. Montaje de pruebas sobre maletín "universal trainer"

Problemas con las salidas PWM

En el trabajo realizado con el los módulos PWM del microcontrolador se

presenta una anomalía destacable: a pesar de que en la fase de simulación todo

funciona correctamente, en la aplicación real los pines configurados para salidas de

PWM, no responden. Tampoco algunos de los pines compartidos con PWM que

han sido configurados como entrada/salida del puerto.: RB8, RB9, RB10, RB11.

Tras consultar la situación en medios especializados sin éxito, se comprueba

que lo que tienen en común dichos pines es que forman parte de un periférico: el

JTAG (utilizado para depuración y test de circuitos), que es prioritario sobre el PWM

(la prioridad puede comprobarse de izquierda a derecha en el esquema de pines).

La solución pasa por deshabilitar este periférico en segundo plano desde la palabra

de configuración del micro.

Interacción entre los sistemas

Se modifica el montaje hardware para conectar con la etapa de potencia y

probar el funcionamiento completo: dsPIC + etapa de potencia + motores.

La señal PWM de salida de la etapa, en carga con el motor, resulta cuadrada

casi perfecta, con perturbaciones transitorias en los flancos de subida/bajada.



Ilustración 80. Pulsos PWM para DC= 50% y distintos períodos

Se prueba el modo más adecuado de uso de las salidas PWM para conectar

con la etapa de potencia:

- Como salida digital 0V-3V: a pesar de que la electrónica de la etapa de

potencia utiliza nivel lógico alto a 5V, admite los 3V que proporciona el

microcontrolador como salida digital a nivel alto del módulo PWM.:

- Como salida en drenador abierto: Para conseguir niveles de tensión de

5V se plantea el uso de las salidas en modo open-drain conectando

resistencias pull-up. En resultado no es satisfactorio para 10 Kohm

pero sí para 5K, obteniéndose 3 voltios en la entrada de la etapa de

potencia. El resultado óptimo se consigue para una resistencia

equivalente de pull-up de 3,3K, alcanzando 4V. Tampoco debe

utilizarse una resistencia menor de 1,75 KOhmn pues a nivel bajo la

patilla tendría que absorber más de los 4mA admitidos.

Pruebas con el módulo QEI

Se configura uno de los dos módulos para la interacción con encóder del robot.

La aplicación MPLAB no proporciona soporte para la simulación de este

módulo, por lo que se hace directamente el montaje de los circuitos.

La labor del módulo consiste básicamente en contar los flancos que recibe de

las señales QEIxA y QEIxB generadas al girar el disco magnético del encóder.

Gracias a un la lógica interna del módulo es capaz de determinar el sentido de giro,

y con él, añadir o restar cuentas del registro QEIxCON.



Este registro puede ser leído y escrito, por lo que el programa de prueba

trasladará el valor de uno de los bits del registro al puerto, monitorizándolo con un

led.

Se activan los motores y se aplican distintos valores de velocidad,

comprobando que la frecuencia de parpadeo del led responde a las variaciones de

velocidad de las ruedas.

En cuanto al sentido de giro, se saca por una patilla el bit de sentido del

módulo QEI, comprobando que efectivamente es capaz de seguir el sentido real.

Ilustración 81. Captura del video realizado con la prueba de módulos PWM y QEI

6.2.2. Prueba de los sistemas del robot.

Las pruebas sobre placa de prototipos sirvieron para validar los circuitos y la

configuración software de los periféricos del microcontrolador.

Al pasarse a una placa de circuito impreso montada en la aplicación real,

deben realizarse comprobaciones encaminados a establecer los efectos reales de

los ajustes software: sentido de giro de los motores, coherencia con las lecturas de

los encóder, funcionamiento de las comunicaciones, así como desempeño global

del sistema.



Una vez que los aspectos físicos del robot están conseguidos, comienza la

tarea de desarrollar la aplicación de control del robot, que será la encargada de

dotarlo de las funcionalidades deseadas.

Ilustración 82. Placa electrónica de control de tracción

6.3. Pruebas de movimiento. Ajuste de los algoritmos de control de posición y velocidad

6.3.1. Respuesta en lazo abierto. Caracterización del sistema

Las primeras pruebas de movimiento del robot consisten en ordenar un

desplazamiento con una acción de control fija sobre los motores, que cesa en el

momento en que la interrupción que gestiona los pulsos de encóder indica que se

ha alcanzado la distancia deseada.



En este instante, se da la orden de dejar de alimentar los motores.

Se observa que la respuesta ante una entrada escalón es enérgica,

alcanzando una velocidad aparentemente estable en fracciones de segundo.

En los momentos siguientes a que los motores dejen de ser alimentados, la

inercia del móvil lo mantiene en movimiento después de haber alcanzado la

referencia de posición, por lo que se incurre en un sobrepaso que es tanto mayor

cuanto mayor fuera la velocidad del robot.

En la figura siguiente se aprecia el montaje para la prueba y el sobrepaso de

posición, de unos 20 cm sobre una orden de un metro al 50% de velocidad

máxima.

Ilustración 83. Posición final de robot. Distancia: 1m. Velocidad 50%

Frenado regenerativo y con reverso de corriente

La primera mejora consiste en introducir una rutina de frenado al final del

movimiento. La rutina configura las conexiones de la etapa de potencia de modo

que al frenar, los bornes de los motores quedan en cortocircuito entre ellos. Los

motores se comportan como generadores suministrando corriente y por tanto

aparece un par resistente que se opone al movimiento.



Se comprueba que el sobrepaso se hace pequeño, pero no nulo.

El inconveniente del frenado regenerativo es que es menor cuanto menor va

siendo la velocidad. Cuando el motor está próximo a parar su acción es pequeña.

Una vuelta de tuerca consiste en un frenado activo: la rutina de frenado hace

que los motores sean alimentados en reverso, a una tensión pequeña, pues es una

estrategia agresiva.

El resultado es un frenado casi inmediato del robot. Las ruedas literalmente se

bloquean, y el sobrepaso se hace imperceptible, pero la brusquedad produce

derrape en muchos casos.

Ilustración 84. Posición final. Distancia 1m.V: 50% frenado activo

En los casos descritos, se pone de manifiesto que debe mejorarse el

desempeño del sistema, y para ello es necesario caracterizarlo.

Los movimientos del robot son el resultado de la acción combinada de los

motores a su izquierda y derecha. Se pretende en primer lugar conocer su

respuesta ante entradas conocidas, para que el programa de control sea capaz de

realizar el cálculo inverso al recibir órdenes de movimiento: qué acción de control

hay que aplicar para conseguir un efecto deseado.

Se diseña una batería de pruebas cuya mecánica es la siguiente:

- En pruebas sucesivas se dan valores crecientes a la excitación de los

motores, igual para izquierda y derecha.



- Se carga una consigna de distancia, igual para el lado izquierdo que

para el derecho. Esta consigna es tal que permita razonablemente

alcanzar una velocidad estacionaria. Al ser alcanzada provoca

interrupción, y deja de alimentarse el motor correspondiente.

- Al término de un tiempo prefijado, siempre mayor que el del

movimiento, los datos cinemáticos que han sido registrados

periódicamente (cada 25ms) son enviados al hiperterminal, en formato

CSV.

- Se repite la prueba, primero con las ruedas girando al aire y luego en

carga (robot en movimiento). En el primer caso, la respuesta observada

es sólo la del propio motor, las transmisiones y las ruedas, mientras en

el segundo caso entra en juego la inercia del móvil y la interacción de

los bloques mecánicos izquierdo y derecho, que se encuentran

acoplados.

- Por último, se representa gráficamente la respuesta temporal y se

procesa la información obtenida

Se muestran a continuación algunos resultados representativos:

6.3.1.1. Respuesta escalón con mecánicas en vacío

Respuesta lazo abierto. DC= 300 (15% Dcmax). Distancia = 500mm. Libre

-20

0

20

40

60

80

100

120

140

160

012

525

037

550

062

575

087

510

0011

2512

5013

7515

0016

2517

5018

7520

0021

2522

5023

7525

0026

2527

5028

7530

0031

2532

5033

7535

0036

2537

5038

7540

0041

2542

5043

7545

0046

2547

5048

7550

00

tiempo (ms)

Vel

oci

dad

(m

m/s

)

VI_mmps

VD_mmps

Ilustración 85. Respuesta en lazo abierto a escalón del 15% DCmax. Libre



Respuesta lazo abierto. DC=500 (25% DCmax). Distancia= 500mm. Libre

0

50

100

150

200

250

300

350

400

0

150

300

450

600

750

900

1050

1200

1350

1500

1650

1800

1950

2100

2250

2400

2550

2700

2850

3000

3150

3300

3450

3600

tiempo (ms)

Vel

oci

dad

(m

m/s

)

VI mmps

VD mmps


Respuesta lazo abierto. DC= 750 (38% DCmax). Libre

0

100

200

300

400

500

600

700

0

125

250

375

500

625

750

875

1000

1125

1250

1375

1500

1625

1750

1875

2000

2125

2250

2375

tiempo (ms)

Vel

oci

dad

(m

m/s

)

VI_mmps

VD mmp




Respuesta lazo abierto DC=1000 (50% Dcmax). Distancia= 2000mm. Libre

-100

0

100

200

300

400

500

600

700

800

900

0

125

250

375

500

625

750

875

1000

1125

1250

1375

1500

1625

1750

1875

2000

2125

2250

2375

2500

2625

2750

2875

3000

3125

3250

tiempo (ms)

Vel

oci

dad

(m

m/s

)

VI mmps

VDmmps


Respuesta lazo abierto. DC= 1500 (75% Dcmax). Distancia= 2000 mm. Libre

-200

0

200

400

600

800

1000

1200

1400

0 75 150

225

300

375

450

525

600

675

750

825

900

975

1050

1125

1200

1275

1350

1425

1500

1575

1650

1725

1800

1875

1950

2025

2100

2175

2250

2325

2400

tiempo (ms)

Vel

oci

dad

(m

m/s

)

VI_mmps

VD_mmps

Ilustración 89. Respuesta en lazao abierto a escalón del 75% DCmax. Libre



Respuesta escalón. DC=2000 (100% DCmax). Distancia 2500 mm. Libre

0

200

400

600

800

1000

1200

1400

1600

1800

0 50 100

150

200

250

300

350

400

450

500

550

600

650

700

750

800

850

900

950

1000

1050

1100

1150

1200

1250

1300

1350

1400

1450

1500

1550

1600

1650

1700

1750

1800

1850

1900

1950

2000

tiempo (ms)

Vel

oci

dad

(m

m/s

)

VI_mmps

VD_mmps


6.3.1.2. Respuesta escalón con mecánicas en carga

Respuesta lazo abierto. DC=300 (15% DCmax). Distancia 500mm. Carga

0

20

40

60

80

100

120

140

012

525

037

550

062

575

087

510

0011

2512

5013

7515

0016

2517

5018

7520

0021

2522

5023

7525

0026

2527

5028

7530

0031

2532

5033

7535

0036

2537

5038

7540

0041

2542

5043

7545

0046

2547

5048

7550

00

tiempo (ms)

Vel

oci

dad

(m

m/s

)

VD_mmps

VI_mmps

Ilustración 91. Respuesta en lazo abierto a escalón del 15% DCmax. En carga



Respuesta en lazo abierto DC= 500 (25% Dcmax). Distancia=500. Carga

0

50

100

150

200

250

300

350

012

525

037

550

062

575

087

510

0011

2512

5013

7515

0016

2517

5018

7520

0021

2522

5023

7525

0026

2527

5028

7530

0031

2532

5033

7535

0036

2537

5038

7540

0041

2542

5043

7545

0046

2547

5048

7550

00

tiempo (ms)

Vel

oci

dad

(m

m/s

)

VI mmps

VD mmps


Respuesta lazo abierto. DC=750 (38% DCmax). Distancia= 1000mm. Carga

-100

0

100

200

300

400

500

600

0

100

200

300

400

500

600

700

800

900

1000

1100

1200

1300

1400

1500

1600

1700

1800

1900

2000

2100

2200

2300

2400

2500

2600

2700

2800

2900

3000

tiempo (ms)

Velo

cidad

(mm

/s)

VI_mmps

VD_mmps


Respuesta lazo abierto. DC=1000 (50% Dcmax). Distancia = 2000 mm. Carga

-100

0

100

200

300

400

500

600

700

800

010

020

030

040

050

060

070

080

090

010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

0030

0031

0032

0033

0034

0035

0036

0037

0038

00

tiempo (ms)

Vel

oci

dad

mm

/s

VI_mmps

VD_mmps




Respuesta lazo abierto. DC= 1500 (75% Dcmax). Distancia=2000mm. Carga

0

200

400

600

800

1000

1200

1400

0 75 175

275

375

475

575

675

775

875

975

1075

1175

1275

1375

1475

1575

1675

1775

1875

1975

2075

2175

2275

2375

2475

2575

2675

2775

2875

tiempo (ms)

Vel

oci

dad

(m

m/s

)

VI_mmps

VD_mmps


Respuesta lazo abierto. DC= 2000 (100% Dcmax). Distancia= 2500mm. En carga

-200

0

200

400

600

800

1000

1200

1400

1600

1800

0

125

250

375

500

625

750

875

1000

1125

1250

1375

1500

1625

1750

1875

2000

2125

tiempo (ms)

Vel

oci

dad

(m

m/s

)

VI mmps

VD mmps

Ilustración 96. Respuesta en lazo abierto a escalón del 100% de DCmax. En carga

6.3.1.3. Conclusiones y caracterización en lazo abierto

El tratamiento de la información recogida consiste en primer lugar en valorar el

tipo de respuesta transitoria y estacionaria de los distintos sistemas ( motores con

ruedas al aire / motores en carga).

La respuesta transitoria de las mecánicas en vacío es limpia y corresponde a

un sistema rápido, de segundo orden o superior y sobreamortiguado, pues no

presenta sobrepaso. La duración del transitorio se prolonga por más de 8 períodos

de muestreo, por lo que la validez del período de muestreo de 25ms queda

demostrada.



Con la mecánica en carga la señal se hace mucho más ruidosa y resulta difícil

distinguir un perfil claro.

En cuanto a la respuesta estacionaria, se comprueba que en vacío, la

velocidad del bloque izquierdo es superior a la del bloque derecho. Esto puede

tener su origen en los propios motores o en un montaje asimétrico de la mecánica,

siendo algo previsible en aplicaciones de mundo real. La consecuencia es que

siendo rigurosos, habría que encontrar un ajuste específico para el comando en

lazo abierto de cada bloque de motores.

En carga, sin embargo, el aumento de la inercia y el acoplamiento de las

mecánicas hacen que su velocidad se regularice, aunque se siguen percibiendo

perturbaciones periódicas.

Aunque los sistemas no se corresponden con uno de primer orden, para

comparar los resultados en los distintos ensayos, se ha extraído de cada uno de

ellos la constante de tiempo equivalente de primer orden, como el tiempo para el

cual la velocidad alcanza por primera vez el 66% del valor estacionario, y el tiempo

para el estacionario será 4* T.

Además, se enfrenta el valor estimado de velocidad estacionaria para

diferentes consignas ensayadas, obteniéndose la regresión lineal para los casos

libre y en carga:

Tabla 16. Resumen de pruebas. Escalón lazo abierto sin carga

PRUEBA DC Vmed Vi_inf Vd_inf T(66%) ms1.1.1 300 114,5 122 107 752.1.1 500 317 326 308 753.1.1 750 543,5 561 526 754.1.1 1000 771,5 799 744 755.1.1 1500 1224 1260 1188 756.1.1 2000 1623,5 1670 1577 75



Velocidad estacionaria VS DC accionamiento

y = 0,8882x - 129,95

R2 = 0,99890

200

400

600

800

1000

1200

1400

1600

1800

0 500 1000 1500 2000 2500

Vmed

Lineal(Vmed)

Ilustración 97. Velocidad estacionaria frente a accionamiento. Libre

Tabla 17. Resumen de pruebas. Escalón lazo abierto en carga

PRUEBA DC Vmed Vi_inf Vd_inf T(66%) ms1.2.1 300 92 91 93 2252.2.1 500 280 281 279 1503.2.2 750 506 510 502 1504.2.1 1000 726,5 735 718 1756.2.1 2000 1519 1519 1519 1505.2.2 1500 1132 1131 1133 1506.2.2 2000 1503,5 1494 1513 175

Velocidad estacionaria VS DC Accionamiento

y = 0,8269x - 128,17

R2 = 0,9986

0200400600800

10001200140016001800

0 500 1000 1500 2000 2500

Vmed

Lineal

Ilustración 98. Velocidad estacionaria frente a accionamiento . En carga



6.3.2. Ajuste de PID para control de velocidad

Gracias a la rutina de frenado activo se puede conseguir un sobrepaso casi

nulo a velocidades moderadas. Sin embargo, la alimentación de los motores en

modo escalón de velocidad castiga sus devanados, al aparecer elevadas corrientes

de arranque, aumentando el riesgo de derrape y por tanto de fiabilidad en la

maniobra.

Por otro lado, ya se ha hablado de la diferencia en la respuesta real de los

bloques de motores ante la misma excitación, y que podría abordarse con un ajuste

específico en lazo abierto.

Sin embargo, estas diferencias pueden no ser estáticas, y evolucionar en el

tiempo.

También pueden variar con la aplicación la carga o su distribución en el robot,

que deban mover los motores.

De la capacidad de controlar la velocidad de giro de las ruedas incluso en

condiciones con cargas variables, depende la capacidad de generar trayectorias

con fiabilidad.

Por su parte, el control de posición es imprescindible, por ejemplo, para

ejecutar con precisión los lances del juego en EUROBOT.

Por todo ello se optó por incorporar un algoritmo de control de velocidad PID

en el programa de control del robot.

Puesto que esta es una aplicación habitual para un microcontrolador, Microchip

proporciona información de referencia. En particular es de utilidad el documento

AN532. “Servo Control of a DC-Brush Motor” [31].

El lazo de control para esta aplicación es el siguiente:

Ilustración 99. Lazo de control de velocidad.



El papel de conversión D/A puede atribuírsele al módulo PWM, pues genera

una tensión que es variable en promedio. Se identifican los dos canales del

encóder, el contador de pulsos y la realimentación al micro.

El ajuste del controlador PID consiste en encontrar valores para sus

parámetros que proporcionen una buena respuesta en un rango de uso amplio. No

se trata por tanto de encontrar un controlador óptimo para unas condiciones

concretas.

No se dispone de un modelo analítico del sistema, por lo que se recurre a

pruebas empíricas para comprobar la validez del control propuesto.

Orden de magnitud de los parámetros del control

En primer lugar se desea acotar los valores razonables de los parámetros

Kp_x, Ki_x y Kd_x sobre los que trabajar, donde x indica que pueden establecerse

valores distintos para los dos controles (como solución general, mismos para el

control sobre las velocidades izquierda y derecha).

La acción sobre los motores tiene la forma:

VcontrolVbaseVconsigna

Ecuación 8. Composición de la consigna de velocidad

Donde:

- Vbase es la componente contínua de la señal, generada a partir de la

regresión experimental de Velocidad real frente a accionamiento en

lazo abierto. Sigue la forma del perfil de velocidad buscado.

- Vcontrol es propiamente la componente de control, generada por el

algoritmo PID, que se ocupa de compensar las desviaciones.



Profundizando en Vcontrol:

ktDEkdktIEkiktIEkpktVcontrol

Ecuación 9. Expresión de acción de control PID en términos de sus componentes

Que representa la contribución de los términos proporcional, integral y

derivativo del control a la acción de control, donde:

- kp = Kp

- ki = Ki*deltaT

- kd= Kd/deltaT

Para una situación general de control, se pretende que las acciones de control

alcancen valores razonables, teniendo como referencia el valor de la señal Vbase.

Se encuentra un orden de magnitud sobre el que trabajar con los parámetros:

A esto se añade la siguiente restricción por la implementación del algoritmo en

el microcontrolador:

Metodología de las pruebas

Una vez establecida la comunicación con el robot, se le sitúa sobre la

plataforma de pruebas.

Desde el hiperterminal se ajusta el modo de funcionamiento (por defecto,

control y registro de datos, activos) y se da valor a los parámetros de control.

Se envía la orden de movimiento de prueba, que es ejecutada por el robot, a

cuyo término se reciben los datos registrados, de los que destacan por su interés:

- Instante de lectura de los datos

- Cuentas absolutas de los encóder izquierdo y derecho

Kp, Ki, Kd ≤9,99

Kp ≈ 1 Ki≈1 Kd≈0.01



- Velocidades base ( referencia)

- Velocidad real leída

Evaluación del desempeño

Para valorar la bondad del control, es necesario disponer de indicadores de

desempeño que además simplifiquen la comparación entre distintos controles

propuestos.

Actualmente se encuentran implementados tres indicadores:

Sobrepaso máximo:

El sobrepaso en velocidad tiene como principal efecto no deseado que

se alcanza la distancia consignada en un instante anterior al planeado,

y para el que la velocidad de consigna planeada no es nula. Para

incurrir en el menor sobrepaso posible, el control frena bruscamente el

motor, incurriendo en acciones de control agresivas.

Error absoluto máximo:

En general el error máximo suele tener lugar en instantes siguientes al

arranque, cuando los motores deben vencer la inercia del sistema, así

como las fricciones estáticas de los componentes.

Integral de error absoluto:

Este indicador permite valorar el desempeño a lo largo de una

trayectoria. Se define como:

fin

t

tVrealtVbaseIEA0

|)()(|

Ecuación 10. Integral de error absoluto

Además de esta información capturada por el robot, y facilitada al final del

recorrido, se debe tener en cuenta el comportamiento observado en el ensayo en

cuanto a sobrepaso, deslizamiento de las ruedas, brusquedad de movimientos e

impresión general.



Resultados de pruebas sobre consigna trapezoidal de velocidad:

Se toma como orden de movimiento de referencia, para todas las pruebas

siguientes:

Correspondiente a un tramo recto de 1500 mm de longitud y una velocidad

tangencial del robot de 800 mm/s (aproximadamente el 50% de su velocidad

máxima).

0

100

200

300

400

500

600

700

800

900

1000

010

020

030

040

050

060

070

080

090

010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

0026

0027

0028

0029

00

Velo

cida

d m

mps

Kp: 0; Ki: 0; Kd: 0

Vbase_i

Vbase_d

Vi

Vd

Ilustración 100. Prueba 1 de ajuste de parámetros PID.

-600

-400

-200

0

200

400

600

800

1000

0

100

200

300

400

500

600

700

800

900

1000

1100

1200

1300

1400

1500

1600

1700

1800

1900

2000

2100

2200

2300

2400

2500

Velo

cida

d (m

m/s

)

MOV[800,0,1500,0,0] Kp: 1; Ki:0; Kd:0

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd

Ilustración 101. Prueba 2 de ajuste de parámetros PID

MOV[800,0,1500,0,0]



-800

-600

-400

-200

0

200

400

600

800

1000

0 75 150

225

300

375

450

525

600

675

750

825

900

975

1050

1125

1200

1275

1350

1425

1500

1575

1650

1725

1800

1875

1950

2025

2100

2175

2250

2325

2400

2475Ve

locid

ad m

mps

MOV[800,0,1500,0,0] Kp:1.5; Ki:0; Kd:0

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd


-800

-600

-400

-200

0

200

400

600

800

1000

010

020

030

040

050

060

070

080

090

010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

00Velo

cida

d (m

m/s

)

MOV[800,0,1500,0,0] Kp:2; Ki:0; Kd:0

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd




-800

-600

-400

-200

0

200

400

600

800

1000

010

020

030

040

050

060

070

080

090

010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

0026

00Velo

cida

d m

mps

MOV[800,0,1500,0,0] Kp:2,5; Ki:0; Kd:0

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd


-600

-400

-200

0

200

400

600

800

1000

010

020

030

040

050

060

070

080

090

010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

00

Velo

cida

d m

mps

MOV[800,0,1500,0,0] Kp:1; Ki:0.5; Kd:0

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd




-600

-400

-200

0

200

400

600

800

1000

0 75 150

225

300

375

450

525

600

675

750

825

900

975

1050

1125

1200

1275

1350

1425

1500

1575

1650

1725

1800

1875

1950

2025

2100

2175

2250

2325

2400

2475

2550

Velo

cida

d m

mps

MOV[800,0,1500,0,0] Kp:1,5; Ki:0,5; Kd:0

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd


-700

-500

-300

-100

100

300

500

700

900

1100

010

020

030

040

050

060

070

080

090

010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

0025

00

Velo

cida

d m

mps

MOV[800,0,1500,0,0] Kp:1,5; Ki:0,9; Kd:0

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd




-500

-300

-100

100

300

500

700

9000

100

200

300

400

500

600

700

800

900

1000

1100

1200

1300

1400

1500

1600

1700

1800

1900

2000

2100

2200

2300

2400

2500

Velo

cida

d m

mps

MOV[800,0,1500,0,0] Kp:1; Ki:2; Kd:0

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd


-300

-100

100

300

500

700

900

010

020

030

040

050

060

070

080

090

010

0011

0012

0013

0014

0015

0016

0017

0018

0019

0020

0021

0022

0023

0024

00

Velo

cida

d m

mps

MOV[800,0,1500,0,0] Kp:0; Ki:2; Kd:0

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd




-1000

-500

0

500

1000

1500

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97 101

105

109

113

117

121

125Ve

loci

dad

mm

ps

MOV[800,0,1500,0,0] Kp:1; Ki:0; Kd:0,1

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd




-2000

-1500

-1000

-500

0

500

1000

15000 75 150

225

300

375

450

525

600

675

750

825

900

975

1050

1125

1200

1275

1350

1425

1500

1575

1650

1725

1800

1875

1950

2025

2100

2175

2250

2325

2400

2475

2550

Velo

cida

d m

mps

MOV[800,0,1500,0,0] Kp:1;Ki: 2; Kd:0.1

Vbase_i

Vbase_d

VControl_i

Vcontrol_d

Vi

Vd


-300

-100

100

300

500

700

900

0

100

200

300

400

500

600

700

800

900

1000

1100

1200

1300

1400

1500

1600

1700

1800

1900

2000

2100

2200

2300

2400

2500

2600

2700

2800

Títu

lo d

el e

je

MOV[800,0,1500,0,0] Kp:1; Ki=0; Kd:0

Vbase_i

Vbase_d

Control_i

Vcontrol_d

Vi

Vd




Pru

eba

VS

Kp

Ki

Kd

Ep

osI

_fin

Ep

osD

_fin

IEA

_i IE

A_d

ma

x_so

brep

aso

_i m

ax_s

ob

rep

aso

_d E

A_m

ax_i

EA

_max

_dP1

800

1500

00

0-9

4-1

2234

4.46

343.

99 -4

35.9

4 -5

06.6

343

5.94

506

.63

P280

015

001

00

-7-1

514

1.22

143

.92

-471

.28

-465

.39

471

.28

465

.39

P380

015

001,

50

0-9

-912

4.58

118.

4 4 -3

77.0

3 -3

53.4

637

7.03

353

.46

P480

015

002

00

-6-8

113.

5710

8.71

-312

.22

-259

.20

312.

22 2

59.2

0P5

800

1500

2,5

00

-4-6

95.3

1 1

02.0

9 1

35.4

9 -4

1.24

253

.31

259

.20

P680

015

001

0,5

0-9

-715

6.01

148.

68 -3

59.3

5 5

3.02

359.

35 5

41.9

7P7

800

1500

1,5

0,5

0-5

-413

4.63

125.

99 1

06.0

4 1

23.7

128

2.77

335

.79

P880

015

001,

50,

90

-8-4

144.

26 1

28.3

8 1

00.1

5 1

29.6

0 3

18.1

1 3

82.9

2P9

800

1500

12

0-7

-815

0.26

134.

5 4 -3

18.1

1 -3

00.4

431

8.11

300

.44

P10

800

1500

02

0-1

4-1

019

5.15

190.

99 -3

88.8

1 5

.89

388.

81 4

24.1

5P1

180

015

001

00,

1-7

-12

165.

81 1

51.6

6 5

.89

129

.60

253

.31

265

.10

P12

800

1500

12

0,1

-11

-814

3.41

140.

60 -4

53.6

1 -4

18.2

645

3.61

418

.26

P13

800

1500

10

0-7

-618

5.07

181

.70

-200

.29

41.

24 2

00.2

9 2

65.1

0

Tabla 18. Resumen pruebas de ajuste parámetros PID



Observaciones

La secuencia de pruebas se ha realizado teniendo en cuenta algunos de los

métodos clásicos de ajuste de PID.

En particular, según el método de Ziegler-Nichols, el proceso debe comenzar

trabajando sólo con la ganancia proporcional, haciendo 0 el valor de Ki y de Kd.

El valor de Ki se va aumentando, comprobando que para valores mayores de

un valor crítico, el sistema se vuelve inestable.

Para poder contrastar con una situación de referencia, se realiza la prueba 1,

en la que el algoritmo de control está desactivado, y por tanto la salida del sistema

es la respuesta en lazo abierto ante una consigna trapezoidal.

Ganancia proporcional

Entre las pruebas 2 a 5 se va aumentando el valor de la ganancia a 1, 1’5, 2 y

2’5 respectivamente. Se aprecia claramente que va mejorando el desempeño en

todos los indicadores, pero a costa de acciones de control crecientes en

agresividad.

Ya para Kp=2’5, se aprecia que la acción de control al cambiar bruscamente la

consigna, alcanza valores de saturación.

Para el valor de Kp=3, el sistema se vuelve críticamente estable: en el entorno

del equilibrio, la acción de control hace que el robot se mueva bruscamente hacia

delante y hacia atrás, sin llegar a tener un avance neto, y no llega a completar el

recorrido consignado.

Ganancia integral

Para permitir margen de acción en el control a la acción integral se mantiene

un valor moderado de acción integral (Kp=1) y se establece Ki=0’5, en la prueba 6.

No se consigue una mejora tangible del desempeño por lo que se van alternando

aumentos en Kp y aumentos en Kd en las pruebas siguientes.

A partir de la prueba 7 se aprecia una mejora en el seguimiento de las rampas,

que sin la acción integral no se conseguía.



La prueba 9, con Kp=1 y Kd=2 ofrece un desempeño muy equilibrado: el

seguimiento de la rampa de aceleración es el mejor conseguido, pues aunque el

sistema empieza por debajo, es capaz de alcanzar la consigna al final del tramo.

Sin embargo la acción integral por el error acumulado produce sobrepaso en el

tramo a velocidad constante. Al llegar el tramo de deceleración, se consigue

idénticamente un buen seguimiento, apreciándose que para el momento de la

detención, la velocidad de los motores es muy cercana a la de la consigna de

velocidad, y el cambio brusco en la consigna (orden de parada, Vbase=0), no

produce una acción de control correctora demasiado violenta.

Este es un buen punto de partida para incorporar la acción derivativa.

Como curiosidad, se hace un control puramente integral en la prueba 10.

Ganancia derivativa

A partir de la prueba 11 se trabaja la acción derivativa. Para percibir la

importancia de su efecto se deshabilita la acción integral y se deja un valor

moderado de Kp=1.

Se fija Kd=0’1. Aun siendo un valor pequeño, se observa que contribuye

decididamente en el control de la velocidad derecha, produciendo un perfil irregular

durante toda la trayectoria, para finalmente provocar valores de salida en saturación

ante el cambio brusco de consigna que se produce en la detención.

Recuperando los resultados para lazo abierto, la importante contribución sólo

en el lado derecho puede corresponderse a que su salida es de forma natural más

oscilante.

Tras varios ajustes en el valor de Kd no se consigue uno en el que su

aportación mejore el desempeño, y puesto que sí se introduce el riesgo de

amplificar perturbaciones, se desestima utilizar la acción de control derivativa.

Solución adoptada

De entre todas las opciones que se han estudiado, el mejor ajuste encontrado

es el de la prueba 9.



Para poner de manifiesto la mejora que produce en el desempeño, se

muestran en una misma gráfica los resultados de la prueba 0 y el de la 9:

0

100

200

300

400

500

600

700

800

900

1000

0 75 150

225

300

375

450

525

600

675

750

825

900

975

1050

1125

1200

1275

1350

1425

1500

1575

1650

1725

1800

1875

1950

2025

2100

2175

2250

2325

2400

2475

2550

2625

2700

2775

2850

Velo

cidad

Comparación ajuste entre control apagado y (Kp=1; Ki=2;Kd=0)

Vbase_i

Vbase_d

Vi_LA

Vd_LA

Vi_PI

Vd_PI

Ilustración 113. Comparación entre gobierno en lazo abierto y ajuste del control propuesto

Resulta evidente al comparar las curvas de velocidad que el seguimiento de la

referencia es mucho mejor con la intervención del control propuesto.

Comparando los indicadores de desempeño que proporciona el robot se tiene:

IEA_i IEA_d max_sobrepaso_i max_sobrepaso_d EA_max_i EA_max_dLazo abierto 344.46 343.99 -435.94 -506.63 435.94 506.63Kp=1; Ki=2 150.26 134.54 -318.11 -300.44 318.11 300.44

Siendo todos favorables al control propuesto.

Estudio Económico 185


7. Estudio Económico En el presente capítulo se pretende dar cuenta de los recursos que han sido

necesarios para llevarlo a cabo.

Se distingue entre recursos materiales (medidos en euros) y recursos humanos

(horas de trabajo. Para llegar a unos costes homogéneos se valorarán los recursos

humanos a precio de mercado.

En la estructura de costes se distingue entre directos e indirectos, que a su vez

se clasifican por su origen. Finalmente se agregan los costes para mostrar un

presupuesto total.

7.1. Costes directos Los costes directos son aquellos imputables de manera inmediata a los

equipos desarrollados y entregables generados. A su vez pueden clasificarse por el

origen del coste.

7.1.1. Costes en materias primas y componentes

Tabla 19. Costes del material electrónico (euros)

Descripción Referencia ProveedorCoste

unitarioCantidad Coste total

Placa potencia dual VNH2SP30 708 Pololu 40,00 1 40,00Adaptador USB-serie 391 Pololu 12,00 1 12,00Kit 2 módulos inalámbricos WIXEL 1338 Pololu 32,27 1 32,27Placa fotosensible positiva FR4 Electrosón 16,00 2 32,00Micro dsPIC33FJ64MC802 Sagitrón 3,20 3 9,60Componentes Varios Farnell 18,60 1 18,60Monitor de tensión LIPO Hobbyking 4,60 1 4,60

149,07

MATERIAL ELECTRÓNICO

Total



Tabla 20. Coste de los componentes mecánicos del robot (euros)



Piezas ALU corte láser Láser Ebro 1 95,00Plexiglás tapa electrónica Leroy Merlin 8,00 1 8,00Perfil ALU 15*15 Lerol Merlin 3,20 2 6,40Perfil ALU 10*15 Leroy Merlin 2,85 2 5,70Casquillo polea dentada 10Z 226106 Conrad DE 6,95 8 55,60Correa dentada 40 Z 226050 Conrad DE 1,95 5 9,75Rodamientos 6x19x6 ZZ 214469 Conrad DE 1,50 10 15,00Barra acero eje 6mm 237086 Conrad DE 3,95 1 3,95Juego anillos de presión D 6mm 225436 Conrad DE 4,95 1 4,95Tornillería M3 Ferr. Ortiz 0,03 200 6,00Tornillería M4 Ferr. Ortiz 0,04 120 4,80Par casquillos adaptador ruedas 1083 Pololu 6,10 3 18,30Par de ruedas 90x10 Pololu 7,70 3 23,10

256,55

MATERIAL PARA ESTRUCTURA Y COMPONENTES MECÁNICOS

Total

Tabla 21. Coste de los materiales eléctricos del robot



Motor 37D 291 encoder 64CPR 1443 Pololu 19,19 3 57,57Motor 37D291 1103 Pololu 30,73 3 92,19Batería LI-Po 2S 1200mAh Conrad 12,20 1 12,20Batería Li-Po 3S 4000mAh Hobbyking 26,00 1 26,00Interruptor DPDT Electroson 2,30 1 2,30Portafusibles Hispanofil 1,60 2 3,20Cableado CSV 1,20 3 3,60Ventilador ABM PAPST Electroson 11,60 1 11,60Interruptor palanca SPST Electrosón 1,30 3 3,90Terminales y componentes Varios Varios 7,70

220,26

MATERIAL ELÉCTRICO

Total

Tabla 22. Resumen de costes en materias primas y componentes (euros)

Elementos electrónicos 149,07Elementos mecánicos 256,55Elementos eléctricos 220,26Suma 625,88IVA 18% 112,6584

Total 738,5384

COSTES EN MATERIALES DEL ROBOT



7.1.2. Costes de amortización de equipos y herramientas.

Los costes de amortización son una figura contable para contemplar el

deterioro producido por el uso o envejecimiento de equipos y herramientas.

Tabla 23. Costes de amortización

DescripciónCoste

unitarioUnidades Coste total

Amortización herramientas 1,5 /h 20 30Equipos de medida 0,75/h 50 37,5Ordenador portátil 0,20/h 960 192

259,5Total

7.1.3. Costes de software y licencias.

Tabla 24. Costes por licencias informáticas

Descripción Coste unitario Unidades Coste total

Windows XP Amortizado 20 30Solid Edge ST2 2 160 320Autocad 2005 0,53 100 53Proteus 7 Licencia UVA 0Dropbox Gratis 0Microsoft Office 2003 Amortizado 0Adobe Photoshop 7.0 49/mes 1 49MPLAB 8.83 0,75/h 50 37,5

489,5Total

7.1.4. Costes por mano de obra empleada

Las horas de mano de obra se presentan desagregadas por paquetes de

trabajo, de modo que sirva también como registro del esfuerzo realizado en cada

grupo de tareas.

Para la conversión de horas a euros se supone que el diseño, construcción y

montaje de los sistemas, así como su programación y validación ha sido realizado

por un ingeniero.



En primer lugar debe calcularse el coste por hora de ingeniero. Se supone el

año laboral de 1760 horas. Como base salarial, 27000 euros brutos/año, que resulta

coherente con los convenios colectivos sectoriales.

Sobre esto debe cargarse la seguridad social a cargo de la empresa, con lo

que se obtiene el coste total para la empresa.

Tabla 25. Coste por hora de ingeniero

Concepto Importe

Salario bruto anual 27000Seguridad Social a cargo de la empresa (29,7%) 8019Coste anual por empleado 35019

Horas laborables/año 1760

Coste por hora 19,90

En cuanto al esfuerzo de los paquetes de trabajo, se tiene el siguiente registro

de duración de actividades:



Tabla 26. Esfuerzo y coste de M.O. asociados al robot

TAREAEsfuerzo (horas)

Coste MO ingeniero

INICIACIÓNComunicación con interesados 10 horas 199Reunión kick-off con tutor 2 horas 39,8

DISEÑO 0Arquitectura robótica 48 horas 955,2Diseño electrónico 0

Placa control tracción 64 horas 1273,6Placa accionamientos 40 horas 796Pruebas en placa de prototipos 30 horas 597Gestión adquisiciones electrónica 24 horas 477,6

Mecánica 0Gestión de adquisiciones mecánica 24 horas 477,6Diseño mecánico y modelado 3D 200 horas 3980

CONSTRUCCIÓN Y MONTAJE 0Electrónica 0

Placa de accionamientos y de control tracción 0Fabricación PCB 12 horas 238,8Montaje de componentes 24 horas 477,6Comprobaciones 16 horas 318,4

Placa de potencia 0Montaje y validación 4 horas 79,6Conexiones conjunto 24 horas 477,6

Mecánica 0Bloques motor 24 horas 477,6Estructura y bastidor 32 horas 636,8Montaje conjunto 16 horas 318,4

Programación 0Herramientas de lenguaje 30 horas 597Configuración de los módulos 130 horas 2587Pruebas 32 horas 636,8Integración en VICBOT 24 horas 477,6

SEGUIMIENTO Y CONTROL 0Documentación de los trabajos 16 horas 318,4Reuniones con el tutor 4 horas 79,6

CIERRE DEL PROYECTO 0Redaccion de la memoria 120 horas 2388Preparación presentación 16 horas 318,4

Total 966 horas 19223,46,6 meses

Se han dedicado al proyecto un total de 966 horas, que distribuidas sobre una

jornada laboral de 40 horas semanales con un único ingeniero para su ejecución,

dan lugar a una duración de 6 meses y 12 días de trabajo.



7.2. Costes indirectos Se incluyen como indirectos aquellos costes que no pueden imputarse

directamente a la fabricación del robot.

Tabla 27. Costes indirectos y generales

Concepto Importe

Gastos generales de oficina 72Gastos generales laboratorio 26Consumos y suministros 160Gastos de envío 65Transporte y desplazamientos 11

334,00

7.3. Costes totales del proyecto

Tabla 28. Costes totales del proyecto

Concepto Parciales Totales

Costes materiales 738,5384Costes amortizaciones y herramientas 259,5Costes mano de obra 19223,4Costes en permisos y licencias 489,5

Total costes directos 20710,9384Costes indirectos 334,00

Total costes del proyecto 21044,94

El coste total de la ejecución del proyecto es de veintiún mil cuarenta y cuatro

con noventa y cuatro euros.

Conclusiones y Trabajos Futuros 191


8. Conclusiones y Trabajos Futuros En el presente capítulo se deja constancia de las conclusiones a la realización

del proyecto y se apunta hacia futuras líneas de trabajo como continuación de éste

o profundizando en vías abiertas que pueden resultar de interés.

El comienzo de este trabajo se encuentra en el deseo de participar en la

competición de robótica EUROBOT, que bajo un pretexto lúdico, plantea un reto

técnico muy interesante para un estudiante de ingeniería: el diseño y construcción

de robots móviles.

El reto es exigente, y se decidió abordarlo de forma modular, de modo que

fuera abarcable y permitiera su continuación con nuevos proyectos.

Desde la lectura de las bases de la competición, se hizo un planteamiento

general del robot, encaminado a dar soluciones a las principales tareas que el

robot tendrá que afrontar. A la luz de las teorías clásicas de la robótica, se propone

combinar aspectos de arquitecturas deliberativas, tales como la planificación de

estrategias o de trayectorias, con otros de arquitecturas reactivas, tales como la

respuesta a obstáculos o a eventos no esperados.

Una vez creado un marco general, se aborda el diseño de la plataforma móvil

para el robot. De entre las posibilidades que hay para vehículos con ruedas, se ha

apostado por la tracción “skid steer” con dos ruedas motrices por lado. Se valoró la

estabilidad que da al conjunto y su versatilidad, siendo conscientes de que la

aplicación de un modelo cinemático diferencial es formalmente inconsistente, pues

la hipótesis de no deslizamiento de las ruedas no se cumple.

En el diseño de la mecánica del robot se buscó una solución formada por

bloques motores robustos y flexibles. El hecho de que el motor, las transmisiones y

el bastidor formen bloques intercambiables, facilita su recolocación o sustitución, y

junto a la posibilidad de inclinar los bloques, lo hace muy adaptable a las

necesidades de espacio que pueden surgir.

El eje de las ruedas descansa sobre rodamientos de bolas, que unido al uso de

motores potentes confiere a la plataforma una gran capacidad de carga.



Para lidiar con la complejidad del diseño mecánico, y posteriormente la

integración de todos los sistemas del robot, se ha recurrido al modelado en tres

dimensiones con el software comercial Solid Edge, que ha resultado una

herramienta muy poderosa, facilitando el diseño y la identificación de errores,

permitiendo probar distintas alternativas, elaborar automáticamente listas de piezas

o archivos para fabricación asistida por ordenador, y otras ventajas no

estrictamente técnicas tales como la elaboración de material multimedia con el que

presentar de forma atractiva el proyecto.

El paso de los diseños a las piezas físicas ha exigido fabricar algunas en corte

por láser, y adquirir otras, siendo necesario recurrir a proveedores por internet al no

encontrarse en establecimientos locales a precios asumibles.

En cuanto al diseño electrónico, se han diseñado dos tarjetas: una para el

control de tracción, basada en microcontrolador, y otra para el accionamiento de los

circuitos eléctricos. Se ha utilizado el software Proteus, que ha permitido tanto

realizar los esquemas como el diseño de la placa de circuito impreso.

La construcción de las placas de circuito impreso se ha realizado por insolado

y ataque químico utilizando medios caseros, resultando ser mucho más costoso de

lo esperado, tanto en términos económicos como de tiempo dedicado, hasta lograr

un acabado aceptable. El coste de encargar la fabricación por medios industriales

parece estar justificado.

Como núcleo de la placa de control de tracción se ha seleccionado un potente

microcontrolador dsPIC33 de Microchip. Incorpora dos periféricos muy útiles para

aplicaciones de control de motores: interfaz para encóder de cuadratura y

generador de señales PWM. El primero de ellos permite conseguir diseños muy

compactos y elimina la necesidad de gestionar el conteo de pulsos por software. En

cuanto al segundo, permite generar señales que, amplificadas por la etapa de

potencia, permiten la regulación de velocidad del motor. Su utilización combinada

es la base de los algoritmos de control en lazo cerrado.

El diseño software comienza con la configuración de los periféricos del micro.

Para hacerlo es necesario bajar hasta el nivel físico, y ni siquiera el uso de un

lenguaje de alto nivel evita tener que conocer el dsPIC en detalle. Esto es un

importante obstáculo para el desarrollo de aplicaciones, por lo que se han

configurado y probado individualmente los periféricos de interés para aplicaciones

de control de motores, se han desarrollado funciones para las principales rutinas de

Conclusiones y Trabajos Futuros 193


movimiento y se ha integrado el código generado en el proyecto software

Vicbot.mcp.

Como conclusión, gracias a la labor realizada en este proyecto, se ha creado

un punto de partida para el desarrollo de aplicaciones que exigen movimiento que

resulta cómodo y que permite obtener resultados con inmediatez. El desarrollador

no tiene que preocuparse de los sistemas físicos del robot, que ya han sido

convenientemente comprobados, ni de conocer los entresijos del microcontrolador

que gobierna el movimiento. Dispone de una serie de funciones para ordenar el

movimiento y puede por tanto centrar sus esfuerzos en otras tareas.

En cuanto a futuras líneas de trabajo, este proyecto tiene continuación natural

en el desarrollo de los sistemas correspondientes a arquitectura de más alto nivel

según se describió y planificó en el Capítulo 2: niveles deliberativo y nivel

secuencial, necesarios para realizar las tareas propias de la competición Eurobot,.

También pueden desarrollarse otros sistemas de bajo nivel complementarios a los

que se han creado en este trabajo, y que pueden incorporarse a la plataforma, tales

como actuadores específicos para manipulación de objetos, brazos robóticos,

sistemas de sensores, de comunicación o de posicionamiento por balizas, y otras

muchas posibilidades.

Otra posibilidad es la implantación de los sistemas o bloques que forman este

robot, de forma independiente en otros desarrollos.

El área de mejoras siempre ofrece multitud de opciones. Pueden desarrollarse

nuevos proyectos software con librerías de funciones. Se puede utilizar la

plataforma para experimentación con algoritmos de control, como soporte de

aplicaciones distintas de Eurobot, y un gran número de posibilidades.

Anexos 195


ANEXOS

Código fuente 197


CÓDIGO FUENTE “Vicbot.h” /******************************************************************************/ /* VicBot.h */ /* DEFINICIONES GLOBALES */ /******************************************************************************/ /* Define macros */ //#define Nop() __asm__ volatile ("nop"); /*---- TIEMPOS Y FRECUENCIAS ----*/ #define FCY 40000000 //40MHz #define FCYPWM 10000 //10KHz #define BAUDRATE 9600 #define BRGVAL ((FCY/BAUDRATE)/16)-1 // Generador del Baud rate #define Delta_t 0.025 #define Inv_Delta_t 40 /*---- DIMENSIONES GEOMÉTRICAS Y CONVERSIONES ----*/ #define Rrueda_mm 45 #define Drueda_mm 90 #define PI 3.14 #define CPR 64 #define REDUCCION 30 #define b 300 #define b_med 150 #define RADIANESporGRADOporBMED 2.6175 // #define FACTOR_PULSOS_POR_MM (CPR*REDUCCION/(2*PI*Rrueda_mm)) #define FACTOR_PULSOS_POR_MM 6.79 //Cuidado, habrá que truncar. #define FACTOR_PULSOS_POR_METRO 6794 #define FACTOR_DESLIZAMIENTO_defecto 1.15 //1.11//Teoría inverso de:0.949 //Sconsigna=Sorden/cos(arctg(b_med/a_med)) /***************** PWM ********************************************************/ #define PWM1A LATBbits.LATB9 //Canal A PWM1 #define PWM1B LATBbits.LATB11 //Canal B PWM1 #define PWM2A LATBbits.LATB6 //Canal A PWM2 #define PWM2B LATBbits.LATB7 //Canal B PWM2 #define INTERRUPTS_POR_CICLO_CONTROL 31 //Cada - interrupciones PWM se ejecuta el //bucle control cada 0,1ms x 16 (postscalPWM) x 31=49,6ms #define DCI P1DC3 // Duty cycle lado izquierdo #define DCD P2DC1 // Duty cycle lado derecho #define HABILITAR_PWM_I() P1TCONbits.PTEN=1 //Habilita base de tiempos módulo PWM1 #define HABILITAR_PWM_D() P2TCONbits.PTEN=1 //Habilita base de tiempos módulo PWM2 #define PRESCALER_PWM1 4 //Para calcular PxTPER para PWM_FCY #define PRESCALER_PWM2 4 #define POSTSCALER_PWM1 1 //Interrup una cada tantos pulsos PWM (1,2,4,8,16) #define POSTSCALER_PWM2 1 /*************** QEI *********************************************************/ #define HABILITAR_QEI1() QEI1CONbits.QEIM=7 //modo x4 #define HABILITAR_QEI2() QEI2CONbits.QEIM=7 //modo x4



// POS1CNT // POS2CNT // MAX1CNT // MAX2CNT /***************** UART1 ****************************************************/ #define HABILITAR_UART1() U1MODEbits.UARTEN=1; // Habilita UART1 #define HABILITAR_TX1() U1STAbits.UTXEN=1; // Habilita la transmisión por TX1 #define bufferTXlleno() U1STAbits.UTXBF //1 si el buffer TX lleno #define bufferTXvacio() U1STAbits.TRMT //1 si buffer TX y registro de salida vacíos // U1TXREG Registro dato para enviar // U1RXREG // Registro donde se lee el dato recibido /**************** TIMER1 ******************************************************/ #define ENCENDER_TIMER1() T1CONbits.TON=1; #define APAGAR_TIMER1() T1CONbits.TON=0; /**************** INTERRUPCIONES **********************************************/ #define HABILITAR_INTERRUP_TMR1() IEC0bits.T1IE =1 #define HABILITAR_INTERRUP_QEI1() IEC3bits.QEI1IE=1 // interrup por POS1CNT==MAX1CNT #define HABILITAR_INTERRUP_QEI2() IEC4bits.QEI2IE=1 // interrup por POS2CNT==MAX2CNT #define HABILITAR_INTERRUP_RX1() IEC0bits.U1RXIE =1 #define HABILITAR_INTERRUP_TX1() IEC0bits.U1TXIE =1 //#define HABILITAR_INTERRUP_PWM1() IEC3bits.PWM1IE=1 //#define HABILITAR_INTERRUP_PWM2() IEC4bits.PWM2IE=1 #define DESHABILITAR_INTERRUP_QEI1() IEC3bits.QEI1IE=0 #define DESHABILITAR_INTERRUP_QEI2() IEC4bits.QEI2IE=0 /**************** REGISTROS DEL ROBOT *****************************************/ #define MAX_ELEM_COLA_MOV 10 //Se devuelve error si más órdenes #define MAX_LONG_MENSAJE 40 //Tamaño máximo de un mensaje de comandos /**************** GESTIÓN MENSAJES ********************************************/ #define long_max 6 //Longitud en caracteres decimales de Vorden,etc.. // 5 útiles y uno para \0 /***************RANGOS DE VELOCIDADES *****************************************/ #define VMIN_pos 160 //mm/s a que equivale el DCmin, de regresión () #define VMIN_neg -160 //Supongo que zona muerta positiva y negativa iguales #define DC_min 150 //DC que en regresión () corresponde a V=0 #define ACELERACION_DC 25 //Udc/ciclo: equivalencias 1000 dc/s #define ACELERACION_mmps_defecto 850.64 //mm/s2 Recordar: 0.8506mm/udc #define ACELERACION_mmpc_defecto 34.0256 //mm/ciclo. #define TRAPECIO 1 #define TRIANGULO 2 #define ACELERANDO 1 #define PLANO 2 #define DECELERANDO 3 #define PARADA 0 #define V_orden_MAX 1500 //Corresponde a poco menos que DC= 2000 #define Fipunto_orden_MAX 360 //Arbitrario. Razonable. /**************** PARAMETROS DE REGRESIONES ******************************/ // (1) Vmmps=F(DC)= 0.85*DC-127,4 #define A1 0.95// CALCULADA: 0.85 #define B1 -127.4// CALCULADA:-127.4

Código fuente 199


// (2) DC entre [0,2000]=F(V_orden)=V_orden*1,1756+149,79 // Fórmula extraída de (1) #define A2 1.05// CALCULADA: 1.1756 #define B2 133//149.79 /**************** PARAMETROS DE PID **************************************/ #define Kp_i_defecto 1 #define Ki_i_defecto 0 //10 #define Kd_i_defecto 0 //0.01 #define Kp_d_defecto 1 #define Ki_d_defecto 0 //10 #define Kd_d_defecto 0 //0.01 #define escala_K 10 //kp, ki,kd menor que 10 o mayor que 0,031 #define escala_E 2000 //Mayor que V_orden_MAX



“Config_perif.c” /*-------------------------------------------------------------------------------*/ /* Archivo: Config_perif.c CONFIGURACION DE PERIFÉRICOS */ /*------------------------------------------------------------------------------*/ /* Realizado por Vicente Izcara Autillo */ /* Fecha última revisión 21-11-2012 Descripción: Se recogen todas las funciones verificadas para un proyecto genérico Debe incluirse este archivo como archivo de código fuente en el proyecto. Deben copiarse la siguiente declaración de funciones en en archivo con main(): void InitTIMER1(void) void OSCconfig() void InitQEI(void) void InitUART1(void) void IOConfig() void InitPWM(void) Este archivo utiliza los siguientes include: #define FCY 40000000 //40MHz #define FCYPWM 10000 //10KHz #define BAUDRATE 9600 #define BRGVAL ((FCY/BAUDRATE)/16)-1 // Generador del Baud rate */ #include <p33fj64mc802.h> //dispositivo utilizado #include "VicBot.h" //Definiciones generales //#define FCY 40000000 #include <libpic30.h> #include <stdio.h> //Para el printf //#include <libq.h> //Librería matemática en punto fijo Q15 y Q16 /* MACROS */ //#define Nop() __asm__ volatile ("nop"); /* GLOBALES */ /********************* INICIALIZACIÓN TIMER 1 ***************************/ void InitTIMER1(void) TMR1 = 0; // Reseteo contador del timer T1CONbits.TON = 0; // Apagando el timer 1 T1CONbits.TSIDL = 0; // El modulo continua durante modo sleep T1CONbits.TGATE = 0; // Gated timer accumulation disabled T1CONbits.TCS = 0; // se usa Tcy como fuente de reloj T1CONbits.TCKPS = 2; // Tcy / 64 as input clock PR1 = 15625; // Período de interrupción de 25ms con prescaler de 64 IFS0bits.T1IF = 0; // Bajar bandera de interrupción por TMR1 IEC0bits.T1IE = 1; // Habilitando interrupcion por TMR1 IPC0bits.T1IP = 5; // Nivel de prioridad para interrupción TMR1

Código fuente 201


//T1CONbits.TON = 1; // Encendiendo TMR1 return; /************************ CONFIGURACION OSCILADOR *****************************/ void OSCconfig() // CONFIGURATION WORD: registros FOSCSEL y FOSC. Tipo de oscilador // SFR: Configuracion y ajuste /*OSCON*/ // Bit 6 para LOCK, read only.PLL enganchó bien /*CLKDIV*/ CLKDIVbits.FRCDIV=0; //'000'b Divisor en 1:1 CLKDIVbits.PLLPOST=0; //'00'b N2=2 CLKDIVbits.PLLPRE=1; //'00001'b N1=3 /*PLLFBD*/ PLLFBDbits.PLLDIV=63; //'000111111'b M=65 cargando un 63 /*OSCTUN*/ OSCTUNbits.TUN=0; //'000000'b 7,37 MHz+- 0% while(OSCCONbits.LOCK!= 1) ; // Wait for PLL to lock return; /************************ CONFIGURACION MODULOS QEI ************************/ void InitQEI(void) // REMAPEO DE LAS ENTRADAS AL PERIFÉRICO // REMAPEO DE BIT DE SENTIDO HACIA EL PUERTO // Habilitamos escritura sobre registros RPINRx y RPORX. __builtin_write_OSCCONL(OSCCON & 0xBF); //UNLOCK:Respeta OSCCON salvo bit6 a 0. RPINR14bits.QEA1R=12; //RP12 para QEI1A RPINR14bits.QEB1R=13; //RP13 para QEI1B RPOR2bits.RP4R=0b11010; //RP4 para UPDN1 RPINR16bits.QEA2R=14; //RP14 para QEI2A RPINR16bits.QEB2R=15; //RP15 para QEI2B RPOR2bits.RP5R=0b11011; //RP5 para UPDN2 // Si fuera necesario, aquí remapeo de UART1 // Bloqueamos escritura sobre registros RPINRx y RPORX. __builtin_write_OSCCONL(OSCCON |0x40); //LOCK: Respeta OSCCON salbo bit6 a 1. // OJO PORQUE ESAS PATILLAS SON TAMBIÉN DEL MÓDULO PWM; Asignadas a Puerto en FUSES /***** QEI1 *****/ QEI1CONbits.QEIM = 0; // Disable QEI Module QEI1CONbits.CNTERR = 0; // Clear any count errors QEI1CONbits.QEISIDL = 0; // Continue operation during sleep QEI1CONbits.SWPAB = 0; // QEA and QEB not swapped QEI1CONbits.PCDOUT = 1; // 1=Pin asignado a UPDN - 0=Normal I/O pin operation QEI1CONbits.POSRES = 0; // Index pulse does not reset position counter DFLT1CONbits.CEID = 1; // Count error interrupts disabled DFLT1CONbits.QEOUT = 1;



// Digital filters output enabled for QEn pins DFLT1CONbits.QECK = 7; // 1:256 clock divide for digital filter for QEn, reset for MAXCOUNT match MAX1CNT=0XFFFF; // Resetea al ponerse a tope POS1CNT = 0; // Reset position counter //QEI1CONbits.QEIM = 7; // Habilita en modo X4 mode with position counter reset by match (MAX1CNT) //Interrupción por POS1CNT==MAX1CNT IPC14bits.QEI1IP=6; // Nivel de prioridad interrupcion QEI1 IFS3bits.QEI1IF=0; // Reseteo flag //IEC3bits.QEI1IE=1; // Habilito interrupcion por POS1CNT==MAX1CNT en QEI1 /***** QEI2 *****/ QEI2CONbits.QEIM = 0; // Disable QEI Module QEI2CONbits.CNTERR = 0; // Clear any count errors QEI2CONbits.QEISIDL = 0; // Continue operation during sleep QEI2CONbits.SWPAB = 1; // QEA and QEB SÍ están cambiados, así que lo arreglo software QEI2CONbits.PCDOUT = 1; // 1=Pin asignado a UPDN - 0=Normal I/O pin operation QEI2CONbits.POSRES = 0; // Index pulse does not reset position counter DFLT2CONbits.CEID = 1; // Count error interrupts disabled DFLT2CONbits.QEOUT = 1; // Digital filters output enabled for QEn pins DFLT2CONbits.QECK = 7; // 1:256 clock divide for digital filter for QEn MAX2CNT=0XFFFF; // Resetea al ponerse a tope POS2CNT = 0; // Reset position counter //QEI2CONbits.QEIM = 7; // X4 mode with position counter reset by Index //Interrupción por POS2CNT==MAX2CN IPC18bits.QEI2IP=6; // Nivel de prioridad para interrupcion QEI2 IFS4bits.QEI2IF=0; // Reseteo flag //IEC4bits.QEI2IE=1; // Habilito interrupción por POS2CNT==MAX2CNT en QEI2 return; /************************ CONFIGURACION UART1 ************************/ void InitUART1(void) int i; //Aquí el remapeo de la UART1 __builtin_write_OSCCONL(OSCCON & 0xBF); //UNLOCK:Respeta OSCCON salvo bit6 a 0. RPINR18bits.U1RXR=3; //RP3 para UART1 RX RPOR1bits.RP2R=0b00011; //RP2 para UART1 TX // Bloqueamos escritura sobre registros RPINRx y RPORX. __builtin_write_OSCCONL(OSCCON |0x40); //LOCK: Respeta OSCCON salbo bit6 a 1.

Código fuente 203


U1MODEbits.UARTEN = 0; // Bit15 TX, RX DISABLED, ENABLE at end offunc U1MODEbits.USIDL = 0; // Bit13 Continue in Idle U1MODEbits.IREN = 0; // Bit12 No IR translation U1MODEbits.RTSMD = 0;//1; // Bit11 Simplex Mode, sin control de flujo RTS U1MODEbits.UEN = 0; // Bits8,9 TX,RX enabled, CTS,RTS not U1MODEbits.WAKE = 0; // Bit7 No Wake up (since we don't sleep here) U1MODEbits.LPBACK = 0; // Bit6 No Loop Back U1MODEbits.ABAUD = 0; // Bit5 No Autobaud (would require sending'55') U1MODEbits.URXINV = 0; // Bit4 IdleState = 1 (for dsPIC) U1MODEbits.BRGH = 0; // Bit3 16 clocks per bit period U1MODEbits.PDSEL = 0; // Bits1,2 8bit, No Parity U1MODEbits.STSEL = 0; // Bit0 One Stop Bit // Load a value into Baud Rate Generator. Example is for 9600. // See section 19.3.1 of datasheet. U1BRG = BRGVAL; // BAUD Rate Setting for 9600 // Load all values in for U1STA SFR U1STAbits.UTXISEL1 = 0; //Bit15 Interrupt when one TX character transferred (1/2config!) U1STAbits.UTXISEL0 = 0; //Bit13 Other half of Bit1 U1STAbits.UTXINV = 0; //Bit14 N/A, Tx idle is 1. U1STAbits.UTXBRK = 0; //Bit11 Disabled U1STAbits.UTXEN = 1; // U1STAbits.URXISEL = 0; //Bits6,7 Int. on character recieved U1STAbits.ADDEN = 0; //Bit5 Address Detect Disable // Habilito la UART U1MODEbits.UARTEN = 1; //And turn the peripheral on U1STAbits.UTXEN = 1; //UART TX enable // Interrupciones por UART IPC3bits.U1TXIP=0b100; //Prioridad media para interrupción TX1 IPC2bits.U1RXIP=0b100; //Prioridad media para interrupción RX1 IFS0bits.U1TXIF = 0; //Clear the Transmit Interrupt Flag IFS0bits.U1RXIF = 0; //Clear the Recieve Interrupt Flag //IEC0bits.U1RXIE = 1; // Enable UART RX Interrupt //IEC0bits.U1TXIE = 1; // Enable UART TX Interrupt /* wait at least 104 usec (1/9600) before sending first char */ for(i = 0; i < 4160; i++) Nop(); return; /************************ CONFIGURACION PATILLAS ************************/ /* -----U---- MCLR- Vpp -| 1 28|- AVdd CS1 AN0 -| 2 27|- AVss CS2 AN1 -| 3 26|- RP15 QEI2B PGED1 -| 4 25|- RP14 QEI2A PGEC1 -| 5 24|- RP13 QEI1B RP2 U1TX -| 6 23|- RP12 QEI1A



RP3 U1RX -| 7 22|- RB11 2B 5V Vss -| 8 21|- RB10 PWM1H3 5V RA2 -| 9 20|- Vcap RA3 -|10 19|- Vss RP4 QEI1DIR -|11 18|- RB9 2A 5V RA4 -|12 17|- RB8 PWM2H1 5V Vdd -|13 16|- RB7 1B 5V RP5 QEI2DIR 5V RB5-|14 15|- RB6 1A 5V */ void IOConfig() LATB=0; //Todas salidas a 0 para empezar TRISB=0xF00B; //1111000000001011 Entrada/salida PORTB LATA=0; //Todas salidas a 0 para empezar TRISA=0x0003; //00011 Entradas/salidas ODCB=0XFFFF; //Pongo salidas 5V en open drain AD1PCFGL=60; //111100 RA0 y RA1 analógicas;RB<3:0>digitales return; /************************ CONFIGURACION PWM ************************/ void InitPWM(void) /************ PWM1 MODULE ***********************/ //P1TCONbits.PTEN=1; //Enable time base P1TCONbits.PTSIDL=0; //PWM runs in idle mode P1TCONbits.PTOPS=0b1111; //Output postscaler 16, permite interrupt cada 16*PxTPER //Opciones de prescaler para base de tiempos PWM1. Quedan ocultas las no aplicadas. //P1TCONbits.PTCKPS=0b00; //Prescaler1 1:1 Tcy P1TCONbits.PTCKPS=0b01; //Prescaler1 1:4 Tcy //P1TCONbits.PTCKPS=Ob10; //Prescaler1 1:16 Tcy //P1TCONbits.PTCKPS=0b11; //Prescaler1 1:64 Tcy P1TCONbits.PTMOD=0; //Time base in free run P1TMRbits.PTDIR=0; //Counting up P1TMRbits.PTMR=0; //Reset del contador de pulsos, base de tiempos PWM1 //P1TPER=(FCY/(FCYPWM*PRESCALER_PWM1))-1; P1TPER=999; //FUNCIONAMIENTO: PERIODO 0.1ms P1SECMPbits.SEVTDIR=0; //Special event in counting up P1SECMPbits.SEVTCMP=P1TPER; //FUNCIONAMIENTO:A la vez que P1CNT==P1TPER, P1CNT==P1SECMPbits.SEVTCMP, disparo ADC //No confundir con generar interrupcion por fin de ciclo PWM PWM1CON1bits.PMOD3=1; //Canal H3 y L3 en modo independent PWM1CON1bits.PEN3H=1; //Pin enabled for PWM PWM1CON1bits.PEN2H=0; //Pin disabled, gpi/o PWM1CON1bits.PEN1H=0; //Pin disabled, gpi/o PWM1CON1bits.PEN3L=0; //Pin disabled, gpi/o PWM1CON1bits.PEN2L=0; //Pin disabled, gpi/o

Código fuente 205


PWM1CON1bits.PEN1L=0; //Pin disabled, gpi/o PWM1CON2bits.SEVOPS=0; //1:1 Postscaller para special event trigger PWM1CON2bits.IUE=0; //Updates of DC1 synchro to PWM timebase PWM1CON2bits.OSYNC=0; //Overrides synchro to Tcy PWM1CON2bits.UDIS=0; //Updates of DC and PTPER enabled P1OVDCONbits.POVD3H=1; //Output on PWM1H3 controlled by the PWM generator //Interrupciones por TIME BASE OUTPUT POSTSCALER= períodos completados //IPC14bits.PWM1IP=5; //Prioridad //IFS3bits.PWM1IF=0; //Bajo el flag //IEC3bits.PWM1IE=1; //Habilito interrupcion //P1DC3=1000; //FUNCIONAMIENTO: Esto debería darme un 50% //P1TCONbits.PTEN=1; //Enable time base /************ PWM2 MODULE ***********************/ //P2TCONbits.PTEN=1; //Enable time base P2TCONbits.PTSIDL=0; //PWM runs in idle mode P2TCONbits.PTOPS=0b1111; //Output postscaler 16 //Opciones de prescaler para base de tiempos PWM1. Quedan ocultas las no aplicadas. //P2TCONbits.PTCKPS=0b00; //Prescaler1 1:1 Tcy P2TCONbits.PTCKPS=0b01; //Prescaler 1:4 Tcy //P2TCONbits.PTCKPS=Ob10; //Prescaler1 1:16 Tcy //P2TCONbits.PTCKPS=0b11; //Prescaler1 1:64 Tcy P2TCONbits.PTMOD=0; //Time base in free run P2TMRbits.PTDIR=0; //Counting up P2TMRbits.PTMR=0; //Reset del contador de pulsos, base de tiempos P2 //P2TPER=(FCY/(FCYPWM*PRESCALER_PWM2))-1; P2TPER=999; //FUNCIONAMIENTO: PERIODO 0.1ms P2SECMPbits.SEVTDIR=0; //Special event in counting up P2SECMPbits.SEVTCMP=P2TPER; //FUNCIONAMIENTO:Disparo de SpcialEvent a la vez que fin de período:ADC PWM2CON1bits.PMOD1=1; //Canal H1 y L1 en modo independent PWM2CON1bits.PEN1H=1; //Pin enabled for PWM PWM2CON1bits.PEN1L=0; //Pin disabled, gpi/o //PWM2CON2bits.SEVOPS=0; //1:1 Postscaller para special event trigger PWM2CON2bits.IUE=0; //Updates of DC1 synchro to PWM timebase PWM2CON2bits.OSYNC=0; //Overrides synchro to Tcy PWM2CON2bits.UDIS=0; //Updates of DC and PTPER enabled P2OVDCONbits.POVD1H=1; //Output on PWM2H1 controlled by the PWM generator



// INTERRUPCIÓN PWM2 // IPC18bits.PWM2IP=5; //Prioridad // IFS4bits.PWM2IF=0; //Bajo el flag // IEC4bits.PWM2IE=1; //Habilito interrupcion //P2DC1=1000; //FUNCIONAMIENTO: Esto debería darme un 50% //P2TCONbits.PTEN=1; //Enable time base return;

Código fuente 207


“VicBot_main.c”

/******************************************************************************/ /* */ /* Proyecto: VicBot.mcp */ /* File: VicBot_main.c */ /* Description: Programa principal de aplicación de control de movimiento */ /* Incorpora interfaz de comunicación y control PID velocidad */ /* Otros archivos requeridos: */ /* Config_perif.c */ /* VicBot.h */ /* p33fj64mc802.h */ /* libpic30-coff.a */ /* libc-coff.a */ /* libq-coff.a */ /* libq-dsp-coff.a */ /* Autor: Vicente Izcara Autillo */ /* [email protected] */ /* Herramientas utilizadas: */ /* MPLAB -> 8.83 */ /* Revision: release (20-01-2013) */ /* */ /******************************************************************************/ #include <p33fj64mc802.h> //dispositivo utilizado #include "VicBot.h" //definiciones generales //#define FCY 40000000 #include <libpic30.h> //Ojo, definir FCY antes!! #include <stdio.h> //Para el printf #include <libq.h> //Para numeros fraccionales #include <stdlib.h> //Para atoi #include <string.h> //Para strncmp #include <math.h> //Para fabs #include <dsp.h> //Para PID -4funciones- //#include "Config_perif.c" //Funciones de inicializacion /******************************************************************************/ /* FUSES */ /******************************************************************************/ // Configuracion proteccion flash y ram _FBS(BWRP_WRPROTECT_OFF) // Sin proteccion de escritura _FGS(GCP_OFF) // Code protect disabled // Seleccion del oscilador: _FOSCSEL( FNOSC_FRCPLL & IESO_OFF ) // Fast RC oscillator w/ divide and PLL, two speed off _FOSC(FCKSM_CSDCMD & OSCIOFNC_ON & POSCMD_NONE & IOL1WAY_OFF )



//Clock switch disable, OSC2 digital I/O, Primary oscilator disabled, Allow multiple reconfig for PeriPortSelect // Configuracion del watch dog _FWDT(FWDTEN_OFF) // Watchdog disabled // Configuraciones generales: I2C, JTAG.. _FPOR(PWMPIN_ON & HPOL_ON & LPOL_ON & FPWRT_PWR1) // PWM Module pins controlled IO port, Active High for PWMH y PWML, Power on reset disable _FICD( ICS_PGD1 & JTAGEN_OFF ) // ICD communication channel on PGC1 y PGD1, JTAG port OFF /******************************************************************************/ /* DECLARACION DE VARIABLES GLOBALES */ /******************************************************************************/ int Cuenta_eventos_QEI1; // Almacena num interrupciones QEI1 char mytext[]; char* punt_mytext; char mensaje [MAX_LONG_MENSAJE]; char * puntmensaje; char caso_movimiento_actual; //Codifico la gestión según tipo de mov int variables1[200][9]; int contador_variables=0; int tiempo=0; int posicion_i_anterior=0; int posicion_d_anterior=0; typedef struct //FLAGS DEMOVIMIENTO unsigned activado:1; // Flag robot activo unsigned movencurso:1; // Flag trayectoria en curso unsigned colamovvacia:1; // Flag cola de órdenes vacía unsigned colamovllena:1; // Flag cola de órdenes llena unsigned mensajencurso:1; // Flag recibiendo caracteres de mensaje unsigned mensajerecibido:1; // Flag para espera de ser anotado en cola unsigned semiparada:1; // Semáforo de espera a que dos motores terminen para movencurso=0 unsigned log_ON:1; // Modo con registro de datos activado unsigned control_ON:1; // Modo control de velocidad activado unsigned registro_datos_lleno:1; //Array de registro lleno, deja de registrar FLAGSrobot; volatile FLAGSrobot FLAGSROBOT __attribute__((address(0x0800))); typedef struct orden

Código fuente 209


int v_orden; int fipunto_orden; int S_orden; int fi_orden; int t; struct orden * sig; //A mayores para cola por lista //int relleno; //Por si orden debe ocupar potencia de 2 posiciones ORDEN_MOV; /*------------ VARIABLES ALGORITMOS POSICION-VELOCIDAD ---------------*/ int V_orden; //Rango tipico: (-1600,1600) mm/s int S_orden; //Rango int: acuerdo que siempre >0 (-32768,32767) mm int Fipunto_orden; //Rango tipico: (-1000,1000) º/s int Fi_orden; int t; //Según interrupción de timer float Vi_orden; //Rango típico (-1600,1600)mm/s float Vd_orden; //Rango típico (-1600,1600)mm/s //int Titapuni_orden; //int Titapund_orden; float Vconsigna_i, Vconsigna_d; float Vbase_i, Vbase_d; float Vcontrol_i, Vcontrol_d; float Si_orden; // Acuerdo que siempre >0 float Sd_orden; // Acuerdo que siempre >0 float S1_i,S1_d; // Fin de ACELERANDO en TRIANGULO y TRAPECIO float S2_i,S2_d; // Fin DECELERANDO en TRIAN y PLANO en TRAP float S3_i,S3_d; // Fin DECELERANDO en TRAP char perfil; //Cargo el tipo TRAPECIO O TRIANGULO en calcular_PREMOVE() char fase_perfil_i; //Opciones: ACELERANDO,PLANO, DECELERANDO, PARADA char fase_perfil_d; float A_mmps; int Ai_dc; //Aceleración izquierda unidades DC por ciclo float Ai_mmps; int Ad_dc; //Aceleración derecha unidades DC por ciclo float Ad_mmps; float Incremento_Vbase_i; float Incremento_Vbase_d; int pos_acumulada_i;//Recogen el salto al resetear POSxCNT, mov en curso int pos_acumulada_d; int MAX1CNT_COPIA; int MAX2CNT_COPIA; /* ------- A cuenta del CONTROL ------- */ // Declaracion variables globales ya hecha en dsp.h que se incluye // typedef struct tPID // // fractional * abcCoefficients ; // /* Puntero a los coeficientes que se encuentran en el // espacio de memoria X, estos coeficientes se deriva // de los valores de las ganancias PID : Kp , Ki y Kd */ // fractional * controlHistory ; // /* Puntero a las 3 ultimas muestras almacenadas en el // espacio de memoria Y, la primera es la mas reciente*/ // fractional controlOutput ; // /* Salida del regulador PID */ // fractional measuredOutput ; // /* Valor medido de la respuesta del sistema */ // fractional controlReference ;



// /* Referencia del sistema */ // tPID ; //Declaracion funciones rutinas PID //tPID PID ( tPID *); //void PIDInit ( tPID * fooPIDStruct ); //void PIDCoeffCalc ( fractional * fooPIDGainCoeff , tPID * fooPIDStruct ); tPID PID_i, PID_d; //Estructuras de datos PID para VicBot //Variables utilizadas por las rutinas PID fractional abcCoefficient_i [3] __attribute__ (( section (".xbss , bss , xmemory "))); fractional abcCoefficient_d [3] __attribute__ (( section (".xbss , bss , xmemory "))); // A= Kp+Ki+Kd // B= -(Kp+2Kd) // C= Kd fractional controlHistory_i [3] __attribute__ ((section (".ybss , bss , ymemory"),far)); fractional controlHistory_d [3] __attribute__ ((section (".ybss , bss , ymemory"),far)); //Una vez ejecutada la rutina, quedan: [0]=[1] actual; [2] anterior; fractional kCoeffs_i [3]; //= 0 ,0 ,0; fractional kCoeffs_d [3]; //= 0 ,0 ,0; float velocidad_i_mmps; float velocidad_d_mmps; float U_control; float Vi_orden; float Vd_orden; float V_mmps; float Fipunto; float S; float Fi; int pos1_abs; int pos2_abs; float Vi_mmps, Vd_mmps; float Vi_1, Vd_1; float Vi_2, Vd_2; int POSi, POSd; int POSi_1,POSd_1; float EV; float EFipunto; float ES; float EVi,EVd; float EVi_1, EVd_1; float Kp_i; float Ki_i,Kd_i; //Variables absolutas del algoritmo float Kp_d,Ki_d,Kd_d; float kp_i,ki_i,kd_i; //Variables adaptadas a Delta_t float kp_d,ki_d,kd_d;

Código fuente 211


float IEA_i; //Integral de error absoluto float IEA_d; float max_sobrepaso_i; float max_sobrepaso_d; float EA_max_i; float EA_max_d; //No creo en paralelo A_i, A_d, B_i, B_d... typedef struct int posicion; int posicion_1; float S; float V; float V_1; float A; cinematica; cinematica CINEMATICA_i, CINEMATICA_d; //Almacenar cálculos cinemáticos typedef struct float V; float V_1; float Fipunto; float A; cinematica_robot; cinematica_robot VICBOT; typedef struct //El santo Ángel de Jerez de la Frontera: colegio Fernando Díez int Vsqr; int Fipunto_sqr; int lado_sqr; cuadrado; cuadrado trayec_cuadrado; typedef struct int radio_cir; int Vcir; circulo; circulo trayec_circulo; typedef struct //Cola genérica ORDEN_MOV* inicial; ORDEN_MOV* final; unsigned int numelem; //Ojo a que ocupe potencias de 2; cola; cola COLA_MOV; //Hago una para ordenes de mov. ORDEN_MOV* recibida; //Apunta recibida en espera de sitio en cola ORDEN_MOV* extraida; //Apunta extraida para ser ejecutada void iniciar_COLA (cola*); ORDEN_MOV* crear_ORDEN_MOV(int*); //Reserva memoria y rellena sus campos void alojar_ORDEN_MOV(cola*,ORDEN_MOV*); //Recibe orden y coloca en cola según numelem ORDEN_MOV* extraer_ORDEN_MOV(cola*); //Saca orden de cola void ejecutar_ORDEN_MOV(ORDEN_MOV*); //Gestiona la orden de movimiento



void demo_cola (int[]); int extraer_mensaje (int*); //Para hacer más compacta la extraccion de datos int calcularDC (float); //Según regresion (2) float calcularV (int); //Según regresión (1) void IOConfig(void); void OSCconfig(void); void InitQEI(void); void InitPWM(void); void InitUART1(void); void InitTIMER1 (void); void rafaga_100(unsigned int); //extern void asmFUNCION (void); //int CALCULA_DC(int PTPER, int porciento); // Calcula valor para cargar en DCx void PARAR_IZQUIERDA(void); // Declaro funcion detiene motores Iz void PARAR_DERECHA(void); // Declaro funcion detiene motores De void detener(void); void hacia_delante(void); void hacia_atras(void); void spin_izquierda(void); void spin_derecha(void); int CALCULAR_PULSOS(int); // Calcula pulsos para mm void Desplazamiento_mm_i (int,int); // Carga MAXxCNT y POSxCNT según num y signo de mm y origen void Desplazamiento_mm_d (int,int); void Gestionar_DCI (int); //Carga en DCI y ajusta sentido de giro void Gestionar_DCD (int); //Carga en DCD y ajusta sentido de giro int convertir_mmps_a_ppc (int); int convertir_ppc_a_mmps (int); void putUART1(char); // Carga un caracter para enviar void putsUART1(char*); // Carga una cadena para enviar void Filtrado_Vi_Vd_orden(void); // Escala valores dentro de rango void Cargar_var_defecto (void); void Cargar_kCoeffs (void); // Carga en array kp,ki,kd (i y d), en Q15 void Evaluar_pos1_abs(void); // Juzga con Pos_acumulada y void Evaluar_pos2_abs(void); // POSxCNT ó MAXxCNT según signo void Calcular_cinematica (cinematica*, int); void Calcular_cinematica_ROBOT (cinematica *, cinematica*, cinematica_robot*); void Saturacion_consignas (void); // Trunca consignas a valor max void Evaluar_indicadores (void); void Iniciar_variables (void); //Variables e indicadores, cada nuevo mov void Registrar_datos (void); //Refresca la cinemática y lo almacena en array void Reset_cinematica (cinematica *); // Resetea historial de cinematica void Reset_cinematica_robot(cinematica_robot *); //Resetea historial cinematica robot /******************************************************************************/ /* INTERRUPCIONES */ /******************************************************************************/ /*--------- INFO: PRIORIDAD DE INTERRUPCIONES ---------- */ // UART1RX: 4

Código fuente 213


// UART1TX: 4 // TIMER1: 5 // QEI1: 6 // QEI2: 6 // PWM1: 5 // PWM2: 5 //========================================================================== void __attribute__((interrupt, no_auto_psv)) _T1Interrupt (void) //========================================================================== /* Rutina de atención interrupción TIMER1 - TMR1=PR1 */ Evaluar_pos1_abs(); Evaluar_pos2_abs(); /* if (Si_orden>=0) pos1_abs= (int) POS1CNT+ pos_acumulada_i; else pos1_abs= -((MAX1CNT_COPIA-(int)POS1CNT)+ pos_acumulada_i); if (Sd_orden>=0) pos2_abs= (int) POS2CNT+ pos_acumulada_d; else pos2_abs= -((MAX2CNT_COPIA-(int)POS2CNT)+ pos_acumulada_d); */ switch (fase_perfil_i) case ACELERANDO: if(fabsf(Vbase_i)<fabsf(Vi_orden)) //Ambas, mmps valor entero Vbase_i=Vbase_i+Incremento_Vbase_i; break; case DECELERANDO: if (fabsf(Vbase_i)>=200) //fabsf(Incremento_Vbase_i)) //Ultimo decremento da Vbase=0 Vbase_i=Vbase_i-Incremento_Vbase_i; break; case PARADA:



Vbase_i=0; break; switch (fase_perfil_d) case ACELERANDO: if (fabsf(Vbase_d)<fabsf(Vd_orden)) Vbase_d=Vbase_d+Incremento_Vbase_d; break; case DECELERANDO: if (fabsf(Vbase_d)>=200) //fabsf(Incremento_Vbase_d)) Vbase_d=Vbase_d-Incremento_Vbase_d; break; case PARADA: Vbase_d=0; break; //Evaluación del control izquierdo //Return DCI=calcularDC(Vconsigna_i) Calcular_cinematica (&CINEMATICA_i, pos1_abs); Calcular_cinematica (&CINEMATICA_d, pos2_abs); Calcular_cinematica_ROBOT (&CINEMATICA_i,&CINEMATICA_d, &VICBOT); //----¿Fin del movimiento?<-> fase_i=PARADA & Vi=Vbase_i & fase_d=PARADA & Vd=Vbase_d --/ if ((fase_perfil_i==PARADA)&&(fabsf(CINEMATICA_i.V)<100)&&(fase_perfil_d==PARADA)&&(fabsf(CINEMATICA_d.V)<100)) detener(); FLAGSROBOT.movencurso=0; else // Cargar en variables PID las cinematicas if (FLAGSROBOT.control_ON==1) PID_i . controlReference = _Q15ftoi((float)Vbase_i/escala_E) ; //Escala V=2000 PID_d . controlReference = _Q15ftoi((float)Vbase_d/escala_E) ; //Escala V=2000 PID_i . measuredOutput= _Q15ftoi ((float)CINEMATICA_i.V/escala_E); //Le paso la salida real PID_d . measuredOutput= _Q15ftoi ((float)CINEMATICA_d.V/escala_E); PID (& PID_i ); //Llamo a la función que computa la acción de control PID (& PID_d );

Código fuente 215


Vcontrol_i=(_itofQ15(PID_i . controlOutput))*escala_K*escala_E; Vcontrol_d=(_itofQ15(PID_d . controlOutput))*escala_K*escala_E; //Vcontrol_i=0; //Lo suyo, la salida del PID //Vcontrol_d=0; else Vcontrol_i=0; Vcontrol_d=0; Evaluar_indicadores (); Vconsigna_i=(Vbase_i+Vcontrol_i)*1.05; Vconsigna_d=Vbase_d+Vcontrol_d; /* Saturacion */ Saturacion_consignas(); Gestionar_DCI (calcularDC(Vconsigna_i)); Gestionar_DCD (calcularDC(Vconsigna_d)); if ((FLAGSROBOT.log_ON==1)&&(!FLAGSROBOT.registro_datos_lleno)) Registrar_datos(); IFS0bits.T1IF = 0; // Se baja la bandera por interrupción de TMR1 return; //======================================================================= void __attribute__((interrupt, no_auto_psv)) _QEI1Interrupt(void) //======================================================================= /* Rutina de atención interrupción QEI1 - Position counter 1 compare */ /* ---- NUEVO TRAMO SEGÚN PERFIL y NUEVO LÍMITE MAXxCNT ----*/ pos_acumulada_i+=MAX1CNT_COPIA; switch (fase_perfil_i) case ACELERANDO: if (perfil==TRIANGULO)



//MAX1CNT=CALCULAR_PULSOS((int)S2_i); //Aquí, S1_i=S2_i=Si_med Desplazamiento_mm_i((int)S2_i,0); fase_perfil_i=DECELERANDO; if (perfil==TRAPECIO) //MAX1CNT=CALCULAR_PULSOS((int)(S2_i)); Desplazamiento_mm_i((int)S2_i,0); fase_perfil_i=PLANO; break; case PLANO: //MAX1CNT=CALCULAR_PULSOS((int)S3_i); Desplazamiento_mm_i((int)S3_i,0); fase_perfil_i=DECELERANDO; break; case DECELERANDO: PARAR_IZQUIERDA(); fase_perfil_i=PARADA; DESHABILITAR_INTERRUP_QEI1(); putsUART1("IZDA listo\n\r"); /* if (FLAGSROBOT.semiparada==1) //Semáforo de espera a que dos motores terminen FLAGSROBOT.semiparada=0; FLAGSROBOT.movencurso=0; putsUART1("Fin MOVenQ1\n\r"); else FLAGSROBOT.semiparada=1; */ break; IFS3bits.QEI1IF=0; // Restablecer flag de interrupcion //============================================================================ void __attribute__((interrupt, no_auto_psv)) _QEI2Interrupt(void) //============================================================================ /* Rutina de atención interrupción QEI2 - Position counter 2 compare */ /* ---- NUEVO TRAMO SEGÚN PERFIL y NUEVO LÍMITE MAXxCNT ----*/ pos_acumulada_d+= MAX2CNT_COPIA; switch (fase_perfil_d) case ACELERANDO: if (perfil==TRIANGULO) //MAX2CNT=CALCULAR_PULSOS((int)S2_d); Desplazamiento_mm_d((int)S2_d,0); fase_perfil_d=DECELERANDO; if (perfil==TRAPECIO) //MAX2CNT=CALCULAR_PULSOS((int)(S2_d)); Desplazamiento_mm_d((int)S2_d,0); fase_perfil_d=PLANO;

Código fuente 217


break; case PLANO: //MAX2CNT=CALCULAR_PULSOS((int)S3_d); Desplazamiento_mm_d((int)S3_d,0); fase_perfil_d=DECELERANDO; break; case DECELERANDO: PARAR_DERECHA(); fase_perfil_d=PARADA; DESHABILITAR_INTERRUP_QEI2(); putsUART1("DCHA listo\n\r"); /* if (FLAGSROBOT.semiparada==1) //Semáforo de espera a que dos motores terminen FLAGSROBOT.semiparada=0; FLAGSROBOT.movencurso=0; putsUART1("Fin MOVenQ2\n\r"); else FLAGSROBOT.semiparada=1; */ break; IFS4bits.QEI2IF=0; // Restablecer flag //======================================================================= void __attribute__((interrupt, no_auto_psv)) _U1RXInterrupt(void) //======================================================================= /* Rutina de atención interrupción UART1 RX */ char recibido; char caso_comando; char caso_variable; int i,j; //indice mensaje, índice submensaje char variable[10]; //nombre de variable float valor; //Valor de la variable int orden_recibida[5]; //Pivote para ir apuntando recibido=U1RXREG; switch (recibido) case '$': //$: d36 ó 0x24 puntmensaje=&(mensaje[0]); for (i=0;i<MAX_LONG_MENSAJE;i++) mensaje[i]='\0'; /*while (*puntmensaje != '\0') //Asumo que \0 es el último elemento *puntmensaje=' '; puntmensaje++; */ puntmensaje=&(mensaje[0]); //Listo para apuntar comando FLAGSROBOT.mensajencurso=1; FLAGSROBOT.mensajerecibido=0; break; case '#': //#: d35 ó 0x23



FLAGSROBOT.mensajerecibido=1; FLAGSROBOT.mensajencurso=0; Nop(); break; default: //Apunto caracteres que no sean $# *puntmensaje=recibido; puntmensaje++; break; //Interpretar mensaje // Bloque COMANDO: if (FLAGSROBOT.mensajerecibido==1) caso_comando=0; //por defecto if(strncmp(mensaje,"MOV",3)==0) caso_comando=1; else if(strncmp(mensaje,"WHO",3)==0) caso_comando=2; else if(strncmp(mensaje,"SET",3)==0) caso_comando=3; else if(strncmp(mensaje,"LOG ON",6)==0) caso_comando=4; else if(strncmp(mensaje,"LOG OFF",7)==0) caso_comando=5; else if(strncmp(mensaje,"CTRL ON",7)==0) caso_comando=6; else if(strncmp(mensaje,"CTRL OFF",8)==0) caso_comando=7; else if(strncmp(mensaje,"ASK",3)==0) caso_comando=8; else if(strncmp(mensaje,"SQR",3)==0) caso_comando=9; else if(strncmp(mensaje,"CIR",3)==0) caso_comando=10; switch (caso_comando) case 0: putsUART1("Comando no reconocido\n\n\r"); FLAGSROBOT.mensajerecibido=0; break; case 1: /* ---- PRIMER SUBMENSAJE ---- */ i=1; while (mensaje[i-1]!='[') i++; //Recorro hasta el siguiente de [ //El mensaje es global orden_recibida[0]= extraer_mensaje (&i); //Extrae hasta siguiente ','ó']' /* ---- SEGUNDO SUBMENSAJE ----*/ //i debe quedar en siguiente a primera , orden_recibida[1]= extraer_mensaje (&i); /* ---- TERCER SUBMENSAJE ----*/

Código fuente 219


//i debe quedar en siguiente a segunda , orden_recibida[2]= extraer_mensaje (&i); /* ---- CUARTO SUBMENSAJE ----*/ //i debe quedar en siguiente a tercera , orden_recibida[3]=extraer_mensaje(&i); /* ---- QUINTO SUBMENSAJE ----*/ //i queda en siguiente a cuarta , orden_recibida[4]=extraer_mensaje(&i); //Cargar orden en cola de movimiento alojar_ORDEN_MOV(&COLA_MOV,crear_ORDEN_MOV(orden_recibida)); FLAGSROBOT.mensajerecibido=0; //Puedo cargar uno nuevo break; case 2: //Mensaje de identificación putsUART1("VICBOT al aparato\n\r"); FLAGSROBOT.mensajerecibido=0; break; case 3: //Comando SET de cambio en variable i=1; while (mensaje[i-1]!='[') i++; //Recorro hasta el siguiente de [ for (j=0; j<10; j++) variable[j]='\0'; //Limpio el arreglo j=0; while (mensaje[i]!=',') variable[j]=mensaje[i]; i++; j++; // Evalúo de qué variable se trata caso_variable=0; if(strncmp(variable,"Kp_i",4)==0) caso_variable=1; else if (strncmp(variable,"Ki_i",4)==0) caso_variable=2; else if (strncmp(variable,"Kd_i",4)==0) caso_variable=3; else if (strncmp(variable,"Kp_d",4)==0) caso_variable=4; else if (strncmp(variable,"Ki_d",4)==0) caso_variable=5; else if (strncmp(variable,"Kd_d",4)==0) caso_variable=6; else if (strncmp(variable,"A_mmps",6)==0)



caso_variable=7; //Extraigo el valor de la variable for (j=0;j<10;j++) variable[j]='\0'; i++; j=0; while (mensaje[i]!=']') variable[j]=mensaje[i]; i++; j++; valor=atof(variable); //Confío en '.' coma decimal switch (caso_variable) case 0: putsUART1("Variable no reconocida\n"); FLAGSROBOT.mensajerecibido=0; break; case 1: Kp_i=valor; putsUART1("Kp_i SET\n\r"); break; case 2: Ki_i=valor; putsUART1("Ki_i SET\n\r"); break; case 3: Kd_i=valor; putsUART1("Kd_i SET\n\r"); break; case 4: Kp_d=valor; putsUART1("Kp_d SET\n\r"); break; case 5: Ki_d=valor; putsUART1("Ki_d SET\n\r"); break; case 6: Kd_d=valor; putsUART1("Kd_d SET\n\r"); break; case 7: A_mmps=valor; putsUART1("A_mmps SET\n\r"); break; FLAGSROBOT.mensajerecibido=0; break;

Código fuente 221


case 4: // Activar registro datos FLAGSROBOT.log_ON=1; putsUART1("Registro datos ON\n\r"); FLAGSROBOT.mensajerecibido=0; break; case 5: //Desactivar registro datos FLAGSROBOT.log_ON=0; putsUART1("Registro datos OFF\n\r"); FLAGSROBOT.mensajerecibido=0; break; case 6: //Activar control de velocidad FLAGSROBOT.control_ON=1; putsUART1("Control ON\n\r"); FLAGSROBOT.mensajerecibido=0; break; case 7: //Desactivar control de velocidad FLAGSROBOT.control_ON=0; putsUART1("Control OFF\n\r"); FLAGSROBOT.mensajerecibido=0; break; case 8: //Preguntar valor de parámetro o variables i=1; while (mensaje[i-1]!='[') i++; //Recorro hasta el siguiente de [ for (j=0; j<10; j++) variable[j]='\0'; //Limpio el arreglo j=0; while (mensaje[i]!=']') variable[j]=mensaje[i]; i++; j++; // Evalúo de qué variable se trata caso_variable=0; if(strncmp(variable,"Kp_i",4)==0) caso_variable=1; else if (strncmp(variable,"Ki_i",4)==0) caso_variable=2; else if (strncmp(variable,"Kd_i",4)==0) caso_variable=3; else if (strncmp(variable,"Kp_d",4)==0) caso_variable=4; else if (strncmp(variable,"Ki_d",4)==0) caso_variable=5; else if (strncmp(variable,"Kd_d",4)==0) caso_variable=6; else if (strncmp(variable,"A_mmps",6)==0) caso_variable=7; //Mostrar el valor de lo seleccionado switch (caso_variable)



case 0: putsUART1("Variable no reconocida\n"); FLAGSROBOT.mensajerecibido=0; break; case 1: printf("Kp_i: %.2f \n\r",Kp_i); break; case 2: printf("Ki_i: %.2f \n\r",Ki_i); break; case 3: printf("Kd_i: %.2f \n\r",Kd_i); break; case 4: printf("Kp_d: %.2f \n\r",Kp_d); break; case 5: printf("Ki_d: %.2f \n\r",Ki_d); break; case 6: printf("Kd_d: %.2f \n\r",Kd_d); break; case 7: printf("A_mmps: %.2f \n\r",A_mmps); break; FLAGSROBOT.mensajerecibido=0; break; case 9: //CREAR TRAYECTORIA CUADRADO i=1; while (mensaje[i-1]!='[') i++; //Recorro hasta el siguiente de [ //El mensaje es global trayec_cuadrado.Vsqr= extraer_mensaje (&i); //Extrae hasta siguiente ','ó']' /* ---- SEGUNDO SUBMENSAJE ----*/ //i debe quedar en siguiente a primera , trayec_cuadrado.Fipunto_sqr= extraer_mensaje (&i); /* ---- TERCER SUBMENSAJE ----*/ //i debe quedar en siguiente a segunda , trayec_cuadrado.lado_sqr= extraer_mensaje (&i);

Código fuente 223


//Cargar parámetros de cuadrado en array for (i=0;i<4;i++) /* Tramo recto */ orden_recibida[0]=trayec_cuadrado.Vsqr; orden_recibida[1]=0; orden_recibida[2]=trayec_cuadrado.lado_sqr; orden_recibida[3]=0; orden_recibida[4]=0; alojar_ORDEN_MOV(&COLA_MOV,crear_ORDEN_MOV(orden_recibida)); putsUART1("Recto alojado\n\r"); //Debug /* Tramo giro 90º */ orden_recibida[0]=0; orden_recibida[1]=trayec_cuadrado.Fipunto_sqr; orden_recibida[2]=0; orden_recibida[3]=90; orden_recibida[4]=0; alojar_ORDEN_MOV(&COLA_MOV,crear_ORDEN_MOV(orden_recibida)); putsUART1("Giro alojado\n\r");//Debug putsUART1("Cuadrado en cola\n\r"); FLAGSROBOT.mensajerecibido=0; break; case 10: //CREAR TRAYECTORIA CIRCUNFERENCIA i=1; while (mensaje[i-1]!='[') i++; //Recorro hasta el siguiente de [ //El mensaje es global trayec_circulo.Vcir= extraer_mensaje (&i); //Extrae hasta siguiente ','ó']' /* ---- SEGUNDO SUBMENSAJE ----*/ //i debe quedar en siguiente a primera , trayec_circulo.radio_cir= extraer_mensaje (&i); //Cargar parámetros de círculo en array orden /* Tramo recto */ orden_recibida[0]=trayec_circulo.Vcir; orden_recibida[1]=(int) (((float)trayec_circulo.Vcir)/(float)trayec_circulo.radio_cir*((float)180/PI)); orden_recibida[2]=(int) (2*PI*trayec_circulo.radio_cir);



orden_recibida[3]=360; orden_recibida[4]=0; alojar_ORDEN_MOV(&COLA_MOV,crear_ORDEN_MOV(orden_recibida)); putsUART1("Círculo en cola\n\r"); FLAGSROBOT.mensajerecibido=0; break; IFS0bits.U1RXIF = 0; //Restablecer flag //Fin rutina interrupcion RX //========================================================================= void __attribute__((interrupt, no_auto_psv)) _U1TXInterrupt(void) //========================================================================= /* Rutina de atención interrupción UART1 TX */ IFS0bits.U1TXIF = 0; //Restablecer flag //=========================================================================== void __attribute__((interrupt, no_auto_psv)) _MPWM1Interrupt(void) //=========================================================================== /* Rutina de atención interrupción PWM1 - una de tantas P1TMR match P1TPER */ IFS3bits.PWM1IF=0; // Restablecer flag //=========================================================================== void __attribute__((interrupt, no_auto_psv)) _MPWM2Interrupt(void) //=========================================================================== /* Rutina de atención interrupción PWM2 - una de tantas P2TMR match P2TPER */ IFS4bits.PWM2IF=0; // Restablecer flag /******************************************************************************/ /* ERRORES */ /******************************************************************************/ // Err1: reserva memoria para crear_ORDEN_MOV() // Err2: nueva orden con COLA_MOV llena MAX_ELEM_COLA_MOV // Err3: en extraer_ORDEN_MOV /******************************************************************************/ /* PROCEDIMIENTOS */

Código fuente 225


/******************************************************************************/ int main (void) unsigned int contador; volatile int z=0; /*Configuración de periféricos*/ OSCconfig(); IOConfig(); InitQEI(); InitPWM(); InitUART1(); InitTIMER1(); /*Habilito periféricos*/ HABILITAR_QEI1(); HABILITAR_QEI2(); HABILITAR_PWM_I(); HABILITAR_PWM_D(); HABILITAR_UART1(); /*Habilito interrupciones*/ HABILITAR_INTERRUP_RX1(); __delay_ms(100); iniciar_COLA (&COLA_MOV); //Pone a 0 los tres campos de COLA_MOV Cargar_var_defecto (); while (1) //Bucle principal Nop(); Iniciar_variables(); while (FLAGSROBOT.colamovvacia==1) Nop(); if (FLAGSROBOT.control_ON==1) /* Primer paso , inicializar las estructuras de datos PID */ /* Apuntar a los coeficientes */ PID_i . abcCoefficients = & abcCoefficient_i [0]; PID_d . abcCoefficients = & abcCoefficient_d [0]; /* Apuntar al historial de muestras del regulador */ PID_i . controlHistory = & controlHistory_i [0]; PID_d . controlHistory = & controlHistory_d [0]; /* Limpiar el historial y la salida del controlador */ PIDInit (& PID_i ); PIDInit (& PID_d ); Cargar_kCoeffs(); //Carga en array kp, ki y



kd en Q15 /* Derivar los coeficientes a,b, & c a partir de kp , ki & kd */ PIDCoeffCalc (& kCoeffs_i [0] , & PID_i ); PIDCoeffCalc (& kCoeffs_d [0] , & PID_d ); extraida=extraer_ORDEN_MOV(&COLA_MOV); FLAGSROBOT.movencurso=1; ejecutar_ORDEN_MOV(extraida); while (FLAGSROBOT.movencurso!=0) Nop(); //Aquí podría ir enviando datos para mejorar cadencia /* check for receive errors CODIGO EJEMPLO DS70188D RX UART */ //if(U1STAbits.FERR = 1) // //continue; // /* must clear the overrun error to keep uart receiving */ //if(U1STAbits.OERR = 1) // //U1STAbits.OERR = 0; //continue; // /* get the data */ //if(U1STAbits.URXDA = 1) // //ReceivedChar = U1RXREG; // APAGAR_TIMER1(); if (FLAGSROBOT.log_ON==1) putsUART1("Tiempo; POS1CNT_global; POS2CNT_global; Vbase_i; Vbase_d; Control_i; Vcontrol_d; Vi; Vd\r\n"); for(z=0; z<contador_variables; z++) //printf("%d; %d; %d; %d; %d\n",variables1[z][0], variables1[z][1], variables1[z][2],(int)calcularV(variables1[z][3]),(int)calcularV(variables1[z][4])); printf("%d; %d; %d; %d; %d; %d; %d; %d; %d\n",variables1[z][0], variables1[z][1], variables1[z][2],(int)variables1[z][3],(int)variables1[z][4], variables1[z][5], variables1[z][6], variables1[z][7], variables1[z][8]); __delay_ms(10); putsUART1("\n\r"); putsUART1("\n\r Kp_i; Ki_i; Kd_i\n\r"); printf("%.2f; %.2f; %.2f\n\r",Kp_i,Ki_i,Kd_i); putsUART1("\n\r Kp_d; Ki_d; Kd_d\n\r"); printf("%.2f; %.2f; %.2f\n\n\r",Kp_d,Ki_d,Kd_d); putsUART1("IEA_i; IEA_d; max_sobrepaso_i; max_sobrepaso_d; EA_max_i; EA_max_d\n\r"); printf("%.2f; %.2f; %.2f; %.2f; %.2f; %.2f\n\\r",IEA_i,IEA_d, max_sobrepaso_i, max_sobrepaso_d, EA_max_i, EA_max_d); putsUART1("============\n\r");

Código fuente 227


//Fin while //FIN DE MAIN //============================================================== // FUNCIONES DE USUARIO //============================================================== void PARAR_IZQUIERDA(void) PWM1A=0; // (0,0) Freno a GND PWM1B=0; DCI=2000; // Freno a tope return; void PARAR_DERECHA (void) PWM2A=0; PWM2B=0; DCD=2000; //Freno a tope return; void detener(void) PARAR_IZQUIERDA(); PARAR_DERECHA(); return; void hacia_delante(void) PWM1A=1; PWM1B=0; //Izquierda adelante PWM2A=1; PWM2B=0; //Derecha adelante return; void hacia_atras(void) PWM1A=0; PWM1B=1; //Izquierda atrás PWM2A=0; PWM2B=1; //Derecha atrás return; void spin_izquierda(void) PWM1A=0; PWM1B=1; //Izquierda atrás PWM2A=1; PWM2B=0; //Derecha adelante return;



void spin_derecha(void) PWM1A=1; PWM1B=0; //Izquierda adelante PWM2A=0; PWM2B=1; //Derecha atrás return; int CALCULAR_PULSOS (int mm) int pulsos=0; pulsos= mm*FACTOR_PULSOS_POR_MM; //Longitud_rueda*Factor_Reductora*CPR return (pulsos); void putUART1(char c) while ( U1STAbits.UTXBF); // wait while Tx buffer full U1TXREG = c; void putsUART1 (char* s)//( char *s) unsigned int i=0; while(s[i]) // loop until *s == ‘\0’, end of string putUART1(s[i++]); // send the character and point to the next one void rafaga_100(unsigned int num_destellos) unsigned int i; for (i=0;i<=num_destellos; i++) LATAbits.LATA4=1; __delay_ms(100); LATAbits.LATA4=0; __delay_ms(100); /********** FUNCIONES PILA DE ORDENES DE MOVIMIENTO ***************/ /* Es una cola FIFO mediante lista enlazada de órdenes de movimiento. La alternativa sería un buffer circular: http://es.wikipedia.org/wiki/Buffer_circular En el buffer los elementos son contiguos, y no se necesita indicar la posición del siguiente; Las órdenes son un tipo de dato estructura con campos. La cola es una estructura con dos punteros: - MOVsiguiente apunta al primer elemento - ULTIMO apunta al último elemento - Cuando la lista queda vacía debe activarse FLAGSROBOTS.pilamovvacia */ void iniciar_COLA (cola* COLA) COLA->inicial=NULL; COLA->final= NULL; COLA->numelem=0; FLAGSROBOT.colamovvacia=1; FLAGSROBOT.colamovllena=0;

Código fuente 229


putsUART1("Cola iniciada. Vacia\n\r"); ORDEN_MOV* crear_ORDEN_MOV (int orden_recibida[]) //en rutina de recepción, cargar parametros de comando MOV ORDEN_MOV* nueva_orden; nueva_orden=(ORDEN_MOV*)malloc(sizeof(ORDEN_MOV)); if (nueva_orden==NULL) putsUART1("ERR1"); return(0); nueva_orden->v_orden=orden_recibida[0]; nueva_orden->fipunto_orden=orden_recibida[1]; nueva_orden->S_orden=orden_recibida[2]; nueva_orden->fi_orden=orden_recibida[3]; nueva_orden->t=orden_recibida[4]; nueva_orden->sig=NULL; //nueva_orden->relleno=0; //Para ocupar 16 posiciones return (nueva_orden); void alojar_ORDEN_MOV (cola* COLA_AUX, ORDEN_MOV* nueva_orden) ORDEN_MOV* ultimo_actual; //pivote if(FLAGSROBOT.colamovllena) //menos enrevesado putsUART1("Err2\n\r"); return; if (FLAGSROBOT.colamovvacia) //anotar elemento como inicio y fin COLA_AUX->inicial=nueva_orden; else ultimo_actual=(COLA_AUX->final); //cargo el actual último (ultimo_actual->sig) =nueva_orden; // COLA_AUX->final=nueva_orden; (COLA_AUX->numelem)++; putsUART1("Nueva OM\n\r"); FLAGSROBOT.colamovvacia=0; if ((COLA_AUX->numelem)>=MAX_ELEM_COLA_MOV) FLAGSROBOT.colamovllena=1; putsUART1("Cola Mov llena\n\r"); ORDEN_MOV* extraer_ORDEN_MOV(cola* COLA_AUX) ORDEN_MOV* temporal; if((COLA_AUX->numelem)<=0) putsUART1("Err3\n\r");



return (NULL); temporal=COLA_AUX->inicial; (COLA_AUX->inicial)=(temporal->sig); //Paso a primer lugar el 2º (COLA_AUX->numelem)--; putsUART1("OM extraida\n\r"); FLAGSROBOT.colamovllena=0; if((COLA_AUX->numelem)<=0) FLAGSROBOT.colamovvacia=1; COLA_AUX->final=NULL; putsUART1("Cola vacia\n\r"); return(temporal); //OJO UNA VEZ USADO DEBE ELIMINARSE LA ORDEN EXTRAIDA //donde corresponda: free(ORDEN_MOV) void demo_cola (int orden_recibida[]) int i,j,numero; ORDEN_MOV* nueva_orden; j=10; while (!FLAGSROBOT.colamovllena) nueva_orden=crear_ORDEN_MOV (orden_recibida); alojar_ORDEN_MOV(&COLA_MOV,nueva_orden); printf("Ordenes COLA_MOV: %d\r\n",COLA_MOV.numelem); __delay_ms(5); for (i=0;i<5;i++) orden_recibida[i]+=j; j=j+10; //contador para ir cambiando el contenido de las órdentes de mov numero=0; while (!FLAGSROBOT.colamovvacia) extraida= extraer_ORDEN_MOV(&COLA_MOV); orden_recibida[0]=((extraida->v_orden)+numero); orden_recibida[1]=((extraida->fipunto_orden)+numero); orden_recibida[2]=((extraida->S_orden)+numero); orden_recibida[3]=((extraida->fi_orden)+numero); orden_recibida[4]=((extraida->t)+numero); free(extraida); Nop(); for(i=0;i<5;i++) printf("orden_recib %d = %d\n\r",(COLA_MOV.numelem+1),orden_recibida[i]); int extraer_mensaje (int* p_i) // Extrae el entero de la cadena de caracteres entre i y ',' ó ']' /* ----------DESCRIPCIÓN: ---------------------------------------------------*/ // Función que lee el array mensaje desde la posición apuntada por p_i hasta // que se encuentra un delimitador de submensaje: ',' ó ']'.

Código fuente 231


// Captura los caracteres (dígitos decimales), los ordena, añade \0 al fin // del array, se lo pasa a atoi y devuelve el enteroque representan. // NOTA: // atoi(cadena[]) con cadena: [espacios][signo]dato. ¡dato terminado en '\0'! // int i; int j; int dato_extraido=0; //char temporal[long_max]; char dato_mensaje[long_max]; i=*p_i; //necesito que los cambios en i sean globales if ((mensaje[i]==',')||(mensaje[i]==']')) //Campo V vacío->rotacion dato_extraido=0; // i queda en , else for(j=0;j<long_max;j++) //Limpio el array dato_mensaje[j]=0; j=0; while ((mensaje[i]!=',')&&(mensaje[i]!=']')&&(j<(long_max-1))) dato_mensaje[j]=mensaje[i]; j++; i++; //i queda en , y j en el num de caract válidos i++; //Hago que i quede en siguiente submensaje *p_i=i; //Saco el valor de i dato_extraido=atoi(dato_mensaje); return(dato_extraido); void ejecutar_ORDEN_MOV(ORDEN_MOV* orden_siguiente) int parametros[5]; float FactorDI; float t1; float S_para_Vi,Si_med; float S_para_Vd,Sd_med; V_orden=orden_siguiente->v_orden; Fipunto_orden=orden_siguiente->fipunto_orden; S_orden=orden_siguiente->S_orden; Fi_orden=orden_siguiente->fi_orden; t=orden_siguiente->t; free(orden_siguiente); printf("MOV[%d,%d,%d,%d,%d]\n\r", V_orden, Fipunto_orden, S_orden, Fi_orden,t); //Filtrado de casos: Vi_orden S_orden; Fipunto_orden Fi_orden; MISMO SIGNO if ((V_orden<0)||(S_orden<0)) V_orden=-abs(V_orden);



S_orden=-abs(S_orden); if ((Fipunto_orden<0)||(Fi_orden<0)) Fipunto_orden=-abs(Fipunto_orden); Fi_orden=-abs(Fi_orden); //Filtrado de valores if (V_orden> V_orden_MAX)V_orden=V_orden_MAX; if (V_orden< -V_orden_MAX) V_orden= -V_orden_MAX; if (Fipunto_orden>Fipunto_orden_MAX)Fipunto_orden=Fipunto_orden_MAX; if (Fipunto_orden<-Fipunto_orden_MAX)Fipunto_orden=-Fipunto_orden_MAX; if (t<0) t=-t; //t siempre >=0 //Decodificar el tipo de movimiento que se manda caso_movimiento_actual=0; if ((V_orden!=0)&&(Fipunto_orden==0)&&(S_orden!=0)) //Sólo es caso particular de GENERAL caso_movimiento_actual=3; //Recto por distancia, gestionado como GENERAL if ((V_orden!=0)&&(Fipunto_orden==0)&&(S_orden==0)&&(t!=0)) caso_movimiento_actual=2; //Recto por tiempo if ((V_orden!=0)&&(Fipunto_orden!=0)) //GENERAL caso_movimiento_actual=3; //Curvo general if ((V_orden==0)&&(Fipunto_orden!=0)&&(Fi_orden!=0)) caso_movimiento_actual=3; //Spin por ángulo, adaptado en general if ((V_orden==0)&&(Fipunto_orden!=0)&&(Fi_orden==0)&&(t!=0)) caso_movimiento_actual=5; //Spin por tiempo switch (caso_movimiento_actual) case 0: putsUART1("Movimiento no reconocido\r\n"); break; case 1: /*--- RECTO POR DISTANCIA ---*/ break; case 2: /*--- RECTO POR TIEMPO ---*/ break; case 3: /*--- CURVO GENERAL ---*/ putsUART1("MOV GENERAL\n\r"); Vi_orden=V_orden -(int)(Fipunto_orden*RADIANESporGRADOporBMED); Vd_orden=V_orden +(int)(Fipunto_orden*RADIANESporGRADOporBMED); Filtrado_Vi_Vd_orden();

Código fuente 233


if (S_orden !=0) //Mov general Si_orden= (2*S_orden*Vi_orden)/(Vi_orden+Vd_orden); Sd_orden= 2*S_orden-Si_orden; //(2*S_orden*Vd_orden)/(Vi_orden+Vd_orden); else //Spin Sd_orden= Fi_orden*RADIANESporGRADOporBMED*FACTOR_DESLIZAMIENTO_defecto; Si_orden= -Sd_orden; FactorDI=Vd_orden/Vi_orden; //Calcular_PREMOVE() //Aquí juzgo si tendremos TRAPECIO o TRIANGULO //El lado rápido acelera a ACELERACIÓN. El lento, proporcional. if (V_orden<0) putsUART1("General marchatras \n\r"); if (Fipunto_orden>0) //Vd_orden>Vi_orden Ad_mmps=-(A_mmps*(Vd_orden/Vi_orden)); Ai_mmps=-A_mmps; else Ad_mmps=-A_mmps; Ai_mmps=-(A_mmps*(Vi_orden/Vd_orden)); else if (V_orden>0) putsUART1("General adelante \n\r"); if (Fipunto_orden>=0) //Vd_orden>Vi_orden Ad_mmps=A_mmps; Ai_mmps=A_mmps*(Vi_orden/Vd_orden); else Ad_mmps=A_mmps*(Vd_orden/Vi_orden); Ai_mmps=A_mmps; else //(V_orden==0), SPIN if (Fipunto_orden>0) Ad_mmps=A_mmps; Ai_mmps=-A_mmps; else if (Fipunto_orden<0) Ad_mmps=-A_mmps; Ai_mmps=A_mmps; t1=Vi_orden/Ai_mmps;//fabsf(Vi_orden/Ai_mmps);



//T1 son s, igual para i que para d S_para_Vi=0.5*Vi_orden*t1; //fabsf(0.5*Vi_orden*t1); S_para_Vd=0.5*Vd_orden*t1; //fabsf(0.5*Vd_orden*t1); Si_med=0.5*Si_orden; Sd_med=0.5*Sd_orden; if (fabsf(Si_med)>fabsf(S_para_Vi)) perfil=TRAPECIO; S1_i=S_para_Vi; S1_d=S_para_Vd; S2_i=Si_orden-(2*S1_i); //Trapecio simétrico S2_d=Sd_orden-(2*S1_d); S3_i=S1_i; S3_d=S1_d; else perfil=TRIANGULO; S1_i=S2_i=Si_med; //Triángulo isósceles S1_d=S2_d=Sd_med; fase_perfil_i=ACELERANDO; fase_perfil_d=ACELERANDO; //pos_acumulada_i=0; //pos_acumulada_d=0; Vbase_i=0; Vbase_d=0; Vcontrol_i=0; Vcontrol_d=0; Incremento_Vbase_i=Ai_mmps*Delta_t; //Sumo en cada ciclo ACELERANDO Incremento_Vbase_d=Ad_mmps*Delta_t; //Sumo en cada ciclo ACELERANDO Vconsigna_i=Vbase_i+Vcontrol_i; Vconsigna_d=Vbase_d+Vcontrol_d; Desplazamiento_mm_i (S1_i,0); Desplazamiento_mm_d (S1_d,0); //MAX1CNT= CALCULAR_PULSOS ((int)S1_i); //MAX2CNT= CALCULAR_PULSOS ((int)S1_d); Gestionar_DCI (0); Gestionar_DCD (0); //DCI=0; //DCD=0; if (FLAGSROBOT.log_ON==1) Evaluar_pos1_abs(); Evaluar_pos2_abs(); Calcular_cinematica (&CINEMATICA_i, pos1_abs); Calcular_cinematica (&CINEMATICA_d, pos2_abs); Calcular_cinematica_ROBOT

Código fuente 235


(&CINEMATICA_i,&CINEMATICA_d, &VICBOT); Registrar_datos(); HABILITAR_INTERRUP_QEI1(); HABILITAR_INTERRUP_QEI2(); ENCENDER_TIMER1(); HABILITAR_INTERRUP_TMR1(); break; case 4: /*--- SPIN POR ÁNGULO ---*/ break; case 5: /*--- SPIN POR TIEMPO ---*/ break; return; float calcularV (int DC) //Da la velocidad estacionaria obtenida en lazo abierto, recto, con DC //Según regresión (1)en Vicbot.h //V con signo, extrapolo simétrico en DC<0 float V; if (abs(DC)<=(int)B2) V=0; else if (DC<-B2) V=A1*DC-B1; else V=A1*DC+B1; return (V); int calcularDC (float V) //Da el DC que en lazo abierto da velocidad V en mm/s //Según regresión (2)en VicBot.h //DC para cargar en registro (sólo positivo) MODIFICADO: tanto *como- int DC; if (V==0) DC=0; else if (V>0) DC=(int)(A2*V+B2); else if (V<0) DC=(int)(A2*V-B2); return (DC); int convertir_mmps_a_ppc (int mmps)



int ppc; ppc=(int) mmps*FACTOR_PULSOS_POR_MM * Delta_t; return (ppc); int convertir_ppc_a_mmps (int ppc) int mmps; mmps=(int) ppc/(FACTOR_PULSOS_POR_MM * Delta_t); return (mmps); void Desplazamiento_mm_i (int mm, int mm_origen) //Carga pulsos en QEI1 según magnitud y signo de desplazamiento //Para cargar valores absolutos, proporciono origen en mm int aux; aux=mm+mm_origen; if (mm>=0) //Conteo ascendente MAX1CNT=CALCULAR_PULSOS (aux); POS1CNT=mm_origen; MAX1CNT_COPIA=(int)MAX1CNT; //Lo uso para pos_acumulada else //Conteo descendente POS1CNT=CALCULAR_PULSOS (-aux); //En conteo descendente, cuando POS=0, carga POS=MAX. MAX1CNT=POS1CNT+1; MAX1CNT_COPIA=(int)POS1CNT; //Lo uso para pos_acumulada void Desplazamiento_mm_d (int mm, int mm_origen) //Carga pulsos en QEI2 según magnitud y signo de desplazamiento //Para cargar valores absolutos, proporciono origen en mm int aux; aux=mm+mm_origen; if (mm>=0) //Conteo ascendente MAX2CNT=CALCULAR_PULSOS (aux); POS2CNT=mm_origen; MAX2CNT_COPIA=(int)MAX2CNT; else //Conteo descendente POS2CNT=CALCULAR_PULSOS (-aux); //En conteo descendente, cuando POS=0, carga POS=MAX. MAX2CNT=POS2CNT+1; MAX2CNT_COPIA=(int)POS2CNT; void Gestionar_DCI (int valor_DCI) //Carga en el registro DCI velocidad y pone salidas según sentido

Código fuente 237


if (valor_DCI>=0) DCI=valor_DCI; PWM1A=1; PWM1B=0; else DCI=-valor_DCI; PWM1A=0; PWM1B=1; void Gestionar_DCD (int valor_DCD) //Carga en el registro DCD velocidad y pone salidas según sentido if (valor_DCD>=0) DCD=valor_DCD; PWM2A=1; PWM2B=0; else DCD=-valor_DCD; PWM2A=0; PWM2B=1; void Filtrado_Vi_Vd_orden(void) //Escala dentro de rango las velocidades, manteniendo su relación if (Vi_orden> V_orden_MAX) Vd_orden=Vd_orden*(V_orden_MAX/Vi_orden); Vi_orden=V_orden_MAX; if (Vd_orden> V_orden_MAX) Vi_orden=Vi_orden*(V_orden_MAX/Vd_orden); Vd_orden=V_orden_MAX; if (Vi_orden< -V_orden_MAX) Vd_orden=Vd_orden*(-V_orden_MAX/Vi_orden); Vi_orden= -V_orden_MAX; if (Vd_orden< -V_orden_MAX) Vi_orden=Vi_orden*(-V_orden_MAX/Vd_orden); Vd_orden= -V_orden_MAX; void Cargar_var_defecto (void) Kp_i= Kp_i_defecto; Ki_i= Ki_i_defecto; Kd_i= Kd_i_defecto;



Kp_d= Kp_d_defecto; Ki_d= Ki_d_defecto; Kd_d= Kd_d_defecto; FLAGSROBOT.activado=1; FLAGSROBOT.movencurso=0; FLAGSROBOT.control_ON=1; FLAGSROBOT.log_ON=1; A_mmps=ACELERACION_mmps_defecto; //------- PID ------- void Cargar_kCoeffs (void) kp_i=Kp_i; //Algoritmo U=PID(kp,ki,kd) en vez de (Kp,Ki,Kd,delta_t) ki_i=Ki_i*Delta_t; kd_d=Kd_i/Delta_t; kp_d=Kp_d; ki_d=Ki_d*Delta_t; kd_d=Kd_d/Delta_t; kCoeffs_i [0]=_Q15ftoi( kp_i/escala_K); kCoeffs_i [1]=_Q15ftoi( ki_i/escala_K); kCoeffs_i [2]=_Q15ftoi( kd_i/escala_K); kCoeffs_d [0]=_Q15ftoi( kp_d/escala_K); kCoeffs_d [1]=_Q15ftoi( ki_d/escala_K); kCoeffs_d [2]=_Q15ftoi( kd_d/escala_K); void Evaluar_pos1_abs(void) //Calcula la posicion absoluta con Pos_acumulada y POSx ó MAXx según signo Vx_orden if (Si_orden>=0) pos1_abs= (int) POS1CNT+ pos_acumulada_i; else pos1_abs= -((MAX1CNT_COPIA-(int)POS1CNT)+ pos_acumulada_i); void Evaluar_pos2_abs(void) if (Sd_orden>=0) pos2_abs= (int) POS2CNT+ pos_acumulada_d; else pos2_abs= -((MAX2CNT_COPIA-(int)POS2CNT)+ pos_acumulada_d);

Código fuente 239


void Calcular_cinematica (cinematica * bloque, int pos) //Realiza una iteración de cálculo cinemático de un bloque //La estructura debió ser cuidadosamente inicializada //Llamadas: para I: Calcular_cinematica (CINEMATICA_i, (int) POS1CNT); // para D: Calcular_cinematica (CINEMATICA_d, (int) POS2CNT); bloque->posicion_1=bloque->posicion; bloque->posicion= pos; //Aquí espera lectura de POSxCNT bloque->S=(float)(bloque->posicion-bloque->posicion_1)/FACTOR_PULSOS_POR_MM; bloque->V_1=bloque->V; bloque->V=(float) (bloque->S)*Inv_Delta_t; bloque->A=(float) ((bloque->V)-(bloque->V_1))*Inv_Delta_t; void Calcular_cinematica_ROBOT (cinematica * bloque_i, cinematica* bloque_d, cinematica_robot* ROBOT) //Realiza una iteración de cálculo cinemático del robot //La estructura debe ser cuidadosamente iniciada //Llamada Calcular_cinematica_ROBOT (CINEMATICA_i,CINEMATICA_d, VICBOT); ROBOT->V_1=ROBOT->V; ROBOT->V=(float) (bloque_i->V + bloque_d->V)/2; ROBOT->Fipunto= (float) ((bloque_d->V - bloque_i->V)*180/(b*PI)); ROBOT->A = (ROBOT->V- ROBOT->V_1)*Inv_Delta_t; void Saturacion_consignas (void) if (Vconsigna_i > V_orden_MAX) Vconsigna_i=V_orden_MAX; putsUART1("Vconsigna_i saturada +\n\r"); if (Vconsigna_i< -V_orden_MAX) Vconsigna_i=-V_orden_MAX; putsUART1("Vconsigna_i saturada -\n\r"); if (Vconsigna_d>V_orden_MAX) Vconsigna_d=V_orden_MAX; putsUART1("Vconsigna_d saturada +\n\r"); if (Vconsigna_d< -V_orden_MAX) Vconsigna_d=-V_orden_MAX; putsUART1("Vconsigna_d saturada -\n\r");



void Evaluar_indicadores (void) EVi=(float)(Vbase_i)-CINEMATICA_i.V; EVd=(float)(Vbase_d)-CINEMATICA_d.V; //EIA IEA_i+= fabsf(EVi*Delta_t); //Indicador de desempeño IEA_d+= fabsf(EVd*Delta_t); //Sobrepaso max //Izquierda if ((Vi_orden>=0)&&(EVi<0)&&(EVi< max_sobrepaso_i)) max_sobrepaso_i=EVi; else if ((EVi>0)&&(EVi> max_sobrepaso_i)) max_sobrepaso_i=EVi; //Derecha if ((Vd_orden>=0)&&(EVd<0)&&(EVd< max_sobrepaso_d)) max_sobrepaso_d=EVd; else if ((EVd>0)&&(EVd> max_sobrepaso_d)) max_sobrepaso_d=EVd; //Error absoluto max if (fabsf(EVi)>fabsf(EA_max_i)) EA_max_i=fabsf(EVi); if (fabsf(EVd)>fabsf(EA_max_d)) EA_max_d=fabsf(EVd); void Iniciar_variables (void) //Variables que se reinician para cada movimiento EVi=0; EVd=0; IEA_i=0; IEA_d=0; max_sobrepaso_i=0; max_sobrepaso_d=0; EA_max_i=0; EA_max_d=0; pos_acumulada_i=0; pos_acumulada_d=0; contador_variables=0;

Código fuente 241


tiempo=0; FLAGSROBOT.registro_datos_lleno=0; Reset_cinematica(&CINEMATICA_i); //Quitar si hay ordenes seguidas Reset_cinematica(&CINEMATICA_d); //Idem Reset_cinematica_robot(&VICBOT); //Idem void Registrar_datos (void) // Almacena en array // Requiere que código de llamada refresque al menos: // Evaluar_pos1_abs(); // Evaluar_pos2_abs(); // Calcular_cinematica (&CINEMATICA_i, pos1_abs); // Calcular_cinematica (&CINEMATICA_d, pos2_abs); // Calcular_cinematica_ROBOT (&CINEMATICA_i,&CINEMATICA_d, &VICBOT); variables1[contador_variables][0]=tiempo; variables1[contador_variables][1]=pos1_abs;//(int)POS1CNT// Saco directamente la total variables1[contador_variables][2]=pos2_abs;//(int)POS2CNT; variables1[contador_variables][3]=Vbase_i;//(int) DCI; //¡¡¡¡¡OJO A QUE EN PRIMERA ITERACION SEA 0!!! variables1[contador_variables][4]=Vbase_d;//(int) DCD; variables1[contador_variables][5]=Vcontrol_i; variables1[contador_variables][6]=Vcontrol_d; variables1[contador_variables][7]=CINEMATICA_i.V; variables1[contador_variables][8]=CINEMATICA_d.V; //VICBOT.Fipunto; contador_variables++; tiempo+=25; if(contador_variables>=200) FLAGSROBOT.registro_datos_lleno=1; void Reset_cinematica (cinematica *puntero) // Resetea historial de cinematica. Quitar de Iniciar_variables si Ordenes seguidas.. puntero->posicion=0; puntero->posicion_1=0; puntero->S=0; puntero->V=0; puntero->V_1=0; puntero->A=0; void Reset_cinematica_robot(cinematica_robot *puntero) puntero->V=0; puntero->V_1=0; puntero->Fipunto=0; puntero->A=0;



//============================================================ // FUNCIONES RECEPCIÓN Y GESTIÓN COMANDOS //============================================================ /* FORMATO ENVÍO: $MOV[ V ,Fipun, S , Fi , t ]# Descripción: comando de orden de movimiento. $WHO# Descripción: comando de orden de identificacion $SET[Var, Valor]# Descripción: comando para anotar parámetro Parámetros admitidos: Kp_i Ganancia proporcional PID izquierda Ki_i Ganancia integral PID izquierda Kd_i Ganancia derivativa PID izquierda Kp_d Ganancia proporcional PID derecha Ki_d Ganancia integral PID derecha Kd_d Ganancia derivativa PID derecha A_mmps Aceleración para rampas de velocidad $LOG ON# $LOG OFF# $CTRL ON# $CTRL OFF# $ASK[Var]# Descripción: comando consulta de parámetros o variables Parámetros admitidos: mismos que para SET $SQR[Vsqr,Fipunto_sqr,lado_sqr]# $CIR[Vcir,radio_cir]#

Índice de Ilustraciones 243


ÍNDICE DE ILUSTRACIONES Ilustración 1. Arquitectura sensor-control-actuador ....................................................................... 17 Ilustración 2. Esquema básico de arquitectura basada en pizarra ............................................... 18 Ilustración 3. Competencias verticales de arquitecturas clásicas ................................................... 20 Ilustración 4. Enfoque horizontal de la arquitectura Subsumption ............................................... 20 Ilustración 5. Capas de comportamiento de la arquitectura Subsumption ................................... 21 Ilustración 6. Robot XD Eurobot 2011 .............................................................................................. 33 Ilustración 7. Dimensiones en planta según normativa ................................................................... 34 Ilustración 8. Altura permitida según normativa ............................................................................ 35 Ilustración 9. Configuración Ackerman ........................................................................................... 36 Ilustración 10. Configuración tipo triciclo ........................................................................................ 37 Ilustración 11. Configuración diferencial ......................................................................................... 38 Ilustración 12. Robot AURIGA, universidad de Málaga ................................................................ 39 Ilustración 13. Configuración de ruedas síncronas .......................................................................... 39 Ilustración 14.Rueda sueca u omnidireccional ................................................................................. 40 Ilustración 15. Robot omnidireccional .............................................................................................. 40 Ilustración 16. Plataforma robótica diseñada .................................................................................. 45 Ilustración 17. Pieza P3 ...................................................................................................................... 47 Ilustración 18. Pieza P4 ...................................................................................................................... 47 Ilustración 19. Pieza P5 ...................................................................................................................... 48 Ilustración 20. Pieza P6 ...................................................................................................................... 48 Ilustración 21. Bloque motor ............................................................................................................. 49 Ilustración 22. Vista explosionada de un bloque motor ................................................................... 49 Ilustración 23. Esquema de un motor de corriente contínua. Fuente:[] ......................................... 51 Ilustración 24. Esquema circuito encóder motor ............................................................................. 54 Ilustración 25. Robot Edubot (CARTIF) .......................................................................................... 57 Ilustración 26. Distintos formatos de placa de ordenador embebido ............................................ 57 Ilustración 27. Ordenador embebido Raspberry Pi ......................................................................... 58 Ilustración 28. Diagrama de bloques del posicionamiento por odometría ..................................... 63 Ilustración 29. Entorno de desarrollo Proteus ISIS ......................................................................... 64 Ilustración 30. Placa electrónica de control de tracción ................................................................. 66 Ilustración 31. PCB para placa de control de tracción ................................................................... 67 Ilustración 32. Decapado de la PCB .................................................................................................. 69 Ilustración 33. Descripción de la placa de control de tracción. ...................................................... 70 Ilustración 34. Entrada/salida universal ........................................................................................... 72 Ilustración 35. Configuraciones posibles de la entrada/salida universal........................................ 72 Ilustración 36. Conector ICSP y jumpers para configuración de la placa ..................................... 73 Ilustración 37. Adaptador USB / serie CP2102, zócalo y jumpers para configuración de la placa

..................................................................................................................................................... 74 Ilustración 38. Módulo inalámbrico wixel ........................................................................................ 75 Ilustración 40. Placa de potencia Dual VNH2SP30 de Pololu ......................................................... 77 Ilustración 41. Circuito de aplicación típica para VNH2SP30. Datasheet pag. 8 .......................... 79 Ilustración 42. Placa de accionamientos en el entorno software Proteus-ARES ........................... 81 Ilustración 43. Placa de accionamientos, mandos y terminales de carga ....................................... 81 Ilustración 44. Batería Li-po de potencia con circuito monitor de tensión .................................... 84 Ilustración 45. Diagrama de la familia dsPIC. Fuente: web de Microchip (www.microchip.com)

..................................................................................................................................................... 89 Ilustración 46. Logo del entorno de desarrollo MPLAB IDE de Microchip .................................. 94 Ilustración 47. Estructura de archivos de un proyecto en MPLAB ............................................... 95



Ilustración 48. Flujo de datos a través de las herramientas software. Tabla 1-1 de la guía de uso del compilador. .......................................................................................................................... 96

Ilustración 49. Diagrama de bloques del oscilador. Fuente: figura 9-1 de DS70291E pag. 146 . 103 Ilustración 50. Esquema de configuración del oscilador con PLL ............................................... 105 Ilustración 51. Estructura típica de un puerto que comparte patilla con un periférico. Fuente:

Figura 1.1 de DS70291E ......................................................................................................... 106 Ilustración 52. Funciones asignadas a las patillas del dsPIC ....................................................... 108 Ilustración 53. Diagrama de bloques del Timer 1. Fuente: Figura 12.1 de DS70291 ................. 108 Ilustración 54. Multiplexado de la entrada U1RX del periférico UART desde distintas patillas

del micro. Fuente: Figura 11-2 de DS70291E ....................................................................... 110 Ilustración 55. Multiplexado de una patilla de salida desde varios periféricos. Fuente: Figura

11-3 de DS70291E ................................................................................................................... 111 Ilustración 56. Diagrama de bloques del módulo PWM de 6 canales (PWM1). Fuente: figura 16-

1 de DS70291 ........................................................................................................................... 113 Ilustración 57. Resolución y sincronismo según PxTMR y PxDCY en modo "Free running" y

prescaler 1:1. Fuente: Figura 14-15 de Family Reference Manual. .................................... 116 Ilustración 58. Lógica de comparación del ciclo activo (Duty Cycle). Fuente: figura 14-16 de

Family Reference Manual. ..................................................................................................... 116 Ilustración 59. Simulación con MPLABSIM de señales PWM para la configuración realizada.

.................................................................................................................................................. 117 Ilustración 60. Diagrama de bloques simplificado de un módulo QEI. Fuente: figura 15-2 de

DS70208. .................................................................................................................................. 120 Ilustración 61. Modelo para el programador del QEI .................................................................. 120 Ilustración 62. Propagación de señal a través de filtro. Fuente: Figura 4 DS93002A ................ 125 Ilustración 63. Señales del encóder en modo x4. Fuente: figura 5 de DS93002A. ....................... 126 Ilustración 64. Diagrama de bloques simplificado de puerto UART. Fuente: figura 17-1 de

DS70188D ................................................................................................................................ 127 Ilustración 65. Tabla de vectores de interrupción. Fuente: figura 7-1 de DS70291E ................. 132 Ilustración 66. Diagrama de flujo rutina principal ....................................................................... 137 Ilustración 67. Rutina de interrupción por recepción de caracteres en UART1 ....................... 139 Ilustración 68. Segmentos del perfil de velocidades en el control de posición. ............................ 143 Ilustración 69. Rutina de interrupción periódica por Timer 1 ..................................................... 144 Ilustración 70. Rutina de interrupción QEI por pulsos de encóder ............................................. 145 Ilustración 71. Implementación del algoritmo PID. ...................................................................... 146 Ilustración 72. Representación de 16 bits en coma fija Q15 ......................................................... 147 Ilustración 73. Vista lateral del modelo 3D del robot .................................................................... 151 Ilustración 74. Vista lateral del robot ............................................................................................. 151 Ilustración 75. Vista isométrica del robot ....................................................................................... 152 Ilustración 76. Imagen isométrica del modelo ............................................................................... 152 Ilustración 77. Vista en planta del modelo 3D del robot. .............................................................. 153 Ilustración 78. Vista en planta del robot. ....................................................................................... 153 Ilustración 79. Montaje de pruebas sobre maletín "universal trainer" ...................................... 155 Ilustración 80. Pulsos PWM para DC= 50% y distintos períodos ................................................ 156 Ilustración 81. Captura del video realizado con la prueba de módulos PWM y QEI ................ 157 Ilustración 82. Placa electrónica de control de tracción ................................................................ 158 Ilustración 83. Posición final de robot. Distancia: 1m. Velocidad 50% ....................................... 159 Ilustración 84. Posición final. Distancia 1m.V: 50% frenado activo ........................................... 160 Ilustración 85. Respuesta en lazo abierto a escalón del 15% DCmax. Libre .............................. 161 Ilustración 86. Respuesta en lazo abierto a escalón del 25% DCmax. Libre .............................. 162 Ilustración 87. Respuesta en lazo abierto a escalón del 38% DCmax. Libre .............................. 162 Ilustración 88. Respuesta en lazo abierto a escalón del 50% DCmax. Libre .............................. 163

Índice de Ilustraciones 245


Ilustración 89. Respuesta en lazao abierto a escalón del 75% DCmax. Libre ............................. 163 Ilustración 90. Respuesta en lazo abierto a escalón del 100% DCmax. Libre ............................. 164 Ilustración 91. Respuesta en lazo abierto a escalón del 15% DCmax. En carga ......................... 164 Ilustración 92. Respuesta en lazo abierto a escalón del 25% DCmax. En carga ......................... 165 Ilustración 93. Respuesta en lazo abierto a escalón del 38% DCmax. En carga ......................... 165 Ilustración 94. Respuesta en lazo abierto a escalón del 50% DCmax. En carga ......................... 165 Ilustración 95. Respuesta en lazo abierto a escalón del 75% DCmax. En carga ......................... 166 Ilustración 96. Respuesta en lazo abierto a escalón del 100% de DCmax. En carga .................. 166 Ilustración 97. Velocidad estacionaria frente a accionamiento. Libre ......................................... 168 Ilustración 98. Velocidad estacionaria frente a accionamiento . En carga .................................. 168 Ilustración 99. Lazo de control de velocidad. ................................................................................. 169 Ilustración 100. Prueba 1 de ajuste de parámetros PID. ............................................................... 173 Ilustración 101. Prueba 2 de ajuste de parámetros PID ................................................................ 173 Ilustración 102. Prueba 3 de ajuste de parámetros PID ................................................................ 174 Ilustración 103. Prueba 4 de ajuste de parámetros PID ................................................................ 174 Ilustración 104. Prueba 5 de ajuste de parámetros PID ................................................................ 175 Ilustración 105. Prueba 6 de ajuste de parámetros PID ................................................................ 175 Ilustración 106. Prueba 7 de ajuste de parámetros PID ................................................................ 176 Ilustración 107. Prueba 8 de ajuste de parámetros PID ................................................................ 176 Ilustración 108. Prueba 9 de ajuste de parámetros PID ................................................................ 177 Ilustración 109. Prueba 10 de ajuste de parámetros PID .............................................................. 177 Ilustración 110. Prueba 11 de ajuste de parámetros PID .............................................................. 178 Ilustración 111. Prueba 12 de ajuste de parámetros PID .............................................................. 179 Ilustración 112. Prueba 13 de ajuste de parámetros PID .............................................................. 179 Ilustración 113. Comparación entre gobierno en lazo abierto y ajuste del control propuesto ... 183

Índice de Tablas 247


ÍNDICE DE TABLAS Tabla 1. Prestaciones del VNH2SP30 ................................................................................................ 78 Tabla 2. Cables eléctricos ................................................................................................................... 85 Tabla 3. Resumen de características del dsPIC33FJ64MC802 de Microchip ............................... 91 Tabla 4. Diagrama de bloques del dsPIC33FJ64MC802. Fuente: Figura 1-1 DS70291E pag.16

................................................................................................................................................... 100 Tabla 5. Asignación de patillas del dsPIC por sistemas ................................................................. 107 Tabla 6. Registro QEIxCON de configuración del QEI. Fuernte: Registro 15-1 de DS70208 ... 121 Tabla 7. Registro DFLTxCON de control del filtro digital para QEI. Fuente: registro 15-2 de

DS70208. ................................................................................................................................... 122 Tabla 8. Registro UxMODE. Fuente: registro 17-1 de DS70188D ............................................... 128 Tabla 9. Registro UxSTA de control y estado de UART . Fuente: registro 20-2 de DS70291E 129 Tabla 10. Interrupciones utilizadas en las aplicaciones de control del robot .............................. 135 Tabla 11. Comando orden de movimiento ...................................................................................... 140 Tabla 12. Comando anotar variables .............................................................................................. 141 Tabla 13. Comando extraer variables ............................................................................................. 141 Tabla 14. Comandos de modo .......................................................................................................... 141 Tabla 15. Comandos trayectoria básica .......................................................................................... 142 Tabla 16. Resumen de pruebas. Escalón lazo abierto sin carga .................................................... 167 Tabla 17. Resumen de pruebas. Escalón lazo abierto en carga .................................................... 168 Tabla 19. Costes del material electrónico (euros) .......................................................................... 185 Tabla 20. Coste de los componentes mecánicos del robot (euros) ................................................ 186 Tabla 21. Coste de los materiales eléctricos del robot ................................................................... 186 Tabla 22. Resumen de costes en materias primas y componentes (euros) ................................... 186 Tabla 23. Costes de amortización .................................................................................................... 187 Tabla 24. Costes por licencias informáticas .................................................................................... 187 Tabla 25. Coste por hora de ingeniero ............................................................................................ 188 Tabla 26. Esfuerzo y coste de M.O. asociados al robot .................................................................. 189 Tabla 27. Costes indirectos y generales ........................................................................................... 190 Tabla 28. Costes totales del proyecto .............................................................................................. 190

Índice de Ecuaciones 249


ÍNDICE DE ECUACIONES

Ecuación 1. Multiplicación MAC ...................................................................................................... 99 Ecuación 2. Frecuencia de oscilador ............................................................................................... 105 Ecuación 3. Resolución de módulo PWM ....................................................................................... 114 Ecuación 4. Configuración del período PWM ................................................................................ 115 Ecuación 5. Tamaño de pulso de encóder mínimo ......................................................................... 125 Ecuación 6. Ajuste de filtro software para módulo QEI ............................................................... 125 Ecuación 7. Cálculo del generador de tasa de bits ......................................................................... 130 Ecuación 8. Composición de la consigna de velocidad ................................................................... 170 Ecuación 9. Expresión de acción de control PID en términos de sus componentes .................... 171 Ecuación 10. Integral de error absoluto .......................................................................................... 172

Referencias 251


REFERENCIAS

[1] EUROBOT

http://www.eurobot.org/

[2] Planète Sciences

http://www.planete-sciences.org/

[3] Alcabot-Hispabot

http://asimov.depeca.uah.es/robotica/

[4] Asociación de Microbótica de la Universidad de Valladolid (AMUVA)

http://www.eii.uva.es/amuva

[5] ROBOLID

http://www.robolid.net

[6] Robot Shakey

http://www.ai.sri.com/shakey/

[7] Hayes-Roth

http://en.wikipedia.org/wiki/Rick_Hayes-Roth

[8] R.A. Brooks, A robust layered control system for a mobile robot, IEEE journal of Robotics and Automation, Vol. RA-2 No. 1, pp 14-23, marzo 1986

[9] Robot CUBE

http://www.iearobotics.com/personal/juan/proyectos/cube-2.0/cube.html#uno

[10] Proyecto R4P:Robot cuadrúpedo libre

http://www.r4p.es/

[11] Robot Melanie III

http://www.mundobot.com/projects/melanie/v3/spmelanie3.htm



[12] Equipo XD-Francia Eurobot 2011-08-23

http://www.xevel.fr/blog/

[13] Ollero Baturone, A. (2001). ROBÓTICA. Manipuladores y Robots Móviles. Marcombo.

[14] Aluminio

http://es.wikipedia.org/wiki/Aluminio

[15] María José González (2001). Magnetismo y electricidad. Tecnología Industrial II. Departamento de tecnología.IES Dionisio Aguado.

[16] Pololu

http://www.pololu.com/catalog/product/1443

[17] Player Stage

http://playerstage.sourceforge.net

[18] OpenCV

http://opencvlibrary.sourceforge.net/

[19] Raspberry Pi

http://www.raspberrypi.org/

[20] VNH2SP30 dual MOSFETmotor driver

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00043711.pdf

[21] Microchip Technology Inc.

http://www.microchip.com

[22] 16-Bits Language Tools Libraries (DS51456G). Microchip Tecnology Inc. (24-01-2012).

http://ww1.microchip.com/downloads/en/DeviceDoc/51456G.pdf

[23] 16-Bits Language Tools Getting Started (DS70094E). Microchip Technology Inc. (24-01-2012).

http://ww1.microchip.com/downloads/en/DeviceDoc/70094E.pdf

Referencias 253


[24] MPLAB® Assembler, Linker and Utilities for PIC24 MCUs and dsPIC® DSCs User.s Guide (DS51317). Microchip Tecnology Inc. (24-01-2012).

http://ww1.microchip.com/downloads/en/DeviceDoc/51317J.pdf

[25] MPLAB C Compiler for PIC24 MCUs and dsPIC® DSCs User.s Guide (DS51284). Microchip Technology Inc. (24-01-2012).

http://ww1.microchip.com/downloads/en/DeviceDoc/51284H.pdf

[26] dsPIC33FJ32MC302/304, dsPIC33FJ64MCX02/X04 and dsPIC33FJ128MCX02/X04 Data Sheet ( DS70291G). Microchip Technology Inc. (24-01-2012).

http://ww1.microchip.com/downloads/en/DeviceDoc/70291G.pdf

[27] dsPIC33F Family Reference Manual . Microchip Tecnology Inc. (24-01-2012).

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2573

[28] Measuring Speed and Position with the QEI Module (DS93002A). Jorge Zambada. Microchip Technology Inc. (24-01-2012).

http://ww1.microchip.com/downloads/en/DeviceDoc/93002A.pdf

[29] GDB remote serial protocol.

http://sourceware.org/gdb/onlinedocs/gdb/

[30] CE019. Proportional Intergral Derivative (PID) controllers & closed loop control. Microchip Technology Inc. (24-01-2012).

http://www.microchip.com/TechDoc.aspx?type=CodeExamples&ctl00_MainContent_DocListGridChangePage=20

[31] Bucela, Tim (1997). Servo Control of a DC-Brush Motor. AN532 (DS00532C) (24-01-2012).

http://ww1.microchip.com/downloads/en/AppNotes/00532c.pdf

diseño y construcción de una plataforma robótica polivalente para eurobot

Documents