1

Arquitectura Robótica con Orientación Didáctica para Ingeniería

CATEGORÍA: INVESTIGACIÓN SOBRE LA EDUCACIÓN SUPERIOR

2

Arquitectura Robótica con Orientación Didáctica para Ingeniería

Resumen— Se propone una arquitectura robótica con orientación didáctica para el

estudiante de ingeniería; se proporcionan detalles del diseño implementado, buscando

promover el aprendizaje a través del proceso de construcción, modificación y uso de los

sistemas electrónico, de control y de comunicación descritos para el robot.

Palabras Clave— Diseño, robot, arquitectura robótica, didáctica, ingeniería.

1 JUSTIFICACIÓN

La integración de recursos didácticos con aplicaciones de robótica, ha

demostrado su capacidad y flexibilidad para promover la adquisición de significados e

interpretaciones personales de las necesidades sociales y la tecnología actual en

estudiantes de diversas instituciones de todo el orbe (Alimisis, Moro, Arlegui, Pina,

Frangou, & Papanikolau, 2007). Basando su metodología en la resolución de problemas

que implican la construcción, programación y control de modelos tangibles (robots) los

alumnos ejercitan la habilidad de relacionar sus conocimientos y experiencias previas

para dotar a los modelos de la comunicación, la percepción y las acciones necesarias

para su exitosa interacción con el medio físico que le rodea; lo anterior enriquece la

experiencia del participante y propicia además el trabajo de equipos multidisciplinarios

para la consecución de un objetivo común (Aliane & Bemposta, 2008).

Si bien existen numerosas propuestas comerciales - por ejemplo (Lego, 2012) -

para la promoción del aprendizaje a través de la robótica, el enfoque generalizado es

proporcionar productos de “uso fácil”, que permitan al usuario enfocarse en las tareas

a programar y no en los principios que soportan el funcionamiento del robot mismo.

3

Este sin duda es un enfoque importante en el proceso de aprendizaje, pero también

resulta importante para los estudiantes de ingeniería conocer el principio de

funcionamiento de los diversos componentes de un robot y la forma en que se

relacionan. Esto último se logra plenamente por la experiencia adquirida durante el

proceso de construcción o modificación del robot o sus componentes (Alimisis, 2009),

en el que aparecen problemas que generalmente los textos didácticos no abordan con

amplitud, y los productos comerciales intentan evitar al usuario.

En mi experiencia docente, conocer los entresijos de cualquier arquitectura

robótica (estructura lógica y física del robot), a tal grado de ser capaz de modificarla

conscientemente, constituye todo un reto y una experiencia de aprendizaje importante

para cualquier estudiante de ingeniería, ya que confluyen una cantidad de

conocimientos y habilidades considerables. Desafortunadamente, no todas las

universidades cuentan con robots destinados a ser intervenidos por sus estudiantes,

por tal motivo, los esfuerzos de este trabajo van dirigidos en este sentido.

2 PLANTEAMIENTO DEL PROBLEMA

Con el panorama anterior se plantea el objetivo del presente trabajo:

Diseñar e implementar una arquitectura robótica orientada hacia actividades

didácticas de ingeniería, a través de la construcción, uso y modificación de la misma.

Así también se plantean las siguientes particularidades:

1. Diseñar un sistema electrónico para el robot que incluya el uso de diversos

sensores, actuadores y sistemas de comunicación.

2. Diseñar o seleccionar diseños de tarjetas electrónicas de control para

sensores y actuadores, y para los sistemas de comunicación.

4

3. Diseñar la arquitectura para el software de control.

4. Implementar un prototipo para pruebas.

3 REVISIÓN BREVE DE LOS ELEMENTOS DE UNA ARQUITECTURA ROBÓTICA

La arquitectura de un robot (Ollero Baturone, 2007) describe los diversos

componentes de su estructura lógica y física, así como las interrelaciones existentes

entre los mismos: desde la parte estructural que impacta su desenvolvimiento

