1 Memoria

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
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.
4
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.
5
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.
6
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.
7
Dedicatoria
A m i p a dre ,
por s er a lg u i en e n q u i en s iem pr e pu e d o c onf i ar.
8
Agradecimientos
A m i f am il ia , es p ec i a l m ente a m is pa dr es , m is her m an os y m i t í a C ac h a , s i n
s u a po yo s e gu r am en t e es te dí a n o ha br ía s id o p os i b l e.
A n ues tr a q uer i d a am iga Am al i a, s i n s u a yu d a h o y yo n o es t arí a a q uí .
A m i n o v ia S an dr a, f u en t e de m i i ns p ir ac ió n .
A m is pr of es or es , t an t o de l a UP R c om o d e l a E PS , s i n los c o n oc i m ient os q ue
m e ha n d a do n o h a br í a s i do pos i b le t erm in a r es ta obr a .
A l d ir ec t or d e es t e pr o ye c t o, s in s u gu í a to d o h abr ía s i do m u y d if í c i l.
A t od os , m uc h as gr ac i as .
10
Ín d ic e de c o n te n id os
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
12
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
13
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
14
Ín d ic e de f i gu r as
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
16
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
17
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
18
Ín d ic e de t a bl as
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
20
Bloque I
Introducción
Capítulo
Introducción 1
WHEX 1: Diseño y construcción de un robot hexápodo programable. 24

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
Estado de la cuestión 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
Fig. 2.1: Microcontroladores PIC.
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.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

1
siguientes :
 Atmel : AVR mega, AVR tiny, 89Sxxxx, AVR32 y AT91SAM.
2
 Microchip : PIC10F, PIC16F, PIC18F, PIC24F, PIC30F, PIC32, dsPIC30F y dsPIC33F.

3
 Freescale (antes Motorola): 68HCxx, 68k, PowerPC y HCS08.

4
 Intel: 8048, 8051, MCS96 y MXS296.

 Renesas5: H8, H8 tiny, H8S, R8C, M16C, H8SX, R32C, M32C y SHx.
 ST : STMSS, ST6, ST7, uPSD y ST10
6
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
Fig. 2.3: Motor DC.
(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/
3
http://www.microchip.com
4
http://www.freescale.com
5
http://www.renesas.eu/prod/mcumpu/
6
http://www.st.com/mcu/

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. Fig. 2.4: Motor DC con
caja reductora.
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. Fig. 2.5: Servomotor de
modelismo.
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).
Fig. 2.6: Componentes de un servomotor de modelismo.
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.

 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
Fig. 2.7: Modulación por Ancho de Pulso (PWM). 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
7
la empresa Mondo Tronics ).
Fig. 2.8: Alambre Flexinol.
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/

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,
8
semi-contraído y contraído totalmente .
Fig. 2.10: Músculo artificial de la

El músculo está compuesto por la membrana, dos terminales, y compañía Schadow Robot.
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
9
aire .
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

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 Fig. 2.11: Pistones
Hidráulicos.
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.
Fig. 2.12: Controladora de servos

La placa de la figura 2.12 permite el control de hasta 32 SSC32.
servomotores simultáneamente a través de un puerto serie

10
RS232 .
La placa de la figura 2.13 permite el control de hasta 28

servomotores simultáneamente a través de un puerto USB o serie
11
(RS232) . Fig. 2.13: Controladora de
servos ELECTAN.
La placa de la figura 2.14 permite el control de hasta 21

12
servomotores simultáneamente a través de un bus I2C .
Estas placas se suelen utilizar para la sincronización de múltiples Fig. 2.14: Controladora de
servos por I2C.
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

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
13
mercado muchos tipos de baterías :
 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
14
forma incompleta . 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). Fig. 2.16: Batería de plomo.
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.

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 Fig. 2.17: Baterías
de Níquel Cadmio.
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 Fig. 2.18: Baterías de Níquel e
que puede entregar. Hidruro Metálico.
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.

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

Fig. 2.19: Batería de Iones de
que entrega a medida que la carga se agota, siendo los siguientes Litio para teléfono móvil
valores, los proporcionados: Nokia.
 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 Fig. 2.20: Batería de
