Universidad San Pablo - CEU Escuela Politécnica Superior...

Universidad San Pablo - CEU

Escuela Politécnica Superior

Ingeniería en Informática

Proyecto Final de Carrera

WHEX 1: Diseño y construcción de

un robot hexápodo programable.

Autor: Wiljan Arias Milián

Director: Mariano Fernández López

febrero de 2011

Universidad San Pablo - CEU

Escuela Politécnica Superior

División de Ingeniería Informática y de Telecomunicación

Calificación del Proyecto Final de Carrera

Datos personales del alumno D.N.I.

APELLIDOS

NOMBRE

Directores

Director 1 (tantos como sean los directores) D/Dª

Tribunal calificador

Presidente D/Dª

FIRMA

Secretario D/Dª

FIRMA

Vocal D/Dª

FIRMA

Fecha de calificación

Calificación

4

Resumen

El presente proyecto surge con el objetivo de diseñar un robot hexápodo programable dedicado

al aprendizaje de programación robótica por parte de estudiantes de ingeniería.

Antes de comenzar el diseño se definieron con claridad los requisitos que el robot debe

cumplir: caminar y rotar simulando el comportamiento de una hormiga u otro insecto de seis

patas, adoptar posturas relativamente complejas, detectar objetos remotamente (mediante una

cámara) y determinar la distancia de posibles obstáculos al caminar, entre otros. Además, el

robot debe ser autónomo en cuanto a fuente de energía y debe poderse controlar remotamente

desde un ordenador.

Una vez comprendidos los requisitos se define la arquitectura principal del sistema. Esta

arquitectura cuenta con tres capas: hardware, servicios de acceso al hardware y software de

control. La capa de hardware incluye todo lo relacionado con la estructura mecánica y

electrónica, los actuadores, sistemas de control y fuentes de energía. Por otro lado, la capa de

servicios de acceso al hardware, como su nombre indica, contiene módulos de software y

firmware cuyo objetivo es servir de mediador entre el software de control y el hardware. Por

último, la capa de software de control constituye el “cerebro” que rige las funciones de alto nivel

del robot.

La estructura mecánica cuenta con 20 grados de libertad, tres en cada pata y dos en el cuello.

Esta estructura se diseñó totalmente utilizando técnicas de diseño asistido por ordenador, para

ello se utilizó la herramienta Varicad 3.01. Las piezas diseñadas se fabricaron en aluminio y

policarbonato. Los actuadores que mueven la estructura son 20 servomotores de radio control.

La electrónica se desarrolló utilizando las herramientas Labcenter Electronics Proteus y

Cadence Orcad 10.3. Los circuitos creados se simularon y validaron antes de su fabricación. El

firmware ejecutado por los microcontroladores PIC incluidos en la electrónica se programó en

ensamblador y C, utilizando para ello MPLAB IDE.

El robot, además de la electrónica que se desarrolló específicamente para él, cuenta con un

ordenador de a bordo, que ejecuta el sistema operativo Debian Linux 5.0.

El software de control creado es totalmente modular, es decir, toda la funcionalidad de

procesamiento y entrada - salida se encuentra distribuida en módulos; este es un requisito

imprescindible pues, debido al carácter académico del robot, este debe ser fácilmente

programable y modificable. El software se codificó en C++ para el compilador GCC.

5

Una característica notable es la visión artificial que se ha incluido en el robot, la cual consiste

en la detección de rostros humanos mediante una cámara web para posteriormente realizar su

seguimiento. Este módulo de software se ha implementado utilizando las librerías OpenCV.

Al concluir el proyecto se cuenta con un prototipo de robot hexápodo, llamado WHEX 1, sobre

el cual se han aplicado un conjunto de pruebas para validar el correcto funcionamiento de los

subsistemas que lo componen. El proyecto se dio por terminado en el momento en que el

prototipo creado pasó satisfactoriamente todas las pruebas.

6

Abstract

This project has been created to design a programmable hexapod robot, useful as a hardware

platform in the learning of robotics programming.

The first step was to define the specific requirements of the robot: To be able to walk and rotate

simulating the behavior of an ant or other insect with six legs, to adopt relatively complex

postures, to identify objects remotely (via a camera) and determine the distance to potential

barriers while walking, among others. In addition, the robot must be autonomous in terms of

source of energy and should be controllable from a computer.

Once the requirements were understood, the next step was to define the core architecture of the

system. This architecture has three layers: hardware, hardware access services and control

software. The hardware layer includes everything related to the mechanical structure and

electronics, actuators, control systems and energy sources. On the other hand, the hardware

access services layer, as its name suggests, contains software and firmware modules intended

to serve as a mediator between the control software and hardware. Finally, the control software

layer is the "brain" that governs high level functions of the robot.

The mechanical structure has 20 degrees of freedom, three in each leg and two in the

neck. This structure was designed entirely using computer aided design techniques, using

Varicad 3.01 tools. The designed parts were manufactured using aluminum and

polycarbonate. The actuators are 20 radio control servomotors.

The electronics was developed using Labcenter Electronics Proteus and Cadence Orcad 10.3

software tools. All the circuits were simulated and validated previus to their manufacture. The

firmware executed by the PIC microcontrollers included in the electronics was programmed in

assembler and C, using MPLAB IDE.

The robot, as well as the electronics developed specifically for it, features an onboard computer,

running the Debian Linux 5.0 operating system.

The control software was designed to be modular; all the functionality of processing and input-

output is distributed in modules; this characteristic is a prerequisite because the robot needs to

be easily modifiable and programmable. The software was coded using the GCC C++ compiler.

An important feature is the artificial vision that has been included in the robot, which is the

detection of human faces using a webcam to track them later. This software module was

implemented using the OpenCV libraries.

7

The hexapod robot prototype called WHEX 1 was finished at the end of the project, and several

tests were run in order to validate the proper function of its subsystems. Once the prototype

passed all the tests, the project was considered successfully terminated.

8

Dedicatoria

A mi padre,

por ser a lguien en quien s iempre puedo conf iar .

10

Agradecimientos

A mi famil ia , especia lmente a mis padres, mis her manos y mi t ía Cacha, s in

su apoyo seguramente este día no habr ía s ido posib le.

A nuestra quer ida amiga Amal ia, s in su ayuda hoy yo no estaría aquí .

A mi novia Sandra, fuente de mi inspirac ión.

A mis profesores, tanto de la UPR como de la EPS, s in los c onocimientos que

me han dado no habría s ido pos ib le terminar esta obra.

Al d irector de este proyecto, s in su guía todo habr ía s ido muy d if íc i l .

A todos, muchas grac ias.

12

Índice de contenidos

RESUMEN 4

ABSTRACT 6

DEDICATORIA 8

AGRADECIMIENTOS 10

CAPITULO 1: INTRODUCCIÓN 26

CAPITULO 2: ESTADO DE LA CUESTIÓN 34

2.1 MICROCONTROLADORES 34

2.2 ACTUADORES EN ROBÓTICA 36

2.2.1 MOTORES 36

2.2.2 MOTOR DC CON CAJA REDUCTORA 37

2.2.3 SERVOMOTOR 37

2.2.4 ALAMBRES MUSCULARES 38

2.2.5 MÚSCULOS ARTIFICIALES 39

2.2.6 PISTONES NEUMÁTICOS E HIDRÁULICOS 40

2.3 PLACAS DE CIRCUITO IMPRESO COMERCIALES 40

2.4 SENSORES 41

2.5 BATERÍAS 41

2.5.1 BATERÍAS DE PLOMO 43

2.5.2 BATERÍAS DE NÍQUEL CADMIO 43

2.5.3 BATERÍAS DE NÍQUEL E HIDRURO METÁLICO 44

2.5.4 BATERÍAS DE IONES DE LITIO 44

2.5.5 BATERÍAS DE POLÍMERO DE LITIO. 45

2.6 ALGORITMOS EMPLEADOS EN ROBÓTICA MÓVIL 45

2.6.1 GENERACIÓN DE MOVIMIENTOS EN ROBOTS MÓVILES Y MANIPULADORES 46

2.6.2 ALGORITMOS DE PERCEPCIÓN COMPUTACIONAL 48

2.7 PROYECTOS ACTUALES DE ROBÓTICA MÓVIL 51

2.7.1 ASIMO 51

2.7.2 BIGDOG 52

2.7.3 RHEX 53

2.7.4 AIBO 53

2.7.5 OTROS PROYECTOS DE ROBÓTICA 53

CAPITULO 3: ESPECIFICACIÓN DE REQUISITOS 60

3.1 ÁMBITO DEL SISTEMA 60

3.2 DESCRIPCIÓN GENERAL DE WHEX 1 60

3.3 FUNCIONES 61

3.4 CARACTERÍSTICAS DE LOS USUARIOS 61

3.5 RESTRICCIONES 61

3.6 REQUISITOS ESPECÍFICOS 62

3.6.1 REQUISITOS FUNCIONALES 62

13

3.6.2 REQUISITOS DE INTERFACES EXTERNAS 65

3.6.3 REQUISITOS DE RENDIMIENTO 66

3.6.4 REQUISITOS DE FIABILIDAD 66

CAPITULO 4: ARQUITECTURA GENERAL DEL SISTEMA 70

4.1 CAPA 1: HARDWARE DEL ROBOT. 71

4.2 CAPA 2: SERVICIOS Y ACCESO AL HARDWARE. 72

4.3 CAPA 3: SOFTWARE CONTROLADOR WHEX 1. 72

CAPITULO 5: DISEÑO Y CONSTRUCCIÓN DE LA ESTRUCTURA MECÁNICA. 76

5.1 CUERPO DE WHEX 1. 76

5.2 PATAS DE WHEX 1. 80

5.3 CABEZA DE WHEX 1. 85

CAPITULO 6: DISEÑO Y CONSTRUCCIÓN DE LA ELECTRÓNICA. 92

6.1 BATERÍAS: 93

6.2 CIRCUITO DE DISTRIBUCIÓN DE ENERGÍA 94

6.3 PLACA CONTROLADORA WHEX 1 95

6.3.1 METODOLOGÍA DE DISEÑO HARDWARE EMPLEADA. 98

6.3.2 DISEÑO DE LOS DIAGRAMAS ESQUEMÁTICOS DE LA PLACA CONTROLADORA. 99

6.3.3 DISEÑO Y FABRICACIÓN DEL CIRCUITO IMPRESO DE LA PLACA CONTROLADORA WHEX 1. 106

6.4 ORDENADOR DE A BORDO 109

CAPITULO 7: DISEÑO Y DESARROLLO DEL FIRMWARE DEL ROBOT. 114

7.1 METODOLOGÍAS Y TÉCNICAS EMPLEADAS PARA EL DISEÑO Y CODIFICACIÓN DEL FIRMWARE 115

7.2 DISEÑO Y CODIFICACIÓN DEL PAQUETE CONTROLADOR DE SERVOMOTORES. 117

7.2.1 MÉTODO EMPLEADO PARA CONTROLAR 24 SERVOMOTORES UTILIZANDO UN PIC18F4525. 118

7.2.2 MODELOS MATEMÁTICOS EMPLEADOS PARA LA PROGRAMACIÓN DE LOS TEMPORIZADORES. 119

7.2.3 ALGORITMO DEL PROGRAMA CONTROLADOR DE SERVOMOTORES. 121

7.3 DISEÑO Y CODIFICACIÓN DEL PAQUETE CONTROLADOR PRINCIPAL WHEX 1. 130

7.3.1 ARQUITECTURA GENERAL DEL PAQUETE CONTROLADOR PRINCIPAL WHEX 1. 130

7.3.2 COMUNICACIÓN CON EL EXTERIOR. 131

7.3.3 GESTOR DE PETICIONES. 134

7.3.4 CINEMÁTICA INVERSA 135

7.3.5 GENERADOR DE MOVIMIENTOS. 140

7.3.6 GESTOR DE PERIFÉRICOS. 153

CAPITULO 8: INSTALACIÓN Y CONFIGURACIÓN DEL S.O. DEL ORDENADOR. 156

8.1 INSTALACIÓN Y CONFIGURACIÓN DEL DRIVER MULTIMEDIA. 157

8.2 INSTALACIÓN Y CONFIGURACIÓN DE LA CONTROLADORA WIFI USB SMC EZ CONNECT. 158

8.2.1 CONFIGURACIÓN DE LA WIFI. 158

8.3 INSTALACIÓN Y CONFIGURACIÓN DEL DRIVER DE LA WEBCAM. 160

8.4 INSTALACIÓN DE LAS LIBRERÍAS DE PROCESAMIENTO DE IMÁGENES OPENCV. 160

14

CAPITULO 9: DISEÑO Y DESARROLLO DEL SOFTWARE DE CONTROL WHEX 1. 164

9.1 FRAMEWORK WHEX 1 164

9.1.1 GESTOR DE MÓDULOS. 165

9.1.2 SISTEMA DE COMUNICACIÓN INTERNO DEL FRAMEWORK. 166

9.1.3 GESTOR DE EVENTOS PERIÓDICOS. 168

9.1.4 INTERFAZ CON EL HARDWARE DEL ROBOT. 168

9.1.5 UNIDAD MODULAR Y DE COMUNICACIÓN. 169

9.2 SOFTWARE DE CONTROL CREADO PARA EL ROBOT WHEX 1. 171

9.2.1 PROCESO DRIVER DE LA PLACA CONTROLADORA WHEX 1. 172

9.2.2 PROCESO DETECTOR DE ROSTROS. 174

9.2.3 PROCESO PRINCIPAL DEL SOFTWARE WHEX 1. 178

9.2.4 PROCESO CLIENTE WHEX 1. 186

CAPITULO 10: DISEÑO Y EJECUCIÓN DE LAS PRUEBAS DEL SISTEMA. 190

10.1 PRUEBAS REALIZADAS SOBRE LA ESTRUCTURA MECÁNICA. 190

10.2 PRUEBAS REALIZADAS A LA PLACA CONTROLADORA WHEX 1. 191

10.2.1 PRUEBAS REALIZADAS AL FIRMWARE DEL CONTROLADOR DE SERVOMOTORES. 191

10.2.2 PRUEBAS REALIZADAS AL FIRMWARE DEL CONTROLADOR PRINCIPAL WHEX 1. 192

10.2.3 CIRCUITO IMPRESO DE LA PLACA CONTROLADORA. 192

10.3 SOFTWARE CONTROLADOR WHEX 1. 193

CAPITULO 11: CONCLUSIONES Y LÍNEAS FUTURAS. 198

11.1 CONCLUSIONES. 198

11.2 LÍNEAS FUTURAS. 199

BIBLIOGRAFÍA 202

16

Índice de f iguras

FIG. 2.1: MICROCONTROLADORES PIC. .......................................................................................... 34

FIG. 2.2: BUCLE DE CONTROL DE UN MICROCONTROLADOR. ............................................................. 35

FIG. 2.3: MOTOR DC. .................................................................................................................... 36

FIG. 2.4: MOTOR DC CON CAJA REDUCTORA. .................................................................................. 37

FIG. 2.5: SERVOMOTOR DE MODELISMO. ......................................................................................... 37

FIG. 2.6: COMPONENTES DE UN SERVOMOTOR DE MODELISMO. ........................................................ 37

FIG. 2.7: MODULACIÓN POR ANCHO DE PULSO (PWM). ................................................................... 38

FIG. 2.8: ALAMBRE FLEXINOL. ........................................................................................................ 38

FIG. 2.9: HEXÁPODO MOVIDO POR ALAMBRES DE NITINOL. ............................................................... 39

FIG. 2.10: MÚSCULO ARTIFICIAL DE LA COMPAÑÍA SCHADOW ROBOT. ............................................... 39

FIG. 2.11: PISTONES HIDRÁULICOS. ............................................................................................... 40

FIG. 2.12: CONTROLADORA DE SERVOS SSC32. ............................................................................. 40

FIG. 2.13: CONTROLADORA DE SERVOS ELECTAN. ....................................................................... 40

FIG. 2.14: CONTROLADORA DE SERVOS POR I2C. ........................................................................... 40

FIG. 2.15: EFECTO MEMORIA. ......................................................................................................... 42

FIG. 2.16: BATERÍA DE PLOMO. ....................................................................................................... 43

FIG. 2.17: BATERÍAS DE NÍQUEL CADMIO. ....................................................................................... 44

FIG. 2.18: BATERÍAS DE NÍQUEL E HIDRURO METÁLICO. .................................................................. 44

FIG. 2.19: BATERÍA DE IONES DE LITIO PARA TELÉFONO MÓVIL NOKIA. ............................................. 45

FIG. 2.20: BATERÍA DE POLÍMEROS DE LITIO EMPLEADA EN AEROMODELISMO. .................................. 45

FIG. 2.21: ROBOT HEXÁPODO, VISTA SUPERIOR. REGIONES PARA EL ALGORITMO DE LOC. LIBRE. ....... 48

FIG. 2.22: IMAGEN INTEGRAL. ......................................................................................................... 49

FIG. 2.23: CARACTERÍSTICAS TIPO HAAR. ....................................................................................... 49

FIG. 2.24: CARACTERÍSTICAS TIPO HAAR QUE IMPLEMENTA EL DETECTOR DE OPENCV. .................... 49

FIG. 2.25: ROBOT HUMANOIDE ASIMO DE HONDA. ......................................................................... 51

FIG. 2.26: ROBOT CUADRÚPEDO MILITAR BIGDOG. .......................................................................... 52

FIG. 2.27: ROBOT HEXÁPODO TODOTERRENO RHEX. ...................................................................... 53

FIG. 2.28: ROBOT MASCOTA AIBO DE SONY .................................................................................... 53

FIG. 2.29: ROBOT HEXÁPODO LYNXMOTION PHENIX. ....................................................................... 54

FIG. 2.30: ROBOT HEXÁPODO DE MICROMAGIC. .............................................................................. 54

FIG. 2.31: ROBOT HEXÁPODO HEXPIDER......................................................................................... 54

FIG. 2.32: ROBOT HEXÁPODO A-POD. ............................................................................................ 54

FIG. 3.1: ENTORNO DE LABORATORIO EN EL QUE SE DESEMPEÑARÁ WHEX 1. .................................. 60

FIG. 4.1: DIAGRAMA DE CAPAS QUE MUESTRA LA ARQUITECTURA GENERAL DEL ROBOT WHEX 1....... 70

FIG. 5.1: ELEMENTOS DE LA ARQUITECTURA DEL ROBOT QUE ABORDA EL CAPÍTULO 5. ...................... 76

FIG. 5.2: PIEZA WHEX BODY 1 DISEÑADA EN VARICAD. ................................................................. 77

FIG. 5.3: PIEZA WHEX BODY 2 DISEÑADA EN VARICAD. ................................................................. 77

FIG. 5.4: PIEZA WHEX BODY COVER DISEÑADA EN VARICAD. ........................................................ 78

FIG. 5.5: COMPONENTES DEL CUERPO DEL ROBOT WHEX 1 DISPUESTOS EN ORDEN DE MONTAJE. .... 79

FIG. 5.6: SEPARADORES, TUERCAS Y TORNILLOS UTILIZADOS EN EL MONTAJE DEL CUERPO. .............. 80

FIG. 5.7: ESTRUCTURA MECÁNICA ENSAMBLADA DEL CUERPO DEL ROBOT WHEX 1. ......................... 80

FIG. 5.8: MODELOS DE PATA DISEÑADOS PARA EL ROBOT WHEX 1. ................................................. 80

FIG. 5.9: TRAZADO EN VARICAD Y REPRESENTACIÓN TRIDIMENSIONAL DE LA PIEZA LEG 1. ............... 81

FIG. 5.10: TRAZADO EN VARICAD Y REPRESENTACIÓN TRIDIMENSIONAL DE LA PIEZA LEG 2. ............. 81

FIG. 5.11: COMPONENTES DE LA ESTRUCTURA MECÁNICA DE LAS PATAS. ......................................... 82

FIG. 5.12: RANGO PERMITIDO DE MOVIMIENTOS DE LAS ARTICULACIONES DE LA PATA........................ 82

FIG. 5.13: PUNTAS DE GOMA ANTIDESLIZANTE COMERCIALIZADAS POR LA COMPAÑÍA LYNXMOTION. ... 83

FIG. 5.14: REPRESENTACIÓN ESQUEMÁTICA DE LA ESTRUCTURA MECÁNICA DE UNA PATA. ................ 83

FIG. 5.15: SOPORTE MULTIFUNCIONAL PARA SERVOMOTORES COMERCIALIZADO POR LYNXMOTION. .. 83

FIG. 5.16: PASOS DE LA SECUENCIA DE UNIÓN DE CADA PATA AL CUERPO DEL ROBOT. ...................... 83

FIG. 5.17: RANGO DE MOVIMIENTOS DE LOS SERVOMOTORES DE LA CADERA. ................................... 84

17

FIG. 5.18: ESTRUCTURA MECÁNICA DEL CUERPO DE WHEX 1, INCLUYENDO LAS 6 PATAS. ................ 84

FIG. 5.21: PIEZA HEAD 1 DISEÑADA EN VARICAD............................................................................ 85

FIG. 5.19: MECANISMO PAN & TILT COMERCIALIZADO POR LA EMPRESA LYNXMOTION. ...................... 85

FIG. 5.20: PLATINAS EN FORMA DE C UTILIZADAS EN EL MECANISMO PAN & TILT ............................... 85

FIG. 5.22: SECUENCIA DE MONTAJE DE LA CABEZA DEL ROBOT WHEX 1. ......................................... 86

FIG. 5.23: ESTRUCTURA MECÁNICA DE LA CABEZA DEL ROBOT HEXÁPODO WHEX 1. ........................ 87

FIG. 5.25: ESTRUCTURA MECÁNICA TERMINADA DEL ROBOT HEXÁPODO WHEX 1. ............................ 87

FIG. 5.24: SECUENCIA DE UNIÓN DE LA CABEZA DEL ROBOT AL CUERPO. ........................................... 87

FIG. 5.26: PIEZA WHEX BODY 1. ................................................................................................... 88

FIG. 5.27: PIEZA WHEX BODY 2. ................................................................................................... 88

FIG. 5.28: PIEZA WHEX BODY 1 CON EL ORDENADOR INSTALADO. .................................................. 88

FIG. 5.29: PIEZA WHEX BODY 2 CON SERVOMOTORES. .................................................................. 88

FIG. 5.30: CUERPO DEL ROBOT WHEX 1. ....................................................................................... 89

FIG. 5.31: PATA DEL ROBOT WHEX 1. ............................................................................................ 89

FIG. 6.1: ELEMENTOS DE LA ARQUITECTURA DEL ROBOT QUE ABORDA EL CAPÍTULO 6. ...................... 92

FIG. 6.2: COMPONENTES PRINCIPALES DE LA ELECTRÓNICA DE WHEX 1. ......................................... 93

FIG. 6.3: BATERÍA LIPO UTILIZADA EN WHEX 1. ............................................................................. 93

FIG. 6.4: REPRESENTACIÓN ESQUEMÁTICA DEL CIRCUITO DISTRIBUIDOR DE ENERGÍA. ....................... 94

FIG. 6.5: UBEC DE 5 V / 6 V, 3 A CONSTANTES Y 5 A DE PICO, DE MARCA TURNIGY. ...................... 95

FIG. 6.6: UBEC DE 5 V / 6 V, 8 A CONSTANTES Y 15 A DE PICO, DE MARCA G.T. POWER. ................. 95

FIG. 6.7: ESQUEMA QUE REPRESENTA LOS COMPONENTES Y CONECTORES DE LA PLACA WHEX 1. ... 96

FIG. 6.8: PROCESO DE DISEÑO DE HARDWARE SIN UTILIZAR SIMULACIONES. ..................................... 98

FIG. 6.9: PROCESO DE DISEÑO DE HARDWARE UTILIZANDO SIMULACIONES. ....................................... 99

FIG. 6.10: CAMINO LÓGICO SEGUIDO POR LOS DATOS EN LA PLACA CONTROLADORA WHEX 1. ........ 100

FIG. 6.11: DIAGRAMA ESQUEMÁTICO DEL CIRCUITO DEL DRIVER RS232. ........................................ 101

FIG. 6.12: CONFIGURACIÓN DE LOS JUMPERS DEL DRIVER RS232 PARA: ....................................... 101

FIG. 6.13: DIAGRAMA ESQUEMÁTICO DEL CONTROLADOR PRINCIPAL WHEX 1. .............................. 102

FIG. 6.14: DIAGRAMA ESQUEMÁTICO DEL CONTROLADOR DE SERVOMOTORES. .............................. 105

FIG. 6.15: CAPA SUPERIOR DEL CIRCUITO IMPRESO DE LA PLACA CONTROLADORA WHEX 1. ........... 107

FIG. 6.16: CAPA INFERIOR DEL CIRCUITO IMPRESO DE LA PLACA CONTROLADORA WHEX 1. ............ 107

FIG. 6.17: VISTA DE SERIGRAFÍA DE ORCAD DE LA PLACA CONTROLADORA. ................................... 108

FIG. 6.18: PLACA CONTROLADORA WHEX 1 INSTALADA EN EL CUERPO DEL ROBOT. ....................... 108

FIG. 6.19: COMPONENTES DEL ORDENADOR DE A BORDO DE WHEX 1. .......................................... 109

FIG. 6.20: PLACA BASE VIA EPIA PICO ITX. .................................................................................. 109

FIG. 6.22: COMPONENTES DEL SUBSISTEMA DE ALMACENAMIENTO CONFIGURADO PARA WHEX 1. .. 110

FIG. 6.21: FUENTE DE ALIMENTACIÓN PICOPSU 60WI .................................................................. 110

FIG. 6.24: PROTOTIPO DEL ROBOT WHEX 1 CONSTRUIDO. ............................................................ 111

FIG. 6.23: CONTROLADORA WIFI USB SMC EZ CONNECT, UTILIZADA EN WHEX 1. ...................... 111

FIG. 7.1: ELEMENTOS DE LA ARQUITECTURA QUE SE ANALIZAN EN EL CAPÍTULO 7. .......................... 114

FIG. 7.2: DIAGRAMA DE DESPLIEGUE DE LOS COMPONENTES DEL ROBOT WHEX 1. ......................... 114

FIG. 7.3: GRAFO DE DEPENDENCIAS DE LOS MÓDULOS DEL FIRMWARE DEL ROBOT WHEX 1. .......... 116

FIG. 7.4: INCREMENTOS DEFINIDOS PARA EL DESARROLLO DEL CONTROLADOR DE SERVOMOTORES. 116

FIG. 7.5: INCREMENTOS DEFINIDOS PARA EL DESARROLLO DEL GENERADOR DE MOVIMIENTOS. ....... 116

FIG. 7.6: ESQUEMA DE TIEMPO QUE MUESTRA EL COMPORTAMIENTO DE 8 SEÑALES PWM. ............. 119

FIG. 7.7: ESQUEMA DE TIEMPO QUE MUESTRA LAS 8 SEÑALES PWM SOLAPADAS. ........................... 119

FIG. 7.8: DIAGRAMA DE FLUJO DEL PROGRAMA PRINCIPAL DEL CONTROLADOR DE SERVOMOTORES. 122

FIG. 7.9: DIAGRAMA DE FLUJO DEL PROCESO ACTUALIZAR POSICIÓN DE SERVOMOTORES. .............. 125

FIG. 7.10: ALGORITMO DEL ESCLAVO I2C ..................................................................................... 126

FIG. 7.11: ARQUITECTURA DEL PAQUETE DE FIRMWARE CONTROLADOR PRINCIPAL WHEX 1 ........... 130

FIG. 7.12: MÁQUINA DE MOORE QUE GESTIONA EL PUERTO SERIE. ................................................. 132

FIG. 7.13: ARQUITECTURA INTERNA DEL GESTOR DE PETICIONES ................................................... 134

FIG. 7.14: SISTEMAS DE COORDENADAS DEFINIDOS PARA LA CINEMÁTICA INVERSA. ........................ 135

FIG. 7.15: MODELO GEOMÉTRICO TRIDIMENSIONAL DE UNA PATA DEL ROBOT WHEX 1. .................. 137

18

FIG. 7.16: PROYECCIÓN DEL MODELO GEOMÉTRICO DE LA FIGURA 3.67 EN EL PLANO ZW. .............. 137

FIG. 7.17: ESQUEMA QUE MUESTRA AL AUTÓMATA GENERADOR DE MOVIMIENTOS. .......................... 140

FIG. 7.18: DIAGRAMA QUE MUESTRA LOS ESTADOS DE LAS PATAS DEL ROBOT Y SUS TRANSICIONES 141

FIG. 7.19: VISTA SUPERIOR DEL ROBOT WHEX 1. ......................................................................... 145

FIG. 7.20: SECUENCIA DE MOVIMIENTOS DE UNA PATA EN UN PASO. ............................................... 145

FIG. 7.21: SECUENCIA DE PASOS QUE EJECUTA EL ROBOT WHEX 1 EN LOS MODOS 0 Y 1. .............. 146

FIG. 7.22: SECUENCIA DE PASOS QUE EJECUTA EL ROBOT WHEX 1 EN EL MODO 2. ........................ 146

FIG. 7.23: SECUENCIA DE PASOS QUE EJECUTA EL ROBOT WHEX 1 EN EL MODO 3. ........................ 146

FIG. 7.24: SECUENCIA DE MOVIMIENTOS DE UNA PATA EN UN PASO CON ANOTACIONES ................... 147

FIG. 7.25: AUTÓMATA GENERADOR DE MOVIMIENTOS CON EL ESTADO 2 AMPLIADO. ........................ 149

FIG. 7.26: VISTA SUPERIOR DEL ROBOT WHEX 1. ......................................................................... 152

FIG. 7.27: SECUENCIA DE MOVIMIENTOS DE UNA PATA AL ROTAR. ................................................... 152



FIG. 9.2: ARQUITECTURA GENERAL DEL FRAMEWORK WHEX 1. ..................................................... 165

FIG. 9.3: ESTRUCTURA DE BUZONES MANTENIDA POR EL SISTEMA DE COMUNICACIÓN. .................... 167

FIG. 9.4: ARQUITECTURA DEL SOFTWARE CONTROLADOR WHEX 1. ............................................... 171

FIG. 9.5: DIAGRAMA DE FLUJO QUE REPRESENTA EL ALGORITMO DEL PROCESO DRIVER. ................. 173

FIG. 9.6: DIAGRAMA DE FLUJO DEL ALGORITMO DEL PROCESO DETECTOR DE ROSTROS. .................. 178

FIG. 9.7: MECANISMO DE COMUNICACIÓN CONFIGURADO EN EL SOFTWARE DE CONTROL WHEX 1. . 180

FIG. 9.8: MÁQUINA DE MEALY QUE IMPLEMENTA EL MÓDULO SEGUIDOR DE ROSTROS ...................... 182

FIG. 9.9: VENTANA “CONECTAR CON EL ROBOT” DEL CLIENTE WHEX 1. ......................................... 186

FIG. 9.10: VENTANA PRINCIPAL DEL CLIENTE WHEX 1. ................................................................. 186

FIG. 10.1: PIEZAS DE LAS PATAS FABRICADAS EN POLICARBONATO QUE SE DESCARTARON. ............. 190

FIG. 10.2: FIJADOR DE PLÁSTICO RODEANDO EL SERVOMOTOR DE LA CADERA. ............................... 191

FIG. 10.3: CIRCUITO COMMASTERPORT. ...................................................................................... 191

20

Índice de tablas

TABLA 2.1: TABLA DE BÚSQUEDA PARA UNA ARTICULACIÓN EN EL ALGORITMO DE LOCOMOCIÓN FIJA. . 47

TABLA 2.2: PATAS QUE PUEDEN MOVERSE EN EL ALGORITMO DE LOCOMOCIÓN LIBRE. ....................... 48

TABLA 5.1: PRECIOS DE LOS COMPONENTES DE LA ESTRUCTURA MECÁNICA DEL ROBOT WHEX 1. .... 88

TABLA 6.1: PRECIOS DE LOS COMPONENTES DE LA ELECTRÓNICA DEL ROBOT WHEX 1 .................. 111

TABLA 7.1: ESTRUCTURA DE LOS REGISTROS DE VELOCIDAD Y POSICIÓN DE LOS SERVOMOTORES. .. 123

TABLA 7.2: ASIGNACIÓN DE LAS 24 SEÑALES PWM A LOS INTERVALOS DEFINIDOS EN SU PERÍODO. . 128

TABLA 7.3: ORDEN DE LAS PATAS ASIGNADO A CADA UNO DE LOS MODOS DEL ROBOT. .................... 150

TABLA 9.1: ENTRADAS DEL FICHERO DE CONFIGURACIÓN DEL PROCESO DRIVER. ............................ 174

TABLA 9.2: ENTRADAS DEL FICHERO DE NOMBRES DE COMANDOS. ................................................. 174

TABLA 9.3: MÓDULOS CREADOS E INCLUIDOS DE SERIE EN EL SOFTWARE CONTROLADOR WHEX 1. 179

TABLA 9.4: BUZONES DE MENSAJES QUE SE HAN DEFINIDO Y LOS MÓDULOS SUSCRITOS A ELLOS. .... 179

TABLA 11.1: DURACIONES ESTIMADAS Y REALES DE LAS TAREAS DEL PROYECTO. ........................... 198

Bloque I

Introducción

WHEX 1: Diseño y construcción de un robot hexápodo programable. 24

Capítulo

Introducción

1

Introducción


1 Introducción

Este proyecto está enmarcado dentro de las ciencias de la robótica, específicamente la

robótica móvil. Su propósito es el diseño y desarrollo de una plataforma robótica hexápoda,

maximizando la sencillez del diseño de hardware y la fiabilidad del sistema, y teniendo un

enfoque eminentemente académico.

El prototipo debe ser lo suficientemente fácil de operar y programar, para permitir el

aprendizaje y perfeccionamiento de las técnicas de programación robótica a estudiantes de

ingeniería, quienes podrán utilizar el hardware creado para programar funciones propias y

aprender, observando los resultados.

Para llegar a este objetivo se ha manifestado la necesidad de realizar las siguientes tareas que

conforman la aproximación que se ha planteado a la solución:

Estudio del estado de la cuestión en materia de desarrollo de robots: tecnologías

existentes, kits comercializados, proyectos actuales, etc.

Diseño y desarrollo de la estructura mecánica del robot: piezas mecánicas de las

extremidades, el cuerpo y la cabeza, así como sus uniones.

Elección de los actuadores, sensores y partes mecánicas comerciales que serán

utilizados, y los que serán desarrollados.

Diseño y desarrollo de una placa controladora de las funciones de bajo nivel del robot,

como son la generación de movimientos y lecturas de los sensores.

Diseño y codificación del firmware de los microcontroladores de la placa creada.

Elección y puesta a punto del hardware de procesamiento de a bordo del robot (placa

base que se utilizará, fuente de alimentación, discos, etc.), maximizando la sencillez del

mismo.

Configuración de una distribución de Linux para operar en el ordenador de a bordo del

robot.

Diseño y codificación del software de control de las funciones de alto nivel del robot,

como son la planificación de movimientos, la navegación y la comunicación.

Crear código de ejemplo para mostrar las potencialidades técnicas y académicas del

robot y un programa cliente para controlarlo.

Diseño y ejecución de las pruebas que debe pasar el sistema creado.

Introducción


El presente proyecto concluye con la fabricación y prueba del hardware, firmware y software de

control del prototipo. Queda fuera del alcance de este trabajo:

Creación de un sistema de localización y navegación visual del robot.

Creación de un sistema de gestión de energía y carga automática de las baterías del

robot.

Creación de módulos hardware de expansión, aunque sí entra en el trabajo crear las

interfaces hardware necesarias para la expansión mediante tarjetas nuevas.

Funcionamiento del robot en superficies irregulares.

Detección por parte del robot de precipicios, como por ejemplo escaleras.

El presente documento tiene como objetivo principal la recopilación y organización de toda la

documentación que se ha generado durante el desarrollo del proyecto y se ha organizado en

cuatro bloques, que a su vez se han subdividido en los siguientes capítulos:

Bloque I

o Capítulo 1. Introducción.

Bloque II

o Capítulo 2. Estado de la cuestión, aquí se realiza un análisis y recopilación de