cinemático, el sistema de control de bajo nivel (sensores, actuadores, reacciones de

control (Kelly & Santibañez, 2003) ), hasta aspectos de la estructura de un

comportamiento claramente inteligente dentro de su medio ambiente (Russell, 2004).

3.1 Morfología del robot.

Es posible clasificar a los robots en dos grandes categorías, robots móviles y

robots manipuladores. Los primeros presentan típicamente alguna estas

configuraciones: Triciclo clásico, Ackerman, Diferencial o Skid Steer (Ollero Baturone,

2007). Para el caso de los manipuladores algunas configuraciones recurrentes son:

Cartesiana, Cilíndrica, Polar, Scara, entre otras. La morfología determina su

comportamiento cinemático, es decir la relación existente entre la posición o velocidad

de sus articulaciones (determinada por motores u otros actuadores) y su posición,

orientación y velocidades asumidas dentro del ambiente donde se desenvuelve.

3.2 Sensores y actuadores

3.2.1 Sensores

Los sensores dotan de “sentidos” al robot, le permiten percibir diferentes

fenómenos (fuerza, distancia, temperatura, colisión, contacto, iluminación, etc.) de su

5

entorno al convertirlos en señales eléctricas (Bolton 2006), (Angulo Usategui, Romero

Yesa, & Angulo Martínez, 2002).

Las señales entregadas por los sensores requieren ser acondicionadas y

posiblemente digitalizadas para su procesamiento por el sistema de control, por lo que

casi siempre los sensores van acompañados de elementos auxiliares como pueden ser

módulos de linealización, escalado, desplazamiento, conversión analógica a digital, por

citar algunos. Estos módulos además pueden tener implementaciones en hardware y/o

software.

3.2.2. Actuadores.

Los actuadores permiten al robot modificar su entorno a través de movimientos o

acciones de control sobre las variables percibidas. Existen actuadores, hidráulicos,

mecánicos, neumáticos y eléctricos. Para los fines de este trabajo, destacan dentro de

los actuadores eléctricos, diferentes tipos de motores como los de corriente directa,

servomotores y motores a pasos (Bolton 2006).

3.3 Arquitectura de software.

Al igual que en otros ámbitos, en el mundo del software, “arquitectura es

equivalente a diseño en el más alto nivel” (Braude, 2005). En su obra, Braude indica las

bondades que se buscan en una arquitectura de software (tabla1).

Tabla 1. Metas de diseño seleccionadas (Braude, 2005)

Extensión. Facilidad para la adición de nuevas características.

Cambio. Facilidad para cambios en los requerimientos.

Sencillez. Fácil comprensión e implementación.

Eficiencia. Alta velocidad en ejecución y compilación y tamaño pequeño de tiempo y código.

En el mismo trabajo, el autor describe algunas clasificaciones tradicionales,

como: Arquitectura de flujos de datos, Componentes independientes, Máquinas

Virtuales, Arquitecturas de almacenamiento y Arquitectura de capas.

6

3.4 Sistemas de comunicación

La tendencia actual de sistemas de comunicación omnipresentes, obliga al

docente y al estudiante de ingeniería a involucrarse en estas tecnologías. Existen

diversas tecnologías de comunicación como por ejemplo, Radio Frecuencia, Infrarrojo,

Bluetooth, I2C, Ethernet, Serial (Bolton 2006).

Para los fines de este trabajo no es indispensable conocer los fundamentos de

cada protocolo, ya que existen circuitos integrados y tarjetas electrónicas que

encapsulan la operación de bajo nivel (Arduino, 2013).

3.5 Sistemas de Control

Si bien hasta hace pocos años, implicaba un alto costo (temporal y económico)

implementar un sistema de control para un robot de tal forma que fuera capaz de

realizar diversas tareas programadas, en la actualidad la proliferación de

microcontroladores, microprocesadores y plataformas de desarrollo, simplifican el

trabajo y reducen costos de gran manera. Así tenemos plataformas como Arduino

(Arduino 2013), ChipKit (Microchip, 2013), y RaspBerry Pi (RaspBerry Pi, 2013), entre

