Aslab D 2011 019

Desarrollo e implantacion de plataforma robotica movil en
entorno distribuido
Franciso J. Arjonilla Garca
18 de octubre de 2011
A mi abuelo
que en paz descanse
Indice general
1. Introducci
on
1.1. Motivaci
on . . . . . . . . . . . . . . . . . . .
1.2. Estructura del documento . . . . . . . . . . .
1.3. Estado del arte . . . . . . . . . . . . . . . . .
1.3.1. Robots aut
onomos . . . . . . . . . . .
1.3.2. Rob
otica m
ovil . . . . . . . . . . . . .
1.3.3. Ejemplos de robots para investigacion
1.4. Marco del proyecto . . . . . . . . . . . . . . .
1.4.1. Proyecto ASys . . . . . . . . . . . . .
1.4.2. Otros proyectos de investigacion . . .
1.5. Alcance del proyecto . . . . . . . . . . . . . .
1.6. Objetivo del proyecto . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
8
9
13
17
17
18
18
18
2. Requisitos
2.1. Definici
on de los requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Vista general del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
21
27
3. Sistema de partida
3.1. Descripci
on del robot base . . . . . . . . . . . . .
3.2. Descripci
on de la mu
neca . . . . . . . . . . . . .
3.3. Descripci
on de la c
amara . . . . . . . . . . . . .
3.4. Descripci
on del sistema l
aser . . . . . . . . . . .
3.5. Descripci
on del sistema GPS diferencial . . . . .
3.6. Descripci
on de la tarjeta de adquisicion de datos
3.6.1. Aceler
ometro . . . . . . . . . . . . . . . .
3.6.2. Br
ujula electr
onica . . . . . . . . . . . . .
3.7. Descripci
on del ordenador de a bordo . . . . . .
3.8. Descripci
on del entorno de red del laboratorio . .
.
.
.
.
.
.
.
.
.
.
28
28
29
29
30
32
33
34
34
35
36
.
.
.
.
.
.
37
37
37
39
41
45
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Dise
no hardware
4.1. Dise
no de la tarjeta de alimentaciones . . . . . . . . .
4.1.1. An
alisis de los requisitos . . . . . . . . . . . . .
4.1.2. Dise
no electr
onico y seleccion de componentes .
4.1.3. Fabricaci
on y complicaciones surgidas . . . . .
4.2. Dise
no del sensor de corriente y tension . . . . . . . .
4.2.1. An
alisis de requisitos . . . . . . . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INDICE GENERAL
4.2.2. Dise
no te
orico . . . . . . . . . . . . . . .
4.2.3. Consideraciones pr
acticas y construccion
4.3. Montaje y cableado . . . . . . . . . . . . . . . .
4.3.1. Dise
no del p
ortico . . . . . . . . . . . .
4.3.2. Montaje de m
odulos . . . . . . . . . . .
4.3.3. Cableado de datos . . . . . . . . . . . .
4.3.4. Cableado de alimentaciones . . . . . . .
. . . .
fsica
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
47
48
50
50
51
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
54
54
54
56
57
58
58
59
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
61
61
62
62
64
66
67
68
68
69
70
73
7. Validaci
on y pruebas
7.1. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2. Validaci
on de los requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
77
77
8. Aspectos de la direcci
on de proyectos
8.1. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
82
9. Conclusiones y trabajo futuro

9.1. Conclusiones . . . . . . . . . . . . . . . .
9.2. Lneas de desarrollo actualmente abiertas
9.2.1. Webcam . . . . . . . . . . . . . . .
9.2.2. ROS . . . . . . . . . . . . . . . . .
9.2.3. Kinect . . . . . . . . . . . . . . . .
9.3. Trabajos futuros . . . . . . . . . . . . . .
9.3.1. Estaci
on de carga . . . . . . . . . .
85
85
87
87
87
88
88
88
5. Entorno software de trabajo

5.1. Subversion . . . . . . . . . . . . . . . .
5.2. Sistema de compilaci
on CMake . . . .
5.3. Libreras comunes . . . . . . . . . . .
5.4. Sistemas operativos en el ordenador de
5.5. Configuraci
on de los m
odulos CORBA
5.5.1. Par
ametros de los servants . .
5.5.2. Ejecuci
on de los servants . . .
6. M
odulos software
6.1. Mu
neca . . . . . . . . . . . . . .
6.1.1. Servant . . . . . . . . . .
6.1.2. Tolerancia a fallos . . . .
6.2. L
aser . . . . . . . . . . . . . . . .
6.2.1. Selecci
on del c
odigo base
6.2.2. Servant . . . . . . . . . .
6.3. GPSd . . . . . . . . . . . . . . .
6.3.1. Servant . . . . . . . . . .
6.4. Tarjeta de adquisici
on de datos .
6.4.1. Firmware . . . . . . . . .
6.4.2. Servant . . . . . . . . . .
6.5. Executive . . . . . . . . . . . . .
6.6. Prevenci
on de impactos . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
a
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
bordo
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INDICE GENERAL
9.3.2. Optimizaci
on del envo de vdeo . . . . . . . . . . . . . . . . . . . . .
9.3.3. Uso de bateras de litio . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.4. Panel solar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
89
89
89
Bibliografa
90
A. Esquemas de la placa de alimentaciones
91
B. Manual de referencia de la librera executive
98
C. Manual de usuario
109
D. Manual del desarrollador
129
E. Herramientas
160
Indice de figuras
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
1.7.
1.8.
1.9.
El pr
oximo robot de exploracion marciana, Curiosity. . . . . . . . . . . . . . .
Uno de los robots iRobot usados en el reciente desastre nuclear de Fukushima.
Robot de patas BigDog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vehculo lunar de la NASA en investigacion. . . . . . . . . . . . . . . . . . . .
El robot Urbano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
El robot Khepera con vista del interior. . . . . . . . . . . . . . . . . . . . . .
El robot Qbo en desarrollo por la empresa thecorpora. . . . . . . . . . . . . .
Logo de la UPM y ASLab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logo de ASys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
11
12
13
14
15
16
17
17
2.1. Vista general del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.1. La plataforma rob

otica de investigacion tomada como base. . . .
3.2. La mu
neca usada en el movimiento de la camara. . . . . . . . . .
3.3. C
amara estereosc
opica . . . . . . . . . . . . . . . . . . . . . . . .
3.4. El sensor l
aser SICK LMS200 . . . . . . . . . . . . . . . . . . . .
3.5. Componentes que forman el sistema GPS de la estacion movil . .
3.6. La antena, radio y caja de control de la estacion movil del GPS.
3.7. Componentes de la estaci
on base del sistema GPS . . . . . . . .
3.8. Localizaci
on de la antena GPS en el atico del departamento. . . .
3.9. Detalle del aceler
ometro. . . . . . . . . . . . . . . . . . . . . . . .
3.10. Detalle de la br
ujula electr
onica. . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
31
31
32
33
33
34
35
35
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
Fotografa de la tarjeta de alimentaciones montada sobre el robot. . .

Esquema de referencia para el sensor tension-intensidad . . . . . . . .
Esquema final de los sensores I/V . . . . . . . . . . . . . . . . . . . . .
Distribuci
on de pistas del sensor I/V . . . . . . . . . . . . . . . . . . .
Fotografa del convertidor de se
nal del sensor de tension e intensidad. .
Fotografa del sensor i/v acoplado a la tarjeta de adquisicion de datos.
Diagrama de conexiones de datos. . . . . . . . . . . . . . . . . . . . . .
Diagrama de conexiones de alimentaciones. . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
46
48
49
49
49
52
53
6.1.
6.2.
6.3.
6.4.
6.5.
Diagrama de clases de la mu
neca. . . . . . . . . . . . . . . . . . . . . . .
Diagrama de secuencia tpica para una llamada al servant de la mu
neca.
Gesti
on de errores en la mu
neca. . . . . . . . . . . . . . . . . . . . . . .
Procedimiento de inicializacion del protocolo del sensor laser. . . . . . .
Estructuras de datos definidas en la interfaz IDL del laser. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
62
63
64
65
65
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INDICE DE FIGURAS
6.6. Tipos de datos retornados por llamadas al servant del GPS. . . . . . .

6.7. Diagrama de clases del servant de la tarjeta de adqusicion de datos. .
6.8. Diagrama de secuencia del envo de mensajes. . . . . . . . . . . . . . .
6.9. Diagrama de clases de libExecutive. . . . . . . . . . . . . . . . . . . .
6.10. Diagrama de actividades de libExecutive. . . . . . . . . . . . . . . . .
6.11. Representaci
on de las variables usadas en la prevencion de impactos. .
6.12. Funci
on de limitaci
on de la velocidad maxima respecto de la distancia.
.
.
.
.
.
.
.
67
69
70
70
71
74
75
8.1. Estructura de Descomposici

on del Proyecto. . . . . . . . . . . . . . . . . . . .
8.2. Diagrama de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
84
9.1. La plataforma rob

otica m
ovil, bautizada como Higgs, en todo su esplendor. .
9.2. El sensor Kinect de Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
88
A.1.
A.2.
A.3.
A.4.
A.5.
A.6.
A.7.
Esquema del canal de 12V de la placa de alimentaciones . . . . . . . . .

Esquema del canal de 24V de la placa de alimentaciones . . . . . . . . .
Esquema general de la placa de alimentaciones . . . . . . . . . . . . . .
Distribuci
on de pistas en la capa superior de la placa de alimentaciones
Distribuci
on de pistas en la capa inferior de la placa de alimentaciones .
Serigrafa de la placa de alimentaciones . . . . . . . . . . . . . . . . . .
Distribuci
on y di
ametro de los orificios de la placa de alimentaciones . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
92
92
93
94
95
96
97
E.1.
E.2.
E.3.
E.4.
E.5.
Comunicaci
on entre objetos de servicios CORBA.
Esquema de la arquitectura CORBA. . . . . . . .
Logo de subversion . . . . . . . . . . . . . . . . .
Logo de Doxygen . . . . . . . . . . . . . . . . . .
Logo de VIM . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
161
161
162
162
163
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Indice de cuadros
2.1. Arbol
de requisitos resumido. . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.1. Caractersticas principales del rele usado en la tarjeta de alimentaciones . . .

4.2. Distribuci
on de dispositivos por canales en la tarjeta de alimentaciones . . . .
4.3. Listado de presupuestos para la fabricacion del circuito impreso de la tarjeta
de alimentaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4. Listado de componentes de la tarjeta de alimentaciones. . . . . . . . . . . . .
4.5. Valores obtenidos para el sensor I/V . . . . . . . . . . . . . . . . . . . . . . .
4.6. Datos de dise
no del p
ortico . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
41
6.1. Par
ametros de los sensores y distancias mnimas en la prevencion de impactos.
75
8.1. Presupuesto del sistema de partida. . . . . . . . . . . . . . . . . . . . . . . . .

8.2. Presupuesto del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
82
42
43
47
50
Captulo 1
Introducci
on
1.1.
Motivaci
on
El desarrollo de nuevos algoritmos en inteligencia artificial y ciencia cognitiva necesitan

ser probados para que resulten u
tiles en la mejora de la calidad de vida de las personas.
Actualmente se est
a realizando un gran esfuerzo para el desarrollo de nuevas tecnologas en
estos campos, sin embargo, su uso se limita a entornos simulados y la obtencion de informacion.
El objetivo de este proyecto es proporcionar una plataforma robotica para probar en entornos
reales los sistemas de control que se encuentran en fase de investigacion.
La ingeniera de un sistema de estas caractersticas no es trivial, y en general se recurre
a la adquisici
on de robots preparados para investigacion. No obstante la combinacion de
actuadores y sensores deseados debe hacerse a medida y este caso no es una excepcion. Uno
de los elementos diferenciadores que existen es que los componentes que forman el cuerpo del
robot deben ser independientes a los que forman la mente, ademas la capacidad de computo
de la mente no est
a definido y en principio no se impondran lmites a su escalabilidad. Por
ello se ha optado por el uso de la tecnologa CORBA que capacita al robot a funcionar en
entorno distribuido, es decir, con el procesamiento de la informacion realizandose en sistemas
externos al robot propiamente dicho.
Este proyecto contin
ua la labor de otros proyectos fin de carrera completandolos donde
sea necesario, desarrollando las capacidades ausentes e integrando todo ello para que el Laboratorio de Sistemas Aut
onomos de la Universidad Politecnica de Madrid disponga de una
plataforma de pruebas robusta y funcional.
1.2.
Estructura del documento
El captulo 2 presenta una visi

on general sobre los objetivos del proyecto. El captulo 3
ofrece una visi
on detallada de los requisitos que debe tener el robot y las especificaciones
de los requisitos. El proyecto parte desde unos componentes ya seleccionados y adquiridos,
una estructura b
asica y algunos m
odulos ya realizados; este sistema de partida es descrito
en el captulo 4. Los captulos 5 a 7 describen el trabajo de dise
no y desarrollo realizado,
separados en la parte hardware, las herramientas creadas que no participan directamente
en el funcionamiento y la programacion software, respectivamente. El captulo 8 presenta
las pruebas realizadas para cumplir con los requisitos. En el siguiente captulo se analiza la
organizaci
on de los recursos antes y durante el proyecto para terminar en el captulo 10 con las
7

CAPITULO 1. INTRODUCCION
conclusiones, haciendo enfasis en la trascendencia de las tareas realizadas y posibles mejoras

a realizar en el futuro. Finalmente en los anexos aparecen los trabajos mas detallados que por
su amplitud resulta conveniente incluirlos separados de la redaccion del proyecto.
1.3.
Estado del arte
En esta secci
on se har
a un recorrido por el estado de la tecnica en lo que se refiere a robots
para investigaci
on. Se realizar
a una clasificacion de los tipos de robots existentes en cuanto
al campo de utilidad, el entorno de trabajo y la autonoma, para inferir las caractersticas de
robots moviles para investigaci
on, que es el caso que se aborda en este proyecto, y se daran
algunos ejemplos.
1.3.1.
Robots aut
onomos
Un robot aut
onomo es aquel capaz de realizar tareas relativamente complejas en entornos
no estructurados y desconocidos sin la orientacion continua de un operador humano. Un grado
de autonoma alto ya es una realidad en campos como la limpieza de domicilios y robots corta
cesped, y es necesario en campos m
as crticos como la exploracion del espacio y el control en
industrias con productos peligrosos.
La mayor parte de las f
abricas m
as avanzadas incorporan robots autonomos dentro de su
entorno directo. La localizaci
on y orientacion tanto del producto a transformar como de las
herramientas a usar est
a cada vez menos fijado por el proceso de produccion y es el robot el
que debe decidir ante una situaci
on no contemplada a priori.
Otro area de investigaci
on en rob
otica es dotar al robot de las capacidades suficientes para
hacerle capaz de desenvolverse en su entorno, ya sea en tierra, interiores, sumergido, aereo o
espacial.
Un robot completamente aut
onomo debe tener como mnimo estas capacidades:
Obtener datos del estado de su entorno.
Operar durante tiempos prolongados sin intervencion humana.
Manipular parte del entorno y desplazarse para satisfacer sus objetivos.
Evitar las situaciones potencialmente peligrosas para las personas, bienes y para s mismo, a no ser que sea parte de su dise
no.
A medida que un robot tiene mayores grados de autonoma tambien puede adquirir, mediante el aprendizaje, nuevas habilidades como la adaptacion a entornos cambiantes y el
reajuste de los metodos usados para realizar la tarea que tiene encomendada.
La rob
otica comercial aut
onoma ha logrado introducir algunos de los progresos realizados
en los laboratorios.
Auto mantenimiento Para la autonoma completa es necesario que un robot sea capaz de
cuidar de s mismo. Los juguetes robotizados y las aspiradoras domesticas son capaces de
localizar y acoplarse a estaciones de carga cuando su nivel de bateras se reduce.
El mantenimiento se basa en parte en la capacidad del robot para conocer el estado de
s mismo. El conocimiento de este estado se puede aproximar con modelos internos. En general,

estos modelos no son suficientemente exactos y la lectura con sensores propioceptivos aportan
informacion m
as fidedigna con menos esfuerzo de desarrollo.
Los sistemas propioceptivos m
as importantes incluyen:
Encoders
Sensores termicos
Sensores de efecto Hall
Sensores de inclinaci
on
Sensores qumicos
Percepci
on del entorno La exterocepcion se define como la capacidad para percibir el estado
del entorno. Para realizar sus tareas los robots autonomos necesitan sensores que actualicen
el estado interno del entorno con los datos proporcionados por sensores que midan las perturbaciones en la interacci
on del robot con el entorno, como por ejemplo la cantidad de suciedad
a limpiar en una determinada zona. Sensores exteroceptivos son:
Sensores de sonido
Sensores t
actiles
Sensores de contacto
Sensores
opticos
Sensores de proximidad
En general los sensores se clasifican como propioceptivos o exteroceptivos por las variables
que miden, si son propias del robot independientemente del entorno o son del entorno.
Ejecuci
on de tareas Tras la percepcion del estado interno y externo el siguiente paso consiste
en realizar una tarea fsica que modifique este estado. Esta tarea puede ser parte de una
secuencia de subtareas o ser una tarea condicional. Como ejemplo, un robot patrulla puede
tener una secuencia de movimientos preconfigurada que se ve alterada cuando detecta un
intruso.
1.3.2.
Rob
otica m
ovil
Locomoci
on
Existe una gran variedad de modos de desplazarse sobre superficies. Los mas empleados
en robotica son ruedas, cadenas y patas. Los robots de ruedas son los mas empleados con
diferencia. Son m
as sencillos, m
as economicos y la carga que pueden transportar es relativamente mayor. En general, Para una misma carga u
til, tanto los robots con patas como los
que llevan cadenas son m
as complicados y pesados. Ademas, la disponibilidad de robots de
ruedas es mucho mayor, pues es posible transformar coches de radio control.
No obstante los robots de ruedas pueden tener dificultades para moverse en terrenos
irregulares o para superar obst
aculos mayores que aproximadamente 0,4 veces el radio de sus

10
Figura 1.1: El pr
oximo robot de exploracion marciana, Curiosity.
ruedas. Para estos terrenos las cadenas son la opcion mas conveniente. Las cadenas son m
as
resistentes y pueden superar obst
aculos mayores e incluso zanjas. Sin embargo el giro de estas
ruedas provoca el deslizamiento de las cadenas que reducen la eficacia del desplazamiento. En
odometra las cadenas son poco pr
acticas pues el error acumulativo es muy grande y depende
mucho del terreno.
Los robots con patas son los m
as aptos para desplazarse por terrenos muy accidentados.
Su mayor complejidad, proveniente del n
umero de grados de libertad, hace que el control de
estos robots suponga un verdadero reto. Cada pata necesita varios motores cada uno con su
sistema de control, m
as luego el control de la coordinacion de todos los motores. Actualmente
es un area de investigaci
on muy activo que esta siendo liderado por el robot BigDog, de la
Agencia de Proyectos Avanzados de Investigacion de la Defensa de Estados Unidos. Cuenta
con actuadores hidr
aulicos y la suavidad de sus movimientos se asemeja al de un mamfero
peque
no.
Localizaci
on y navegaci
on en interiores
Moverse por el interior de un edificio puede ser complejo cuando no se conoce el mapa,
mas a
un si u
nicamente se percibe una franja limitada del entorno en forma de distancias a
objetos detectados. Un robot debe saber en que lugar se encuentra y ser capaz de moverse de
un punto a otro. Los robots comerciales actuales como Roomba pueden desplazarse de forma
autonoma entre habitaciones detectando caractersticas del entorno, ya sea por contacto o
por cualquier otro medio.
Los sistemas m
as avanzados usan informacion de varios sensores simultaneamente, realizando localizaci
on y navegaci
on simultaneamente (SLAM). Pueden condicionar el uso de cada
sensor al que proporcione los datos mas fiables y reconstruir el mapa partiendo de esa nueva
informacion.
En general, los robots de interiores limitan su movimiento al alcanzable por una silla de
ruedas, controlando ascensores y puertas electronicas en un mapa 2D. Los costes de investigacion se abaratan, mientras que la autonoma necesaria para subir escaleras y abrir puertas

11
Figura 1.2: Uno de los robots iRobot usados en el reciente desastre nuclear de Fukushima.
son temas de investigaci
on candentes.
Localizaci
on y navegaci
on en exteriores
La autonoma en exteriores es alcanzable mas facilmente que en interiores. Los obstaculos
raramente aparecen y son f
acilmente sorteables. No cortan el paso y no existen riesgos de
choque o necesidad de b
usqueda de caminos, pues una desviacion del rumbo no implica
necesariamente que el robot impacte contra un obstaculo.
Algunos ejemplos de robots aut
onomos en exteriores son aeronaves no tripuladas, misiles de crucero y robots submarinos. Algunos de estos robots logran realizar misiones sin
interaccion humana alguna. Parte de esta tecnologa tambien se ha introducido en aeronaves
tripuladas donde el control lo realiza una maquina y el piloto gua al sistema de control sin
tener acceso directo a los accionamientos.
A
un as, la autonoma de vehculos terrestres es mas compleja que los no terrestres, debido
a irregularidades en el terreno, diferencia de densidades de superficie, distintas condiciones
climatologicas y de la superficie y posibles inestabilidades del entorno percibido.
Una de las aplicaciones m
as notables de la navegacion en exteriores son los rovers de
exploracion marciana. Los robots Sojourner, Spirit, Opportunity y el mas reciente Curiosity,
programado para ser lanzado en diciembre de este a
no 2011, pueden encontrar la posicion del
sol y navegar por sus propias rutas a destinos sobre la marcha mediante:
Creaci
on de un mapa 3D con las caractersticas topograficas de la zona.
Distinci
on de terrenos seguros e inseguros.

12
Figura 1.3: Robot de patas BigDog.

Calculo de rutas posibles hacia el destino prefijado.
Navegaci
on a lo largo de la ruta calculada.
Dos proyectos militares estadounidenses, el DARPA Grand Challenge y el DARPA Urban
Challenge, promueven la investigaci
on en navegacion en exteriores, el primero en zonas rurales
y el segundo en urbanas, habiendo logrado a fecha de hoy gran autonoma en los vehculos
desarrollados.
En [13] se ha llegado a una soluci
on bastante buena para el problema de control de robots
moviles.
Dise
no de ruedas
Se puede clasificar los robots m
oviles terrestres con ruedas seg
un su estructura:
Uniciclo Es uno de los dise
nos m
as sencillos tanto mecanicamente como desde el punto de
vista del control. El robot puede trazar curvas, girar sobre s mismo e ir recto. El centro de
giro se puede situar en cualquier punto del eje perpendicular a la direccion de avance de la
rueda. Dada la inestabilidad de un robot de una rueda, se suele implementar con dos o m
as
ruedas en cada lateral del robot que deslizan en los giros.
Ackerman Este tipo de dise
no es el usado por los vehculos de carretera. La caracterstica principal es que todas las ruedas se desplazan perpendicularmente al centro de giro del
vehculo, siendo la configuraci
on m
as tpica dos ruedas motrices traseras y dos ruedas directrices delanteras. Es m
as eficiente que el uniciclo porque las ruedas no sufren deslizamiento,
sin embargo, no permite curvas con radio de giro peque
no. Tiene buena estabilidad a altas
velocidades.
Dise
no sincronizado En este dise
no todas las ruedas son tanto directrices como motrices.
Permite un rango de movimientos omnidireccional. Cada rueda puede girarse sobre s misma
para ajustarse al movimiento requerido sin sufrir deslizamiento. Se esta investigando en este
tipo de robots para la pr
oxima generacion de vehculos lunares (Figura 1.4).

13
Figura 1.4: Vehculo lunar de la NASA en investigacion.
1.3.3.
Ejemplos de robots para investigaci

on
Urbano
Urbano es un robot fruto de la investigacion en Control Inteligente y Tecnologa del Habla
de la Universidad Politecnica de Madrid. Fue dise
nado para realizar la funcion de gua en ferias
y museos, aunque ha servido para realizar m
ultiples experimentos en robotica movil.
Urbano ha sido habilitado para ser operado mediante lenguaje hablado y se puede interaccionar con el presencialmente o a distancia a traves de Internet.
Es capaz de realizar SLAM (Simultaneous Localization And Mapping) en grandes edificios utilizando sensores l
aser para el posicionamiento y una red de sensores infrarrojos y
ultrasonicos para detectar obst
aculos fijos y moviles y poder as evitarlos para llegar al destino previamente programado.
Ha sido provisto de un rostro artificial y un brazo articulado a semejanza de un brazo
humano con el fin de empatizar con los visitantes de los museos y a los que puede mostrar su
estado interno en cuanto a bateras y otras variables, mostrando distintas emociones.
Las u
ltimas investigaciones realizadas con este robot han consistido en el desarrollo de
un generador de presentaciones por el cual el robot, partiendo de una base de datos de presentaciones, selecciona los mejores p
arrafos basandose en el entendimiento semantico de las
caractersticas de los p
arrafos y de los criterios de calidad apropiados para una presentacion
p
ublica. Es capaz de aprender para optimizar la calidad de las presentaciones usando logica
difusa para la toma de decisiones y representa las creencias del robot en cuanto a lo que
es bueno, malo o indiferente para una presentacion. Las creencias del robot contin
uan evolucionando para coincidir con las opiniones del p
ublico usando algoritmos geneticos para la
adaptacion de las reglas que guan esta evolucion [2].
Khepera
Los robots Khepera son una serie de peque
nos robots con m
ultiples funcionalidades y posibilidad de expandir estas funciones con tarjetas de extension, como comunicacion inalambrica

14
Figura 1.5: El robot Urbano

y otros sensores. Han sido desarrollados por la empresa K-Team Corporation. Es de especial
utilidad en la investigaci
on de las capacidades de enjambres de robots trabajando para un
objetivo com
un. En [3] hay m
as informacion sobre un proyecto de investigacion que ha usado
estos robots.
En su versi
on m
as b
asica, el robot Khepera-III dispone de sensores de ultrasonidos en
todo su permetro, sensores de proximidad basados en infrarrojos para rangos de distancias
peque
nas y una configuraci
on de ruedas con los que desplazarse como un movil tipo uniciclo.
Tal como se expone en su p
agina web, la caracterstica mas importante es su modularidad gracias al bus de extensiones incorporado para practicamente cualquier configuracion de
sensores y actuadores. Incorpora dos motores DC de alta eficiencia y precision.
Hace uso del sistema operativo GNU/Linux y de todas las herramientas de desarrollo
tpicamente usadas en este sistema operativo, como el compilador cruzado de C/C++. Se
incluye con varios programas y utilidades que facilitan el desarrollo de aplicaciones de control.
Qbo
Qbo es un robot actualmente en desarrollo por la empresa thecorpora y su mision primaria
es ejercer de plataforma rob
otica para investigacion en interacciones sociales humano-robot.
Para ello cuenta con una multitud de sensores especficos de esta tarea:
Tres micr
ofonos, uno de ellos unidireccional.
Dos altavoces de alta calidad.
Dos c
amaras de alta definici
on con cierres deslizantes a modo de parpados.
LEDs en boca y nariz.

15
Figura 1.6: El robot Khepera con vista del interior.

Sensores de proximidad.
Una pantalla LCD de 20x4 caracteres.
Otros sensores internos.
Su sistema de control est
a formado por varios procesadores en una disposicion muy similar a
la que se ha propuesto en este proyecto:
Tarjeta Arduino para controlar los sensores y actuadores situados en el cuerpo del robot.
Una tarjeta basada en un microcontrolador ARM para controlar los dispositivos situados
en la cabeza del robot.
Una placa Mini-ITX con procesador ATOM y tarjeta grafica Nvidia ION donde realizar
los c
alculos pesados para reconocimiento de habla y vision artificial.
Todas estas caractersticas dotan al robot Qbo de m
ultiples capacidades entre las que se
incluyen:
Vision Estereosc
opica.
Sistema de Reconocimiento de Voz.
Sistema para la Sntesis de la Voz.
API y Panel de Control.
Wifi & Bluetooth conexiones.
Qbo puede sortear esquinas y no caerse gracias a los sensores.
Para potenciar la misi
on investigadora del robot todo su codigo ha sido liberado con
licencias abiertas y est
a en desarrollo un portal web en el que los usuarios puedan publicar y divulgar sus algoritmos de control. Qbo esta llamado a ser la referencia en cuanto a
investigaci
on en robots sociales.

Figura 1.7: El robot Qbo en desarrollo por la empresa thecorpora.
16

1.4.
17
Marco del proyecto
El proyecto se ha desarrollado en el Laboratorio de Sistemas Autonomos1 de la Universidad

Politecnica de Madrid, donde se desarrollan proyectos encaminados a mejorar los sistemas de
control industriales.
Figura 1.8: Logo de la UPM y ASLab.

El laboratorio ASLab tiene varias lneas de investigacion abiertas, todas encaminadas
hacia el cumplimiento de los objetivos a medio y largo plazo del grupo de investigacion, que
estan recogidos en el proyecto ASys.
Las investigaciones realizadas producen sistemas que han de ser validadas mediante pruebas reales.
1.4.1.
Proyecto ASys
ASys es el proyecto principal del grupo ASLab. Se trata de una lnea de investigacion a
largo plazo en la que se enmarcan los demas proyectos. Uno de los objetivos principales es el
desarrollo de tecnologas universales para la construccion de sistemas de gran autonoma.
Figura 1.9: Logo de ASys.

ASLab, a
un enfoc
andose en el objetivo a largo plazo de ciencia y tecnologa para autonoma, tiene algunas lneas de investigacion mas especficas alrededor de temas concretos:
Arquitecturas de control integradas.
Sistemas de control basados en modelos.
Ontologas para sistemas aut
onomos.
Procesos de desarrollo para controladores complejos.
Componentes de control reutilizables.
Middleware de tiempo real y plataformas para control distribuido.
1
La p
agina web de ASLab es http://www.aslab.org.

18
Reubicaci
on de componentes de control embebidos.
Tecnologa de sistemas conscientes.
Implicaciones filos
oficas de la tecnologa de maquinas conscientes.
1.4.2.
Otros proyectos de investigaci