información acerca de las tecnologías existentes en la actualidad relacionadas

con la robótica. Se analizan las diferentes alternativas de hardware y los

algoritmos que se han desarrollado. Por último se comentan algunos proyectos

actuales de robótica.

Bloque III

o Capítulo 3. Especificación de requisitos, se definen los requisitos funcionales y

no funcionales que debe cumplir el prototipo de robot creado.

o Capítulo 4. Arquitectura general del sistema, donde se propone la arquitectura

global del sistema robótico creado, describiendo brevemente cada uno de sus

elementos.

o Capítulo 5. Diseño y construcción de la estructura mecánica, se aborda el

diseño y fabricación de las diferentes piezas que componen la estructura

mecánica del robot. También se describen las piezas que se ha optado adquirir

ya fabricadas para su uso en la estructura.

o Capítulo 6. Diseño y construcción de la electrónica, aquí se desarrolla la

electrónica del robot, describiendo los procesos de diseño y construcción de la

placa controladora y la elección y configuración del hardware del ordenador de

a bordo.

o Capítulo 7. Diseño y desarrollo del firmware del robot, donde se describen los

paquetes de firmware que se han codificado, sus algoritmos y modelos

matemáticos.

Introducción


o Capítulo 8. Elección y configuración del sistema operativo, documentación del

proceso de instalación y configuración de la distribución de Linux empleada

como sistema operativo del ordenador de a bordo del robot.

o Capítulo 9. Diseño y desarrollo del software de control WHEX 1, exposición de,

en primer lugar, las características del framework de programación de

aplicaciones desarrollado exclusivamente para WHEX 1 y, a continuación, se

explica el software diseñado utilizando este framework para controlar el robot.

o Capítulo 10. Diseño y ejecución de las pruebas del sistema, explicación de las

pruebas realizadas sobre cada elemento del sistema del robot WHEX 1 y los

resultados obtenidos en su ejecución.

Bloque IV

o Capítulo 11. Conclusiones y líneas futuras, donde se enumeran las

conclusiones a las que se ha llegado con la realización del trabajo y las líneas

futuras para su continuación.

Es necesario mencionar que los anexos no se han incluido en este documento por motivos de

extensión. Para consultarlos se debe buscar el documento de anexos que se ha incluido en el

CD que se adjunta. Este CD contiene además otros materiales de interés que han sido

generados a lo largo del proyecto, como por ejemplo el diseño tridimensional de la estructura

mecánica del robot, los diagramas esquemáticos de la electrónica y el código fuente de los

distintos módulos de firmware y software, entre otros.

Bloque II

Estado de la cuestión


Capítulo


2



2 Estado de la cuestión

En este capítulo se abordarán las tecnologías existentes en la actualidad, relacionadas con la

robótica, y más específicamente, la robótica móvil. Se realizará una breve descripción de los

diferentes microcontroladores, actuadores, placas de circuito impreso, sensores y soluciones

de procesamiento de a bordo para robots, sus características, recursos y capacidades, así

como algoritmos existentes.

También se comentarán algunos proyectos actuales de robótica, que por su relevancia en los

campos de investigación y comercial se hacen imposibles de pasar por alto.

2.1 Microcontroladores

Un microcontrolador es un dispositivo programable que ejecuta las

instrucciones grabadas en su memoria. De esta forma, el

microcontrolador se convierte en un pequeño ordenador y es el

desarrollador el encargado de programarlo según sus necesidades.

Además de la flexibilidad que esto aporta, los microcontroladores

suelen contar con otros módulos que añaden nuevas

funcionalidades que se analizarán más adelante, como temporizadores, conversores analógico

digital, módulos CCP, etc. [1]

La figura 2.1 muestra varios microcontroladores empleados comúnmente en proyectos de

robótica, en este caso se trata de microcontroladores PIC de gamas media y baja.

Para la construcción de un sistema automatizado moderno, es imprescindible la presencia en el

diseño de microcontroladores, ya sea de un sistema de domótica, robótica o control industrial.

Estos elementos de procesamiento actúan como bucles de control en los sistemas, permitiendo

leer de sus entradas, procesar los datos recibidos y generar salidas a los diferentes

actuadores. [1]

Fig. 2.1: Microcontroladores PIC.



Fig. 2.2: Bucle de control de un microcontrolador.

En la figura 2.2 se observa el ciclo de control de un microcontrolador, en cada iteración [1]:

Se leen las entradas, que pueden venir de sensores (temperatura, movimiento,

distancias, etc.) o de otros elementos de control (un ordenador, pulsadores, otros

microcontroladores, etc.).

Los datos recibidos por las entradas son procesados, generando salidas y datos de

estado interno del microcontrolador.

Las salidas son enviadas a los actuadores (motores, servomotores) o a otros

elementos de control y monitorización (un ordenador, otro microcontrolador, etc.).

En robótica los microcontroladores pueden desempeñar varias tareas, dependiendo del grado

de complejidad del robot:

Generación de señales de control de actuadores.

Gestión de entradas provenientes de sensores.

Cerebro del robot, cuando este es sencillo.



Las principales familias de microcontroladores existentes en el mercado actualmente son las

siguientes1:

Atmel2: AVR mega, AVR tiny, 89Sxxxx, AVR32 y AT91SAM.

Microchip3: PIC10F, PIC16F, PIC18F, PIC24F, PIC30F, PIC32, dsPIC30F y dsPIC33F.

Freescale4 (antes Motorola): 68HCxx, 68k, PowerPC y HCS08.

Intel: 8048, 8051, MCS96 y MXS296.

Renesas5: H8, H8 tiny, H8S, R8C, M16C, H8SX, R32C, M32C y SHx.

ST6: STMSS, ST6, ST7, uPSD y ST10

Todas estas familias contienen dispositivos muy similares, pudiendo ser programados en

Ensamblador (propio de cada familia y dispositivo), Visual Basic, C, o incluso C++.

En el presente trabajo se han utilizado microcontroladores de la familia PIC18F de Microchip,

programados en Ensamblador y C, específicamente el modelo PIC18F4525.

2.2 Actuadores en robótica

Un Actuador es un dispositivo capaz de “actuar” físicamente en el entorno del robot [2],

generando desplazamiento, presión, temperatura, iluminación y sonido, entre otros.

2.2.1 Motores

Un motor eléctrico es un dispositivo que transforma energía eléctrica en energía mecánica por

medio de interacciones electromagnéticas [2].

El motor más sencillo, llamado también Motor DC, genera movimiento

rotatorio continuo al suministrarle energía eléctrica continua (CC) [2],

pudiendo variar la velocidad de rotación a medida que aumenta la potencia

suministrada o mediante una técnica llamada Modulación por Ancho de Pulso

(En inglés PWM: Pulse Width Modulation), que se verá más adelante en este

trabajo.

El motor DC es la base para el resto de motores que se describirán a continuación. La figura

2.3 muestra un motor DC de baja potencia.

1 http://www.forosdeelectronica.com/wiki/microcontroladores

2 http://www.atmel.com/

2 http://www.atmel.com/

3 http://www.microchip.com

4 http://www.freescale.com

5 http://www.renesas.eu/prod/mcumpu/

6 http://www.st.com/mcu/

Fig. 2.3: Motor DC.

http://es.wikipedia.org/wiki/Energ%C3%ADa_el%C3%A9ctrica

http://es.wikipedia.org/wiki/Energ%C3%ADa_mec%C3%A1nica

http://es.wikipedia.org/wiki/Electromagnetismo



2.2.2 Motor DC con caja reductora

Este motor se comporta exactamente igual al motor DC, solo que presenta

en su eje de rotación una serie de engranajes reductores, logrando que

disminuya la velocidad de rotación del eje, permitiendo aumentar

considerablemente el torque generado por el motor.

Son muy útiles en robots móviles con ruedas, siendo un esquema muy extendido el uso de dos

motores, uno en cada rueda del robot, y una rueda no motriz que puede girar en cualquier

sentido (rueda loca).

La figura 2.4 muestra un motor DC con caja reductora acoplada directamente sobre la carcasa

del motor.

2.2.3 Servomotor

Un servomotor es en sí todo un sistema microcontrolado, consta de un

motor DC, un sensor de posición del eje principal, una caja reductora y un

circuito de control [3]. El aspecto externo de un servomotor de los

empleados en aplicaciones de modelismo y robótica móvil se puede

apreciar en la figura 2.5.

Los servomotores solo pueden girar su eje principal un ángulo determinado, por ejemplo 180

grados [3].

El esquema de la figura 2.6 muestra las diferentes partes que componen un servomotor:

Caja del servomotor.

Eje principal del servomotor.

Engranajes.

Motor DC.

Tarjeta controladora.

Sensor de posición (resistencia

variable).

El funcionamiento es el siguiente [3]:

Al servomotor se le suministra energía eléctrica continua (CC) y una señal de control,

codificada de alguna manera, por ejemplo mediante Modulación de Ancho de Pulso,

esta última es el caso más común.

Fig. 2.4: Motor DC con caja reductora.

Fig. 2.5: Servomotor de modelismo.

Fig. 2.6: Componentes de un servomotor de modelismo.



El circuito de control interno determina, dada la señal de control, la posición que debe

tener el eje principal del motor.

El circuito de control también lee la información de posición real del eje del motor desde

el sensor que incorpora.

Entonces, si estas dos posiciones difieren, se genera la corriente necesaria hacia el

motor DC que haga girar el eje a la posición deseada.

Si las dos lecturas coinciden, el motor permanece en reposo, manteniendo la posición

actual.

La modulación por ancho de pulso suele utilizarse para codificar la señal de control de los

servomotores, dicha modulación consiste en enviar una serie de pulsos de período constante,

por ejemplo 20 milisegundos, haciendo variar el tiempo en el cual la señal se encuentra en

estado 1 [3], esto se puede ver en la figura 2.7.

Los servomotores de modelismo (los más utilizados

en robots de tamaños pequeños) gestionan un ancho

de pulso que va desde 1 ms a 2 ms con la señal en

estado 1, y el período de los pulsos suele ser de 20

ms, aunque algunos modelos pueden necesitar

ampliar este rango desde los 0.5 ms a los 2.5 ms

para abarcar todo el movimiento de su eje [3].

2.2.4 Alambres musculares

Las palabras “Alambres Musculares” son la traducción al

español de “Muscle Wires” (la cual es una marca registrada de

la empresa Mondo Tronics7).

Estos alambres metálicos delgados cuando conduce corriente eléctrica se contraen y cuando

dejan de conducir corriente se relajan de forma muy parecida a como lo hace un músculo [4].

El funcionamiento de estos actuadores se basa en la aleación de níquel y titanio llamada

Nitinol, de la cual están compuestos [4].

Esta aleación cambia su estructura molecular dependiendo de la temperatura, de ahí el cambio

de longitud del alambre al circular corriente eléctrica a través de él [4]. Los dos tipos más

comercializados son los que requieren temperaturas de 70 y 90 grados centígrados para

activarse. Los de 90 grados tienen la terminación “HT” (High Temperature) y los de 70 grados

7 http://www.mondotronics.com/

Fig. 2.7: Modulación por Ancho de Pulso (PWM).

Fig. 2.8: Alambre Flexinol.



terminan en “LT”. El nombre de estos alambres se divide en tres partes: “Flexinol” que es la

marca, luego viene el diámetro en micrones, y luego si es HT o LT. Por ejemplo: el alambre

“FLEXINOL 100 HT” es de 100 micrómetros y se activa a 90 grados centígrados [4]. La figura

2.8 muestra varios alambres de Flexinol.

Estos alambres pueden contraerse hasta un 10% de su longitud.

La figura 2.9 muestra un robot hexápodo que mueve sus patas gracias a esta tecnología.

Fig. 2.9: Hexápodo movido por alambres de Nitinol.

2.2.5 Músculos artificiales

Un músculo artificial es un tubo compuesto por una membrana que

es capaz de contraerse longitudinalmente y expandirse radialmente

al ser presurizado con un gas, típicamente aire. La figura 2.10

muestra un músculo artificial en tres estados de actividad: relajado,

semi-contraído y contraído totalmente8.

El músculo está compuesto por la membrana, dos terminales, y

una válvula.

Para contraer el músculo, es necesario abrir la válvula e inyectar aire presurizado en el interior

del músculo, haciendo que se contraiga. Para relajarlo basta con abrir la válvula y extraer el

aire9.

Para la utilización de este tipo de actuador es necesario contar con una fuente de aire

presurizado, que puede ser un compresor, un tanque de aire presurizado previamente o la

combinación de ambos elementos.

8 http://lucy.vub.ac.be/gendescription.htm

9 http://www.shadowrobot.com/airmuscles/overview.shtml

Fig. 2.10: Músculo artificial de la compañía Schadow Robot.



2.2.6 Pistones neumáticos e hidráulicos

Un pistón funciona haciéndole llegar algún vapor (neumático) o líquido

(hidráulico) a su interior, generando una presión que hace que el brazo

móvil se desplace en cada sentido, dependiendo de si aumenta la presión

o disminuye esta (ver figura 2.11).

Estos dispositivos suelen utilizarse en estructuras mecánicas grandes y

pesadas, que no requieran de una velocidad de actuación muy elevada,

pues suelen ser lentos, por este motivo no suelen utilizarse en robótica móvil, sí en brazos

robóticos.

2.3 Placas de circuito impreso comerciales

En el mercado existen innumerables placas de circuito impreso que desempeñan tareas

relacionadas con la robótica, siendo las más atractivas para este campo las controladoras de

motores y servomotores, a continuación se mostrarán algunas de estas placas y sus

características.

En las figuras 2.12, 2.13 y 2.14 se muestran tres ejemplos de placas

controladoras de servomotores que se comercializan actualmente.

La placa de la figura 2.12 permite el control de hasta 32

servomotores simultáneamente a través de un puerto serie

RS23210

.


servomotores simultáneamente a través de un puerto USB o serie

(RS232)11

.


servomotores simultáneamente a través de un bus I2C12

.

Estas placas se suelen utilizar para la sincronización de múltiples

servomotores en proyectos de robótica móvil con patas y en

manipuladores (brazos robóticos).

10

http://www.lynxmotion.com/Product.aspx?productID=395 11

http://www.electan.com/robotica/6/controladora-30-servos-usb/ 12

http://www.acroname.com/robotics/parts/R240-SD21.html

Fig. 2.11: Pistones Hidráulicos.

Fig. 2.13: Controladora de servos ELECTAN.

Fig. 2.14: Controladora de servos por I2C.

Fig. 2.12: Controladora de servos SSC32.



En el presente trabajo se ha optado por el diseño y desarrollo de una placa controladora de

servomotores propia, en siguientes capítulos se abordará este tema.

2.4 Sensores

Los sensores son los sentidos de los robots, existen muchos tipos de sensores, desde los más

sencillos, como los detectores de luz, hasta los sensores CCD de imágenes, pasando por

sensores de distancia por infrarrojos y ultrasonidos, de movimiento, de presencia y de campos

magnéticos, entre otros.

A continuación se enumeran los diferentes tipos de sensores existentes en el mercado:

Sensor de distancia por ultrasonidos.

Sensor de distancia por infrarrojos.

Sensor de aceleración, o también llamado acelerómetro.

Sensor de sonidos (micrófono).

Sensores de temperatura.

Sensores de iluminación (LDR)

Detectores de colisión, también llamados bumpers.

Detectores de movimiento por infrarrojos.

Detectores de vibración.

Detectores de campos magnéticos, también llamados brújulas digitales.

Detectores de gravedad (inclinación).

Cámaras de video.

Sensor de presión resistivo.

En el presente trabajo se ha utilizado un sensor ultrasónico de distancias, específicamente el

SRF08, que es capaz de medir distancias de hasta 6 metros, además es capaz de medir

intensidad luminosa gracias a una LDR que incorpora. También se ha utilizado una webcam

Creative Live! Cam como sensor de imágenes para la visión artificial.

2.5 Baterías

Las baterías son utilizadas como fuente de energía de a bordo en robots móviles. Existen en el

mercado muchos tipos de baterías13

:

Plomo

Níquel Cadmio

Níquel e Hidruro Metálico

Iones de Litio.

Polímero de Litio.

13

Más información en: http://www.avele.org/index.php?option=com_content&view=article&id=21&Itemid=26



Antes de describir cada tipo de batería, es necesario definir los conceptos “efecto memoria” y

“auto descarga”, que serán utilizados más adelante.

Efecto Memoria:

El efecto memoria es un fenómeno que reduce la capacidad de las baterías al ser cargadas de

forma incompleta14

. Se produce cuando se carga una batería sin haber sido descargada del

todo o se interrumpe la carga antes de que esta finalice.

El efecto memoria consiste en la formación de cristales de mayor tamaño de lo normal en el

interior de las celdas de la batería, ocasionando que unos pocos cristales estén en contacto

entre sí y con los electrodos de la celda (debido a su tamaño mayor de lo habitual). La figura

2.15 muestra en la imagen a) los cristales de tamaño normal en una batería de Níquel Cadmio

(1 micrón) y en la imagen b) los cristales producidos debido al efecto memoria en este tipo de

batería (mayor a 10 micrones).

a) b)

Fig. 2.15: Efecto memoria.

a) Cristales normales en una batería de Níquel Cadmio.

b) Cristales formados en una batería de Níquel Cadmio debido al efecto memoria.

Dependiendo del tipo de batería, el efecto memoria será más o menos intenso, siendo las de

Níquel Cadmio las más propensas.

Para evitar el efecto memoria basta con realizar cargas completas a las baterías cada cierto

tiempo.

Auto descarga:

Las baterías sufren también de un efecto de auto descarga, o sea, pierden parte de su energía

cuando no son utilizadas.

Una batería de Níquel Cadmio puede perder cerca del 10% su energía en las primeras 24

horas. Normalmente, una batería con una tasa de auto descarga superior a 30% al día deberá

ser reciclada.

14

http://medellincelular.com/consejos/tipos_de_baterias.pdf



El efecto de auto descarga depende de la temperatura de la batería, siendo mayor cuanto

mayor sea la temperatura.

A continuación se analizarán algunos tipos de batería existentes en el mercado que son

utilizadas en robótica, exponiendo sus pros y sus contras.

2.5.1 Baterías de Plomo

Las baterías de plomo son un tipo de batería muy común en automóviles. Suelen dar 6, 12 u

otro múltiplo de 6 V. La tensión que suministra cada celda es de 2 V. Tienen una gran

capacidad de corriente que las hacen ideales para los motores de arranque de vehículos.

Este tipo de batería consiste en un depósito de ácido sulfúrico y dentro de él una serie de

placas de plomo dispuestas alternadamente.

Generalmente, las placas positivas están recubiertas o

impregnadas de dióxido de plomo (PbO2), y las negativas

están formadas por plomo esponjoso. Este estado inicial

corresponde a la batería cargada, así que el electrolito

agregado inicialmente debe corresponder a la batería con

carga completa (densidad 1.280 g/ml).

Según el número de placas, la intensidad de la corriente suministrada será mayor o menor.

Este tipo de batería presenta muy poco efecto memoria y su grado de auto descarga es

también muy bajo (alrededor del 5% de su carga al mes).

El principal inconveniente de estas baterías para su aplicación en robótica es el elevado peso

que presentan, así como su gran tamaño. La figura 2.16 muestra una batería de plomo de

aplicación en automóviles convencionales no híbridos.

2.5.2 Baterías de Níquel Cadmio

Este tipo de batería presenta un cátodo de hidróxido de níquel y un ánodo de un compuesto de

cadmio. El electrolito es hidróxido de potasio. Esta configuración de materiales permite recargar

la batería una vez está agotada, para su reutilización.

Las baterías de Níquel Cadmio tienen muy baja densidad de energía: tan sólo 50 Wh/kg; lo que

hace que tengan poca capacidad en comparación con su peso.

Fig. 2.16: Batería de plomo.



Admiten sobrecargas de corriente, se pueden seguir cargando cuando ya

no admiten mas carga sin que esto represente peligro para la batería,

aunque la carga sobrante no la almacenarán, pueden funcionar en un

amplio rango de temperaturas.

La tensión de cada celda es de 1,2V y son muy propensas al efecto

memoria, debido a esto se hace imprescindible el uso de un cargador

diseñado para este tipo de baterías y respetar los ciclos de

carga – descarga.

Debido al efecto nocivo del cadmio para el medio ambiente y a la introducción en el mercado

de las baterías de Níquel e Hidruro Metálico, las baterías de Níquel Cadmio se han dejado de

producir y comercializar.

La figura 2.17 muestra baterías de Níquel Cadmio de diferentes tamaños y capacidades.

2.5.3 Baterías de Níquel e Hidruro Metálico

Estas baterías son muy similares a las de Níquel Cadmio en su

estructura, presentan un ánodo de hidróxido de níquel y un cátodo

de una aleación de hidruro metálico. Este tipo de baterías se

encuentran menos afectadas por el efecto memoria, no funcionan

bien en frío extremo, reduciendo drásticamente la potencia eficaz

que puede entregar.

La tensión proporcionada por una celda es de 1,2V, la densidad de energía es un poco mayor:

80 Wh/Kg.

La figura 2.18 muestra varias baterías de Níquel e Hidruro Metálico, de diferentes tamaños y

capacidades.

2.5.4 Baterías de Iones de Litio

Las baterías de Iones de Litio (Li-ion) tienen un ánodo de grafito y un cátodo de óxido de

cobalto, trifilina (LiFePO4) u óxido de manganeso.

Su desarrollo es más reciente, y presentan altas densidades de energía (115 Wh/Kg). No

admiten sobrecargas y sufren mucho cuando éstas suceden, por lo que suelen llevar acoplada

circuitería adicional para conocer el estado de la batería y la cantidad de carga que se les

demanda, y evitar así tanto la carga excesiva, como la descarga completa.

Fig. 2.17: Baterías de Níquel Cadmio.

Fig. 2.18: Baterías de Níquel e Hidruro Metálico.



Estas baterías apenas sufren el efecto memoria y pueden cargarse

sin necesidad de estar descargadas completamente, sin reducción de

su vida útil.

La celda de iones de litio presenta una gran variación de la tensión

que entrega a medida que la carga se agota, siendo los siguientes

valores, los proporcionados:

A Plena carga: Entre 4.2V y 4.3V dependiendo del fabricante.

A carga nominal: Entre 3.6V y 3.7V dependiendo del fabricante.

A baja carga: Entre 2,65V y 2,75V dependiendo del fabricante (este valor es

recomendado, no es un límite).

La capacidad usual suele ser de entre 1.5 y 2.8 Amperios

La figura 2.19 muestra una batería de iones de litio utilizada en

telefonía móvil.

2.5.5 Baterías de Polímero de Litio.

Son una variación de las baterías de iones de litio (Li-ion) descritas

anteriormente, sus características son muy similares, pero tienen

una mayor densidad de energía, así como una tasa de descarga

bastante superior.

Estas baterías tienen un tamaño más reducido respecto a las de otros componentes. Su

tamaño y peso las hace muy útiles para equipos pequeños que requieran potencia y duración,

como por ejemplo un robot.

La figura 2.20 muestra una batería de polímero de litio empleada en aeromodelismo.

2.6 Algoritmos empleados en robótica móvil

La robótica es todavía una ciencia joven, una gran comunidad de científicos e ingenieros

continúa investigando sus diferentes áreas. Como fruto de esta investigación han surgido

muchas técnicas y algoritmos relacionados con la generación de movimientos, control y

navegación en robots móviles.

A continuación se mencionarán algunos de estos algoritmos, describiendo sus objetivos y

características principales.

Fig. 2.19: Batería de Iones de Litio para teléfono móvil Nokia.

Fig. 2.20: Batería de Polímeros de Litio empleada en aeromodelismo.



2.6.1 Generación de movimientos en robots móviles y manipuladores

Para que un robot se mueva, este debe determinar la posición a establecer en cada una de sus

articulaciones para lograr una pose determinada y posteriormente sincronizar los movimientos

de todas sus articulaciones para que el cambio de una pose a otra sea el necesario para

generar locomoción u otro movimiento útil.

Para lograr lo anterior se han creado varios algoritmos, a continuación se describirán los más

utilizados.

2.6.1.1 Cinemática inversa

El problema cinemático inverso consiste en encontrar los valores que deben adoptar las

coordenadas articulares del robot q = [q1, q2, . . . , qn] para que su extremo se posicione y

oriente según una determinada localización espacial, o sea, para posicionar el robot de una

forma determinada, qué valores angulares debo tener en cada articulación [5].

En la actualidad existen procedimientos genéricos susceptibles de ser programados para la

resolución de la cinemática inversa y obtener la n−tupla de valores articulares que posicionen y

orienten el extremo final. Sin embargo, el principal inconveniente de estos procedimientos es

que son métodos numéricos iterativos, que no siempre garantizan tener la solución en el

momento adecuado. De esta manera, a la hora de resolver el problema cinemático inverso es

mucho más adecuado encontrar una solución cerrada, que se adapte lo mejor posible a la

necesidad puntual del robot que se está programando15

[5].

En siguientes capítulos de este trabajo se expondrá la solución específica que se ha dado al

problema de la cinemática inversa del robot que se ha creado.

2.6.1.2 Locomoción fija en robots móviles con patas

El algoritmo de locomoción fija establece el uso de tablas de búsqueda para determinar qué

articulaciones se mueven a qué posición en cada momento del tiempo. [6]

Se cuenta con tablas similares a la mostrada en la tabla 2.1, una para cada articulación.

El funcionamiento es el siguiente:

Dado el tiempo t, el robot moverá cada una de sus articulaciones al valor que se

encuentre en las tablas, en dicho momento t.

Si en la tabla no hay ningún valor en esa posición, el robot no moverá dicha articulación

en ese tiempo.

15

https://disclab.ua.es/robolab/



Los tiempos suelen indicarse como un entero que se incrementa o como un intervalo

de tiempo desde el evento anterior.

Tabla 2.1: Tabla de búsqueda para una articulación en el algoritmo de locomoción fija.

Este algoritmo suele utilizarse para generar secuencias predefinidas en robots, como por

ejemplo un baile, o la secuencia de locomoción en un robot con patas. [6]

El algoritmo, una vez creadas las tablas, se comporta de forma rígida, siendo poco adaptable a

cambios de ambiente del robot. [6]

2.6.1.3 Locomoción libre en robots móviles con patas

El algoritmo de locomoción libre determina qué articulación mover y a qué posición

dependiendo de variables del robot y el entorno de este, como pueden ser el centro de

gravedad actual del robot, la inclinación del terreno, la presencia de obstáculos, etc.

Este algoritmo es muy dependiente de la morfología del robot, es decir, de la forma del cuerpo,

número de patas, etc. [6, 7]

A continuación se explicará brevemente el caso de un robot hexápodo.

En un robot hexápodo cada movimiento es determinado por el vector de dirección de la

locomoción y por la posición del centro de gravedad del robot, siendo de vital importancia la

monitorización en todo momento de dicho centro de gravedad para no comprometer nunca la

estabilidad del robot. [8]

Entonces, lo primero que se debe determinar en cada iteración es la posición del centro de

gravedad del robot, para esto puede ser necesario incluir hardware específico en el robot,

como por ejemplo, sensores de presión en cada pata. [6, 7]

Una vez determinada la posición del centro de gravedad, se analiza que patas pueden ser

levantadas sin que se comprometa la estabilidad.

La figura 2.21 muestra un robot hexápodo, al cual se ha superpuesto un diagrama de regiones

determinadas por las posiciones actuales de sus patas. La tabla 2.2 muestra las patas que

Tiempo Posición

1 30º

2 0º

3 -

4 120º



pueden levantarse cuando el centro de gravedad del robot se encuentra en cada región de la

figura.

En cada iteración del algoritmo se determina [7]:

Vector de dirección de locomoción.

Proyección del centro de gravedad actual en el polígono de la figura 2.21.

Para cada pata que se puede mover (determinada por la tabla 2.2):

o Determinar la nueva posición de la pata.

o Cálculo del nuevo centro de gravedad del robot.

o Se selecciona la pata que otorgue más estabilidad al robot en la nueva

posición.

Mover la pata.

El resultado de este algoritmo es un movimiento mucho más adaptable a los cambios del

entorno del robot en comparación con el algoritmo de locomoción fija [6, 7].

2.6.2 Algoritmos de percepción computacional

2.6.2.1 Clasificador basado en características tipo Haar

Dada la importancia que va teniendo actualmente la navegación visual en robots móviles

mediante el uso de una, o dos cámaras de vídeo, se describirá a continuación un algoritmo de

reconocimiento de patrones en imágenes que puede ser utilizado como punto de partida para

la navegación visual, este algoritmo es llamado Clasificador basado en características tipo

Haar.

Región Patas

A P4, P5, P6

B P3, P5, P6

C P1, P2, P4

D P1, P2, P3

E P2, P3, P4, P6

F P1, P3, P4, P5

G P1, P2, P3,P4,P5,P6

H P2, P4, P6

I P1, P3, P5

Fig. 2.21: Robot hexápodo, vista superior. Regiones para el algoritmo de locomoción libre.

Tabla 2.2: Patas que pueden moverse en el algoritmo de locomoción libre según la región en la que se encuentre el centro de gravedad del robot.



El método de clasificación se divide en tres etapas principales:

Calculo de Imagen Integral.

Extracción de Características con Filtros Base Haar.

Clasificación con AdaBoost.

Cálculo de Imagen Integral:

La imagen integral es una representación intermedia que nos

permite hacer cálculos más rápido en regiones rectangulares de

la imagen original. Se define como una matriz bidimensional, en

la cual, cada localización (x,y) es la suma de los valores

numéricos de los píxeles contenidos arriba y a la izquierda del

mismo punto (x,y) en la imagen original. [9]

En la figura 2.22 se puede apreciar este concepto: el valor de la

posición (x,y) en la imagen integral es igual a la suma de todos

los pixeles de la región sombreada en la imagen original.

Extracción de Características con Filtros Base Haar:

Las características tipo Haar se utilizan en el

reconocimiento de patrones en imágenes, a la imagen se

inscriben rectángulos orientados de forma horizontal,

vertical y diagonal, los cuales actúan como ventanas para el

cálculo de sumas de pixeles en la imagen, la figura 2.23

muestra la forma de dichas ventanas. [9, 10]

En la figura 2.23 se puede apreciar que cada rectángulo posee regiones claras y regiones

oscuras, a continuación se describirá cómo son utilizadas dichas ventanas a la hora de extraer

las características de la imagen.

La característica se calcula mediante la diferencia de las

sumas de los píxeles de las regiones oscuras y las claras.

El valor obtenido permite caracterizar las diferencias de

contraste de las imágenes, siendo útiles para detectar

gradientes y bordes. [9, 10]

Es necesario mencionar que dependiendo de la orientación

de las regiones (ver rectángulos horizontales, verticales y

Fig. 2.23: Características tipo Haar.

Fig. 2.22: Imagen integral, el valor de la imagen integral en el punto (x,y) es la suma de todos los píxeles que pertenecen a la parte sombreada en la imagen original.

Fig. 2.24: Características tipo Haar que implementa el detector de OpenCV.



diagonales), de las características empleadas, el clasificador será capaz de detectar bordes

horizontales, verticales y diagonales. [10]

El detector implementado en las librerías OpenCV utiliza las características Haar mostradas en

la figura 2.24. [11]

Clasificación con AdaBoost:

AdaBoost es un algoritmo propuesto en [9, 12] y es usado para la construcción de mejores

clasificadores que resultan de la combinación lineal de clasificadores más simples.

Utilizando varios clasificadores simples (que utilizan una sola característica de las

anteriormente descritas), es entrenado un clasificador resultante de la combinación lineal de

estos, partiendo de muchas imágenes del objeto que se quiere reconocer. Una vez concluido el

entrenamiento, el clasificador es capaz de detectar los objetos en una imagen.

Antes de pasar al algoritmo de entrenamiento es necesario definir los siguientes conceptos:

ht(x): Clasificador débil o característica tipo Haar.

H(x) = sign(f(x)): Clasificador final, donde:

2.6.2.2 Algoritmo de entrenamiento del clasificador según [12] y adaptado al reconocimiento

de patrones en imágenes [11]:

1 Calcular las imágenes integrales de cada imagen que será utilizada en el entrenamiento.

Sea X el conjunto de todas las imágenes integrales que serán utilizadas en el

entrenamiento.

2 Representar las imágenes y su clase con (x, y), donde x X es la imagen integral e y es su

clase (-1: imagen negativa, 1: imagen positiva).

3 Se define m: cantidad de imágenes que se utilizará en el entrenamiento.

4 Para cada: (x1, y1), . . . , (xm, ym); xi X, yi {−1, 1}

4.1 Inicializar los pesos W1(i) = 1/m

4.2 Iterar por t = 0, … , T-1, (t: clasificador débil, T: número de clasificadores débiles a

emplear):

a) Seleccionar el clasificador base ht(xi) respecto al peso del error:

Seleccionando el clasificador base que minimice el error.



b) Calcular:

c) Actualizar los pesos W:

Donde ei = 0 si xi es clasificado correctamente, si no ei = 1.

5 Finalmente, obtener un clasificador más robusto:

2.7 Proyectos actuales de robótica móvil

Actualmente existen innumerables proyectos de robots móviles con patas:

Investigativos: Asimo, BigDog, RHex.

Comerciales: Aibo, Lynxmotion, Micromagic.

Educativos e independientes: Pucho, Phobos, Hexpaider.

2.7.1 Asimo16

ASIMO es el acrónimo de "Advanced Step in Innovative Mobility": paso avanzado en movilidad

innovadora. Es un robot humanoide creado en el año 2000 por la empresa Honda (ver figura

2.25).

La primera versión del robot fue creada en 1986. El resultado es ASIMO, un robot humanoide

tecnológicamente muy avanzado, capaz de andar, correr, subir y bajar escaleras, girarse

suavemente e imitar muchos otros movimientos humanos.17

18

En septiembre de 2007, la compañía presentó en Barcelona

(España) la última versión de ASIMO, que mide 130 cm, pesa 54

kg y cuenta con varias aplicaciones procedentes de la inteligencia

artificial: puede identificar y coger objetos, entender y dar

respuesta a órdenes orales e incluso reconocer las caras de

algunas personas.

16

http://world.honda.com/ASIMO/ 17

http://www.roboticspot.com/especial/asi2004/asi2004.php 18

http://www.abadiadigital.com/articulo/historia-de-los-robots-de-honda-del-proyecto-e0-a-asimo/

Fig. 2.25: Robot humanoide ASIMO de Honda.

http://es.wikipedia.org/wiki/Acr%C3%B3nimo

http://es.wikipedia.org/wiki/Robot

http://es.wikipedia.org/wiki/Humanoide

http://es.wikipedia.org/wiki/2000

http://es.wikipedia.org/wiki/Honda




El robot ASIMO cuenta con los siguientes sensores19

:

Sensor de superficie del suelo: es un sensor láser, que utiliza para determinar la

inclinación del suelo y los obstáculos que podría haber, como por ejemplo, huecos.

Cámara estereoscópica: sensor compuesto por dos cámaras de vídeo situadas en la

posición de los ojos.

Dos sensores de distancias por ultrasonidos, uno en el pecho y otro en la espalda.

Dos micrófonos situados en su cabeza, para el reconocimiento de sonidos.

Un giroscopio y un acelerómetro situados en el torso, utilizados para mantener el

equilibrio.

Sensores de presión en los pies.

2.7.2 BigDog20

BigDog es un robot cuadrúpedo dinámicamente estable para

uso militar. Fue creado en 2005 conjuntamente por las

compañías Boston Dynamics y Foster-Miller, el Laboratorio de

Propulsión a Chorro de la Nasa y la Concord Field Station de

la Universidad de Harvard.21

(ver figura 2.26)

Mide 0,91 m de largo, por 0,76 de alto y pesa 110 kg; más o

menos como una mula pequeña.19

Es capaz de atravesar terrenos complicados a una velocidad de 6,4 km/h cargando hasta 150

kg de peso y de subir pendientes de 35°. Un ordenador de a bordo controla la tracción, en base

a las entradas que recibe de los múltiples sensores con los que cuenta el robot, así como la

navegación y el equilibrio.19