otras.

4 DESARROLLO METODOLÓGICO.

La metodología de diseño se apega a la descrita por el enfoque mecatrónico

(National Instruments Corporation, 2013), que se resume en la figura 1.

Sistema

mecánico

Sistema electrónico

Sistema mecatrónico

7

Figura 1. Diseño concurrente de los diversos sistemas de un dispositivo mecatrónico.

La idea básica es un proceso de diseño concurrente y sinérgico de los sistemas

electrónico, mecánico, de cómputo y de control soportado generalmente por

herramientas CAD y prototipos virtuales. Los pasos a seguir dentro de este diseño

concurrente son los indicados en la figura 2 (Bolton 2006). La etapa 1 ha quedado

descrita con la justificación y los objetivos, las etapas 2 y 3 se detallan en los apartados

4.1 y 4.2, respectivamente, las etapas 4 y 5 se describen en la sección de resultados, ya

que los diseños en sí, son los productos de este trabajo.

Figura 2. Etapas del proceso de diseño.

4.1 Establecimiento de especificaciones

La orientación didáctica pretendida para el diseño robot, dicta la preferencia de

incluir sensores, actuadores, sistemas de comunicación y de control de diversa

naturaleza, más que perseguir un diseño adecuado para algún otro fin específico. Con

1. Detección de necesidades

2. Establecimiento de especificaciones

3. Diseño a nivel de sistema

4. Diseño detallado

5. Prototipo para evaluación del sistema

8

esta premisa, el robot es un móvil con configuración diferencial, que soporta un brazo

manipulador Scara y que se controla desde un computador anfitrión; este último puede

funcionar como un puente para delegar el control a un dispositivo móvil.

4.2 Diseño a nivel de sistema

La figura 3 muestra un bosquejo del sistema: un brazo manipulador montado

sobre un robot móvil, que se comunica mediante RF (radiofrecuencia) o Bluetooth a un

computador anfitrión, el cuál puede comunicarse a su vez con otros elementos de

cómputo. El presente reporte no abarca la programación y comunicación de estos

últimos elementos.

Figura 3. Esquema general del sistema

La parte móvil del robot adopta una configuración diferencial, la cual

contempla sólo dos ruedas para controlar su desplazamiento y rotación; esta

configuración presenta como ventaja la facilidad de asimilación de su modelo

cinemático, como se observa en la figura 4

9

Figura 4. Configuración diferencial.

Sobre la parte móvil se ubica un brazo manipulador, para el cual se ha

seleccionado la configuración Scara (figura 5), que se compone por tres

articulaciones. Las primeras dos articulaciones (hombro y codo) son rotativas, y

proporcionan libertad sobre el plano (x, y), la tercera articulación (muñeca) es de

desplazamiento para manipular la coordenada z. En el extremo del tercer eslabón se

localizan a manera de efector unas pinzas para las tareas de manipulación.

Figura 5. Ejemplo de manipulador con configuración Scara.

X

Y V r o b o t

X c

Y c

q

w

10

Con esta base cinemática, la figura 6 muestra el diagrama a bloques para el

sistema electrónico, que tiene como elementos de control un par de tarjetas Arduino

Uno (figura 9). El diseño contempla la utilización de motores a pasos bipolares, motores

a pasos unipolares y servomotores, entradas para 11 sensores digitales y para 4

sensores analógicos, así como módulos para la comunicación con el computador

anfitrión.

Figura 6. Diagrama a bloques del diseño propuesto para el sistema electrónico.

11

El software de control del sistema electrónico, adoptará la arquitectura mostrada

en la figura 7. Se observa que lo componen dos partes principales, el código que corre

en el computador anfitrión y el código que corre en las tarjetas Arduino del robot

(firmware).

La comunicación entre el robot y el computador anfitrión será por radiofrecuencia

o por Bluetooth, ambas con base serial. Se ha diseñado un protocolo conformado por