on
Algunos de los proyectos en los que ha trabajado o esta trabajando el grupo ASLab son:
HUMANOBS Humanoides que aprenden habilidades socio-comunicativas por imitacion.
Financiado por el programa IST de la Comision Europea.
COMPARE Una aproximaci
on por componentes a sistemas embebidos y en tiempo real,
financiado por el programa IST de la Comision Europea.
ICEA Integrando Cognici
on, Emocion y Autonoma, financiado por el programa IST de la
Comisi
on Europea.
C3 Control Cognitivo Consciente, financiado por el Ministerio de Educacion y Ciencia.
1.5.
Alcance del proyecto
El alcance del proyecto es el desarrollo y la implantacion de una plataforma robotica movil

para navegaci
on en interiores y exteriores en entorno distribuido con el middleware CORBA,
usando en lo posible componentes hardware ya adquiridos, y la redaccion de documentacion
en forma de manuales de cuanto sea necesario para operar el robot, con el objeto de permitir
pruebas de sistemas de control en investigacion de sistemas conscientes y autorreparables.
1.6.
Objetivo del proyecto
El objetivo principal del proyecto es la ejecucion de las tareas propuestas en el alcance

del proyecto. Para ello es necesario analizar el sistema existente y el sistema deseado con
detalle suficiente para poder planificar el tiempo de desarrollo. A partir de este analisis se
estableceran los requisitos que ha de cumplir el robot a la finalizacion del proyecto.
El proyecto tiene sentido siempre y cuando el robot permita realizar investigaciones en
sistemas distribuidos, sistemas de tiempo real, algoritmos de navegacion en interior y exterior,
sistemas cognitivos de control y sistemas autorreparables. A pesar de ser un proyecto de
desarrollo, establecer
a la base necesaria para la investigacion en dichos campos.
El desarrollo se dividir
a en dos bloques:
Plataforma fsica:
Se ha de dise
nar la plataforma con objeto de integrar fsicamente todos los componentes
hardware.
Se seleccionar
an los componentes y los sensores que aumenten las capacidades del robot.
Se dise
nar
a el control de alimentaciones y sensado de nivel de bateras.
Se integrar
an los canales de se
nales de los equipos.

19
Dise
no del software de la plataforma:
Se usar
a CORBA en el despliegue del entorno distribuido.
Se integrar
a el control remoto de los equipos con el desarrollo de modulos CORBA.
Se deber
a gestionar los errores, la tolerancia a fallos y las desconexiones de los dispositivos.
Se implementar
an las herramientas necesarias que faciliten el desarrollo y despliegue,
as como las libreras de explotacion de la plataforma, junto con plantillas, documentacion, etc.
Captulo 2
Requisitos
En este captulo se describe en detalle cada uno de los requisitos del proyecto. El cuadro
2.1 ofrece una visi
on general del
arbol de requisitos.
N
umero
1
1.1
1.1.1
1.1.2
1.2
1.2.1
1.2.2
1.2.3
2
2.1
2.2
2.3
2.4
2.4.1
2.4.2
2.4.3
2.5
2.5.1
2.5.1.1
2.5.1.2
2.5.2
2.5.3
2.5.3.1
3
Descripci
on
Establecer base de desarrollo
Integraci
on de un ordenador de a bordo
Sistema operativo en tiempo real
Elaboraci
on de un sistema de configuracion e inicializacion de servants
Desarrollo de tarjeta de alimentaciones
Los dispositivos se controlaran individualmente
Apagado manual de dispositivos
Apagado remoto de dispositivos
Integraci
on de sensores y actuadores
Uso de la tecnologa CORBA
Los objetos CORBA estaran disponibles cuando el dispositivo lo este.
Recuperar funcionalidades automaticamente.
Integraci
on de sensores propioceptivos
Integraci
on de una br
ujula electronica
Integraci
on de acelerometros
Integraci
on de sensores de tension e intensidad
Integraci
on de sensores exteroceptivos
Integraci
on de una camara direccionable
Integraci
on de la c
amara estereoscopica existente
Integraci
on de la mu
neca
Integraci
on del dispositivo laser
Integraci
on del receptor GPS
Integraci
on del sistema de correcion diferencial del GPS
Uso de est
andares y optimizacion en el desarrollo
Cuadro 2.1: Arbol

de requisitos resumido.
20
CAPITULO 2. REQUISITOS
2.1.
21
Definici
on de los requisitos
Esta secci
on contiene tablas para cada requisito ofreciendo descripciones mas especficas,
la importancia que tiene en el proyecto, el motivo por el cual es necesario y el metodo de
validacion que se deber
a usar para comprobar el cumplimiento del requisito. La numeracion
empleada describe la jerarqua de requisitos de manera que un requisito derivado describe
detalles del superior.
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
1
Establecer base de desarrollo
alta
Se establecer
a una plataforma base sobre la que desarrollar e integrar el
resto de componentes software y hardware.
Los m
odulos a desarrollar necesitan una base sobre la que funcionar.
Es posible desarrollar e integrar modulos en la plataforma robotica base.
1.1
Integraci
on de un ordenador de a bordo
alta
Se instalar
a un ordenador a bordo que ejecutara los servicios que el robot
ofrezca a clientes remotos.
Es necesario un sistema de procesamiento de informacion que entienda
los protocolos del entorno distribuido y adapte las se
nales de los dispositivos.
Se iniciar
a una sesion en modo consola remotamente desde otro ordenador.
1.1.1
Sistema operativo en tiempo real
media
El sistema operativo del ordenador de a bordo debera contar con capacidades de tiempo real
En la ejecuci
on de una tarea, las acciones que realiza un robot puede
ser inadecuado por realizarse mas tarde de lo debido. Los tiempos de
ejecuci
on de los procesos han de ser predecibles.
Se realizar
an pruebas especficas que confirmen el correcto funcionamiento de procesos en tiempo real usando las herramientas para tal fin del
que disponen los n
ucleos en tiempo real.
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
verificaci
on
n
umero
nombre
importancia
descripci
on
justificaci
on
verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
22
1.1.2
Elaboraci
on de un sistema de configuracion e inicializacion de servants
alta
Se crear
an los scripts y los archivos de configuracion necesarios para
que todos los m
odulos hagan uso de los mismos parametros y se facilite la configuraci
on com
un. El sistema de inicializacion de servants se
realizar
a usando las utilidades de arranque del sistema operativo.
Durante la experimentacion con el robot se realizaran cambios en la
configuraci
on que no deberan suponer mas esfuerzo que el cambio del
par
ametro en un solo punto del sistema.
Existir
a un
arbol de directorios desde el que se controlaran los parametros m
as importantes de configuracion de los servants.
1.2
Desarrollo de tarjeta de alimentaciones
alta
Se desarrollar
a una tarjeta que controle la alimentacion de los distintos
dispositivos que se instalen en el robot.
El consumo en vehculos autonomos debe reducirse si se quiere aumentar
la autonoma de las bateras. Se realizaran experimentos en los que los
dispositivos se apagan espontaneamente.
Los dispositivos se encenderan al accionar un interruptor en la tarjeta
de alimentaciones.
1.2.1
Los dispositivos se controlaran individualmente
media
La tarjeta se implementara con varios canales independientes que permitan el control individual de dispositivos a 12V y 24V.
Habr
a momentos durante la experimentacion con sistemas de control en
los que interese mantener en funcionamiento unos dispositivos y apagar
los dem
as.
Se podr
a apagar cada dispositivo individualmente dejando los demas
encendidos.
1.2.2
Apagado manual de dispositivos
media
Se podr
a apagar manualmente cualquier dispositivo en cualquier momento mediante interruptor.
Se realizar
an experimentos en los cuales se simula el fallo arbitrario de
dispositivos.
Se podr
a apagar cada dispositivo individualmente mediante interruptores f
acilmente alcanzables.
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
23
1.2.3
Apagado remoto de dispositivos
media
Se podr
a apagar remotamente cualquier dispositivo sin que sea necesario
intervenci
on humana alguna.
En determinadas situaciones es deseable apagar dispositivos no funcionales o de baja importancia para reducir el consumo.
Se cortar
a remotamente la alimentacion de cada dispositivo conectado a
la tarjeta de alimentaciones usando un programa que funcione autonomamente.
2
Integraci
on de sensores y actuadores.
alta
Se integrar
an los sensores y actuadores complementarios al robot base que permitan extender la funcionalidad del robot a navegacion en
interiores y exteriores.
Todo sistema de control requiere de entradas y salidas para ser funcional.
Se podr
a controlar remotamente cada dispositivo.
2.1
Uso de la tecnologa CORBA
alta
Se usar
a la tecnologa CORBA en todos los servicios que se publiquen
en el robot.
El est
andar CORBA es una tecnologa probada para la creacion de entornos distribuidos.
Se podr
an realizar todas las funciones del robot a traves de interfaces
CORBA ejecutadas remotamente.
2.2
Los objetos CORBA estaran disponibles cuando el dispositivo lo este.
alta
Cuando un dispositivo falle, el objeto CORBA correspodiente dejara de
estar disponible. Una vez vuelva a estar en funcionamiento el dispositivo,
los objetos CORBA deberan ser capaces de reiniciarse por s mismos.
Para considerar que un robot es autonomo y tiene capacidades de autocuraci
on no debe existir intervencion humana en los procesos de recuperaci
on de la funcionalidad.
Para cada dispositivo, el objeto CORBA debe dar error al apagar el
dispositivo y recuperar la funcionalidad original al encender de nuevo el
dispositivo, sin que haya manipulacion del ordenador de a bordo.
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
24
2.3
Recuperar funcionalidades automaticamente.
alta
El robot contar
a con capacidades para recuperar, sin intervencion del
operador, funcionalidades perdidas en los dispositivos.
Los m
odulos CORBA en funcionamiento moriran al apagar el dispositivo
correspondiente y se reiniciaran automaticamente cuando el dispositivo
vuelva a estar disponible.
2.4
Integraci
on de sensores propioceptivos
media
Se desarrollar
an e integraran sensores que permitan conocer el estado
interno del robot.
Se podr
a comprobar remotamente la salida de los sensores propioceptivos.
2.4.1
Integraci
on de una br
ujula electronica
media
Se desarrollar
a e integrara una br
ujula electronica.
La br
ujula electr
onica sirve como complemento de datos odometricos y
del receptor GPS para conocer la orientacion del robot.
Se podr
a comprobar remotamente la orientacion del robot respecto del
campo magnetico terrestre.
2.4.2
Integraci
on de acelerometros
baja
Se desarrollar
a e integrara un sensor que mida aceleraciones
Es posible que tanto en exteriores como en interiores el robot se desplace
por terrenos accidentados o inclinados. Los sistemas de control deben
estar al corriente de esta situacion para adaptarse mejor al entorno.
Se podr
a comprobar remotamente la inclinacion del robot en reposo
respecto de la vertical.
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
25
2.4.3
Integraci
on de sensores de tension e intensidad
media
Se desarrollar
a e integrara un sensor que mida el consumo y el nivel de
carga tanto de las bateras de la base robotica como de las bateras de
dispositivos.
Los sistemas de control deben estar al corriente de la salud de todos los
componentes del robot para preveer fallos por falta de energa.
Se podr
a comprobar remotamente la tension de las bateras y el consumo
instant
aneo.
2.5
Integraci
on de sensores exteroceptivos.
alta
Se desarrollar
an e integraran sensores que permitan conocer el entorno
del robot, tanto en exteriores como en interiores.
Un robot aut
onomo necesita conocer el entorno que le rodea para poder
manipularlo y desenvolverse en el.
Se podr
a comprobar remotamente variables asociadas al entorno del
robot.
2.5.1
Integraci
on de una camara direccionable
media
Se desarrollar
a e integrara un sistema de visionado que permita tomar
im
agenes y tomar datos de profundidad en todos los angulos.
La visi
on es uno de los sentidos mas complejos y a la vez mas u
tiles para
el control de robots en movimiento.
Se podr
a controlar remotamente la direccion en la que enfoca la camara
y recibir im
agenes de esta.
2.5.1.1
Integraci
on de la camara estereoscopica existente
media
Se integrar
a la c
amara estereoscopica que dispone el laboratorio en el
conjunto del robot.
Se podr
a capturar imagenes estereoscopicas remotamente.
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
N
umero
Nombre
Importancia
Descripci
on
Justificaci
on
Verificaci
on
26
2.5.1.2
Integraci
on de la mu
neca
media
Se desarrollar
a e integrara un sistema de movimiento de la camara utilizando el dispositivo powercube de dos grados de libertad que posee el
laboratorio.
Cumplimiento del requisito 2.5.1 sobre direccionamiento de la camara.
Se podr
a controlar remotamente la direccion a la que apunta la camara.
2.5.2
Integraci
on del dispositivo laser
alta
Se desarrollar
a e integrara un sistema de sensado de distancias en interiores a partir del dispositivo laser montado en el robot.
Es necesario un sistema de deteccion de obstaculos para la navegacion
en interiores.
Se podr
a comprobar remotamente la lectura de las distancias a objetos
pr
oximos.
2.5.3
Integraci
on del receptor GPS
alta
Se desarrollar
a e integrara un sistema de recepcion de posicion en exteriores basado en el receptor GPS existente.
Es necesario un sistema de localizacion para navegacion en exteriores.
Se podr
a comprobar remotamente la posicion y velocidad del robot.
2.5.3.1
Integraci
on del sistema de correcion diferencial del GPS
baja
Se montar
a una estacion base para la lectura y envo por radio de correcciones diferenciales basado en el receptor GPSd existente.
Es preferible que el sistema de localizacion tenga una buena precision
en la posici
on.
Se podr
a comprobar remotamente la posicion del robot en exteriores con
un error menor a medio metro.
3
Uso de est
andares y optimizacion en el desarrollo
media
Se har
a uso de herramientas y normas estandar donde sea posible. Donde
no existan normas estandar se unificara en libreras y scripts comunes a
todos los m
odulos el codigo que sea posible compartir.
El desarrollo se facilita con el uso de estandares y se asegura la continuidad a medio-largo plazo.
El uso de software propietario se limita a lo estrictamente necesario.
2.2.
27
Vista general del proyecto
En la figura 2.1 se da una visi

on general del proyecto. Se ha separado en dos bloques, la
parte software y la parte hardware. La parte software esta desarrollado con las utilidades,
libreras y scripts que se crear
an y compondran el entorno de desarrollo, que no interviene
durante la operaci
on del robot. La parte software necesita un sistema operativo sobre el que
ejecutar y poder comunicarse con el hardware; tambien se implantara como parte del proyecto.
Sistema desarrollado
Plataforma Robtica
Mdulos Software
Entorno de
desarrollo
Sistema Operativo
Componentes
Hardware
Figura 2.1: Vista general del proyecto.
Captulo 3
Sistema de partida
El desarrollo del robot ha sido una constante evolucion y lo seguira siendo, incorporando
nuevos dispositivos a medida que aparezcan y las necesidades as lo soliciten, y adaptando
las tecnologas que surjan para un mejor aprovechamiento de las capacidades del robot. Por
ello, este proyecto no parte desde cero, sino que existe una base desde la cual se han ido
desarrollando otros proyectos y que han ido completando el robot.
Este captulo describe los dispositivos que ya estan adquiridos, que se ha desarrollado con
ellos antes del inicio de este proyecto y que nivel de integracion cuentan en el conjunto del
robot.
3.1.
Descripci
on del robot base
La plataforma rob
otica m
ovil que se ha tomado como base es un robot Pioneer 2-AT8 de
la casa mobilerobots. Este robot ha sido ampliamente utilizado durante la u
ltima decada por
laboratorios de investigaci
on en todo el mundo Sus caractersticas principales son:
Cuerpo robusto en aluminio.
Robot tipo (2,0)1 con 4 ruedas controladas con regulador.
Microcontrolador H8S integrado. Interfaz por puerto serie.
Bateras de
acido-plomo integradas, accesibles por compuerta en parte trasera.
16 sensores de proximidad por ultrasonidos, distribuidos por el permetro del robot.
Dimensiones 500x490x240 mm
Peso 15Kg
Ademas del robot base se ha incluido una estructura en su parte inferior con sensores
de contacto que detienen el robot, como medida de seguridad ante posibles choques. Esta
estructura sobresale por la parte anterior y posterior y tambien protege las ruedas.
Al comienzo de este proyecto la base robotica se encontraba plenamente operativa e integrada en el conjunto. El software para controlarlo estaba bien implementado y todas las
1
Seg
un la clasificaci
on de robot propuesta en [4]
28
CAPITULO 3. SISTEMA DE PARTIDA
29
Figura 3.1: La plataforma robotica de investigacion tomada como base.

funciones estaban disponibles a traves de una interfaz CORBA2 que mapeaba las funciones
de la biblioteca ARIA destinadas a este robot, incluyendo el movimiento del robot, la lectura
de los ultrasonidos y la lectura de los sensores de contacto. Este proyecto se desarrollo en [16].
Existe una rutina de comprobaci
on en el servant CORBA por el cual hace que el robot emita
sonidos caractersticos cuando la inicializacion ha sido correcta y esta preparado para recibir
ordenes. La publicaci
on en el servidor de nombres tambien estaba implementada.
3.2.
Descripci
on de la mu
neca
La mu
neca consiste en un actuador robotizado de dos grados de libertad. El dispositivo
que cumple esta funci
on ya est
a disponible y montado sobre el robot, y se trata del modelo
PW-070 del fabricante SCHUNK. El cableado estaba pendiente de integrar en el robot.
El software existente para controlar este dispositivo se encontraba parcialmente desarrollado. Era posible enviar
ordenes de movimiento sencillas de manera poco estructurada, desde
un ordenador conectado directamente por puerto serie. No exista servant CORBA ni interfaz
definida.
El protocolo est
a descrito en el manual correspondiente que puede encontrarse en el subdirectorio doc dentro
arbol de directorios del codigo fuente de la mu
neca, en el repositorio
SVN. Resumiendo, se trata de un protocolo cliente-servidor en el que la mu
neca act
ua como
servidor, tanto para recibir los comandos de movimiento como para enviar datos relativos a
su estado interno, como temperatura y consumo instantaneo.
3.3.
Descripci
on de la c
amara
La camara estaba preparada y montada sobre la mu

neca. A pesar de usar una interfaz
FireWire, la alimentaci
on de la c
amara es independiente y el cableado estaba pendiente de
integrar, es decir, que tan s
olo estaba resuelto la conexion a ordenadores de sobremesa para
trabajar con la c
amara desmontada.
2
Se da una descripci
on somera de esta tecnologa en la secci
on E
30
Figura 3.2: La mu
neca usada en el movimiento de la camara.
El servant CORBA estaba programado y funcionando. Esta basado en un driver para
linux realizado en el laboratorio para esta aplicacion con soporte para la captura sncrona
de ambos sensores y m
ultiples resoluciones. El envo de los datos de la imagen se realiza por
peticion de cada frame por parte del cliente a traves de una llamada CORBA. Los datos
se envan encapsulados en el protocolo CORBA sin comprimir, con codificacion YUV que el
cliente deber
a convertir a RGB.
El mayor inconveniente de este modulo es que el ancho de banda necesario para enviar los
datos sin comprimir es muy alto. No tiene importancia cuando el cliente y la camara estan en
el mismo ordenador, pero cuando los datos han de enviarse inalambricamente para cumplir
con los requisitos del proyecto se consume toda la capacidad de la red existente, aumentando
las latencias de otras llamadas CORBA, y siempre que se usen resoluciones bajas. Para las
resoluciones m
as altas el m
odulo no es usable: latencias de varios segundos y refrescos muy
bajos.
3.4.
Descripci
on del sistema l
aser
El sistema de detecci
on de obst
aculos principal consiste en el sensor laser SICK LMS200,
con capacidad para la lectura de distancias basado en el tiempo de retorno de un haz de luz
laser, desde 8mm hasta 80m. Cuenta con tres parametros principales configurables:
1. Resoluci
on y distancia m
axima. Se puede configurar entre una resolucion de 1mm y
distancias de hasta 8m o una precision de 1cm y distancias de 80m.
2. Angulo
de barrido. Seleccionable entre 180y 100.
3. Resoluci
on angular. Las opciones son 0,25, 0,5y 1, siendo la primera usable u
nicamente
para barridos de 100.
31
Figura 3.3: Camara estereoscopica
Figura 3.4: El sensor laser SICK LMS200

El u
ltimo par
ametro configurable, no relacionado con el funcionamiento del laser, es la
velocidad de comunicaci
on por el puerto serie. Puede seleccionarse entre 9600bps, 19200bps
y 38400bps en el modo RS-232, y tambien 500000bps en el modo RS-422. La seleccion del
modo se realiza empezando la comunicacion a la velocidad de 9600bps, ya sea RS-232 o RS422, y enviando el comando apropiado para cambiar la velocidad a la deseada. Si con los
parametros elegidos, tambien configurable mediante comandos, la velocidad del puerto serie
no es suficiente para enviar todos los datos de las distancias, se pierde el u
ltimo barrido.
El sensor dispone de dos entradas con proteccion contra polvo y agua, La primera de ellas
es el suministro de alimentaci
on a 24V y la segunda de ellas es la conexion del puerto serie,
ya sea RS-232 o RS-422. Tal como queda indicado en el manual, la seleccion entre ambos
protocolos se realiza cortocircuitando dos terminales en el interior de la caja de conexiones
de la entrada del puerto serie.
32
El manual del l
aser y el protocolo que sigue se puede encontrar en el directorio del codigo
fuente del m
odulo. Existe un m
odulo CORBA realizado en el proyecto fin de carrera [11]
que hace uso de la librera ARIA, esta limitado a las necesidades del citado proyecto y no
esta integrado con el resto del robot.
3.5.
Descripci
on del sistema GPS diferencial
El sistema GPSd es uno de los menos desarrollados. Los componentes hardware fueron
adquiridos en el a
no 2007 y se trata del model OEMV-2-RT2 compuesto por una estacion
base emisora de correcciones diferenciales y una estacion movil.
Al inicio del proyecto los componentes del GPS se encontraban almacenados en el maletn
original y se hicieron algunas pruebas infructuosas para tratar de recibir la posicion, usando
para ello un terminal serie conectado al receptor y comandado mediante ordenes manuales
sencillas. Est
a pendiente el desarrollo del modulo CORBA, el driver de conexion, pruebas de
funcionamiento y la integraci
on.
Figura 3.5: Componentes que forman el sistema GPS de la estacion movil

La estaci
on base est
a compuesta por una caja de control en la que se procesan las se
nales
recibidas de los satelites. Tiene dos conectores coaxiales, el primero de ellos e la entrada del
oscilador de alta precisi
on que no se usara, y el segundo es donde debe conectarse la antena
que ira situada en la parte m
as elevada del robot. La parte frontal consta de cuatro conectores
para puerto serie, de los cuales el etiquetado como COM1 se usa como interfaz de conexion
con el ordenador de a bordo y COM2 para recibir las correcciones diferenciales de la radio.
La radio es el cilindro azul en el que se colocara la antena correspondiente. Consta de un
solo conector del que parte un cable que separa la se
nal de datos y la alimentacion. La radio
esta alimentada con una batera propia. Esta batera tiene ademas su propio cargador.
El sistema GPS de la estaci
on base es muy parecido al de la estacion movil. Se compone
de una caja de control con la electronica, exactamente el mismo hardware pero con una
(a)
33
(b)
(c)
Figura 3.6: La antena, radio y caja de control de la estacion movil del GPS.
configuraci
on software distinta, una antena de mayores dimensiones y una radio con una
potencia de emisi
on de 2W. El resto de componentes son iguales.
Figura 3.7: Componentes de la estacion base del sistema GPS

Existe una antena GPS instalada en el atico del departamento de automatica. Su localizacion se puede ver en la figura 3.8. De el cae un cable coaxial por la fachada del edificio que
permite instalar los componentes de la estacion base en el interior del edificio.
3.6.
Descripci
on de la tarjeta de adquisici
on de datos
El robot cuenta con diversos sensores y actuadores que no son directamente conectables
a un puerto serie o cualquier otra interfaz de conexion con una computadora moderna. La
tarjeta de adquisici
on de datos viene a suplir esta necesidad de conectar dispositivos sencillos
con el ordenador de a bordo.
La funcionalidad de la tarjeta de adquisicion de datos esta dividida dos partes. La primera
de ellas reside en el ordenador de a bordo y se encarga de mediar entre la interfaz CORBA
existente y el puerto serie con el que se comunica con la tarjeta, y la segunda es la tarjeta de
adquisicion de datos y el firmware desarrollado en sincrona con el servant.
34
Figura 3.8: Localizaci

on de la antena GPS en el atico del departamento.
El servant CORBA est
a desarrollado en Java y dispone de una interfaz grafica por la que
se pueden visualizar todas las variables cuyo valor se reciba desde la tarjeta. Asimismo estas
variables se pueden observar a traves de la interfaz CORBA. La version inicial de este modulo
se desarroll
o en [15].
La tarjeta de adquisici
on de datos es una tarjeta Arduino Mega que usa el microcontrolador
Atmel Mega 1260. Se trata de una tarjeta debajo coste dise
nada para desarrollos rapidos
que incorpora su propio entorno de desarrollo basado en la herramienta processing e incluye
libreras que evitan tener que programar en ensamblador para acceder a las funciones basicas
de entrada y salida del microcontrolador.
A continuaci
on se describen el acelerometro y la br
ujula electronica, que estan pendientes
de implantar.
3.6.1.
Aceler
ometro
El aceler
ometro es una tarjeta con dos sensores de aceleracion monoaxiales independientes, dispuestos perpendicularmente. Parten dos cables con alimentacion y datos para cada
acelerometro, como se muestra en la figura 3.9. Su salida es analogica.
Es necesario probarlo e integrarlo en el conjunto del robot.
3.6.2.
Br
ujula electr
onica
La br
ujula electr
onica usada en este proyecto es una peque
na tarjeta autocontenida con
un microcontrolador Microchip que procesa la informacion recibida de dos sensores Philips
unidireccionales de campo magnetico situados perpendicularmente, tal que la salida de la
tarjeta es una se
nal PWM proporcional al angulo respecto al norte magnetico. Cuenta con
compensaci
on del campo magnetico creado por la corriente electrica del cableado de los edificios con opci
on de configurarlo a 50Hz o a 60Hz y de un terminal de inicializacion que solo
35
Figura 3.9: Detalle del acelerometro.

ha de emplearse en el primer uso o cuando haya cambios de localizacion importantes, para
ajustarse a los nuevos niveles de campo electromagnetico terrestre.
Figura 3.10: Detalle de la br