BigDog está alimentado por un motor 15-HP go-kart de dos tiempos y un cilindro a 9.000 rpm,

el cual acciona una bomba hidráulica, la cual a su vez acciona los actuadores de las piernas.

Cada pierna tiene cuatro actuadores, dos para el junte con la cadera, uno para la rodilla y otro

para el tobillo, por lo que cada robot tiene un total de 16.

Cada actuador consiste de un cilindro hidráulico, una servoválvula y sensores de fuerza y

posición.

El ordenador de a bordo consta de una placa base PC/104 modificada, con un procesador

Pentium 4. Utiliza QNX como sistema operativo.

19

http://nosoyfriky.wordpress.com/2009/10/08/asimo-sensores-y-grados-de-libertad/ 20

http://www.bostondynamics.com/robot_bigdog.html 21

http://www.bostondynamics.com/img/BigDog_IFAC_Apr-8-2008.pdf

Fig. 2.26: Robot cuadrúpedo militar BigDog.

http://es.wikipedia.org/wiki/Cuadr%C3%BApedo


http://es.wikipedia.org/w/index.php?title=Boston_Dynamics&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Foster-Miller&action=edit&redlink=1

http://es.wikipedia.org/wiki/Laboratorio_de_Propulsi%C3%B3n_a_Chorro

http://es.wikipedia.org/wiki/Laboratorio_de_Propulsi%C3%B3n_a_Chorro

http://es.wikipedia.org/wiki/Nasa

http://es.wikipedia.org/wiki/Universidad_de_Harvard

http://es.wikipedia.org/wiki/Mula

http://es.wikipedia.org/wiki/Motor_de_dos_tiempos

http://es.wikipedia.org/wiki/Rpm

http://es.wikipedia.org/wiki/Bomba_hidr%C3%A1ulica

http://es.wikipedia.org/wiki/Actuador

http://es.wikipedia.org/wiki/Cilindro_hidr%C3%A1ulico

http://es.wikipedia.org/w/index.php?title=Servov%C3%A1lvula&action=edit&redlink=1

http://es.wikipedia.org/wiki/Placa_base

http://es.wikipedia.org/wiki/PC/104

http://es.wikipedia.org/wiki/Procesador

http://es.wikipedia.org/wiki/Pentium_4

http://es.wikipedia.org/wiki/QNX

http://es.wikipedia.org/wiki/Sistema_operativo



2.7.3 RHex22

RHex es un robot hexápodo autónomo todoterreno que

es capaz de caminar, correr y girar sobre cualquier tipo

de superficie, incluso es capaz de nadar en el agua.23

Cada una de sus 6 patas está formada por una

estructura semicircular y es animada por solo un

actuador (motor Paso a Paso), con lo que cuenta

entonces con 6 actuadores.

La figura 2.27 muestra al robot RHex sin la carcasa externa.

2.7.4 Aibo24

Aibo es un robot mascota fabricado por Sony. Tiene forma de

perro. Dispone de sensores que le evitan chocar contra objetos y

detección de contacto en su cuerpo. (ver figura 2.28)

Presentado en 1999, Aibo combina tecnologías robóticas, de

multimedia e inteligencia artificial para hacer posible que pueda

tratarse como si fuera un compañero interactivo.

Aibo es capaz de reconocer los gestos e incluso la actitud corporal de su dueño, es sensible a

las caricias, tiene mucha capacidad de movimientos y equilibrio.

A parte de haber sido concebido como una mascota, Aibo se ha usado para la investigación de

la inteligencia artificial, dado que integra una computadora, sistema de visión y motores de

articulación en un único paquete muy barato comparado con otros robots de investigación de

inteligencia artificial más comunes.

2.7.5 Otros proyectos de robótica

Existen muchos otros proyectos de robótica actualmente, algunos todavía se encuentran en

fase de desarrollo, otros se pueden comprar en kit para ensamblar.

Las imágenes 2.29, 2.30, 2.31 y 2.32 muestran robots hexápodos que utilizan servomotores de

radio control como actuadores, y las placas controladoras de servomotores mencionadas

anteriormente como cerebro del robot.

22

http://www.bostondynamics.com/robot_rhex.html 23

http://www.bostondynamics.com/dist/RHex.wmv 24

http://support.sony-europe.com/aibo/index.asp

Fig. 2.27: Robot hexápodo todoterreno RHex.

Fig. 2.28: Robot mascota Aibo de Sony

http://es.wikipedia.org/wiki/Robot

http://es.wikipedia.org/wiki/Mascota

http://es.wikipedia.org/wiki/Sony




Fig. 2.29: Robot hexápodo Lynxmotion Phenix. Fig. 2.30: Robot hexápodo de Micromagic.

Fig. 2.31: Robot hexápodo Hexpider. Fig. 2.32: Robot hexápodo A-Pod.

Los cuatro robots anteriores son muy similares, todos usan cinemática inversa para generar

sus movimientos, que son llevados a cabo por medio de sus actuadores de tipo servomotores

de radiocontrol y no presentan procesamiento a bordo, necesitan de un ordenador externo para

operar.

En este capítulo se han analizado las diferentes tecnologías que se utilizan en el campo de la

robótica así como los distintos proyectos existentes en la actualidad, algunos tan ambiciosos

como Asimo y BigDog, mientras que otros se han desarrollado con presupuestos muchísimo

menores, como es el caso de RHex, pero que no dejan de sorprender en cuanto a las

habilidades que son capaces de desarrollar.

En siguientes capítulos de este trabajo se abordará el diseño y desarrollo de un robot

hexápodo autónomo: WHEX 1, movido por 20 servomotores de radiocontrol y controlado por

una placa de circuito impreso de fabricación propia que integra 3 microcontroladores PIC de

microchip.

Bloque III

Especificación de requisitos


Capítulo


3



3 Especificación de requisitos

La presente especificación describe los requisitos que el robot WHEX 1 debe cumplir una vez

terminado su desarrollo. Dichos requisitos incluyen las funcionalidades, restricciones y

características de rendimiento del sistema así como de las interfaces mediante las cuales se

interactuará con este.

El propósito de esta sección de la memoria del proyecto es asegurar que los requisitos

plasmados en ella queden definidos y se comprendan correctamente.

3.1 Ámbito del sistema

El robot a desarrollar deberá funcionar con buen desempeño en un entorno controlado de

laboratorio. La figura 3.1 muestra de forma esquemática los componentes de dicho entorno.

Fig. 3.1: Entorno de laboratorio en el que se desempeñará WHEX 1.

Los robots WHEX 1 de la figura 3.1 se encuentran conectados a ordenadores remotos a través

de un enlace WIFI, configurado en modo de infraestructura, por tanto el entorno debe tener un

punto de acceso para la conectividad con los robots, e incluso entre ellos.

3.2 Descripción general de WHEX 1

En primer lugar, se caracterizará al robot que se desea crear, describiéndolo según los

siguientes criterios de clasificación.

Tipo (móvil, manipulador).

o Elementos que utiliza para la locomoción en robots móviles (ruedas, patas).

o Cantidad de patas en robots móviles con patas (0, 1, 2, 4, 6, 8).

o Grados de libertad en robots manipuladores(3 o más)

Razón de ser (propósito general o investigativo, propósito específico).

Autonomía de control (autónomo, control remoto).

Autonomía de energía (fuente de energía de a bordo, fuente de energía externa).



El robot WHEX 1 será un robot móvil de seis patas, de propósito general. Se ha concebido

como plataforma hardware para el entrenamiento en técnicas de programación robótica, por

este motivo debe ser programable.

WHEX 1 debe ser totalmente autónomo en cuanto a energía. En cuanto al control, WHEX 1

debe ser híbrido, permitiendo la posibilidad de ser controlado remotamente sin que esto impida

que en un momento determinado se comporte de forma autónoma.

3.3 Funciones

El robot WHEX 1 debe ser capaz de desplazarse, rotar, detectar objetos próximos e incluso

reconocerlos.

El cuerpo del robot debe poder adoptar posturas complejas que consideren los siguientes

aspectos:

Inclinación del cuerpo: el robot debe poder inclinar el cuerpo hasta un ángulo de 30

grados en todas direcciones.

Desplazamiento del centro de gravedad del cuerpo: el robot debe poder desplazar su

centro de gravedad realizando movimientos de alabeo.

Altura del cuerpo: el robot debe poder modificar la altura de su cuerpo.

Grado de apertura de patas: las patas del robot deben poder situarse más o menos

cercanas al cuerpo para así crear posturas más relajadas o contraídas.

Además de la adopción de posturas complejas, el robot deberá ser capaz de caminar y rotar,

manteniendo la postura que se halla establecido previamente, a varias velocidades y en

cualquier sentido. Para esto se definen 4 modos:

Modos 0 y 1: En estos modos el robot camina o rota moviendo solo una pata cada vez.

En el modo 0 la velocidad de desplazamiento es inferior a la alcanzada en el modo 1.

Modo 2: En este modo el robot es capaz de desplazarse y rotar moviendo

simultáneamente dos patas.

Modo 3: En este modo el robot mueve simultáneamente tres patas.

Mientras camina o rota, WHEX 1 deberá tener la posibilidad de detectar los obstáculos que

pudiese encontrar a su paso, impidiendo, por ejemplo, que se produzca un choque. Así mismo

se proporcionará la posibilidad de reconocer y clasificar objetos mediante el uso de una

cámara. Se podrá seleccionar la dirección a la cual apuntar la cámara.

3.4 Características de los usuarios

Los usuarios de WHEX 1 serán estudiantes de ingeniería que deseen aprender la

programación y la inteligencia artificial aplicada a robots móviles; por tanto, deben tener

conocimientos de programación en el lenguaje C++ y deben ser capaces de crear código e

incorporarlo al robot utilizando para ello cualquier entorno de desarrollo integrado existente.

3.5 Restricciones

El desarrollo del robot hexápodo WHEX 1 se condiciona a las siguientes restricciones:

1. El ancho y la longitud de la estructura mecánica creada no deben ser superiores a 50

cm.

2. El peso máximo que deberá tener el robot no sobrepasará los 2.5 Kg.

3. El cuerpo del robot y la distribución de las patas debe tener simetría bilateral.

4. El software de control se debe implementar en lenguaje C++.

5. El interfaz de comunicación del robot debe ser compatible con WIFI.



6. Puede dotarse al robot de capacidad de procesamiento de a bordo, en este caso, el

ordenador de a bordo debe interactuar con el hardware mediante un enlace RS232 y con

los ordenadores remotos mediante WIFI. En caso contrario se debe conectar un

adaptador WIFI – RS232 que proporcione la comunicación directa del hardware del robot

con el ordenador remoto.

7. No se tendrá en cuenta la posibilidad de que el robot camine en superficies irregulares.

8. No se tendrá en cuenta que el robot detecte precipicios como por ejemplo unas

escaleras; pero sí se tendrá en cuenta la detección de obstáculos como por ejemplo una

pared.

9. Se debe utilizar como elementos de control al chip PIC18F4525 o alguno inferior en

prestaciones.

10. El software de control del robot debe ser modular y fácil de modificar.

3.6 Requisitos específicos

En este apartado se presentan los requisitos funcionales que deben ser satisfechos por el

sistema desarrollado.

3.6.1 Requisitos funcionales

Los requisitos funcionales se han descrito mediante casos de uso, estos casos de uso se

muestran a continuación:

Caso de uso establecer datos de movimiento

Prioridad: Alta

Actor principal: El usuario

Actores de apoyo: No existen.

Casos de uso relacionados: (1) Comenzar a caminar y (2) comenzar a rotar.

Precondiciones: No existen.

Postcondiciones: Después de la ejecución del caso de uso se han establecido el vector de

dirección de movimientos, el grado de giro al desplazarse y la dirección de giro.

Escenario principal de éxito: Se escriben el vector de dirección de movimientos, el grado de

giro al desplazarse y la dirección de giro en los registros del hardware del robot.

Escenarios alternativos: (1) El grado de giro no es un valor real comprendido entre -1 y 1 y

(2) la dirección de giro no es un valor booleano.

Caso de uso establecer datos de postura

Prioridad: Alta



Casos de uso relacionados: (1) Adoptar postura.


Postcondiciones: Después de la ejecución del caso de uso se han establecido los parámetros

que describen la postura del cuerpo.

Escenario principal de éxito: Se escriben los datos de inclinación y altura del cuerpo, el grado

de separación de las patas y la posición del centro de gravedad en los registros del hardware

del robot.

Escenarios alternativos: (1) Los datos no se encuentran dentro de los rangos permitidos.



Caso de uso mover articulación

Prioridad: Alta

Actor principal: WHEX 1


Casos de uso relacionados: No existen.

Precondiciones: El robot no se encuentra en estado de reposo.

Postcondiciones: Después de la ejecución del caso de uso la articulación se ha movido hacia

el ángulo determinado.

Escenario principal de éxito: La articulación se mueve hacia el ángulo deseado a la velocidad

establecida.

Escenarios alternativos: (1) El ángulo es menor que 0 o mayor que 180 y (2) velocidad es

igual a cero.

Caso de uso mover pata

Prioridad: Alta



Casos de uso relacionados: (1) Mover articulación.

Precondiciones: El robot no se encuentra en estado de reposo y el punto hacia el cual se

desea mover la pata es alcanzable por esta.

Postcondiciones: Después de la ejecución del caso de uso el extremo de la pata se encuentra

en el punto deseado.

Escenario principal de éxito: Se comprueba que la pata se encuentra en posición.

Escenarios alternativos: (1) El punto está fuera del alcance de la pata.

Caso de uso leer distancia a objeto

Prioridad: Media

Actor principal: El usuario; WHEX 1




Postcondiciones: Con la ejecución del caso de uso se obtiene la medición de la distancia

hacia el objeto más cercano.

Escenario principal de éxito: Se lee una distancia mayor que cero.

Escenarios alternativos: (1) Se lee cero, significando que el sensor no se encuentra

preparado para realizar una medición.

Caso de uso reconocer objeto visualmente

Prioridad: Media




Precondiciones: La cámara se encuentra preparada para tomar una fotografía.

Postcondiciones: Con la ejecución del caso de uso se obtiene una lista de objetos clasificados

que han sido detectados por el robot.

Escenario principal de éxito: Se obtiene un listado (posiblemente vacío) de objetos

reconocidos.

Escenarios alternativos: (1) No se puede inicializar la cámara.



Caso de uso realizar seguimiento de objeto

Prioridad: Media



Casos de uso relacionados: (1) reconocer objeto visualmente; (2) mover articulación; (3)

mover pata y (4) leer distancia a objeto.

Precondiciones: Se ha detectado un objeto.

Postcondiciones: El robot mueve la cámara en dirección al objeto que se desea seguir,

enfocando en todo momento dicho objeto.

Escenario principal de éxito: El objeto se encuentra centrado en el espacio visual de la

cámara.

Escenarios alternativos: (1) Se pierde el objeto que se está siguiendo.

Caso de uso comenzar a caminar

Prioridad: Alta



Casos de uso relacionados: (1) Enviar datos de movimiento y (2) gestionar movimientos.

Precondiciones: El robot no se encuentra en estado de reposo; el modo establecido es menor

o igual que 4.

Postcondiciones: Con la ejecución del caso de uso se observa que el robot comienza a

caminar, cambiando su estado a Caminando.

Escenario principal de éxito: el robot se encuentra en estado Caminando.

Escenarios alternativos: (1) El robot no puede iniciar a caminar si se encuentra en estado de

reposo.

Caso de uso comenzar a rotar

Prioridad: Alta



Casos de uso relacionados: (1) Enviar datos de movimiento y (2) gestionar movimientos.

Precondiciones: El robot no se encuentra en estado de reposo; el modo establecido es menor

o igual que 4.

Postcondiciones: Con la ejecución del caso de uso se observa que el robot comienza a rotar

hacia la dirección establecida previamente, cambiando su estado a Rotando.

Escenario principal de éxito: el robot se encuentra en estado Rotando.

Escenarios alternativos: (1) El robot no puede iniciar a rotar si se encuentra en estado de

reposo.

Caso de uso iniciar detención

Prioridad: Alta



Casos de uso relacionados: (1) Gestionar movimientos.

Precondiciones: El robot se encuentra en estado Caminando o Rotando.

Postcondiciones: Con la ejecución del caso de uso se observa que el robot comienza la

secuencia de detención, cambiando su estado a Detenido.

Escenario principal de éxito: El robot se encuentra en estado Detenido.



Escenarios alternativos: (1) El robot no puede iniciar la detención si ya se encuentra en

estado de reposo.

Caso de uso adoptar postura

Prioridad: Alta



Casos de uso relacionados: (1) Mover pata y (2) establecer datos de postura.

Precondiciones: Se han establecido correctamente los datos de la postura que se desea

adoptar.

Postcondiciones: El robot adopta la postura definida por los datos de postura establecidos

con anterioridad y se mantiene inmovil.

Escenario principal de éxito: El robot se queda inmóvil, adoptando la postura deseada.

Escenarios alternativos: No existen

Caso de uso gestionar movimientos

Prioridad: Alta



Casos de uso relacionados: (1) Mover pata; (2) leer distancia a objeto y (3) reconocer objeto

visualmente.


Postcondiciones: El caso de uso se mantiene funcionando continuamente mientras el robot se

encuentre energizado.

Escenario principal de éxito: El robot realiza las acciones necesarias, dependiendo del

estado en el que se encuentre.

Escenarios alternativos: No existen

3.6.2 Requisitos de interfaces externas

En este apartado se definen los requisitos que deben cumplir las interfaces existentes en el

robot.

Interfaces de usuario

El robot WHEX 1 se podrá comandar desde un ordenador remoto a través de una conexión

inalámbrica. En el ordenador remoto deben facilitarse dos interfaces de usuario:

Interfaz de texto:

La primera interfaz de usuario debe ser de tipo texto. En esta interfaz se mostrará un mensaje

pidiendo los datos de usuario y contraseña para realizar la conexión con el robot. En caso de

que la conexión se realice correctamente se notificará al usuario y se comenzará a aceptar

comandos para enviar al robot.

La sintaxis de los comandos debe ser la siguiente:

<texto comando> [ = dato ]



En esta sintaxis el texto del comando debe ser una cadena alfanumérica que comience por una

letra y el dato, opcional, un valor numérico.

Interfaz gráfica:

La interfaz gráfica no exige ningún requisito preestablecido.

Interfaces hardware

No se han definido.

Interfaces software

El software controlador WHEX 1 debe brindar una interfaz de programación de aplicaciones

(API) que proporcione conectividad con los elementos hardware del robot, de forma tal que

pueda ser programada nueva funcionalidad sin la necesidad de modificar la ya existente.

Esta interfaz se definirá mediante clases y macros que formen, en su conjunto, un framework

de desarrollo de nuevas funcionalidades utilizando el lenguaje C++.

Interfaces de comunicación

La interfaz de comunicación que empleará el robot WHEX 1 para conectar con ordenadores

remotos será un enlace WIFI sobre el cual se encontrará montada una red TCP/IP de

direccionamiento dinámico, de modo que el entorno sea responsable de la funcionalidad

DHCP.

Esta red se utilizará para establecer conexiones inalámbricas TCP utilizando un protocolo

cliente servidor desarrollado íntegramente para el robot WHEX 1. El robot actuará en modo

servidor siempre que la conexión se establezca con un ordenador remoto y opcionalmente

podrá actuar como cliente en caso de programarse algún modo cooperativo entre varios robots

WHEX 1.

3.6.3 Requisitos de rendimiento

Los requisitos de rendimiento establecidos para WHEX 1 son los siguientes:

El robot debe responder a las órdenes enviadas a él prácticamente de forma inmediata,

permitiéndose retardos de menos de un segundo.

El tiempo de reconocimiento de objetos no debe ser mayor a 5 segundos.

La autonomía de las baterías debe ser mayor o igual a 30 minutos.

3.6.4 Requisitos de fiabilidad

La fiabilidad del sistema creado debe ser acorde con el propósito académico del mismo.

Es necesario que la estructura mecánica sea lo suficientemente robusta como para soportar

maltrato moderado causado por la programación errónea de movimientos por parte de los

usuarios: movimientos que puedan, en algún momento, luxar alguna articulación. Por este

motivo las articulaciones deben protegerse a varios niveles, desde el nivel mecánico hasta el

nivel de control para evitar que una orden errónea resulte en un movimiento fuera del rango de

la articulación.



Así mismo debe protegerse el circuito electrónico añadiendo algún dispositivo de seguridad que

desconecte la alimentación en caso de avería o sobre-consumo, por ejemplo un fusible.

Se desarrollarán baterías de prueba que deben pasar el firmware y el software de control para

que pueda darse por terminado su desarrollo.

La interfaz de programación de aplicaciones suministrada con el software de control del robot

debe realizar un chequeo exhaustivo de errores en la funcionalidad que los usuarios añadan,

de forma tal que errores en dicha funcionalidad no afecten el correcto funcionamiento del resto

del robot.

Arquitectura general del sistema


Capítulo

Arquitectura general del sistema 4



4 Arquitectura general del sistema

Una vez analizados los requisitos, se ha diseñado la arquitectura general del sistema a

desarrollar. El diagrama de la figura 4.1 muestra los componentes principales de dicha

arquitectura.

Fig. 4.1: Diagrama de capas que muestra los componentes principales de la arquitectura general del robot WHEX 1.



La arquitectura diseñada presenta tres capas principales:

Capa 1: Hardware del robot.

Capa 2: Servicios y acceso al hardware.

Capa 3: Software controlador WHEX 1.

A continuación se describen brevemente cada una de estas capas, sus componentes internos y

las funciones que desempeñan.

4.1 Capa 1: Hardware del robot.

La capa de hardware integra la estructura mecánica, los actuadores que mueven dicha

estructura, la electrónica de control y el sistema de alimentación. Esta capa es en sí el cuerpo

físico del robot.

La estructura mecánica da soporte a todo el sistema, es el cuerpo del robot y le permite actuar

en el mundo físico. La estructura mecánica también alberga todos los sistemas de a bordo del

robot.

La estructura se mueve por motivo del trabajo realizado por los actuadores que, en el caso del

robot WHEX 1, son servomotores de modelismo, específicamente los modelos:

HITEC HS311: Articulaciones verticales de las caderas y articulaciones del cuello.

BlueBird BMS620MG: Articulaciones de la rodillas.

BlueBird BMS630MG: Artiulaciones horizontales de las caderas.

El sistema de alimentación regula la tensión proveniente de las baterías del robot y envía dicha

tensión hacia la electrónica y los actuadores.

La electrónica está formada por dos elementos principales:

Ordenador de a bordo.

Placa controladora WHEX 1.

El ordenador de a bordo del robot es el nodo de procesamiento principal de toda la

arquitectura, su función es alojar y ejecutar el software controlador WHEX 1, responsable de

las funciones de alto nivel del robot.

La placa controladora WHEX 1 se encarga de la ejecución del firmware del robot. La función

principal de esta placa es servir de enlace entre el ordenador de a bordo del robot y los

sensores y actuadores de la estructura mecánica del mismo. Esta placa también se encarga de

las funciones de bajo nivel, por ejemplo la lectura de los sensores y la generación de señales

PWM de los servomotores, entre otros.



4.2 Capa 2: Servicios y acceso al hardware.

Esta capa está constituida por dos elementos principales:

El sistema operativo del ordenador de a bordo.

El firmware de la placa controladora WHEX 1.

Como sistema operativo del ordenador de a bordo se ha seleccionado la distribución de Linux

Debian 5.0, la cual se ha configurado para dar soporte a los recursos que necesita el robot:

Comunicación con otros ordenadores mediante WIFI.

Cámara web a modo de sensor de visión.

Puerto serie para la comunicación con el firmware de la placa controladora.

Sistema de sonido para la ejecución de las voces del robot.

El firmware de la placa controladora es el encargado de hacer accesible los recursos de la

placa al ordenador de a bordo, proveyendo funciones de acceso al hardware, consulta del

estado de sensores y realización de movimientos por medio de los actuadores.

4.3 Capa 3: Software controlador WHEX 1.

El software controlador WHEX 1 es el encargado de la gestión y control total de los recursos

del robot, incluye los siguientes elementos:

Framework WHEX 1.

Módulos de usuario.

El Framework WHEX 1 se ha diseñado con el objetivo de dar soporte a los programadores para

que puedan crear nuevas funcionalidades para el robot de forma sencilla.

El framework permite a los programas de control del robot (módulos de usuario) acceder a los

recursos de la plataforma hardware y permite que dichos programas se comuniquen entre sí.

La ventaja principal de este framework es que posibilita la creación de software de control muy

fácil de modificar en un futuro (debido a la modularidad) y por tanto facilita que el robot pueda

ser utilizado como plataforma académica para el aprendizaje de programación robótica.

Los módulos de usuario son los programas que rigen el funcionamiento global del robot.

Diseño y construcción de la estructura mecánica.


Capítulo

Diseño y construcción de la estructura mecánica

5



5 Diseño y construcción de la estructura mecánica.

Fig. 5.1: Elementos de la arquitectura del robot que aborda el capítulo.

Como puede verse en el esquema de la figura 5.1, en este capítulo se mostrará el diseño de

las partes mecánicas del robot hexápodo WHEX 1: la estructura mecánica y los servomotores;

explicando las decisiones que se han tomado, las piezas fabricadas y las adquiridas; así como

el proceso de fabricación que se ha seguido.

5.1 Cuerpo de WHEX 1.

Como se ha visto anteriormente en la especificación de requisitos, el cuerpo del robot WHEX 1

presenta simetría bilateral. Este hecho ha condicionado todo el diseño mecánico y funcional del

mismo.

El diseño mecánico de WHEX 1 se ha realizado utilizando la herramienta de diseño

tridimensional VariCAD 3.01.

Para el cuerpo del robot se han diseñado 3 piezas planas, de 3 mm de espesor. Las imágenes

5.2, 5.3 y 5.4 muestran el trazado y una vista tridimensional de cada una de estas piezas.

La pieza de la figura 5.2, llamada WHEX Body 1 se ha diseñado para ser fabricada utilizando

cualquier plancha de plástico, por ejemplo policarbonato o PVC, pudiendo ser algo flexible, ya

que la rigidez del cuerpo del robot vendrá dada por la combinación de esta pieza con las

siguientes que se han diseñado.



a) b)

Fig. 5.2: Pieza WHEX Body 1 diseñada en VariCAD.

a) Trazado bidimensional de la pieza utilizando la herramienta VariCAD 3.01.

b) Vista tridimensional de la pieza.

La figura 5.3 muestra el trazado en VariCAD y una vista tridimensional de la segunda pieza del

cuerpo del robot, llamada WHEX Body 2, la cual ha sido diseñada para ser fabricada en

aluminio de 2 mm. En esta pieza van fijos los servomotores de las caderas del robot.

a) b)

Fig. 5.3: Pieza WHEX Body 2 diseñada en VariCAD.





La figura 5.4 muestra la tercera pieza que se ha diseñado para conformar el cuerpo del robot,

llamada WHEX Body Cover. Esta pieza se utiliza como cubierta del ordenador de a bordo y su

función principal es protegerlo.

a) b)

Fig. 5.4: Pieza WHEX Body Cover diseñada en VariCAD.



La figura 5.5 muestra los componentes del cuerpo del robot WHEX 1 dispuestos según el orden

de montaje de las piezas. Los pasos de la secuencia de montaje son los siguientes:

1) Fijar cada servomotor a la pieza WHEX Body 2, utilizando los espaciadores y tornillos

mostrados en la figura 5.6b.

2) Fijar la pieza WHEX Body 1 a los espaciadores montados en el paso 1 utilizando las

tuercas de la figura 5.6b.

3) Fijar la pieza WHEX Body Cover al cuerpo del robot, utilizando los espaciadores,

tornillos y tuercas de la figura 5.6a.

Opcionalmente puede añadirse a la pieza WHEX Body Cover una malla metálica u otra

superficie plana para cubrir las cuatro aberturas de la misma

Una vez terminado el montaje, el cuerpo del robot debe asimilarse al esquema de la figura 5.7.

Es necesario mencionar que puede accederse al interior del robot, a través de la cubierta

(pieza WHEX Body Cover), quitándola temporalmente.

Para el montaje de la electrónica en el robot, se utilizan los agujeros para tornillos de la pieza

WHEX Body 2.



Fig. 5.5: Componentes del cuerpo del robot WHEX 1 dispuestos en orden de montaje.

1) Pieza WHEX Body Cover.

2) Espaciador, tornillo y tuerca utilizados para fijar la pieza WHEX Body Cover al cuerpo del robot

(ver figura 3.20a).

3) Pieza WHEX Body 1.

4) Espaciador, tornillo y tuerca utilizados para fijar la pieza WHEX Body 1 a la pieza WHEX Body 2 y

los servomotores (ver figura 3.20b).

5) Servomotores utilizados en WHEX 1.

6) Pieza WHEX Body 2.

1

2

3

4

5

6



a) b)

Fig. 5.6: Separadores, tuercas y tornillos utilizados en el montaje del cuerpo del robot.

a) Separador hexagonal de 15 mm de largo con terminales hembra – macho con rosca M3 y tornillo y tuerca

M3 utilizados en el montaje de la pieza WHEX Body Cover.

b) Separador hexagonal de 30 mm de largo con terminales hembra – macho con rosca M3 y tornillo y tuerca

M3 utilizados en el montaje de las piezas WHEX Body 1, WHEX Body 2 y los servomotores de las caderas

del robot.

Fig. 5.7: Estructura mecánica ensamblada del cuerpo del robot WHEX 1.

5.2 Patas de WHEX 1.

Para el diseño de las patas del robot hexápodo WHEX 1 se tuvieron en cuenta varios aspectos:

los grados de libertad que se debía otorgar a cada pata, la flexibilidad de los materiales que

debían ser utilizados y el máximo grado de torsión tolerable, entre otros.

Se diseñaron dos modelos de pata, uno con dos grados de libertad, mostrado en la figura 5.8a

y otro con tres, mostrado en la figura 5.8b.

a) b)

Fig. 5.8: Modelos de pata diseñados para el robot WHEX 1.

a) Modelo con dos grados de libertad en la cadera.

b) Modelo con tres grados de libertad, dos en la cadera y uno en la rodilla.



El modelo mostrado en la figura 5.8a es bastante sencillo, presenta dos grados de libertad

(ambos en la cadera), pudiendo ejecutar movimientos básicos como la traslación y rotación del

robot, pero no permite la adopción de posturas complejas (requisito necesario). Por otro lado, el

modelo mostrado en la figura 5.8b, al tener tres grados de libertad (dos en la cadera y uno en la

rodilla), permite un número muy elevado de movimientos y posturas, por este motivo, a pesar

de ser más complejo, se ha decidido utilizarlo para las patas del robot WHEX 1.

Al diseñar la pata según el modelo de tres grados de libertad, se han desarrollado dos piezas,

que deben ser fabricadas utilizando planchas de aluminio de 3 mm. Estas piezas se deben

fabricar en aluminio para garantizar una baja torsión mecánica, minimizando el error inducido

por la torsión; entonces, el error mecánico de cada pata, solo vendrá dado por la precisión de

los servomotores de cada articulación.

La figura 5.9 muestra la primera pieza fabricada, llamada Leg 1 y la figura 5.10 muestra la

segunda pieza Leg 2.

La figura 5.11 muestra de forma esquemática los componentes de la pata, en esta se puede

apreciar la forma en que deben montarse dichos componentes para conformar la estructura

mecánica.

La secuencia de montaje de cada una de las patas es la siguiente:

1) Fijar el servomotor de la rodilla a la pieza Leg 1, utilizando tornillos y tuercas

apropiados.

2) Fijar la pieza Leg 2 a la platina del servomotor de la rodilla. En este paso es necesario

tener en cuenta que el movimiento de la rodilla debe ser el correcto, es decir, el tope

Fig. 5.9: Trazado en VariCAD y representación tridimensional de la pieza Leg 1.

Fig. 5.10: Trazado en VariCAD y representación tridimensional de la pieza Leg 2.



superior del movimiento de la rodilla debe formar un ángulo de 180 grados con la recta

definida por los extremos de la pieza Leg 2 (ver figura 5.12a).

3) Fijar el otro extremo de la pieza Leg 2 a la platina del servomotor de la cadera. En este

paso es necesario también garantizar un rango de movimientos correcto de la

articulación de la cadera, o sea, el tope superior del movimiento debe formar un ángulo

de 90 grados con la horizontal (ver figura 5.12b).

4) Por último fijar la punta de goma antideslizante de la figura 5.13 al extremo de la pata.

Fig. 5.11: Componentes de la estructura mecánica de las patas del robot hexápodo WHEX 1.

1. Pieza Leg 1.

2. Tornillo y tuerca de fijación del servomotor de la rodilla.

3. Servomotor de la rodilla.

4. Tornillos y tuercas de fijación de la pieza Leg2 a las platinas giratorias de los servomotores de la

cadera y la rodilla.

5. Pieza Leg 2.

6. Servomotor de la cadera.

7. Tornillo y tuerca de fijación de la punta de goma de la pata.

8. Punta de goma antideslizante de la pata.

a) b)

Fig. 5.12: Rango permitido de movimientos de las articulaciones de la pata.

a) Rango de movimientos de la articulación de la rodilla.

b) Rango de movimientos de la articulación de la cadera.

1 2

3

4

5 6

7 8



Hecho lo anterior, la estructura terminada debe ser similar a la mostrada en la figura 5.14 y

debe poder moverse según los rangos de movimientos anteriormente descritos en la figura

5.12.

Fig. 5.13: Puntas de goma antideslizante comercializadas por la compañía Lynxmotion.

Fig. 5.14: Representación esquemática de la estructura mecánica de una pata del robot hexápodo WHEX 1 terminada.

Fig. 5.15: Soporte multifuncional para servomotores comercializado por la compañía Lynxmotion.

El siguiente paso en el montaje de las patas es unir las articulaciones de la cadera de

cada pata con el cuerpo del robot, para esto se ha utilizado el soporte multifuncional

para servomotores mostrado en la figura 5.15.

La figura 5.16 muestra de forma esquemática los pasos de la secuencia de montaje:

1. Primeramente fijar el soporte multifuncional a la platina del servomotor de la

cadera que se encuentra en el cuerpo del robot. En este paso es necesario

(como se ha hecho anteriormente con el resto de articulaciones) garantizar que

la articulación se mueva dentro del rango de movimientos permitido, que en

este caso es, para cada una de las patas del robot, el mostrado en la figura

5.17.

2. A continuación fijar el servomotor de la cadera que se encuentra en la pata, al

soporte multifuncional, como puede verse en la figura 5.16.

Fig. 5.16: Pasos de la secuencia de unión de cada pata al cuerpo del robot hexápodo WHEX 1 utilizando el soporte multifuncional para servomotores de Lynxmotion.

1

2



Fig. 5.17: Rango de movimientos de los servomotores de la cadera que se encuentran fijos al cuerpo del robot.

Una vez unidas las seis patas al cuerpo, la estructura mecánica del robot debe

parecerse al esquema de la figura 5.18.

Fig. 5.18: Estructura mecánica del cuerpo de WHEX 1, incluyendo las 6 patas.



5.3 Cabeza de WHEX 1.

La cabeza del robot WHEX 1 tiene la función principal de dar soporte a los sensores de

visión (Cámara Creative Live Cam) y de distancias por ultrasonidos (SRF08).

La cabeza cuenta con un mecanismo Pan & Tilt (a modo de cuello) que le permite

ajustar la dirección en que apuntan los sensores que soporta, para esto emplea dos

servomotores, uno para el desplazamiento vertical y otro para el horizontal.

El desarrollo de la cabeza se ha dividido en dos partes, la primera de ellas corresponde

a la elección del mecanismo Pan & Tilt del cuello y la segunda parte corresponde al

diseño de la plataforma donde se anclarán los sensores.

La figura 5.19 muestra el mecanismo Pan & Tilt que se ha optado utilizar, este es

comercializado en forma de kit por la empresa Lynxmotion. Este mecanismo está

formado por dos servomotores, un soporte multifuncional para servomotores (ver figura

5.15) y una platina en forma de C, mostrada en la figura 5.20.

Para montar los sensores en el mecanismo anterior se ha diseñado una pieza, llamada