bloques de 4 bytes desde el computador anfitrión hacia el robot, y respuestas por parte

del robot de 2 bytes. La tabla 2, muestra la organización de estos bloques. Para cerrar

esta sección, la figura 8 muestra los diferentes protocolos de comunicación pretendidos

a través del sistema.

Figura 7. Arquitectura del sistema de control.

12

Tabla 2. Organización de los bloques de comunicación entre el computador anfitrión y el Robot

Computador - robot

Byte 0

Byte 1 Byte 2 Byte 3

Nibble Alto Nibble Bajo

Tipo de comando (Lectura de sensor,

lectura de estado de actuador, configuración de actuador, comandos de

sincronización de

comunicación)

Identificación del

Actuador/Sensor

Número de pulsos (motores a

pasos), velocidad (servomotores)

Número de pulsos

(motores a pasos), ángulo (servomotores)

Frecuencia de operación (motores a

pasos)

Robot-Computador

Byte 0 Byte 1

Dato Solicitado, entero 16 bits (Byte bajo) Dato Solicitado, entero 16 bits (Byte alto)

Bluetooth, Serial Serial RF, Serial I

2C

Ethernet Bluetooth

Figura 8. Sistema de comunicación.

5 RESULTADOS

5.1 Diseño detallado

5.1.1 Sistema electrónico

La asignación de terminales para las tarjetas Arduino Uno (figura 9), en modo

esclavo y amo se muestran en las tablas 3 y 4. Si bien, pudo emplearse en el diseño

sólo una tarjeta con mayor número de terminales, se optó por un par de tarjetas Uno

para mostrar el protocolo de comunicación I2C.

A r d u i n o U n o A m o

A r d u i n o U n o

E s c l a v o

T r a n s c e p t o r d e l

C o m p u t a d o r A n f i t r i ó n

T r a n s c e p t o r d e l r o b o t

C o m p u t a d o r a n f i t r i ó n

D i s p o s i t i v o s m ó v i l e s

13

Figura 9. Tarjeta Arduino Uno.

Tabla 3. Asignación de terminales para la tarjeta Arduino esclava

Motores a Pasos

Sentido de

Giro

Habilitación Reloj Paso

(H/F)

Motor Rueda Izquierda D7 D0 D5

D13

Motor Rueda Derecha D8

Motor Hombro D9 D1

D6 Motor Codo D10 D2

Motor muñeca D11 D3

Servomotores

Pulso

Motor Pinzas 4

Motor1 Sensor de

distancia 12

Motor2 Sensor de

distancia

Comunicación I2C

SDA A4

SDC A5

14

Tabla 4. Asignación de terminales para la tarjeta

Arduino ama

Sensores Digitales

Terminales de entrada D2-D12

Sensores Analógicos

Terminales de entrada D2-D12

Comunicación I2C

SDA A4

SDC A5

Comunicación Serial

RX D0

TX D1

La tabla 5 muestra los tipos de sensores seleccionados para el prototipo, y la

figura 10 muestra el aspecto de algunos de ellos. Algunos como el sensor de distancia

y el magnético no requieren tarjetas electrónicas, los demás muestran su conexión

típica en la hoja de datos.

Tabla 5. Sensores seleccionados

Entrada Variable Modelo seleccionado

Analógica Temperatura LM35

Analógica Fuerza FlexiForce

Analógica Distancia GP2Y0A02YK (Sharp)

Analógica Campo Magnético Dispositivo 1108

(Phidgets)

Digital Reflexión QRD 1114 (Fairchild)

Digital Contacto Interruptor de palanca

Digital Inclinación (booleana) C-7231 (Fadisel)

(a) (b) (c) (d) (e)

Figura 10. a)Sensor de temperatura LM35, b) Sensor de fuerza FlexiForce, c) Sensor de reflexión QRD 114 , d)Sensor magnético, e) Sensor de distancia.

15

Los motores seleccionados se muestran en la figura 11. Las tarjetas para el

control de los motores a pasos están basadas en los integrados L297 y L298, este