ujula electronica.
3.7.
Descripci
on del ordenador de a bordo
El ordenador de a bordo es un portatil marca Sony y modelo Vaio TX2HP. Sus caractarsticas son:
Intel Pentium M a 1,1GHz.
512MB de memoria SDRAM.
80GB de disco duro a 4200rpm.
Pantalla LCD de 11,1".
DVD+RW
Los puertos de los que dispone son:
2xUSB
FireWire
36
Ethernet 100Mbps
Wifi IEEE 802.11b/g
Bluetooth
Tiene instalado un sistema operativo Fedora Linux desde el que se han hecho pruebas con
algunos dispositivos pero sin llegar a funcionar autonomamente, es decir, que los servants
y los programas se han ejecutado manualmente y el ordenador no se ha llegado a integrar
adecuadamente con el resto de componentes del robot.
3.8.
Descripci
on del entorno de red del laboratorio
El laboratorio dispone de una red propia con servidores de distinto tipo. Los servicios m
as
importantes que se han usado a lo largo de este proyecto, junto con una breve descripcion del
uso que se ha hecho de ellos se expone a continuacion:
NIS Identificaci
on por contrase
na en los ordenadores. El laboratorio esta dispuesto tal que
cualquier usuario puede usar cualquier ordenador y encontrarse en el la misma configuraci
on con la que abri
o sesi
on por u
ltima vez, aunque fuera en otro ordenador. El
mantenimiento de las contrase
nas se puede realizar as desde un u
nico punto para todos
los usuarios.
NFS Net File System, o sistema de archivos en red. Se trata de un disco duro virtual situado
remotamente. Es un servicio complementario a NIS por el cual se pueden almacenar
los archivos personales en el servidor principal. Permite abrir sesion con los archivos
personales disponibles en cada ordenador. La tarea de realizar las copias de seguridad
para todos los miembros del laboratorio se automatiza facilmente y, al tener el servidor
un sistema RAID con discos duros extrables en caliente se mejora la seguridad de los
datos.
CVS Sistema de control de versiones. Utilizado inicialmente para ir almacenando las diferentes versiones del software desarrollado as como los archivos de dise
no del hardware,
en su evoluci
on. Tambien usado para compartir el codigo con el resto del laboratorio.
SVN Equivalente a CVS pero m
as moderno. Se describe en detalle en el anexo E.
SSH Secure SHell. Programa con interfaz en modo texto que abre consolas en otros ordenadores remotamente. Ha sido utilizado para coordinar comodamente todos los ordenadores
con los que se ha trabajado simultaneamente.
Existe un punto de acceso wifi con ESSID aslab wireless necesario para las comunicaciones
inalambricas con el robot.
Captulo 4
Dise
no hardware
En este captulo se describir
a el proceso seguido para el dise
no del hardware. No todo
el robot ha sido dise
nado, sino que una parte estaba ya montado y funcionando, aunque sin
robustez ni integraci
on adecuadas, otra parte son elementos adquiridos pero no montados
sobre el robot, y algunos componentes han tenido que dise
narse desde cero.
4.1.
Dise
no de la tarjeta de alimentaciones
4.1.1.
An
alisis de los requisitos
En esta secci
on se va a analizar el requisito 1.2. Una de las condiciones que debe cumplir el
robot movil es, como ya se ha comentado en el capitulo 2 relativo al analisis de requisitos, es
que pueda continuar operando con normalidad aunque no todos sistemas esten en funcionamiento. El caso tpico sera aquel en el que el robot se pone en marcha con todos los sistemas
operando correctamente y con el transcurso del tiempo y de la mision asignada, ciertos componentes dejen de responder bien sea por avera o por cualquier otra cosa. Por ejemplo, una
mision en la que el robot m
ovil deba desplazarse por interiores y por exteriores necesita de
sensores de proximidad, en este caso el laser, en el interior del edificio que le ayude a reconocer
las habitaciones, mobiliario y obst
aculos, y otro sensor totalmente distinto para exteriores,
en este caso el GPS. En interiores el GPS no es funcional debido a la mala recepcion de las
se
nales electromagneticas enviadas por los satelites, y en exteriores el sensor de proximidad
u
nicamente valdra para la detecci
on de obstaculos, no as la localizacion por mapas ya que
en exteriores no hay paredes ni mobiliario y el sensor tiene un rango maximo de deteccion de
objetos de unos ocho metros ( u ochenta metros, dependiendo de la configuracion). En ambos
casos, exterior e interior, los sensores dejan de aportar informacion u
til por lo que siempre
habra alg
un sensor que no pueda ser usado para recabar informacion del entorno y que sin
embargo siguen consumiendo energa y reduciendo la carga de las bateras del robot. Seria
conveniente poder apagar estos sensores para aumentar el tiempo de operacion del robot sin
necesidad de recargar.
Por lo tanto, los requisitos principales que debe reunir la tarjeta de alimentaciones es que
sea capaz de gestionar la alimentaci
on de cada uno de los sensores y actuadores por separado
de dos maneras distintas. Una automatica, controlada por ordenador, en la que se pueda
apagar remotamente los sistemas para ahorrar energia independientemente de si en el punto
remoto esta trabajando un operador humano o es una arquitectura cognitiva que decide que el
37
HARDWARE
CAPITULO 4. DISENO
38
sistema en cuesti
on no es u
til en ese momento, y otra manual que haga las veces de simulador
de fallos en los sistemas.
Desconexi
on autom
atica
Para el metodo autom
atico, se necesitara un medio que conecte la tarjeta de alimentaciones
con la tarjeta de adquisici
on de datos en la que cada una de las lineas controle digitalmente
la tension de cada sistema, que se llevara a los pines digitales de entrada y salida generales
de la tarjeta de adquisici
on de datos. Sera responsabilidad de la tarjeta de adquisicion de
datos la que, a traves de la conexi
on USB con el ordenador de a bordo, suministre las se
nales
adecuadas para el correcto control del apagado automatico de cada uno de los canales. El
requisito 1.2.3 estara resuelto.
Desconexi
on manual
Por otra parte tambien se desea simular la avera de los sensores para que el software
de control que opere el robot pueda ser probado ante estas eventualidades sin tener que
provocar una avera real sobre los sistemas. Muchas veces estas averas se dan de forma
intermitente y el robot debe ser capaz de recuperarse de ellas una vez el sistema afectado
vuelve a estar disponible. Tal es el caso en el que un cable defectuoso queda a circuito abierto,
por problemas en el conector o incluso por problemas de los conductores del cable mismo,
bajo determinadas condiciones, como por ejemplo cuando la temperatura ambiente supera
un cierto umbral, digamos 30 . La condicion de fallo de este ejemplo se dara u
nicamente
en verano y en exteriores. El robot, una vez han desaparecido las condiciones de fallo, debe
restablecer el sistema. La mayor dificultad sera pues que el software del sistema tolerara
estos fallos y tuviera una cierta capacidad de auto-curacion, problema que se afrontara en
el captulo 6, y para poder probar este software se requiere poder simular los fallos. En este
proyecto la simulaci
on de estos fallos se va a limitar al apagado manual arbitrario de sistemas
individuales, suponiendo que si un sistema esta operativo entonces interactuara con el entorno
de una manera correcta y fiable, cumpliendo con el requisito 1.2.2. Otro ejemplo sera el de
un actuador que se sobrecalienta y se avera, se le ordenara moverse pero los sensores no
registrasen los datos que se esperara si el actuador se hubiera realmente movido.
Otras consideraciones
Para el metodo manual se facilitara un interruptor por cada dispositivo. Adicionalmente
habra un interruptor general que controle la alimentacion de todos los sistemas y reduzca
efectivamente, con corriente consumida nula o despreciable, el gasto de carga de las bateras
cuando el robot no este en uso. Tambien sera necesario instalar un conector de alimentacion
estandar power jack que cargue las bateras aunque el interruptor general este apagado.
Algunos de los dispositivos funcionan a 24V, mientras que las baterias aportan una tension
nominal de 12V, que en la practica es variable entre 10,5V y 13.5V. Existe un convertidor
12VDC/24VDC instalado en la parte frontal de la base del robot que tambien debera ser
controlado por la tarjeta de alimentaciones de modo que este apagado cuando no haya dispositivos de 24V en funcionamiento y as reducir el consumo ya que este convertidor tiene un
consumo fijo de 6W incluso cuando no existe consumo electrico en los 24V.
Por tanto, cada sistema estar
a controlado por un canal con dos metodos distintos de
apagado, digital y con un interruptor, configurados como una AND logica, es decir, que el
HARDWARE
CAPITULO 4. DISENO
Tension de bobina
Corriente nominal maxima
Configuraci
on de los contactos
Resistencia de contacto
Resistencia de bobina
Referencia del fabricante
39
12VDC
5A
DPST-NO
30mW
480W
G6B-2214P-US 12DC
Cuadro 4.1: Caractersticas principales del rele usado en la tarjeta de alimentaciones
sistema estar
a encendido solamente si ambos metodos permiten simultaneamente el encendido
del sistema. Existir
an tantos canales como sistemas haya, mas algunos de reserva para futuras
ampliaciones del robot con nuevos dispositivos. Cada canal debera contar con un indicador
luminoso que indique la existencia de tension en el conector de salida de la tarjeta de alimentaciones de cada canal y un indicador luminoso que facilite la comprobacion de encendido de
la tarjeta. Con este desarrollo se cumplira tambien el requisito 1.2.1.
4.1.2.
Dise
no electr
onico y selecci
on de componentes
En esta secci
on se describe el proceso para la seleccion cualitativa de los componentes
y los calculos matem
aticos para obtener los valores cuantitativos de los componentes que lo
requieran.
Selecci
on del interruptor electr
onico
En la selecci
on del dispositivo de interrupcion electronica se ha descartado el uso de
transistores y otros componentes semiconductores debido a la cada de tension entre sus
terminales, de unos 0,6V, y que resulta inaceptable para muchos de los dispositivos cuando
la carga de las bateras se reduce, al imponer una reduccion en la tension de la alimentacion
aun mas baja y restringiendo el mnimo de carga necesaria para que contin
ue operando.
Finalmente se opt
o por el uso de reles. Estos dispositivos electromecanicos ofrecen una
cada de tensi
on despreciable aunque la velocidad de conmutacion es baja, del orden de
10Hz. Esto no es un problema ya que la frecuencia de conmutacion del rele debe estar por
debajo del tiempo de inicializaci
on de los dispositivos que alimenta. A modo de ejemplo, el
sensor laser tarda de media unos 40 segundos en inicializarse, mas el tiempo que dura la
sincronizaci
on y la inicializaci
on del software controlador. El rele debe ser capaz de soportar
la corriente del dispositivo de mayor consumo, que se ha analizado en parrafos anteriores y
corresponde a los 4A de la mu
neca, la bobina debe funcionar a 12V y debe disponer de dos
contactos normalmente abiertos, uno para controlar el dispositivo en si y otro para desconectar
el convertidor 12VDC/24VDC en los canales de 24V. Se usara el mismo rele para todos
los canales. Las caractersticas principales del rele seleccionado se muestran en la tabla 4.1.
Se trata de un rele subminiaturizado de dos polos y un terminal por polo con contactos
normalmente abiertos.
De la tabla de datos se deduce que la cada de tension maxima que sufrira el rele en el
peor de los casos es de 4A 30mW = 0, 12V .
HARDWARE
CAPITULO 4. DISENO
40
Dise
no del circuito de control del rel
e
La bobina de activaci
on del rele no es tan sensible a variaciones de tension como lo son los
dispositivos y es posible controlarlo con un transistor. Se ha usado un transistor de proposito
general NPN en serie con la bobina. Ver la figura A.1. La base del circuito estara controlado
por una fuente de corriente continua formada por la fuente de 12V y una resistencia que
realice simult
aneamente la funci
on de resistencia pull-up, siendo el resto de componentes los
que desvan la corriente de base del transistor hacia tierra sin pasar por este, cuando se quiere
tener el dispositivo apagado, bien sea con el metodo automatico o con el manual. El metodo
automatico dispone de un diodo que evita que el microcontrolador que se encuentra al otro
lado pueda suministrar la tensi
on de polarizacion al transistor, es decir, que solo podra forzar
la base del transistor a 0V. Sucede que las cadas de tension propias del microcontrolador
y de este u
ltimo diodo son mayores que la cada de tension base-emisor del transistor, de
ah la colocaci
on del diodo zener de tension de polarizacion inversa de 2,4V que invierta esta
situacion. El valor de la resistencia esta dise
nada teniendo en cuenta esto y la del transistor.
Para el metodo de apagado manual se ha dispuesto un interruptor con un condensador en
paralelo que elimina el efecto rebote del interruptor y ayuda a alargar la vida u
til del rele.
Finalmente el transistor est
a protegido contra sobretensiones con un diodo en paralelo con la
bobina.
Por aplicaci
on de la ley de ohm a las caractersticas del rele, la corriente necesaria para
su activaci
on, y sabiendo por las especificaciones que necesita un mnimo de tension del 70 %
del nominal que se va a cumplir incluso en condiciones de baja carga, es
12V
= 25mA
480mW
(4.1)
A esta corriente de colector, la del transistor esta situada entre 60 y 100.

25mA
= 0, 41b
6mA
60
(4.2)
Aplicamos un margen de seguridad aproximando la corriente de base a 0,9mA, y la resistencia

de pull-up limita la corriente con un valor de
12V 2, 4V 0,7V
= 9, b
8k W 10k W
0, 0009A
(4.3)
Las resistencias limitadoras de corriente para los LED indicadores:

Vcc VLED
12V 2, 5V
24V 2, 5V
=
' 1k W;
' 2, 2k W
ILED
10mA
10mA
(4.4)
Para terminar, la constante de tiempo en el condensador, que ha sido validado por estimacion,
queda:
= 10k W 1, 5F = 15ms
(4.5)
mas que suficiente para eliminar el efecto rebote.
Resto de componentes
El n
umero de canales que se van a implementar son nueve: seis de ellos con tension de
alimentaci
on a 12V y el resto a 24V. La distribucion elegida para los dispositivos es la que se
HARDWARE
CAPITULO 4. DISENO
Canal
1
2
3
4
5
6
7
8
9
Tensi
on
12V
12V
12V
12V
12V
12V
24V
24V
24V
Dispositivo
Reserva
Sensores4
Servo
Reserva
Camara
GPS
Mu
neca
Laser
Reserva
41
Consumo (en A)
0,3
1,5
0,083
0,5
3
0,7
Cuadro 4.2: Distribuci

on de dispositivos por canales en la tarjeta de alimentaciones
muestra en la tabla 4.2. Se ha resuelto dejar dos canales de reserva en el canal a 12V y uno
en el que va a 24V.
En cuanto al dise
no de las pistas, la separacion mnima entre pistas viene fijado por
la diferencia de potencial m
axima que es de 24V,que se corresponde a una separacion de
0,3mm. El grosor de las pistas viene condicionado por la corriente que transportan, siendo
las mayores las de los conmutadores de los reles. Se acepta un incremento de temperatura
admisible m
axima de 30. Para un grosor de cobre de 35, el ancho de pista que soporta
una corriente de 1A es de 0,45mm. Se ha tenido en cuenta que no todos los dispositivos usan
el maximo de corriente de 4A por canal, y que los dispositivos de 24V consumen el doble
de corriente en la parte de 12V antes de la conversion a 24V. Un ancho de 1cm soporta
as 22,7A que es aproximadamente la corriente maxima consumida por todos los dispositivos
en funcionamiento.
La conexi
on con la tarjeta de adquisicion de datos se realizara mediante cable plano, que
re
una en un solo cable los 9 canales y la conexion a tierra. La tarjeta de adquisicion de datos
dispone de una serie de pines digitales de entrada/salida general con disposicion identica a
la de cable plano, circunstancia que se aprovechara para facilitar la conexion. Los esquemas
electronicos y la distribuci
on de pistas, serigrafa y orificios se pueden encontrar en el anexo
A.
4.1.3.
Fabricaci
on y complicaciones surgidas
Circuito impreso
El dise
no finalizado se export
o a archivos gerber, que es el formato mas aceptado entre los
fabricantes de circuitos impresos. Estos archivos se pueden encontrar en formato comprimido
dentro del directorio Power_Board/OrCAD del cede del proyecto. Se solicito presupuesto para
la realizaci
on del prototipo a las empresas detalladas en la tabla 4.3.
Las ofertas detalladas de estos presupuestos remitidas por los fabricantes se encuentran en
el cede que acompa
na este proyecto. Cabe destacar los siguientes factores a la hora de elegir
el fabricante:
El plazo de entrega deba ser lo mas corto posible sin que se dispare el precio por
urgencia. Tras recibir los presupuestos el plazo mas razonable con todos los fabricantes
result
o ser de 5 das.
HARDWARE
CAPITULO 4. DISENO
Empresa fabricante
FAST PCB
2CI
ELATE
NOVATEK
LAB CIRCUITS
42
Presupuesto
308,00
202,87
280,88
251,76
335,00
Cuadro 4.3: Listado de presupuestos para la fabricacion del circuito impreso de la tarjeta de
alimentaciones.
El espesor de cobre base debe ser mayor que el estandar para soportar las altas corrientes
que se esperan. El espesor base estandar es de 18, existiendo ofertas de 35 e incluso
70.
Se tomar
a en consideraci
on el color del acabado de la tarjeta por motivos esteticos,
siendo preferible el azul que es el color de la tarjeta de adquisicion de datos. No obstante
seguir
an teniendo m
as peso los motivos economicos.
El circuito impreso ser
a de clase 3, que es la de menor calidad que com
unmente realizan
los fabricantes.
Los fabricantes exigen un mnimo de dos a cuatro tarjetas en la fabricacion del prototipo.
No se tendr
a en cuenta el precio por tarjeta del presupuesto, sino el precio global ya
que el prototipo ser
a tambien el circuito impreso final que se usara en el robot.
Una vez analizados los presupuestos se opto por aceptar la oferta de 2CI. Los dos principales motivos fueron el coste y la calidad percibida. Las caractersticas mas relevantes del
circuito impreso se exponen a continuacion:
Grosor de cobre: 35.
Color de m
ascara: Azul. Blanco para la serigrafa.
Plazo de entrega 5 das
Dos capas clase 3.
Grosor del material base 1,6mm de material FR4 (fibra de vidrio con resina epoxi).
Montaje de componentes
Recibidos los tres prototipos del circuito impreso se procedio a montar y soldar los componentes previamente pedidos. La lista de componentes, Bill Of Materials, se muestra en el
cuadro 4.4. Se ha a
nadido la referencia de la tienda online RS-Amidata para cada componente.
El montaje y soldadura de los componentes se realizo manualmente con herramientas
pertenecientes al grupo de investigaci
on. Durante el montaje se encontraron algunos problemas
y fallos de dise
no que pudieron resolverse sin necesidad de encargar mas circuitos impresos,
pero que habr
a que tener en cuenta y redise
nar el circuito impreso si se da el caso de tener
que fabricarlo de nuevo:
HARDWARE
CAPITULO 4. DISENO
Cantidad
9
1
9
12
9
9
1
10
9
1
3
7
9
18
3
20
1
Referencia RS
332-818
317-695
294-312
670-5715
544-3503
188-3036
542-8784
466-4260
369-781
487-836
131-299
131-255
131-378
628-9029
426-3722
679-5776
172-9134
43
Descripcion
Right angle small switch
Right angle switch with lever
Low signal NPN transistor
MiniFit connector, male PCB
Zener diode 2V4
Capacitor, 1,5uF electrolythic
Ribbon connector 10way PCB header
Right angle LED
DPST Relay
Power Jack connector, male PCB
Resistor 2K2
Resistor 1K
Resistor 10K
1N2004 Diode
Ribbon 10way plug
MiniFit connector, female plug
MiniFit connector, bag with 100 terminals
Cuadro 4.4: Listado de componentes de la tarjeta de alimentaciones.
1. Los orificios para los pines de los reles presentan una separacion excesiva. Ademas, los
dos pines correspondientes a la bobina estan invertidos, fallo que no se encontro por
situar casualmente los pines con la polaridad adecuada durante las pruebas iniciales y
por no estar suficientemente documentado en la hoja de especificaciones del rele. Se
solucion
o separando manualmente los pines antes de montarlos sobre las tarjetas y extendiendo los pines de la bobina e intercambiandolos, usando pegamento termoadhesivo
como aislante. Adem
as, debido al debilitamiento de los pines con su manipulacion, se
reforz
o la sujeci
on del rele a la tarjeta con adhesivo.
2. El conector de carga de la batera tiene desconectado el pin de tension positiva. Se
resolvi
o creando un puente de esta
no con la pista adecuada.
3. Los orificios de los diodos 1N4004 son de tama
no insuficiente. Se aumento el tama
no
con una taladradora que destruyo la capa de cobre pasante, por lo que hubo que soldar
estos componentes por ambas caras del circuito impreso.
4. La serigrafa del conector 24VIN es incorrecta y esta marcado como 12VIN que queda
duplicado. De ambos, es el conector mas alejado del cable plano el que se marco con
tinta indeleble la marca correcta 24VIN.
El resultado final con la localizacion de conectores e interruptores se muestra en la figura
4.1.
HARDWARE
CAPITULO 4. DISENO
Figura 4.1: Fotografa de la tarjeta de alimentaciones montada sobre el robot.
44
HARDWARE
CAPITULO 4. DISENO
4.2.
Dise
no del sensor de corriente y tensi
on
4.2.1.
An
alisis de requisitos
45
En general un robot cuenta con sensores que captan informacion del entorno pero tambien
cuenta con otros sensores que reciben informacion sobre el estado del propio robot, de esta
manera los algoritmos pueden adaptar sus resultados para obtener la mejor solucion teniendo en cuenta no solamente el exterior sino las funciones internas, descalibraciones y otras
desviaciones de la idealidad. El sensor de corriente y tension esta pensado para satisfacer
esta necesidad en cuanto se refiere a la cantidad de energa que a
un puede usar el robot y el
consumo actual, tal como se ha indicado en el requisito 2.4.3.
Existen cuatro bateras independientes en el robot movil, cada uno alimentando una serie
de sistemas distintos.
Bateras de motores Alimentan el robot base, incluyendo los motores, el controlador interno y los sensores s
onar.
Bateras de instrumentaci
on Alimentan los dispositivos montados sobre el robot base.
La distribuci
on de las alimentaciones esta gestionada por la tarjeta de alimentaciones.
Incluye L
aser, GPS, mu
neca, etc.
Batera del ordenador de a bordo Esta integrada en el ordenador de a bordo e incorpora
su propio sistema de gesti
on de bateras, accesible desde el sistema operativo.
Batera de la radio del GPSd Alimenta el receptor de radio del GPS diferencial.
Se van a monitorizar las tres primeras bateras. La cuarta presenta las siguientes caractersticas
que desaconsejan su monitorizaci
on, pues a
nadira complejidad al sistema sin que sea una
informacion suficientemente u
til: Se trata de un sistema propietario cerrado con cables y
conectores dedicados, la duraci
on de la carga es de un orden de magnitud mayor que el resto
de bateras en el robot y la perdida de la radio del GPS implicara u
nicamente la reduccion
en la precisi
on de la posici
on en exteriores.
La batera del ordenador de a bordo puede ser monitorizada por el n
ucleo del sistema
operativo y no necesita ning
un circuito adicional; Las bateras de los motores y de la instrumentacion son muy parecidas diferenciandose en la potencia que deben aportar, siendo en el
caso de los motores de hasta 17A y en el de la instrumentacion de hasta 6A (ver cuadro 4.2).
Ambas bateras son de plomo y
acido compuestas por tres celulas de 7A h cada una.
4.2.2.
Dise
no te
orico
La tecnica elegida ha sido colocar en serie una resistencia schunt a la salida de las bateras,
de modo que se pueda medir la tension de la batera antes de la resistencia y la corriente
indirectamente leyendo la diferencia de tension en la resistencia schunt. Esta configuracion
necesita un divisor de tensi
on que reduzca las tensiones a niveles con los que los componentes
que se usar
an puedan trabajar, a saber un amplificador operacional que convierta dos tensiones
proximas en una tensi
on proporcional a la diferencia de tensiones y un microcontrolador. La
figura 4.2 muestra el esquema del circuito electronico dise
nado, donde se aprecia los divisores
de tensiones y el circuito diferencial, haciendo uso de uno de los divisores para una funcion
doble: la lectura de la tensi
on por parte del microcontrolador y la adaptacion de esa misma
tension al amplificador operacional.
HARDWARE
CAPITULO 4. DISENO
46
R4
U+
Rs
U0
R3
U
RL
R1
R2
R5
Figura 4.2: Esquema de referencia para el sensor tension-intensidad

Aplicando la primera ley de Kirchhoff a la entrada positiva del amplificador operacional,
U + Ue
Ue
R2
=
Ue = U +
R3
R2
R1 + R2
(4.6)
Aplicando la misma ley sobre la entrada negativa,

U Ue
Ue U0
Ue
=
+
R3
R4
R5
(4.7)
Sustituyendo (4.6) en (4.7)

R2 R4
U0 = U
R1 + R2
+
1
1
1
+
+
R3 R4 R5
R4
R3
(4.8)
Ahora, seg
un esta u
ltima ecuaci
on, U0 depende tanto del diferencial entre las tensiones de
entrada como del modo com
un. Eliminaremos el la desviacion por el modo com
un buscando
una ecuaci
on de la forma U0 = K (U + U ). Para ello igualamos los factores por los que se
multiplican las tensiones de entrada:

R2 R4
1
1
1
R4
+
+
=
(4.9)
R1 + R2
R3 R4 R5
R3
Y despejando R1 /R2 en funci
on de R3 , R4 y R5 queda:
R1
R3
=
R2
R4 k R5
(4.10)
Conservar esta relaci

on de valores en las resistencias es importante de cara a mantener la
linealidad del circuito. Al no existir condensadores ni bobinas, no hay polos ni ceros en la
funcion de transferencia del circuito y por tanto el sistema es estable.
HARDWARE
CAPITULO 4. DISENO
47
C
alculo de los valores de las resistencias
La tensi
on m
axima de entrada al amplificador operacional y al microcontrolador esta limitado a 3,5V superiormente y a 0V inferiormente seg
un la hoja de especificaciones de ambos.
Los factores que se han de controlar son: La ganancia diferencial, el divisor de la tension
en el lado de la batera y la tensi
on de entrada maxima al amplificador operacional.
En ambos casos se ha seguido un procedimiento iterativo en el cual se empieza asignando
valores razonables al divisor de tension formado por R1 y R2 , seguir dise
nando la ganancia
con R3 y R4 y terminar ajustando R5 para que se cumpla la condicion (4.10). Se analizan
los valores obtenidos y se comprueba esten dentro de unos margenes practicos entre 10kWy
1MWaproximadamente y que existan comercialmente. En caso de no cumplir se asignan nuevos
valores y se repite el proceso hasta encontrar unos valores satisfactorios.
El valor elegido para la resistencia shunt de la parte de instrumentos es de 0,05W. Para
un consumo m
aximo de 6A resulta en una cada de tension maxima en la resistencia de
0, 05W 6A = 0, 3V y una potencia de 0, 3V 6A = 1, 8W . La parte de motores llevara una
resistencia de 0,01Wque tendr
a una cada de tension de 0, 01W 17A = 0, 17V . Al primero se
le puede aplicar una ganancia de 10 y al segundo de 18 aproximadamente para adaptar esas
tensiones diferenciales al rango 0V-3,5V de la entrada del convertidor analogico-digital del
microcontrolador.
Los valores de dise
no de las resistencias, la ganancia del diferencial y el factor de la cada
de tension est
an indicados en el cuadro 4.5.
Elemento
R1
R2
R3
R4
R5
Ganancia
U/U +
Instrumentaci
on
33k W
8, 45k W k 330k W
33k W
330k W
8, 45k W
10
0, 1998
Motores
18, 7k W
5, 6k W k 330k W
18, 7k W
330k W
5, 6k W
17, 647
0, 2275
Cuadro 4.5: Valores obtenidos para el sensor I/V
4.2.3.
Consideraciones pr
acticas y construcci
on fsica
El circuito tiene una alta sensibilidad a la entrada, tanto para desviaciones en las tensiones
diferenciales, que es lo que se busca medir, como a variaciones producidas por las tolerancias
de las resistencias. Analizando el efecto de la tolerancia de las resistencias comprobamos que
peque
nas desviaciones tienen una gran repercusion en la tension de salida del amplificador
diferencial. Haciendo R1 = R3 , la resistencia R2 es ahora la mas sensible, pues tiene que
valer exactamente el paralelo entre R4 y R5 . Sustituyamos su valor por otro un 1 % mayor
R20 = R2 1, 01 e introduzc
amos el nuevo valor en la ecuacion (4.8) tomando por ejemplo
+
U = 12V y U = 11, 7V y usando los valores del resto de resistencias los correspondientes
a la parte de instrumentaci
on:
U0 = 10, 07986173W 12V 10W 11, 7V = 3, 96V
(4.11)
HARDWARE
CAPITULO 4. DISENO
48
Figura 4.3: Esquema final de los sensores I/V

Comparandolo con el valor que dara sin el error en R2 , que sera de U0 = 10W 12V 10W
11, 7V = 3V se observa que un error de un 1 % en la resistencia R2 produce desviaciones
de casi 1V, es decir, errores un 33 % mayores. Dado que las resistencias comerciales tienen
tolerancias de un 10 % o de un 5 % tpicamente, no se puede confiar en que colocando una
resistencia con el valor te
orico exacto el circuito vaya a funcionar.
Para solventar este problema se ha recurrido al hecho de que las resistencias se fabrican
en serie y que una resistencia fabricada inmediatamente posterior a otra sera muy parecida
por haber tenido practicamente las mismas condiciones de temperatura, presion, etc. Cuando
se necesiten coger dos resistencias iguales, se cogera del lote recibido de la empresa suministradora dos resistencias contiguas en la parte central y se comprobara mediante polimetro
que tienen el mismo valor. De esta manera, aunque el valor de ambas resistencias tenga una
tolerancia de 5 % o 10 % tendran un valor parecido cualquiera que sea este. Es el caso de las
resistencias R1 y R3 correspondientes a los sensores de la bateria de instrumentacion y de los
motores. Para las resistencias cuyo valor teorico se corresponde con el paralelo de dos resistencias se han montado uniendo fisicamente dos resistencias en paralelo obtenidas como se
ha descrito en el procedimiento anterior, de esta manera la precision obtenida es la adecuada
para las necesidades.
4.3.
Montaje y cableado
En esta secci
on se describe c
omo se han montado los componentes hardware que faltaban
por integrar fsicamente en el robot, al igual que la distribucion esquematica del cableado
tanto de la alimentaci
on como de los datos.
HARDWARE
CAPITULO 4. DISENO
Figura 4.4: Distribucion de pistas del sensor I/V
Figura 4.5: Fotografa del convertidor de se

nal del sensor de tension e intensidad.
Figura 4.6: Fotografa del sensor i/v acoplado a la tarjeta de adquisicion de datos.
49
HARDWARE
CAPITULO 4. DISENO
4.3.1.
50
Dise
no del p
ortico
Se ha construido un p
ortico en aluminio que proporciona una plataforma elevada donde
apoyar la antena receptora de se
nal GPS y la br
ujula electronica (requisitos 2.4.1 y 2.5.3).
El material elegido ha sido el aluminio por sus caractersticas mecanicas y sus propiedades
electromagneticas.El peso calculado de toda la estructura aporta u
nicamente 0,34Kg a todo
el conjunto del robot. El aluminio es paramagnetico y no interfiere significativamente en el
campo magnetico del globo terr
aqueo por lo que la br
ujula no se ve interferida al usar este
material.
Se ha utilizado un perfil en L porque es el el perfil que mejor se ajusta a los elementos ya
presentes en el robot. Con este perfil es posible fijar el portico a la estructura de metacrilato.
esta union se ha realizado con tornillos. Puesto que el metacrilato es un material fragil, se
ha utilizado arandelas de nylon que se adapta a las rugosidades superficiales del metacrilato
y el aluminio y distribuye las presiones por toda la superficie con la que esta en contacto,
reduciendo el riesgo de concentraci
on de tensiones y rotura del metacrilato. Tambien se han
usado tuercas con nylon que evitan el fallo accidental de la union por vibraciones.
Los datos del p
ortico se presentan en el cuadro 4.6
Altura
Anchura
Espesor de perfil
Anchura del perfil
Peso del conjunto
Tornillera
Material de las arandelas
Tipo de tuerca
502mm
335mm
3,3mm
19,2mm
0,34Kg
M5x25
Nylon
Con retencion de nylon
Cuadro 4.6: Datos de dise

no del portico
4.3.2.
Montaje de m
odulos
GPS
La estaci
on m
ovil del GPS se monto de forma definitiva sobre el robot. Se adapto la
superficie del robot base para la fijacion de la radio en el lado derecho del laser. La antena
se atornill
o al p
ortico. La caja de control y la batera de la radio se fijaron al interior de la
estructura de metacrilato posterior.
La estaci
on base no se ha instalado de forma definitiva, sino que ha de prepararse en una
ubicacion temporal con cada uso. Esta preparacion esta descrita en el manual del usuario,
anexo C.
Sensores de la tarjeta de adquisici
on de datos
La br
ujula electr
onica se mont
o sobre el portico de la manera que ya se ha descrito. Se
conecto a la tarjeta de adquisici
on de datos con un cable plano de tres conductores portando
alimentaci
on y la se
nal PWM con la codificacion de la orientacion del sensor.
HARDWARE
CAPITULO 4. DISENO
51
Los aceler
ometros se colocaron detras de la tarjeta de extension de conectores del arduino,
entre esta y la estructura de metacrilato que soporta el lase, donde encuentra proteccion fsica
y a la vez se puede observar su correcta colocacion, que por su tama
no y bajo peso se ha
realizado con velcro. Junto al servant del arduino desarrollado en el captulo 6, se realizara el
requisito 2.4.2.
Las resistenacias shunt se han montado:
1. La primera, que controla las bateras de dispositivo a la entrada de la tarjeta de alimentaciones, al aire con la sujeci
on de los cables.
2. La segunda, que controla las bateras de la base del robot, sobre la puerta de acceso
a las bateras, por el lado interior. Se accede a el desmontando la base del robot y la
tarjeta electr
onica de control de los motores.
4.3.3.
Cableado de datos
Se ha tratado de reducir al m
aximo el impacto visual del cableado sin que reduzca la
accesibilidad a estos para mantenimiento, reparaciones o reconfiguraciones. El diagrama simplificado del cableado de datos se muestra en la figura 4.7. Las flechas se
nalan el flujo de
informacion u
til entre dispositivos. Tambien se ha incluido la transmision de datos inalambrica del sistema GPSd, no as las conexiones inalambricas con la red del laboratorio.
4.3.4.
Cableado de alimentaciones
El cableado de alimentaciones esta centrado alrededor de la tarjeta de alimentaciones. En