Polímeros de Litio empleada
bastante superior. en aeromodelismo.
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.

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
15
necesidad puntual del robot que se está programando [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.
Tiempo Posición
1 30º
2 0º
3 -
4 120º
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

pueden levantarse cuando el centro de gravedad del robot se encuentra en cada región de la
figura.
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. Tabla 2.2: Patas que pueden moverse en el algoritmo de
Regiones para el algoritmo de locomoción locomoción libre según la región en la que se encuentre
libre. el centro de gravedad del robot.
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.

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]
Fig. 2.22: Imagen integral, el valor

En la figura 2.22 se puede apreciar este concepto: el valor de la de la imagen integral en el punto
(x,y) es la suma de todos los
posición (x,y) en la imagen integral es igual a la suma de todos píxeles que pertenecen a la parte
los pixeles de la región sombreada en la imagen original. 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

Fig. 2.23: Características tipo Haar.
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]
Fig. 2.24: Características tipo Haar que

Es necesario mencionar que dependiendo de la orientación implementa el detector de OpenCV.
de las regiones (ver rectángulos horizontales, verticales y

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.
16
2.7.1 Asimo
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
17 18
suavemente e imitar muchos otros movimientos humanos.
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.
Fig. 2.25: Robot humanoide

ASIMO de Honda.
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/

19
El robot ASIMO cuenta con los siguientes sensores :
 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.
20
2.7.2 BigDog
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
21
la Universidad de Harvard. (ver figura 2.26)
Mide 0,91 m de largo, por 0,76 de alto y pesa 110 kg; más o
19
menos como una mula pequeña. Fig. 2.26: Robot cuadrúpedo
militar BigDog.
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
19
navegación y el equilibrio.
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

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

es capaz de caminar, correr y girar sobre cualquier tipo
23
de superficie, incluso es capaz de nadar en el agua.
Cada una de sus 6 patas está formada por una

estructura semicircular y es animada por solo un
Fig. 2.27: Robot hexápodo todoterreno
actuador (motor Paso a Paso), con lo que cuenta RHex.
entonces con 6 actuadores.
La figura 2.27 muestra al robot RHex sin la carcasa externa.
24
2.7.4 Aibo
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
Fig. 2.28: Robot mascota Aibo
tratarse como si fuera un compañero interactivo. de Sony
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.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
Especificación de requisitos 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.
Diseño y construcción de la estructura mecánica

Capítulo
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.

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.
Fig. 5.9: Trazado en VariCAD y representación Fig. 5.10: Trazado en VariCAD y representación
tridimensional de la pieza Leg 1. tridimensional de la 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

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.
1
2
3
4
5 6
7
8
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.

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 Fig. 5.14: Representación Fig. 5.15: Soporte multifuncional
antideslizante comercializadas por esquemática de la estructura para servomotores comercializado
la compañía Lynxmotion. mecánica de una pata del robot por la compañía Lynxmotion.
hexápodo WHEX 1 terminada.
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.

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.
Fig. 5.19: Mecanismo Pan & Tilt Fig. 5.20: Platinas en forma de C utilizadas en
comercializado por la empresa Lynxmotion. el mecanismo Pan & Tilt del cuello de WHEX 1
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.


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.
2
F 4
3
5
C
C
E D
G
A
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.

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: 2
1. Fijar el servomotor responsable del movimiento horizontal de

la cabeza a la pieza WHEX Body Cover, utilizando para ello 1
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
Fig. 5.24: Secuencia de
figura 5.25. unión de la cabeza del
robot al cuerpo.
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.

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 Cantidad Precio Total

unitario utilizada (Euro)
(Euro)
Plancha de Policarbonato Leroy Merlin 9.00 1 9.00
de 500 x 250 mm
Plancha de aluminio de 500 Leroy Merlin 12.00 2 24.00
x 250 mm
Separador hexagonal 15 www.ebay.es 0.10 9 0.90
mm
Separador hexagonal 30 www.ebay.es 0.15 24 3.60
mm
Punta de goma Lynxmotion Lynxmotion 0.40 6 2.40
Mecanismo Pan & Tilt Lynxmotion 7.50 1 7.50
Soporte multifuncional para Lynxmotion 4.50 6 27.00
servomotor
Servomotor HITEC HS311 www.ebay.es 9.00 8 72.00
Servomotor Bluebird www.ebay.es 18.00 6 108.00
BMS630MG
Servomotor Bluebird www.ebay.es 12.50 6 75.00
BMS620MG
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 Fig. 5.29: Pieza WHEX Body 2 con servomotores.
instalado.

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.
Diseño y construcción de la electrónica

Capítulo
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.
Fig. 6.3: Batería LIPO
utilizada en WHEX 1.
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.

 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,
25
llegando a explotar si no se detecta a tiempo .
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.
Fig. 6.5: UBEC de 5 V / 6 V, 3 A constantes Fig. 6.6: UBEC de 5 V / 6 V, 8 A constantes

y 5 A de pico, de marca TURNIGY, y 15 A de pico, de marca G.T. Power,
protegido contra interferencias. protegido contra interferencias y con
monitor del estado de carga de las
baterías.
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,

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
26
servomotores. 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
27
I2C), estos comandos se codifican según el estándar I2C .
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
28
WHEX 1, este circuito tiene como elemento principal al microcontrolador PIC18F4525 ,
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
29
inferior. La placa se ha fabricado siguiendo el método de foto-exposición y ataque ácido 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,
30
entre otros. En la figura 6.20 se puede ver esta placa base.
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