Head 1, mostrada en la figura 5.21.

a) b)

Fig. 5.21: Pieza Head 1 diseñada en VariCAD.



Fig. 5.19: Mecanismo Pan & Tilt comercializado por la empresa Lynxmotion.

Fig. 5.20: Platinas en forma de C utilizadas en el mecanismo Pan & Tilt del cuello de WHEX 1



Esta pieza se ha diseñado específicamente para los sensores utilizados (cámara

Creative Live Cam y sensor de ultrasonidos SRF08); por tanto, en caso de querer

montar otros sensores, esta pieza deberá ser rediseñada específicamente para estos.

La figura 5.22 muestra la secuencia de montaje de la cabeza del robot hexápodo

WHEX 1, los pasos a seguir son los siguientes:

1) Fijar el soporte multifuncional para servomotores a la platina del servomotor A.

2) Fijar el servomotor B al soporte multifuncional para servomotores.

3) Unir los sensores a la pieza Head 1; para ello emplear los tornillos y tuercas

necesarios, además de la pieza auxiliar G empleada para fijar correctamente la

cámara.

4) Unir la pieza Head 1 con la platina C.

5) Fijar la platina C al resto del mecanismo Pan & Tilt ensamblado en los pasos 1

y 2.

Fig. 5.22: Secuencia de montaje de la cabeza del robot WHEX 1.

A. Servomotor responsable del movimiento horizontal de la cabeza.

B. Servomotor responsable del movimiento vertical de la cabeza.

C. Platina en forma de C.

D. Pieza Head 1.

E. Cámara web Creative Live Cam.

F. Sensor de distancias por ultrasonidos SRF08.

G. Pieza auxiliar empleada para fijar la cámara a la pieza Head 1.

Una vez terminado el montaje de la cabeza, esta debe ser semejante al esquema de la

figura 5.23.

1

2

5

3

4

A

B

C

C D E

F

G



a) b)

Fig. 5.23: Estructura mecánica de la cabeza del robot hexápodo WHEX 1.

a) Con los sensores montados.

b) Sin los sensores montados.

Ahora es necesario fijar correctamente la cabeza al cuerpo del robot,

para esto realizamos los pasos mostrados en la figura 5.24:

1. Fijar el servomotor responsable del movimiento horizontal de

la cabeza a la pieza WHEX Body Cover, utilizando para ello

los tornillos, tuercas y separadores necesarios.

2. Fijar todo el mecanismo de la cabeza a la pieza WHEX Body

1, utilizando para ello los tornillos, tuercas y separadores

necesarios, además de la pieza auxiliar mostrada en la figura.

Hecho lo anterior, ya se encuentra terminada la estructura mecánica

del robot, esta debe ser semejante a la estructura mostrada en la

figura 5.25.

Fig. 5.25: Estructura mecánica terminada del robot hexápodo WHEX 1.

Todas las piezas diseñadas fueron fabricadas de forma artesanal utilizando, entre otras

herramientas, una multifuncional Dremel.

1

2

Fig. 5.24: Secuencia de unión de la cabeza del robot al cuerpo.



La tabla 5.1 muestra los precios de cada componente empleado en la estructura

mecánica del robot WHEX 1.

Producto o componente Proveedor Precio unitario (Euro)

Cantidad utilizada

Precio Total (Euro)

Plancha de Policarbonato de 500 x 250 mm

Leroy Merlin 9.00 1 9.00

Plancha de aluminio de 500 x 250 mm

Leroy Merlin 12.00 2 24.00

Separador hexagonal 15 mm

www.ebay.es 0.10 9 0.90

Separador hexagonal 30 mm

www.ebay.es 0.15 24 3.60

Punta de goma Lynxmotion Lynxmotion 0.40 6 2.40

Mecanismo Pan & Tilt Lynxmotion 7.50 1 7.50

Soporte multifuncional para servomotor

Lynxmotion 4.50 6 27.00

Servomotor HITEC HS311 www.ebay.es 9.00 8 72.00

Servomotor Bluebird BMS630MG

www.ebay.es 18.00 6 108.00

Servomotor Bluebird BMS620MG

www.ebay.es 12.50 6 75.00

329.40

Tabla 5.1: Precios de los componentes de la estructura mecánica del robot WHEX 1.

A continuación se muestran imágenes reales de algunas de las piezas que han sido

fabricadas, así como de diferentes estados intermedios del montaje del robot.

Fig. 5.26: Pieza WHEX Body 1.

Fig. 5.27: Pieza WHEX Body 2.

Fig. 5.28: Pieza WHEX Body 1 con el ordenador instalado.

Fig. 5.29: Pieza WHEX Body 2 con servomotores.



Fig. 5.30: Cuerpo del robot WHEX 1. Fig. 5.31: Pata del robot WHEX 1.

Diseño y construcción de la electrónica.


Capítulo

Diseño y construcción de la electrónica

6



6 Diseño y construcción de la electrónica.

El presente capítulo describe el proceso de diseño y construcción de la parte electrónica del

hardware del robot WHEX 1. Se abordan los aspectos de la arquitectura del robot resaltados en

la figura 6.1.

Fig. 6.1: Elementos de la arquitectura del robot que aborda el capítulo.

La electrónica del robot está formada principalmente por tres componentes:

Sistema de alimentación.

Placa controladora WHEX 1.

Ordenador de a bordo.

El diagrama de la figura 6.2 muestra de forma muy detallada los componentes electrónicos del

hardware del robot WHEX 1 y las interfaces entre ellos. En este diagrama se puede apreciar

que la electrónica está dividida en dos secciones principales, la sección de alimentación y la

sección de procesamiento del robot.

La sección de alimentación incluye las baterías y el circuito de distribución de energía, que

tienen como función principal la alimentación de todas las partes del robot, creando fuentes de

energía estabilizadas y aisladas entre sí.

La sección de procesamiento del robot está formada por la placa controladora WHEX 1 y el

ordenador de a bordo. La placa controladora se encarga de las funciones de bajo nivel del

robot, como por ejemplo la gestión de los servomotores y el sensor de distancias por

ultrasonidos, la generación de secuencias de pasos y la expansión hardware mediante sus



múltiples puertos disponibles, entre otras. Por otro lado, el ordenador de a bordo debe ejecutar

las tareas de alto nivel del robot que le sean programadas.

Fig. 6.2: Componentes principales de la electrónica de WHEX 1.

6.1 Baterías:

Las baterías son la fuente de toda la energía que consume WHEX 1.

Existen en el mercado muchos tipos de baterías, las cuales han sido

analizadas en el capítulo Estado de la Cuestión.

Para WHEX 1 se ha optado por utilizar una batería de polímero de litio

(LIPO) de 7.4 V y 4300 mA. Esta batería consta de 2 celdas de polímero de litio conectadas en

serie. La figura 6.3 muestra la batería que utiliza WHEX 1.

Se ha decidido la utilización de este tipo de batería debido a:

La alta densidad de energía (energía por gramo de peso) que tiene, lo cual implica que

la batería tenga un reducido peso.

Fig. 6.3: Batería LIPO utilizada en WHEX 1.



El alto nivel de descarga que soporta (hasta 20 C), esto significa que puede descargar

hasta 20 x 4300 mA en varios segundos, lo cual es más que suficiente para la

necesidad de picos de energía del robot.

No presentan efecto memoria.

Se recargan muy rápidamente utilizando un cargador diseñado para baterías LIPO.

Es necesario advertir que estas baterías requieren un cuidado especial en su manipulación y

carga, ya que el uso indebido, los cortocircuitos o las cargas utilizando un cargador no

homologado para baterías de Polímero de Litio pueden ocasionar que la batería se deforme,

llegando a explotar si no se detecta a tiempo25

.

Debido a que el mayor problema de este tipo de baterías es que no toleran los cortocircuitos,

se ha colocado en su terminal positivo un fusible de 10 A. con esto se evita que la batería se

dañe por un fallo de hardware.

6.2 Circuito de distribución de energía

El circuito de distribución de energía es el encargado del rectificado y la estabilización de la

corriente que irá a los actuadores (servomotores), la placa controladora del robot y el

ordenador de a bordo, realizando las conversiones de tensión que sean necesarias.

La figura 6.4 muestra una representación esquemática de este circuito.

Fig. 6.4: Representación esquemática del circuito distribuidor de energía.

25

Manual de uso de baterías LIPO: http://www.rcmaterial.com/pdfs/LipoManualES.pdf



El circuito distribuidor de energía debe alimentarse a partir de las baterías del robot y generar

tres salidas con tensiones e intensidades de corriente máxima diferentes e independientes,

aisladas entre sí para evitar interferencias provenientes de los servomotores, que pudieran

generar un malfuncionamiento de la placa controladora y el ordenador de a bordo.

Estas salidas se generan utilizando fuentes de tensión conmutadas DC / DC, como se puede

ver en el diagrama de la figura 6.4.

El conmutador SW1 tiene la doble función del encendido / apagado del robot y la conexión

directa de la toma de carga con las baterías, para posibilitar cargarlas utilizando un cargador

para baterías LIPO externo. SW1, en la posición mostrada en la figura 6.4, cierra el circuito de

alimentación del robot, y en la otra posición apaga el robot y conecta la entrada de carga de las

baterías a estas.

Como se puede ver en el circuito, la salida destinada al ordenador de a bordo se toma

directamente de la entrada de las baterías, esto se hace así debido a que el ordenador cuenta

con una fuente ATX propia, la cual regula y estabiliza la tensión que lo alimenta.

La figura 6.5 muestra un UBEC (Ultimate Battery Eliminator Circuit) diseñado para aplicaciones

de modelismo, este se ha utilizado para generar la salida hacia la placa controladora. La figura

6.6 muestra también un UBEC de modelismo, de mayor capacidad, utilizado para generar la

salida hacia los servomotores, se ha requerido de dos de estos conectados en paralelo para

cumplir con los requerimientos de consumo de los servomotores.

6.3 Placa controladora WHEX 1

Como se ha mencionado anteriormente, la placa controladora WHEX 1 es la encargada de

todas las funciones de bajo nivel del robot, desde las más básicas (generación de señales

PWM para el control de los servomotores) hasta las más complejas (generación de secuencias

de pasos, generación de posturas del robot y lectura del sensor de distancias por ultrasonidos,

Fig. 6.5: UBEC de 5 V / 6 V, 3 A constantes y 5 A de pico, de marca TURNIGY, protegido contra interferencias.

Fig. 6.6: UBEC de 5 V / 6 V, 8 A constantes y 15 A de pico, de marca G.T. Power, protegido contra interferencias y con monitor del estado de carga de las baterías.



entre otros). Esta placa se ha desarrollado íntegramente y ha sido diseñada para el robot

WHEX 1; pero teniendo como principal objetivo de diseño, que pueda ser expandida mediante

módulos hardware adicionales, sin que esto implique la modificación de ninguna de las partes

de la placa.

La figura 6.7 muestra los componentes principales de esta placa, así como los conectores que

presenta.

Fig. 6.7: Esquema que representa los componentes y conectores de la placa controladora WHEX 1.

A la placa controladora llegan dos tensiones de alimentación diferente: 5 V para alimentar la

lógica y 6 V para alimentar los servomotores conectados (conectores de alimentación, ver

figura 6.7). Asimismo, esta placa recibe los comandos que debe ejecutar a través de un enlace

RS232 (Conector RS232 en la figura 6.7).

Para la comunicación con esta placa se ha diseñado un set de comandos. Este set de

comandos puede ser consultado en la tabla del Anexo A.

Los servomotores se conectan en cualquiera de los 48 conectores para servomotores que

integra, estos conectores están diseñados para funcionar con la mayoría de los servomotores

de radiocontrol que se encuentran disponibles en el mercado.



Además, la placa cuenta con los siguientes puertos de expansión, que serán explicados más

detalladamente en la sección 6.3.2.2:

8 puertos del bus I2C interno de la placa, a través de los cuales pueden ser

conectados a los microcontroladores del robot, otros microcontroladores externos,

sensores, y placas de expansión.

8 puertos para pulsadores. En estos puertos pueden conectarse hasta 8 pulsadores,

por ejemplo, para detectar si las patas del robot se encuentran apoyadas o no.

6 puertos digitales de 1 bit, o un puerto digital de 6 bits. Estos puertos se pueden

utilizar para la conexión de sensores que requieran de líneas digitales para la

interconexión con microcontroladores.

4 puertos analógicos. Estos se pueden utilizar para que el robot lea magnitudes

analógicas, como por ejemplo, la señal proveniente de una LDR (sensor de luz).

Como muestra de la capacidad de expansión de la placa, actualmente se encuentra conectado

un sensor de ultrasonidos SRF08 a uno de los 8 puertos I2C de esta.

Para la realización de sus funciones, la placa integra dos módulos principales: el controlador

principal WHEX 1 y el controlador de servomotores.

El controlador principal WHEX 1 es el encargado de recibir los comandos provenientes del

puerto RS232 y procesarlos, determinando la acción a realizar: la lectura o escritura de uno de

los puertos antes mencionados, la generación de una secuencia de acciones del robot, como

por ejemplo, comenzar a caminar o detenerse, etc.

En caso de que sea necesario, el controlador principal WHEX 1, debe generar comandos de

control de servomotores y enviarlos al controlador de servomotores, para que este los ejecute.

El segundo módulo es el controlador de servomotores, que solo tiene una tarea, generar y

mantener las 48 señales PWM independientes que se necesitan para controlar los 48

servomotores.26

Se ha requerido de un módulo aparte al Controlador Principal WHEX 1, debido

a la complejidad que tiene la gestión de 48 señales PWM independientes entre sí.

Como se puede ver en la figura 6.7, este módulo recibe los comandos que ejecuta a través del

bus I2C al que se encuentra conectado.

Además de los módulos descritos anteriormente, la placa controladora cuenta con un módulo

auxiliar responsable de la comunicación RS232 con el ordenador: el driver RS232 (ver figura

6.7).

26

Esta placa permite controlar hasta 48 servomotores, aunque el robot solo necesita 20.



6.3.1 Metodología de diseño hardware empleada.

Las metodologías de diseño hardware más utilizadas son las llamadas Bottom-Up y Top-Down.

En la metodología Bottom-Up, se comienza a partir de los componentes más simples del

diseño, agrupándolos en módulos hasta llegar al sistema como un todo, probando su

funcionamiento antes de la integración en cada etapa; esta metodología es válida para

sistemas relativamente pequeños, ya que en sistemas grandes se hace muy compleja la

integración de todas las partes. La metodología Top-Down describe primeramente al sistema

como una entidad, con entradas, salidas y un estado interno, es decir, desde el punto de vista

funcional; a continuación desciende cada vez más hacia sus componentes internos hasta llegar

a los elementos básicos de diseño. [13]

En el desarrollo de esta placa controladora se ha seguido una metodología Top-Down, que

concluye con la fabricación de un prototipo totalmente funcional. Para esto se han utilizado

herramientas de diseño asistido por ordenador, logrando reducir los tiempos de diseño y

fabricación del prototipo.

El diseño hardware asistido por ordenador se basa en un conjunto de aplicaciones informáticas

bajo un mismo entorno que las interrelaciona. Estos entornos de desarrollo de productos

electrónicos EDA (de sus siglas en inglés: Electronic Design Automation) controlan la totalidad

del proceso de desarrollo de un producto, desde la fase de diseño hasta su fabricación,

permitiendo cambios de diseño en cada iteración; por tanto, la característica principal de los

entornos EDA es la flexibilidad y la propagación de cambios entre las aplicaciones que

integran. [14]

La ventaja principal del uso de un entorno de diseño asistido por ordenador es la eliminación de

la necesidad de construcción de prototipos físicos para la validación y verificación del sistema

diseñado, ya que estos entornos incluyen, en cada iteración de diseño, una etapa de

simulación del hardware a varios niveles de abstracción; por tanto, solo es necesaria la

creación de un prototipo físico al final del proceso de diseño. [15]

El esquema de la figura 6.8 muestra el proceso iterativo de diseño hardware sin utilizar

simulación, resultando en iteraciones muy costosas en tiempo y recursos, ya que para validar y

verificar el diseño es necesario realizar un prototipo. [15]

Fig. 6.8: Proceso de diseño de hardware sin utilizar simulaciones.



El esquema de la figura 6.9 muestra el proceso de diseño de hardware utilizando la simulación,

con lo cual se consigue agilizar las iteraciones y reducir costes, ya que no es necesaria la

fabricación de prototipos en cada iteración. [15]

Fig. 6.9: Proceso de diseño de hardware utilizando simulaciones.

En este trabajo se ha seguido el ciclo de diseño con simulación de la figura 6.9. Esto ha

posibilitado validar el diseño sin la necesidad de construir prototipos intermedios y de este

modo fabricar la placa controladora una vez verificado su funcionamiento.

El diseño y la simulación de la placa se han realizado utilizado los entornos Labcenter

Electronics Proteus y Cadence Orcad 10.3. Para las etapas de Diseño del Esquemático,

Desarrollo de Firmware y Simulación del sistema se ha utilizado el entorno Proteus, mientras

que para el Diseño del Layout se ha utilizado Orcad.

6.3.2 Diseño de los diagramas esquemáticos de la placa controladora.

Como ya se ha visto en la figura 6.7, la placa controladora está formada principalmente por tres

módulos:

1. El driver RS232.

2. El controlador principal WHEX 1.

3. El controlador de servomotores.

El driver RS232 tiene como única función la conversión de niveles de tensión desde los ±12 V

del puerto serie del ordenador a los 5 V que necesita el puerto serie de los microcontroladores

utilizados en la placa. Esta función es totalmente hardware y es ejecutada por el circuito

integrado MAX232.

El controlador principal WHEX 1 actúa como maestro del bus I2C interno de la placa, al cual se

encuentra conectado, entre otros dispositivos, el módulo controlador de servomotores. Entre

estos dos módulos se establece, mediante el bus I2C, una relación maestro – esclavo.

La figura 6.10 muestra el camino lógico que siguen los datos en la placa controladora. Como se

ve en esta figura, la información proveniente del ordenador de a bordo, codificada según el

estándar RS232 y con niveles de tensión entre 12 y -12 VDC, ingresa al driver RS232 de la

placa controladora. El driver transforma los niveles de tensión de la señal a niveles TTL (5 VDC



para el 1 lógico y 0 VDC para el 0 lógico). La señal modificada sale del driver e ingresa al

controlador principal WHEX 1, transportando los comandos que este debe ejecutar.

El controlador principal ejecuta las acciones necesarias y genera respuestas, las cuales son

enviadas de regreso al ordenador de a bordo. El controlador principal (maestro del bus I2C)

genera también comandos que son enviados al módulo controlador de servomotores (esclavo

I2C), estos comandos se codifican según el estándar I2C27

.

Por último, el controlador de servomotores genera y mantiene las 48 señales PWM que

controlan la posición y movimientos de los servomotores del robot.

Fig. 6.10: Camino lógico seguido por los datos en la placa controladora WHEX 1.

Según este camino lógico de datos han sido determinadas las entradas y salidas de cada

módulo.

6.3.2.1 Diagrama esquemático del Driver RS232

La figura 6.11 muestra el diagrama esquemático del driver RS232. El componente principal de

este módulo es el circuito integrado MAX232, que realiza la función de conversión de niveles

de tensión de los 12 y -12 VDC que requiere un puerto serie de ordenador (según el estándar

RS232) a los 5 VDC requeridos por los módulos Serie de la mayoría de los circuitos integrados

existentes actualmente, entre ellos los PIC.

Sobre este circuito es necesario mencionar también que ha sido provisto de varios

conmutadores tipo “jumper” para habilitar o deshabilitar su funcionamiento, y con esto las

conversiones (ver figura 6.12). Esto es necesario para brindar flexibilidad a la placa

controladora; pues de esta forma puede ser comandada desde el puerto serie de un ordenador,

haciéndose necesaria la activación del driver RS232 para que convierta los niveles de tensión,

o desde un PIC u otro microcontrolador, en cuyo caso no sería necesario realizar conversiones

de tensión.

27

Especificación del estándar en: http://www.nxp.com/acrobat_download2/literature/9398/39340011.pdf



Fig. 6.11: Diagrama esquemático del circuito del Driver RS232.

En la figura 6.12a se muestra la configuración necesaria para activar el Driver RS232: deben

ser conectados los terminales 1-2 del conmutador ON/OFF, 1-2 del conmutador RX y 1-2 del

conmutador TX. Así mismo, la figura 6.12b muestra la configuración necesaria para desactivar

el módulo: deben conectarse solamente los terminales 2-3 de los conmutadores TX y RX.

a) b)

Fig. 6.12: Configuración de los jumpers del Driver RS232 para:

a) Activar el módulo y las conversiones de niveles de tensión.

b) Desactivar el módulo y conectar la entrada de este con la salida de forma

directa, o sea, sin realizar conversiones.

6.3.2.2 Diagrama esquemático del Controlador Principal WHEX 1

La figura 6.13 muestra el diagrama esquemático del circuito del módulo Controlador Principal

WHEX 1, este circuito tiene como elemento principal al microcontrolador PIC18F452528

,

ejecutando a 24 Mhz.

Como puede verse en el circuito de la figura 6.13, los comandos llegan a través de la línea

serial RX y las respuestas son transmitidas a través de la línea TX hacia la entidad que

comande la placa, ya sea un ordenador u otro microcontrolador, pasando, si es necesario, a

través del driver RS232.

28

Hoja de datos del PIC18F4525 en la url: http://ww1.microchip.com/downloads/en/DeviceDoc/39626e.pdf



Fig. 6.13: Diagrama esquemático del Controlador Principal WHEX 1.



También es necesario mencionar que el circuito puede expandirse añadiendo más hardware a

cualquiera de los puertos que provee. A continuación se describirán las interfaces de dichos

puertos.

6.3.2.2.1 Puerto Bus I2C

La placa controladora WHEX 1 tiene ocho conectores para dispositivos que funcionen

utilizando el bus I2C en modo esclavo. El microcontrolador PIC18F4525 actúa como nodo

maestro en este bus.

La cantidad de dispositivos I2C que pueden conectarse al bus está determinada por la longitud

de las direcciones, que en el caso del bus I2C es de 7 bits; por tanto, pueden ser conectados

hasta 128 dispositivos esclavos. Sin embargo solo se proveen 8 conectores para este puerto,

así que en caso de necesitar conectar más de 8 dispositivos, será necesario instalar, en uno de

los puertos, un extensor que provea más conectores.

El conector que se ha diseñado para este puerto tiene 4 terminales:

1. VCC: 5 VDC.

2. SDA: Línea de datos del bus I2C.

3. SCL: Línea de reloj del bus I2C.

4. VSS: Tensión de referencia o masa (0 VDC).

El conector diseñado provee de alimentación (pines 1 y 4) y datos (pines 2 y 3) al dispositivo

que se le conecte, por tanto no es necesario que el dispositivo tenga ninguna otra conexión

para poder operar.

6.3.2.2.2 Puerto para dispositivos analógicos.

El puerto para dispositivos analógicos permite la conexión a la placa controladora de

dispositivos que necesiten una línea analógica como salida, por ejemplo, sensores de luz

(LDR).

La placa provee 4 puertos para conectar estos dispositivos, cada puerto tiene los siguientes

terminales:

1. Entrada analógica (salida del dispositivo).

2. VCC: 5 VDC.


Si se desea conectar un dispositivo que necesite más de una línea analógica para enviar sus

datos, por ejemplo un acelerómetro de dos o tres ejes, este puede ser conectado utilizando un

conector por cada línea que se necesite (hasta un máximo de 4).



6.3.2.2.3 Puerto para dispositivos digitales.

La placa permite la interconexión de dispositivos de entrada / salida digitales a través de un

puerto digital de seis bits.

Se proveen 6 conectores con la siguiente interfaz:

1. Línea de entrada / salida digital.


3. VCC: 5 VDC.

6.3.2.2.4 Conectores para 8 pulsadores

La placa cuenta con 8 conectores para pulsadores. A estos conectores de dos terminales

pueden ser conectados pulsadores normalmente abiertos sin la necesidad de añadir hardware

extra, ya que la placa cuenta con resistencias de pull-up que mantienen la salida del pulsador

en estado lógico 1 mientras este no se presione, cambiando a estado lógico 0 al ser

presionado.

Como el elemento principal de este circuito es un microcontrolador, específicamente un

PIC18F4525 de Microchip, es necesario desarrollar un firmware que ejecute las funciones que

el circuito debe realizar, esto será descrito en secciones siguientes del presente trabajo.

6.3.2.3 Diagrama esquemático del Controlador de Servomotores

La figura 6.14 muestra el diagrama esquemático del circuito controlador de servomotores, cuyo

componente principal es un PIC18F4525 ejecutando a 24 MHz.

Este controlador, con el firmware preciso, es capaz de generar 24 señales PWM para el control

de 24 servomotores.

La placa controladora WHEX 1 presenta dos de estos módulos, por tanto es capaz de generar

hasta 48 señales PWM simultáneamente.

Este módulo funciona como esclavo I2C, recibiendo las órdenes mediante el bus I2C de la

placa controladora y realizando las acciones necesarias para mantener las señales PWM de

cada servomotor.



Fig. 6.14: Diagrama esquemático del Controlador de Servomotores.



Como puede verse en el diagrama de la figura 6.14, cada servomotor se conecta mediante un

conector de tres terminales, compatible con las marcas más conocidas de servomotores de

modelismo. Este conector tiene los siguientes pines:

1. Señal PWM de control.

2. VCC: 6 VDC para alimentar al servomotor.


Al igual que sucede con el controlador principal WHEX 1, el componente principal de este

circuito es un microcontrolador PIC18F4525, por tanto es necesario un firmware que ejecute las

funciones del módulo. El desarrollo de este firmware será abordado en siguientes secciones de

este trabajo.

6.3.3 Diseño y fabricación del circuito impreso de la placa controladora WHEX 1.

Llegados a este punto se cuenta con los circuitos esquemáticos de la placa, los cuales han sido

comprobados mediante simulación y su implementación en la placa de prototipado rápido.

Entonces, para concluir el desarrollo de la placa controladora solo resta la fabricación de un

prototipo permanente mediante una placa de circuitos impresos.

Para el diseño del circuito impreso se partió de los diagramas esquemáticos creados en

secciones anteriores y utilizando la herramienta Layout Plus integrada en OrCAD 10.3 se

realizó el posicionamiento de los componentes y encaminamiento de las pistas en el circuito.

El circuito se ha diseñado utilizando dos capas de cobre interconectadas mediante vías

también de cobre. Las figuras 6.15 y 6.16 muestran respectivamente la capa superior y la

inferior. La placa se ha fabricado siguiendo el método de foto-exposición y ataque ácido29

que

consiste básicamente en lo siguiente:

Imprimir en un acetato transparente los patrones de las figuras 6.15 y 6.16.

En una habitación con muy poca luz, preferiblemente de tonos rojos, fijar los acetatos

impresos a ambos lados de una placa fotosensible positiva de doble cara,

asegurándose que queden perfectamente alineados.

Exponer ambas caras de la placa con las máscaras aplicadas a una fuente de luz

ultravioleta, como por ejemplo el sol o una insoladora de circuitos.

Con baja iluminación realizar un baño de la placa, ya sin las máscaras, utilizando una

disolución de sosa caustica (esta puede comprarse ya preparada en tiendas de

electrónica).

Cuando la imagen aparezca en ambas caras de la placa ya se ha completado el

revelado y pueden encenderse las luces de la habitación.

Aplicar un baño ácido a la placa para eliminar el cobre que no ha sido cubierto por el

patrón y obtener de esta forma el diagrama del circuito impreso.

29

El método completo en: http://www.pcpaudio.com/pcpfiles/doc_amplificadores/PCBs/PCBs.html



Fig. 6.15: Capa superior del circuito impreso de la placa controladora WHEX 1.

Fig. 6.16: Capa inferior del circuito impreso de la placa controladora WHEX 1.

Los componentes han sido fijados en la capa superior del circuito siguiendo como guía para

realizar esta tarea la vista de serigrafía que brinda OrCAD, esta vista puede apreciarse en la

figura 6.17.



Fig. 6.17: Vista en OrCAD que permite la localización de las posiciones de los componentes en el circuito impreso.

La figura 6.18 muestra la placa fabricada e instalada en su sitio dentro del cuerpo del robot

WHEX 1.

Fig. 6.18: Placa controladora WHEX 1 instalada en el cuerpo del robot.



6.4 Ordenador de a bordo

WHEX 1 cuenta con un ordenador de a bordo responsable de las tareas de alto nivel del robot,

como por ejemplo la gestión de la comunicación con el ordenador remoto y la navegación,

entre otras.

El diagrama de la figura 6.19 muestra los componentes que han sido configurados para el

ordenador de a bordo de WHEX 1.

Fig. 6.19: Componentes del ordenador de a bordo de WHEX 1.

El ordenador que se ha utilizado está basado en la placa base VIA Epia Pico ITX: un sistema

provisto de controladora de vídeo, conexiones PATA y SATA para unidades de

almacenamiento, 4 puertos USB y un puerto serie RS232 para la conexión de dispositivos

periféricos, un conector RJ45 para LAN de 10/100Mbps y conectores de altavoces y micrófono,

entre otros. En la figura 6.20 se puede ver esta placa base.30

a) b)

Fig. 6.20: Placa base VIA Epia Pico ITX.

a) Placa base sin el disipador y ventilador del procesador, comparada con un naipe.

b) Placa base con el disipador y ventilador del procesador instalados.

30

La hoja de datos en: http://www.via.com.tw/en/products/embedded/ProductDetailTabs.jsp?id=690&tabs=1#tabs-4



Como se puede ver en la figura 6.20, se ha instalado 1 GB de memoria RAM DDR2, lo cual es

suficiente para que el software del robot (sobre todo la visión artificial) pueda ejecutar con

fluidez.

Para alimentar al ordenador de a bordo se ha utilizado la

fuente de alimentación PicoPSU 60WI31

(figura 6.21),

cuyo diseño está muy optimizado para su uso con la

placa base Epia y permite ser conectada a una tensión

de entrada desde 6 VDC a 32 VDC, esto último es muy

importante debido al modelo de descarga de las baterías

que se utilizan en WHEX 1, que hacen variar la tensión

desde 9 VDC cuando están totalmente cargada a 6 VDC cuando están descargadas. Esta

fuente de alimentación se conecta directamente en la salida etiquetada como Salida al

ordenador del circuito distribuidor de energía. (ver figura 6.4)

Otro elemento que debe ser analizado del diagrama de la figura 6.19 es la solución que se ha

dado al almacenamiento.

Un disco duro necesita mantener girando a alta velocidad (7200 RPM) los discos donde

almacena los datos, por tanto, sus motores consumen mucha energía. En esta aplicación, el

ahorro energético es de vital importancia, así que se ha optado por una unidad de estado

sólido, específicamente, una tarjeta Compact Flash de 4 Gb, conectada al conector PATA de la

placa base a través de un adaptador IDE a Compact Flash. La figura 6.22 muestra estos

componentes.

a) b)

Fig. 6.22: Componentes del subsistema de almacenamiento configurado para WHEX 1.

a) Adaptador IDE 2.5” a Compact Flash.

b) Compact Flash SanDisk Extreme III de 4 Gb.

31

El manual en: http://resources.mini-box.com/online/PWR-PICOPSU-60-WI/PWR-PICOPSU-60-WI-manual.pdf

Fig. 6.21: Fuente de alimentación PicoPSU 60WI



Por último es necesario mencionar que se ha utilizado una controladora

WIFI USB para proveer al robot de enlace inalámbrico a internet, la

controladora utilizada es una SMC EZ Connect SMCWUSBS-N32

,

mostrada en la figura 6.23.

La tabla 6.1 muestra los precios de los componentes que integran la

electrónica del robot.

Producto o componente Proveedor Precio unitario (Euro)

Cantidad utilizada Precio Total (Euro)

Batería LIPO 4300 mA www.ebay.es 21.00 1 21.00

UBEC 3 A www.ebay.es 8.99 1 8.10

UBEC 8 A www.ebay.es 16.99 2 33.98

PIC18F4525 Digital SA 6.40 3 19.20

MAX232 Digital SA 1.40 1 1.40

Placa PCB positiva 2 caras Digital SA 2.85 1 2.85

Cristal 24 MHz Digital SA 0.77 3 2.31

Capacitor 22 pF Digital SA 0.05 6 0.30

Placa base Epia PICO ITX www.ebay.es 150.00 1 150.00

Fuente PICO PSU www.ebay.es 30.00 1 30.00

Webcam Creative Live Cam PC Box 14.99 1 14.99

Wifi SMC EZ Connect PC Box 8.80 1 8.80

Adaptador CF - IDE www.ebay.es 12.70 1 12.70

Tarjeta Compact Flash 4 gb Menaje del Hogar 19.99 1 19.99

Sensor Ultrasónico SRF08 www.superrobotica.com 32.25 1 32.25

357.87

Tabla 6.1: Precios de los componentes de la electrónica del robot WHEX 1

La figura 6.24 muestra el prototipo del robot hexápodo WHEX 1 que se ha construido. En

siguientes capítulos del presente trabajo se analiza la configuración del firmware, software de

su sistema operativo y sistemas de control.

Fig. 6.24: Prototipo del robot WHEX 1 construido.

32

http://www.smc.com/index.cfm?event=viewProduct&localeCode=EN_USA&cid=5&scid=117&pid=1645

Fig. 6.23: Controladora WIFI USB SMC EZ Connect, utilizada en WHEX 1.

Diseño y desarrollo del firmware del robot.


Capítulo

Diseño y desarrollo del firmware del robot

7



7 Diseño y desarrollo del firmware del robot.

Como se ha visto en el capítulo anterior, la placa controladora WHEX 1 cuenta con tres

microcontroladores PIC18F4525, que se comunican mediante un bus I2C, en el cual, uno de

los microcontroladores actúa como maestro (controlador principal WHEX 1) y los otros dos

actúan como esclavo (controladores de servomotores).

En este capítulo se analiza el proceso de diseño y codificación de los paquetes de firmware

que se ejecutan en los microcontroladores de la placa controladora WHEX 1. La figura 7.1

muestra los elementos de la arquitectura del robot que se analizan en el capítulo.

Fig. 7.1: Elementos de la arquitectura que se analizan en el presente capítulo.

La figura 7.2 muestra un diagrama de despliegue en el cual se pueden apreciar los distintos

elementos de firmware que integra la placa controladora.

Fig. 7.2: Diagrama de despliegue de los distintos componentes software / firmware en el robot WHEX 1.



En el diagrama de la figura 7.2 puede apreciarse que se ha desarrollado firmware para el

controlador principal WHEX 1 y para los controladores de servomotores, en las siguientes

secciones serán abordados con detalles el diseño y codificación de estos dos paquetes de

software.

7.1 Metodologías y técnicas empleadas para el diseño y codificación del firmware de la

placa controladora WHEX 1

Para el diseño y codificación del firmware se ha seguido un ciclo de vida evolutivo,

desarrollando primeramente lo imprescindible para poder seguir desarrollando, es decir,

siguiendo un orden lógico en la selección de las funcionalidades que deben ser desarrolladas

primero que una funcionalidad específica.

Como se ha dicho en la sección anterior, el firmware se ha dividido en dos paquetes, uno para

el controlador principal WHEX 1 y el otro para los controladores de servomotores.

Para determinar en cada momento que parte de estos paquetes de firmware debe ser

desarrollada y en qué orden, se han analizado los requisitos que debe cumplir la placa

controladora, determinando las prioridades de cada requisito y las dependencias entre ellos.

Como resultado de este análisis se han dividido los paquetes en los siguientes componentes:

Paquete: Firmware del controlador de servomotores

Esclavo I2C.

Controlador de Servomotores.

Paquete: Firmware del controlador principal WHEX 1

Comunicación RS232.

Maestro I2C.

Gestor de peticiones.

Cinemática inversa de pata.

Cinemática inversa del cuerpo.

Generador de movimientos.

Gestor de periféricos.

Además, se ha realizado el grafo de dependencias de la figura 7.3, que representa la

secuencia correcta de codificación de estos componentes.

Así mismo se han definido los incrementos que deben efectuarse en la codificación de los