la figura 4.8 se mueestra un esquema del cableado de alimentaciones. Cada bloque representa
el conjunto de dispositivos que alimenta cada una de las bateras presentes en el robot. Los
elementos hexagonales representan las bateras y los elementos cuadrados, los dispositivos
que necesitan ser alimentados. La tarjeta de adquisicion de datos, o tarjeta de adquisicion de
datos, se ha representado entre bloques pertenecientes a bateras distintas porque puede ser
alimentado desde USB y usando la batera de dispositivos.
Algunos dispositivos usan el mismo cable simultaneamente para la transimision de datos
y para la alimentaci
on. Estos cables se han indicado con linea discontinua.
HARDWARE
CAPITULO 4. DISENO
52
Ordenador
de a bordo
GPSd
base
GPSd
rover
Cmara
Lser
USB
hub
Mueca
Radio
Radio
Base del robot
MCU
x2
Power board
Sensor I/U
Servo
x2
Interruptor fin
de carrera
Brjula
x2
Acelermetro
Figura 4.7: Diagrama de conexiones de datos.
HARDWARE
CAPITULO 4. DISENO
Batera del
ordenador
53
Ordenador
de a bordo
USB
hub
x3
Convertidor
USB a RS232
Tarjeta
microcontroladora
Brjula
Acelermetro
Batera de
dispositivos
Lser
Power Board
Mueca
Servo
Cmara
Convertidor
12V a 24V
GPSd
rover
Bateras de
la base del
robot
Batera de
la radio del
GPS
Base del robot

Motores Snar
H8 MCU
Bumpers
Leyenda:
12V
24V
radio GPSd
Energa y datos en
cable compartido
Resistencia Schunt
Figura 4.8: Diagrama de conexiones de alimentaciones.
Captulo 5
Entorno software de trabajo

Dado el n
umero de m
odulos con los que se ha trabajado y la similitud entre ellos, ha
sido necesario convenir la organizacion de los modulos. El codigo fuente se ha almacenado
en el repositorio SVN (ver anexo E), y ha sido tambien utilizado para el intercambio y
la actualizaci
on del c
odigo. Al no ser una herramienta de comunicacion, la publicacion de
nuevas versiones, cuando as se ha considerado oportuno, se ha realizado personalmente, si
solo estaba involucrada una persona, o por correo electronico cuando esa persona no estaba
presente o haba m
as personas involucradas. Esto
ha sido contemplado en el requisito 1.
5.1.
Subversion
Una de las primeras recomendaciones que se planteo fue mudar el repositorio de software
de CVS, o Concurrent Versioning System, a SVN, abreviatura de Subversion. Los motivos
que llevaron a este cambio fueron:
Posibilidad de versionar directorios.
Posibilidad de mover, borrar y copiar archivos sin renunciar al historial de cambios.
Cada cambio que se hace define un nuevo arbol completo en el repositorio, lo que evita
actualizaciones incompletas.
Mejor integraci
on general y robustez.
Mayor flexibilidad en la configuracion del servidor y la administracion del repositorio.
Todo ello llev
o a migrar el c
odigo, la documentacion y el resto de archivos contenidos en CVS
a SVN, tal y como hicieron en su da la mayora de proyectos que usaban CVS como sistema de
control de versiones. No obstante se ha mantenido el servidor CVS con el repositorio completo
por motivos de archivado hist
orico.
5.2.
Sistema de compilaci
on CMake
CMake es una herramienta que automatiza la tarea de construir, probar y empaquetar

software. Es multiplataforma y puede generar los archivos de compilacion necesarios para
una multitud de entornos de desarrollo, tales como Makefiles, Eclipse y entornos Windows. El
54
CAPITULO 5. ENTORNO SOFTWARE DE TRABAJO
55
proceso de compilaci
on del software se controla mediante archivos de configuracion textuales
sencillos. CMake es el sistema de compilacion de eleccion para los grandes proyectos de codigo
abierto y su adopci
on es cada vez mayor.
Antes de la implantaci
on de este sistema de compilacion los modulos se compilaban directamente desde la consola, con Makefiles generados manualmente o usando el ya obsoleto
GNU/Autoconf y GNU/Automake, con todos los problemas que acarrea. Se decidio cambiar
el sistema de compilaci
on en todos los modulos para unificar y simplificar la tarea de trabajar
con los modulos, facilitando el desarrollo y el mantenimiento del codigo al tener que trabajar
con una u
nica herramienta de compilacion. El nuevo sistema mejorara el cumplimiento de los
requisitos 1 y 3.
Igualmente CORBA plantea una serie de dificultades en cuanto a la generacion del codigo
de los stubs y los skeletons. A continuacion se presenta una extension que se ha hecho en
el propio lenguaje de archivos de configuracion de CMake que permite a esta herramienta
compilar los archivos IDL al lenguaje C++ y controlar las modificaciones:
1 MACRO ( MacroGenerateIDL )
2
IF (NOT IDL COMPILER)
3
SET(IDL COMPILER t a o i d l )
4
ENDIF(NOT IDL COMPILER)
5
IF (NOT IDL DIR )
6
SET( IDL DIR . . / . . / i d l )
7
ENDIF(NOT IDL DIR )
8
FOREACH( i n F I L E $ {ARGN} )
9
GET FILENAME COMPONENT( base FILE $ { i n F I L E } NAME WE)
10
ADD CUSTOM COMMAND(
11
OUTPUT $ { base FILE }S . h $ { base FILE }S . cpp $ { base FILE }S . i n l
\
12
$ { base FILE }C . h $ { base FILE }C . cpp $ { base FILE }C .
inl
13
MAIN DEPENDENCY $ {IDL DIR}/ $ { base FILE } . i d l
14
COMMAND $ {IDL COMPILER} I $ {IDL DIR} $ {IDL DIR}/ $ { base FILE
}. idl
15
)
16
ENDFOREACH( i n F I L E $ {ARGN} )
17 ENDMACRO ( MacroGenerateIDL )
Ahora es posible crear nuevos m
odulos y que la tarea de crear las dependencias y compilar el codigo CORBA sea casi inmediato. A continuacion se presenta un archivo tpico de
configuraci
on de CMake:
1 # Example c o n f i g u r a t i o n f i l e for CMAKE.
2 # S u b s t i t u t e names b e g i n n i n g with
3 cmake minimum required (VERSION 2 . 6 )
4 p r o j e c t ( module )
5
6 s e t (CORBA LIBS TAO RTCORBA TAO RTPortableServer TAO PortableServer
TAO CosNaming TAO ACE TAO AnyTypeCode )
7 # Remove t h e s e two l i n e s if not using ARIA .

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
56
i n c l u d e d i r e c t o r i e s ( / u s r / l o c a l / Aria / i n c l u d e / )
l i n k d i r e c t o r i e s ( / u s r / l o c a l / Aria / l i b / )
s e t (CMAKE CXX FLAGS "-Wall -fPIC" )
s e t (CMAKE BUILD TYPE Debug )
# CORBA r e l a t e d s o u r c e s .
INCLUDE ( . . / . . / l i b /IDL command . cmake )
MacroGenerateIDL ( CosNaming module )
s e t (CORBA SOURCES moduleC . cpp moduleS . cpp CosNamingC . cpp )
# Client .
a d d e x e c u t a b l e ( m o d u l e c l i e n t m o d u l e c l i e n t . c c $ {CORBA SOURCES} )
t a r g e t l i n k l i b r a r i e s ( m o d u l e c l i e n t $ {CORBA LIBS} )
# Servant .
a d d e x e c u t a b l e ( m o d u l e s e r v e r m o d u l e s e r v e r . c c $ {CORBA SOURCES} )
t a r g e t l i n k l i b r a r i e s ( m o d u l e s e r v e r $ {CORBA LIBS} Aria p t h r e a d d l
)
26
27 # I n s t a l l a t i o n o f s e r v a n t on onboard computer .
28 s e t (CMAKE INSTALL RPATH USE LINK PATH TRUE)
29 i n s t a l l p r o g r a m s ( / . . / . . / . . / . . / . . / . . / . . / e t c / h i g g s / s e r v a n t s
m o d u l e s e r v e r . sh )
30 i n s t a l l t a r g e t s ( / b i n m o d u l e s e r v e r )
CMake tambien se ha usado para la generacion de documentacion de codigo con Doxygen
(Anexo E).
5.3.
Libreras comunes
Los modulos incorporan elementos comunes en su programacion que han sido recogidos
e implementados en un u
nico lugar. Las dos ventajas principales de compartir codigo son,
primero, que se reduce el tiempo de programacion en cada modulo, evitando reinventar la
rueda y reduciendo el n
umero de lneas, que facilita la revision del codigo. Segundo, que si
se hace necesario modificar este c
odigo com
un con realizarlo una vez basta y los cambios se
propagan a todos los m
odulos cuando se compilen, o si la modificacion es en la configuracion,
cuando se reinicien. Aunque la necesidad de esta librera ha surgido despues del incio del
proyecto, se enmarca dentro de los requisitos 1 y 3.
El codigo fuente de esta librera se puede encontrar en el cede que acompa
na al proyecto
dentro del archivo
code/lib/CORBA_utils.h
A continuaci
on se lista el c
odigo de un hipotetico servant que se ha tomado como referencia
para construir los m
odulos.
1 // A typical servant executable would be something like:

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
57
# include " implementation .h"

# include " CosNamingC .h"
# include " ../../ lib/ CORBA_utils .h"
int main ( int argc , char * argv [ ] )
{
CORBA BEGIN SERVER( argc , argv ) ;
i m p l e m e n t a t i o n t impl ( ) ;
h i g g s : : i m p l e m e n t a t i o n t v a r i m p l v a r = impl . t h i s ( ) ;
CORBA REGISTER REFERENCE( implvar , "IMPL" ) ;
CORBA END SERVER;
return 0 ;
}
La implementaci
on CORBA que se ha usado obliga a pasar como argumentos del ejecutable la direcci
on del servidor de nombres. Los servants CORBA existentes al inicio del proyecto
resolvan esta situaci
on ejecutando en lugar del ejecutable un script conteniendo la llamada al
ejecutable del cliente o servant y la direccion del servidor de nombres como argumento, m
as
el puerto de escucha para el caso de los servants. Usando esta librera se elimino la necesidad
de este script, duplicado por cada ejecutable creado, sin necesidad de modificar el codigo de
ning
un modulo y puediendo realizar cambios en la configuracion de todos los servants con
solo modificar un archivo (ver secci
on 5.5).
5.4.
Sistemas operativos en el ordenador de a bordo
Se probaron distintos sistemas operativos antes de decidir el mas adecuado para cumplir
el requisito 1.1. Los requerimientos por los que se seleccion el sistema operativo fueron:
Posibilidad de n
ucleo en tiempo real (requisito 1.1.1).
Amplia biblioteca de libreras.
Facilidad de instalaci
on y uso.
Compatibilidad con el c
odigo ya desarrollado.
A continuaci
on se muestra una lista con los sistemas operativos probados junto con las
ventajas y desventajas de cada uno de ellos.
Windows XP Es el sistema operativo por defecto que vena incluido con el ordenador. Se
incluye licencia. Windows XP no trae caractersticas de tiempo real en la distribucion
estandar y sus libreras son propietarias. No es compatible con gran parte del codigo ya desarrollado por estar hecho para sistemas basados en UNIX. Configurar este
sistema operativo para tareas empotradas es dificultoso, sin embargo existen muchas
implementaciones CORBA, la mayora de ellas propietarias.
58
WindRiver VxWorks Este

es el sistema operativo usado hasta la fecha. Esta basado en
UNIX (cumple POSIX), tiene un buen soporte para tiempo real y esta dise
nado para
ser usado en sistemas empotrados. Su mayor inconveniente reside en la dificultad para
su instalaci
on, por la que hay que crear un entorno de desarrollo cruzado para compilar las herramientas y servicios desarrollados. Es necesario solicitar licencia a la casa
comercializadora.
Fedora Linux Se trata de un sistema operativo de facil instalacion y uso para usuarios
que no necesariamente tienen altos conocimientos en administracion de sistemas UNIX.
Esta enfocado hacia un entorno grafico con una carga alta sobre el procesador y la
memoria, lo que lo hace demasiado complejo para sistemas empotrados. No es tiempo
real.
Orquestra Orquestra Control Engine es un sistema operativo basado en Ubuntu Linux de
libre distribuci
on, preparado para ser utilizado en aplicaciones industriales y de control
de robots. Es de f
acil instalaci
on, incluye un n
ucleo de tiempo real y m
ultiples libreras
y utilidades de control de robots, creacion de entornos virtuales, calculo cinematico
inverso y filtros. Adem
as est
a siendo usado por otros grupos de investgacion dentro del
departamento.
Ubuntu Linux + RTAI Se trata de la distribucion Ubuntu Linux, una de las mas usadas
en ordenadores de esritorio y portatiles, a la que se le a
nade un n
ucleo de tiempo real.
Hay mucha documentaci
on y tutoriales que facilitan la modificacion de la distribucion
para hacerlo en tiempo real.
Finalmente se decidi
o instalar Ubuntu Linux 10.04 LTS, con soporte oficial durante tres
a
nos, hasta el 2013, usando como n
ucleo el kernel de linux con los parches RTAI. El proceso
seguido para descargar, configurar, compilar e instalar el n
ucleo se describe en el manual del
desarrollador, anexo D.
5.5.
Configuraci
on de los m
odulos CORBA
Esta
secci
on resuelve las necesidades planteadas por el requisito 1.1.2.
5.5.1.
Par
ametros de los servants
Se ha creado un
arbol de directorios donde se han introducido los archivos de configuracion
necesarios para iniciar los servants. Este

directorio debe ir ubicado en
/etc/higgs
en todos los ordenadores que vayan a ejecutar componentes CORBA, ya sean clientes o
servants. Los clientes u
nicamente necesita el archivo con la direccion del servicio de nombres,
mientras que en el ordenador de a bordo se han necesitado todos ellos. El arbol resultante es
el siguiente:
higgs
|-- devices

|
|
|
|
|-|-|
|
--
59
|-- arduino_dev -> /dev/ttyUSB2

|-- higgs_dev -> /dev/ttyUSB0
|-- wrist_dev -> /dev/ttyUSB3
-- laser_dev -> /dev/ttyUSB1
listen\_endpoint.ip
modules
|-- ftdi\_sio.ko
-- pl2303.ko
nameservice.ip
A continuaci
on se hace una breve explicacion de cada entrada:
devices Subdirectorio que contiene enlaces simbolicos a los archivos de dispositivos en /dev.
Los servants abren estos archivos en lugar del dispositivo real para no tener que recompilarlo cada vez que el dispositivo cambia de nombre, hecho muy frecuente con los
convertidores USB a RS-232.
listen endpoint.ip Direcci
on IP de la interfaz de red por el que se desea que se pongan a
la escucha los servants.
modules En este caso modules se refiere a modulos recargables del n
ucleo de linux. Los
drivers de los convertidores USB a RS-232 cargan en orden arbitrario cada vez que se
reinicia el ordenador de a bordo, lo que provoca cambios en los nombres de los archivos
de dispositivo. Para evitarlo se han movido los drivers a este directorio, evitando que el
n
ucleo los cargue autom
aticamente. Se ha a
nadido una instruccion de carga manual de
estos drivers en la secuenca
nameservice.ip Direcci
on IP del servicio de nombres. Unico
archivo obligatorio para los
ordenadores que solo ejecuten clientes. de arranque del sistema operativo, de este modo
los drivers se cargan siempre en el mismo orden.
5.5.2.
Ejecuci
on de los servants
El requisito 2.3 requiere que los servants se recuperen automaticamente tras un fallo.
Los servants se encargan de abortarse a s mismos, pero el arranque debe realizarse a m
as
bajo nivel, desde el sistema operativo. Se ha usado la utilidad de arranque de los servicios
del sistema operativo Ubuntu, Upstart. Esta

utilidad es un reemplazo del antiguo sistema
Init V. Se usan archivos de configuracion en lugar de entradas en el arbol de directorios de
arranque del sistema y de esta manera lograr mayor flexibilidad en las opciones de arranque
de los demonios mientras se mejor el control de los mismos. Estos archivos se guardan en el
directorio
/etc/init
Tpicamente el archivo de configuracion de ejecucion de los modulos sera como el mostrado
a continuaci
on del l
aser que se toma como ejemplo. Notese que se redirecciona la salida
estandar y de error al archivo de log, pero no la direccion del servicio de nombres de CORBA:
60
description "Upstart config file for the arduino servant"

author "Francisco J. Arjonilla Garc
a"
#start on started Naming_Service
respawn
script
sleep 5
date >> /var/log/higgs/laser.log
su -l -c /usr/local/bin/laser_server higgs >> /var/log/higgs/laser.log 2>&1
end script
El servant java de la tarjeta de adquisicion de datos no usa las macros C++ que automatizan la configuraci
on del broker de CORBA por lo que hay que especificarlo manualmente
en el archivo de configuraci
on del servant:
author "Francisco J. Arjonilla Garc
a"
start on started Naming_Service
respawn
script
sleep 5
date >> /var/log/higgs/arduino.log
su -l -c "java -jar /usr/local/bin/arduino.jar \
-ORBInitRef Naming_Service=corbaloc::$(cat /etc/higgs/nameservice.ip)\
/NameService" higgs >> /var/log/higgs/arduino.log 2>&1
end script
El servidor de nombres de CORBA necesita tener fijados la direccion y el puerto por los
que escuchar. El archivo de configuracion es:
description "CORBA Naming Service"
start on net-device-up
respawn
exec Naming_Service -ORBEndPoint iiop://higgs2.disam.etsii.upm.es:9876
Captulo 6
M
odulos software
En este captulo se describe la parte software de los modulos. Todos ellos estan encapsulados en un objeto CORBA que implementa las interfaces IDL creadas como consecuencia del
requisito 2.1.
6.1.
Mu
neca
El desarrollo del m
odulo de la mu
neca viene a cumplir con el requisito 2.5.1.2 y se ha
centrado en el desarrollo del servant. Al inicio del proyecto se encontraba instalada sobre la
estructura de metacrilato que soporta el laser pero preparada para ser alimentada externamente y controlada desde ordenadores externos. Se termino de integrar al robot adaptandolo
a la tarjeta de alimentaciones y a los convertidores USB a RS-232.
6.1.1.
Servant
El desarrollo del m
odulo se inici
o a partir de un codigo que lograba conectar con la mu
neca
y aplicar comandos sencillos de movimiento. La interfaz de este codigo no era suficientemente
buena para trabajar con ella, por lo que se empezo reorganizando y reestructurando el codigo.
Tras unos das de trabajo se decidi
o que sera mas sencillo comenzarlo desde cero usando la
documentaci
on para la elaboraci
on del protocolo y tomando como referencia de codigo en funcionamiento el c
odigo antiguo. Se inicio analizando el protocolo y dise
nando unas clases, a
un
sin la complejidad de CORBA, que facilitaran su implementacion. En cuanto se consiguio la
comunicaci
on con la misma secuencia de envo de bytes por el puerto serie, la extension del
protocolo a la funcionalidad completa de la mu
neca se acelero, gracias a la nueva estructura
de clases, que se puede observar en la figura 6.1.
Conseguida la comunicaci
on con la mu
neca se escribio la interfaz IDL y se implemento el
servant usando el c
odigo descrito en el parrafo anterior.
6.1.2.
Tolerancia a fallos
Se ha logrado una muy buena tolerancia a fallos en este servant. Los fallos que se tienen
en cuenta son:
1. Tensi
on de alimentaci
on fuera del rango admitido.
61

CAPITULO 6. MODULOS
SOFTWARE
62
Figura 6.1: Diagrama de clases de la mu

neca.
2. Sobrecorrientes.
3. Dispositivo apagado.
En los tres casos el servant detectar
a la condicion de error y abortara la ejecucion, a la espera
de que se reinicie y vuelva a intentar abrir la comunicacion.
6.2.
L
aser
A continuaci
on se expone las tareas desarrolladas en el ambito del requisito 2.5.2
6.2.1.
Selecci
on del c
odigo base
El codigo base desde el que se partio esta basado en la librera ARIA1 y usa algunas
clases con funciones avanzadas de calculo estadstico para la determinacion de segmentos
rectos en los datos de entrada, en concreto ArSick y ArLineFinder. Este

codigo se ha usado
satisfactoriamente en [11] en el cual no es necesario capacidades de curacion del sistema.
La integraci
on de este m
odulo CORBA ya realizado tropezo con la necesidad de recuperarse de un fallo o de una desconexion del sensor, por lo que no pudo integrarse sin previa
adaptacion, lo que constituira la primera opcion para tener un modulo laser funcional. Por
otra parte se dispona del c
odigo creado a medida por los compa
neros del laboratorio de
robotica m
ovil consistente en dos unidades de compilacion. La tercera opcion consistio en
programar un nuevo driver a medida de las necesidades del robot. A continuacion se describen brevemente las ventajas y desventajas de cada opcion.
Librera ARIA. Como ventaja fundamental se puede citar que ya esta integrado dentro
de un servant CORBA probado y en funcionamiento y que dispone de funciones para
1
Se puede descargar m
as informaci
on sobre esta librera en http://robots.mobilerobots.com/wiki/ARIA

CAPITULO 6. MODULOS
SOFTWARE
63
Figura 6.2: Diagrama de secuencia tpica para una llamada al servant de la mu

neca.
la determinaci
on de segmentos rectos. En contra, que no dispone de algoritmos para
resincronizar el protocolo en caso de fallo del hardware o del servant, que depende de una
librera de gran tama
no poco manejable y que el esfuerzo de adaptacion requiere estudiar
el codigo fuente de la librera. Ademas, habra que actualizar la librera con cada nueva
versi
on que apareciese y llevar registro de los cambios. Adicionalmente, esta librera
filtra algunos mensajes perdiendo parte de la informacion de las distancias en cada
lectura y no est
a preparado para funcionar a la maxima velocidad que permite el sensor.
Tampoco proporciona metodos para controlar condiciones de error en el protocolo sino
que simplemente ofrece la u
ltima lectura tomada como valida por antigua que sea.
Driver proporcionado por compa
neros de robotica movil. Dispone de la funcionalidad
completa que ofrece el sensor pero no puede recuperar el sincronismo. No tiene dependencias con libreras externas (es autocontenido) y esta preparado para ser enlazado
estaticamente.
Empezar un nuevo driver desde cero. Se pierde la ventaja de partir de un sistema ya
probado y en funcionamiento para repetir un trabajo de programacion que ya esta realizado. A favor, que el c
odigo resultante se ajustara perfectamente a los requerimientos
del proyecto.
En primer lugar se program
o una serie de funciones capaces de conectar con el laser y
recuperar el sincronismo independientemente de su estado inicial, con idea de usar este codigo
tras la selecci
on del c
odigo base. Se decidio abandonar la librera ARIA en favor de un codigo
mas controlable y compacto donde la robustez del protocolo quedara garantizada, no solo
en la ejecuci
on sino en la instalaci
on y facilidad de mantenimiento del codigo. Las funciones
desarrolladas se introdujeron en las rutinas de inicializacion del driver proporcionado por los
compa
neros de r
obotica m
ovil aprovechando as la posibilidad de cambiar la frecuencia del
puerto serie y los par
ametros de sensado del laser.

CAPITULO 6. MODULOS
SOFTWARE
64
Figura 6.3: Gestion de errores en la mu

neca.
6.2.2.
Servant
Finalmente se cre
o el servant CORBA usando este driver y el cliente de prueba. El servant
adapta los valores de entrada a la convencion matematica usada a lo largo del proyecto:
Radianes para referirse a los
angulos en sentido positivo con referencia vertical hacia arriba
y origen mirando al frente, y las distancias en metros. Existe un hilo especfico para manejar
el protocolo del l
aser y otro para atender las llamadas de los clientes CORBA, teniendo la
implementaci
on del servant un buffer intermedio en el que los dos hilos se transmiten la
informacion del sensor.
A continuaci
on se presenta la parte desarrollada del driver capaz de resincronizarse bajo
todas las frecuencias del protocolo y en cualquier punto de este:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
char cadena [ 1 0 0 ] ;
int baud [ ] = { 9 6 0 0 , 3 8 4 0 0 , 5 0 0 0 0 0 } ;
// int baud []={9600 ,38400};
// int baud []={9600};
int i =0;
int s i z e=sizeof ( baud ) / sizeof ( int ) ;
for ( i =0; i<=s i z e ; i ++)
{
int bps ;
if ( i == s i z e ) // In case a Reset () returns the laser to 9600
bps.
bps = baud [ 0 ] ;
else
bps = baud [ i ] ;
p o r t . SetBaud ( bps ) ;
p r i n t f ( " Trying to connect at %d baud .\n" , bps ) ;

CAPITULO 6. MODULOS
SOFTWARE
65
Figura 6.4: Procedimiento de inicializacion del protocolo del sensor laser.
Figura 6.5: Estructuras de datos definidas en la interfaz IDL del laser.

16
17
18
19
20
21
22
23
24
25
26
27
28
// Try to syncronize from a previous program crash .

unsigned char c [ 5 ] ;
memset ( c , 0 , 5 ) ;
int j ;
for ( j = 0 ; j < 1 0 0 0 ; j ++)
{
for ( int k = 0 ; k < 4 ; k++)
c[k] = c[k + 1];
if ( ! p o r t . R e c e i v e ( 1 , c +4) )
{
c o u t << "No data received . Synchronization failed ." << e n d l
;
break ; // Receive failed . We try to set up the laser .
}

CAPITULO 6. MODULOS
SOFTWARE
29
30
31
32
33
34
35
36
66
int m s g l e n g t h = 0 ;
if ( c [ 0 ] == 0 x02 && c [ 1 ] == 0 x80 && c [ 4 ] == 0 xb0 )
{
m s g l e n g t h += c [ 2 ] + 256 * c [ 3 ] 1 + 2 ;
unsigned char dump [ 1 0 0 0 ] ;
c o u t << " Telegram detected with length " << m s g l e n g t h <<
". Waited for " << j << " characters ." << e n d l ;
if ( m s g l e n g t h >= 1000 | | p o r t . R e c e i v e ( ms g leng th , dump) !=
msg length )
{
c o u t << " Telegram not fully received . Synchronization
failed ."
<< e n d l ;
break ; // Receive failed . We try to set up the laser .
}
Stop ( ) ;
break ; // Receive successful . We stop and reset the
configuration .
}
37
38
39
40
41
42
43
44
45
46
47
48
}
if ( j == 1 0 0 0 )
{
c o u t << "Data stream received , but no header found . Trying
to reset ."
<< e n d l ;
Reset ( ) ;
}
int pru=LMSType( cadena ) ;
if ( pru !=PROT LMS OK)
{
p r i n t f ( " Connection at %d baud failed . Reason : %d\n" , bps , pru
);
}
else
{
p r i n t f ( " Connection at %d succesful \n" , bps ) ;
break ;
}
}
if ( i>=s i z e ) return PROT LMS ERROR;
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
6.3.
GPSd
El desarrollo del m
odulo GPS esta motivado por el requisito 2.5.3 y 2.5.3.1 y se ha dividido en tres partes: Instalaci
on mecanica, analisis del protocolo y desarrollo del servant.
La instalaci
on mec
anica se ha contemplado en el captulo 4 En primer lugar se descifro el

CAPITULO 6. MODULOS
SOFTWARE
67
protocolo de comunicaci
on, estudiando los manuales del GPS, conectando por el terminal
usando la utilidad est
andar de UNIX minicom y realizando pruebas hasta conseguir capturar
la posicion.
6.3.1.
Servant
El desarrollo del servant se realiz

o como el resto de modulos. Se utlizo el sistema CMake
para el sistema de compilaci
on y se aprovecharon las libreras comunes para el desarrollo del
servant. La interfaz incluye metodos para las siguientes funciones:
1. Posici
on en coordenadas geogr
aficas.
2. Velocidad en m/s.
3. Desviaci
on est
andar de la posicion.
4. N
umero de satelites usados en la solucion.
5. Tipo de soluci
on (Ver tipos en figura 6.6).
El funcionamiento interno del m
odulo es similar al de la tarjeta de adquisicion de datos y se
basa en la existencia de dos hilos. El primero de ellos esta bajo control del broker de CORBA
y atiende llamadas de objetos remotos volcando la informacion de variables intermedias en
los valores de retorno. El segundo hilo es el mas complejo y es el que inicializa la caja de
control del GPS para despues quedarse a la escucha y decodificar los mensajes del GPS, que
son enviados cada segundo.
Un tercer hilo asegura que las comunicaciones entre el servant y la caja de control siguen
activas. Su funcionamiento es similar al de un watchdog: Se habilita un temporizador que
con cada mensaje recibido se reinicia. Si el contador pasa un lmite, que en el caso de este
modulo est
a establecido en 5 segundos, fuerza la finalizacion del proceso y consecuentemente
el reinicio, si el archivo de configuracion de upstart esta correctamente instalado.
Figura 6.6: Tipos de datos retornados por llamadas al servant del GPS.