31
fuente de alimentación PicoPSU 60WI (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 Fig. 6.21: Fuente de alimentación PicoPSU
60WI
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

Por último es necesario mencionar que se ha utilizado una controladora

WIFI USB para proveer al robot de enlace inalámbrico a internet, la
32
controladora utilizada es una SMC EZ Connect SMCWUSBS-N ,
mostrada en la figura 6.23.
Fig. 6.23: Controladora
WIFI USB SMC EZ Connect,
La tabla 6.1 muestra los precios de los componentes que integran la utilizada en WHEX 1.
electrónica del robot.
Producto o componente Proveedor Precio unitario Cantidad utilizada Precio Total

(Euro) (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

Diseño y desarrollo del firmware del robot.
Diseño y desarrollo del firmware del robot

Capítulo
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 Velocidad Posición Posición Posición Posición

del servo (8 bits) final. final actual actual.
Precarga (8 bits) (8 bits) Precarga.
(16 bits) (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 8: PuertoD[7]  Servo 16: PuertoA[4]
 Servo 1: PuertoB[6]  Servo 9: PuertoD[6]  Servo 17: PuertoA[5]
 Servo 2: PuertoB[5]  Servo 10: PuertoD[5]  Servo 18: PuertoC[2]
 Servo 3: PuertoB[4]  Servo 11: PuertoD[4]  Servo 19: PuertoC[1]
 Servo 4: PuertoB[3]  Servo 12: PuertoA[0]  Servo 20: PuertoC[0]
 Servo 5: PuertoB[2]  Servo 13: PuertoA[1]  Servo 21: PuertoD[0]
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
Asignar PosiciónFinal8Bits[i] = PosiciónRecibida.
Asignar Velocidad[i] = VelocidadRecibida.
Fin repetir
Sino Si comando == Activar todos los Servos
Establecer bit ServoEnabled[i] = ‘1’.
Fin repetir
Sino
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 Primer grupo de Segundo grupo de Tercer grupo de

(variable contador) señales señales señales
(Temporizador 0) (Temporizador 1) (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 Temporizador 0 Precarga = PosiciónActual16Bits[AtenderServoTemp0].
Activar Temporizador 0.
Si ServoEnabled[AtenderServoTemp0] == ‘1’
Establecer bit Puertos[AtenderServoTemp0] = ‘1’.
Temporizador 0:
Asignar AtenderServoTemp0 = Contador.
Restablecer bit Puertos[AtenderServoTemp0] = ‘0’.
Desactivar Temporizador 0.
Temporizador 1:
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 adoptar , calcular los puntos
33
(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. 3: Rotando.
1: Detenido. 4: Deteniendo.
2: Caminando.
* 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
// Estado 2.2

// Estado 2.3
Ejecutar EstablecerEstadoPatasSeleccionadas(Modo, Moviendo).
Ejecutar EstablecerContadorPasoPatasSeleccionadas(Modo).
Ejecutar SeleccionarSiguientesPatas(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.
Elección y configuración del sistema operativo

Capítulo
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.
Diseño y desarrollo del software de control WHEX 1

Capítulo
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‛
// Unidad modular
WHEX_MODULOS(UnidadModularEjemplo)
INSTANCIA_MODULO(1,Modulo1(1))
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_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
34
Como imágenes positivas se ha utilizado la base de datos de rostros FERET , 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 Funcionalidad de detección de rostros utilizando la
rostros cámara del robot.
4 Procesador Seguidor de Generación de comandos de movimientos para
rostros. realizar el seguimiento de un rostro mediante la
cámara.
5 Procesador Sensor de Gestión del sensor de distancias por ultrasonidos.
distancias
6 Procesador Movimiento Gestión de las órdenes relacionadas con la postura y
los movimientos del robot.
7 Procesador Generador de Generación de notificaciones acústicas y mensajes
Voz 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 E/S TCP/IP
través de la conexión TCP/IP
2 Mensajes que contienen comandos que se deben enviar al E/S Driver WHEX 1
driver de la tarjeta controladora WHEX 1.
3 Mensajes que contienen comandos de activación y E/S Visión de rostros
desactivación de la detecció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 Proc Sensor distancias
ultrasonidos.
6 Mensajes que contienen los datos y comandos para controlar el Proc Movimiento
comportamiento del robot y su postura, por ejemplo ordenes de
caminar, rotar, detenerse o dormir, entre otras.
7 Mensajes que contienen frases en el idioma español destinadas Proc Voz
a ser sintetizadas, generando mensajes hablados.
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 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
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 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
Sino
Ejecutar EnviarMensajeInterno(‚go_stop‛).
Ejecutar EnviarMensajeInterno(‚set_head_x=P.X set_head_y=P.Y
Asignar Estado = 3.
Fin Si

Sino Si Estado == 3
Asignar Estado = 1.
Sino
Ejecutar EnviarMensajeInterno(‚set_head_x=0 set_head_y=0
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

35
mpg321 mientras que para la síntesis de la voz en idioma español se utiliza el software
36
sintetizador festival , 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_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.
Diseño y ejecución de las pruebas del sistema

Capítulo
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 Fig. 10.1: Piezas de las patas
utilizar (HITEC HS311) no contaban con la fuerza suficiente para fabricadas en policarbonato
que se descartaron debido a
soportar el peso del robot, que para realizar las pruebas se estimó en su alta torsión.
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,

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 Fig. 10.2: Fijador de plástico
rodeando el servomotor de la cadera
de plástico para mantener al servomotor en su sitio. para impedir que el exceso de peso
deforme el soporte multifuncional.
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
Fig. 10.3: Circuito ComMasterPort
puerto Serie del ordenador. De esta forma es posible enviar utilizado para la realización de las
comandos desde un ordenador a cualquier dispositivo esclavo pruebas al controlador de
I2C, como es el controlador de servomotores desarrollado para servomotores.
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.

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 Tiempo real

inicialmente (semanas)
(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 1 2
bordo.
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 3 4
académicas del robot y un programa cliente para controlarlo.
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

1 Memoria

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

1 Memoria

Încărcat de

Drepturi de autor:

Formate disponibile

Universidad San Pablo - CEU

Escuela Politécnica Superior

Proyecto Final de Carrera

WHEX 1: Diseño y construcción de

Autor: Wiljan Arias Milián

Calificación del Proyecto Final de Carrera

Datos personales del alumno

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

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

por s er a lg u i en e n q u i en s iem pr e pu e d o c onf i ar.

A n ues tr a q uer i d a am iga Am al i a, s i n s u a yu d a h o y yo n o es t arí a a q uí .

CAPITULO 2: ESTADO DE LA CUESTIÓN 34

CAPITULO 3: ESPECIFICACIÓN DE REQUISITOS 60

3.1 ÁMBITO DEL SISTEMA 60

CAPITULO 4: ARQUITECTURA GENERAL DEL SISTEMA 70

4.1 CAPA 1: HARDWARE DEL ROBOT. 71

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

5.1 CUERPO DE WHEX 1. 76

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

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

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

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

9.1 FRAMEWORK WHEX 1 164

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

10.1 PRUEBAS REALIZADAS SOBRE LA ESTRUCTURA MECÁNICA. 190

CAPITULO 11: CONCLUSIONES Y LÍNEAS FUTURAS. 198

11.1 CONCLUSIONES. 198

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

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

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

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

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

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

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

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

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

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

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

Un microcontrolador es un dispositivo programable que ejecuta las

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

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

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

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]:

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

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

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

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

 Intel: 8048, 8051, MCS96 y MXS296.

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

2.2 Actuadores en robótica

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

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

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

2.2.2 Motor DC con caja reductora

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

 Caja del servomotor.

Fig. 2.6: Componentes de un servomotor de modelismo.

El funcionamiento es el siguiente [3]:

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

Los servomotores de modelismo (los más utilizados

2.2.4 Alambres musculares

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

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