componentes más complejos, que son el controlador de servomotores y el generador de

movimientos. Esto ha sido necesario dado el ciclo de vida evolutivo que ha guiado el desarrollo.



Las figuras 7.4 y 7.5 muestran las secuencias de incrementos que han sido definidas para el

desarrollo del controlador de servomotores y el generador de movimientos respectivamente.

Fig. 7.3: Grafo de precedencia que representa las dependencias de construcción de los módulos que integran el firmware de la placa controladora WHEX 1.

Fig. 7.4: Incrementos definidos para el desarrollo del controlador de servomotores.

Fig. 7.5: Incrementos definidos para el desarrollo del Generador de movimientos.



Con esta secuencia de pasos ya establecida, solo queda comenzar a diseñar y codificar los

componentes que han sido definidos.

A la hora de comenzar a desarrollar cualquier producto software es imprescindible, para poder

seleccionar correctamente el entorno de desarrollo y los lenguajes a emplear, conocer las

condiciones en las que el software se debe ejecutar.

En este caso se trata de software que debe ejecutar embebido en un circuito electrónico y

alojado en un microcontrolador PIC18F4525; por tanto, el primer paso en esta decisión es

determinar los lenguajes de programación que soporta este microcontrolador así como las

ventajas, desventajas y esfuerzo que llevaría realizar los programas con cada uno de ellos.

El PIC18F4525 puede ser programado utilizando los siguientes lenguajes de programación:

Ensamblador, específico para el PIC18F4525 y distribuido por Microchip con el entorno

de desarrollo MPLAB.

C, de este lenguaje hay varios compiladores:

o C18: Distribuido por Microchip en forma de plugin para el entorno MPLAB.

o mikroC: Distribuido por MikroElektronika.

o CCS C: Distribuido por Custom Computer Services en forma de IDE propio y

plugin para MPLAB.

Basic: desarrollado por microEngineering Labs, es un compilador para PIC del popular

lenguaje Basic.

Para desarrollar el firmware se han escogido dos lenguajes de los arriba listados, el

ensamblador propio del PIC18F4525 para el paquete controlador de servomotores y el

compilador de C de CCS para el paquete controlador principal WHEX 1. Esta selección se ha

basado en dos aspectos principales:

Para generar las señales PWM utilizadas para controlar servomotores es

extremadamente importante que el microcontrolador ejecute las secuencias de código

en un tiempo específico, ya que si existen desviaciones de este tiempo el servomotor

puede moverse de forma errática. Por tanto, solo puede ser programado este paquete

utilizando ensamblador, ya que los compiladores de otros lenguajes de alto nivel hacen

una traducción del código escrito en el lenguaje de alto nivel a código ensamblador y

de este a código máquina, generando varias instrucciones en código maquina por cada

instrucción en el lenguaje de alto nivel, con lo cual se hace imposible realizar

mediciones exactas del tiempo de ejecución del código de máquina generado.

Para el otro paquete de firmware se ha utilizado el compilador C de CCS debido a que

este paquete no presenta el requisito de diseño mencionado anteriormente y el

lenguaje C está muy extendido y existe mucha documentación para él; por tanto, la

utilización de este lenguaje facilita mucho el desarrollo de este paquete.

7.2 Diseño y codificación del paquete controlador de servomotores.

Como se ha dicho anteriormente, el desarrollo de este paquete se ha llevado a cabo en tres

incrementos que van desde controlar un servomotor hasta el control de los 24 servomotores

que cada chip PIC18F4525 debe controlar.

Antes de continuar, es necesario mencionar que este PIC cuenta con 4 temporizadores en

hardware capaces de medir tiempo de forma muy precisa. Estos temporizadores incrementan

su valor cada vez que ocurre un ciclo de instrucción en el PIC, generando una interrupción

software cuando desbordan; pueden ser programados, precargándolos con un valor específico,

para que desborden justamente en un tiempo determinado. Estos temporizadores se han

utilizado en este paquete para controlar los intervalos de tiempo.



7.2.1 Método empleado para controlar 24 servomotores utilizando los recursos limitados de

un chip PIC18F4525.

Como se ha explicado en el Estado de la cuestión, para controlar un servomotor de modelismo

es necesario generar una señal de control PWM con período de unos 20 ms. Esta señal

codifica el ángulo que debe tomar el eje del servomotor.

La codificación está determinada por el intervalo de tiempo que dura el pulso en estado lógico

alto en esta señal, variando desde 0.5 ms para el 0º hasta los 2.5 ms para los 180º.

Entonces, si dividimos los 20 ms del período de la señal entre 2.5 ms, que es el tiempo máximo

que la señal puede estar en estado lógico alto, el resultado obtenido es 8; lo cual indica que

podrían generarse hasta 8 pulsos seguidos de 2.5 ms como máximo cada 20 ms.

Si utilizamos un temporizador para generar esos 8 pulsos en salidas diferentes del PIC, se

obtendrían 8 señales PWM con período de 20 ms y tiempos de pulso de entre 0.5 y 2.5 ms,

desfasadas unos 2.5 ms entre sí.

Entonces, si utilizamos tres temporizadores trabajando en paralelo, podrían generarse las 24

señales PWM que se necesitan.

El esquema de la figura 7.6 muestra el comportamiento de 8 señales PWM generadas

mediante este método, utilizando solo un temporizador. En este esquema puede verse que el

período de la señal ha sido dividido en 8 intervalos iguales, cada uno de 2.5 ms, generándose

un pulso en cada uno de estos intervalos.

Como puede verse en el esquema de la figura 7.6, las señales están desfasadas unos 2.5 ms.

Este comportamiento no implica consecuencias para el resultado final, ya que cuando

transcurra el primer período de 20 ms todos los servomotores habrán recibido su primer pulso,

posicionándose en el ángulo correspondiente, y a partir de este, seguirán recibiendo pulsos

cada 20 milisegundos exactamente.

El esquema de la figura 7.7 muestra las 8 señales solapadas para poder apreciar mejor la

forma en que trabaja el temporizador: en cada intervalo de 2.5 ms el temporizador genera un

pulso en la señal correspondiente.

De esta forma, utilizando los 4 temporizadores hardware del microcontrolador PIC18F4525 se

ha diseñado el algoritmo de generación de las 24 señales PWM necesarias para controlar los

servomotores.



Fig. 7.6: Esquema de tiempo que muestra el comportamiento de 8 señales PWM en uno de sus períodos de 20 ms.

Fig. 7.7: Esquema de tiempo que muestra las 8 señales PWM solapadas.

7.2.2 Modelos matemáticos empleados para la programación de los temporizadores.

Para poder medir tiempos utilizando los temporizadores hardware que integra el PIC18F4525

es necesario comprender bien su funcionamiento. Existen dos modelos matemáticos

empleados por estos módulos hardware: el primero de ellos rige el funcionamiento de los

temporizadores 0, 1 y 3 y el segundo modelo rige el funcionamiento del temporizador 2.

El robot WHEX 1 emplea los 4 temporizadores para controlar sus servomotores; por tanto, en

esta sección se explicará la aplicación concreta al robot WHEX 1 de estos modelos

matemáticos.

Se comenzará analizando la siguiente ecuación:

Precarga = 62536 – 47*Posición8Bits. (1)



La ecuación anterior no es más que la relación lineal que se establece entre la posición del eje

de un servomotor, representada mediante 8 bits y con rango desde 0 hasta 255, y el valor de

precarga necesario para que los temporizadores 0, 1 y 3 midan tiempos entre 0.5 ms

(posición = 0) y 2.5 ms (posición = 255).

A continuación se explicará brevemente la deducción de esta ecuación.

El período de tiempo entre interrupciones por desbordamiento de los temporizadores 0, 1 y 3

en los PIC está regido por la siguiente ecuación:

(2)

Donde:

Período es el tiempo entre desbordamientos del temporizador, medido en segundos.

Fosc es la frecuencia del reloj interno del PIC, medida en Hz.

Prescaler es el valor asignado al divisor de frecuencias integrado en la mayoría de los

temporizadores del PIC.

Rango es la cantidad de valores que puede tomar el temporizador: 256 para

temporizadores de 8 bits y 65536 para temporizadores de 16 bits.

Precarga es el valor que se escribe en el temporizador antes de hacerlo funcionar para

poder ajustar el Período.

Entonces, si se necesita realizar la medición de un tiempo determinado utilizando uno de estos

temporizadores, solo se deben precargar los registros del temporizador con el valor preciso.

Para calcular el valor de la precarga necesaria, se despeja en la ecuación (2) y se sustituyen

los valores constantes siguientes:

FrecuenciaOscilación = 24 MHz = 24000000 Hz.

Prescaler = 1 (divisor de frecuancias 1:1 o desactivado).

Rango = 65536 (temporizador de 16 bits).

Quedando:

(3)

Utilizando la ecuación (3), se calculan las precargas necesarias para la medición de los

tiempos de 0.5 ms y 2.5 ms correspondientes a las posiciones 0 y 255 (0º y 180º

respectivamente), resultando las siguientes:

Para Posición = 0 (0.5 ms): 62536.

Para Posición = 255 (2.5 ms): 50536.

Entonces, utilizando los puntos (0; 62536) y (255; 50536) se calcula la ecuación de la recta que

representa la relación lineal entre estos dominios, resultando la ecuación:

Y = 62536 – 47*X. (4)



Y sustituyendo los nombres de las variables:

Precarga = 62536 – 47*Posición8Bits. (5)

La ecuación (5) establece la correspondencia entre la posición del eje de los servomotores y el

valor de precarga necesario para realizar la medición, utilizando los temporizadores 0, 1 y 3,

del tiempo de pulso necesario para que los servomotores posicionen su eje en dicha posición.

El segundo modelo se ha empleado para medir un intervalo de tiempo fijo de 2.5 ms utilizando

el temporizador 2 del PIC (en la siguiente sección se explica la finalidad de esta medición):

El período entre interrupciones del temporizador 2 está dado por la siguiente ecuación:

(6)

Donde:

Período es el tiempo entre desbordamientos del temporizador, medido en segundos.

Fosc es la frecuencia del reloj interno del PIC, medida en Hz.

Prescaler es el valor asignado al divisor de frecuencias integrado en la mayoría de los

temporizadores del PIC.

Postscaler es un divisor de frecuencias que se aplica en la salida del temporizador 2.

ValorDeInterrupción es un registro de 8 bits que determina el fin del conteo del

temporizador 2, si el valor del temporizador es igual a este valor, se solicita la

interrupción y se reinicia el temporizador.

Precarga es el valor que se escribe en el temporizador antes de hacerlo funcionar para

poder ajustar el Período.

Para obtener un tiempo de 2.5 ms utilizando el temporizador 2 del PIC solo es necesario

despejar en la ecuación (6) y sustituir los valores constantes siguientes:

FrecuenciaOscilación = 24 MHz = 24000000 Hz.

Prescaler = 1:4.

Postscaler = 1:15.

Precarga = 0.

Quedando:

(7)

Entonces, para medir un tiempo de 2.5 ms utilizando el temporizador 2, solo es necesario

configurarlo con los valores constantes analizados anteriormente y establecer su registro

ValorDeInterrupción a 250.

7.2.3 Algoritmo del programa controlador de servomotores.

Partiendo del método de generación explicado en la sección 7.2.1, se ha creado el algoritmo

mostrado en el diagrama de flujo de la figura 7.8.



Fig. 7.8: Diagrama de flujo del programa principal del paquete controlador de servomotores.

En el diagrama de la figura 7.8 puede apreciarse que existen tres almacenes de información

principales: los registros de control, los registros de servomotores y los puertos del

microcontrolador.

Los registros de control son todas las variables globales que determinan el funcionamiento

general del programa.



Los registros de servomotores contienen, en forma de tabla, las variables de posición y

velocidad de cada uno de los servomotores. La tabla 7.1 muestra la organización de este

almacén de datos.

Índice del servo

Velocidad (8 bits)

Posición final. Precarga (16 bits)

Posición final (8 bits)

Posición actual (8 bits)

Posición actual. Precarga. (16 bits)

0

…

23

Tabla 7.1: Estructura de los registros de velocidad y posición de los servomotores.

Para hacer que un servomotor rote su eje desde un ángulo hacia otro es necesario modificar el

ancho de los pulsos que se le suministran. Si este ancho de pulsos se modifica de forma

inmediata el servomotor se desplazará a su velocidad máxima. Por el contrario, si el ancho de

los pulsos se hace variar de forma gradual, el servomotor se desplazará hacia el ángulo final a

una menor velocidad.

La velocidad de los servomotores se ha definido como un entero de 8 bits cuyo rango válido va

desde 1 hasta 255, extremos incluidos. Esta variable determina la rapidez a la que se hará

variar la posición del eje del servomotor en cuestión.

Tanto la posición final del servo como la posición actual han sido representadas de dos formas:

Mediante un entero de 8 bits, con rango desde 0 (0º) hasta 255 (180º).

Mediante un entero de 16 bits que almacena el valor de precarga necesario para

realizar la programación de los temporizadores 0, 1 y 3. Este valor es calculado a partir

de la representación de 8 bits mediante la ecuación (5) de la sección 7.2.2:

Posición16Bits = 62536 – 47*Posición8Bits.

Los registros de posición y velocidad de los servomotores incluyen también tres registros de 8

bits que almacenan un bit por cada servomotor (8 x 3 = 24 servomotores). Si el bit

correspondiente a un servomotor en estos registros es igual a 1, el servomotor se encuentra

activado, en otro caso, el servomotor se encuentra desactivado.

El tercer almacén definido en el diagrama contiene los puertos del microcontrolador a los que

se han conectado físicamente los servomotores. Estos puertos son los siguientes:

Servo 0: PuertoB[7]

Servo 1: PuertoB[6]

Servo 2: PuertoB[5]

Servo 3: PuertoB[4]

Servo 4: PuertoB[3]

Servo 5: PuertoB[2]

Servo 6: PuertoB[1]

Servo 7: PuertoB[0]

Servo 8: PuertoD[7]

Servo 9: PuertoD[6]

Servo 10: PuertoD[5]


Servo 12: PuertoA[0]






Servo 18: PuertoC[2]






Vistos los datos manipulados, a continuación se explicarán los diferentes algoritmos que

forman parte del paquete controlador de servomotores.



El algoritmo general del programa es el siguiente:

Inicializar

Inicializar registros de control. Inicializar puertos. Inicializar registros de servomotores a sus valores iniciales. Inicializar comunicación I2C. Inicializar temporizadores. Inicializar interrupciones hardware del módulo SSP y los contadores.

Repetir indefinidamente: Actualizar posición actual de servomotores. Esperar un tiempo determinado. Atender eventos de interrupciones de forma paralela.

En caso de ocurrir un evento, pausar la ejecución del programa y atender dicho evento.

Fin repetir.

La primera etapa del algoritmo es la inicialización, en esta etapa se prepara el microcontrolador

y su memoria para el comienzo de la ejecución del firmware:

Inicialización de los registros de control del PIC para que ejecute a 24 MHz, entre otras

opciones.

Inicialización de las variables globales del programa.

Inicialización de los puertos a los que se han conectado los servomotores,

estableciéndolos en modo de escritura digital e inicializando su valor a 0 lógico.

Inicialización de registros de velocidad y posición de servomotores, estableciendo el

valor de la velocidad a 255 y la posición inicial y actual a 125 (90º).

Inicializar la comunicación mediante el bus I2C, escribiendo los registros de control

necesarios para activar y establecer el módulo SSP del PIC en modo esclavo I2C.

Inicializar los 4 temporizadores.

Activar las interrupciones de los temporizadores y el protocolo del bus I2C.

Una vez realizada la inicialización, el programa entra en un bucle infinito en el cual se actualiza

la posición actual de cada servomotor. La figura 7.9 muestra el diagrama de flujo de este

proceso.

Este proceso se encarga de ir actualizando la posición actual de cada servomotor según su

velocidad y posición final establecidas. Mientras mayor sea la velocidad del servomotor, más

rápidamente se desplazará su posición actual hacia su posición final, deteniéndose en la

posición final una vez alcanzada.



Fig. 7.9: Diagrama de flujo del proceso Actualizar posición de servomotores.

El algoritmo representado por el diagrama de flujo de la figura 3.60 es el siguiente:

Actualizar posición de servomotores: Para cada servomotor i, desde 0 hasta 23, repetir: Si PosiciónActual8Bits[i] != PosiciónFinal8Bits[i] Si PosiciónActual8Bits[i] > PosiciónFinal8Bits[i] Si PosiciónActual8Bits[i] – Velocidad[i] < PosiciónFinal8Bits[i] Asignar PosiciónActual8Bits[i] = PosiciónFinal8Bits[i].

Sino Asignar PosiciónActual8Bits[i] = PosiciónActual8Bits[i] – Velocidad[i].

Fin si Sino Si PosiciónActual8Bits[i] + Velocidad[i] > PosiciónFinal8Bits[i] Asignar PosiciónActual8Bits[i] = PosiciónFinal8Bits[i].

Sino Asignar PosiciónActual8Bits[i] = PosiciónActual8Bits[i] + Velocidad[i].

Fin si Fin si Asignar PosiciónActual16Bits[i] = 62536 – 47 * PosiciónActual8Bits[i].

Fin si Fin repetir



7.2.3.1 Comunicación con el exterior

Como ya se ha visto en secciones anteriores, la comunicación con el exterior se realiza a

través de un bus I2C al cual el controlador de servomotores se encuentra conectado en modo

esclavo, atendiendo peticiones de tipo Comando - Respuesta. El diagrama de flujo de la figura

7.10 muestra el algoritmo del autómata que gestiona estas solicitudes I2C (Actividad Esclavo

I2C en el diagrama de la figura 7.8).

Fig. 7.10: Algoritmo del autómata que gestiona las actualizaciones de los registros de posición y velocidad de los servomotores (Esclavo I2C).



Ante la ocurrencia de una petición en el bus I2C, el controlador de servomotores debe

responder, pausándose e iniciando una rutina de actualización de los registros de velocidad y

posición de los servomotores. La rutina de actualización determina que operación debe

realizarse, dependiendo del comando recibido por el bus I2C; esta rutina es la representada en

el diagrama de flujo de la figura 7.10.

Las direcciones en el bus I2C de los dos controladores de servomotores que utiliza el robot

WHEX 1 son la 22h para el primer controlador y la 24h para el segundo controlador.

El algoritmo representado en la figura 7.10 comienza leyendo y almacenando el comando y

parámetro recibido por I2C y a continuación determina la acción a realizar.

Las acciones se dividen en dos grupos: las que necesitan un parámetro y las que no necesitan

ningún parámetro, teniendo todas ellas como objetivo final mantener actualizado los registros

de posición y velocidad de los servomotores

El algoritmo es el siguiente:

Esclavo I2C: Recibir Comando y almacenarlo. Recibir Dato y almacenarlo. Determinar acción a realizar:

Si comando == Activar Servo Establecer bit ServoEnabled[Dato] = ‘1’.

Sino Si comando == Desactivar Servo Restablecer bit ServoEnabled[Dato] = ‘0’.

Sino Si comando == Copiar Velocidad Asignar VelocidadRecibida = Dato.

Sino Si comando == Copiar Posición Asignar PosiciónRecibida = Dato.

Sino Si comando == Actualizar Servo Asignar PosiciónFinal8Bits[Dato] = PosiciónRecibida. Asignar Velocidad[Dato] = VelocidadRecibida.

Sino Si comando == Leer Velocidad de Servo Enviar por I2C Velocidad[Dato].

Sino Si comando == Leer Posición de Servo Enviar por I2C PosiciónActual[Dato].

Sino Si comando == Actualizar todos los Servos Para cada servomotor i, desde 0 hasta 23, repetir:

Asignar PosiciónFinal8Bits[i] = PosiciónRecibida. Asignar Velocidad[i] = VelocidadRecibida.

Fin repetir Sino Si comando == Activar todos los Servos

Para cada servomotor i, desde 0 hasta 23, repetir: Establecer bit ServoEnabled[i] = ‘1’.

Fin repetir Sino

Para cada servomotor i, desde 0 hasta 23, repetir: Restablecer bit ServoEnabled[i] = ‘0’.

Fin repetir Fin si

Fin repetir



Por último queda explicar el algoritmo que se ha seguido para la generación de las 24 señales

PWM empleando el método de generación explicado en la sección 7.2.1 y los modelos

matemáticos de la sección 7.2.2.

7.2.3.2 Algoritmo de generación de las 24 señales PWM

Además de las interrupciones generadas por las solicitudes I2C, se han configurado los cuatro

temporizadores hardware del PIC para que generen interrupciones cuyas rutinas de atención

son las responsables de la generación de los flancos de subida y bajada de las señales PWM

que controlan los servomotores.

Como se ha visto en la sección 7.2.1, el período de las señales PWM se ha dividido en 8

intervalos de 2.5 ms. En cada uno de estos intervalos deben ser generados tres pulsos

pertenecientes a tres señales respectivamente, de forma tal que, al transcurrir los 20 ms del

período completo, se hayan generado los pulsos de las 24 señales.

Para lograr lo anterior se ha utilizado una variable contador cuyo valor define el intervalo de 2,5

ms en el cual deben ser generados los pulsos de cada señal. La tabla 7.2 muestra los

intervalos y el temporizador asignados a cada señal según el valor de dicha variable.

Intervalo de tiempo (variable contador)

Primer grupo de señales (Temporizador 0)

Segundo grupo de señales (Temporizador 1)

Tercer grupo de señales (Temporizador 3)

0 Servo 0 Servo 8 Servo 16








Tabla 7.2: Asignación de las 24 señales PWM a los intervalos de tiempo en que ha sido dividido el período de estas.

Por ejemplo, en el intervalo de tiempo perteneciente al valor 3 de la variable “contador”, deben

ser generados los pulsos de las señales pertenecientes a los servomotores 3, 11 y 19.

Como parte de la inicialización, la variable contador se ha establecido al valor -1.

Entonces, los temporizadores se han configurado del siguiente modo:

El temporizador 2 se ha configurado para que genere una interrupción cada 2.5 ms

exactamente y ejecute las siguientes acciones:

o Actualizar la variable contador del modo siguiente:

Incrementarla en 1.

Si su valor es igual a 8, entonces asignarle el valor 0.

o Determinar los tres servomotores que deben ser atendidos en el intervalo de

tiempo actual, basándose en la tabla 7.2.

o Precargar los temporizadores 0, 1 y 3 con los valores de la posición actual (16

bits) de los tres servomotores determinados en el punto anterior. Con esta

acción quedan programados los temporizadores para que midan el tiempo de

pulso correspondiente a las posiciones que deben adoptar los servomotores.

o Activar los temporizadores 0, 1 y 3.



o Establecer a 1 las señales que correspondan a los servomotores previamente

seleccionados solo en caso de que estén activados. Con esta acción se

generan los flancos de subida de estas señales.

Los temporizadores 0, 1 y 3 desbordarán una vez transcurridos los tiempos

programados en la interrupción del temporizador 2 y ejecutarán las acciones

siguientes:

o Determinar el servomotor que les corresponde atender en el intervalo de

tiempo actual, basándose en la tabla de 7.2.

o Establecer a “0” la señal que corresponda al servomotor previamente

seleccionado. Con esta acción se genera el flanco de bajada de la señal.

o Desactivar el temporizador correspondiente.

Los algoritmos de las rutinas de interrupción de los temporizadores son los siguientes:

Temporizador 2: Asignar Contador = Contador + 1. Si Contador == 8

Asignar Contador = 0. Asignar AtenderServoTemp0 = Contador. Asignar AtenderServoTemp1 = Contador + 8. Asignar AtenderServoTemp3 = Contador + 16. Asignar Temporizador 0 Precarga = PosiciónActual16Bits[AtenderServoTemp0]. Asignar Temporizador 1 Precarga = PosiciónActual16Bits[AtenderServoTemp1]. Asignar Temporizador 3 Precarga = PosiciónActual16Bits[AtenderServoTemp3]. Activar Temporizador 0. Activar Temporizador 1. Activar Temporizador 3. Si ServoEnabled[AtenderServoTemp0] == ‘1’

Establecer bit Puertos[AtenderServoTemp0] = ‘1’. Si ServoEnabled[AtenderServoTemp1] == ‘1’

Establecer bit Puertos[AtenderServoTemp1] = ‘1’. Si ServoEnabled[AtenderServoTemp3] == ‘1’

Establecer bit Puertos[AtenderServoTemp3] = ‘1’. Temporizador 0: Asignar AtenderServoTemp0 = Contador. Restablecer bit Puertos[AtenderServoTemp0] = ‘0’. Desactivar Temporizador 0. Temporizador 1: Asignar AtenderServoTemp1 = Contador + 8. Restablecer bit Puertos[AtenderServoTemp1] = ‘0’. Desactivar Temporizador 1. Temporizador 3: Asignar AtenderServoTemp3 = Contador + 16. Restablecer bit Puertos[AtenderServoTemp3] = ‘0’. Desactivar Temporizador 3.

El listado del Anexo B muestra las partes más significativas del programa en lenguaje

ensamblador correspondiente al paquete controlador de servomotores.



7.3 Diseño y codificación del paquete controlador principal WHEX 1.

En las siguientes secciones se describe el proceso de diseño y codificación del paquete de

firmware controlador principal WHEX 1.

Serán tratados a continuación los siguientes aspectos:

Arquitectura general del paquete.

Comunicación con el exterior.

Gestor de peticiones.

Cinemática inversa.

Generador de movimientos.

Gestión de periféricos.

7.3.1 Arquitectura general del paquete Controlador principal WHEX 1.

El paquete controlador principal WHEX 1 ha sido diseñado optimizando al máximo cada uno de

sus componentes, tanto en cantidad de código como en eficiencia del mismo. Esta optimización

ha sido necesaria pues sus algoritmos presentan una mayor complejidad que los del

controlador de servomotores y al igual que estos, deben ejecutar en un microcontrolador

PIC18F4525, con una memoria de programa de tan solo 48 KB y un reloj principal de 24 MHz.

El esquema de la figura 7.11 muestra la arquitectura de este paquete de firmware.

Fig. 7.11: Arquitectura del paquete de firmware controlador principal WHEX 1: componentes principales e interfaces de comunicación con el exterior.

En el esquema de la figura 7.11 pueden apreciarse los componentes principales de este

paquete así como sus interfaces de comunicación internas y externas.



El ordenador de a bordo genera comandos que son enviados al controlador a través del driver

RS232 integrado en la placa controladora WHEX 1.

Los comandos recibidos por el controlador principal WHEX 1 son tratados por el módulo

“Comunicación con el exterior”, específicamente por el “Gestor del puerto serie” y puestos en

una cola de peticiones administrada por el “Gestor de peticiones”; entonces, según el orden de

llegada, las peticiones son atendidas dependiendo de su tipo por el “Generador de

movimientos” o por el “Gestor de periféricos”.

Tanto el “Generador de movimientos” como el “gestor de periféricos” pueden generar

comandos que son enviados mediante el módulo “Maestro I2C” y a través del bus I2C hacia los

controladores de servomotores y otros periféricos conectados a dicho bus.

El módulo “Generador de movimientos” delega cálculos relacionados con la geometría del robot

al módulo de “Cinemática inversa”, que se encarga de calcular los valores de los ángulos de

cada articulación del robot para adoptar una postura concreta. Una vez calculados los ángulos

de las articulaciones, el “Generador de movimientos” envía mediante el “Maestro I2C” los

comandos de actualización de servomotores necesarios para que el robot adopte la postura

deseada.

El módulo “Gestor de periféricos” se encarga de controlar los periféricos conectados al robot,

tanto si son del tipo I2C como si no lo son. En caso de que se desee controlar un periférico que

no es de tipo I2C, esto se realiza directamente mediante los puertos digitales y analógicos

presentes en la placa controladora WHEX 1, en otro caso, el periférico I2C es controlado a

través del módulo “Maestro I2C”, que se encarga de gestionar la comunicación mediante este

bus.

Por último, en el diagrama de la figura 7.11 pueden ser apreciadas las interfaces de

comunicación con el exterior de este paquete de firmware:

Interfaz serie (RS232): comunicación con el ordenador de a bordo del robot WHEX 1.

Interfaz bus I2C: configurada en modo maestro único del bus, para controlar periféricos

I2C que se conecten al bus en modo esclavo, incluyendo los dos controladores de

servomotores que utiliza el robot WHEX 1.

Puertos digitales y analógicos de la placa controladora: comunicación con los

periféricos no I2C conectados a dichos puertos.

7.3.2 Comunicación con el exterior.

El modulo de comunicación con el exterior se encarga de gestionar las transferencias de

información mediante el puerto serie RS232 y el bus I2C. Como se ha visto en la sección

anterior, el puerto serie RS232 se utiliza para la comunicación con el ordenador de a bordo del

robot y el bus I2C para el control de periféricos que emplean este bus, incluyendo los

controladores de servomotores diseñados para WHEX 1.

7.3.2.1 Puerto serie RS232.

El puerto serie ha sido configurado con los siguientes parámetros:

38400 Baudios.

8 bits de datos.

1 bit de parada.

Sin bit de paridad.



La información intercambiada a través del puerto serie ha sido organizada en forma de

comando – respuesta y notificaciones hacia atrás.

El ordenador de a bordo envía comandos de 8 o 16 bits; de los cuales, los primeros 8 bits

identifican el comando y los siguientes 8 bits, opcionales, transportan los datos que necesita el

comando. La tabla completa de comandos aceptados por el controlador principal WHEX 1 y los

datos que necesitan se puede consultar en el anexo A.

Opcionalmente, el ordenador de a bordo puede enviar un byte con el valor hexadecimal 0xFF.

Este byte es considerado por el controlador como un byte de sincronización, es decir, al ser

recibido este byte el controlador WHEX 1 descarta el comando que se pudo haber recibido con

anterioridad, asumiendo que el próximo byte que recibirá es un nuevo comando y no un dato.

Por cada byte recibido, ya sea un byte de sincronización, un comando o un dato, se envía un

carácter 0x21 hacia el ordenador a modo de notificación de la recepción.

El diagrama de la figura 7,12 muestra el autómata finito que gestiona la recepción de

comandos a través del puerto serie.

Fig. 7.12: Máquina de Moore que gestiona la recepción de comandos a través del puerto serie.

A. Enviar hacia el ordenador, a través del puerto serie, el carácter 0x21.

B. Enviar hacia el ordenador, a través del puerto serie, el carácter 0x21.

C. Entregar el comando y opcionalmente el dato recibidos al módulo “Gestor de peticiones”.

El autómata de la figura 7.12 se ejecuta cada vez que se recibe un byte de información a través

del puerto serie y, dependiendo el estado, realiza las siguientes acciones:

Estado 0: en este estado el autómata espera como entrada un comando o el byte de

sincronización.

o En caso de recibirse el byte de sincronización la máquina permanece en el

estado 0 y se notifica la recepción enviando por el puerto serie el byte 0x21.

o En caso de recibirse un comando menor que 6, la máquina pasa al estado 2,

donde se envía el comando recibido al módulo “Gestor de peticiones” para que

sea puesto en la cola de ejecución y automáticamente se retorna al estado 0,

notificando la recepción con el envío del carácter 0x21.

o En caso de recibirse un comando mayor o igual a 6, la máquina pasa al estado

1, notificando la recepción con el envío del carácter 0x21.

Estado 1: en este estado el autómata espera como entrada un dato, o el byte de

sincronización.

o En caso de recibirse el byte de sincronización la máquina retorna al estado 0 y

se notifica la recepción enviando por el puerto serie el byte 0x21.

o En caso de recibirse un dato, la máquina pasa al estado 2, donde se envían el

comando y dato recibidos al módulo “Gestor de peticiones” para que sean



puestos en la cola de ejecución y automáticamente se retorna al estado 0,

notificando la recepción con el envío del carácter 0x21.

Estado 2: En este estado no se espera entrada alguna, solo se envían el comando y

opcionalmente el dato recibidos al módulo “Gestor de peticiones” para que se coloque

en la cola de ejecución y automáticamente se retorna al estado 0.

El algoritmo siguiente implementa a este autómata y se ha establecido como rutina de atención

a la interrupción del puerto serie del PIC:

Leer por RS232 TempLeido. Si TempLeido == 0xFF

Asignar Estado = 0. Sino Si Estado == 0

Asignar Comando = TempLeido. Si Comando > 5

Asignar Estado = 1. Sino

Ejecutar GestorPeticiones.Añadir(Comando). Fin Si

Sino Asignar Dato = TempLeido. Ejecutar GestorPeticiones.Añadir(Comando, Dato). Asignar Estado = 0.

Fin Si Enviar por RS232 0x21.

7.3.2.2 Maestro del Bus I2C.

La otra funcionalidad del módulo de comunicación con el exterior, además de la gestión del

puerto serie explicada en la sección anterior, es la de controlar el bus I2C de la placa

controladora WHEX 1.

Se ha configurado el módulo hardware SSP del PIC para que funcione en modo maestro I2C,

con los siguientes parámetros:

Modo maestro.

Baja velocidad.

Líneas utilizadas:

o SDA: C4.

o SCL: C3.

Con la configuración anterior ya es posible gestionar todos los periféricos de tipo I2C que sean

conectados al bus en modo esclavo, incluyendo los dos controladores de servomotores que

utiliza el robot WHEX 1, estos se han configurado en las direcciones I2C siguientes:

Controlador #1: 22h

Controlador #2: 24h

Así mismo la dirección del sensor de distancias por ultrasonido SRF08 utilizado se ha

establecido al valor E0h.



7.3.3 Gestor de peticiones.

El controlador principal WHEX 1 debe estar siempre disponible para atender peticiones

provenientes del ordenador de a bordo a través del puerto serie, así que el diseño del firmware

debe minimizar el tiempo mínimo entre peticiones consecutivas, para así reducir la probabilidad

de perder una petición por no estar escuchando al puerto serie en el momento de su llegada.

Como se ha explicado en secciones anteriores, cada vez que se recibe un byte de información

en el puerto serie se desencadena una interrupción que hace que sea ejecutado el algoritmo

del autómata de la figura 7.12. Durante el tiempo de ejecución de esta rutina de interrupción

serán descartados todos los bytes de información que se reciban a través del puerto serie; por

tanto, es necesario que dicha rutina tenga un tiempo de ejecución mínimo.

Para lograr ese tiempo de ejecución mínimo se hace imprescindible un diseño que permita la

ejecución asíncrona de los comandos recibidos. Esto se ha logrado utilizando una cola donde

los comandos recibidos son depositados para que esperen su turno de ejecución y de este

modo la rutina de interrupción del puerto serie pueda retornar inmediatamente después de

colocar el comando en la cola.

Fig. 7.13: Arquitectura interna del gestor de peticiones que permite la ejecución asíncrona de comandos.

El esquema de la figura 7.13 muestra la arquitectura interna del módulo “Gestor de peticiones”,

y como elemento principal de esta arquitectura se puede apreciar la cola de comandos.

La cola de comandos posibilita que los comandos puedan ser ejecutados de forma asíncrona

por un proceso diferente a la rutina de interrupciones que gestiona el puerto serie, de forma tal

que dicha rutina retorna inmediatamente una vez que el comando ha sido añadido a la cola,

minimizando su tiempo de ejecución.

En orden de llegada a la cola, los comandos son extraídos secuencialmente de esta y

ejecutados.

La longitud de la cola debe fijarse lo suficientemente grande como para que no desborde, este

valor se ha calculado de forma empírica y se ha establecido a 50.



7.3.4 Cinemática inversa

La cinemática inversa puede ser aplicada de forma específica a todo tipo de robot con

articulaciones móviles, de forma tal que partiendo de los datos que describen una postura del

robot, puedan ser calculados los valores angulares que cada articulación debe tomar para

lograr dicha postura.

WHEX 1 es un robot móvil de seis patas, cada una de las cuales presenta tres articulaciones:

una en la rodilla (llamada “rodilla”) y dos en la cadera (llamadas “cadera 1” y “cadera 2”). Cada

una de estas patas puede ser modelada como un brazo robótico de tres grados de libertad,

cuya postura se define con un punto en el espacio tridimensional donde el extremo de la pata

debe situarse.

Siguiendo el análisis anterior, el problema cinemático inverso específico del robot WHEX 1 se