CAPITULO 6. MODULOS
SOFTWARE
6.4.
68
Tarjeta de adquisici
on de datos
on de datos presenta una serie de desventajas que hace necesario su
modificaci
on. Se ha tenido que estudiar en detalle el sistema de partida, realizando ingeniera
inversa, debido a la escasa documentacion que acompa
na el codigo.
1. La interfaz gr
afica impide la ejecucion del servant en ordenadores empotrados, sin sistema gr
afico o con recursos limitados.
2. Algunas de las
ordenes enviadas a la tarjeta son ignoradas.
3. El codigo del firmware no es lo suficientemente estable como para asegurar un funcionamiento continuado.
4. La interfaz IDL es mejorable.
5. La configuraci
on e inicializaci
on del servant es difcil y laboriosa.
6. El conjunto no es robusto y necesita monitorizacion constante por parte del operador.
Estos
defectos vienen motivados de la naturaleza del desarrollo anterior que se limitaba a
una fusion sensorial de algunos dispositivos del robot. El desarrollo realizado en este proyecto
mejora este m
odulo y lo ampla, habilitando algunos sensores que no existan a la hora de
realizar el proyecto.
Los sensores y actuadores que se han a
nadido son:
1. Br
ujula electr
onica.
2. Aceler
ometros.
3. Apagado remoto de dispositivos, ver seccion 4.1.
4. Sensores de medici
on de corriente e intensidad de las bateras, ver seccion 4.2.
Para ello se ha modificado tanto el firmware como el servant.
6.4.1.
Firmware
El firmware ha necesitado un repaso general de las funciones que implementa. En primer

lugar se elimin
o el c
odigo irrelevante que u
nicamente reduca el rendimiento del procesamiento.
En segundo lugar se a
nadi
o la captura de los nuevos sensores, habilitando nuevos tipos de
datos de entrada. Se a
nadi
o la captura de tiempos para el PWM enviado por la br
ujula
electronica, a
nadiendo esta captura al ciclo de lectura de los registros correspondientes a cada
sensor. Finalmente se adaptaron los comandos a las nuevas funcionalidades y se eliminaron
funcionalidades obsoletas no aplicables al conjunto del robot.
Ademas durante todo el proceso se fueron corrigiendo peque
nos errores as como mejorando la estructura para facilitar el mantenimiento futuro del codigo. En el manual del desarrollador, anexo D se ha documentado en detalle los pasos a seguir para realizar actualizaciones
del firmware.

CAPITULO 6. MODULOS
SOFTWARE
6.4.2.
69
Servant
En primer lugar se ha adaptado el codigo para poder ejecutarse en modo demonio, es

decir, sin interfaces con las que interaccionar. Esto permite iniciar el servant con el arranque
del sistema operativo y es necesario para lograr mayor autonoma del modulo, limitando las
interacciones a la interfaz CORBA ofrecida y el registro de los mensajes en los archivos de
log.
Se ha realizado un estudio de las necesidades del grupo ASLab con la funcionalidad que
debe ofrecer este m
odulo y se ha modificado la interfaz IDL acorde a los metodos requeridos.
Ello debe ir acompa
nado por la modificacion correspondiente en el codigo del servant, que
esta escrito en Java. Una implementacion ideal usara un lenguaje que no necesitara una
maquina virtual y as aprovechar el tiempo de procesamiento de la CPU, que es escaso debido
a los requisitos de tiempo real y de procesamiento de los servants del resto de modulos.
Se busc
o el motivo por el cual se ignoraban algunos mensajes y el diagnostico resulto ser
que la estructura de datos usada para comunicar los hilos del servant y de escucha del puerto
serie era sobreescrita antes de ser enviada a la tarjeta. Se resolvio sustituyendo la estructura
de datos por una cola de
ordenes a enviar. Esta cola crece con cada solicitud recibida por el
hilo del servant y se reduce cada vez que el hilo de escucha del puerto serie enva la orden
correspondiente a la tarjeta (figura 6.8). La nueva relacion de clases se puede ver en la figura
6.7.
Figura 6.7: Diagrama de clases del servant de la tarjeta de adqusicion de datos.

Dado que el sistema CMake no soporta la compilacion de codigo Java, se ha hecho una excepcion con este m
odulo y se ha creado un archivo Makefile especfico generado manualmente
y que incluye instrucciones para las siguientes operaciones:
Instalaci
on de las libreras requeridas, que se encuentran dentro del arbol del codigo
fuente del m
odulo.
Generaci
on del c
odigo a partir de las IDLs.
Compilaci
on del servant.

CAPITULO 6. MODULOS
SOFTWARE
70
Figura 6.8: Diagrama de secuencia del envo de mensajes.

Instalaci
on en el ordenador de a bordo.
6.5.
Executive
libExecutive es el nombre de una librera desarrollada para facilitar la comunicacion entre

modulos que deben trabajar con datos que se actualizan sncronamente. Surgio la necesidad de
contar con una utilidad que, funcionando por ciclos, cogiera en primer lugar el valor de ciertos
datos en determinados objetos, los distribuyera entre todos aquellos objetos que hiciesen uso
de ese dato y cerrase el ciclo solicitando a los objetos que hiciesen los calculos necesarios con
los datos actualizados para comenzar un nuevo ciclo, que se representa en la figura 6.10
Figura 6.9: Diagrama de clases de libExecutive.

Los datos son atributos miembro de objetos C++. Los metodos que deben llamarse son
tres y tambien son miembros de alguna clase, por lo que junto a la referencia del puntero
a metodo miembro hay que almacenar el objeto, de modo que la llamada al metodo sea
efectiva tal como se producira con un objeto. Ha sido necesario el uso de plantillas debido a
que los objetos pueden ser de cualquier tipo, combinando las caractersticas mas avanzadas

CAPITULO 6. MODULOS
SOFTWARE
71
Figura 6.10: Diagrama de actividades de libExecutive.

del lenguaje C++ en su versi
on C++03. Ver [7] para una de las mejores referencias C++
existentes.
Es similar al servicio de eventos de CORBA, con la diferencia de que el servicio de eventos
espera a que los objetos suministren el dato, en lugar de recogerlos el mismo, y libExecutive
gestiona los ciclos y el momento en que cada objeto puede realizar los calculos, manteniendo
en sincronismo los datos.
Debido a la naturaleza distribuida del proyecto, se ha preparado esta librera para trabajar
con objetos CORBA, estando soportados la mayora de tipos de datos, habiendose excluido
los datos de longitud variable. Tambien se ha optimizado el uso de los recursos habilitando un
hilo por cada llamada que se realiza, de modo que estas llamadas se hacen simultaneamente
y, si los objetos distribuidos se encuentran en maquinas remotas o la CPU esta compuesto por
varios n
ucleos, se mejora el uso los recursos de computacion existentes al no tener que esperar
a que cada objeto realice los c
alculos en su maquina, es decir, que el tiempo de calculo no
depende del n
umero de objetos/llamadas a realizar, sino del objeto que tarde mas en realizar
el computo.
El codigo fuente de esta librera se ha incluido en el cede que acompa
na el proyeto y la
documentaci
on generada ha sido extrada con Doxygen (ver anexo E y manual de uso en [9])
y se incluye en el anexo B. Tambien se ha incluido un ejemplo de uso que ha servido asimismo
para probar y validar el c
odigo, del cual se pueden encontrar mas detalles en el captulo 7.
A continuaci
on se incluye algunos de los metodos implementados en la cabecera de la
librera. Este c
odigo no es funcional, pero sirve para tener una ideal del funcionamiento
interno del c
odigo desarrollado. Se han omitido tipos de datos, atributos y comentarios. Estos
u
ltimos ya est
an incluidos en la documentacion y se han omitido para evitar duplicidades;
notese que el cuerpo de los metodos es suficientemente sencillo para ser autoexplicativo y no
necesitar m
as comentarios.
1 template <class T>
2 class e x e c u t i v e a t t r i b u t e

CAPITULO 6. MODULOS
SOFTWARE
72
3 {
4 public :
5
template <class O>
6
e x e c u t i v e a t t r i b u t e ( e x e c u t i v e & ex , O * obj , T (O: : * g e t ) ( )
const )
7
{
8
// Register the supplier .
9
s u p p l i e r e n t i t y . o b j = ( phony * ) o b j ;
10
s u p p l i e r e n t i t y . g e t = (T ( phony : : * ) ( ) const ) g e t ;
11
s u p p l i e r e n t i t y . g e t t y p e = NORMAL;
12
s u p p l i e r e n t i t y . v a l u e = &v a l u e ;
13
14
// Register to the executive .
15
a d d t h i s t o e x e c u t i v e ( ex ) ;
16
}
17
18
executive attribute ()
19
{
20
for ( s t d : : v e c t o r <e x e c u t i v e : : c a l l b a c k s > : : i t e r a t o r i =
21
exec>c a l l b a c k s p o o l . b e g i n ( ) ;
22
i != exec>c a l l b a c k s p o o l . end ( ) ; )
23
{
24
if ( i >o b j == ( phony * ) this )
25
exec>c a l l b a c k s p o o l . e r a s e ( i ) ;
26
else
27
i ++;
28
}
29
}
30
template <class O>
31
void s u b s c r i b e c o n s u m e r (O * obj , void (O: : * s e t ) (T) )
32
{
33
consumer c ;
34
c . o b j = ( phony * ) o b j ;
35
c . s e t = ( void ( phony : : * ) (T) ) s e t ;
36
c . v a l u e = &v a l u e ;
37
c . s e t t y p e = NORMAL;
38
c o n s u m e r p o o l . push back ( c ) ;
39
}
40
void a d d t h i s t o e x e c u t i v e ( e x e c u t i v e & ex )
41
{
42
e x e c u t i v e : : c a l l b a c k s ev ;
43
ev . o b j =
( phony * ) this ;
44
ev . a s y n c g e t =
45
( void ( phony : : * ) ( ) )&e x e c u t i v e a t t r i b u t e <T> : :
async get ;
46
ev . a s y n c s e t =
47

CAPITULO 6. MODULOS
SOFTWARE
async set ;
ev . async compute =
async compute ;
e x e c = &ex ;
exec>c a l l b a c k s p o o l . push back ( ev ) ;
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
73
};
}
void a s y n c s e t ( )
{
for ( s i z e t i = 0 ; i < c o n s u m e r p o o l . s i z e ( ) ; i ++)
{
pthread t thread ;
p t h r e a d c r e a t e (& thread , 0 , t h r e a d e d s e t , &c o n s u m e r p o o l
[ i ]) ;
exec>t h r e a d p o o l . push back ( t h r e a d ) ;
}
}
static void * t h r e a d e d s e t ( void * v o i d d a t a )
{
consumer * data = ( consumer * ) v o i d d a t a ;
T * value p ;
switch ( data>s e t t y p e )
{
case NORMAL:
( data>obj >*data>s e t ) ( * data>v a l u e ) ;
break ;
case POINTER:
v a l u e p = new T( * data>v a l u e ) ;
( data>obj >*data>s e t p ) ( v a l u e p ) ;
break ;
case REFERENCE:
( data>obj >*data>s e t r ) ( * data>v a l u e ) ;
break ;
}
return 0 ;
}
6.6.
Prevenci
on de impactos
Se ha desarrollado un algoritmo para extender el modulo del robot base y que protegera contra posibles impactos, reduciendo la velocidad del robot de manera progresiva a
medida que se aproxima a un obst
aculo. El algoritmo calcula por una parte la velocidad
maxima en direcci
on del eje del sensor que puede tener el robot en funcion de la distancia
al obstaculo detectado, si hay alguno, con los sensores ultrasonicos de la base robotica, y
por otra parte la velocidad solicitada desplazada a cada sensor y proyectada sobre su eje. Si

CAPITULO 6. MODULOS
SOFTWARE
74
la velocidad calculada supera la velocidad maxima, se acota la primera a la segunda. Este

algoritmo permite desplazar el robot cerca de obstaculos y paredes siempre que no se acerque a ellos. Puede pasar por pasillos estrechos sin limitar la velocidad de avance y evitando
choques laterales y tambien evitar choques frontales sin reducir la capacidad de giro ante
paredes. Los movimientos que el robot hace son previsibles, pues no modifica la direccion ni
el sentido del desplazamiento solicitado, u
nicamente limita la velocidad de avance, incluso
deteniendo el robot, en caso de choque inminente. Tampoco limita la velocidad cuando se
solicitan movimientos suaves y precisos en espacios peque
nos, cumpliendo con los requisitos
solicitados.
Vmax
V
Vi
Vd
y
x
Figura 6.11: Representaci

on de las variables usadas en la prevencion de impactos.
Las velocidades de las ruedas izquierda, derecha, del punto central del robot y del punto
representado son, respectivamente,
Vi = ( a) ;
V
Vd = ( + a) ;
(6.1)
V = r
Los datos conocidos, obtenidos por la odometra y por las especificaciones geometricas del
robot son Vi , Vd y a. Las inc
ognitas para obtener el centro instantaneo de rotacion son y .
Despejando en 6.1,
Vd Vi
Vi + Vd
=
=
a
(6.2)
2a
Vi Vd
Por relaciones geometricas,
p
r = y 2 + ( x)2
= arctg(
y
)
x
(6.3)
Y tomando = + /2, resulta que la velocidad se excede cuando

V cos() > Vmax
Y se debe limitar la velocidad a
|V | =
|Vmax |
cos()
(6.4)
(6.5)

CAPITULO 6. MODULOS
SOFTWARE
Sensor #
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
0
40
60
80
100
120
140
180
180
220
240
260
280
300
320
360
75
x(m)
0.136
0.119
0.079
0.027
-0.027
-0.079
-0.119
-0.136
-0.136
-0.119
-0.19
-0.027
0.027
0.079
0.119
0.136
dmin (m)
0.12
0.17
0.11
0.09
0.09
0.11
0.17
0.12
0.12
0.17
0.11
0.08
0.08
0.11
0.17
0.12
y(m)
0.147
0.193
0.227
0.245
0.245
0.227
0.193
0.147
-0.144
-0.189
-0.223
-0.241
-0.241
-0.223
-0.189
-0.144
Cuadro 6.1: Par

ametros de los sensores y distancias mnimas en la prevencion de impactos.
La velocidad m
axima Vmax se calcula a partir de la distancia del sensor al obstaculo,
siguiendo la curva de la figura 6.12. En esta figura la velocidad admmisible esta acotada
superiormente por tres rectas:
1. Distancia de seguridad, que incluye la distancia del sensor hacia el interior del contorno
en planta del robot y la distancia mnima del sensor.
2. Rampa de velocidades incrementales. Se permite mayor velocidad cuanto mas lejos
este el obst
aculo,
3. La velocidad m
axima Vmotor que son capaces de alcanzar los motores.
Vmax
Vmotor
dmin
Figura 6.12: Funci

on de limitaci
on de la velocidad maxima respecto de la distancia.

CAPITULO 6. MODULOS
SOFTWARE
76
En cada actualizaci
on de la lectura de los sensores ultrasonicos y cada vez que se recibe
un nuevo comando de movimiento se recalculan las velocidades maximas Vmax permitidas
por cada sensor y la transformaci
on espacial de la velocidad solicitada a la posicion de cada
sensor y proyectadas sobre su direcci
on usando los datos de la tabla 6.1, limitando la velocidad
absoluta solicitada al sensor que m
as limite la velocidad, es decir, el mnimo de velocidades
maximas.
Captulo 7
Validaci
on y pruebas
7.1.
Pruebas
A lo largo del proyecto se han ido realizando pruebas sobre los modulos en desarrollo,
comprobando el correcto funcionamiento de los componentes de forma individual. Las pruebas
se han centrado en la verificaci
on funcional de los componentes.
on de datos sufre de un problema en la interaccion con la tarjeta de
alimentaciones. Se trata de que si esta alimentado u
nicamente por USB, los pines de salida
digitales se configuran a cero con una resistencia, lo que hace que apague ocasionalmente
algunos de los dispositivos. Se ha resuelto asegurandose que la tarjeta de alimentaciones tiene
el interruptor correspondiente a la tarjeta de adquisicion de datos encendido.
Se han realizado pruebas en exterior que contemplan el funcionamiento simultaneo de
varios servants. Estos

son el robot base, la tarjeta de adquisicion de datos, el GPS y el sensor
laser. Esto implica que otros m

odulos desarrollados, como la tarjeta de alimentaciones y el
sensor i/v, han sido correctamente integrados, ya que el sistema de control usado controlo el
robot a traves de las interfaces IDL proporcionadas.
7.2.
Validaci
on de los requisitos
Se har
a un repaso breve de la verificacion efectuada sobre cada requisito.
Requisito 1: Establecer base de desarrollo. Este requisito ha sido validado a lo largo del
desarrollo de los m
odulos. El hecho de existir nuevos modulos funcionando sobre la plataforma
da por valido la verificaci
on del requisito.
Requisito 1.1: Integraci
on de un ordenador de a bordo. Se han abierto constantemente
consolas remotamente desde la instalacion del sistema operativo para configuracion, instalacion, etc.
Requisito 1.1.1: Sistema operativo en tiempo real. Se han seguido los pasos para la isntalacion de Linux RTAI en el sistema. El u
ltimo paso consiste en comprobar que funciona. Los
comandos crticos para esta verificacion son:
77
Y PRUEBAS
CAPITULO 7. VALIDACION
#
#
#
#
78
cd /usr/realtime/testsuite/modules
insmod rtai_hal.ko
cd /usr/realtime/testsuite/kern/cd latency
./run
Esto
comenzar
a la ejecuci
on de la prueba. Se ha probado con el procesador en reposo y
ejecutando programas convencionales que ocupan el 100 % de la CPU. El resultado es una
salida del programa en forma de listado cuya u
ltima columna indica el n
umero de overruns.
En todos los casos ha sido de 0, validando el requisito.
Requisito 1.1.2: Elaboraci
on de un sistema de configuraci
on e inicializaci
on de servants.
Se puede comprobar cuando se arranca el ordenador de a bordo que los servants se inicializan
con la configuraci
on de los archivos que se encuentran en /etc/higgs.
Requisito 1.2: Desarrollo de tarjeta de alimentaciones. Es inmediato encender un dispositivo con los interruptores de la placa de alimentacion. No es necesario tener el ordenador de a
bordo encendido, por ello no se prestara el servicio remoto aunque en este caso es irrelevante;
se esta comprobando u
nicamente que se controla la alimentacion a los dispositivos.
Requisito 1.2.1: Los dispositivos se controlar
an individualmente. Como el anterior, solo
que se accionan los interruptores especficos del canal que se quiera controlar. Debajo de cada
interruptor est
a indicado con una etiqueta el dispositivo que controla.
Requisito 1.2.2: Apagado manual de dispositivos.
quisito anterior.
La verificacion coincide con la del re-
Requisito 1.2.3: Apagado remoto de dispositivos. Similar a la verificacion del requisito

1.2.1 salvo que en lugar de accionar los interruptores manualmente, se dejan todos encendidos
y mediante el cliente de pruebas desarrollado para la tarjeta de adquisicion de datos y que
apaga y vuelve a encender cada dispositivo aproximadamente cada segundo, queda verificado
el requisito.
Requisito 2: Integraci
on de sensores y actuadores. En los siguientes parrafos se encuentran
multitud de ejemplos de control de dispositivos remotos.
Requisito 2.1: Uso de la tecnologa CORBA. No hay mas que conectarse a alguno de
los servants. Muchos de los requisitos se han validado simultaneamente ya que entran en
funcionamiento muchos elementos que trabajan a la vez.
Requisito 2.2: Los objetos CORBA estar
an disponibles cuando el dispositivo lo est
e. Se
puede comprobar que si se apaga la alimentacion de cada dispositivo, las referencias a objetos
CORBA dejan de ser v
alidas. Cuando se llama a un metodo remoto en estas condiciones se
recibe una excepci
on TRANSIENT. Cada modulo ha sido dise
nado prestando mucha atencion
a este requerimiento. Se han a
nadido hilos de ejecucion a modo de watchdog y se capturan
los errores en la comunicaci
on.
Y PRUEBAS
79
Requisito 2.3: Recuperar funcionalidades autom

aticamente. Continuacion de la verificacion anterior. Durante el arranque del ordenador de a bordo o despues de la cada de un
dispositivo, se puede observar en los logs como los scripts de inicio tratan de ejecutar los
servants continuamente hasta que es fructfera por estar el dispositivo fsico nuevamente operativo. Los servants se han desarrollado cuidadosamente para ofrecer este comportamiento.
on de sensores propioceptivos.
Requisito 2.4.1: Integraci
on de una br
ujula electr
onica.
on de aceler
ometros.
on de sensores de tensi
on e intensidad. Estos cuatro requisitos
se validan con llamadas remotas al servant del Arduino. Cada uno tiene un metodo en la
interfaz IDL. Basta con llamar a los tres metodos1 en secuencia para efectuar la validacion.
on de sensores exteroceptivos. Validando cualquiera de los requisitos derivados se valida este.
on de una c
amara direccionable.
derivados se valida este.
Validando los dos requisitos
Requisito 2.5.1.1: Integraci

on de la c
amara estereosc
opica existente. Validado parcialmente. La conexi
on CORBA funciona correctamente cuando el servant y el cliente estan en
el mismo computador, pero no as cuando corren en computadores distintos porque apare
cen retardos mayores al segundo y el refresco es tambien demasiado bajo. Esto
es as por el
ancho de banda requerido para transmitir los datos de vdeo, que no estan optimizados para
streaming.
on de la mu
neca. Al igual que modulos anteriores, es posible
controlar remotamente la mu
neca usando los dos clientes CORBA desarrollados. El primer
cliente realiza un bucle que enva comandos de vaiven alternativos de amplitud creciente. A
continuaci
on se muestra este c
odigo como ejemplo representativo para los demas modulos y
en el que se observa la sencillez con la que se pueden escribir clientes:
1
2
3
4
5
6
7
8
9
10
11
12
13
# include <i o s t r e a m >

# include " wristC .h"
# include " CosNamingC .h"
# include " ../../../ lib/ CORBA_utils .h"
int main ( int argc , char * argv [ ] ) {
CORBA BEGIN CLIENT( argc , argv ) ;
CORBA GET REFERENCE( h i g g s : : w r i s t , w r i s t , " wrist " ) ;
w r i s t >s e t
w r i s t >s e t
w r i s t >s e t
w r i s t >s e t
float f =
1
max
max
max
max
.1F;
speed ( 6 .F,
accel (5.F,
accel (2.F,
speed ( 4 .F,
higgs
higgs
higgs
higgs
::
::
::
::
wrist
wrist
wrist
wrist
: : PITCH) ;
: : PITCH) ;
: : ROLL) ;
: : ROLL) ;
En el manual del usuario, anexo C, se dan detalles para llevarlo a cabo.
Y PRUEBAS
14
15
16
17
18
19
20
80
for ( int i = 0 ; i < 9 ; i ++)

{
w r i s t >s e t p o s i t i o n ( 0 . 3 * f , h i g g s : : w r i s t : : PITCH) ;
w r i s t >s e t p o s i t i o n ( 0 . 3 * f , h i g g s : : w r i s t : : ROLL) ;
while ( ! w r i s t >i s r e a d y ( h i g g s : : w r i s t : : PITCH) )
{
s t d : : c o u t << w r i s t >g e t c u r r e n t ( h i g g s : : w r i s t : : PITCH) <<
std : : endl ;
}
w r i s t >w a i t ( h i g g s : : w r i s t : : BOTH) ;
f += ( f > 0 ) ? 0 . 1 : 0.1;
f *= 1;
}
w r i s t >s e t p o s i t i o n ( 0 . F , h i g g s : : w r i s t : : BOTH) ;
w r i s t >w a i t ( h i g g s : : w r i s t : : BOTH) ;
21
22
23
24
25
26
27
28
29
30
31 }
CORBA END CLIENT ;

return 0 ;
El segundo cliente consiste en un control de la mu

neca con el raton del ordenador donde
reside el cliente. Como nota curiosa, con esta aplicacion se ha conseguido enga
nar a algunos
visitantes haciendoles pensar que el robot realizaba reconocimiento y seguimiento de rostros2 .
on del dispositivo l
aser. El cliente de pruebas desarrollado lista
por pantalla las distancias medidas por el sensor laser. Este cliente ha sido ejecutado remotamente, validando el requisito.
on del receptor GPS. Debido a la perdida de cobertura de la
conexion wifi en exteriores, no ha sido posible verificar este requisito tal y como se redacto. Sin
embargo, s se ha logrado conectar con el servant y recibir los datos de posicion y velocidad con
un cliente corriendo localmente. No hay motivos para pensar que con una conexion adecuada
se pueda acceder remotamente a estos datos.
Por otra parte, se han hecho pruebas usando el receptor GPS situado en el atico. Como
no se puede considerar que esta configuracion de los componentes del GPS este integrada en
el robot tampoco es v
alido para verificar el requisito.
on del sistema de correci
on diferencial del GPS. La correccion
diferencial sufre de los mismos problemas que el GPS sin correcciones. Adicionalmente la
estacion base tiene que estar operativa y se deben recibir las correcciones va radio.
Tan solo en una ocasi
on y durante unos breves instantes se consiguio leer la posicion del
robot en exteriores con un error de menos de medio metro. Se logro en el centro del campo
de futbito. Lamentablemente, se estaban haciendo pruebas de protocolo y el servant a
un no
2
El objetivo de este proyecto es proporcionar la base para lograr estas capacidades con sistemas de control
que usen los servants del robot.
Y PRUEBAS
81
estaba desarrollado, por lo que la comprobacion se hizo visualmente a traves del terminal. Se
llego a una desviaci
on est
andar de 0.2m.
Al parecer existen sistemas de interferencia de la se
nal de radio en el entorno del campus
universitario provenientes de edificios gubernamentales cercanos. Se ha especulado que este
es el motivo de no recibir la correcci
on diferencial.
Requisito 3: Uso de est
andares y optimizaci
on en el desarrollo. Todos los servants desarrollados son conformes a C++ est
andar salvo el modulo de la tarjeta de adquisicion de datos
que esta escrito en Java. El software propietario se ha limitado a estos casos:
1. Diagramas convencionales con Omnigraffle.
2. Diagramas UML con RSA.
3. Primera verificaci
on de funcionamiento con el software de control del GPS incluido en
el paquete.
4. Dise
no de las tarjetas con OrCAD.
Captulo 8
Aspectos de la direcci
on de proyectos
8.1.
Presupuesto
Concepto
Robot Pioneer 2AT-8
C
amara STH-MDCS-C
Sony Vaio 11
Br
ujula CMPS03
Aceler
ometro 300019
Powercube 2 GDL
L
aser SICK LMS200
Sistema GPSd
Arduino Mega
Total
Precio
7.434,00e
876,00e
1.505,41e
39,90e
42,20e
3.400,00e
1.230,00e
18.500,00e
46,95e
33.074,46e
Cuadro 8.1: Presupuesto del sistema de partida.

Concepto
Pedido de componentes 13/10/2009
Fabricaci
on de PCB
Cables y convertidores USB-RS232
Proyectante (23 meses, 900e/mes)
Total
Precio
63,11e
235,33e
140,25e
122,71e
106,80e
60,07e
85,10e
20.700,00e
21.513,37e
Cuadro 8.2: Presupuesto del proyecto.
82
Sensor de tensin
e intensidad
Familiarizacin
con el robot
Formacin en
CORBA
Prtico y cableado
Integracin en el
laboratorio
Figura 8.1: Estructura de Descomposicion del Proyecto.

Prevencin de
impactos
Mdulo GPS
Librera Executive
Instalacin de los
mdulos
Sistema
Operativo
Redaccin de los
manuales
Validacin del
sistema completo
Validacin de
cada mdulo
Validacin de los
requisitos y
pruebas
Conversin a
CMake
Desarrollo del
entorno e
integracin
Mdulo del lser
Mdulo del
Arduino
Mdulo de la
mueca
Desarrollo del
software
Presentacin de
resultados
peridicamente
Tarjeta de
alimentaciones
Desarrollo del
Hardware
Definicin de
objetivos
Toma de contacto
y formacin
Reuniones
peridicas
Seguimiento de
proyecto
ESTRUCTURA DE DESCOMPOSICIN DEL PROYECTO

DESARROLLO E IMPLANTACIN DE PLATAFORMA
ROBTICA MVIL EN ENTORNO DISTRIBUIDO
Cierre del
proyecto
Redaccin del
proyecto
Elaboracin de
conclusiones
DE PROYECTOS
CAPITULO 8. ASPECTOS DE LA DIRECCION
83
DE PROYECTOS
CAPITULO 8. ASPECTOS DE LA DIRECCION
Figura 8.2: Diagrama de Gantt.
84
Captulo 9
Conclusiones y trabajo futuro

En este captulo se har
a un balance global del proyecto, repasando el trabajo realizado,
algunos incidentes y logros y las observaciones destacables que han ido surgiendo durante
su desarrollo. Se seguir
a comentando algunos de los desarrollos actuales sobre el robot que
escapan del alcance de este proyecto y se plantean trabajos futuros que resuelven problemas
o mejoras propuestas durante el desarrollo de este proyecto y que no estaban contempladas
en los requisitos iniciales.
9.1.
Conclusiones
Se han alcanzado los objetivos principales planteados al inicio del proyecto. Se ha logrado
el funcionamiento remoto de todos los sistemas y se ha facilitado documentacion que permita
el uso y la continuidad del proyecto.
La complejidad y su extensi
on hacen de este el mayor proyecto realizado por el autor
hasta la fecha.
Algunos de los m
odulos desarrollados no tienen nada que envidiar a sus homologos profesionales. Se podra comercializar algunos de estos desarrollos y as sacar rentabilidad a los
productos provenientes de investigacion.
En el mercado existen multitud de sensores que resuelven parte de la problematica que
existe con el robot. Por ejemplo, existen camaras direccionables comercialazadas como un
paquete cerrado y con drivers est
andar. Descartar la camara y la mu
neca en beneficio de uno
de estos paquetes habra ahorrado tiempo de desarrollo y dinero, pues el coste de tener una
persona desarrollando estos m
odulos durante varios meses es alto.
Colaboraci
on con otros grupos
La comunicaci
on con el resto de personal del departamento ha sido continua y ha permitido
la colaboraci
on con otros grupos de investigacion dentro de la universidad, en concreto con
el grupo de investigaci
on en Control Inteligente. Las funciones programadas que realizan la
sincronizaci
on del protocolo del sensor laser fueron integradas en el codigo fuente del driver
desarrollado por ellos mismos, probadas y devueltas con las modificaciones realizadas. Esta
colaboraci
on se ha traducido en una reduccion del tiempo de desarrollo del driver del laser al
tener ya implementado y probado las funciones mas importantes suministradas por el sensor
laser. Tambien ha aportado mayor fiabilidad y robustez a los robots de ambos grupos al no
85
CAPITULO 9. CONCLUSIONES Y TRABAJO FUTURO
86
Figura 9.1: La plataforma rob