último para el caso de motores bipolares. El integrado L297 comprende la circuitería

para implementar la lógica de control de motores a pasos unipolares o bipolares. El

integrado L298 contiene dos puentes H, con él es posible controlar motores a pasos

bipolares de hasta 2 Amperios. Para la etapa de potencia de las tarjetas para

unipolares, se emplean arreglos de transistores IRFZ44N. Los detalles del diseño de

estas tarjetas se pueden obtener de la hoja de datos del integrado L297.

Figura 11. a) Motor a pasos bipolar, modelo 42BYGHW811; b) Motor a pasos unipolar modelo PM42L-048-17; c) Servomotor, modelo HK15288A empleado en las pinzas, modelo HK15178 empleado para

rotar los sensores de distancia.

5.1.2 Sistema de comunicación.

Las tarjetas Arduino, se comunican entre sí empleando el protocolo I2C, el cual

viene incluido en la biblioteca Wire. Este protocolo se emplea comúnmente para

comunicar microcontroladores y sus periféricos en sistemas embebidos, y emplea 2

líneas de comunicación, SDA (data line implementada en el pin A4) y SCL (clock line,

implementada en el pin A5). Una de las tarjetas trabaja en modo amo y la otra en modo

esclavo.

( a ) ( b) ( c )

16

.

Por otra parte, con respecto a la comunicación entre el robot y el computador, se

han seleccionado tarjetas de RF y de Bluetooth. Los módulos de comunicación RF

(figura 12), tienen como elemento medular los circuitos integrados TRM-433-LT y SDM-

USB-QS1-S ambos de LINX; el primero de ellos implementa propiamente la

comunicación RF y el segundo es un módulo USB. En el caso de la comunicación

Bluetooth, se emplea el módulo HC-06 de la firma Wavesen, el cual sólo puede asumir

el rol de esclavo (figura 13).

Figura 12. Módulos de comunicación, basados en productos LINX

Figura 13. Módulos HC-06 para comunicación Bluetooth.

5.1.3 Software

Las figuras 14 y 15 muestran con detalle el diagrama de clases del software. En

la figura 15 se describe las clases Sensor y sus clases derivadas SensorDigital y Sensor

Analógico, así como la clase base Actuador y sus clases derivadas MotorPAP y

ServoMotor. En la figura 15 se muestra la clase Comunicación y la clase Robot. Esta

17

última está compuesta por todas las anteriores. También se muestran las

enumeraciones que fungen como propiedades de sensores y actuadores

Figura 14. Detalle de las clases Sensor, Actuador y clases derivadas.

18

Figura 15. Detalle de las clases Comunicación, Robot y enumeraciones empleadas.

19

5.2 Prototipo de prueba

Se construyeron tarjetas de control para los motores a pasos unipolares y

bipolares, la figura 16, muestra a un ejemplo de estas.

Figura 16. Tarjeta construida para el control de motores unipolares basada en el integrado L297.

Se crearon dos bibliotecas en el firmware, una para implementar la comunicación

serial de manera sincronizada, y otra para traducir el protocolo descrito, como ilustra la

figura 17. El módulo restante del firmware, el de ejecución de comandos quedó

implementado en el programa principal. Se empleó el paradigma de la programación

orientada a objetos.

Figura 17. Bibliotecas creadas para el firmware

Por otra parte, el software que ejecuta el computador anfitrión, está elaborado

con C#. Este entorno de desarrollo permite una comunicación serial fácilmente a través

del uso del componente SerialPort.

20

El código del computador anfitrión está organizado en clases dentro de la

biblioteca Robot.dll, de tal forma que el usuario pueda controlar al robot por medio de

esta última al incluirla en sus propios programas escritos. A manera de ejemplo, en la

figura 18, se muestra la interfaz empleada para pruebas. Finalmente la figura 19,

muestra una imagen del primer prototipo construido.

Figura 18. Interfaz creada para probar la biblioteca robot.dll.

21

Figura 19. Primer prototipo construido

6 CONCLUSIONES