ha dividido en 7 ámbitos: un ámbito global, y 6 ámbitos locales: uno para cada pata del robot.

Cada ámbito tiene su propio sistema de coordenadas rectangulares, la figura 7.14 muestra

dichos sistemas de coordenadas.

Los ejes Z de estos sistemas de coordenadas presentan la misma dirección y sentido

(ascendente), siendo paralelos entre sí.

Fig. 7.14: Sistemas de coordenadas definidos para la resolución de la cinemática inversa del robot hexápodo WHEX 1.

Entonces, el proceso de resolución de los valores angulares de las articulaciones para lograr

una postura se divide en los siguientes apartados:

A partir de los datos que definen la postura que se desea adoptar33

, calcular los puntos

(relativos al sistema global de coordenadas) en los cuales deben situarse los extremos

de las 6 patas del robot.

33

Estos datos se explican en la especificación de requisitos.



Para cada pata:

o Realizar el cambio de coordenadas del punto donde debe posicionarse el

extremo de la pata al sistema de coordenadas local de la pata.

o Determinar el valor angular que debe tomar cada articulación de la pata para

que esta se posicione en el punto deseado utilizando cinemática inversa.

Del proceso anterior solo será explicado en esta sección el método empleado para determinar

los ángulos que deben adoptar las articulaciones de las patas para posicionar sus extremos en

un punto determinado, pues solamente en este apartado se utiliza cinemática inversa. La

explicación del resto de apartados puede encontrarse en la sección 7.3.5.

7.3.4.1. Cinemática inversa de las patas del robot WHEX 1.

Como ya se ha visto anteriormente, las patas del robot hexápodo WHEX 1 presentan dos

partes rígidas, articuladas mediante tres articulaciones, que le confieren tres grados de libertad.

Las articulaciones son las siguientes:

En la rodilla:

Articulación de la rodilla.

En la cadera:

Articulación horizontal de la cadera (llamada cadera 1).

Articulación vertical de la cadera (llamada cadera 2).

El problema a resolver mediante cinemática inversa es el siguiente:

Dado un punto en el espacio tridimensional definido por el sistema de coordenadas local de la

pata (ver figura 7.14), determinar los tres ángulos que deben tomar las articulaciones de la

cadera y la rodilla para posicionar el extremo de la pata en dicho punto.

Resolución:

Las patas del robot WHEX 1 están formadas por dos piezas de diferentes longitudes. La

diferencia de dichas longitudes es de unos 3 cm. A pesar de lo anterior, para el cálculo de la

cinemática inversa se han modelado las patas como si ambas piezas tuvieran la misma

longitud L. Esta aproximación ha sido necesaria debido a que los cálculos del modelo original

consumían más tiempo que el máximo admisible, retardando excesivamente la ejecución de

todo el programa. Es preciso mencionar que se ha verificado de forma empírica el buen

funcionamiento de esta aproximación.

Se han definido las siguientes variables:

P(X,Y,Z): Punto en el que se desea posicionar el extremo de la pata.

Norma: Distancia del punto P al origen del sistema de coordenadas.

W: Distancia del punto P al eje Z del sistema de coordenadas.

a: Ángulo de la rodilla de la pata cuando el extremo de esta se encuentra situado en P.

b: Ángulo de la Cadera 2 de la pata cuando el extremo de esta se encuentra situado en P.

c: Ángulo de la cadera 1 de la pata cuando el extremo de esta se encuentra situado en P.

y la constante:

L: Longitud de las dos piezas rígidas de la pata.



La solución obtenida calcula los tres ángulos a, b y c de las articulaciones para cualquier punto

que se encuentre dentro del alcance de la pata. Los ángulos a y c se calculan de forma

semejante para todos estos puntos, mientras que para el cálculo del ángulo b es necesario

diferenciar dos casos específicos:

Caso 1: Z < 0.

Caso 2: Z ≥ 0.

La figura 7.15 muestra la representación geométrica tridimensional del modelo empleado para

los cálculos de la cinemática inversa y la figura 7.16 muestra las proyecciones en el plano ZW

correspondientes a los casos 1 y 2 anteriormente explicados.

Fig. 7.15: Modelo geométrico tridimensional de una pata del robot WHEX 1.

a) b)

Fig. 7.16: Proyección del modelo geométrico de la figura 3.67 en el plano ZW.

a) Caso para Z < 0.

b) Caso para Z >= 0.

Calcular el ángulo a:

(8)



Como:

∆ORP es isósceles, pues como se puede ver en la figura 7.16 las longitudes de sus

lados y son iguales a L.

es mediatriz del triángulo ORP relativa su lado y también bisectriz relativa al

ángulo , pues contiene al vértice R del triángulo isósceles ORP y OMR es

recto.

, pues es bisectriz del ángulo .

Entonces, de la ecuación (8) se obtiene:

(9)

Como ∆ORM es rectángulo, se cumple entre sus lados la función seno, y:

(10)

Como , por ser mediatriz relativa al lado del triángulo ORP, entonces:

(11)

Calcular el ángulo b:

Para el cálculo del ángulo b, el problema se ha dividido en dos casos: cuando Z < 0 y cuando

Z ≥ 0. Las figuras 7.16a y 7.16b muestran estos casos.

Caso 1: Z < 0

Al observar la figura 7.16a se puede ver que:

(11)

Como:

, por suma de ángulos interiores de un triángulo.

, por ser los ángulos opuestos a los lados iguales de un triángulo

isósceles.

se obtiene, a partir de la ecuación (11):

(12)

Como ∆OZP es rectángulo y partiendo de la ecuación (12), se plantea:

(13)

Caso 2: Z ≥ 0

Al observar la figura 7.16b se puede ver que:

(14)



Partiendo de la ecuación anterior, y siguiendo la misma deducción que dio como resultado la

ecuación (12) se obtiene:

(15)

Como ∆OWP es rectángulo y partiendo de la ecuación (15):

(16)

Calcular el ángulo c:

Al observar la figura 7.15 se puede apreciar que ∆NPZ es rectángulo, por tanto se plantea:

(17)

Las ecuaciones 11, 13, 16 y 17 se utilizan para el cálculo de los ángulos de las articulaciones

de la pata, obteniendo los resultados en radianes; pero los controladores de servomotores no

tratan los ángulos en radianes, sino mediante un byte donde el valor 0 corresponde a los 0

radianes y el 255 a los π radianes. Por tanto es necesario definir una ecuación de conversión

para expresar los valores de ángulos en la unidad de medida utilizada por los controladores de

servomotores.

Utilizando regla de tres:

(18)

Y despejando en la ecuación (18) obtenemos la relación de conversión:

(18)

7.3.4.2. Algoritmo para el cálculo de los ángulos

Utilizando el modelo matemático explicado se ha codificado el siguiente algoritmo de cálculo de

los ángulos que deben tomar las articulaciones de las patas del robot para posicionar su

extremo en un punto determinado:

Función CalcularAngulos(Punto P, Int L): AngulosPata ap

Asignar Norma = sqrt(P.X*P.X + P.Y*P.Y + P.Z*P.Z). Asignar a = 2*asin(Norma/(2*L)). Asignar W = sqrt(P.X*P.X + P.Y*P.Y). Si P.Z < 0

Asignar b = 180-(180-a)/2-asin(W/Norma). Sino

Asignar b = 90-(180-a)/2-asin(P.Z/Norma). Fin Si Asignar c = acos(P.X/W). Asignar ap.rodilla = (255*a)/PI. Asignar ap.cadera1 = (255*b)/PI. Asignar ap.cadera2 = (255*c)/PI.

Fin función



7.3.5 Generador de movimientos.

El módulo generador de movimientos es el encargado de generar en todo momento las

coordenadas tridimensionales de los extremos de las patas del robot para que este adopte una

postura determinada, camine o gire. Además, este módulo debe enviar las coordenadas

calculadas al módulo de cinemática inversa para que sean determinados los ángulos de las

articulaciones y por último enviar dichos ángulos al controlador de servomotores para que el

robot haga efectivo el movimiento.

El robot WHEX 1 es capaz de adoptar posturas complejas además de caminar y rotar de cuatro

modos diferentes, dos de los modos mueven solo una pata cada vez, mientras que los otros

dos modos mueven dos y tres patas de forma simultánea respectivamente. El cálculo y

ejecución de estas secuencias de movimientos es responsabilidad íntegra del generador de

movimiento.

El software del generador de movimientos se ha diseñado como una máquina de estados de

tipo Moore, la cual ejecuta las acciones necesarias basándose en la información de estado con

que cuenta. La figura 7.17 muestra de forma simplificada al autómata que implementa el

generador de movimientos.

Fig. 7.17: Esquema que muestra al autómata que implementa el generador de movimientos.

Estados

0: Durmiendo.

1: Detenido.

2: Caminando.

3: Rotando.

4: Deteniendo.

* Fin de la secuencia de movimientos que se estaban ejecutando al recibir

la orden de detenerse.

El estado en el que se encuentra el generador de movimientos en un momento dado está

constituido por los siguientes componentes:

Estado del robot.

Estado de cada una de las seis patas del robot

El estado del robot se define como una enumeración de los siguientes conceptos:

Durmiendo: En este estado el robot se encuentra apoyado en su cuerpo, con las seis

patas posicionadas junto a él.

Detenido: En este estado el robot adopta la postura que se le ordene, soportando todo

su peso en las 6 patas.



Caminando: En este estado el robot se desplaza siguiendo un vector de movimiento

establecido previamente.

Girando: En este estado el robot gira sobre su propio eje.

Deteniendo: En este estado el robot está realizando los últimos movimientos de una

secuencia de caminar o girar, para pasar al estado de Detenido.

Cada pata del robot se encuentra en todo momento en uno de los siguientes estados:

Recogida: En este estado la pata se encuentra totalmente recogida al lado del cuerpo

del robot, sin soportar peso alguno. Este estado se corresponde con el estado de

“Durmiendo” del robot.

En punto neutro: en este estado la pata se encuentra apoyada y detenida en su

posición de postura normal, correspondiéndose con el estado de “Detenido” del robot.

Moviendo: en este estado la pata se encuentra apoyada y desplazándose en un paso,

ya sea cuando el robot se encuentra caminando o rotando.

Avanzando: En este estado la pata se encuentra levantada y moviéndose para iniciar

un nuevo paso, ya sea cuando el robot se encuentre caminando o rotando.

La figura 7.18 muestra las transiciones entre los estados definidos para las patas del robot.

Fig. 7.18: Diagrama que muestra los estados en los que puede encontrarse una pata del robot y las transiciones entre estos.

Estados

0: Recogida.

1: En punto neutro.

2: Avanzando.

3: Moviendo.

Entonces, el estado del módulo generador de movimientos puede ser expresado de la siguiente

forma:

[Estado del robot, [Estado Pata 1, Estado pata 2, … , Estado pata 6]]

Por ejemplo, una vez encendido el robot, el estado se establece a:

[Durmiendo, [Recogida, Recogida, Recogida, Recogida, Recogida, Recogida]

Basándose en el estado actual, el generador de movimientos determina qué acciones debe

realizar, dividiendo el problema en cuatro partes principales, que se corresponden con los

estados del robot: Durmiendo, Detenido, Caminando y Rotando.

En las secciones siguientes se explicarán los algoritmos de generación de las secuencias de

movimientos relacionadas con cada uno de estos estados.



7.3.5.1 Durmiendo

Al encenderse el robot o al recibir el comando Dormir este pasa al estado Durmiendo,

posicionando todas las patas de forma simultánea al lado del cuerpo y apoyándose mediante

este en la superficie donde se encuentra. En este estado el consumo de energía es mínimo,

pues el peso total del robot se apoya en el cuerpo y no en las patas, liberando por completo los

servomotores.

Para posicionar las patas en la posición correcta se ha creado el siguiente algoritmo:

Dormir: Asignar punto = (0, 1, -2). Para cada pata p, repetir:

Ejecutar MoverPata(p, punto, 1). Fin repetir.

El algoritmo de la función MoverPata es el siguiente:

Función MoverPata(Pata pata, Punto punto, Int velocidad): bool res

Asignar ap = CalcularAngulos(punto, 10). Si ap.rodilla != 0xFF

Ejecutar MoverServo(pata.servoRodilla, ap.rodilla, velocidad); Ejecutar MoverServo(pata.servoCadera1, ap.cadera1, velocidad); Ejecutar MoverServo(pata.servoCadera2, ap.cadera2, velocidad); Asignar Res = true.

Sino Asignar Res = false.

Fin Si Fin función. Función MoverServo(Int servo, Int ángulo, Int velocidad)

Asignar dirección = 0x22. Si servo >= 24

Asignar dirección = 0x24. Asignar servo = servo – 24.

Fin Si Enviar comando por I2C dirección, COM_ENVIAR_VELOCIDAD, velocidad. Enviar comando por I2C dirección, COM_ENVIAR_POSICION, ángulo. Enviar comando por I2C dirección, COM_ACTUALIZAR_SERVO, servo.

Fin función.

7.3.5.2 Detenido.

Cuando se recibe el comando Adoptar postura o Detenerse, el generador de movimientos pasa

al estado Detenido, en el cual se mantiene inmóvil la postura que se ha definido con

anterioridad, según los parámetros siguientes:

Altura del cuerpo: Valor negativo que define la altura del cuerpo en centímetros, a

menor valor de este parámetro, mayor es la altura del cuerpo del robot.

Apertura de patas: Valor que define el grado de separación de las patas del robot en

centímetros, a mayor valor de este parámetro, mayor es la apertura de las patas del

robot.



Torsión del cuerpo: Ángulo en grados que define la rotación del cuerpo del robot

alrededor del eje Z del sistema global de coordenadas.

Descentre del cuerpo: Vector en R2 que, unido a la componente Z proporcionada por el

parámetro “Altura del cuerpo”, define la posición del centro geométrico del cuerpo del

robot en el sistema de coordenadas global.

Inclinación longitudinal del cuerpo: valor en centímetros que define la mitad de la

diferencia de alturas entre la parte anterior y la parte posterior del cuerpo.

Inclinación transversal del cuerpo: valor en centímetros que define la mitad de la

diferencia de alturas entre la parte derecha y la parte izquierda del cuerpo.

Vector de posición de cada pata: este parámetro es específico de cada pata y es un

vector unitario en R2, relativo al sistema de coordenadas local de la pata, que

determina la razón de las coordenadas de la pata cuando el robot se encuentra en

estado Detenido.

Basándose en los parámetros anteriores se ha definido el concepto de Punto Neutro de la pata,

que no es más que el punto en el que debe posicionarse el extremo de la pata cuando el robot

está en estado Detenido para que la postura final del mismo sea la definida por los parámetros

anteriormente establecidos. Las coordenadas del punto neutro de cada pata son relativas al

sistema de coordenadas local de la pata (ver figura 7.14)

Para calcular el punto neutro de una pata se ha creado el algoritmo siguiente:

Función CalcularPuntoNeutro(Pata pata, ParametrosPostura parametros)

Asignar vectorTemp = MultiplicarPorEscalar(pata.vectorPosicion, parámetros.AperturaPatas). Asignar descentreTemp = ConvertirSistLocal(parámetros.DescentreCuerpo). Asignar vectorTemp.X = vectorTemp.X + descentreTemp.X. Asignar vectorTemp.Y = vectorTemp.Y + descentreTemp.Y. Si pata.Izquierda

Asignar parametros.TorcionCuerpo = -1 * Parametros.TorcionCuerpo. Fin Si Asignar vectorTemp = RotarVector(vectorTemp,parámetros.TorcionCuerpo). Asignar elevaciones = CalcularElevaciones(parametros.AlturaCuerpo, parametros.InclinacionLong, parametros.InclinacionTrans). Asignar vectorTemp.Z = elevaciones[pata.Indice]. Asignar pata.PuntoNeutro = vectorTemp.

Fin función. Función CalcularElevaciones(float Altura, float IncLong, float IncTrans): vector[6] v

Asignar temp = Altura + IncLong. Asignar v[3] = temp + IncTrans. Asignar v[0] = temp - IncTrans. Asignar temp = Altura - IncLong; Asignar v[5] = temp + IncTrans. Asignar v[2] = temp - IncTrans. Asignar v[1] = Altura + IncTrans. Asignar v[4] = Altura - IncTrans.

Fin función.



El algoritmo siguiente se utiliza para adoptar una postura determinada por los parámetros

anteriormente explicados:

Adoptar postura: Para cada pata p, repetir:

Ejecutar CalcularPuntoNeutro(p, parametros). Ejecutar MoverPata(p, p.PuntoNeutro, velocidad).

Fin repetir.

7.3.5.3 Caminando.

Al recibir el comando Caminar, el generador de movimientos pasa al estado Caminando, en

este estado el robot se desplaza siguiendo un vector de dirección establecido previamente.

El desplazamiento del robot está determinado por los siguientes parámetros:

Vector de dirección: este parámetro es un vector en R2, relativo al sistema de

coordenadas global, que determina la dirección en la cual se desplaza el robot.

Grado de giro al desplazarse: este parámetro es un valor real, acotado entre -1 y 1, que

determina el grado de cambio de dirección que tendrá el desplazamiento del robot. Si

el parámetro tiene un valor positivo el robot se desplaza cambiando de dirección hacia

la izquierda, si el valor es negativo el cambio de dirección es hacia la derecha y si el

valor es igual a cero, el robot camina en línea recta.

Modo de desplazamiento: el robot puede caminar de cuatro modos diferentes:

o Modo0: en este modo el robot se desplaza muy lentamente, moviendo solo una

pata en cada ocasión.

o Modo1: en este modo el robot se desplaza más velozmente que en el modo 0

pues se ha aumentado la longitud del paso, moviendo solo una pata cada vez.

o Modo2: en este modo el robot se desplaza moviendo dos patas

simultáneamente.

o Modo3: en este modo el robot se desplaza moviendo tres patas

simultáneamente, es el modo de desplazamiento más veloz y en el cual hay

mayor gasto de energía.

Para desplazarse, ya sea en el modo 0, 1, 2 o 3, el robot realiza una secuencia continua de

pasos orientados a avanzar según el vector de dirección de movimiento. Los pasos que cada

pata realiza se centran en su punto neutro, previamente establecido. La figura 7.19 muestra de

forma esquemática este concepto.

En la figura 7.19 puede apreciarse que los pasos de las patas de la derecha del robot tienen

una menor longitud que los de las patas de la izquierda, esto se debe a que el valor del grado

de giro al desplazarse tomado como ejemplo es -0.6, o sea, un valor negativo; entonces, las

patas de la derecha deben acortar sus pasos para que el robot cambie de dirección hacia ese

lado.



Fig. 7.19: Vista superior del robot WHEX 1 en la que se han representado mediante vectores los desplazamientos de las patas del robot cuando este camina.

El esquema de la figura 7.20 muestra, en una vista lateral, la secuencia de movimientos de una

pata en un paso, esta secuencia se repite continuamente mientras el robot camina. En esta

figura, los puntos etiquetados desde el 1 hasta el 6 se denominan puntos principales del paso,

los vectores de color azul corresponden a los movimientos de la pata cuando esta no está

apoyada (movimientos de posicionamiento para un nuevo paso) y los vectores de color negro

representan los movimientos de avance del paso, cuando la pata está apoyada.

Fig. 7.20: Secuencia de movimientos de una pata en un paso en la que se representan los puntos principales del paso y los vectores de movimiento implicados en este.

En los diagramas que acompañan las explicaciones que siguen a continuación se ha utilizado,

para referirse a cada pata del robot, la siguiente nomenclatura:

ID: Pata izquierda delantera.

DD: Pata derecha delantera.

IC: Pata izquierda central

DC: Pata derecha central.

IT: Pata izquierda trasera.

DT: Pata derecha trasera.

En cada paso, el robot puede ejecutar los movimientos de posicionamiento (vectores azules en

la figura 7.20) simultáneamente en varias patas: desde una hasta tres (dependiendo del modo

que se seleccione para caminar). En los modos 0 y 1 se ejecutan estos movimientos en sólo

una pata a la vez; en el modo 2 se ejecutan estos movimientos en dos patas simultáneamente

y en el modo 3 se ejecutan en tres patas.

Los esquemas de las figuras 7.21, 7.22 y 7.23 muestran las secuencias que utiliza el robot

WHEX 1 al caminar. En estos esquemas, el trazo azul simboliza el tiempo empleado por la pata



en ejecutar los movimientos de posicionamiento para un nuevo paso y la línea fina simboliza el

tiempo que tarda la pata en ejecutar los movimientos de avance del paso.

Fig. 7.21: Secuencia de pasos que ejecuta el robot WHEX 1 al caminar y rotar en los modos 0 y 1.

Fig. 7.22: Secuencia de pasos que ejecuta el robot WHEX 1 al caminar y rotar en el modo 2.

Fig. 7.23: Secuencia de pasos que ejecuta el robot WHEX 1 al caminar y rotar en el modo 3.



En los esquemas de las figuras 7.21, 7.22 y 7.23 se han representado los extremos de las

secuencias de pasos mediante una línea vertical un poco más gruesa que las demás. En esos

instantes termina una secuencia completa y se inicia la siguiente, dando como resultado un

movimiento continuo y repetitivo.

Se puede observar en estos diagramas que en los modos 0 y 1 se ejecutan los movimientos de

avance del paso (vectores negros en la figura 7.20) más lentamente que en el modo 2, y en

este más lentamente que en el modo 3, resultando en velocidades de desplazamiento

diferentes.

7.3.5.3.1 Cálculo de las coordenadas de los puntos implicados en un paso.

La figura 7.24 muestra, de forma similar al diagrama de la figura 7.20, los 6 puntos que definen

los vectores del movimiento de la pata en un paso. Para un mejor entendimiento de las

explicaciones estos puntos serán denotados según la figura, con números desde el 1 hasta el

6. También se ha representado el punto neutro de la pata y algunas distancias importantes en

los cálculos como son la elevación, ancho y variación del paso.

Fig. 7.24: Secuencia de movimientos de una pata en un paso en la cual han sido anotadas las dimensiones entre los puntos principales del paso.

No se puede perder de vista que los vectores representados en los diagramas de las figuras

7.20 y 7.24 no pertenecen a R2, sino que pertenecen al espacio R3 definido por el sistema de

coordenadas local de la pata. La dimensión horizontal en estos diagramas es paralela al vector

de dirección de movimiento y la dimensión vertical se corresponde con el eje Z del sistema de

coordenadas local de la pata.

Para calcular las coordenadas de los puntos principales del paso se parte del punto neutro de

la pata que es en sí el punto medio del paso (ver figuras 7.19 y 7.24). Se define:

: Coordenadas del punto neutro de la pata relativas al sistema de

coordenadas local.

Las ecuaciones utilizadas para calcular los puntos principales del paso son ecuaciones

iterativas, es decir, cada ecuación necesita del resultado de la ecuación anterior para

evaluarse.

Como datos para el cálculo de las coordenadas se cuenta con los parámetros que definen el

desplazamiento del robot: vector de dirección del movimiento ( ), grado de giro al

desplazarse (GG) y modo (M). Además de estos datos, se cuenta con los siguientes:

Elevación del paso (EP): Valor real positivo que define la altura a la que debe

mantenerse la pata cuando esta está efectuando los movimientos de posicionamiento

para un nuevo paso.



Descriptor del ancho máximo del paso (AMP): Valor real, dependiente del modo de

desplazamiento, que representa la tercera parte del valor máximo del ancho total de los

pasos.

Valores temporales necesarios para el cálculo de las coordenadas de los puntos del paso

(relativos a cada pata):

Dirección del paso ( ): Vector que define la dirección del paso y que tiene por norma

la mitad del ancho total del paso después de calcular el impacto del grado de giro sobre

la pata en cuestión. (ver figura 7.24)

Variación del Paso ( ): Vector que define los movimientos de avance del paso y que

tiene por norma la tercera parte del ancho total del mismo después de calcular el

impacto del grado de giro sobre la pata en cuestión. (vectores negros en las figuras

7.20 y 7.24).

Con los datos ya expuestos es hora de definir las ecuaciones que se han utilizado, no sin antes

aclarar que todas las coordenadas calculadas por estas ecuaciones son relativas al sistema de

coordenadas local de la pata.

Dirección del paso

Para calcular este vector es necesario definir su norma, la cual es igual a 1.5*AMP si la pata se

encuentra en el lado opuesto a donde debe girar el robot según GG, en otro caso dicha norma

se ve afectada por GG:

(19)

(20)

Una vez calculada la norma del vector, podemos generar las componentes del mismo. Esto se

hace generando primeramente el vector unitario relativo a con coordenadas en el sistema

local de la pata y multiplicándolo por la norma previamente calculada:

(21)

Variación del paso

El vector variación del paso es un vector con dirección paralela a la dirección del movimiento

pero con sentido opuesto y con una norma igual a la tercera parte del ancho total del paso:

(22)

Puntos principales del paso

El primer vector a calcular en la secuencia es , este se obtiene sumándole el valor EP a la

componente Z del vector resultante de la sustracción vectorial de a :

(23)



se obtiene mediante la suma vectorial de y un vector con dirección y sentido iguales a

los de y con el doble de norma.

(24)

se obtiene restando a la coordenada Z de P3 el valor EP:

(25)

Los vectores , y se obtienen iterativamente sumando el vector :

(26)

(27)

(28)

7.3.5.3.2 Algoritmo generador de las secuencias de pasos

Para programar las secuencias de pasos que cumplan con los requisitos anteriormente

explicados se ha diseñado un autómata de tipo Moore, sincronizado utilizando el temporizador

0 del PIC. El temporizador 0 se ha configurado en modo de 16 bits con divisor de frecuencias

(prescaler) de 1:256 y se ha precargado con el valor 63426, resultando en una interrupción

cada 90 ms aproximadamente (tiempo entre pulsos en los diagramas de las figuras 7.21, 7.22 y

7.23).

La figura 7.25 muestra al autómata que implementa el generador de movimientos (que se

puede apreciar en su forma simplificada en la figura 7.17), al cual se han añadido los sub-

estados encargados de generar las secuencias de pasos cuando el robot camina.

Una vez el robot alcanza el estado Caminando (por recibir el comando Caminar), este entra al

sub-estado 2.0, activando el temporizador y comenzando así la secuencia de pasos, esto se

mantiene mientras no se reciba ninguno de los comandos que hacen que el robot abandone el

estado Caminando.

Fig. 7.25: Autómata generador de movimientos con el estado 2 ampliado.

Sub-estados del estado Caminando

2.0: Inicio de secuencia.

2.1: Levantar patas.

2.2: Avanzar patas.

2.3: Posicionar patas.

* Fin de la secuencia de movimientos que se estaban ejecutando al recibir

la orden de detenerse.



Respecto al autómata de la figura 7.25 es necesario mencionar que el estado “Caminando” se

puede abandonar independientemente del sub-estado en el que el autómata se encuentre en el

momento de recibir los comandos “Girar” y “Detenerse”.

7.3.5.3.3 Algoritmo

Para codificar las secuencias de pasos se ha diseñado un algoritmo, el cual se explicará a

continuación.

Las patas del robot se tratan como miembros de una lista indexada en la cual el orden define la

secuencia en que las patas se moverán (ver figuras 7.21, 7.22 y 7.23). La tabla 7.3 muestra el

orden asignado a las patas para cada modo de funcionamiento.

Índice Modos 0, 1 y 2 Modo 3

0 IT IT

1 DD ID

2 DT DC

3 ID DD

4 DC DT

5 IC IC

Tabla 7.3: Orden de las patas asignado a cada uno de los modos de funcionamiento del robot.

El algoritmo mantiene tres índices que apuntan a las patas que debe mover en cada momento

según el modo de funcionamiento. Al comenzar cada secuencia de paso se actualizan dichos

índices. También se mantienen calculados los vectores y para agilizar los cálculos de los

puntos … en cada pata.

El algoritmo del autómata es el siguiente:

Caminar: // Estado 2.0 Si estado == 2.0

Para cada pata i, desde 0 hasta 5, repetir: Asignar listaPatas[i].Estado = Avanzando.

Fin repetir Ejecutar InicializarIndicesPatas(Modo). Ejecutar SeleccionarSiguientesPatas(Modo). Ejecutar MoverPatasSeleccionadasPunto2(Modo). Ejecutar EstablecerEstadoPatasSeleccionadas(Modo, Avanzando). Asignar estado = 2.1.

// Estado 2.1 Sino Si estado == 2.1

Ejecutar MoverPatasSeleccionadasPunto3(Modo).


Ejecutar MoverPatasSeleccionadasPunto4(Modo).




Ejecutar MoverPatasSeleccionadasPunto5(Modo). Ejecutar EstablecerEstadoPatasSeleccionadas(Modo, Moviendo). Ejecutar EstablecerContadorPasoPatasSeleccionadas(Modo). Ejecutar SeleccionarSiguientesPatas(Modo). Ejecutar MoverPatasSeleccionadasPunto2(Modo). Ejecutar EstablecerEstadoPatasSeleccionadas(Modo, Avanzando). Asignar estado = 2.1.

Fin Si. // Mover resto de patas que no estén en estado Avanzando Para cada pata i, desde 0 hasta 5, repetir:

Si listaPatas[i].Estado != Avanzando Si listaPatas[i].contadorPaso == 0

Ejecutar AvanzarPasoPata(listaPatas[i]). Sino

Asignar listaPatas[i].contadorPaso --. Fin Si

Fin Si Fin repetir

El algoritmo anterior es simple: en cada estado el autómata actualiza la posición de las patas

seleccionadas según el modo de funcionamiento, haciéndolas mover hacia el punto que le

corresponda.

En el estado 2.3 ocurre la transición entre una secuencia de paso y la siguiente; por tanto,

después de mover las patas seleccionadas hacia es necesario establecer el estado de

dichas patas a Moviendo y comenzar una nueva secuencia, seleccionando nuevamente las

patas que correspondan y haciéndolas mover hacia .

En todos los estados el autómata actualiza la posición de todas las patas que no se encuentren

en estado Avanzando, esto es necesario para que dichas patas ejecuten los movimientos hacia

y simultáneamente y a la velocidad necesaria.

7.3.5.4 Rotando.

Al recibir el comando Rotar, el generador de movimientos pasa al estado Rotando, en este

estado el robot gira sobre su propio eje.

En el estado Rotando el robot funciona de forma muy similar a como lo hace en el estado

Caminando: los mismos modos de funcionamiento, secuencias de pasos y el autómata que las

genera. La diferencia principal radica en la forma en que se calculan los puntos principales del

paso, que en este caso solo dependen del ángulo de giro que se halla establecido con

anterioridad.

La figura 7.26 muestra una vista superior del robot WHEX 1 en la que se han señalado con

arcos los movimientos de sus patas cuando este rota.



Fig. 7.26: Vista superior del robot WHEX 1 en la que se han representado mediante arcos los desplazamientos de las patas del robot cuando este rota.

El esquema de la figura 7.27 muestra la secuencia de movimientos de una pata cuando el robot

rota sobre su propio eje. Como puede apreciarse en esta figura solo existe un movimiento de

avance (vector negro), esto se debe principalmente a que el movimiento que se necesita tiene

forma de arco y por tanto no es necesario insertar puntos intermedios para que el trayecto sea

rectilíneo (como sucedía en el estado Caminando).

Fig. 7.27: Secuencia de movimientos de una pata en un paso cuando el robot rota sobre su propio eje.

Los puntos se calculan haciendo rotar las coordenadas del punto neutro de la pata un ángulo

determinado, utilizando para esto una matriz de rotación en R2.

7.3.5.5 Deteniendo.

Cuando se recibe el comando Detenerse, el robot pasa al estado Deteniendo. En este estado

se permanece mientras se concluya la secuencia de pasos actual y se esté en condiciones de

adoptar la postura definida por los puntos neutros de las patas, instante en el cual se pasa

automáticamente al estado Detenido.



7.3.6 Gestor de periféricos.

El último módulo del paquete de firmware del controlador principal WHEX 1 es el llamado

Gestor de periféricos, este módulo se ha incluido como soporte a futuras expansiones de

software relacionadas con la inclusión de nuevo hardware al robot, utilizando para ello los

puertos de expansión de la tarjeta controladora.

Los comandos dirigidos a este módulo comienzan siempre por un byte 0xEE, que le dice al

controlador que debe encaminar el siguiente byte al gestor de peticiones.

En estos momentos solo se da soporte al sensor de distancias por ultrasonido SRF08 instalado

en el robot mediante el bus I2C, permitiendo los comandos siguientes:

Realizar lectura de distancia: Este comando ordena una medición de la distancia

utilizando el sensor de distancias por ultrasonidos instalado en el puerto I2C en la

dirección 0xE0.

Realizar lectura de luminosidad: Este comando ordena una lectura de la intensidad de

luz mediante la LDR integrada en el sensor SRF08.

El listado del Anexo C muestra las partes más significativas del programa en lenguaje C para

PIC correspondiente al paquete controlador principal WHEX 1.

Elección y configuración del sistema operativo.


Capítulo

Elección y configuración del sistema operativo

8



8 Instalación y configuración del sistema operativo del ordenador de a bordo.

En el presente capítulo se aborda la instalación y configuración del sistema operativo del

ordenador de a bordo del robot, la figura 8,1 muestra los elementos de la arquitectura WHEX 1

tratados.


El hardware del ordenador de a bordo del robot WHEX 1 se ha configurado para permitir

ejecutar una versión de Linux como sistema operativo. Entre las múltiples distribuciones de

este sistema operativo se ha seleccionado la distribución Debian 5.0 “Lenny” debido

principalmente a que es una de las distribuciones “ligeras” más completa que existe y a su

facilidad de configuración.

El proceso de instalación se ha realizado desde el CD, conectando una unidad de CD externa a

través de uno de los puertos USB del robot y haciendo iniciar el ordenador de a bordo desde

esta unidad. La instalación se ha ejecutado conforme a los valores preestablecidos por los

desarrolladores de Debian y al concluir esta, se cuenta con un sistema operativo básico sin

entorno de escritorio ni software adicional.

Para configurar el sistema recién instalado se tienen dos opciones:

Conectar un monitor compatible VGA en el conector VGA integrado en el robot y un

teclado USB en uno de los puertos USB.

Configurar utilizando un ordenador externo, conectando vía SSH.

La primera opción resulta interesante para la configuración que se realice inmediatamente

después de instalar el sistema operativo, pues para la instalación es imprescindible tener estos

dispositivos conectados al robot; no obstante, es conveniente utilizar la segunda opción en

caso de realizar cambios a la configuración en algún momento posterior.

Para poder conectar mediante SSH es necesario contar con una interfaz de red operativa a

nivel 3 en el robot. La interfaz que se utiliza para este fin es la controladora Ethernet integrada,

así que antes de nada, es necesario configurar dicha interfaz.

La interfaz Ethernet se ha configurado con los siguientes parámetros:

Modo: estático

IP: 192.168.60.100

Máscara: 255.255.255.0



Para efectuar esta configuración es necesario editar el fichero /etc/network/interfaces,

añadiendo o modificando en caso de existir las siguientes líneas:

# The primary network interface

auto eth0

iface eth0 inet static

address 192.168.60.100

netmask 255.255.255.0

Hecho lo anterior se debe reiniciar el servicio de red:

$ /etc/init.d/networking -stop

$ /etc/init.d/networking -start

Con el interfaz Ethernet ya configurado se puede proceder a realizar la configuración del resto

de elementos necesarios.

Como ya se ha visto anteriormente, el robot WHEX 1 necesita que su sistema operativo brinde

soporte para los siguientes periféricos:

Multimedia: Controladora onboard AC’97.

Soporte WIFI: Controladora WIFI USB SMC EZ Connect.

Sensor de visión: Webcam Creative Live! Cam Notebook.

Librerías OpenCV para procesamiento de imágenes.

8.1 Instalación y configuración del driver multimedia.

La controladora de audio con que cuenta el ordenador de a bordo es una controladora AC’97,

con chipset Realtek. Para estas tarjetas se puede instalar el software Alsa, lo cual se hace

mediante los comandos siguientes:

$ aptitude install alsa-base alsa-utils alsa-tools alsa-oss oss-compat

$ alsaconf

Una vez ejecutados los comandos anteriores es necesario reiniciar el ordenador. Hecho esto ya

se ha instalado y configurado el driver de audio.

Además de la controladora de audio AC’97, el robot cuenta con una webcan Creative Live!

Cam y esta a su vez incluye hardware de audio (micrófono), por este motivo es necesario

configurar la controladora AC’97 como el dispositivo de reproducción y grabación de audio por

defecto del sistema.

Para esto, primeramente, listar los dispositivos de audio existentes:

$ cat /proc/asound/modules

0 snd_hda_intel

1 snd_usb_audio



Después se debe editar el fichero /etc/modprobe.d/alsa-base, añadiendo las siguientes líneas:

options snd_hda_intel index=0

options snd_usb_audio index=-2

En el fichero anterior, la línea con la anotación “index=0” establece el dispositivo por defecto.

8.2 Instalación y configuración de la controladora WIFI USB SMC EZ Connect.

Para la puesta en funcionamiento de esta tarjeta se han utilizado los drivers para Windows XP,

esto se ha hecho debido a que no existen drivers nativos para este hardware en Linux.

Para hacer funcionar drivers de red diseñados para Windows XP bajo entornos Linux se debe

instalar el software Ndiswrapper. Para instalar este paquete se debe ejecutar el siguiente

comando:

$ sudo aptitude install ndiswrapper-common ndiswrapper-modules-1.9

ndiswrapper-utils-1.9

Hecho lo anterior ya se cuenta con Ndiswrapper en el sistema, ahora es necesario cargar los

drivers de Windows XP que se desean utilizar:

$ sudo ndiswrapper -i driver.inf

Este comando copia el archivo driver.sys y crea una configuración para él. Hecho lo anterior es

necesario cargar el módulo Ndiswrapper, esto lo hacemos de la siguiente forma:

$ sudo depmod -a

$ sudo modprobe ndiswrapper

$ sudo ndiswrapper -m

Ahora es necesario editar el fichero /etc/modules para que al iniciarse el sistema se cargue

automáticamente Ndiswrapper. Para esto, se añade la siguiente línea:

ndiswrapper

8.2.1 Configuración de la WIFI.

Con los drivers de red ya instalados, es hora de configurar el sistema para que haga uso de la

WIFI, ya sea conectándose a una red inalámbrica existente o generando una red inalámbrica

propia en modo “ad hoc”.

Para configurar la WIFI es necesario editar el fichero /etc/network/interfaces. A continuación se

expondrán las distintas configuraciones posibles.



8.2.1.1 Conectándose a una red WIFI cifrada con WEP.

La configuración es la siguiente:

# Configuración en modo infraestructura con WEP

auto wlan0

iface wlan0 inet dhcp

wireless-essid SSID_RED

wireless-key s:CONTRASEÑA

Solo es necesario modificar donde se especifica el SSID y la contraseña de red y

posteriormente reiniciar el servicio de red.

En caso de que la red no cuente con un servidor DHCP que gestione las direcciones IP, puede

ser necesario modificar también la entrada iface, especificando que es del tipo static y añadir

entradas address y netmask que provean los parámetros de nivel 3 necesarios para configurar

el interfaz.

8.2.1.2 Conectándose a una red WIFI cifrada con WPA.

La configuración para este tipo de cifrado es la siguiente:

# Configuración en modo infraestructura con WPA

auto wlan0

iface wlan0 inet dhcp

wpa-ssid SSID_RED

wpa-psk CONTRASEÑA

Al igual que en el caso de WEP, solo es necesario modificar para establecer el SSID y la

contraseña de la red a la que se desea conectar.

8.2.1.3 Generando una red inalámbrica propia en modo “ad hoc”.

Para generar una red inalámbrica propia cifrada con WEP y conectarse a esta es necesario

configurar del modo siguiente:

# Configuración en modo ad hoc cifrando con WEP

auto wlan0

iface wlan0 inet static

wireless-mode ad-hoc

wireless-channel 1

wireless-essid SSID_RED

wireless-key s:CONTRASEÑA

address 192.168.50.100

netmask 255.255.255.0

En la configuración anterior se genera una red inalámbrica cifrada con WEP sobre el canal 1.

Además el interfaz inalámbrico se configura para que se conecte de forma estática a dicha red,

utilizando la dirección IP 192.168.50.100/24.



8.3 Instalación y configuración del driver de la webcam Creative Live! Cam Notebook.

Antes de nada se debe descargar la última versión del driver ov51x JPEG, esto se hace desde

su web: http://www.rastageeks.org/ov51x-jpeg/index.php/Main_Page.

El siguiente paso es asegurar que no se tiene instalado el módulo ov511, pues este se podría

iniciar primero y hacer que el driver deje de funcionar:

$ sudo rmmod ov511

Antes de continuar con la instalación es imprescindible asegurar que el sistema cuenta con

todo lo necesario para compilar código. Para instalar las herramientas de compilación se debe

ejecutar el siguiente comando:

$ apt-get install build-essential

Para instalar el driver se deben extraer los archivos, compilarlos e instalar el módulo, para

hacer esto se ejecutan los comandos siguientes:

$ tar -xzvf ov51x-jpeg-1.5.6.tar.gz

$ make

$ sudo make install

Ahora solo resta configurar el módulo para que se inicie automáticamente:

$ sudo modprobe ov51x-jpeg

Hecho lo anterior el driver ya se encuentra instalado y listo para funcionar.

8.4 Instalación de las librerías de procesamiento de imágenes OpenCV.

Para instalar las librerías OpenCV ejecutamos los comandos siguientes:

$ sudo apt-get install libpng12-dev

$ sudo apt-get install libcv-dev libcv1 libcvaux-dev libcvaux1 libhighgui-dev

libhighgui1

Hecho lo anterior ya se encuentran instaladas las librerías y listas para funcionar.

Diseño y desarrollo del software de control WHEX 1.


Capítulo

Diseño y desarrollo del software de control WHEX 1

9



9 Diseño y desarrollo del software de control del robot WHEX 1.

En este punto se cuenta con un prototipo totalmente funcional del robot hexápodo WHEX 1, por

tanto solo queda desarrollar el software de control responsable de generar los comandos que el

robot debe acatar.

La figura 9.1 muestra los componentes de la arquitectura del sistema que se tratan en el

presente capítulo.


9.1 Framework WHEX 1

Debido al carácter académico del proyecto y que el robot se ha concebido desde sus inicios

como plataforma hardware de apoyo al aprendizaje de la programación de robots móviles, el

software de control debe ser muy flexible a modificaciones futuras tanto de su lógica como de

los datos manipulados.

El software debe definirse desde un enfoque modular, pues así el estudiante puede reemplazar

los módulos que estime conveniente por otros que cumplan sus expectativas o que presenten

alguna mejora con respecto al original, o también agregar módulos que proporcionen nuevas

funcionalidades al robot y de esta forma ir modificando la programación del mismo.

Así mismo el software debe ser robusto ante las modificaciones que le sean realizadas: cada

módulo debe reaccionar correctamente ante errores generados por otros módulos.

Para cumplir los requisitos no funcionales anteriormente descritos y utilizando las técnicas de

diseño dirigido por pruebas se ha creado un framework de programación. Este framework debe

permitir acceder a los recursos de hardware y software del robot de forma fácil, por ejemplo,

ejecutando funciones o instanciando alguna clase.

La figura 9.2 muestra la arquitectura del framework diseñado.



Fig. 9.2: Arquitectura general del framework de programación de aplicaciones WHEX 1.

En la figura 9.2 se puede apreciar que el framework permite crear software totalmente modular,

toda la funcionalidad de procesamiento y entrada – salida se encuentra organizada en módulos

que se comunican a través de subscripciones a buzones de mensajes gestionados por el

sistema de comunicación interno. Los módulos son mantenidos por el gestor de módulos y

acceden a los servicios del hardware del robot mediante una interfaz hacia este.

En secciones siguientes se comenta el diseño de cada una de las partes de esta arquitectura.

9.1.1 Gestor de módulos.

El gestor de módulos tiene por responsabilidad la gestión del listado de módulos: añadiendo,

eliminando, activando y desactivando los módulos que sean necesarios para lograr la

configuración del software que se desee.

Los módulos son las unidades funcionales en las que se ha dividido el software de control del

robot WHEX 1, estos pueden ser de los siguientes tipos:

Módulo Procesador: Este tipo de módulo se utiliza como nodo de procesamiento en el

robot, analizando los mensajes que le llegan a través del sistema interno de

comunicación, tomando decisiones y generando respuestas que son inyectadas

también al sistema de comunicación.

Módulo E/S: Este tipo de módulo gestiona la entrada - salida con algún agente externo,

posibilitando por ejemplo la comunicación de un PC remoto con el robot a través de

Internet o la conexión de un mando a distancias.

Módulo Sniffer: Este tipo de módulo se ha definido para obtener información

secuencial desde algún medio externo e inyectarla al sistema de comunicación interno.

Cada clase de módulo debe tener una serie de servicios mínimos indispensables para su

integración en el software, específicamente en el sistema de comunicación interno y en el

gestor de eventos periódicos. Estos servicios mínimos se logran haciendo que el desarrollador



de un módulo herede de la clase abstracta correspondiente al tipo de módulo que desee

implementar y codifique los servicios que se necesiten para que la clase deje de ser abstracta.

Cada módulo debe implementar las siguientes funciones:

Módulo Procesador:

inicializar(): esta función es ejecutada por el gestor de módulos al crear la instancia del

módulo en cuestión.

onMensajeInterno(Modulo& remitente, MSG & msg): esta función es ejecutada por el

sistema de comunicación cada vez que llega un mensaje interno que debe ser

encaminado al módulo en cuestión. En esta función debe ser programada la

funcionalidad de procesamiento del módulo, en caso de existir.

onEventoPeriodico(int IdEvento): esta función se ejecuta de forma periódica si el

módulo se encuentra suscrito a algún evento periódico(en secciones siguientes se

amplía este concepto).

Módulo E/S (además de las funciones de Módulo Procesador):

abrirSocketExterno(): esta función debe abrir y retornar el socket que utilizará el

módulo de E/S para comunicarse con el agente externo al cual sirve de interfaz.

atenderSocketExterno(Int SocketExterno): esta función permite al módulo realizar una

operación personalizada cuando el socket está listo para ser leído.

onMensajeExterno(Int SocketRemitente, MSG & msg): esta función es ejecutada por el

sistema de comunicación cuando recibe datos desde el agente externo al cual el

módulo de E/S sirve de interfaz.

cerrarSocketExterno(): esta función debe cerrar de forma segura la comunicación con

el agente externo.

Módulo Sniffer (además de las funciones de Módulo Procesador):

inicializarFuente(): esta función debe inicializar, si es necesario, la fuente de datos

secuenciales de la cual el módulo sniffer leerá los datos.

leerDatos(): esta función es ejecutada por el sistema de comunicación de forma

periódica.

cerrarFuente(): esta función debe cerrar de forma segura la fuente de datos.

9.1.2 Sistema de comunicación interno del framework.

El sistema de comunicación interno permite que los módulos existentes se comuniquen entre sí

de forma eficiente y segura. La comunicación es síncrona: los mensajes son entregados a

todos los módulos que lo necesiten de forma inmediata. Un mensaje puede ser entregado a

más de un módulo, notificando la recepción al módulo emisor en todo caso.

La figura 9.3 muestra la estructura de buzones mantenida por el sistema de comunicación y las

subscripciones de los distintos módulos a estos.



Fig. 9.3: Estructura de buzones mantenida por el sistema de comunicación interna para realizar el encaminamiento de mensajes.

El sistema de comunicación mantiene una lista de buzones. Cada buzón corresponde a un tipo

de mensaje, identificado por un id. Los módulos se suscriben a los buzones de los cuales

deseen recibir mensajes y el gestor de buzones (ver figura 9.3) encamina el mensaje hacia

todos los módulos que se encuentren suscritos al buzón correspondiente.

El siguiente algoritmo es empleado por el gestor de buzones para encaminar cada mensaje

hacia los módulos destino:

EncaminarMensaje(Modulo Remitente, Int IdBuzon, Mensaje M)

Asignar Buzon = ObtenerBuzon(IdBuzon). Asignar Suscripciones = ObtenerSuscripciones(Buzon). Para cada Modulo Mod en Suscripciones, repetir:

Ejecutar Mod.OnMensajeInterno(Remitente, M). Fin repetir

Fin

De este modo, el sistema de comunicación provee un medio de transporte flexible para que

todos los módulos se comuniquen entre sí.

Este mecanismo de comunicación es muy útil cuando los módulos no conocen el destino de los

mensajes. Por ejemplo, un módulo que gestione el sensor de distancias por ultrasonidos no

necesita saber que módulos utilizarán posteriormente los datos de distancias leídos,

simplemente se limita a leer los datos provenientes del sensor de distancias e inyectarlos en el

sistema de comunicación.

Los módulos también pueden enviarse mensajes directamente unos a otros siempre y cuando

conozcan los módulos de destino. Esta forma de comunicación punto a punto es útil por

ejemplo para enviar respuestas hacia el remitente de una petición.

Existen dos tipos de mensajes internos: los mensajes de texto y los mensajes de objetos.



La estructura de los mensajes de texto es la siguiente:

Id de mensaje: entero que identifica el tipo de mensaje y el buzón al cual va

encaminado El id = 0 se reserva para los mensajes entregados directamente al módulo

destino, por ejemplo los mensajes de respuestas.

Id de operación: entero que identifica la operación a la que pertenece el mensaje, todos

los mensajes de una operación determinada tienen el mismo id de operación.

Param1, Param2 y Param3: Tres valores de punto flotante de propósito general para

almacenar parámetros específicos de cada tipo de mensaje.

Texto: Texto del mensaje.

Mientras que la estructura de los mensajes de objetos es la siguiente:

Id de mensaje: idéntico al id de los mensajes de texto.

Id de operación: idéntico al id de operación de los mensajes de texto.

Objeto: Objeto que contiene los datos transportados por el mensaje.

9.1.3 Gestor de eventos periódicos.

Un robot, además de poderse comandar de forma remota, debe ser capaz de tomar decisiones

propias con cierta autonomía. Por este motivo surge la necesidad de poder ejecutar

procedimientos sin que estos sean desencadenados por eventos de entrada / salida. Para

poder realizar esta tarea el framework WHEX 1 utiliza el gestor de eventos periódicos.

El gestor permite que los módulos se suscriban a eventos internos generados de forma

periódica. Los módulos, para suscribirse a un evento, solamente necesitan especificar el

periodo de tiempo entre notificaciones que necesiten.

Al inicializarse el gestor y antes de que ningún módulo se suscriba, se configura un

temporizador de tiempo real en el núcleo del sistema operativo. Este temporizador es

configurado para que genere una señal SIGALRM de forma periódica. El período de estas

señales es preestablecido y constituye la base de tiempos del gestor de eventos periódicos.

Al ocurrir una señal SIGALRM el gestor de eventos periódicos determina que eventos deben

ser notificados. Para esto cada evento mantiene un contador que es disminuido en uno por el

gestor cada vez que se recibe una señal. Cuando el contador llega a cero, se notifica la

ocurrencia del evento al módulo correspondiente.

9.1.4 Interfaz con el hardware del robot.

La interfaz con el hardware del robot es el medio mediante el cual el resto del software, que se

encuentra dividido en módulos, se comunica con los recursos hardware del robot. Está formada

por dos clases principales:

Driver de la placa controladora WHEX 1: esta clase incluye todas las funciones

necesarias para acceder a los servicios de la placa controladora a través de los

comandos mostrados en la tabla del anexo A. para utilizarla solo es necesario

referenciar la clase y ejecutar alguna de sus funciones.

Driver de la cámara: esta clase se utiliza para acceder a la cámara del robot.

El driver de la placa controladora implementa los siguientes servicios.

Envío de comandos en modo RAW a la placa.

Gestión de los parámetros de la postura del robot.



Gestión de comportamiento del robot (caminar, rotar, detenerse, dormir, etc).

Gestión del sensor de distancias por ultrasonidos.

El driver de la cámara del robot permite:

Inicializar la cámara.

Leer las imágenes desde la cámara.

9.1.5 Unidad modular y de comunicación.

Al desarrollar aplicaciones utilizando el framework diseñado para el robot WHEX 1 no es

necesario definir ningún método principal; en vez de esto, es necesario definir una unidad

modular y de comunicación.

La unidad modular y de comunicación tiene cuatro funciones principales:

Declarar e inicializar los módulos que serán utilizados.

Definir la estructura de buzones del sistema de comunicación interno.

Establecer las suscripciones de cada módulo a los buzones que sean necesarios.

Configurar el gestor de eventos periódicos.

La unidad modular y de comunicación debe definirse en un fichero de código de C++. A

continuación se presenta un ejemplo:

// Sección de declaraciones #include "WHEX.h" #include "Modulo1.h‛ #include "Modulo2.h‛ #include "Modulo3.h‛ // Unidad modular WHEX_MODULOS(UnidadModularEjemplo) INSTANCIA_MODULO(1,Modulo1(1)) INSTANCIA_MODULO(2,Modulo2(2)) INSTANCIA_MODULO(3,Modulo3(3)) WHEX_FIN_MODULOS // Unidad de comunicaciones WHEX_UNIDAD_COMUNICACION(UnidadComunicacionEjemplo) WHEX_BUZONES WHEX_BUZON(1,Mensajes de estado) WHEX_BUZON(2,Mensajes de comandos) WHEX_FIN_BUZONES WHEX_SUSCRIPCIONES WHEX_SUSCRIPCION_BUZON(1,1) WHEX_SUSCRIPCION_BUZON(1,2) WHEX_SUSCRIPCION_BUZON(2,1) WHEX_SUSCRIPCION_BUZON(3,2) WHEX_FIN_SUSCRIPCIONES WHEX_EVENTOS_PERIODICOS(100000,100000) WHEX_SUSCRIPCION_EVENTO(1,3,500000) WHEX_ACTIVAR_EVENTO(1,3) WHEX_FIN_EVENTOS_PERIODICOS WHEX_FIN_UNIDAD_COMUNICACION



Como se puede apreciar en el ejemplo anterior, la definición de la unidad modular y de

comunicación tiene tres secciones principales: la sección de declaraciones, la unidad modular y

la unidad de comunicaciones.

En la sección de declaraciones deben añadirse los encabezamientos de todos los módulos que

se han codificado y que serán utilizados por la unidad modular y de comunicación. La unidad

modular define e inicializa los módulos que se utilizarán. Esta inicialización se realiza

estableciendo el identificador de cada módulo e invocando su constructor. Por último la unidad

de comunicación define los buzones de mensajes, establece las suscripciones de los módulos

a estos buzones y configura al gestor de eventos periódicos.

Entonces, un programa desarrollado utilizando esta arquitectura incluye una serie de módulos

que contienen toda la funcionalidad de la aplicación y una unidad modular y de comunicación

que define la interacción entre dichos módulos.

Para definir la unidad modular y de comunicación el framework WHEX 1 provee las siguientes

macros:

WHEX_MODULOS(Nombre): definición del nombre de la unidad modular que se desea

declarar. El nombre debe ser una cadena alfanumérica válida. Es necesario mencionar que

esta cadena no debe encerrarse entre comillas.

INSTANCIA_MODULO(IdModulo,ConstructorModulo): instanciación de un módulo.

WHEX_FIN_MODULOS: establece el final de la unidad modular.

WHEX_UNIDAD_COMUNICACION(Nombre): define el nombre de la unidad de comunicación

que se utilizará. Esta cadena no debe encerrarse entre comillas.

WHEX_BUZONES: comienzo de la definición de buzones.

WHEX_BUZON(Id,Nombre): declaración de un buzón. Esta macro provee el identificador y una

descripción de los mensajes que serán enviados al buzón que se está definiendo.

WHEX_FIN_BUZONES: establece el final de la sección de definición de buzones.

WHEX_SUSCRIPCIONES: inicio de la sección de suscripciones.

WHEX_SUSCRIPCION_BUZON(IdBuzon,IdModulo): crea una suscripción de un módulo a un

buzón.

WHEX_FIN_SUSCRIPCIONES: establece el fin de la sección de suscripciones.

WHEX_EVENTOS_PERIODICOS(Inicio, Período): esta macro define los parámetros de la base

de tiempos del gestor de eventos periódicos. El tiempo de inicio es el tiempo hasta la

ocurrencia de la primera señal SIGALRM y el período es el tiempo entre señales.

WHEX_SUSCRIPCION_EVENTO(IdEvento, IdModulo, PeriodoEvento): suscripción de un

módulo a un evento, estableciendo el período del mismo.



WHEX_ACTIVAR_EVENTO(IdEvento, IdModulo): esta macro activa el evento determinado por

los identificadores. El evento se tuvo que haber suscrito con anterioridad.

WHEX_FIN_EVENTOS_PERIODICOS: señala el fin de la configuración del gestor de eventos

periódicos.

WHEX_FIN_UNIDAD_COMUNICACION: establece el fin de la unidad de comunicación que se

ha declarado.

9.2 Software de control creado para el robot WHEX 1.

Utilizando como herramienta de diseño principal el framework explicado en secciones

anteriores se ha creado un conjunto de programas que constituyen el software de control del

robot WHEX 1. Estos programas implementan los comportamientos que se incluyen de serie

con el robot:

Control del robot desde un ordenador remoto a través de internet.

Posibilidad de adoptar posturas complejas.

Posibilidad de controlar el comportamiento del robot de forma remota, soportando las

funcionalidades de caminar, rotar, detenerse, ponerse en pie y dormir.

Control de la distancia a la que se encuentran los obstáculos cuando el robot camina

hacia adelante para impedir que este choque.

Detección de rostros en el campo visual del robot y seguimiento de los mismos.

Notificación del estado del robot mediante señales acústicas y voz hablada en idioma

español.

El esquema de la figura 9.4 muestra la arquitectura general del software de control del robot

WHEX 1. El núcleo de este sistema está formado por un conjunto de módulos que se

comunican a través del mecanismo de comunicación interno que provee el framework.

Fig. 9.4: Arquitectura del software controlador WHEX 1.



En el diagrama de la figura 9.4 pueden apreciarse también los cuatro procesos que conforman

el sistema:

Proceso principal del software: cuyo núcleo es el mecanismo de comunicación interno

del framework WHEX 1. Este proceso incluye toda la funcionalidad del software,

distribuida en un conjunto de módulos.

Proceso driver de la placa controladora WHEX 1: este proceso constituye la interfaz de

comunicación del software con el hardware de la placa controladora. Como se observa

en la figura 9.4, este proceso se comunica con la tarjeta controladora mediante el

protocolo RS232 y con el proceso principal mediante una tubería FIFO gestionada por

un módulo de entrada – salida.

Proceso detector de rostros: este proceso incluye toda la funcionalidad de detección de

rostros, utiliza para ello las librerías de visión artificial OpenCV.

Proceso cliente WHEX 1: este proceso actúa como cliente del robot. Permite enviar

comandos al robot para que sean ejecutados. La comunicación de este proceso con el

proceso principal es del tipo cliente – servidor, utilizando los protocolos TCP/IP; en esta

comunicación el servidor está implementado mediante un módulo de entrada – salida

en el proceso principal.

En el diagrama de la figura 9.4 es fácil deducir la ruta que siguen los datos. Como ejemplo

tomar el caso en el cual un ordenador remoto ordena al robot que comience a caminar,

enviando el vector de dirección y el grado de giro:

El proceso cliente genera y envía al proceso principal del software un mensaje con el

comando “comenzar a caminar”, que incluye como datos el vector de dirección de

movimiento y el grado de giro.

El comando llega al módulo E/S que gestiona las conexiones TCP/IP, este módulo

genera un mensaje interno que es encaminado al módulo procesador de movimiento.

El módulo procesador de movimiento recibe el mensaje y lo procesa, extrayendo los

comandos necesarios para hacer efectiva la orden.

Los comandos son enviados secuencialmente al módulo E/S que gestiona el driver de

la tarjeta controladora WHEX 1, el cual los envía al proceso driver WHEX 1.

El proceso driver WHEX 1 se comunica con el hardware a través de su interfaz serie y

el robot comienza a caminar.

En las secciones siguientes se describen los diferentes procesos que conforman el software

controlador WHEX 1.

9.2.1 Proceso driver de la placa controladora WHEX 1.

El proceso driver tiene como principal función permitir que el software de control interactúe con

el firmware presente en la placa controladora.

Como se ha visto en la sección anterior, este proceso se comunica con el hardware mediante

una interfaz serie sobre la cual actúa el protocolo RS232 y con el proceso principal del software

WHEX 1 a través de una tubería FIFO (ver figura 9.4).

El diagrama de flujo de la figura 9.5 representa el algoritmo de este proceso.



Fig. 9.5: Diagrama de flujo que representa el algoritmo del proceso driver.

Primeramente se inicializan los datos y recursos que utilizará el proceso. Esta inicialización se

compone de las siguientes tareas (ver figura 9.5):

1. Primeramente se inicializan los datos que manejará el proceso, leyendo de un fichero

de configuración principal (llamado driver.conf). La tabla 9.1 muestra las entradas de

este fichero y sus descripciones.

2. A continuación se carga un fichero de comandos que tiene como función principal

asignar a cada comando admitido por la placa controladora (valor numérico de 8 bits),

un nombre (cadena de texto alfanumérico). Esto se hace para permitir que los

comandos se identifiquen mediante un nombre de alto nivel, independiente del

hardware y que pueda ser cambiado en el futuro. La tabla 9.2 muestra las entradas de

este fichero.

3. El último paso de la inicialización es la apertura del puerto serie y las tuberías de

comunicación con el proceso principal.



Identificador de la entrada Descripción

driver_com_port_path Ruta en el sistema de ficheros del dispositivo puerto serie a utilizar.

driver_commands Ruta del fichero de comandos admitidos por la placa controladora.

driver_commands_fifo Ruta en el sistema de ficheros de la FIFO por donde se recibirán los comandos del driver.

driver_responses_fifo Ruta en el sistema de ficheros de la FIFO que se utilizará para emitir las respuestas.

driver_binary_path Ruta del fichero binario del driver.

Tabla 9.1: Entradas del fichero de configuración del proceso driver.

Si no se encuentra ningún error en la inicialización, el proceso entra en un bucle de atención a

la entrada / salida. En este bucle se realiza una multiplexación síncrona de la entrada /salida,

atendiendo los eventos que puedan ocurrir sobre el puerto serie y las FIFOs de forma

simultánea. En este bucle:

Si se detecta la llegada de un mensaje a través de las FIFOs de comunicación con el

proceso principal entonces se extraen todos los comandos que el mensaje transporta,

se verifica la validez de la sintaxis de los mismos y se envían a la placa controladora

mediante el puerto serie.

Si se detecta la llegada de un mensaje a través del puerto serie se procede a adaptar

la información recibida y a enviarla hacia el proceso principal mediante las FIFOs de

comunicación.

Si se detecta una señal SIGINT o SIGTERM se cierran las tuberías y el puerto serie,

finalizando la ejecución del programa.

Nombre del comando Valor numérico Nombre del comando Valor numérico

get_version 0 set_body_slope_trans 18

enable_all_servos 1 adopt_stand 19

disable_all_servos 2 go_sleep 20

refresh_all_servos 3 go_walk 21

set_stand_neutral_values 4 go_turn 22

go_stop 5 set_walk_dir_x 23

change_servo_controller_state 6 set_walk_dir_y 24

enable_servo 7 set_turn_dir 25

disable_servo 8 set_walking_turn_grade 26

set_speed 9 get_stand_values 27

set_position 10 adopt_stand_steps 28

refresh_servo 11 set_head_x 29

set_body_height 12 set_head_y 30

set_legs_openness 13 adopt_head_stand 31

set_body_twist 14 change_head_x 32

set_body_center_x 15 change_head_y 33

set_body_center_y 16 get_head_pos 34

set_body_slope_long 17

Tabla 9.2: Entradas del fichero de nombres de comandos.

9.2.2 Proceso detector de rostros.

Este proceso tiene como principal función la detección de rostros humanos haciendo uso del

sensor de visión del robot WHEX 1.

Como se ha mencionado en secciones anteriores de este trabajo, WHEX 1 utiliza una cámara

web Creative Live! a modo de sensor óptico. El proceso detector de rostros utiliza esta cámara

para realizar su labor.



En el capítulo “Estado de la cuestión” se menciona un algoritmo clasificador basado en

características tipo haar. Este algoritmo se encuentra implementado en las librerías de

percepción computacional OpenCV. El proceso detector de rostros emplea esta

implementación del algoritmo para clasificar las imágenes provenientes de la cámara y

determinar si en ellas se encuentra un rostro. En caso positivo, se determinan las coordenadas

donde se encuentra el rostro y se envían al proceso principal, que se encuentra conectado

mediante tuberías FIFOs. Las librerías OpenCV se utilizan además como medio de acceso al

hardware de la cámara.

9.2.2.1 Proceso de entrenamiento del clasificador de OpenCV.

El proceso de entrenamiento del clasificador de OpenCV conlleva la realización de tres tareas:

Adquisición de las imágenes.

Creación de muestras.

Entrenamiento del clasificador.

La adquisición de las imágenes es la primera de las tareas a realizar. Según la documentación

distribuida junto a las librerías OpenCV, para un entrenamiento óptimo se necesitan como

mínimo unas 6500 imágenes, las cuales se dividen en dos grupos:

Imágenes negativas: son imágenes en las cuales no aparece el objeto que queremos

detectar con el clasificador, es decir, imágenes de fondo. De estas imágenes se

necesitan como mínimo unas 5000.

Imágenes positivas: son imágenes en las que aparece el objeto que deseamos

detectar, en este caso, vistas frontales de rostros de personas. De estas imágenes se

necesitan al menos 1500.

Un método perfectamente válido para obtener el número mínimo de imágenes positivas y

negativas a partir de un grupo reducido de estas es generar varias imágenes a partir de cada

una mediante la aplicación de transformaciones, como por ejemplo escalado, rotación,

modificación de la exposición, cambio de saturación de uno o varios canales y aplicación de

filtros monocromáticos, entre otras.

En este trabajo se han utilizado, como imágenes negativas, cerca de 200 fondos de escritorio

de distintas resoluciones. Esta cantidad de imágenes ha sido multiplicada aplicando las

transformaciones anteriormente mencionadas. Las imágenes negativas deben indexarse en un

fichero de texto en el cual cada línea contiene la ruta hacia una imagen:

negativas/imagen1.jpg

negativas/imagen2.jpg

…

negativas/imagenN.jpg

Como imágenes positivas se ha utilizado la base de datos de rostros FERET34

, publicada por el

NIST (National Institute of Standards and Technology) para uso en investigaciones. De esta

base de datos se han tomado 500 imágenes, las cuales han sido escaladas a un tamaño de 50

x 50 píxeles. Para obtener las 1500 imágenes positivas a partir de las 500 existentes se ha

hecho variar la exposición y la saturación, creando a partir de cada imagen, dos más. Estas

34

Link de descarga previo registro: http://face.nist.gov/colorferet/request.html



imágenes también necesitan de un fichero índice que además de listarlas, brinde información

de coordenadas donde se encuentra el objeto que queremos detectar. El fichero índice de

imágenes positivas tiene la siguiente estructura:

positivas/imagen1.jpg X Y Ancho Alto

positivas/imagen2.jpg X Y Ancho Alto

…

positivas/imagenN.jpg X Y Ancho Alto

En el fichero anterior se puede observar que las rutas de las imágenes van acompañadas de

cuatro valores numéricos: X e Y de las coordenadas del objeto que deseamos detectar y las

dimensiones (Ancho y Alto) de dicho objeto. Estas medidas son relativas al sistema de

coordenadas de la imagen, con origen en la esquina superior izquierda y la unidad de medida

es el píxel. Dado el caso de que las imágenes positivas que se han utilizado solamente

contienen el rostro de una persona y que estas han sido escaladas con anterioridad a 50 x 50

píxeles, los valores numéricos que se han empleado en este fichero, para todas las imágenes

positivas son: 0 0 50 50.

El siguiente paso es la creación de las muestras, para esto se utiliza una herramienta

proporcionada por OpenCV: opencv-createsamples. El siguiente listado muestra un uso típico

de esta herramienta:

$ opencv-createsamples -info indice-positivas.txt -vec muestra.vec

-num 1500 -w 20 -h 20

donde:

-info: especifica la ruta del fichero con el índice de las imágenes positivas.

-vec: especifica el nombre del fichero de salida con las muestras generadas.

-num: establece la cantidad de imágenes positivas que contiene el índice.

-w: especifica el ancho en píxeles de las muestras que se generarán.

-h: especifica el alto en píxeles de las muestras que se generarán.

Una vez generadas las muestras, solo queda realizar el entrenamiento del clasificador. En este

entrenamiento se obtiene como resultado un fichero XML que contiene el clasificador.

Para el entrenamiento se utiliza otra utilidad facilitada por OpenCV: opencv-haartraining. Esta

utilidad necesita dos entradas: el fichero índice de imágenes negativas y el fichero de muestras

generado en el paso anterior. El siguiente listado muestra el modo de empleo típico de esta

utilidad:

$ opencv-haartraining -data cascade -vec muestra.vec

-bg indice-negativas.txt -nstages 30 -nsplit 2 -minhitrate 0.999

-maxfalsealarm 0.5 -npos 1500 -nneg 5000 -w 20 -h 20 -mem 1300

-mode ALL

donde:

-data: provee el directorio de salida donde se almacenará el fichero XML resultante.

-vec: proporciona el archivo de muestras generado en la etapa anterior.



-bg: establece el archivo índice de imágenes negativas a utilizar.

-nstages: numero de etapas de entrenamiento.

-nsplit: valor que determina la cantidad de clasificadores en cascada a utilizar.

-minhitrate: umbral de aceptación de cada etapa.

-maxfalsealarm: umbral de falsas alarmas admitidas en cada etapa.

-npos: numero de muestras de imágenes positivas.

-nneg: numero de imágenes negativas indexadas.

-w: ancho de las muestras.

-h: alto de las muestras.

-mem: máxima capacidad de memoria a utilizar en el proceso.

-mode: determina que características haar se utilizarán en el clasificador.

Una vez terminada la ejecución del entrenamiento se cuenta con un fichero XML que define el

clasificador.

9.2.2.2 Algoritmo del proceso detector de rostros.

Una vez entrenado el clasificador solamente resta codificar un programa que lo utilice. El

programa debe detectar los rostros a través de la cámara y enviar sus coordenadas al proceso

principal a través de FIFOs. En caso de que no se detecte ningún rostro, el programa debe

enviar un mensaje notificando el hecho. La figura 9.6 muestra el algoritmo de este programa.

El algoritmo de la figura 9.6 se divide en tres etapas principales:

1. Inicialización.

2. Atención a la entrada / salida.

3. Ejecución del clasificador.

Primeramente se inicializan los datos y recursos que utilizará el proceso. Esta inicialización se

compone de las siguientes tareas (ver figura 9.6):

Cargar el fichero de configuración visión.conf y establecer los valores iniciales de las

variables globales según este fichero.

Cargar el listado de detectores de objetos desde un fichero. Este listado incluye las

rutas de los ficheros XML de los detectores que se utilizarán. En estos momentos

solamente se utiliza el detector de rostros descrito en secciones anteriores; pero el

software se ha desarrollado de forma que sea muy sencillo agregar más detectores

(solamente es necesario añadirlo a este fichero).

Inicializar la cámara, estableciendo el formato de imagen, su resolución, etc.

Abrir las tuberías de comunicación con el proceso principal.

Si la inicialización ha concluido con éxito el proceso entra en un bucle hasta que se detecte una

señal SIGINT o SIGTERM. En este bucle se realizan dos tareas de forma secuencial:

Atender a eventos de lectura en las FIFOs de comunicación con el proceso principal. Si

se detecta la llegada de un mensaje por esta vía, se extrae le comando y se ejecuta.

Ejecución del clasificador. Si después de ejecutado el clasificador sobre la imagen de la

cámara se ha detectado algún rostro, se procede a extraer las coordenadas de dicho

rostro, adaptarlas correctamente y enviarlas al proceso principal a través de las FIFOs.

Si por el contrario no se ha detectado ningún rostro, se notifica este hecho mediante la

misma vía.



Fig. 9.6: Diagrama de flujo que representa el algoritmo del proceso detector de rostros.

Las coordenadas de rostros detectados y demás notificaciones generadas por este proceso

constituyen la entrada al módulo seguidor de rostros que será explicado en secciones

siguientes.

9.2.3 Proceso principal del software WHEX 1.

El proceso principal del software WHEX 1 se ha diseñado utilizando el framework modular

desarrollado exclusivamente para el robot WHEX 1.

Como se puede observar en la figura 9.4 se han desarrollado, utilizando las herramientas

facilitadas por el framework WHEX 1, un conjunto de módulos. La tabla 9.3 muestra una

descripción de cada uno de estos módulos.



ID Tipo Nombre Descripción

1 E/S TCP/IP Gestión de conexiones TCP/IP mediante las cuales se puede controlar el robot a través de internet.

2 E/S Driver WHEX 1 Interfaz con el hardware del robot WHEX 1.

3 E/S Visión de rostros

Funcionalidad de detección de rostros utilizando la cámara del robot.

4 Procesador Seguidor de rostros.

Generación de comandos de movimientos para realizar el seguimiento de un rostro mediante la cámara.

5 Procesador Sensor de distancias

Gestión del sensor de distancias por ultrasonidos.

6 Procesador Movimiento Gestión de las órdenes relacionadas con la postura y los movimientos del robot.

7 Procesador Generador de Voz

Generación de notificaciones acústicas y mensajes hablados en idioma español.

Tabla 9.3: Módulos creados e incluidos de serie en el software controlador WHEX 1.

Como se ha visto anteriormente, los módulos se comunican mediante el paso de mensajes

utilizando para ello una estructura de buzones a los cuales se suscriben. La tabla 9.4 muestra

los buzones definidos y las suscripciones que se han realizado para lograr la configuración del

software planteada en la figura 9.4.

Id Descripción Módulos suscritos

1 Mensajes destinados a ser transmitidos al ordenador remoto a través de la conexión TCP/IP

E/S TCP/IP

2 Mensajes que contienen comandos que se deben enviar al driver de la tarjeta controladora WHEX 1.

E/S Driver WHEX 1

3 Mensajes que contienen comandos de activación y desactivación de la detección de rostros.

E/S Visión de rostros

4 Mensajes que contienen coordenadas de rostros detectados. Proc Seguidor de rostros.

5 Mensajes de control y órdenes para el sensor de distancias por ultrasonidos.

Proc Sensor distancias

6 Mensajes que contienen los datos y comandos para controlar el comportamiento del robot y su postura, por ejemplo ordenes de caminar, rotar, detenerse o dormir, entre otras.

Proc Movimiento

7 Mensajes que contienen frases en el idioma español destinadas a ser sintetizadas, generando mensajes hablados.

Proc Voz

Tabla 9.4: Buzones de mensajes que se han definido y los módulos suscritos a cada uno.

El diagrama de la figura 9.7 muestra una vista lógica de los mecanismos de comunicación que

se han configurado en el software de control.



Fig. 9.7: Mecanismo de comunicación configurado en el software de control WHEX 1.

9.2.3.1 Breve descripción de los módulos desarrollados.

Como ya se ha visto en secciones anteriores de este capítulo, se han desarrollado siete

módulos, de los cuales, tres son módulos de entrada - salida y 4 son procesadores. A

continuación se describirán cada uno de estos módulos.

Módulo E/S TCP/IP.

En este módulo se ha implementado un servidor TCP/IP multiusuario síncrono que acepta

conexiones entrantes a través de la interfaz de red inalámbrica del robot.

Para la comunicación se ha diseñado un protocolo cliente – servidor sencillo, cuyos mensajes

tienen la misma estructura que los mensajes de texto del sistema de comunicación interno del

framework WHEX 1.

Los usuarios, para conectarse, necesitan disponer de un nombre de usuario y una contraseña.

Las contraseñas no se almacenan en texto plano, en su lugar se almacenan sus resúmenes



SHA1 en un fichero llamado “tcpip_passwd”. Para generar estos resúmenes se ha codificado la

utilidad “sha1passwords”, incluida en el software del robot.

Los usuarios pueden ser de dos tipos: administradores y usuarios básicos. A pesar de que esto

no se utiliza aún, esta característica se ha incluido para uso futuro.

El siguiente listado muestra un ejemplo del fichero “tcpip_passwd”:

Pedro#admin#********************

Juan#admin#********************

Ana#user#********************

Módulo E/S Driver.

Este módulo es muy sencillo, su única función es servir de “puente” entre el resto de módulos y

el proceso driver de la placa controladora.

Este módulo, al inicializarse, abre dos tuberías de tipo FIFO: una para los comandos enviados

al driver y otra para las respuestas. A continuación y mediante la llamada al sistema “fork”, crea

un nuevo proceso hijo y ejecuta al driver de la placa.

Módulo E/S Visión de rostros.

Al igual que el módulo driver, este módulo tiene como única función servir de enlace, en este

caso con el proceso detector de rostros, obteniendo las coordenadas de los rostros detectados

y enviándolas al módulo seguidor de rostros.

Módulo seguidor de rostros.

El módulo seguidor de rostros tiene como función realizar el seguimiento de un rostro detectado

mediante la cámara del robot.

En todo momento se trata de mantener el rostro centrado en el campo de visión, ordenando

mover la cabeza del robot y si es necesario iniciando un movimiento de rotación del cuerpo.

El módulo está implementado mediante una maquina de Mealy de cuatro estados. El diagrama

de la figura 9.8 muestra este autómata.

Antes de continuar con la explicación del autómata es necesario mencionar que un rostro

detectado se considera centrado en el campo de visión de la cámara si el valor absoluto de su

coordenada x es menor que 30 píxeles.



Fig. 9.8: Máquina de Mealy que implementa el módulo seguidor de rostros. En este diagrama:

vx: coordenadas de un rostro detectado por la cámara, pudiendo estar centrado o no en el campo de visión.

vc: coordenadas de un rostro detectado por la cámara aproximadamente en el centro del campo de visión.

vd: coordenadas de un rostro detectado por la cámara en la periferia del campo de visión.

f: notificación de que no se ha detectado ningún rostro.

A, B, C, D, E y F: Acciones ejecutadas por el autómata en cada transición.

Como puede observarse en la figura 9.8, el autómata tiene como entradas las coordenadas de

los rostros detectados (en la figura: vx, vc y vd). También es una entrada válida al autómata la

notificación de que no se ha detectado rostro alguno (en la figura: f). El estado inicial es el cero,

y con cada transición se ejecutan las siguientes acciones (ver figura 9.8):

A) Mover la cabeza del robot a su posición de origen (en posición horizontal y mirando al

frente).