otica movil, bautizada como Higgs, en todo su esplendor.
hacerse necesario reiniciar el software de control cada vez que surge alg
un problema en la
comunicaci
on, como la perdida en la transmision de alg
un byte.
Calidad y robustez
Durante una de las pruebas se produjo un accidente por el cual el cable de carga de las
bateras qued
o aprisionado por las ruedas del robot. Al avanzar este, tiro del cable produciendo
su rotura en el interior del conector jack y formandose un cortocircuito en la alimentacion,
tanto del cargador de bateras como de las bateras. El cortocircuito se cerro formando un
circuito en serie formado por la batera, la resistencia shunt, la placa de alimentaciones y
el conector del cargador con el fallo. La buena eleccion en los componentes de la placa de
alimentaciones y el grosor de las pistas hizo que esta no presentara ning
un desperfecto tras el
fallo, no as la resistencia shunt, que supero los valores maximos de funcionamiento y produjo
una peque
na explosi
on por calentamiento repentino por efecto Joule, haciendo las veces de
fusible improvisado del circuito. Gracias a ello solo hubo que cambiar la resistencia shunt y
reparar el cable del cargador para que el robot recuperara la funcionalidad. De esta manera
se comprob
o la calidad de los componentes desarrollados afectados en este accidente.
87
Ingeniera aplicada
El desarrollo de este proyecto ha incluido partes en las que se ha tenido que hacer uso
de los conocimientos te
oricos aprendidos a lo largo de la carrera y aplicarlos en la vida real.
Las dificultades que aparecen son de otra naturaleza y se ha tenido que lidiar con ellas,
como ejemplo m
as claro est
a el sensor i/v en el que las resistencias disponibles en el mercado
sobrepasaban las tolerancias admisibles en el circuito dise
nado, y aun as se ha podido realizar
gracias al conocimiento de los metodos de produccion en serie de las resistencias en las que
artculos de un mismo lote son mucho mas parecidos que artculos de lotes distintos.
9.2.
Lneas de desarrollo actualmente abiertas
La plataforma rob
otica m
ovil es un proyecto en continuo desarrollo, por ello antes de la
finalizacion de este proyecto fin de carrera se realizaron unas modificaciones no contempladas
en los requisitos iniciales. Estas modificaciones son principalmente tres: La actualizacion de
la camara estereosc
opica, la integracion del sensor de profundidad y vdeo Kinect y el uso de
la librera de rob
otica ROS.
9.2.1.
Webcam
La camara con la que se ha trabajado en este proyecto presenta una serie de inconvenientes
que han llevado a la adquisici

on de otra camara. Estos
inconvenientes son:
Vi
neteado muy acusado.
Enfoque y apertura del diafragma manual.
Distorsi
on de los colores hacia el verde.
Algunos de estos defectos pueden estar debidos al driver de la camara. c La nueva camara
no solamente presenta mejor calidad en el color, sino que carece del efecto de vi
neteado de
la anterior y las im
agenes en movimiento quedan mas ntidas. Usa el protocolo relativamente
moderno UVC. Sin embargo las im
agenes de ambas camaras no estan sincronizados lo que
puede dar lugar a c
alculo incorrecto de la profundidad de objetos en movimiento. En realidad
se trata de dos webcam independientes con un hub USB para compartir la conexion, por lo
que ademas no se puede usar ambas camaras a su maxima resolucion simultaneamente.
9.2.2.
ROS
ROS (Robot Operating System) suministra libreras y utilidades para ayudar a desarrolladores de software crear aplicaciones roboticas. Suministra abstraccion de hardware y drivers
para una gran variedad de dispositivos usados en robotica, libreras, visualizadores, paso de
mensages y gesti
on de paquetes, entre otros. Puede plantearse como un reemplazo de CORBA
especfico para rob
otica, aunque no tiene la flexibilidad ni la capacidad de tiempo real.
Su funcionamiento se basa en la publicacion de mensajes a un broker central y envo
de estos mensajes a los nodos que lo soliciten. Los nodos pueden ser drivers de dispositivo,
transformadores de datos, visualizadores, etc.
Se han realizado pruebas satisfactoriamente para el manejo simultaneo del laser, el kinect,
el robot base Pioneer y un mando de control Wiimote en aplicaciones de navegacion en
interior.
88
Es la lnea de trabajo con la que actualmente se esta trabajando debido a la facilidad y la

velocidad de desarrollo permitidos y a la disponibilidad de una amplia variedad de libreras
enfocadas hacia rob
otica.
9.2.3.
Kinect
Kinect es el sensor de Microsoft para la consola XBox 360, aparecido en el mercado en

noviembre de 2010. Debido al gran exito que ha tenido no solo comercialmente sino tambien
en los laboratorios de investigaci
on, en junio de 2011 Microsoft desarrollo una librera para el
uso del sensor desde computadores personales.
Figura 9.2: El sensor Kinect de Microsoft

La caracterstica fundamental de este sensor reside en la capacidad de detectar profundidades como si de una c
amara se tratara, pudiendose realizar mapas 3d del entorno con
facilidad. Tambien incorpora una c
amara convencional en la misma direccion que el sensor de
profundidad, un micr
ofono y un motor que inclina el sensor verticalmente. Puede substituir
las camaras estereosc
opicas y reduce la carga de procesamiento que imponen estas al no tener
que calcular la profundidad a partir de dos imagenes estereoscopicas.
La librera ROS (secci
on 9.2.2) incluye un paquete para controlar este sensor, con el que
se han realizado satisfactoriamente algunas pruebas de navegacion.
9.3.
Trabajos futuros
La plataforma rob
otica, al estar en continuo desarrollo, admite una gran cantidad de
ampliaciones y el trabajo que se realice en nuevas funcionalidades esta limitado u
nicamente
por la imaginaci
on.
9.3.1.
Estaci
on de carga
Para que un robot sea completamente autonomo ademas de comprobar su nivel de energa
debe restaurarlo cuando se reduce. Se propone la realizacion de una estacion de carga a la
que el robot pudiera acoplarse sin intervencion humana y recargarse, de modo que pudiera
completar la tarea a pesar de necesitar varias cargas de bateras para completarla.
9.3.2.
89
Optimizaci
on del envo de vdeo
Uno de los inconvenientes que presenta actualmente la interfaz CORBA para la camara
estereoscopica es el bajo rendimiento en el envo de datos. La solucion que se propone, a
incorporar en el futuro, es modificar la interfaz de manera que se use CORBA para configurar
un sistema de streaming de video usando comunicaciones asncronas UDP/IP para lo cual
existen infinidad de paquetes software en Internet. As el vdeo se enviara comprimido y sin
la perdida de ancho de banda necesario en comunicaciones sncronas y del protocolo IIOP
de CORBA, dejando parte de la conexion wi-fi libre para otras comunicaciones mas crticas,
aunque se perdera tiempo de CPU del ordenador de a bordo en la compresion del vdeo.
9.3.3.
Uso de bateras de litio
Las bateras de plomo son pesadas y sufren de efecto memoria si se las descarga demasiado.
Las bateras de litio son ligeras y no sufren del efecto memoria, sin embargo necesitan un
circuito electr
onico que controle las cargas ya que una carga en exceso puede calentarlas en
exceso o incluso pueden llegar a explotar, y descargarlas al maximo las da
na irreversiblemente.
9.3.4.
Panel solar
Se ha propuesto la instalaci
on de un panel solar que cubra toda la parte superior del
robot para aumentar el tiempo de autonoma de las bateras en exteriores, y si la potencia es
suficiente, eliminar la necesidad de bateras y as reducir el peso total del robot.
Bibliografa
[1] Leslie Lamport, LATEX: A Document Preparation System. Addison Wesley, Massachusetts, 2a Edici
on, 1994.
[2] Rainer Granados, Jose Javier y Galan Lopez, Ramon (2010) URBANO: A Tour-Guide
Robot Learning to Make Better Speeches.
[3] I. Navarro, Collective Movement in Robotic Swarms, Tesis Ph.D., UPM, Madrid, 2010.
[4] Siciliano y Kathib. Springer Handbook of Robotics. s.l.: Springer, 2008.
[5] Jose Luis S
anchez L
opez. Sistema de control para el seguimiento de trayectorias de un
UGV no holon
omico tipo Ackermann, PFC, UPM, Madrid, 2010.
[6] Michi Henning y Steve Vinoski. Advanced CORBA Programming with C++. Ed.
Addison-Wesley, 1999.
[7] Bjarne Stroustrup, The C++ Programming Language, Tercera Edicion, Ed. AddisonWesley, 1997.
[8] Andreas Vogel, Bhaskar Vasudevan, Maira Benjamin y Ted Villalba. C++ Programming
with CORBA. Ed. Wiley, 1999.
[9] Dimitri van Heesch. Doxygen: Manual for version 1.3.2. 2003.
[10] Grady Booch, James Rumbaugh y Ivar Jacobson. The Unified Modeling Language User
Guide, Segunda edici
on, Addison-Wesley
[11] Jose Alberto Arcos. Sistema de navegaci
on y modelado del entorno para un robot m
ovil.
PFC, UPM, Madrid, 2009.
[12] Antonio Barrientos, Luis Felipe Pe
nn, Carlos Balaguer, Rafael Aracil. Fundamentos de
rob
otica, McGraw-Hill, 1997
[13] Ricardo Carelli. Control de robots m
oviles. Conferencia ETSII UPM. 2009.
[14] Crcosi, I. Ortiz y Alejo, F.J. S
anchez. El Proyecto Fin de Carrera. Normas de realizaci
on,
presentaci
on y defensa. Secci
on de puclicaciones de la ETSII UPM. 2005.
[15] Marcos Salom Garca. Fusi
on Sensorial en Plataforma Rob
otica M
ovil. PFC, UPM, Madrid, 2009.
[16] Adolfo Hernando Marcos. Versi
on RT-CORBA del servidor Pioneer 2AT-8. PFC, UPM,
Madrid, 2005.
90
Ap
endice A
Esquemas de la placa de alimentaciones
91

APENDICE
A. ESQUEMAS DE LA PLACA DE ALIMENTACIONES
Figura A.1: Esquema del canal de 12V de la placa de alimentaciones
Figura A.2: Esquema del canal de 24V de la placa de alimentaciones
92

APENDICE
Figura A.3: Esquema general de la placa de alimentaciones
93

APENDICE
Figura A.4: Distribuci

on de pistas en la capa superior de la placa de alimentaciones
94

APENDICE

on de pistas en la capa inferior de la placa de alimentaciones
95

APENDICE
Figura A.6: Serigrafa de la placa de alimentaciones
96

APENDICE

on y di
ametro de los orificios de la placa de alimentaciones
97
Ap
endice B
Manual de referencia de la librera executive
98
libexecutive
Generated by Doxygen 1.6.1
Tue Sep 27 12:20:45 2011
Contents
1
Class Index
1.1
Class List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class Documentation
2.1
executive::callbacks Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1
Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
executive Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1
2.2.2
Member Function Documentation . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2.1
compute_all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2.2
get_all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2.3
set_all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2.4
wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
executive_attribute< T > Class Template Reference . . . . . . . . . . . . . . . . . . . . .
2.3.1
2.3.2
Constructor & Destructor Documentation . . . . . . . . . . . . . . . . . . . . . .
2.3.2.1
executive_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2.2
2.3.2.3
Member Function Documentation . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3.1
subscribe_compute . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3.2
subscribe_consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3.3
2.3.3.4
Member Data Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4.1
value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
phony Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1
2.2
2.3
2.3.3
2.3.4
2.4
Chapter 1
Class Index
1.1
Class List
Here are the classes, structs, unions and interfaces with brief descriptions:
executive::callbacks (Do not use. Internal use ) . . . . . . . . . . . . . . . . . . . . . . . . . .
executive (Asynchronous event dispatcher with the hybrid Push/Pull model ) . . . . . . . . . . .
executive_attribute< T > (Stores an attribute and manages the supplier, consumers and computers associated with that attribute ) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
phony (Auxiliary class that helps circumvent C++ type safety. Please ignore ) . . . . . . . . . .
3
4
6
9
Chapter 2
Class Documentation
2.1
executive::callbacks Struct Reference
Do not use. Internal use.

#include <executive.h>
Public Attributes
2.1.1
phony obj
void(phony:: async_get )()
void(phony:: async_set )()
void(phony:: async_compute )()
Detailed Description

The documentation for this struct was generated from the following file:
executive.h
Class Documentation
2.2
executive Class Reference
Asynchronous event dispatcher with the hybrid Push/Pull model.

Classes
struct callbacks
Public Member Functions
void get_all ()
void set_all ()
void compute_all ()
void wait ()
Waits for all threads to terminate.
void cycle ()
Gets and waits. Sets and waits. Computes and waits.
Public Attributes
std::vector< callbacks > callbacks_pool
std::list< pthread_t > thread_pool
2.2.1 Detailed Description

Asynchronous event dispatcher with the hybrid Push/Pull model.
Author:
Francisco J. Arjonilla Garca
Date:
April 2010
Each instance saves a data value to be distributed amongst the consumers. Do not modify the data in
executive, just call the methods.
USAGE: Create an executive. Then create the attributes passing the executive just created. When creating the attributes the object and pointer to method must point to the supplier. Afterwards subscribe the
consumers and the compute methods and finally while(1) ev_mgr.cycle();
Create one instance of executive_attribute for each data value to be tracked. The interface for the
callback methods must be like: attribute_t get(); set(attribute_t); compute();
Generated on Tue Sep 27 12:20:43 2011 for libexecutive by Doxygen
2.2 executive Class Reference
Note:
Include the pthread library when linking (-lpthread).
Warning:
Although it creates and uses threads, the interface is not itself thread safe.
2.2.2
Member Function Documentation
2.2.2.1
void executive::compute_all ()
Creates a thread for each computer for each attribute and asynchronously calls them.
2.2.2.2
void executive::get_all ()
Creates a thread for each supplier and asynchronously gets the value for each attribute by calling the
suppliers.
2.2.2.3
void executive::set_all ()
Creates a thread for each consumer and asynchronously passes the value for each attribute and in each
consumer by calling asynchronously all the consumers for that attribute.
2.2.2.4
void executive::wait ()
Waits for all threads to terminate. These threads are those created with get_all(), set_all() and
compute_all().
The documentation for this class was generated from the following files:
executive.h
executive.cc
Class Documentation
2.3
executive_attribute< T > Class Template Reference
Stores an attribute and manages the supplier, consumers and computers associated with that attribute.
Classes
struct computer
struct consumer
struct supplier
Public Member Functions

template<class O >
executive_attribute (executive &ex, O obj, T(O::get)() const)
template<class O >
executive_attribute (executive &ex, O obj, T (O::get)())
template<class O >
executive_attribute (executive &ex, O obj, T &(O::get)())
template<class O >
void subscribe_consumer (O obj, void(O::set)(T))
template<class O >
void subscribe_consumer (O obj, void(O::set)(T ))
template<class O >
void subscribe_consumer (O obj, void(O::set)(const T &))
template<class O >
void subscribe_compute (O obj, void(O::compute)())
Public Attributes
T value
2.3.1
Detailed Description
template<class T> class executive_attribute< T >

Stores an attribute and manages the supplier, consumers and computers associated with that attribute. Subscribe the consumers and computers before calling the executive s methods. TODO: Unsubscribing
not implemented, you must delete the executive_attribute instance and create it again without the desired
callbacks.
2.3.2
Constructor & Destructor Documentation
2.3.2.1
template<class T > template<class O > executive_attribute< T >::executive_attribute

(executive & ex, O obj, T(O::)() const get) [inline]
Parameters:
ex The executive that will keep track of the value associated with this attribute.
2.3 executive_attribute< T > Class Template Reference
obj The object to which the get call applies.

get Pointer to member method that supplies the attribute by polling it. It must be of the form
attribute_t get_t::get_method();
Retrieve the pointer to member method with &get_t::get_method .
2.3.2.2

(executive & ex, O obj, T (O::)() get) [inline]
The
same
as
executive_attribute(executive & ex, O obj, T
(O::get)()const) when the supplier returns a pointer to the attribute and executive_attribute must
take care of that memory.
Parameters:
ex The executive that will keep track of the value associated with this attribute.
obj The object to which the get call applies.
get Pointer to member method that supplies a pointer to the attribute by polling it. The caller is
responsible for deallocating the pointer, so the supplier must return a pointer to a memory it
will not manage after returning. get must be of the form attribute_t get_t::get_method();
Retrieve the pointer to member method with &get_t::get_method . TODO: Not tried
with arrays. Probably will not work, as it needs an additional argument indicating the number of
elements in the array.
Warning:
Uses delete to dealloc the memory, which is not portable when using CORBA.
2.3.2.3

(executive & ex, O obj, T &(O::)() get) [inline]
The
same
as
executive_attribute(executive & ex, O obj, T
(O::get)()const) when the supplier returns a reference to the attribute.
2.3.3
Member Function Documentation
2.3.3.1
template<class T > template<class O > void executive_attribute< T

>::subscribe_compute (O obj, void(O::)() compute) [inline]
Parameters:
obj The object to which the compute method should be called with.
compute Pointer to member method that makes computations based on the attribute. It must
be of the form void compute_t::compute_method(); Retrieve this pointer with
&consumer_t::consumer_method .
Class Documentation
2.3.3.2

>::subscribe_consumer (O obj, void(O::)(const T &) set) [inline]
The same as void subscribe_consumer(O obj, void (O::set)(T)) when the consumer receives a reference to the attribute.
Warning:
set has const in the parameter by reference so you cannot modify the attribute.
2.3.3.3

>::subscribe_consumer (O obj, void(O::)(T ) set) [inline]
The same as void subscribe_consumer(O obj, void (O::set)(T)) when the consumer receives a pointer to the attribute.
Parameters:
obj The object to which the set (consumer) method should be called with.
set Pointer to member method that needs to read the attribute. It must be of the form void
consumer_t::consumer_method(attribute_t ); Retrieve this pointer with
Warning:
Do not forget to deallocate the pointer in the consumer method.
2.3.3.4

>::subscribe_consumer (O obj, void(O::)(T) set) [inline]
Parameters:
obj The object to which the set (consumer) method should be called with.
set Pointer to member method that needs to read the attribute.
It must be of the form
void consumer_t::consumer_method(attribute_t); Retrieve this pointer with
2.3.4
Member Data Documentation
2.3.4.1
template<class T > T executive_attribute< T >::value
The attribute that is managed. Set it instead of calling the supplier the first time to have a default value.
Read it between calls to cycle for statistics.
The documentation for this class was generated from the following file:
executive.h
2.4 phony Class Reference
2.4
phony Class Reference
Auxiliary class that helps circumvent C++ type safety. Please ignore.
2.4.1 Detailed Description

Auxiliary class that helps circumvent C++ type safety. Please ignore.
The documentation for this class was generated from the following file:
executive.h
Ap
endice C
Manual de usuario
109
Chapter 4
User Manual
4.1
Functionality description
The Robotic Control Testbed is a Mobile Robot built from a commercial robot
base with added funcionality. The robot base consists of a four wheel vehicle
with position and speed control embedded, integrated power and control
electronics and 16 ultrasonic sensors that give readings on the distance to
close obstacles. Additionally front and rear bumpers have been installed for
safeguarding the robot while operating it in very constrained areas and for
manual stopping.
The Laser range reader can measure distances from 8mm up to 80m, depending on configuration. Typically it will function with a resolution of 1mm and
a range of 8mm to 8m. It is the main sensor along with the odometer readings in SLAM navigation. It can be rotated to make three dimensional maps
with the servo. The mechanism operates in open loop mode, which gives
a low precision angular rotation, given the mechanical hystheresys and the
thermal and age deviations of set.
Next to the laser the I/O board, or data acquisition board, is a general purpose input output board that connects to a compass, a two axis accelerometer,
the laser servo that controls its tilt movement, and two current and voltage
sensors one for monitoring the consumption of the robot base and the other
for the power board and related devices. These sensors and actuators are
controlled through the I/O board module.
For outside applications there is a global absolute position sensor which consists of a GPS antenna, Radio receiver and battery for receiving differential
corrections from a base station and a GPS receiver that processes the data
and converts it to an easier format readable by the onboard computer.
Visual applications can make use of the binocular camera, which in combination with the wrist, that gives pan and tilt movement to the camera with
respect to the robot base and is located on top of the laser, can direct the focus of the attention in almost any direction. The wrist is internally controlled
in position, speed and acceleration, which gives precise and accurate motion
control to the camera.
ASLab.org / Higgs Manual / R-2010-008v 0.1 Draft
27 of 97
The onboard computer runs a full capable operating system and is the communications hub for controlling remotely all the devices on the robot. Software controlling the devices may be installed onboard or in a remote computer.
4.1.1 Visual identification of devices
Figure 4.1: General view of Higgs.
Figure 4.2: Robotic base Pioneer 2AT.
Figure 4.3: On board computer: VAIO laptop.
28 of 97
R-2010-008 v 0.1 Draft / Higgs Manual / ASLab.org
Figure 4.4: Laser sensor.
Figure 4.5: Wrist.
Figure 4.6: Camera.
Figure 4.7: Power board.
29 of 97
Figure 4.8: 12V to 24V converter.
Figure 4.9: Differential GPS set. Rover station parts.
Figure 4.10: Differential GPS set. Base station parts.
30 of 97
Figure 4.11: Input/Output board: Arduino.
Figure 4.12: Compass.
Figure 4.13: Accelerometer.
31 of 97
On board
computer
Camera
Kinect
GPSd
base
GPSd
rover
Laser
USB
hub
Wrist
Radio
Radio
Robot base
I/O sensor
x2
Current/Voltage
sensor
Power board
Laser Tilt Sensor
Compass
Accelerometer
x2
Figure 4.14: General data connection diagram
4.1.2 Data connection diagram

Arrows indicate the direction of valuable information flow.
4.2
Setting up the system

Preparing the robot for operation is easy. Power it on and all systems will
start automatically. On next sections it will be discussed how to command it.
4.2.1 Powering the robot

There are three switches that must be turned on to enable the robot with full
capabilities. The first one is at the back of the robot, next to the wheels. This
switch powers the Pioneer2AT8 robot base and the power board. The power
board has a general switch for all devices and one more for each device for
32 of 97
manual disabling. The power board is placed between the two big methacrylate structures. Each switch has a label with the device that enables. The last
device to power on is the VAIO laptop.
Note: The devices powered by the power board can be also disabled automatically by the Arduino. When the Arduino is not correctly powered on,
the voltage levels at its pins are undefined, and may disable the power to
some devices. Be sure to power the arduino if you are going to use any other
device from the power board.
Only the laptop is mandatory to power on. The other switches may stay off
if you are not going to use the device associated to that switch. However you
will have to start at least one device to make it useful.
The Arduino does not disable any device by default. Both the manual switches
and the Arduino may force the shutdown of any device, so to use a device,
be sure that none of them disables it. The automatic switches are remotely
controlled through the Arduino module.
4.3
Basic maintenance
There is little maintenance to do with the robot. The batteries are the most
important matter to be aware, followed by the wheels.
4.3.1
Wheels
Once every two months or so, the wheels will loose pressure and they must
be inflated evenly, this way the odometry will not loose precision. It can
be noticed when the wheels have deinflated by looking to the tread pattern:
Two separate bands of moist will indicate underinflation, one on the middle
overinflation, and correct inflation when moist is evenly distributed. There is
a manual pump with manometer in the cabinet.
4.3.2
Battery management
The robot has 3 battery packages. One of them is inside the Pioneer2AT8, the
other one powers the radio receiver for the differential GPS and the last one
is embedded in the laptop.
Robot base lead batteries
There are three lead battery packages inside the Pioneer2AT8 that powers
the motors, the internal electronics and the external power board. To access
them, lift the small black lever on the back side of the robot and turn it to
the left. This will loosen the battery door. Open it to 135 . You may have
to pull the door up to get the door over the bump sensors. Once it is open,
33 of 97
Laptop
Battery
On board
computer
USB
hub
x3
USB to RS232
converter
I/O board
Compass
GPSd
rover
Accelerometer
Kinect
Laser
Power Board
Wrist
Servo
Camera
12V to 24V
converter
Robot base
Robot base
batteries
GPS radio
battery
Motors
Sonar
H8 MCU
Bumpers
Legend:
12V
24V
GPSd radio
Power cable shared

with data
I/V Sensor
Figure 4.15: General power connection diagram
34 of 97
pull the batteries with the black sucker, or carefully with the hands do not
get yourself pinched. When inserting the new batteries, remember that the
battery terminals go last. Failure to introduce them correctly will cause short
circuits and damage the electronics.
Figure 4.16: Robot base charger.

Recommended voltage when using the batteries is between 11.5V and 12.5V.
If the batteries are too low the robot will indicate it with continuous short
beeps. You can check the battery status through the battery LED in the Pioneer2AT8 panel: Green when fully charge through orange downto 11.5V,
finally red. To keep the batteries in good conditions, do not discharge them
completely. Doing so will decrease the charge capacity. It is better to fully
charge them after each use.
To charge the batteries, connect the charger to the robot through the power
jack connector to the left of the battery door. Its charger is the big black one,
model PSC-124000A. You may leave the charger connected for as long as you
want, but remember to switch off the robot every night, as electricity in the
laboratory is turned off and the robot will fully discharge the batteries in this
time, damaging them.
GPSD radio battery
There are two radio batteries, one for the GPS base station and the other for
the GPS mobile station. Both batteries are interchangeable, and are 8x9x23cm
in size with a black leather cover. Ni-MH batteries have memory effect, so
35 of 97
you must discharge them completely before charging them again. There are
two chargers. you may found them in the yellow suitcase in the F room or
in a white long box next to the suitcase. Remember that the F room is the
name for the ASLab cabinet in the computer rack room. To charge it, open
the battery tab and connect the charger. Press the button for discharging it
fully, then wait until the charger finishes the operation. Detailed instructions
are printed on the charger.
Figure 4.17: GPSD radio charger.
VAIO laptop battery

The VAIO laptop manages automatically its own battery. You may check its
status with the command acpi -b. On linux RTAI, ACPI is not supported
by the kernel and it will not work so this command is unavailable.
Figure 4.18: VAIO laptop charger.
4.3.3 Diagnostics
Power
There are several indicators of malfunction that can ve verified in case the
robot does not work properly. In the first place, look for correct power in
each device. This is how you can check it:
36 of 97
Pioneer2AT There is a red LED inside the Pioneer when it is powered, but
can only be verified indirectly through reflections in the methacrylate
structure that covers the top hole of the base. Alternatively, There is a
dedicated red LED for this purpose in the Control Panel with the label
PWR.
Laptop The VAIO laptop lights a green LED when it is on.
Laser When it is powered on, a green LED or two orange and red LEDs will
be lighted in the front of the laser device. Green means powered and
prepared, orange and red means powered and initializing.
Arduino When it is powered a little orange LED can be find behind the USB
connector. A fast sanity check is to power the arduino and the servo. If
everything is OK, the Laser will rotate to look upwards in a small angle.
Wrist There is no way to verify this device externally. However, it is quite
robust and will normally work as supposed to. If everything is running
ok, it will make a little calibration movement on startup.
Camera Depends on the camera used. The black stereoscopic one has a red
LED that blinks when the driver is reading it and the Minoru3D lights
up in white when the driver is reading it.
GPS There are two LEDs on the side. One of them indicates that power is
OK and the other lights when enough satellites for position calculation
are being tracked.
Power Board There is a green LED for the general switch and one for each
device.
4.4
Operating the robot manually

4.4.1
Booting the onboard computer and choosing the OS
The onboard computer has several operating systems installed:

WindRiver OS /dev/sda1 (1GB). This was once used as a testbench for the
WindRiver OS. It is several years old and is not used any more.
Windows XP Professional /dev/sda2 (25GB). The original Windows OS
prepackaged with the laptop. The NovAtel GPSD utilities have been
installed here for quick GPS diagnostics.
Ubuntu 10.04 Long Term Service /dev/sda3 (14GB). This is the current working environment, with Real Time Application Interface (RTAI) kernel.
Fedora 13 /dev/sda5 (29GB). Has the previous working environment, with
CORBA modules and depending on the nameserver in the old onboard
computer. Has a custom driver for supporting the FireWire camera.
37 of 97
Swap partition /dev/sda6 (100MB).

On bootup there is a selection of the operating system to start. It includes
Ubuntu with and without real time kernel, a RAM memory test and the other
three OSs. The default OS is Ubuntu with the RTAI kernel. Note that only
the current working OS, that is, the Ubuntu with RTAI kernel, is documented
here. The other operating systems are old but kept for backup and compatibility with old software.
Shutting down.
The correct procedure to shut down the onboard computer is to log in as root
and request shutdown:
root@higgs2:/root# halt
Forcing instant shutdown using the power button is not recommended, however, normally there has been no problem with the OS afterwards.
4.4.2 Loggin in to the onboard computer through SSH

The Secure SHell server is run in the onboard computer by default and open
to everyone that has a user account or the root password. The root password
is the same as the root password for all the computers in the laboratory. Ask
your tutor for a local account on higgs or the root password. Access can be
obtained by opening a terminal and executing the command
your-pc:/$ ssh account_in_higgs@higgs2
and root access by changing account in higgs with root. If you want to
execute programs that use a graphical interface, create a ssh tunnel for X with
the option -X:
your-pc:/$ ssh -X account_in_higgs@higgs2
This way the program will execute in the onboard computer and display in
your local screen remotely. In case you get this error while trying to connect:
ssh: Could not resolve hostname higgs2:\
Name or service not known
then you have a problem with the name resolution on your computer. Copy
these lines to /etc/hosts as root to solve it:
127.0.0.1 localhost
38 of 97
138.100.76.251
sagan.aslab.upm.es sagan
138.100.76.20
138.100.76.26
138.100.76.250
138.100.76.239
138.100.76.252
138.100.76.244
138.100.76.243
138.100.76.217
138.100.76.241
138.100.76.204
noe.aslab.upm.es noe
churchill.disam.etsii.upm.es churchill
quark.disam.etsii.upm.es quark
parker.disam.etsii.upm.es parker
aldiss.disam.etsii.upm.es aldiss
corea.disam.etsii.upm.es corea
mingus.disam.etsii.upm.es mingus
verne.disam.etsii.upm.es verne
gibson.disam.etsii.upm.es gibson
pohl.disam.etsii.upm.es pohl
138.100.76.15 ende.disam.etsii.upm.es ende