Se ha presentado el diseño y desarrollo de un robot con una arquitectura

orientada hacia actividades didácticas para estudiantes de ingeniería. Se ha propuesto

un diseño que involucra diversos sensores, actuadores y sistemas de comunicación. Se

han implementado diseños de tarjetas controladoras para motores a pasos. Se ha

organizado el software de control en bibliotecas para el robot y para el computador

anfitrión, y se ha probado el diseño con la implementación de un prototipo.

Queda como trabajo futuro la implementación del control del robot desde

dispositivos móviles, empleando al computador anfitrión como un puente. Este trabajo

contribuye al desarrollo de la robótica didáctica aplicada en la ingeniería.

7 DISCUSIÓN

El lector que se ha visto involucrado en el proceso de diseño y construcción de

cualquier mecanismo automatizado reconoce la complejidad involucrada, ya que deben

confluir diversos conocimientos y habilidades para lograr tal fin. Estos conocimientos y

22

habilidades son demandados fuertemente al ingeniero por su entorno laboral, y son

también desarrollados de gran manera al realizar el proyecto planteado. En (Lyle D.

Feisel, Feisel, & Peterson, 2002) se plantean 13 objetivos fundamentales de los

laboratorios instruccionales de ingeniería, los cuáles a juicio personal el proyecto

planteado involucra el desarrollo de todos ellos.

Por otra parte, el trabajo presentado puede servir como punto de partida para

trabajos similares.

Finalmente, existe una diferencia fundamental entre que el estudiante compre su

robot o lo construya, en el primer caso, consume tecnología, en el segundo la genera.

REFERENCIAS BIBLIOGRÁFICAS

Lego. (10 de Septiembre de 2012). Recuperado el 15 de Agosto de 2012, de 7.

http://mindstorms.lego.com

Aliane, N., & Bemposta, S. (2008). Una experiencia de aprendizaje basado en proyectos

en una asignatura de robótica. IEEE-RITA, 71-76.

Alimisis, D. (2009). 3 years of joint work in educational robotics: the TERECoP project.

Lessons Learnt From The Terecop Project and New Pathways Into Educational

Robotics (págs. 1-4). Athens: ASPETE.

Alimisis, D., Moro, M., Arlegui, J., Pina, A., Frangou, S., & Papanikolau, K. (2007).

Robotics & Constructivism in Education: the TERECoP proyect. Eurologo 2007.

Bratislava.

Angulo Usategui, J. M., Romero Yesa, S., & Angulo Martínez, I. (2002). Microbótica,

Bolton, W. (2006). Mecatrónica: Sistemas de control electrónico en la ingeniería

mecánica y eléctrica. México: Alfaomega.

Kelly, R., & Santibañez, V. (2003). Control de movimiento de robots manipuladores.

Madrid: Pearson Education.

23

Ollero Baturone, A. (2007). Robótica: Manipuladores y Robots Móviles. México:

Alfaomega.

Russell, S. J. (2004). Inteligencia Artificial, Un enfoque moderno. España: Prentice Hall.

National Instruments Corporation. (03 de Abril de 2013). Introducción a mecatrónica.

México, D.F., México, México.

Braude, E. J. (2005). Ingeniería de software. Una perspectiva orientada a objetos.

México: Alfaomega.

Arduino. (11 de Febrero de 2013). Arduino. Recuperado el 15 de Junio de 13, de

Arduino: http://www.arduino.cc/

RaspBerry Pi. (2013). RaspBerry Pi. Recuperado el 20 de 06 de 2013, de RaspBerry Pi:

http://www.raspberrypi.org/

Microchip. (2013). ChipKIT. Recuperado el 20 de 06 de 2013, de ChipKIT:

http://www.digilentinc.com/

Lyle D. Feisel, P. P., Feisel, L. D., & Peterson, G. D. (2002). A Colloquy on Learning

Objectives For Engineering Education Laboratories. American Society for Engineering

Education Annual Conference. San Diego California: American Society for Engineering

Education.