B) Mover la cabeza del robot en dirección al rostro detectado.

C) Iniciar movimiento de rotación del cuerpo en la dirección del rostro detectado.

Mover la cabeza del robot en dirección al rostro detectado.

D) Detener la rotación del cuerpo del robot.

Mover la cabeza del robot en dirección al rostro detectado.

E) Calcular las coordenadas del punto donde es más probable que se encuentre el rostro

que se estaba siguiendo (y que se ha perdido).

Mover la cabeza del robot hacia las coordenadas calculadas.

F) Detener la rotación del cuerpo del robot.

Calcular las coordenadas del punto donde es más probable que se encuentre el rostro

que se estaba siguiendo (y que se ha perdido).

Mover la cabeza del robot hacia las coordenadas calculadas.



El siguiente algoritmo se corresponde con el autómata de la figura 9.8 y es ejecutado por el

módulo cada vez que se recibe un mensaje proveniente del proceso detector de rostros, ya

sean las coordenadas de un rostro o la notificación de que no se ha detectado ninguno:

Función: onMensajeInterno(Modulo Remitente, Mensaje M)

Si Estado == 0

Si EsCoordenadaRostro(M) Asignar P = CalcularVectorDesplazamientoP(). Ejecutar EnviarMensajeInterno(‚set_head_x=M.Param1

set_head_y=M.param2 adopt_head_stand=10‛). Asignar Estado = 1.

Fin Si

Sino Si Estado == 1 Si EsCoordenadaRostro(M)

Asignar P = CalcularVectorDesplazamientoP(). Si M.Param1 > 30 || M.Param1 < -30

Asignar Dir = ‚left‛. Si M.Param1 > 0

Asignar Dir = ‚right‛. Fin Si Ejecutar EnviarMensajeInterno(‚set_turn_dir=Dir go_turn=1‛). Asignar Estado = 2.

Fin Si Ejecutar EnviarMensajeInterno(‚set_head_x=M.Param1

set_head_y=M.param2 adopt_head_stand=10‛). Sino

Ejecutar EnviarMensajeInterno(‚set_head_x=P.X set_head_y=P.Y adopt_head_stand=10‛).

Asignar Estado = 3. Fin Si

Sino Si Estado == 2 Si EsCoordenadaRostro(M)

Asignar P = CalcularVectorDesplazamientoP(). Si M.Param1 > 30 || M.Param1 < -30

Asignar Dir = ‚left‛. Si M.Param1 > 0

Asignar Dir = ‚right‛. Fin Si Ejecutar EnviarMensajeInterno(‚set_turn_dir=Dir go_turn=1‛).

Sino Ejecutar EnviarMensajeInterno(‚go_stop‛). Asignar Estado = 1.

Fin Si Ejecutar EnviarMensajeInterno(‚set_head_x=M.Param1

set_head_y=M.param2 adopt_head_stand=10‛). Sino

Ejecutar EnviarMensajeInterno(‚go_stop‛). Ejecutar EnviarMensajeInterno(‚set_head_x=P.X set_head_y=P.Y

adopt_head_stand=10‛). Asignar Estado = 3.

Fin Si



Sino Si Estado == 3

Si EsCoordenadaRostro(M) Asignar P = CalcularVectorDesplazamientoP(). Ejecutar EnviarMensajeInterno(‚set_head_x=M.Param1

set_head_y=M.param2 adopt_head_stand=10‛). Asignar Estado = 1.

Sino Ejecutar EnviarMensajeInterno(‚set_head_x=0 set_head_y=0

adopt_head_stand=10‛). Asignar Estado = 0.

Fin Si

Fin Si

Fin función

Módulo de movimientos.

Este módulo se ha codificado para disminuir el acoplamiento existente entre los módulos de

entrada / salida que manejan las conexiones TCP/IP y el driver de la placa controladora

respectivamente. La única función del módulo de movimientos (por ahora) es servir de puente

entre estos dos módulos de entrada - salida.

Módulo sensor de distancias.

El módulo sensor de distancias se encarga de realizar mediciones de la distancia existente

hasta objetos próximos en el frente del robot. Para esto se utiliza el sensor de distancias por

ultrasonidos SRF08 instalado en la cabeza del robot.

Este módulo realiza mediciones de la distancia cada medio segundo y solamente cuando el

robot camina hacia adelante. Las lecturas obtenidas se analizan para determinar si hay peligro

de colisión con algún obstáculo (distancia menor que 35 cm), en este caso, se ordena al robot

que se detenga.

Para poder realizar las mediciones cada medio segundo, este módulo se suscribe a un evento

periódico gestionado, como ya se ha visto, por el gestor de eventos periódicos del framework

WHEX 1.

Módulo generador de sonidos y voz.

Para mejorar la experiencia de usuario, al robot se le ha dado la capacidad de notificar eventos

mediante la reproducción de sonidos y la generación de mensajes hablados en idioma español.

Este módulo recibe dos tipos de mensajes:

Mensajes con la palabra “ok”: indican que se desea reproducir aleatoriamente uno de

los 9 sonidos preestablecidos para este fin. De esta forma el usuario puede percibir

acústicamente que ha ocurrido un evento, aunque no podrá saber cual.

Mensajes con cualquier frase en el idioma español: al recibir estos mensajes, el

módulo procederá a sintetizar audio con la frase en cuestión, de esta forma el usuario

podrá saber exactamente que evento ha ocurrido.



Para la reproducción de los sonidos de notificación se utiliza el reproductor de código abierto

mpg32135

mientras que para la síntesis de la voz en idioma español se utiliza el software

sintetizador festival36

, también de uso público.

9.2.3.2 Unidad modular y de comunicación.

La unidad modular y de comunicación que se ha definido es la siguiente:

// Sección de declaraciones #include "../WHEX/WHEX.h" #include "src/Modulos/ModuloTCPIP.h" #include "src/Modulos/ModuloDriver.h" #include "src/Modulos/ModuloVisionRostros.h" #include "src/Modulos/ModuloSeguidorRostros.h" #include "src/Modulos/ModuloSensorDistancias.h" #include "src/Modulos/ModuloMovimiento.h" #include "src/Modulos/ModuloVoz.h" WHEX_MODULOS(WHEX_MODS) INSTANCIA_MODULO(1,ModuloTCPIP(1)) INSTANCIA_MODULO(2,ModuloDriver(2)) INSTANCIA_MODULO(3,ModuloVisionRostros(3)) INSTANCIA_MODULO(4,ModuloSeguidorRostros(4)) INSTANCIA_MODULO(5,ModuloSensorDistancias(5)) INSTANCIA_MODULO(6,ModuloMovimiento(6)) INSTANCIA_MODULO(7,ModuloVoz(7)) WHEX_FIN_MODULOS WHEX_UNIDAD_COMUNICACION(WHEX_COM) WHEX_BUZONES WHEX_BUZON(1,Mensajes TCP/IP) WHEX_BUZON(2,Mensajes al Driver) WHEX_BUZON(3,Mensajes enviados al proceso de vision) WHEX_BUZON(4,Mensajes de vision) WHEX_BUZON(5,Mensajes del sensor de distancias) WHEX_BUZON(6,Mensajes de comandos de movimiento de alto nivel) WHEX_BUZON(7,Mensajes de voz) WHEX_FIN_BUZONES WHEX_SUSCRIPCIONES WHEX_SUSCRIPCION_BUZON(1,1) WHEX_SUSCRIPCION_BUZON(2,2) WHEX_SUSCRIPCION_BUZON(3,3) WHEX_SUSCRIPCION_BUZON(4,4) WHEX_SUSCRIPCION_BUZON(5,5) WHEX_SUSCRIPCION_BUZON(6,6) WHEX_SUSCRIPCION_BUZON(7,7) WHEX_FIN_SUSCRIPCIONES WHEX_EVENTOS_PERIODICOS(100000,100000) WHEX_SUSCRIPCION_EVENTO(1,5,500000) WHEX_FIN_EVENTOS_PERIODICOS WHEX_FIN_UNIDAD_COMUNICACION

35

Descarga y documentación en: http://mpg321.sourceforge.net/ 36

Descarga y documentación en: http://www.cstr.ed.ac.uk/projects/festival/



Como puede apreciarse en el listado anterior, utilizando las macros expuestas en la sección

9.1.5 se ha definido la arquitectura modular que se utilizará en el software: se han declarado

los módulos, los buzones de mensajes internos y los eventos periódicos que se necesitan

además de las suscripciones de los módulos a estos recursos del framework.

9.2.4 Proceso cliente WHEX 1.

Este proceso se ejecuta fuera del robot en ordenadores clientes y consiste en una interfaz

gráfica creada utilizando el lenguaje Java y las librerías de creación de interfaces gráficas

Swing.

Al iniciar el programa se muestra una ventana que solicita los datos necesarios para conectar

con el robot (ver figura 9.9). Es necesario aclarar que la contraseña no viaja a través de la red,

en su lugar se envía su resumen SHA1.

Fig. 9.9: Ventana “Conectar con el robot” del cliente WHEX 1.

Si los datos de acceso son correctos y se establece la conexión con el robot, se muestra la

ventana principal de la interfaz gráfica (ver figura 9.10). Esta ventana permite controlar los

movimientos y la postura del robot de forma sencilla para el usuario.

Fig. 9.10: Ventana principal del cliente WHEX 1.



El listado del anexo D muestra las partes más significativas del código fuente de los programas

que componen el software controlador WHEX 1, este anexo puede ser consultado como guía

para la codificación de módulos nuevos y su integración en el software.

Diseño y ejecución de las pruebas del sistema.


Capítulo

Diseño y ejecución de las pruebas del sistema

10



10 Diseño y ejecución de las pruebas del sistema.

Para finalizar el desarrollo del presente trabajo se han ejecutado una serie de pruebas que

demuestran el correcto funcionamiento del robot WHEX 1. Se realizaron pruebas unitarias

sobre cada elemento desarrollado y una vez aprobadas dichas pruebas se procedió a su

integración con los demás elementos del sistema. Finalmente, para garantizar el correcto

funcionamiento del robot como un todo, se realizaron pruebas de aceptación.

Las pruebas unitarias y de integración fueron ejecutadas en el mismo orden en el que se

desarrollaron los elementos del robot:

Estructura mecánica.

Placa controladora.

o Firmware del controlador de servomotores.

o Firmware del controlador principal WHEX 1.

o Circuito impreso de la placa controladora.

Software controlador WHEX 1.

Una vez comprobado que todos los elementos anteriores funcionan correctamente de forma

individual se realizaron pruebas de aceptación. A continuación se comentan las pruebas

realizadas y los resultados obtenidos en ellas.

10.1 Pruebas realizadas sobre la estructura mecánica.

Las pruebas realizadas sobre la estructura mecánica se orientaron principalmente hacia la

detección de fallas estructurales por sobrepeso y torsiones en los ejes de las articulaciones. Así

mismo fueron probadas cada una de las piezas que se fabricaron y

las adquiridas.

Inicialmente las piezas de las patas del robot fueron fabricadas

utilizando policarbonato debido a su facilidad de corte; pero al realizar

pruebas de torsión se comprobó que esta era muy elevada, llegando

incluso a romperse la pieza al exceder el peso aplicado. Debido a

esto se decidió cambiar el diseño para fabricar dichas piezas en

aluminio en vez de policarbonato, eliminando casi completamente la

torsión sin agregar peso extra. La figura 10.1 muestra las piezas de

policarbonato que se descartaron.

Por otra parte se comprobó que los servomotores que se pretendía

utilizar (HITEC HS311) no contaban con la fuerza suficiente para

soportar el peso del robot, que para realizar las pruebas se estimó en

2.5 Kg.

Si el robot pesa 2.5 Kg, cada pata del mismo debe poder soportar un peso igual a la sexta

parte de esta cantidad cuando el robot está detenido y de la tercera parte cuando camina, o

sea, aproximadamente 400 y 800 gramos respectivamente. Al aplicar peso sobre una pata

energizada se comprobó que los servomotores no pudieron mantener la posición cuando

pesaban sobre estos aproximadamente 600 gramos.

También se comprobó que se generaba torsión en los ejes de los servomotores, pues en el

HITEC HS311 estos están hechos de plástico; por tanto, debido a esto y a su falta de fuerza,

Fig. 10.1: Piezas de las patas fabricadas en policarbonato que se descartaron debido a su alta torsión.



fueron sustituidos los servomotores de la rodilla por el modelo BMS620MG y los de la cadera

(eje horizontal) por el modelo BMS630MG, ambos de la marca BlueBird; mientras que se

decidió seguir utilizando el modelo de HITEC para el eje vertical de la cadera y para las

articulaciones del cuello del robot.

Cuando todas las patas ya se encontraban en su sitio se decidió realizar una prueba de peso

sobre toda la estructura, fabricada en aluminio y utilizando los nuevos servomotores. Para esto

se colocó un peso de 1.5 Kg sobre la estructura, para así

completar el peso total de 2.5 Kg.

Al ejecutar la prueba se comprobó que los soportes

multifuncionales empleados para fijar las patas al cuerpo del

robot (ver figura 3.28) no eran lo suficientemente fuertes, ya que

se doblaron unos 5º, perdiéndose así la orientación correcta de

las patas. Para solucionar este problema se agregaron fijadores

de plástico para mantener al servomotor en su sitio.

La figura 10.2 muestra un servomotor del eje horizontal de la

cadera, el cual se ha reforzado con un fijador de plástico para impedir que el soporte

multifuncional se deforme.

10.2 Pruebas realizadas a la placa controladora WHEX 1.

Como se ha visto en secciones anteriores del presente trabajo, el proceso de desarrollo de la

placa controladora y los paquetes de firmware que esta integra se realizó utilizando la

simulación para la comprobación de los circuitos y programas creados; por tanto, fueron

verificados y corregidos muchos errores en esta etapa. No obstante, se realizaron pruebas para

comprobar el correcto funcionamiento de los elementos que componen la placa.

El circuito se comprobó implementándolo físicamente en la placa de prototipado rápido. En esta

etapa del diseño se realizaron mediciones de las intensidades y tensiones reales existentes en

el circuito; dichas mediciones sirvieron para ajustar algunos valores de resistencias y

capacitores para cumplir de forma más ajustada los requerimientos de los microcontroladores

PIC utilizados.

10.2.1 Pruebas realizadas al firmware del controlador de servomotores.

Para verificar el firmware se realizaron pruebas en simulación y

en la placa de prototipado rápido. El controlador de

servomotores se verificó físicamente conectando a la placa de

prototipado el circuito ComMasterPort, desarrollado

íntegramente y verificado con anterioridad a este trabajo.

La figura 10.3 muestra el circuito ComMasterPort, este circuito

implementa un dispositivo I2C maestro comandado a través del

puerto Serie del ordenador. De esta forma es posible enviar

comandos desde un ordenador a cualquier dispositivo esclavo

I2C, como es el controlador de servomotores desarrollado para

el robot WHEX 1. El envío de los datos al circuito

ComMasterPort se utilizó utilizando el software para Windows: Eltima Advanced Serial Port

Terminal.

Fig. 10.2: Fijador de plástico rodeando el servomotor de la cadera para impedir que el exceso de peso deforme el soporte multifuncional.

Fig. 10.3: Circuito ComMasterPort utilizado para la realización de las pruebas al controlador de servomotores.



Para verificar que el controlador de servomotores ejecuta los comandos enviados se

conectaron 8 servomotores HITEC HS311 a sus primeras 8 salidas PWM. Verificados todos los

casos de prueba con estas salidas, se ejecutó nuevamente todo el set de pruebas sobre las 8

salidas siguientes y una última vez sobre las 8 restantes salidas.

El diseño de los casos de prueba se basó en las clases de equivalencia mostradas en la

primera tabla del anexo E. Así mismo, la segunda tabla del anexo E muestra los casos de

prueba diseñados y ejecutados para verificar el correcto funcionamiento del controlador de

servomotores.

10.2.2 Pruebas realizadas al firmware del controlador principal WHEX 1.

Las pruebas del controlador principal WHEX 1 se ejecutaron con el controlador insertado en la

placa controladora WHEX 1 y esta a su vez montada en la estructura mecánica del robot. A

continuación se conectaron correctamente todos los servomotores a las salidas PWM

definitivas y utilizando un cable serie se conectó el controlador a un ordenador portátil. Los

comandos se enviaron utilizando el software Eltima Advanced Serial Port Terminal para

Windows.

El diseño de los casos de prueba se realizó por separado para cada funcionalidad del

controlador:

La comunicación RS232 y el módulo maestro I2C se probaron utilizando el mismo set

de pruebas empleado para probar el controlador de servomotores (ver anexo E).

La cinemática inversa se probó utilizando los casos de prueba mostrados en el

anexo F.

El generador de movimientos se probó haciendo funcionar al robot, realizando todas

las transiciones entre estados existentes y corrigiendo sobre la marcha los problemas

encontrados.

Al finalizar las pruebas unitarias se realizaron pruebas de carga utilizando el comando

0x00 para determinar si la comunicación se efectuaba de forma eficiente.

Los resultados obtenidos con las pruebas realizadas demostraron la existencia de varios fallos,

como por ejemplo los siguientes:

El módulo maestro I2C se colgaba al enviar una solicitud de lectura a los servomotores

cuando estos se encontraban inactivos.

El módulo de cinemática inversa no realizaba bien el cálculo del ángulo 1 de la cadera

cuando el punto se encontraba por encima de la base de la pata.

La necesidad de crear el módulo gestor de peticiones surgió debido a que el

controlador se colgaba cuando se realizaban peticiones a ráfagas de 150 comandos

por segundo o más.

El generador de movimientos no generaba una trayectoria rectilínea al caminar

utilizando 1 o 2 patas.

Actualmente todos estos fallos se encuentran corregidos y el controlador principal WHEX 1

funciona correctamente.

10.2.3 Circuito impreso de la placa controladora.

El circuito impreso de la placa controladora fue probado en laboratorio, realizando mediciones

de las tensiones y consumos en todas las partes del circuito para detectar posibles

cortocircuitos.



De igual forma se probaron las salidas PWM, utilizando un osciloscopio para medir las

frecuencias y los tiempos en los que la señal se mantenía en estado 1.

10.3 Software controlador WHEX 1.

El desarrollo del software controlador WHEX 1 se verificó en todo momento mediante pruebas

unitarias automáticas, para esto se utilizaron las librerías CppUnit. El uso de la técnica de

diseño dirigido por pruebas (TDD) facilitó mucho el desarrollo y la detección de fallos en

momentos tempranos del desarrollo.

Bloque IV

Conclusiones y líneas futuras.


Capítulo

Conclusiones y líneas futuras 11



11 Conclusiones y líneas futuras.

11.1 Conclusiones.

Este proyecto ha abordado el diseño y construcción de un robot móvil articulado de seis patas,

el cual se ha concebido desde sus inicios como una plataforma hardware de apoyo a la

enseñanza de técnicas de programación robótica.

Para lograr este objetivo se han realizado un número de tareas relacionadas con el diseño de

la estructura mecánica y la electrónica del robot. Se ha instalado y configurado apropiadamente

la distribución de Linux Debian en el ordenador de a bordo y se han codificado los paquetes de

software y firmware que controlan al robot. La tabla 11.1 muestra las tareas que se han

realizado en el proyecto, especificando para cada una de ellas sus tiempos estimados y reales

(estos tiempos son aproximados).

Nombre de la tarea Tiempo estimado inicialmente (semanas)

Tiempo real (semanas)

Estudio del estado de la cuestión. 2 2

Diseño y desarrollo de la estructura mecánica del robot. 8 9

Elección de los actuadores y sensores. 1 1

Diseño y desarrollo de la placa controladora. 6 7

Diseño y codificación del firmware controlador de servomotores. 3 3

Diseño y codificación del firmware controlador principal WHEX 1. 3 5

Elección y puesta a punto del hardware de ordenador de a bordo. 2 2

Instalación y configuración del sistema operativo del ordenador de a

bordo.

1 2

Diseño y codificación del software de controlador WHEX 1. 4 3

Crear código de ejemplo para mostrar las potencialidades técnicas y

académicas del robot y un programa cliente para controlarlo.

3 4

Documentar. 15 16 + ?

48 54 + ?

Tabla 11.1: Duraciones estimadas y reales de las tareas del proyecto. Nótese que la tarea “documentar” no se ha concluido en el momento de la redacción de estas conclusiones, por eso se han añadido los signos de interrogación.

En el transcurso del proyecto se han tenido que abordar de forma práctica muchos temas en

los cuales no se tenía experiencia alguna, como por ejemplo en la programación de

microcontroladores PIC de gama alta en C; de hecho, las desviaciones en los tiempos de la

tabla 11.1 se han debido principalmente a este motivo.

No obstante, el sistema obtenido es muy flexible tanto desde el punto de vista del hardware

como del software y, dado el propósito académico del robot, esta flexibilidad es una ventaja

clara sobre los proyectos de robótica similares que se pueden encontrar actualmente en el

mercado. El hardware WHEX 1 posibilita, a través de sus múltiples puertos de expansión, la

posibilidad de añadir hardware nuevo sin modificar el ya existente y el software desarrollado

permite ser modificado libremente por los usuarios.

Otra característica que hace que WHEX 1 sea una plataforma robótica hexápoda diferente

dentro de su categoría es la existencia de procesamiento de a bordo. Durante el estudio del

estado de la cuestión en materia de robótica documentado en este trabajo no se encontró



ningún proyecto de robótica que haya diseñado un hexápodo que presente ordenador de a

bordo. Estos robots en realidad no tienen procesamiento alguno, sino que reproducen

secuencias de movimientos grabadas con anterioridad y enviadas desde un ordenador remoto.

Si bien esta es una ventaja de WHEX 1 sobre otros proyectos, su hardware permite crear una

configuración que carezca de ordenador de a bordo, sustituyéndolo por un cable de

comunicación o un módulo de radiofrecuencia serial que establezca la comunicación con algún

ordenador externo.

Desde el punto de vista técnico, el robot WHEX 1 se ha diseñado utilizando tecnología

existente y actualizada. Se ha preferido en todos los aspectos del diseño hardware y software

el empleo de estándares en contraposición al desarrollo propio (y poco estándar) de protocolos.

Tal es el caso de las tecnologías de comunicación empleadas: bus I2C para la comunicación

entre circuitos integrados y los protocolos RS232 y USB para la comunicación entre sistemas.

Esto ha posibilitado que el robot tenga un alto grado de integración con hardware y software de

terceros, como por ejemplo con todos los sensores que emplean al bus I2C como sistema de

comunicación.

El desarrollo del firmware del controlador principal WHEX 1 se comenzó utilizando el lenguaje

ensamblador para PIC18. No obstante, de forma temprana se observó que las desventajas de

este lenguaje eran muy superiores a las ventajas de utilizarlo para codificar un programa

complejo. Por este motivo se decidió, a pesar de la falta de experiencia, utilizar el lenguaje C

para programar este paquete de firmware. Esta decisión impuso el reto de aprender la

tecnología y posibilitó que el desarrollo del firmware concluyera de forma exitosa.

En cuanto a la codificación del software de control hay que mencionar que fue muy ventajoso

utilizar el diseño dirigido por pruebas como técnica principal de diseño. Esto posibilitó aumentar

la agilidad en la codificación y disminuir el número de errores generados. También es preciso

mencionar que la utilización de patrones de diseño en el desarrollo del framework WHEX 1

permitió la creación de un código bastante estándar, escalable y fácil de comprender.

11.2 Líneas futuras.

El robot hexápodo desarrollado en este trabajo cumple con los objetivos que se han planteado

en el inicio del proyecto: servir de plataforma académica y funcionar en condiciones óptimas de

laboratorio. No obstante, su desarrollo puede continuar y para esto se recomiendan las

siguientes líneas futuras.

En estos momentos el ciclo de control que implementa WHEX 1 es abierto, pues no existe

retroalimentación de las posiciones reales de las articulaciones. Por este motivo el robot no

puede reaccionar ante fuerzas externas que impidan la adopción de una postura concreta o la

ejecución de un movimiento determinado.

Algunos servomotores más avanzados y sobre todo más caros que los empleados en WHEX 1

permiten conocer la posición real de su eje en tiempo real; pero estos servomotores fueron

descartados desde el comienzo debido principalmente a su elevado precio. Para implementar

esta característica en los servomotores empleados actualmente en el robot se propone la

siguiente modificación: extraer una línea directamente desde el potenciómetro que codifica la

posición del eje del servomotor. Un microcontrolador auxiliar, que se comunique con el

microcontrolador principal WHEX 1 mediante el bus I2C, podría leer los niveles de tensión

provenientes de estos potenciómetros y decodificar las posiciones reales de las articulaciones.



Por otra parte, el algoritmo de locomoción fija que emplea el robot actualmente funciona muy

bien en superficies regulares; pero no funciona adecuadamente en terreno irregular, por tanto

se propone la implementación del algoritmo de locomoción libre descrito en el estado de la

cuestión. Uno de los pasos de este algoritmo es el cálculo de las coordenadas del centro de

gravedad. Para esto es necesario agregar sensores de presión en la punta de las patas.

Un sensor de presión muy sencillo de desarrollar puede basarse en un pequeño dinamómetro

al cual se le acopla un potenciómetro de desplazamiento lineal que refleje la medida de

deformación del resorte del dinamómetro cuando la pata esté apoyada. Utilizando la medida

del potenciómetro se puede calcular la fuerza con la que la pata se apoya en la superficie.

Otra modificación que puede ser útil en el diseño del algoritmo de locomoción libre es la

incorporación de un sensor gravitacional que le indique al robot el grado de inclinación de la

superficie por la que camina.

El robot actualmente no cuenta con ningún sistema de gestión de la energía de la batería.

Solamente se cuenta con indicadores LED de la carga restante que los usuarios deben

observar.

Un sistema de gestión de la carga de las baterías puede implementarse utilizando un PIC de

gama baja que lea la tensión de las baterías y genere las señales necesarias para ordenarle al

robot que actúe en consecuencias cuando la batería se esté agotando. Este subsistema se

comunicaría mediante el bus I2C presente en el robot e iniciaría un apagado ordenado cuando

se alcanzaran los niveles mínimos de carga, protegiendo de esta forma las baterías.

Estas y muchas otras actualizaciones de hardware podrían realizarse utilizando los puertos de

expansión hardware de la tarjeta controladora.

En cuanto al futuro desarrollo del software de control, este se deja a los usuarios que podrán

añadir módulos nuevos y modificar los existentes para crear nuevas funcionalidades

personalizadas.


Bibliografía

1. Valdés F., Pallás R. (2007) “Microcontroladores. Fundamentos y aplicaciones con PIC”.

Marcombo Ediciones Técnicas, Barcelona.

2. Bergren C. M. (2003) “Anatomy of a robot”. McGraw-Hill.

3. Martín Cuenca E., Asensio L. “PC Práctico: Servomotores y su control”. Asociación de

mcrobótica de la Universidad de Valladolid, Valladolid.

http://www.eis.uva.es/amuva/servos.pdf

4. Gilbertson R (2000) “Muscle Wires Project Book (3-133): A Hands on Guide to Amazing

Robotic Muscles That Shorten When electrically Powered”. Mondo-Tronics,

Incorporated.

5. Craig J.J. (2006) “Robótica”. Pearson, México. Pp 101-135.

6. Gorrostieta E., Vargas E. “Algoritmo de locomoción libre en un robot hexápodo”.

Instituto Tecnológico de Querétaro, México. http://www.mecamex.net/docs/art23.pdf

7. Gorrostieta E., Vargas E. (2007). “Algoritmo difuso de locomoción libre para un robot

caminante de seis patas”. Universidad Autónoma de Querétaro, México.

http://www.cic.ipn.mx/portalCIC/s11/vol11-03/v11no3_Art05.pdf

8. Celaya, E., Porta J.M. (1998) “A Control Structure for the Locomotion of a Legged

Robot on Difficult Terrain”. IEEE Robotics and Automation Magazine. Vol 5. Num 2. pp

43 – 51.

9. Viola P., Jones M.J. (2004) "Robust real-time face detection". International

Journal of Computer Vision, 57(2):151-173.

http://lear.inrialpes.fr/people/triggs/student/vj/viola-ijcv04.pdf

10. Lienhart R., Maydt J. (2002) "An Extended Set of Haar-like Features for Rapid Object

Detection" En: Tekalp A.T. (ed) IEEE ICIP 2002, Vol. 1, Rochester, Nueva York, pp.

900-903, Sep. 2002.http://www.lienhart.de/ICIP2002.pdf

11. Pisarevsky V. “OpenCV Object Detection: Theory and Practice”. Intel Corporation,

Software and Solutions Group.

http://fsa.ia.ac.cn/files/OpenCV_FaceDetection_June10.pdf

12. Freund Y., Schapire R. E. (1997) “A decision-theoretic generalization of on-line learning

and an application to boosting”. Journal of Computer and System Sciences 55, 119-

139.http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=50856377919EFF3A0825

77189BCCC305?doi=10.1.1.109.5335&rep=rep1&type=pdf

13. Alfonso S., Soto E., Fernández S. (2006) “Diseño de sistemas digitales con VHDL”.

Thomson Editores, Madrid, España.

14. Quintáns C. (2008) “Simulación de circuitos electrónicos xon ORCAD® 16 Demo”.

Marcombo Ediciones Técnicas. Barcelona, España.

15. García E. (2008) “Compilador C CCS y Simulador PROTEUS para microcontroladores

PIC”. Marcombo Ediciones Técnicas. Barcelona, España

Universidad San Pablo - CEU Escuela Politécnica Superior...

Documents

Transcript of Universidad San Pablo - CEU Escuela Politécnica Superior...