# 138.100.76.196 luna.disam.etsii.upm.es luna
138.100.76.196 arturo-desktop.disam.etsii.upm.es arturo-desktop
138.100.76.247 higgs.disam.etsii.upm.es higgs
138.100.76.246 higgs2.disam.etsii.upm.es higgs2
Now your computer knows how to translate the hostnames of the laboratory
to IPs. Alternatively, if in a rush substitute higgs2 with its IP, as in
your-pc:/$ ssh local_account@138.100.76.246
The machine with name higgs corresponds to the old on board computer
which was embedded inside the robot base.
Once logged in to higgs2, applications can be run as in a standard linux distribution. Linux RTAI runs a normal kernel with standard functionality ontop
of the realtime features. For using realtime, the programs must be loaded
directly into the kernel as modules. All other programs run in soft real time.
On bootup, the onboard computer will connect automatically to the wireless
accesspoint aslab wireless. This accesspoint is in the same network as
the other computers. The connection is configured using the ESSID of the
wi-fi hotspot and the MAC address too.
4.5
Testing the modules

The CORBA servants access the NameService to publish their services1 . The
table 4.1 shows the ids used by each module, being the kind parameter
empty for all of them.
1
If appropriate module is installed and running.
39 of 97
Description
Camera
I/O Board
Robot base
Wrist
Battery Model
Current Monitor
Laser
GPS
IDL
Camera.idl
Arduino.idl
Pioneer2AT.idl
wrist.idl
BatteryModel.idl
BatteryModel.idl
Laser.idl
gps.idl
Name Service ID
CAMERA
Arduino
PIONEER
wrist
BatteryModel
CurrentAverage
LASCOR
GPS
Table 4.1: Names of the CORBA objects registered in the NameServer.
4.5.1 Subversion.
The device modules have test programs that can be run either locally from the
onboard computer or remotely without needing to log in. This section and
the next one are a quick guide for reconfiguring and troubleshooting easy
problems with the devices. Any problem not solved here requires further
understanding of the robot software mechanisms and are described in the
developer manual.
The first thing to do is download the source code. Supposing you already
have installed the necessary programs and libraries, type
svn co svn+ssh://sagan/home/svn_repositories/Higgs
to check out the source. Again, replace sagan with 138.100.76.251 if your
hosts.conf is not correctly configured and prepend it with your user name
and an @ if your server user is not the same as the local user.
There is a second repository with older modules and code that have not yet
been ported to the new CMake - subversion schema.
svn co svn+ssh://sagan/home/svn_root[/Higgs]
An even older CVS repository exists too.
4.5.2 Subversion directory hierarchy

Once finished, three directories will be available:
trunk The latest code available using the technology currently in development in the robot, which is ROS at the time of this writing.
branches Alternative code using other technologies, which currently is only
CORBA.
docs The source code of this document.
40 of 97
This is the resumed directory tree inside branches/CORBA:

code
|-- LowLevelControl
|-- WorldModel
|-- batteries
|-- control_libraries
|-- devices
|
|-- arduino
|
|-- camera
|
|-- gps
|
|-- laser
|
|-- vaio_tools
|
-- wrist
|-- idl
-- lib
The directories to consider when programming new clients are:
code/idl Contains the IDL definition files of all the modules necesary for
controlling the robot. You may open it for accessing the documentation
for the interfaces and you will have to link to it for generating the stubs
and skeletons.
lib C++ macro and CMake files (See section 4.6.2) for fast client development.
4.5.3
Checking the environment for starting test programs.
Configuration files
The next sections describe how to run the test programs contained in the
CORBA branch for testing the devices.
Before running the test clients the configuration files must have been installed
for proper operation. Clients only need one configuration file:
/etc/higgs/nameservice.ip
containing the address and port of the Naming Service that the servants are
using for publishing themselves:
higgs2:9876
Configuring serial port links
On the server side there are a few more entries inside /etc/higgs, the most
important one for configuration issues being devices. This directory con-
41 of 97
tains soft links to the character devices that represent the USB to RS-232 converters in /dev. The servants open these files instead of the real devices so
they can be reconfigured without having to recompile. Usually you will modify these links when swapping the serial cables of the devices or changing the
arrangement of the USB to serial converters. Knowing which device file goes
with which device is a matter of trial and error, starting the servants and
testing wether they started or not. See 4.5.3 for more information on servant
logging.
Starting and stopping the CORBA servants
The servants use upstart, the standard utility in Ubuntu for booting the system and running the daemons. You may start or stop the servants in case you
need the correspondant devices, i.e. the laser and the robot base in ROS, or
they are not automatically started on boot.
To start a servant use:
$ start higgs_device
and to stop it,
$ stop higgs_device
where device is one of laser, wrist, gps, arduino, pioneer or any other available CORBA servant.
There is one more daemon, the CORBA Naming Service, that opens the port
9876, is always running and does not interfere with the devices.
Logs and troubleshooting
Servants print their output to a log file in the on board computer placed at
/var/log/higgs. You will have to consult these for debugging problems
with the servants such as not starting, setting the device file and checking
overall status.
4.5.4 I/O board

The next procedure is standard on all modules. Enter the directory
$(HIGGS ROOT)/branches/CORBA/code/devices/arduino/client.
Be sure to have the complete source tree, at least the code subdirectory, as
many methods rely on files situated back in the tree. Run:
cmake .; make
This will generate the CORBA stubs and headers and then compile the client
code. The binary arduino client will appear. Run it to read the parameters of the devices attached to the IO board and setreset some of the devices.
42 of 97
4.5.5
GPSd
You may want to test the full GPSd equipment with differential corrections or
only the rover part. The differential readings may not work in the campus because of interferences in the environment that blocks radio communications
between the base station and the rover.
Rover
the serial cables are correctly installed. The USB to RS232 converter should
be attached to COM1. Turn on the GPS switch. Now to the software part: Go
to
$(HIGGS ROOT)/branches/CORBA/code/devices/gps/src and run
cmake .; make. Run gps client. A command line menu will be printed
form where you can check the satellites used in the solution, the current position and speed, the standard deviation for the position and the type of differential corrections used, if any.
Base station
The software part is the same as in the Rover part, with the standard deviation reducing to 0.02m or so if the differential correction is working. Preparing the base station:
Go to the ASLab closet and locate a yellow bag. Take out the black leather
battery, the blue radio transmitter with the antenna, the white box housing
the electronics and the cables. The GPS antenna is located on the roof with
the coaxial cable hanging down the facade to the back of the room where
Higgs lives. Open a window and take it inside. Beware of your workmates
in winter! Connect it to the electronics box. Power the electronics box with
12V, for example using Higgs charger, and the radio transmitter to the battery
pack using the appropriate cable. Finally connect the electronics box to the
battery pack with the serial terminal attached to COM2. The battery pack is
internally wired to connect the serial data and the power to the cable attached
to the serial transmitter. Press power in the serial transmitter. After a few
minutes, the Tx led should start blinking every second. This is the indication
that the differential readings are being transmitted.
In the rover part, attach the three terminal cable to the blue radio receiver, the
battery pack and the COM2 port in the rover GPS electronics box. Press the
power button in the radio receiver and proceed as in the rover section.
4.5.6
Laser
Procedure is similar to the I/O board one. Go to

$(HIGGS ROOT)/branches/CORBA/code/devices/laser/src and
cmake .; make. laser client will be generated. Power the laser in the
43 of 97
robot, wait for it to go green and some more seconds for the laser servant to
start up, and run the client. A list with the distances of the latest reading will
be printed to the console.
4.5.7 Wrist
Again, the procedure is similar, only in this case the device is not read but
told the position to move to. Turn on the switch for the wrist and wait for a
little calibration movement that indicates that it is ready. It will move to the
reset position if not there before the calibration. Go to
$(HIGGS ROOT)/branches/CORBA/code/devices/wrist/src.
Two clients will appear. The first of them, wrist client, will move the two
axis with incremental span around ten times then stop. The second one,
wrist client mouse grab, will let you control the two axis with the mouse.
Once running, take the pointer to the center of the window to move the wrist
to the starting position, then slowly move the pointer and the wrist will follow it. The range of movements is limited by the servant for secure operation
whatever the input is. However, the batteries and converter may not be able
to provide the required power if fast enough movements are requested.
4.5.8 Robot base

TODO
4.6
Developing a client
4.6.1 ASLab client utility functions for CORBA
The methods for initializing the CORBA infrastructure and getting the object
references is quite complicated and always the same. The file
code/lib/CORBA utils.h contains C++ macros that ease the procedures
for setting up a client, managing the errors, reading the object references from
the nameserver and configuring itself for reaching that nameserver.
The typical client would be something like:
#include
#include
#include
#include
<iostream>
"implementationC.h"
"CosNamingC.h"
"Higgs/branches/CORBA/code/lib/CORBA_utils.h"
int main(int argc, char* argv[])

{
CORBA_BEGIN_CLIENT(argc, argv);
CORBA_GET_REFERENCE(module::implementation, impl, "IMPL");
44 of 97
impl->do_things();
CORBA_END_CLIENT;
return 0;
}
With the correct route to CORBA utils.h. The arguments for CORBA GET REFERENCE()
are:
1. module::implementation The type of the object to fetch.
2. impl The identificator desired for the reference. It should not be defined nor declared, it is done inside the macro. Remember that references are used as pointers.
3. "IMPL" String with the name that the object is registered in the NameServer.
4.6.2
CMake
It is encouraged to use CMake as the tool for managing the compilation of the
proyects. There is a sample CMakeLists.txt in Higgs/branches/CORBA/code/lib
prepared for linking the CORBA libraries and generating the necessary dependencies for compiling. Substitute module with the name of your module. The file IDL command.cmake defines a macro for generating and managing the sources of the IDL interfaces. Include all interfaces that you need
when calling the macro MacroGenerateIDL. Use the command
SET(IDL_DIR path/to/idl)
pointing to higgs idl definition files to tell the macro where to find them.
45 of 97
Ap
endice D
Manual del desarrollador
129
Chapter 5
Developer Manual
The RCT testbed has been designed and developed with the tools and libraries that are currently, as the time of this writing, the state of the art. These
tools are usually replaced by easier and more powerful ones with time, and
Higgs can benefit from these. When such a change is performed, normally it
will invalidate some of the documentation herein. Remember to write down
the procedures and descriptions to match the new devices and/or software.
When replacing a broken part, this chapter can be used as a guide for installing the new components. The tools and libraries in use are defined, as
well as how they have been installed and configured, and a detailed description of the modules, both hardware and software.
5.1
Mobile base
5.1.1 Disassembling the robot
The main reason for disassembling the robot is to access the inside of the mobile base for repairs and updates. The remaining components can be accessed
without major disassembling. The robot base has two black plates screwed
to the red chassis with a joint between them. This allows to access different
parts of the robot without fully disassembling it. The front part of the robot is
where the motors are placed and the inner on board computer can be fitted.
No computer is currently installed inside so it will rarely need servicing. See
section 5.1.1 to access it. The back part houses all power and control electronics and the batteries and can be reached disassembling the back methacrylate
structure with the alluminium gantry. This is achieved by unscrewing all six
bolts fixing it to the robot base. Be sure to unplug all necessary cords when
taking it out. The robot base will power up but will not work correctly if the
multi-coloured ribbon cable is not properly connected to the black instrument
panel of figure 5.1.
46 of 97
Figure 5.1: Robot base instrument panel.

Disassembling the laser
There are two ways to disassemble the laser. The first one removes the block
composed of the laser sensor and the metacrylate structure that supports it.
Get a number 5 allen wrench and unscrew the bolt placed under the laser,
tiliting the latter upwards to reveal it. Then remove the two similar bolts on
the other border of the alluminium plate that the first bolt was also holding.
The methacrylate structure will be loose but do not take it off yet. Unplug the
cords attached to the arduino board and the two data and power cords of the
laser. Once all cables are released the structure can be lifted. Be careful not
to damage the accelerometers when reassembling as its placement has been
carefully crafted to fit between the laser structure and the arduino connection
board.
The second way allows for easier but more tedious disassembling. Remove
the radio receiver of the GPS turning it as it was a huge bolt. Then unscrew
the four bolts holding the upper methacrylate plate of the laser structure.
Be careful with the weight of the devices fixed to this plate. This will leave
the two walls standing to the sides of the laser. Looking from a robot point
of view, the right wall can slide outwards releasing the laser from its side
constraints. Take it out after unplugging the power and serial data cords. If
further disassembling is required proceed as in the previous paragraph.
Reaching the inside of the mobile robot.
Once the top part of the mobile base is free from devices and structures both
front and back inside parts of the robot can be reached unscrewing the littlest
black bolts on the black plates. Additionally you can also remove the sonar
sensors for reaching deeper inside the robot. There are four little vertical
bolts inside the structure that holds each sonar array. Remove the ribbon
cable prior to disassembling it.
In the back part of the robot reside the electronics in two layers. To access
47 of 97
the bottom boards the top ones must be removed unscrewing the four small
bolts situated behind the back wheels at the side of the robot and removing
the sonar array so it can be slipped out.
Figure 5.2: Robot base front part disassembled.
5.1.2 Firmware
It is possible to update the firmware of the Mobile base, uploading it to the
nonvolatile memory of the Hitachi H8 microcontroller. Check the Pioneer 2
H8-Series Operations Manual. It is also possible to update the tick count of
the odometry.
5.2
On-board computer
The onboard computer is the sony VAIO laptop running tUbuntu linux 10.04
with a RTAI kernel. The older onboard computer is a GENE board that was
placed inside the mobile base with its own dc/dc regulator running WindRiver. See figure 5.3
48 of 97
Figure 5.3: The old onboard computer GENE
5.2.1
Hubs and converters
The onboard computer has two USB ports and one FireWire port among
others. The FireWire port is used with the binocular camera. The arduino,
GPS, laser, wrist and robot base all use serial RS-232 communication which
is achieved using USB to RS-232 converters. There is a hub behind the power
board with 4 USB ports to where the converters are plugged, either directly
(two of them), with a short USB cable (i.e. the GPS) or has the converter
chip embedded inside the device (i.e. the data acquisiton board). There is a
lack of one serial converter for having all five devices working at the same
time. Be sure to reconfigure the serial ports at /etc/higgs/devices when
changing the connected devices, see 4.5.3.
5.2.2
Real Time Operating System
This section describes the steps that have been made for building and installing the Ubuntu RTAI operating system.
1. Download and burn Ubuntu 10.04 LTS Desktop Edition, then install it
like a standard Ubuntu installation. The Long Term Support surname
guarantees that this version will be supported for 3 years.
2. Install these packages: libncurses-dev build-essential
kernel-package linux-source They are needed for building the
kernel and generating a debian package.
3. Download and uncompress the vanilla linux kernel 2.6.32.11. The version must much exactly so the RTAI patch can be applied smoothly. The
linux kernel sources can be downloaded from http://www.kernel.org/.
49 of 97
4. Get the RTAI patch form http://www.rtai.org/ As the time of this

writing, the latest version was 3.8.1.
5. Apply the patch.
cd /pathtolinuxkernel2.6.32.11/
patch -p1 < /pathtortai/rtai-3.8.1/base/arch/x86/\
patches/hal-linux-2.6.32.11-x86-2.6-0.3.patch
Be sure to use the patch for the exact kernel vanilla version, in this case
2.6.32.11, or errors and warnings will arise. The -p1 option removes
the base directory form the path of the files inside the patch.
6. Configure the kernel. First, copy the ubuntu kernel config
cp /lib/modules/uname -r/build/.config \
/path_to_kernel-2.6.32.11
and run make menuconfig inside the root directory of the downloaded
kernel sources. Look for the following options and change them to
the appropriate values: local version-append to -rtai.3.8.1-1; number
of CPUs to 1; ACPI to no; all power management features to no, module versioning support to yes, interrupt pipeline to yes. The RTAI patch
needs ACPI not to be supported by the kernel. As a consequence, no
power management features will work and the kernel will not be able
to run the HALT instruction on shutdown.
7. Compile with make. This can last many hours.
8. Generate the debian package.
fakeroot
make-kpkg --initrd kernel_image kernel_headers
9. Go to the upper directory, where the packages are created, and install
them with dpkg -i *.dev.
Once the kernel is installed, reboot and start with the new kernel to check
it con boot. Now it is time to finish the installation compiling the realtime
kernel modules and utilities.
1. Go to the root directory of the RTAI source code and run make menuconfig.
Select the number of target cpus with the same number as the kernel
and write the path to the kernel sources.
2. make and as root make install.
3. Configure the libraries as root.
echo /usr/realtime/lib > /etc/ld.so.conf.d/rtai.conf
ldconfig
50 of 97
4. Add /usr/realtime/bin to the path of all users .profile files.

echo "PATH=$PATH:/usr/realtime/bin" > /.profile
5. Finally, check that the realtime extensions are working correctly. Go
to /usr/realtime/testsuite/kern/latency and run ./run. If
realtime is correctly installed, the last column should be all zeroes after
2-3 minutes.
6. Optionally, if space is low remove the packages and the source for the
kernel and patch, or only the object files with make clean.
5.2.3
OS Tweaks
There are some modifications to be done to the Operating System to have

Higgs modules running flawlessly.
There must be a username called higgs and it must be a member of the dialout
group. Note also that by default the iptables firewall is enabled on many
distributions and it must be configured or disabled before CORBA clients
can make calls to the servants.
Kernel modules
The linux kernel loads the serial modules for the converters at startup by default, but the order in which it does it is not the same on each bootup, so the
serial device links must be checked on each bootup with this setup. The modules are the FTDI driver ftdi sio.ko and the pl2303 driver pl2303.ko.
This inconvenience has been avoided by moving the kernel file objects from
their standard placement at /lib/modules/ to /etc/higgs/modules. The
kernel tries to load the modules but fails because it can not find them where
it expects them to be. The modules are loaded with the init scripts in a determined order. The following commands as root can be used to set up this
behaviour on new installations:
cd /etc/init.d
echo "#!/bin/sh" > load_serial_modules
chmod a+x load_serial_modules
echo "insmod /etc/higgs/modules/pl2303.ko" \
>> load_serial_modules
echo "insmod /etc/higgs/modules/ftdi_sio.ko" \
>> load_serial_modules
ln -s /etc/init.d/load_serial_modules \
/etc/rc3.d/S60load_serial_modules
Replace rc3.d with the runlevel the OS starts with. You may instead prefer
to modify the init script skeleton and give more functionality such as removal
of the modules using the standard init V procedure such that loading and unloading the modules is done with ./load serial modules start/stop.
51 of 97
Daemon scripts
The onboard portable computer is running many of the CORBA modules
under Linux. The base operating system has been modified slightly to run in
an unattended fashion.
Modifications made to the onboard computer:
/usr/bin/gnome power manager has been renamed to
/usr/bin/gnome power manager.disabled. This allows1 for the
computer to run while it is on batteries and the screen is down. Otherwise the Vaio goes into suspend mode and no process can execute. To
read the battery life do
cat /proc/acpi/battery/BAT1/state or acpi -b
/etc/init.d The servants are configured to be managed by upstart.
The config files determine which modules to load, when to restart and
where to redirect the output (logs). See section 5.3.2 for detailed description.
restart servants It is possible2 to restart the servants by pressing the eject
button on the Vaio, even with the lid down. This button will generate
an ACPI event that will be processed by acpid using the configuration
file restart servants.conf which in turn will call
restart servants.sh that will force the termination of the servants,
which will be restarted by upstart. The configuration and script files go
respectively under /etc/acpi/events and /etc/acpi/actions.
The output of the commands are redirected to
/var/log/higgs/$PROGRAM.log Any problem associated to the execution of the modules may be diagnosed inspecting the logs in /var/log/higgs/,
where all the output from the programs is registered. These files may
grow big, so it has been created a logrotate config file for them (higgslog)
placed in /etc/logrotate.d/.
MODULES: Removed pl2303 and ftdi sio kernel modules. They do not
load with the same order on each bootup, so they are manually loaded
by the inits scripts as described in 5.2.3. The binaries have been moved
from the original location to /etc/higgs/modules.
5.3
Common libraries and module considerations

The RCT testbed may be controlled remotely by means of procedure calls
to CORBA objects. All of Higgs devices including the base platform have a
1
This is not valid in Ubuntu RTAI as the ACPI subsystem is not functional. It is documented here in case other OS is used.
2
This is not available when running the RTAI kernel.
52 of 97
Figure 5.4: General view of the CORBA modules.

CORBA interface definition that must be used in order to remotely or automatically operate the robot. In this section these interfaces are described in
detail.
There are additional CORBA objects running in the on board computers that
whilst not having direct control on Higgs physical devices, they do use the
devices and provide useful, well-known and proved services.
The Java language requires that all CORBA interfaces are defined inside a
module, so all Higgs interfaces are defined inside the module higgs.
5.3.1
ASLab servant utility functions for CORBA
The same file code/lib/CORBA utils.h for easy creation of clients has
also macros for servants. A typical servant executable would be something
like:
#include "implementation.h"
#include "CosNamingC.h"
#include "../../lib/CORBA_utils.h"
int main(int argc, char* argv[]) {
CORBA_BEGIN_SERVER(argc, argv);
53 of 97
implementation_t impl();
higgs::implementation_t_var implvar = impl._this();
CORBA_REGISTER_REFERENCE(implvar, "IMPL");
CORBA_END_SERVER;
return 0;
}
It is possible to use also CORBA GET REFERENCE in case other objects are
needed.
5.3.2 Module installation and configuration files

The CORBA macros for the servants make use of the file
/etc/higgs/listen_endpoint.ip
to configure the ip address where they should listen to, additionally to nameservice.ip.
Typically will contain the IPv4 address of the computer it is running in, in this
case,
138.100.76.246
Other config files are the device links at
/etc/higgs/devices
each module has this directory and the device file it uses hard coded.
Finally, they need an upstart config file. The upstart config file for the laser
follows as example:
author "Francisco J. Arjonilla Garcia"
start on started Naming_Service
respawn
script
sleep 5
date >> /var/log/higgs/laser.log
su -l -c /usr/local/bin/laser_server higgs\
>> /var/log/higgs/laser.log 2>&1
end script
Other modules have different upstart config files. See each module source
tree. The Naming Service should start automatically too after installing it.
If not, an upstart config file must also be created for it. In either case, the
endpoint must be specified in the parameters, i.e. manual execution:
54 of 97
./Naming_Service -ORBEndPoint\
iiop://higgs2.disam.etsii.upm.es:9876
The JAVA servant does not use the automatic NameService resolution mechanism provided by the C++ macros in CORBA utils.h and needs to have it
specified as arguments when running it. Also, the next two lines must exist
in the .profile file in the home directory of the user running the servant:
export PATH=/opt/jdk1.6.0_26/bin:${PATH}
export LD_LIBRARY_PATH=/usr/local/lib/
Replace paths apropriately.
5.4
I/O board
The I/O board manages the sensors and actuators that do not have a specific
interface for connecting them to a computer. It has been implemented with
an Arduino Mega board. The devices controlled by the I/O board are:
Compass
Accelerometers
Battery sensors
Laser pitch
Power board
These devices are connected to the Arduino Mega commercial board through
a custom made extension board. The connector layout is shown in Figure 5.5,
and the connectors correspondence to the devices in Table 5.1. The ribbon
cable connector is between the digital inputs. The position is marked on the
board and pin 0 (ground) is next to Pin22.
5.4.1
Tilt mechanism for the laser
The laser sensor is housed inside a methacrylate structure with a joint that enables pitch movements on the laser. They are actuated by a servo placed just
behind the laser, and by two end of stroke switches that limit the movements
to safe values. To the left side of the laser, coaxial with the axis of rotation,
there is a potentiometer that closes the loop for precise control of the rotation
angle. The servo, switches and potentiometers are all controlled by the I/O
board and has a PID programmed within its firmware. The details can be
found in the PFC from Marcos Salom.
Currently the PID feature has been disabled and the servo operates in an
open loop fashion, using the end of stroke switches as a reference for rotation
limits during initialization. The factors that motivated this decision are:
55 of 97
Figure 5.5: Connection diagram for compass board
Number
Pin0
Pin1
Pin2
Pin3
Pin4
Pin5
Pin6
Pin7
Pin8
Pin9
Pin10
Pin11(Analog)
Pin11(Digital)
Pin12
Pin13
Pin22
Pin23
Pin24
Pin25
Pin26
Pin27
Ribbon
Device
Not used
Not used
Not used
Instrumentation current
Instrumentation voltage
Laser pitch potentiometer
Motor current
Motor voltage
Accelerometer, X axis
Not used
Not used
Accelerometer, Y axis
Not used
Not used
Laser pitch servo
Min pitch switch
Max pitch switch
Not used
Compass
Not used
Not used
Power board
Table 5.1: Connector correspondence of the Arduino extension board with

the devices.
56 of 97
1. The potentiometer is prone to errors due to mechanical hystheresis,

worn out and temperature effects.
2. There is a lot of functionlity that can be more useful than controlling the
pitch of the laser. The effort has been so displaced elsewhere.
3. A better pitch angle sensor, such as an optic encoder, would justify buying a whole controlled actuator with integrated sensing and electronics.
4. The kinect sensor can partially substitute the laser.
5.4.2
Power board
The I/O board and the power board have been connected with a ribbon cable
that plugs to the doble row of pins of the extension board in the side of the
I/O board. The ground connection has been stripped as the correspondent
pin is not connected to ground in these pins. Common ground with the rest
of the robot is achieved through the power connections that come from the
batteries (Figure 5.2).
5.4.3
Compass
The compass is a solid state magnetism sensor placed next to the GPS antenna
on the aluminum bridge. It was bought at www.superrobotica.com product
reference CMPS03 S320160. The connections are as follows, from bottom to
top as shown in figure 5.6.
1. VDD. To Arduino supply.
2. SCL. To 5V with 47 resistor.
3. SDA. To 5V with 47 resistor.
4. PWM. To Arduino digital input.
5. NC.
6. Calibrate. To button in compass connector.
7. 50Hz-60Hz. To GND.
8. NC.
9. GND. To Arduino supply.
All connections including the calibration button are done inside the IDT connector and protected by thermoadhesive. The button takes the calibration
input to ground when pressed.
57 of 97
Figure 5.6: Connection diagram for compass board

Calibration instructions
As noted in the manual of the compass, to calibrate it you have to press the
button with the board heading perfectly well once in each direction: North,
West, South and East, no order required. It is already calibrated, so there is
no need to do it again.
The compass gives an output pulse of 1ms to 37 ms VCC plus a fixed 65ms
GND. 1ms corresponds to 0 and 37ms to 359 .
The aluminum bridge does not interfere on the compass readings, but if the
robot is moving near steel structures they may be perturbed.
5.4.4 Accelerometers
There are two accelerometers encased on the same electronic board attached
horizontally with Velcro to the top cover of the robot base next to the I/O
board. They give a standard analog 0V to 5V signal and are connected directly to the I/O board.
5.4.5 Intensity/Voltage sensor

There are two I/V sensors installed on board plus the battery status indicator in Vaio accessible through the command line. The two sensors can detect
current and voltage of the Pioneer2AT batteries and the instrumentation batteries. One operational amplifier per battery has been used as a differential
amplifier, as shown in Figure 5.7. This design allows to detect small variations in voltage of higher voltage than those of the working conditions of the
operational amplifier, specifically lower than 3.5V , with the LM2904P operational amplifier powered at 5V . The voltage sensor is a scale down of the
battery voltage, which is then divided by the scale factor by software to recover the true value. The gain is that of the differential amplifier. To read
the true current value, both the gain and the sensing resistor value must be
58 of 97
considered. See Table 5.2 for the numerical values. The printed circuit board
is designed to fit into connectors 3,4,6 and 7 of the Arduino extension board
as an add-on module. The sensing resistors are placed one inside the Pioneer2AT glued to the chassis under the back sonars (figure 5.2) and the other
one is in an aerial connection on the battery cable immediately before the
power board.
Figure 5.7: Battery sensor schematic
Figure 5.8: Battery sensor board layout

Supposing ideal components, the output voltage given by the current sensor
is given by the formulae
U0 = U +
1
1
1
R2
R6 R2
(
+
+
) U
R9 + R6 R1 R2 R5
R1
(5.1)
The condition that must be met for both references to be scaled down by the
59 of 97
Parameter
R1
R2
R5
R6
R9
Max sensing current
Max differential input
Gain
Voltage scale factor
Sensing resistor
Instrumentation
33k
330k
8.45k
8.45k//330k
33k
6A
0.3V
10
0.1998
0.05
Motors
18.7k
330k
5.6k
5.6k//330k
18.7k
17A
0.17V
17.647
0.2275
0.01
Table 5.2: Characteristics of the differential amplifiers for the battery sensors.
same coefficient is that the relation of the resistor values between the positive
input and the negative input is
This way,
R9
R1
=
R6
R2 k R5
(5.2)
R2 +
(U U )
R1
From this result we can observe that there is great sensibility in the operation of the differential amplifiers. The resistors from the negative input and
the positive input must be of the same value, of the same brand and of the
same batch to give enough precision: R9 = R1 and R6 physically being two
resistors in parallel: R6 = R2 k R5 .
U0 =
The current sensors will not work correctly while the batteries are charging.
5.4.6 Servant and firmware

The CORBA module has been written in the JAVA language whilst the test
client in C++. When the TurnOn and TurnOff methods are called, the appropriate device is turned on/off and simultaneously, for the gps, laser, wrist and
camera, the servant that controls the device is killed from the arduino servant
This only works if the device servant is installed and running on the same
machine as the arduino servant, and will solve some issues on the protocol
management that some of the servants have with their device. The servant
will then be restarted by the vaio tools utility scripts.
Both the embedded program inside the I/O board and the Java servant communicate through a USB data connection that gets converted to serial RS-232
by a FTDI chip in the Arduino board. The I/O board starts the communication protocol by sending all the parameters and sensor readings to the servant, and then the servant optionally answers with the order.
The figures 5.9, 5.10, 5.11 and 5.12 show the UML model of the JAVA sources
of the Arduino CORBA servant.
60 of 97
Figure 5.9: CORBA interface and classes used in the JAVA implementation.
Figure 5.10: Interaction diagram for the Arduino CORBA module.
61 of 97
Figure 5.11: Sequence diagram for sending data to the i/o board.
Figure 5.12: Sequence diagram for receiving data from the i/o board.
62 of 97
Modifying and uploading the embedded C code

The embedded program inside the Arduino has been developed using the
official IDE based on the processing IDE and the libraries associated to it.
There are a few issues for remembering when installing this module on a
fresh linux installation. The serial library RXTXcomm is included in the subversion directory
svn+ssh://sagan/home/svnroot/Higgs/code/devices/arduino/lib
The file librxtxSerial.so should be copied to
/usr/$JAVA BASE/jre/lib/i386 and the three jar files core.jar RXTXcomm.jar
and serial.jar to
/usr/$JAVA BASE/jre/lib/ext. Then make sure the user running the
servant is in the groups uucp, dialout and lock, and that the package
uucp is installed. Ensure the cross compilation environment for avr is installed. In Debian/Ubuntu these are the packages gcc-avr, avr-libc and
binutils-avr.
Now check for the embedded C source in the subversion directory
svn+ssh://sagan/home/svnroot/Higgs/code/\
devices/arduino/arduino\_embedded
A copy of the Integrated Development Environment for the arduino is in
svn+ssh://sagan/home/svnroot/Higgs/code/devices/\
arduino/arduino-IDE
or you can get the latest version from the web at
http://arduino.cc/en/Main/Software. Start the IDE with ./arduino
and open the C source file arduino embedded.pde. For the IDE to compile
correctly, the name of the source file without the .pde extension must have
the same name as the directory it is in. Select the correct Board and Serial
Port 3 under the Tools menu, then Compile/Verify and Upload.
5.5
Power board
The Power Board is a custom printed circuit board designed specifically for
the needs of the investigators at ASLab with which to test the algorithms in
system auto-reprogramming with partial malfunction of a robot. The Power
Board is in control of the power supply of up to nine devices in the robot.
Each of these channels may be manually shut down by means of a switch
or remotely/automatically using the ribbon cable connection to the Arduino
board. There is a LED power indicator for each channel plus and a switch and
LED indicator for all the board. Three of the channels, the ones nearer to the
3
The MEGA Arduino board has an integrated USB to RS232 chip, so it will appear as a
serial port devttyUSBx when connecting the USB cable.
63 of 97
Figure 5.13: Photograph of the Power Board indicating each part.

general switch, can control 24V devices whilst the other 6 are for 12V devices.
On the back side there are 12 connectors, 6x12V relay controlled outputs,
3x24V relay controlled outputs, 12V input, 24V input and a 12V output to be
taken to the 12VDC to 24VDC converter that will be powered on whenever
any 24V output is enabled. Additionally, there is a power jack connector for
the battery charger4 . Thus, the Power Board needs a 12V power source and
if the 24V channels are used, it also needs a 12VDC to 24VDC converter.
5.5.1 Power board pinouts

Check figure 5.13 for a visual description of the connectors. The connector
for the ribbon cable has the pinout indicated by table 5.3.
The connectors for the devices are Molex MiniFit, RS references 670-5717
(PCB male), 679-5776 (female), 172-9134 (terminals).
5.5.2 Electric interface

The ribbon cable connector has 10 pins. Starting from pin 0, these are ground,
the six 12V channels and the three 24V channels. The channels are shut down
writing a logical 0 (0V) to the corresponding pin, whilst a 1 (5V), a high
impedance or a no connection will allow for the channel to be powered on.
Both manual and remote switches must allow for the channel to be powered
on for having that channel powered.
4
Originally there was a lead battery pack for powering the devices on top of the robot base.
This power jack connector is no longer neccessary as the robot base has its own power jack
connector for charging the batteries.
64 of 97
Channel / Ribbon cable pin

0
1
2
3
4
6
7
8
5
9
Voltage
12V
12V
12V
12V
12V
12V
24V
24V
24V
Device
Ground common
Not used
Arduino Extension Board (sensors)
Servo
Kinect
GPS receiver
Binocular Camera
Laser
Not used
Wrist
Table 5.3: Distribution of devices in the channels.
Figure 5.14: Schematic for each of the channels.
65 of 97
Figure 5.15: Schematic for the Power Board.
5.5.3 Power Board Bugs

During the design phase of the board there were some errors that passed
the internal tests. As the board was to be manufactured once, it was not
economically feasible to built it again and had to be repaired. These bugs
should be revised before sending the design in case the power board should
be manufactured again.
The holes for the diodes 1N4004 are too small. Can be repaired by
drilling bigger holes and solding the diodes on both sides.
The power jack has the positive pin disconnected. Solved with a bit of
tin covering both the connected pin hole and the positive pin hole.
The silkscreen of the connector for the 24V input is wrong, it has a duplicated 12VIN instead of 24VIN. Solved with a marker-pen.
The relay hole distribution has the two rows of pins too far apart. Moreover, the coils had positive and negative pins and was not well documented in the datasheet, so the coil pins are swapped. Solved by manually separating the pins of the relays and extending the coil pins and securing the relays with termoadhesive. A second better approach would
have been to solder all components on the other side of the board.
Sometimes the relays do not activate correctly and/or the external radio emitter for the DGPS interfere with them and turns them off. Even
66 of 97
though the calculations have been based on the components specification, R14 and analogous have been reduced to 5K4 for ensuring that
enough current passes through the relays coil.
5.6
Wrist
The wrist 5 is a two axis robotics kit module with pan and tilt movements
R It was originally bought for use as the tilt mechmanufactured by Schunk .
anism for the laser, but as the center of gravity of the laser does not match the
center of rotation of either axis of the wrist, it would be a very power hungry method for tilting the laser, given that the laser is heavy and the power
comes from a portable battery system. Moreover, one of the axis from the
wrist would be unused. It was finally decided to use the wrist for controlling
the motion of the camera, even thought it could be achieved with a smaller
controller with minor power requirements.
The manufacturer gives several interfaces for controlling the wrist: Profibus,
CAN and serial. The serial RS-232 bus was chosen over the others because of
the simplicity, the availability of drivers and the sufficient fulfillment of our
requirements. It is connected to the on board computer via a custom made
cable with an intermediate RS-2323 to USB converter. The wrist endpoint has
industry standard serial closings.
5.6.1
Wrist servant
All source code for controlling the wrist is located under

\$(SVN\_ROOT)/Higgs/branches/CORBA/code/devices/wrist
The programs and utilities found there include:
Low level library with direct access to serial port.
Servant code for the CORBA object.
Simple CORBA client to test the functionality and status.
Graphical CORBA client for manually teleoperating the wrist with the
mouse.
Compressed file with the obsolete source code for the wrist, starting
point but fully rewritten code for the current library.
PDF file from the manufacturer describing the serial protocol to the
wrist.
The sources are all under the /src directory and its documentation can be
found inside the source files.
67 of 97
Figure 5.16: Class diagram for wrist module and CORBA interface
Figure 5.17: Activity diagram for wrist servant
68 of 97
When a CORBA client calls a method of this servant a new telegram is created
with the parameters and format adequate to the call, passing the reference to
the serial device already initialized. This telegram sends a message to the
serial device and waits for the acknowledgement. This is valid for both directions of data flow. The telegram gets destroyed once the communication
ends.
Figure 5.18: Sequence diagram for transmitting data to the wrist.
5.6.2
Error recovery
The wrist must be powered, as said in the official documentation, by a 24V

power source, mobile or not. However, the fluctuations in voltage caused by
battery charge and the instant consumption of the devices make it difficult
to keep the voltage of the battery near this value. Because of this fact, the
wrist controller has been designed for high error tolerance. A running thread
in the servant polls periodically the wrist for error codes and takes the appropriate actions when a failure is detected, as explained in each considered
fault. These are the possible faults that have been taken into consideration:
Battery voltage out of bounds
It has been detected empirically that the wrist will not function if the battery
voltage is under 22V or if it is over 27V, so it will not work if the battery
is either fully charged or next to empty. However, the control electronics are
still available. The status command may be issued to detect this anomaly and
a special status code will be sent by the wrist. The CORBA servant code is
5
Note that even though the manufacturer calls this device a powercube, internally we call
it wrist.
69 of 97
aware of this fault and will abort execution to allow to complete device reset,
outputting a log and leaving the restart of the servant to the VAIO utility
programs. This fault can be prevented by periodically reading the voltage
sensor value from the I/O board, the Arduino CORBA servant.
Overcurrent
The internal current sensor will stop the axis when an overcurrent is detected
or a low voltage condition is met if the 12V to 24V converter can not supply
enough power. In this case, a reset and homing procedure is needed before
continuing operating the unit. The maximum speeds and accelerations before
the fault are saved and restored after the reset and homing procedure, but not
the position.
Device not found

This error may arise if the device is powered off, if the serial port is not accessible or can not be found, or if the serial cable is not correctly connected.
In this case the servant will die and get restarted automatically by the init
scripts.
5.7
Laser
The data cable is a serial one prepared for RS-232 and RS-422 communications. There is a jumper on the end connector to select which of the protocols
to use. With the jumper, RS-422. Without the jumper, RS-232. Note that the
RS-422 has not been successfully tested, maybe because the jumper should
be inside the laser connection black box instead of the serial cable endpoint.
5.7.1 Laser servant

The laser servant has been developed on top of the driver given by the people working in the mobile robotics lab. It has been modified to be able to
resynchronize after a transmission error or a reboot of either the sensor or the
servant. The original source code can be found in
$(SVN)/code/devices/laser/libreria_laser-paloma.zip
The documentation for the Sick Laser Sensor both hardwre and protocol definition can be found under the doc directory of the laser sources. Inside the
src directory you will find the modified sources for the laser driver, the servant implementation and a test client, like in other modules.
70 of 97
5.8
Differential GPS
The GPS module is based on two OEMV-2-RT2 receptors with capacity for
Satellite Based Augmentation System (SBAS) and Differential GPS (DGPS).
Both receptors communicate through a radio based modem capable of transmitting in half-duplex mode through relatively long distances at 9600bps.
The base radio has a transmitting power of 2W and the rover radio 0.5W,
however the latter is only used for receiving data. Both radios must be set to
work in the same channel, use the button with the channel label to change it.
The electronics for each receptor have been encapsulated into plastic boxes
with these connectors and indicators available:
One double power LED indicator for checking 12V and 3.3V.
One USB.
Three RS-232 ports COM1 to COM3 with male DB9 connectors.
One DB9 connector labelled CEXT.
Power Jack connector, 12V nominal.
Two TNC connectors.
A reset button.
The connectors used on both base station and rover are the same. The antenna, either the small one on the rover or the bigger circular one on the base
station is connected to the RFIN-labelled TNC connector. The other TNC
connector is not used and its purpose is to have an external high precission
oscillator for the GPS time measures. The power jack is used to power the
unit. COM2 is connected to the radio emitter/receptor for sending/receiving
the differential corrections from the base station to the rover. COM1 is connected to the VAIO laptop through a USB to RS232 adaptor so the GPS receiver can send the position information to the CORBA servant. On the base
station, COM1 is only used when configuring the parameters of the receiver
and saving them to its internal non-volatile memory.
5.8.1
Configuring the devices
These procedures are not to be used while on normal operation of the robot.
They are only needed on first boot, then the configuration is saved permanently on the non-volatile memory of each device. There is a little booklet
inside the yellow bag where the station base is stored with the commands
and parameters used by the stations.
The minicom command line application is best used. You may have to configure it. Open /etc/minirc.ttyS1 and insert these lines:
71 of 97
#
pu
pu
pu
pu
pu
pu
Machine-generated file - use "minicom -s" to change parameters.

port
/dev/ttyS1
baudrate
9600
bits
8
parity
N
stopbits
1
rtscts
No
Change the port as needed. Run

minicom ttyS1
Now you should have access to a command line where you can send commands and check the status of the device.
Base station
Set up the base station with the RF input to the external antenna situated in
the roof of the department of automatics. Get a serial cable and plug your
personal computer to COM1. Start the minicom program to start a new session with the GPS device. These are commands were used to configure it:
FRESET
FIX POSITION 40.4397076 -3.6881482 744
INTERFACEMODE COM2 NONE CMR OFF
LOG COM2 CMROBS ONTIME 1
LOG COM2 CMRREF ONTIME 10
LOG COM2 CMRDESC ONTIME 10 1
SAVECONFIG
The meaning of the commands is as follows:
FRESET
Clears the non-volatile memory and sets the configuration to the default values. RESET does the same thing without clearing the non-volatile memory.
FIX POSITION 40.4397076 -3.6881482 744
This is the position measured for the base station after a period of several
hours (Latitude, Longitude, Height). The command indicates the base station that it should calculate the GPS position for the corrections. All position
reading after this command returns the fixed coordinates given.
INTERFACEMODE COM2 NONE CMR OFF
LOG COM2 CMROBS ONTIME 1
LOG COM2 CMRREF ONTIME 10
LOG COM2 CMRDESC ONTIME 10 1
72 of 97
Sets the COM2 port for sending the corrections using the message types
CMROBS, CMRREF and CMRDESC. See the GPS manual for more information.
ONTIME 1 means to repeat the command every second. Use the UNLOG
log name and UNLOGALL commands to stop transmitting automatic logs.
Omit COM2 for sending the data your terminal.
SAVECONFIG
Stores the configuration to the non-volatile memory.
Rover station
Proceed as for the base station, except that the serial connection may be already available from the on board computer. In this case you may need to
stop the GPS servant first to gain control of the serial device port. These commands were used to configure it:
FRESET
SBASCONTROL ENABLE EGNOS 0 ZEROTOTWO
INTERFACEMODE COM2 CMR NONE OFF
SAVECONFIG
The SBASCONTROL command line configures the GPS mobile station to use
the EGNOS/SBAS satellites for better precision than GPS alone if the differential readings are not available.
5.8.2
Servant
The GPS module uses the convention for other module sources: installation
and execution procedure, code placement inside the subversion repository
and CORBA utilities such as in other modules are used.
The servant code uses non standard commands to receive the data from the
rover station. The commands
LOG BESTPOS
LOG BESTVEL
are sent on startup and used to retrieve the information about satellites, position, standard deviation and speed. This data is fetched by an independent
thread to the CORBA one and stores it into a shared variable for the CORBA
thread to read it each time a client asks for the data. There is also a timeout
by which if no data is received after a fixed amount of time an error is issued.
5.8.3
Radio signals and ETSII-UPM
The ETSII-UPM is surrounded by many governmental sites. It is possible

that radio transmissions with the differential corrections fail because from
73 of 97
interference from these sites. Other investigation groups have had the same
problem. In this case the dGPS will not work. Official service has anyway
recommended us to use this configuration in the rover if the problem persists:
UNDULATION USER 0.0
FIX NONE
COM COM2 9600 N 8 1 N OFF
LOG COM2 GPGGA ONTIME logperiod
INTERFACEMODE COM2 CMR NOVATEL OFF
RTKSOURCE type any (ANY)
5.9
Binocular camera
The binocular camera is attached to the top of the powercube, allowing for
pan and tilt movements.
The image data is transmitted in raw yuv format between the CORBA servant
and the clients.
When restarting the servants, you should kill the process and call
dc1394 reset bus, or else the servant will not succeed on starting again.
5.9.1 Compiling and running the CORBA module

For installing the CORBA module on a fresh fedora linux system, you must
install these libraries which can be found in the repositories provided by the
package atrpms: glut glui libavcodec and related. Inside the directory tree of the sources there are three scripts that help run the servant and
test clients. Compile and run the server with
\$ ./1-server.sh
The test client with
\$ ./2-client.sh
or, for the old client,
\$ ./3-client.sh
The client runs best when configured to run with Xlib instead of OpenGL.
The user that runs the servant, higgs when running unattended, needs to be
in the video group.
The source structure has not been adapted to the new tree configuration nor
cmake. idl Contains the idl interfaces. generated is where the skeleton
and stub source files are generated to. obj the binary files are compiled to
this directory. text contains code to test the camera without using CORBA.
74 of 97
5.10
BatteryModel and CurrentMonitor

Note: Porting to the newer SVN repository is pending.
These two CORBA servants have been implemented into one JAVA binary
and made an unique module inside the VAIO on board computer. The BatteryModel is a component that calculates the parameters related to the charge
in a battery and estimates the remaining life based on the power requirements. The CurrentMonitor is not used in any other module but has been
an utility component for developing the BatteryModel. It periodically polls
the current of the (currently instrumentation) batteries and reports the mean
consumption since it was required to start monitoring.
Neither component reads or uses the peripherals on the computer. BatteryModel is exclusively a CORBA servant and the clients must pass the data to
it in order to compute the estimations for the battery life, whilst CurrentMonitor is, besides a servant, a client to the Arduino CORBA servant for reading
the current values of the batteries.
Installation of the module and automatic setup is achieved as in the other
modules.
75 of 97
Ap
endice E
Herramientas
En este captulo se describen las herramientas software mas utilizadas a lo largo del
proyecto.
Descripci
on de la tecnologa CORBA
CORBA (Common Object Reques Borker Arquitecture) es un estandar elaborado por
OMG (Object Management Group) que define una plataforma de desarrollo para sistemas
distribuidos que se basa en llamadas a metodos bajo un paradigma orientado a objetos. CORBA define protocolos de interoperabilidad, unas interfaces para los lenguajes de programacion
mas com
unmente utilizados y unas libreras que ofrecen servicios adicionales.
CORBA est
a orientado hacia sistemas distribuidos heterogeneos, es decir, aquellos que
estan compuestos por distintos tipos de CPUs con distintos sistemas operativos y unidos
mediante una red. Las arquitecturas, los sistemas operativos y los lenguajes de programacion
estan limitado u
nicamente por las implementaciones disponibles que los soporte. Existen
implementaciones para Ada, C, C++, C#, Smalltalk, Java, Python, Perl y Tcl, entre otros.
Todo ello hace de CORBA el middleware mas flexible existente hoy en da y es utilizado
por una infinidad de empresas, especialmente compa
nas de telecomunicaciones.
El mecanismo de funcionamiento de CORBA se basa en el empaquetamiento de las llamadas a funciones en cadenas de bytes que se envan codificadas de forma estandar y de
ese modo el objeto remoto no necesita conocer mas que el protocolo de comunicacion. Para
facilitar la labor del programador las herramientas de CORBA proporcionan la generacion
de codigo para ser usado tanto por los clientes, que son los usuarios de los servicios de los
objetos CORBA, como los servidores, que implementan la funcionalidad del objeto CORBA.
Estos servidores pueden estar en el mismo espacio de memoria que el cliente, en la misma
maquina o en una m
aquina remota. La localizacion del servidor es transparente al cliente.
El Lenguaje de Definici
on de Interfaces (IDL) es un archivo de texto de sintaxis similar
a C++ que act
ua como pegamento que une los clientes con los servidores; con ellos se define
la interfaz con la que se comunican y son los archivos a partir del cual se genera el codigo
auxiliar en cualquier lenguaje, es decir, que es independiente de la maquina en la que se vaya
a ejecutar el c
odigo y del lenguaje de programacion.
Como ejemplo de uso, se describira la generacion de codigo en C++. La mayor parte de los
lenguajes se aproximan a este metodo. Otros, como C, en los que no existe herencia de clases,
se define la implementaci
on de manera que facilite al maximo la labor del programador.
160

APENDICE
E. HERRAMIENTAS
161
Figura E.1: Comunicacion entre objetos de servicios CORBA.

Un cliente har
a las llamadas a objetos remotos como si se tratara de un objeto residente en
su espacio de memoria. La diferencia es que este objeto no es el autentico sino un intermediario
(proxy) que empaqueta los argumentos y los enva al objeto real en la maquina remota junto a
informacion de la direcci
on donde debe enviar el valor de las variables de retorno y la funcion
a la que se ha llamado. Este objeto intermediario se denomina stub y su codigo es el que se
genera a partir de la IDL con las herramientas de la implementacion CORBA elegida.
Los servidores por el contrario hacen uso de un mecanismo recproco. El codigo generado
resulta en una clase abstracta cuyos metodos virtuales son los definidos en la IDL. El broker
de CORBA instanciar
a un objeto derivado de esta clase denominado skeleton y realizara las
llamadas oportunas solicitadas por clientes, gestionara las llamadas simultaneas y decodificara los mensajes direccion
andolos al objeto adecuado. La labor del programador se resume
en heredar el skeleton y definir todos los metodos virtuales. Esta clase se denomina servant
y es basicamente el software que se necesita desarrollar en este proyecto.
Figura E.2: Esquema de la arquitectura CORBA.

El concepto Compilaci
on de una interfaz IDL hace referencia a la generacion del codigo
stub del cliente y skeleton del servidor.

APENDICE
E. HERRAMIENTAS
162
CORBA es m
as que una definici
on de interoperabilidad entre objetos remotos. Tambien
define un conjunto de servicios que tpicamente son usados en los entornos distribuidos. Los
principales son el servicio de nombres, eventos, seguridad, etc.
Las u
ltimas revisiones de CORBA deinen tambien una especificacion para la tecnologa de
gestion de objetos distribuidos (DOM). Proporciona una interfaz de alto nivel para gestionar
los servants, su ubicaci
on y los metodos de comunicacion. Facilita la labor de los analistas al
permitir el dise
no por componentes.
Dos buenas referencias para aprender a manejar esta tecnologa y como referencia estan
en [6] y en [8].
Subversion
Figura E.3: Logo de subversion

Subversion, o m
as brevemente SVN, es un sistema de gestion de versiones ampliamente
utilizado en el mundo del software libre. Llamado a ser el sucesor de CVS (Concurrent Verrsioning System), trabaja sobre una base de datos de versiones de los archivos fuente, aunque
tambien trabaja con otros tipos de archivos como texto, imagenes, binarios, etc.
Una de las caractersticas m
as destacables es la posibilidad de trabajar con los mismos
archivos por ditintos usuarios simultaneamente, actualizando automaticamente los archivos
cada vez que se enva una nueva version al repositorio. Se puede visualizar el historial de
cambios de cada archivo y comprobar que archivos se han modificado localmente, entre otras
muchas caractersticas interesantes.
Se ha usado como almacenamiento de las distintas versiones del codigo fuente, como
repositorio de copias de seguridad y como herramienta de intercambio de codigo fuente.
Doxygen
Doxygen es una herramienta de generacion de documentacion a partir del codigo fuente
de un proyecto.
Figura E.4: Logo de Doxygen

Los comentarios del c
odigo fuente han de formatearse bajo una norma especfica, aunque
sencilla de seguir e intuitiva, para que sean capturados por el analizador de Doxygen. Adem
as
lee los nombres de las funciones y de otros elementos sintacticos para generar diagramas.
Un comentario tpico se muestra a continuacion (Se puede ver el resultado final en el anexo
B):

APENDICE
E. HERRAMIENTAS
163
1 /**
2
* \param ex The executive that will keep track of the value
associated with this attribute .
3
* \param obj The object to which the get call applies .
4
* \param get Pointer to member method that supplies the attribute
by polling it.
5
*
It must be of the form
6
*
<code > attribute_t get_t :: get_method (); </code > <br >
7
*
Retrieve the pointer to member method with <code > & get_t ::
get_method </code >.
8
*/
9 template <class O>
10 e x e c u t i v e a t t r i b u t e ( e x e c u t i v e & ex , O * obj , T (O: : * g e t ) ( ) const )
11
{
12
...
13
}
RSA
Entorno de desarrollo basado en Eclipse para el analisis y el dise
no UML. Utilizado en
la elaboraci
on de los diagramas UML y para alguna funcionalidad tpica de entornos de
desarrollo, como visualizar el
arbol SVN sin exportar el codigo.
VIM
Vi IMproved. Editor de textos basado en comandos que agiliza la programacion. Ofrece
una interfaz muy flexible pero con una curva de aprendizaje alta. Recomendado para todos
aquellos tecnicos que vayan a programar asiduamente.
Figura E.5: Logo de VIM
LaTeX
LATEXes un sistema de documentos similar en funcion a Microsoft Word u OpenOffice.
La diferencia con estos es que LATEXes un sistema no grafico que se centra en la estructura,
as el usuario puede centrarse en el contenido y dejar que el compilador LATEXse ocupe de la
maquetaci
on, la generaci
on de ndices y la estetica.
Toda la documentaci
on del robot, al igual que este proyecto, han sido redactados en LATEX.

APENDICE
E. HERRAMIENTAS
164
OrCAD
OrCAD es una aplicaci
on para Windows de dise
no CAD de circuitos electronicos. Puede exportar los proyectos al formato usado en las fabricas de circuitos impresos. Para m
as
informacion consultar la web del fabricante http://www.cadence.com.
CTEDRA
DE
PROYECTOS
PROYECTO FIN DE CARRERA

ANEXO III
ETS de
Ing. Industriales
UPM
TTULO DEL PROYECTO:

Desarrollo e implantacin de plataforma robtica mvil en entorno distribuido.
ENTIDAD PROPONENTE:
Departamento de Automtica,
Ingeniera Electrnica e Informtica Industrial
N PROYECTO:
TUTOR ASIGNADO:
Ricardo Sanz Bravo
FECHA de COMIENZO:
1 de octubre de 2009
NOMBRE del ALUMNO:

Francisco Jess Arjonilla Garca
N de MATRICULA:
00031
ESPECIALIDAD E INTENSIFICACIN:
Automtica y electrnica
DESCRIPCIN DEL PROYECTO Y SUS OBJETIVOS PRINCIPALES

El proyecto consiste en el desarrollo de una plataforma robtica mvil para experimentacin en robtica
e inteligencia artificial. Para ello se desarrollarn, sobre la base de un robot mvil Pioneer 2AT8 los
componentes fsicos, la electrnica y el software necesarios para integrar de manera robusta y fiable, entre
otros dispositivos, un escner lser, una cmara binocular direccionable, un receptor GPSD y sensores
propioceptivos. El proyecto se dividir en dos bloques:
Plataforma fsica:
Diseo de la plataforma para la integracin fsica de todos los elementos.
Seleccin e implantacin de componentes y sensores que aumenten las capacidades del robot.
Diseo del sistema de control de alimentaciones, con sensado del nivel de bateras.
Integracin de los canales de seales de los equipos.
Diseo del software de la plataforma:
Despliegue de la tecnologa CORBA.
Integracin del control remoto de los equipos con el desarrollo de mdulos CORBA.
Gestin de errores y tolerancia a fallos y desconexiones de los dispositivos.
Herramientas de desarrollo y despliegue.
Libreras que faciliten la explotacin de la plataforma, junto con plantillas, documentacin, etc.
OBSERVACIONES:
ENTIDAD PROPONENTE:
EL TUTOR:
Nombre:
Nombre: Ricardo Sanz Bravo
POR LA CTEDRA DE PROYECTOS
EL ALUMNO:
Nombre: Fco. Jess Arjonilla Garca
Nombre:

Aslab D 2011 019

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aslab D 2011 019

Enviado por

Direitos autorais:

Formatos disponíveis

Desarrollo e implantacion de plataforma robotica movil en

9. Conclusiones y trabajo futuro

5. Entorno software de trabajo

A. Esquemas de la placa de alimentaciones

B. Manual de referencia de la librera executive

D. Manual del desarrollador

2.1. Vista general del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1. La plataforma rob

Fotografa de la tarjeta de alimentaciones montada sobre el robot. . .

6.6. Tipos de datos retornados por llamadas al servant del GPS. . . . . . .

8.1. Estructura de Descomposici

9.1. La plataforma rob

Esquema del canal de 12V de la placa de alimentaciones . . . . . . . . .

4.1. Caractersticas principales del rele usado en la tarjeta de alimentaciones . . .

8.1. Presupuesto del sistema de partida. . . . . . . . . . . . . . . . . . . . . . . . .

El desarrollo de nuevos algoritmos en inteligencia artificial y ciencia cognitiva necesitan

Estructura del documento

El captulo 2 presenta una visi

conclusiones, haciendo enfasis en la trascendencia de las tareas realizadas y posibles mejoras

Estado del arte

Figura 1.3: Robot de patas BigDog.

Figura 1.4: Vehculo lunar de la NASA en investigacion.

Ejemplos de robots para investigaci

Figura 1.5: El robot Urbano

Figura 1.6: El robot Khepera con vista del interior.

Figura 1.7: El robot Qbo en desarrollo por la empresa thecorpora.

Marco del proyecto

El proyecto se ha desarrollado en el Laboratorio de Sistemas Autonomos1 de la Universidad

Figura 1.8: Logo de la UPM y ASLab.

Figura 1.9: Logo de ASys.

Otros proyectos de investigaci

Alcance del proyecto

El alcance del proyecto es el desarrollo y la implantacion de una plataforma robotica movil

Objetivo del proyecto

El objetivo principal del proyecto es la ejecucion de las tareas propuestas en el alcance

Cuadro 2.1: Arbol

Vista general del proyecto

En la figura 2.1 se da una visi

Figura 2.1: Vista general del proyecto.

CAPITULO 3. SISTEMA DE PARTIDA

Figura 3.1: La plataforma robotica de investigacion tomada como base.

La camara estaba preparada y montada sobre la mu

CAPITULO 3. SISTEMA DE PARTIDA

CAPITULO 3. SISTEMA DE PARTIDA

Figura 3.3: Camara estereoscopica

Figura 3.4: El sensor laser SICK LMS200

CAPITULO 3. SISTEMA DE PARTIDA

Figura 3.5: Componentes que forman el sistema GPS de la estacion movil

CAPITULO 3. SISTEMA DE PARTIDA

Figura 3.7: Componentes de la estacion base del sistema GPS

CAPITULO 3. SISTEMA DE PARTIDA

Figura 3.8: Localizaci

CAPITULO 3. SISTEMA DE PARTIDA

Figura 3.9: Detalle del acelerometro.

Figura 3.10: Detalle de la br

CAPITULO 3. SISTEMA DE PARTIDA

Cuadro 4.1: Caractersticas principales del rele usado en la tarjeta de alimentaciones

A esta corriente de colector, la del transistor esta situada entre 60 y 100.

Aplicamos un margen de seguridad aproximando la corriente de base a 0,9mA, y la resistencia

Las resistencias limitadoras de corriente para los LED indicadores:

Cuadro 4.2: Distribuci

Cuadro 4.4: Listado de componentes de la tarjeta de alimentaciones.

Figura 4.1: Fotografa de la tarjeta de alimentaciones montada sobre el robot.