DiseÃ넀漀 攀 椀洀瀀氀攀洀攀渀琀愀挀椀쎳n de

Grado en Ingeniería en Tecnologías
de Telecomunicación
Telekomunikazio Teknologien
Ingeniaritzako Gradua
Proyecto n de grado
Gradu amaierako proiektua
Diseño e implementación de laboratorio remoto
para la experimentación con el principio de
Arquímedes mediante arquitectura asíncrona
distribuida.
Gustavo Martín Vela
Director: Ignacio Angulo Martínez
Bilbao, Julio de 2013
Resumen
Como parte de la educación, también en la física, existen una serie de principios que es
fundamental que los estudiantes entiendan para poder progresar hacia un conocimiento
avanzado y, cuya asimilación se facilita mediante la demostración. A menudo, esto puede
implicar que los profesores realicen una serie de experimentos. Sin embargo, a veces puede
resultar interesante para los estudiantes el hecho de descubrir los conceptos de primera
mano, en base a su propia experiencia. Este es el caso del principio de Arquímedes. El
objeto de este Proyecto Fin de Grado es el diseño e implementación de un laboratorio
remoto basado en el Principio de Arquímedes, que permita a los estudiantes descubrir los
efectos que las diferentes densidades y materiales tienen sobre la flotabilidad de los objetos.
A tal efecto, se ha desarrollado un acuario equipado con una serie de poleas controladas
por una Raspberry PI. Estas poleas controlan el izado y el arriado de una serie de objetos
sumergibles esféricos rellenados con diferentes líquidos. Gracias al uso de un sistema de
visión artificial gestionado desde una PandaBoard ES, los estudiantes pueden encontrar
el nivel del agua y determinar el porcentaje que los objetos sumergibles están por encima
o por debajo de ella. Estos datos pueden ser utilizados para calcular varios parámetros y
determinar con qué líquido está lleno cada objeto sumergible.
Descriptores
Laboratorios remotos, WebLab-Deusto, visión artificial, principio de Arquímedes,
educación online
iii
Índice
1 Objetivos y alcance
1
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Objetivos Socio Económicos. . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Objetivos Tecnológicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Alcance del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Subsistema de manipulación y gestión remota del laboratorio . . . . . . . . . .
1.2.2 Implementación de RLMS en plataforma embebida de bajo coste . . . . . . . .
1.2.3 Implementación de una interfaz sencilla para el manejo del laboratorio remoto .
1.2.4 Implementación de visión artificial para el laboratorio remoto . . . . . . . . .
2 Estado del arte
2.1 RLMS . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 MIT iLabs . . . . . . . . . . . . . . . . . . .
2.1.2 LabShare Sahara . . . . . . . . . . . . . . . .
2.1.3 WebLab Deusto . . . . . . . . . . . . . . . .
2.1.4 Otros sistemas . . . . . . . . . . . . . . . . .
2.1.5 Comparación entre los RLMS más relevantes .
2.2 Tipos de Arquitecturas de Red . . . . . . . . . . . . .
2.2.1 Arquitectura Centralizada . . . . . . . . . . .
2.2.2 Arquitectura Distribuida . . . . . . . . . . . .
2.2.3 Arquitectura Mixta. . . . . . . . . . . . . . .
2.2.4 Comparación entre las arquitecturas propuestas
2.3 Visión Artificial . . . . . . . . . . . . . . . . . . . .
2.3.1 Librerías para Visión Artificial. . . . . . . . .
2.3.2 Formatos de archivo de imagen . . . . . . . .
2.4 Hardware . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Mecatrónica . . . . . . . . . . . . . . . . . .
2.4.2 Plataformas embebidas. . . . . . . . . . . . .
2.4.3 Cámaras e iluminación . . . . . . . . . . . . .
1
3
5
5
6
6
7
7
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Justificación de las tecnologías utilizadas
3.1 Subsistema de manipulación y gestión remota del laboratorio . . .
3.1.1 Arquitectura del subsistema . . . . . . . . . . . . . . . .
3.1.2 Dispositivo embebido y sistema operativo asociado . . . .
3.1.3 Mecatrónica . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 Servicios web . . . . . . . . . . . . . . . . . . . . . . .
3.1.5 Lenguajes de programación . . . . . . . . . . . . . . . .
3.2 Implementación de RLMS en plataforma embebida de bajo coste.
3.2.1 RLMS . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Dispositivo embebido y sistema operativo asociado . . . .
9
10
13
14
17
18
19
19
20
21
22
23
23
27
30
30
38
43
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
52
52
53
55
55
56
56
57
v
3.3 Implementación de una interfaz sencilla para el manejo del laboratorio remoto .
3.3.1 Interfaz web para laboratorios gestionados. . . . . . . . . . . . . . . .
3.3.2 Interfaz web para laboratorios no gestionados . . . . . . . . . . . . . .
3.4 Implementación de visión artificial para el laboratorio remoto . . . . . . . . .
3.4.1 Dispositivos de captura de imágenes. . . . . . . . . . . . . . . . . . .
3.4.2 Dispositivo embebido y sistema operativo asociado . . . . . . . . . . .
3.4.3 Software de procesado de imágenes . . . . . . . . . . . . . . . . . . .
3.4.4 Tipos de formatos de imagen . . . . . . . . . . . . . . . . . . . . . .
3.4.5 Iluminación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Diseño e Implementación
65
4.1 Subsistema de manipulación y gestión remota del laboratorio . . . . . . . . . .
4.1.1 Dispositivo embebido y mecatrónica. . . . . . . . . . . . . . . . . . .
4.1.2 Servicios web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Implementación de RLMS en plataforma embebida de bajo coste. . . . . . . .
4.3 Implementación de una interfaz sencilla para el manejo del laboratorio remoto .
4.3.1 Interfaz web para laboratorio gestionado. . . . . . . . . . . . . . . . .
4.3.2 Interfaz web para laboratorio no gestionado . . . . . . . . . . . . . . .
4.4 Implementación de visión artificial para el laboratorio remoto . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Planificación
5.1 Planificación económica . . . . . . . . .
5.1.1 Planificación de costes y recursos
5.1.2 Ingresos y mercado . . . . . . .
5.2 Planificación de tiempos . . . . . . . . .
58
58
59
59
60
61
61
63
63
65
65
72
79
83
83
85
86
105
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Conclusiones y trabajo futuro
6.1 Resultados del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Integración completa del laboratorio en el entorno Graasp. . . . . . . .
6.2.2 Integración completa del laboratorio no gestionado en WebLab-Deusto .
6.2.3 Mejoras en la interfaz gráfica de usuario. . . . . . . . . . . . . . . . .
6.2.4 Mejoras en el sistema de izado y arriado de elementos sumergibles . . .
6.2.5 Diseño de una nueva versión del laboratorio . . . . . . . . . . . . . . .
105
105
109
111
113
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
113
114
114
114
116
116
117
Agradecimientos
119
Referencias
124
Anexos
125
A
B
vi
Tareas y Diagramas de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Mockups del proyecto GO-Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Índice de Figuras
1.1
1.2
1.3
Interfaz del laboratorio remoto para física WebLab-Deusto Visir.. . .
Modelo de federación de WebLab-Deusto. . . . . . . . . . . . . . . . .
Arquitectura planteada para el laboratorio. . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
2.27
2.28
2.29
2.30
2.31
Arquitectura de iLabs para experimentos por lotes. . . . . . .
Gestión interna de colas en el servidor de laboratorio. . . . . .
Arquitectura de iLabs para experimentos interactivos. . . . . .
Arquitectura de Labshare Sahara. . . . . . . . . . . . . . . . . .
Arquitectura local de WebLab-Deusto. . . . . . . . . . . . . . .
Diagrama de componentes de VLCAP. . . . . . . . . . . . . . . .
Ejemplo de arquitectura centralizada. . . . . . . . . . . . . . . .
Ejemplo de arquitectura distribuida.. . . . . . . . . . . . . . . .
Ejemplo de arquitectura mixta. . . . . . . . . . . . . . . . . . . .
Proceso de segmentación de una imagen con LTI. . . . . . . . .
Imagen obtenida con VXL aplicando un ltro de contornos. .
OpenCV diferenciando colores dentro de una Raspberry PI. . .
Diferencia de tamaño de los formatos principales en la web. .
Imagen de un motor paso a paso de una impresora. . . . . . .
Imagen de un servomotor.. . . . . . . . . . . . . . . . . . . . . .
Motor DC extraído de un juguete. . . . . . . . . . . . . . . . . .
Representación básica de una polea. . . . . . . . . . . . . . . .
Diseño de la polea a medida en CAD. . . . . . . . . . . . . . . .
Kit de piezas de MakerBeam. . . . . . . . . . . . . . . . . . . . .
Propaganda de Erector de los años 70. . . . . . . . . . . . . . .
Piezas sueltas de Lego Mindstorm.. . . . . . . . . . . . . . . . .
Infografía de una Raspberry PI modelo B. . . . . . . . . . . . .
Imagen de la PandaBoard ES. . . . . . . . . . . . . . . . . . . . .
Imagen de la Arduino Mega 2560. . . . . . . . . . . . . . . . . .
Imagen del Fit-PC2. . . . . . . . . . . . . . . . . . . . . . . . . . .
Imagen de la Beagleboard. . . . . . . . . . . . . . . . . . . . . .
Camara D-Link DCS-5220. . . . . . . . . . . . . . . . . . . . . . .
Camara D-Link DCS-930L. . . . . . . . . . . . . . . . . . . . . . .
Iluminacion posterior difusa y direccional. . . . . . . . . . . . .
Iluminacion frontal oblicua y direccional. . . . . . . . . . . . . .
Iluminacion de campo oscuro. . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
12
14
16
18
20
21
22
24
25
26
28
32
32
33
34
35
36
37
38
39
40
40
41
42
44
45
46
47
47
3.1
3.2
3.3
Polea diseñada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparación de rendimiento de librerías de Visión Arti cial . . . . .
Imagen de el acuario con la iluminación seleccionada. . . . . . . . . .
54
62
64
4.1
4.2
Diagrama de pines de la Raspberry PI usando la librería WiringPI. . .
Esquemático de la PCB diseñada.. . . . . . . . . . . . . . . . . . . . . .
66
68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
4
8
vii
viii
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
4.28
4.29
4.30
Parte delantera de la PCB diseñada. . . . . . . . . . . . . . . . . . . .
Parte trasera de la PCB diseñada.. . . . . . . . . . . . . . . . . . . . .
PCB montada sobre la Raspberry PI. . . . . . . . . . . . . . . . . . . .
Poleas y estructura montadas sobre el acuario. . . . . . . . . . . . .
Poleas y estructura montadas sobre el acuario. . . . . . . . . . . . .
Interfaz web de WebIOPI. . . . . . . . . . . . . . . . . . . . . . . . . .
Página principal de WebLab-Deusto. . . . . . . . . . . . . . . . . . .
Proceso de creación de un usuario para la federación. . . . . . . . .
Proceso de creación de un experimento. . . . . . . . . . . . . . . . .
Interfaz web del laboratorio gestionado. . . . . . . . . . . . . . . . .
Interfaz web del laboratorio no gestionado. . . . . . . . . . . . . . .
Disposición de las cámaras en el acuario. . . . . . . . . . . . . . . . .
Captura de imagen de la cámaras de la derecha. . . . . . . . . . . .
Aplicacion de la funcion boundingRect(). . . . . . . . . . . . . . . . .
Captura de imágenes cambiando el contraste. . . . . . . . . . . . . .
Captura de imágenes cambiando el brillo. . . . . . . . . . . . . . . .
Aplicacion del desenfoque gaussiano.. . . . . . . . . . . . . . . . . .
Diferencia entre los diferentes valores para la función de Canny()..
Aplicacion del ltro Canny sobre la imagen en escala de grises. . .
Aplicacion de diferentes transformadas de Hough. . . . . . . . . . .
Tiempos de procesado en segundos. . . . . . . . . . . . . . . . . . .
Capturas con diferentes umbrales del acumulador. . . . . . . . . . .
Proceso hasta llegar a aplicar un umbral a la imagen. . . . . . . . .
Aplicación de algoritmos para la búsqueda de guras. . . . . . . . .
Circunferencia corregida. . . . . . . . . . . . . . . . . . . . . . . . . .
Imagen con texto sobre la posición de los elementos sumergibles.
Comparación de tiempos (en segundos) con y sin paralelización.. .
Interfaz web de Supervisor. . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
69
69
70
71
72
76
81
82
82
85
86
87
89
90
91
91
92
93
94
96
97
98
100
100
101
102
102
104
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
Costes asociados a los Recursos humanos. . . . . . . . . . . . . . . . .
Costes asociados a los Recursos hardware. . . . . . . . . . . . . . . . .
Costes asociados a los Recursos Software. . . . . . . . . . . . . . . . .
Costes asociados al material fungible.. . . . . . . . . . . . . . . . . . .
Costes jos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Costes jos mensuales. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Porcentaje de penetración. . . . . . . . . . . . . . . . . . . . . . . . . .
Estimación de penetración en el mercado. . . . . . . . . . . . . . . . .
Estimación de ingresos anuales. . . . . . . . . . . . . . . . . . . . . . .
Diagrama de ujos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de tareas primarias para la consecucion de este proyecto.
106
107
108
108
108
109
110
110
110
111
111
6.1
Interfaz de usuario del laboratorio en Graasp. . . . . . . . . . . . . . . 115
Índice de Tablas
2.1
2.2
2.3
2.4
2.5
Comparación de algunas características de los RLMS más relevantes
Comparativa entre los principales formatos de imagen en web. . . .
Comparativa entre los tipos de motores propuestos. . . . . . . . . . .
Comparación de CPU y GPU de las plataformas embebidas. . . . . . .
Comparación de las comunicaciones de las plataformas embebidas..
18
30
34
43
43
3.1
Comparativa entre los motores seleccionados.. . . . . . . . . . . . . .
54
ix
Índice de Bloques de Código fuente
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
Comando para la grabacion de Raspbian en la tarjeta SD. . . . . . . .
De nicion de la struct motor. . . . . . . . . . . . . . . . . . . . . . . . .
Main de programa del motor. . . . . . . . . . . . . . . . . . . . . . . .
Funcion turnMotor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Funcion setMotor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Servicio web para devolver el estado de los elementos sumergibles.
Servicio web para mover los elementos sumergibles. . . . . . . . . .
URL /get_status/ con parametro ALL. . . . . . . . . . . . . . . . . . . .
URL /get_status/ con parametro numerico. . . . . . . . . . . . . . . . .
URL /calibrate_elements/. . . . . . . . . . . . . . . . . . . . . . . . . . .
URL /show_element/. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
URL /move_ball/. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comandos para bajarse el codigo fuente de WebLab-Deusto. . . . . .
Instalacion de Java y Python. . . . . . . . . . . . . . . . . . . . . . . . .
Instalacion de WebLab-Deusto. . . . . . . . . . . . . . . . . . . . . . .
Creacion de instancias en WebLab-Deusto. . . . . . . . . . . . . . . . .
Codigo para la creacion de un experimento en Java. . . . . . . . . . .
Codigo para recortar la imagen necesario para la vision arti cial. . .
Codigo para ajustar el contraste y el brillo en la imagen. . . . . . . .
Codigo para cambiar de espacio de color. . . . . . . . . . . . . . . . .
Codigo para aplicar el ltro canny a la imagen. . . . . . . . . . . . . .
Codigo para aplicar la busqueda de lineas. . . . . . . . . . . . . . . . .
Codigo para aplicar la busqueda de circulos. . . . . . . . . . . . . . . .
Otro codigo para aplicar la busqueda de circulos. . . . . . . . . . . . .
Codigo para generar nuevas imagenes. . . . . . . . . . . . . . . . . . .
URL /image_medium_processed/. . . . . . . . . . . . . . . . . . . . . .
66
73
74
74
75
76
77
78
78
78
79
79
80
80
80
80
84
89
90
92
93
95
98
99
101
103
xi
PROYECTO FIN DE GRADO
1. OBJETIVOS Y ALCANCE
La participación del autor en este proyecto se limita simplemente al desarrollo técnico
de un laboratorio remoto basado en una arquitectura asíncrona distribuida que permita
el aprendizaje de conceptos educativos asociados al Principio de Arquímedes. En este
sentido, la parte pedagógica del proyecto no es obra del autor, pero sigue siendo una parte
del análisis, con el fin de contextualizar adecuadamente el trabajo realizado en el proyecto.
La siguiente lista de objetivos y requisitos presentará una visión general de los objetivos
del proyecto. De acuerdo a lo especificado en el párrafo anterior, el autor se limitará a
desarrollar los objetivos técnicos, así como supervisar los demás objetivos que tienen que
ver más con la parte social y pedagógica. Estos últimos son parte de un esfuerzo continuo
en el proyecto europeo GO-Lab. De hecho, una vez que el autor ha completado el desarrollo
del laboratorio remoto para la experimentación, es decir, el aspecto técnico, el proyecto
ha entrado en la fase de investigación pedagógica, donde toda la parte de interacción con
el usuario del experimento será mejorada y, finalmente, se probará en situaciones reales.
1.1 OBJETIVOS
Un laboratorio remoto es una combinación de hardware y software que permite a un
estudiante controlar desde la distancia los dispositivos que están físicamente en un laboratorio. Este control, normalmente, se hace a través de una interfaz web. La experimentación mediante laboratorios remotos es una tendencia creciente en la educación. De
hecho, y a modo de anécdota, la UOC (en catalán Universitat Oberta de Catalunya) imparte Másteres oficiales no presenciales aprobados por los diferentes colegios de ingenieros
basados en laboratorios remotos. Estos laboratorios tratan de proporcionar una alternativa a los experimentos que se llevan a cabo en los laboratorios presenciales, permitiendo
a los estudiantes realizar experimentos reales a través de Internet. Además, el acceso a
estos recursos puede realizarse desde cualquier parte del mundo y en cualquier momento.
A diferencia de los laboratorios virtuales y las simulaciones, los laboratorios remotos proporcionan a los usuarios experimentación real (Ma & Nickerson 2006). De esta forma, el
alumno puede estar visualizando los resultados de su experimentación en tiempo real sin
tener que estar físicamente en el lugar en el que se desarrolla del experimento. Además,
estos laboratorios suponen un importante ahorro de costes, ya que el mismo laboratorio se
puede llegar a compartir entre millones de personas. Es posible que todas estas personas
pueden llegar a interactuar unas con otras durante el desarrollo del experimento.
1
1 OBJETIVOS Y ALCANCE
Figura 1.1: Interfaz del laboratorio remoto para física WebLab-Deusto Visir.
Una de las principales barreras históricas que ha frenado la evolución y expansión de
los laboratorios remotos es la falta de definición entre los diferentes roles que intervienen
tanto en el desarrollo, como en el consumo de laboratorios remotos. A menudo, en las
universidades los equipos que investigan en experimentación remota han implementado
laboratorios. Sin embargo, estos laboratorios remotos han estado enfocados al desarrollo
de experimentos propios de las asignaturas que imparten estas universidades desde su
particular perspectiva educativa. Podemos pensar entonces que tradicionalmente los laboratorios remotos se han desarrollado para consumo propio, dificultando su consumo desde
otros centros educativos. Además, al vincular los laboratorios remotos con asignaturas
específicas no se ha favorecido con carácter general, su reutilización en otras asignaturas
ni cursos, y aún menos, su extensión a otros centros. Por tanto, se puede decir que nunca
se ha pensado en los laboratorios remotos como un contenido educativo universal que se
pueda compartir. Es precisamente esta polivalencia, una de las metas que persigue este
proyecto.
2
PROYECTO FIN DE GRADO
En este proyecto se pretende implementar un laboratorio remoto que permita la experimentación con un contenido educativo universal en áreas científico-tecnológicas (en
inglés STEM, que viene de Science, Technology, Engineering and Mathematics). Este
laboratorio tratará de proporcionar una píldora educativa que pueda ser consumida por
multitud de usuarios con independencia de su localización, curso o asignatura. En este
sentido se ha elegido el Principio de Arquímedes por ser un principio físico fácilmente
demostrable visualmente y con una gran variedad de aplicaciones a lo largo de toda la
carrera educativa de un niño o adolescente. Este Principio afirma que “un cuerpo total
o parcialmente sumergido en un fluido en reposo, recibe un empuje de abajo hacia arriba
igual al peso del volumen del fluido que desaloja”. Esto es exactamente lo que intenta
plasmar este proyecto a través de diferentes herramientas que provee el laboratorio web.
La idea de este experimento es que se pueda ser usado tanto por alumnos de primaria
como por alumnos de secundaria, e incluso de ciertas carreras, cambiando únicamente las
conclusiones a las que se pretende llegar.
Hay que recalcar que este laboratorio remoto será ofrecido a más de 200 centros educativos europeos dentro del proyecto GO-Lab (Global Online Science Labs for Inquiry
Learning at School) subvencionado por la Comisión Europeo dentro del Séptimo Programa
Marco (FP7). GO-Lab proporciona laboratorios remotos en el ámbito de las ciencias para
su consumo en gran escala en la educación.
En este contexto el objetivo es implementar un laboratorio remoto que permita la experimentación con los conceptos educativos propios del Principio de
Arquímedes a través de Internet. Para ello se utiliza una arquitectura asíncrona distribuida, basada en dispositivos de bajo coste, escalable y fácilmente
accesible gracias al sistema de federación.
1.1.1 Objetivos Socio Económicos
En disciplinas técnicas y científicas, así como en colegios de secundaria, la realización de
experimentos en entornos reales es fundamental para consolidar los conceptos adquiridos
en las aulas teóricas. Sin embargo, a causa de distintos motivos, los laboratorios reales no
siempre están disponibles, lo cual sin duda, supone restricciones en el aprendizaje. Afortunadamente, las nuevas tecnologías basadas en Internet, pueden ser utilizadas para mejorar
la accesibilidad a los experimentos. WebLab-Deusto, a través de estos experimentos tiene
la intención de que los alumnos sean capaces de arraigar conocimientos en campos como
la física, la química, el control, etc., e incluso que estas prácticas puedan irse extendiendo
a otras áreas del conocimiento.
Por otro lado, el gasto requerido para la adquisición y mantenimiento de un laboratorio
dentro de un centro educativo para su utilización puntual es habitualmente difícilmente
amortizable. Gracias a los laboratorios remotos, este coste puede ser compartido entre
varias instituciones y siempre se gozará de una disponibilidad total del laboratorio.
El modelo de gestión a través de federación del sistema WebLab-Deusto, no solo permite
que cada instalación rentabilice su potencial, sino que además, es capaz de escalar el
número de usuarios de los laboratorios gracias a que distribuye la carga de accesos entre
los diferentes centros educativos que comparten recursos. Es decir, podría haber más de
3
1 OBJETIVOS Y ALCANCE
una copia de cada laboratorio en diferentes centros, para mejorar la disponibilidad del
experimento. Así, podría darse el caso de que, más de 600 estudiantes usaran un mismo
laboratorio, a través del balanceo de carga de todos ellos en copias del laboratorio presentes
en los diferentes centros educativos repartidos en todos los continentes.
Figura 1.2: Modelo de federación de WebLab-Deusto.
Además, este modelo permite crear una dinámica de intercambio de recursos que propicia
que el sistema sea económicamente sostenible. Aquellos centros educativos dispuestos a
compartir sus laboratorios pueden fijar unas directivas de uso determinando prioridades
de acceso, marcando el tiempo de las sesiones e incluso limitando el acceso en base al
número de sesiones o a restricciones basadas en el calendario. Este sistema de federación
permite vender o intercambiar accesos a laboratorios, creando por tanto un mercado.
Este proyecto persigue el diseño de una arquitectura que facilite la publicación a través de internet de los laboratorios presenciales instalados en centros
educativos sin necesidad de que estos investiguen directamente en esta línea
de investigación y, sin requerir grandes inversiones, mediante el empleo de
dispositivos de bajo coste.
4
PROYECTO FIN DE GRADO
1.1.2 Objetivos Tecnológicos
El principal objetivo tecnológico del presente proyecto es la implementación de un laboratorio remoto para la experimentación con el principio de Arquímedes mediante una
arquitectura asíncrona distribuida. Una herramienta de estas características implica unos
importantes retos tecnológicos y científicos que se pueden dividir en cuatro áreas:
OT1. Implementación de una plataforma de gestión para el despliegue de laboratorios remotos mediante hardware de bajo coste.
Desplegar un RLMS (Remote Laboratory Management System) en una plataforma
embebida de bajo coste, proporcionando todas las herramientas que permitan la
administración y configuración del mismo, así como la instalación para adaptarse a
un entorno federado.
OT2. Desarrollo de las comunicaciones mediante una arquitectura asíncrona
distribuida.
Desarrollo de todo el sistema de comunicaciones que permita la interacción entre
los diferentes subsistemas necesarios para el desarrollo de un laboratorio remoto
basado, sí es posible, en hardware y software libre.
OT3. Desarrollo de la interfaz de usuario.
Desarrollo de un interfaz de usuario mediante tecnologías RIA (Rich Internet Applications) que permita la experimentación conjunta y simultánea de profesores y
estudiantes en una misma sesión.
OT4. Procesamiento de imagen aplicado a acuario para el reconocimiento de
objetos.
Desarrollo de todo el software necesario para el procesamiento y reconocimiento
de los diferentes objetos que se irán vertiendo al acuario para posibilitar la experimentación con el Principio de Arquímedes.
1.2 ALCANCE DEL PROYECTO
El alcance de este proyecto comprende la realización de la implementación íntegra de
un laboratorio remoto mediante el desarrollo de componentes reutilizables. Este proyecto
tiene como finalidad la de facilitar el despliegue de laboratorios remotos por entidades no
especializadas, como pueden ser centros educativos o instituciones sociales. Este sistma,
que permitirá la experimentación con el principio de Arquímedes, servirá de prueba de
concepto para una arquitectura asíncrona distribuida que establece los mecanismos de
comunicación entre los subsistemas encargados de llevar a cabo las acciones propias de
control de la experimentación y aquellos que administran el acceso remoto. Esta arquitectura estará basada en hardware de bajo coste, ya que la idea es que cualquier centro
educativo o institución social tenga acceso a este tipo de laboratorio remoto independientemente de la capacidad de los recursos económicos de los que puedan disponer. Además,
y gracias a la federación, estas entidades podrán compartir estos inputs con otras.
5
1 OBJETIVOS Y ALCANCE
La arquitectura estará basado en los submódulos que se explican a continuación. Así, el
desarrollo de una estructura compleja como esta puede ser dividida en varios subproblemas más simples, y éstos a su vez, en otros subproblemas más simples. Básicamente se ha
separado el desarrollo de la estructura global en submódulos hasta obtener subproblemas
lo suficientemente simples como para resolverlos fácilmente. Ésta técnica se llama refinamiento sucesivo, divide y vencerás o análisis descendente (en inglés, Top-Down). Cada
uno de estos submódulos tiene una tarea bien definida y algunos necesitan de otros para
poder operar. En el caso de los submódulos que necesitan de otros para poder funcionar,
se comunican con éstos mediante una interfaz de comunicación bien definida. Podemos
ver la arquitectura dividida en lo submódulos más abajo, en la figura 1.3
1.2.1 Subsistema de manipulación y gestión remota del laboratorio
Este subsistema mecánico permitirá la experimentación y gestión del laboratorio, así,
por ejemplo, algunas de sus tareas que realizará son el izado y arriado de elementos
sumergibles, la medición de la temperatura del acuario, la alimentación de los peces del
acuario, el encendido y apagado de luces en función de diferentes parámetros, etc. Este
subsistema debe realizar estas tareas como procesos ligeros o hilos (del inglés threads),
repartiéndose en el procesador de forma dinámica. Este subsistema contara con un núcleo
de tiempo real que gestionará el reparto del tiempo del procesador. Además, todo esto debe
ser realizado en plataformas hardware de bajo coste como la platarforma Raspberry PI,
que tengan por lo menos un número mínimo de GPIOs (General Purpose Input Output)
para llevar a cabo la gestión de los sensores. Además, este subsistema utilizará servicios
web para sus comunicaciones. Así, todas las comunicaciones serán asíncronas, basadas en
REST (Representational State Transfer), y a través de peticiones POST y GET.
1.2.2 Implementación de RLMS en plataforma embebida de bajo coste
Uno de los principales propósitos de este proyecto se basa en la instalación del sistema de
gestión de laboratorios remotos WebLab-Deusto en una plataforma embebida con núcleo
ARM. Los procesadores ARM son, en la actualidad, procesadores de gran popularidad, incluso se podría decir que se encuentran en el interior de los gadgets más vendidos en el mercado. Dispositivos como teléfonos o tablets son algunos de los aparatos con procesadores
ARM incorporado. Los procesadores ARM están enfocados a dar altas prestaciones, con
un consumo reducido gracias a la arquitectura RISC. Los ARM son procesadores ágiles,
sencillos de implementar y programar, de muy bajo consumo y a un coste muy reducido.
De este modo, se consigue alcanzar uno de los principales objetivos del proyecto que es
que los centros educativos puedan desplegar de forma sencilla y barata WebLab-Deusto y
alguno de sus laboratorios de su elección, proporcionando todas las herramientas que permitan la administración y configuración del mismo. Además, tal y como se ha especificado
anteriormente, gracias a la federación, podrían compartir sus laboratorios.
6
PROYECTO FIN DE GRADO
1.2.3 Implementación de una interfaz sencilla para el manejo del laboratorio remoto
El sistema debe tener una aplicación web simple que permita desde el exterior hacer uso
del sistema. Esta aplicación web estará diseñada como una RIA, y debera ser ejecutada
sin problemas bajo navegadores web estandarizados, como puede ser Mozilla Firefox o
Google Chrome. Este tipo de aplicaciones buscan mejorar la experiencia y productividad
del usuario, así como visualizar la aplicación en cualquier tipo de dispositivo conectado a
Internet. Además, la aplicación web estará dividida en módulos para poder implementar
futuras mejoras, como hacer widgets con cada módulo sin apenas esfuerzo. Como ejemplos
de módulos podrían señalarse el módulo de imagen procesada, el módulo de vídeo, el
módulo de dar de comer a los peces, etc.
1.2.4 Implementación de visión artificial para el laboratorio remoto
Este subsistema es específico de este laboratorio, ya que es difícilmente aplicable a
otros, sin embargo, se estudiará la forma de aplicarlo a otros. En él, se llevara a cabo
la detección, localización y reconocimiento de ciertos objetos en imágenes, en este caso
objetos de diferentes colores y formas. También se evaluarán los resultados obtenidos para
posteriormente pasarlos a la aplicación web que se creara. Se pretende también crear
un registro de diferentes imágenes de una misma escena con sus objetos asociados para
intentar hacer concordar un mismo objeto en diversas imágenes. Por último, se pretende
hacer un seguimiento de los diferentes objetos en una secuencia de imágenes. Además,
para que el subsistema de visión artificial funcione requiere de una cuidadosa elección del
mejor tipo de luz adaptada al entorno que se plantea.
7
1 OBJETIVOS Y ALCANCE
Figura 1.3: Arquitectura planteada para el laboratorio.
8
PROYECTO FIN DE GRADO
2. ESTADO DEL ARTE
El presente proyecto tratará de implementar una arquitectura asíncrona distribuida
basada en hardware de bajo coste en el contexto de un laboratorio remoto para experimentación con el principio de Arquímedes. En este sentido, el estado de la arte abarca
varias áreas clave que necesitan ser identificados y analizadas por separado. En primer
lugar, se intenta proporcionar una visión general de los RLMS (Remote Laboratory Management System) que poseen los laboratorios remotos actuales y más populares, así como
los sistemas federación y autenticación que usan, y el diseño de la interfaz gráfica de
usuario. En segundo lugar, el documento intenta recoger las principales arquitecturas de
red presentes en los laboratorios remotos, así como las tendencias que han aparecido en
los últimos años. En tercer lugar, se repasan las diferentes aplicaciones que existen para
visión artificial enfocadas en laboratorios remotos y procesado de imagenes en movimiento,
y por último, se hace un breve resumen del hardware de control que existe para este tipo
de desarrollos, basicamente dispositivos embebidos adaptados. A pesar de que en estas
areas clave no aparece explicitamente señalada la parte del software, si que se hace un
pequeño estudio de las necesidades software en los puntos necesarios. Este capítulo queda
por tanto dividido de la siguiente forma:
• RLMS
• Tipos de Arquitecturas de Red
• Visión Artificial
• Hardware
2.1 RLMS
Judson Harward director del CECI (Center for Educational Computing Initiatives), y
presidente del GOLC (Global Online Laboratories Consortium), donde se acuñó el término
RLMS, subrayó durante la keynote de la conferencia GOLC’2011 “en el mundo existen tres
grandes RLMS capaces de ofrecer autenticación, autorización, planificación, seguimiento
de los usuarios, y además, ser reusables de un laboratorio a otro: MIT iLabs, Labshare
Sahara, y WebLab-Deusto”. Existen algunos más que cumplen, en parte, los requisitos
expuestos en las líneas anteriores y que resulta preciso mencionar.
9
2 ESTADO DEL ARTE
A continuación se describen las principales características de cada una de estas plataformas comentadas anteriormente:
• MIT iLabs
• Labshare Sahara
• WebLab-Deusto
• Otros sistemas
Por ultimo se hara una pequeña comparación entre las características que mas interesan
en este proyecto de los RLMS más relevantes
2.1.1 MIT iLabs
El CECI, perteneciente al MIT (Massachusetts Institute of Technology), ha desarrollado
un sistema de gestión de laboratorios remotos llamado ISA (iLab Shared Architecture).
Este sistema de gestión de laboratorios remotos es, actualmente, el más extendido en todo
el mundo, con diferentes iniciativas para compartir laboratorios de Europa, Australia,
Asia y Estados Unidos. Es también el primer RLMS que incluyó la federación como una
característica nativa (Harward, Del Alamo, Lerman, Bailey, Carpenter, DeLong, Felknor,
Hardison, Harrison, Jabbour et al. 2008).
En 2001 ILabs desplegó una nueva arquitectura basada en servicios web, que posteriormente se convirtió en una infraestructura común para todos los laboratorios. Su desarrollo
fue liderado completamente por el CECI. Esta arquitectura, denominada ISA permite
compartir de forma nativa los laboratorios entre diferentes universidades. Como simple
curiosidad, WebLab-Deusto pasó en 2004 a formar parte de la ISA. Esta arquitectura en
sus comienzos solo soportaba el concepto de laboratorios por lotes, donde las tareas propuestas por los estudiantes se ejecutaban y los resultados eran devueltos posteriormente.
Los estudiantes no eran capaces de interactuar con el laboratorio durante el tiempo asignado. Sin embargo, en 2007 la ISA comenzó a desarrollar laboratorios interactivos, que
permitían a los estudiantes interactuar en tiempo real con ciertos elementos hardware, y
verlo al mismo tiempo.
El sistema de iLabs divide los experimentos en dos categorías principales:
• Laboratorios por lotes (gestionados mediante colas)
• Laboratorios interactivos (gestionados a través de reservas)
La arquitectura de los laboratorios por lotes se representa en la Figura 2.1. En la
figura, hay dos campus que podrían ser dos universidades diferentes. Cada campus tiene
un servidor de laboratorio (en inglés Lab Service) que es el sistema de software sujeto al
equipo final que será utilizado por los estudiantes, y contiene la lógica de la que depende
directamente el laboratorio. Además, cada campus tiene un proveedor de servicios (en
10
PROYECTO FIN DE GRADO
inglés Service Broker), que es el servidor que realiza el logueo de usuarios, la gestión de
permisos y la gestión de accesos.
Figura 2.1: Arquitectura de iLabs para experimentos por lotes.
Los estudiantes inician sesión en el proveedor de servicios de su campus, donde tienen un
conjunto de credenciales y permisos para acceder a sus cuentas. Una vez iniciada la sesión,
los alumnos son capaces de utilizar esos experimentos con independencia del lugar dónde
se encuentren. De esta manera, si un estudiante de la Universidad “A” quiere utilizar un
laboratorio ubicado en la Universidad “B”, el estudiante inicia la sesión en el proveedor
de servicios de la Universidad “A” y transfiere las peticiones a este proveedor de servicios.
El proveedor de servicios de la Universidad “A” las reenvía al servidor de laboratorio de
la Universidad de “B” directamente, y le devuelve al estudiante la respuesta generada por
este servidor de laboratorio. Todas estas comunicaciones están implementadas con SOAP.
La cola está gestionada por el servidor de laboratorio, en la medida en que puede ser
contactado por los estudiantes de diferentes proveedores de servicios al mismo tiempo. El
servidor de laboratorio ofrece una interfaz Web para su gestión. Este servicio de gestión de
las colas podría aplicarse de diferentes maneras por diferentes servidores de laboratorios,
siempre y cuando mantengan la misma interfaz. La cola se gestiona a través una base de
datos intermedia. Como se ve en la figura 2.2, el servidor valida los experimentos antes
de agregarlos a la cola. De esta manera, la cola solo se llena con experimentos válidos,
por lo que los estudiantes que no presentan experimentos válidos no tienen que esperar
para conseguir una ranura de tiempo. Internamente otro proceso recogerá y procesará los
experimentos desde la base de datos.
11
2 ESTADO DEL ARTE
Figura 2.2: Gestión interna de colas en el servidor de laboratorio.
La arquitectura de los laboratorios interactivos se representa en la figura 2.3. El objetivo de esta arquitectura es optimizar la comunicación entre el cliente y el servidor de
laboratorio. En la arquitectura por lotes esto es irrelevante, ya que no existe comunicación entre ellos. Para optimizar esta comunicación se usa una conexión directa entre
nodos, utilizando un protocolo elegido por el desarrollador del servidor de laboratorio. La
comunicación entre los diferentes servidores implicados a nivel ISA se basa en SOAP.
Figura 2.3: Arquitectura de iLabs para experimentos interactivos.
12
PROYECTO FIN DE GRADO
Dado que los experimentos interactivos en iLab duran alrededor de 20 minutos, se ha
desarrollado un sistema de reservas. Además, dado que estos laboratorios son federados,
hay diferentes actores que pueden influir en las reservas de distintas formas. Por ejemplo,
es posible que los administradores del lado de los estudiantes tengan que cambiar las
reservas en algún momento. También es posible que los administradores del lado del
laboratorio tengan que realizar este proceso (por ejemplo, por un cambio en la planificación
del laboratorio planificada o no).
2.1.2 LabShare Sahara
Labshare Sahara es un sistema de gestión de laboratorios remotos desarrollado por la
UTS (University of Technology Sydney) como parte del proyecto Labshare. En mayo de
2010 varios laboratorios remotos migraron para proporcionar una administración centralizada común, entendiéndose este como un RLMS (Lowe, Murray, Weber, de la Villefromoy,
Johnston, Lindsay, Nageswaran & Nafalski 2009). En enero de 2011, se incorporaron varios cambios, como el desarrollo de reservas basadas en el calendario, y algunas más. En
esta sección, se discutira sólo la última versión, ya que es la que se usa actualmente. La
arquitectura del Labshare Sahara está compuesta por tres componentes principales. Las
interacciones entre estos componentes se pueden ver descritas en la Figura 2.4:
• La Interfaz Web (WI, en inglés web interface), desarrollado en PHP, gestiona la
interfaz de usuario básica para la aplicación de autenticación, las tareas de administración, se muestran los permisos, etc.
• El servidor de programación, desarrollado en Java utilizando la infraestructura OSGi
(Open Services Gateway initiative) y gestiona la asignación de los recursos, los contactos de los laboratorios para comprobar si están rotos los sistemas, y lleva a cabo
todo el proceso de planificación.
• El cliente Rig, escrito en Java, que es el componente de software que se ejecuta en
el equipo final.
Labshare Sahara posee una de los más complejos, avanzados y potentes sistemas de
programación en los laboratorios remotos. Es compatible con el balanceo de carga local,
por lo que el sistema puede gestionar más de una copia de cada laboratorio. En efecto,
en la UTS hay desplegadas varias copias de los laboratorios y los estudiantes van siendo
balanceados entre ellos automáticamente por el sistema según van entrando. Además, el
planificador divide los recursos desde los laboratorios solicitados, para que los estudiantes
hacer una petición a un laboratorio llamado, por ejemplo, medida de fuerzas. Mientras
que unos estudiantes están haciendo solicitudes a medida de fuerzas otros pueden hacer
solicitudes a medida de fuerzas vertical y otros a medida de fuerzas horizontal. De esta
manera, un recurso puede servir a más de un tipo de laboratorio. Por ejemplo, el laboratorio de medida de fuerzas vertical puede servir a los estudiantes que solicitan medida de
fuerzas vertical y medida de fuerzas.
13
2 ESTADO DEL ARTE
Además, Labshare Sahara posee un sistema de reservas en el que los estudiantes eligen
si así lo desean usar el sistema de colas (es decir, ”quiero usar el laboratorio tan pronto
como sea posible”) o a través de las reservas (es decir, ”prefiero usarlo mañana a una hora
concreta”).
Figura 2.4: Arquitectura de Labshare Sahara.
2.1.3 WebLab Deusto
WebLab-Deusto es un RLMS de código abierto que se utiliza con los estudiantes de la
Universidad de Deusto desde febrero de 2005 como una herramienta esencial para sus prácticas de laboratorio en diferentes materias relacionados con la ingeniería. Desde WebLabDeusto se ofrecen experimentos reales como FPGAs, CPLDs, microcontroladores PICs,
etc. a un cierto grupo de usuarios a través de Internet. La experiencia de la utilización de
los experimentos que tienen los estudiantes es exactamente la misma a la que obtendrían
si estuvieran delante de un laboratorio tradicional.
WebLab-Deusto ofrece una arquitectura de software distribuida, abierta y escalable que
facilita la integración de nuevos experimentos (WebLab-Deusto 2005 onwards). Existen
dos tipos de experimentos:
• Experimentos gestionados, en los que WebLab-Deusto permite que el desarrollador
del experimento utilice cualquiera de las tecnologías web comunes para el lado del
cliente como JavaScript, Flash, applets de Java, etc. y exige que use la tecnología
para el lado del servidor que WebLab-Deusto provee. WebLab-Deusto cuenta con
bibliotecas para C, C++, NET, LabVIEW, Java. y Python.
• Experimentos no gestionados, donde el desarrollador del experimento coloca una
aplicación en una máquina virtual y WebLab-Deusto gestiona el control de acceso a
la máquina virtual.
14
PROYECTO FIN DE GRADO
Los dos tipos de experimento tienen las ventajas de todas las características comunes
aplicadas para el RLMS WebLab-Deusto, que son:
• Autenticación: WebLab-Deusto ofrece un sistema de autenticación extensible que
soporta nombre de usuario y contraseña almacenadas en una base de datos MySQL,
servidores LDAP remotos, comprobación de credenciales de OpenID para el acceso
desde otras universidades o Facebook, y autenticación basada en la dirección IP del
cliente.
• Gestión de colas: WebLab-Deusto gestiona diferentes colas de reserva para las diferentes plataformas experimentales disponibles, así como balanceo de carga en los
diferentes tipos de experimentos disponibles.
• Escalabilidad: La arquitectura de WebLab-Deusto escala horizontalmente y tiene
herramientas de prueba disponibles para probar diferentes implementaciones.
• Seguridad: La arquitectura distribuida WebLab-Deusto mantiene en forma aislada
el hardware dependiente de la experimentación, y el software, por lo que cualquier
problema relacionado con un mal uso del experimento nunca puede poner todo el
laboratorio remoto en riesgo.
• Implementación: El sistema de implementación WebLab-Deusto hace fácil y flexible configurar la red distribuida en la que están implicados todos los servidores y
experimentos.
• Seguimiento del usuario: Los usos del laboratorio remoto se guardan automáticamente. En el caso de los experimentos gestionados, se almacenan incluso los comandos intercambiados entre el servidor y el cliente. La cantidad de eventos a registrar
depende de lo que decida el administrador.
• Administración: WebLab-Deusto ofrece herramientas de administración que permiten llevar a cabo fácilmente tareas de administración como la monitorización
de usuarios en tiempo real, comprobación de accesos, añadir o quitar permisos a
usuarios y grupos, etc.
• Facebook: WebLab-Deusto se integra con Facebook, por lo que los usuarios pueden
vincular sus cuentas y utilizarlo con herramientas que proporciona Facebook como
el chat.
• Dispositivos móviles: La interfaz de usuario de WebLab-Deusto también está adaptado para dispositivos móviles, y los experimentos gestionados están adaptados para
proporcionar una versión más rápida y fácil de usar.
• Extensible: Cualquier experimento existente se puede adaptar a WebLab-Deusto.
Por poner un ejemplo, el Proyecto VISIR se adaptó a WebLab-Deusto.
WebLab-Deusto utiliza una arquitectura de capas. Los usuarios proporcionan sus credenciales a un servidor aislado llamado servidor de entrada. Este servidor valida las
credenciales, y si son válidas se pone en contacto con el servidor central para solicitar una
nueva sesión.
15
2 ESTADO DEL ARTE
Desde este punto de vista, los usuarios interactuan con el servidor central. El servidor central realiza todas las operaciones de la lógica de negocio como comprobar si los
usuarios están autorizados a usar un laboratorio y en concreto, extraer la información personal del usuario, comunicarse con otros entornos federados, seguimiento de los usuarios,
etc. Además, la mayoría de las interacciones con los experimentos pasan por este servidor, y será él el que las transmitirá al servidor adecuado para acceder a los laboratorios
solicitados.
Figura 2.5: Arquitectura local de WebLab-Deusto.
WebLab-Deusto está construido sobre los siguientes cuatro supuestos relacionados:
• Todas las peticiones que hacen los usuarios se envían al servidor central, el cual los
envía con seguridad a el servidor de cada laboratorio, y éste los envía al servidor
final del experimento. De esta manera, ni el servidor de laboratorios ni el servidor
de experimento necesita tener una dirección IP pública.
• Incluso si el servidor de experimento se encuentra en una red no fiable, el servidor de
laboratorios garantiza que los mensajes se envían de forma segura desde el servidor
central al lugar donde se encuentra.
• Dado que toda la interacción se gestiona a través del servidor central, el es el que
registra todas las interacciones. Si un usuario quiere llevar a cabo una acción malintencionada, puede acceder al servidor de experimento, puede romperlo, pero no
hay forma de que modifique o acceda a la información enviada por otros usuarios.
Tampoco es posible que un servidor de experimento quede mal programado o se
manipule un equipo para detener el logueo de interacciones en el servidor central.
16
PROYECTO FIN DE GRADO
• Las capas de seguridad requeridas pueden ser adoptadas por el servidor de laboratorios, e interactuar con el servidor de experimento. Este servidor de experimento
se puede desarrollar en cualquier lenguaje de programación.
Estas interacciones se muestran en la Figura 2.5, que resume la arquitectura local de
WebLab-Deusto. En esta figura, se puede ver cómo los estudiantes conectan al servidor
central, que envía las peticiones al servidor de laboratorios de la habitación 2, que envía
las peticiones a los servidores particulares de cada experimento. Sin embargo, la adición
de más capas añade dos inconvenientes:
• Latencia: si se añaden más capas, más tiempo se necesitará para que un mensaje
sea enviado al hardware final.
• Flexibilidad: algunos protocolos (como RDP, VNC o SSH) simplemente no pueden
ser reenviados como un conjunto de mensajes de comando.
2.1.4 Otros sistemas
Existen otros sistemas que se diferencian de los anteriores RLMS en que no cumplen
con todas las características citadas anteriormente, pero que sin embargo ofrecen características muy similares.
VLCAP es una plataforma que tiene como objetivo el desarrollo rápido de laboratorios
remotos dentro de instituciones académicas con unas nociones básicas de programación.
Permite también la compartición de todos los laboratorios entre las diferentes instituciones implicadas en el proyecto. Además, y como característica principal tiene un sistema
que permite que cada laboratorio pueda ser compartido hasta por mil personas a la vez
para poder trabajar juntos. VLCAP tiene implementados repositorios de laboratorios,
un sistema de gestión de laboratorios con autenticación basada en diferentes estándares y
reservas, y sistemas para el despliegue rápido de nuevos laboratorios.
Lab2go es un repositorio semántico de laboratorios remotos, sobre la base de ontowiki.
El proyecto podría parecerse en algunas de las características a los sistemas de gestión
de laboratorios remotos, ya que muestra una lista de los laboratorios disponibles en diferentes universidades. Sin embargo, garantizar acceso o gestionar la planificación de los
laboratorios está fuera del alcance de Lab2go, ya que su única finalidad es la de mantener
una lista actualizada de los laboratorios existentes, con la documentación, los lugares,
y semánticamente clasificado. Lab2go es una gran herramienta para buscar laboratorios
remotos.
Con la misma idea de Lab2go, pero con el apoyo del GOLC y la Comunidad Europea,
existe otro repositorio, no semántico, de los laboratorios remotos llamado LiLa (Library of
Labs). LiLa es un portal de acceso a laboratorios remotos. Incluye servicios como sistemas
de planificación, conexión a los recursos de las bibliotecas, sistema de tutorías, entornos
3D para la colaboración en línea, etc. Asimismo, LiLa crea un marco organizativo para
el intercambio de experiencias entre las instituciones y para el acceso a los laboratorios
remotos y ofrece ayuda didáctica para el profesorado en la integración de experimentos
remotos y virtuales en los programas educacionales.
17
2 ESTADO DEL ARTE
Figura 2.6: Diagrama de componentes de VLCAP.
Existen dos proyectos que se ajustan a la definición de los sistemas de gestión de laboratorios remotos (RLMS) y se han desarrollado con la colaboración de estudiantes reales,
pero por limitaciones técnicas no les ha sido posible desarrollar más de un laboratorio.
El primero de estos proyectos, es el proyecto NETLab. Este proyecto constituye un laboratorio de electrónica remota desarrollado por la UniSA (University of South Australia),
basado en una una profunda investigación sobre la programación de sistemas. El segundo
de los referidos proyectos hace referencia a RVLab, proyecto que se ha desplegado como
un laboratorio de domótica, pero que ha sido diseñado para soportar cualquier tipo laboratorio a través de XML-RPC API (Muros-Cobos & Holgado-Terriza 2012).
2.1.5 Comparación entre los RLMS más relevantes
Laboratorios por lotes
Laboratorios Interactivos
Gestión de colas
Balanceo de carga local
Federación
Labshare sahara
7
3
3
3
3
MIT iLabs
3
3
3
7
3
WebLab-Deusto
3
3
3
3
3
Tabla 2.1: Comparación de algunas características de los RLMS más relevantes
18
PROYECTO FIN DE GRADO
2.2 TIPOS DE ARQUITECTURAS DE RED
La arquitectura de red es el medio más efectivo en cuanto a costos para desarrollar
e implementar un conjunto coordinado de productos que se puedan interconectar. La
arquitectura es el “plan” con el que se conectan los dispositivos de hardware, software y
los protocolos. Esto redunda en benéficio tanto para los usuarios de la red como para los
proveedores de hardware y software. Básicamente se puede señalar la existencia de tres
tipos diferentes de arquitecturas de red, aunque realmente el tercer tipo, la arquitectura
mixta, resulta de una combinación de las dos primeras. Estas arquitecturas de red son las
siguientes:
• Arquitectura Centralizada
• Arquitectura Distribuida
• Arquitectura Mixta
Además, se ha desarrollado una pequeña comparativa de las características más interesantes de las mismas.
2.2.1 Arquitectura Centralizada
La arquitectura centralizada se refiere a la arquitectura en la que el control, monitoreo y
supervisión de los diferentes dispositivos y componentes se deben conectar directamente,
bien por cables o de forma inalámbrica, hasta un sistema de control central, como puede
ser un servidor central. Este sistema es el principal centro de control de la red, ya que
recibe y reúne la información de todos los sensores que posee cada uno de los diferentes
dispositivos físicos de la red, toma las decisiones y se las envía a los elementos actuadores
para que ejecuten la tarea asignada, o bien lo envía a otra red que lo solicite por medio
de Internet. El mayor inconveniente de este tipo de arquitectura radica en que cualquier
fallo en el servidor central deja fuera de servicio el sistema en su totalidad. Esto significa
una reducción en las posibilidades de desarrollo en cuanto a la robustez e implementación
en grandes instalaciones y apunta a unas reconfiguraciones muy costosas.
El bajo costo que representa este tipo de arquitectura, que permite tener un solo dispositivo central del que dependan otros dispositivos o directamente sensores, es su principal
ventaja frente a otras, puesto que los elementos que la componen muchas veces no necesitan
ni siquiera módulos adicionales para el direccionamiento, ni interfaces de comunicaciones
para distintos buses. También es importante destacar la sencillez en la instalación y la
compatibilidad entre la gran variedad de elementos y dispositivos que ofrece el mercado.
19
2 ESTADO DEL ARTE
Figura 2.7: Ejemplo de arquitectura centralizada.
2.2.2 Arquitectura Distribuida
La arquitectura distribuida se define como una colección de dispositivos separados físicamente y conectados entre sí por una red de comunicaciones distribuida; cada dispositivo
posee sus propios componentes hardware y software, pero el usuario lo percibe como un
solo sistema (no necesita saber qué cosas están en cada dispositivo). Así, el usuario puede
acceder a los recursos remotos de la misma manera en que accedería a recursos locales
(Garcia-Zubia, Orduña, Angulo, Irurzun & Hernández 2008).
Estos sistemas se caracterizan por ser una topología de red ausente de un centro individual o colectivo. Los nodos se vinculan unos a otros de modo que ninguno de ellos tiene
poder de filtro sobre la información que se transmite en la red. Desaparecen por tanto
los nodos centrales característicos de las redes centralizadas. Se entiende que estas redes
deben de tener ciertas características comunes a todos ellos como son:
• Tolerancia a fallos: Los sistemas distribuidos deben ser muy confiables, es decir,
que si un componente del sistema se estropea, otro componente debe ser capaz de
reemplazarlo.
• Escalabilidad: Los tamaños de los sistemas distribuidos puede ser muy variados,
pueden ser decenas de dispositivos dentro de una red LAN (Local Área Network),
centenas de dispositivos dentro de una WAN (Wide Area Network), o millones de
dispositivos, como es el caso de Internet.
20
PROYECTO FIN DE GRADO
• Transparencia: La transparencia se define como la ocultación, al usuario y al programador de aplicaciones, de la separación de los componentes de un sistema distribuido,
de manera que el sistema se percibe como un todo, en vez de una colección de componentes independientes. La transparencia ejerce una gran influencia en el diseño
del software de sistema.
Además, se puede definir otra característica adicional, importante en los laboratorios
remotos, que resulta interesante en esta línea, que es la apertura del sistema.
• Apertura: Un sistema informático es abierto si el sistema puede ser extendido de
diversas maneras. Un sistema puede ser abierto o cerrado con respecto a extensiones hardware (añadir periféricos, memoria o interfaces de comunicación, etc.) o
con respecto a las extensiones software (añadir características al sistema operativo,
protocolos de comunicación y servicios de compartición de recursos, etc.). La apertura de los sistemas distribuidos se determina primariamente por el grado hacia el
que nuevos servicios de compartición de recursos se pueden añadir sin perjudicar ni
duplicar a los ya existentes.
Figura 2.8: Ejemplo de arquitectura distribuida.
2.2.3 Arquitectura Mixta
La arquitectura mixta se basa en una arquitecturas descentralizada donde todos los sistemas son totalmente independientes en su funcionamiento, pero deben estar comunicados
entre sí por medio de una conexión física (cables) o inalámbrica. Normalmente, estos sistemas están basados en una o varias unidades de control de gestión y uno o varios módulos
21
2 ESTADO DEL ARTE
receptores o actuadores. Este tipo de arquitectura resulta de una combinación entre los
sistemas con arquitectura centralizada y distribuida, aprovechando las ventajas que brindan, entre ellas se puede mencionar la flexibilidad, ya que permite que el sistema se pueda
configurar con múltiples opciones de acceso al usuario final. Como resultado no existe un
único dispositivo central sino un centro colectivo de conectores. La caída de uno de los
dispositivos centralizadores, conlleva la desconexión de uno o más dispositivos del conjunto de la red mientras que la caída del cluster centralizador produciría necesariamente
la ruptura o desaparición de la red. La red se rige por principios como la “adhesión” o la
“participación”. El nacimiento del telégrafo marcó el inicio de las redes descentralizadas.
La Wikipedia es un ejemplo perfecto de lo que son las redes descentralizadas.
Figura 2.9: Ejemplo de arquitectura mixta.
2.2.4 Comparación entre las arquitecturas propuestas
Una vez repasados como es cada una de las opciones de arquitecturas disponibles es
necesario hacer un pequeño resumen que aúne las ventajas y desventajas de cada uno de
ellas.
En el caso de la arquitectura centralizada existe una ventaja clara respecto al resto de
arquitecturas que radica en la gran potencia e inteligencia de los procesadores alojados en
el servidor, ideal para integraciones de gran complejidad y donde tenemos que convivir con
diferentes sistemas. Resulta de especial interés en el caso de que el sistema deba procesar
una gran cantidad de información a gran velocidad. Sin embargo, presenta una desventaja
importante que es que toda la responsabilidad del sistema recae en el servidor central, y
en caso de fallo todo deja de funcionar.
22
PROYECTO FIN DE GRADO
En la arquitectura distribuida existe la ventaja de que cada dispositivo tiene una autonomía propia, lo cual le proporciona una gran seguridad al sistema. Debido a que se hace
un reparto de responsabilidad entre los diferentes nodos del sistema pueden caerse partes
del mismo y seguir funcionando otras. Otra gran ventaja de estos sistemas es que son
fácilmente escalables, ya que por su tipo de arquitectura podemos distribuir tareas entre
los diferentes, y cuando tengamos problemas, incluir nuevos nodos. Como desventaja es
necesario destacar el hecho de que al tener la inteligencia repartida por pequeños dispositivos en pequeños procesadores que sólo acometen sus pequeñas funciones en su programa
de aplicación, no se puede, en principio, obtener gran potencia del sistema. Además al
estar los nodos preprogramados para funciones específicas no suelen ser demasiado flexible
a la hora de volver a programarlos.
Por último, en lo que se refiere a la arquitectura mixta, tal y como se ha indicado
anteriormente, ésta aúna las ventajas de las dos arquitecturas anteriormente citadas, consiguiendo minimizar las desventajas aportando además una importante descentralización
que derive en el aumento de la flexibilidad del sistema.
2.3 VISIÓN ARTIFICIAL
La visión artificial, también conocida como visión por computador (computer vision), es
un subcampo de la inteligencia artificial. El propósito de la visión artificial es programar
un dispositivo para que ”entienda” una escena o las características de una imagen. La
visión artificial incluye métodos para adquirir, procesar, analizar y la comprensión de las
imágenes. Algunos de los objetivos más hábituales de la visión artificial son la detección,
segmentación, localización y reconocimiento de ciertos objetos en imágenes (por ejemplo,
caras humanas), el seguimiento de objetos en una secuencia de imágenes, etc. Las aplicaciones van desde tareas tales como por ejemplo la inspección de botellas. Como disciplina
científica, la visión por ordenador se refiere a la teoría de los sistemas artificiales que extraer información de imágenes. Los datos de imagen se pueden tomar muchas formas,
tales como secuencias de vídeo, vistas desde múltiples cámaras o datos multidimensionales
desde un escáner.
En este proyecto hay dos partes importantes asociadas a la visión artificial, que son:
• Librerías para Visión Artificial
• Formatos de archivos de imagen
2.3.1 Librerías para Visión Artificial
Existen muchas alternativas para utilizar algoritmos de visión artificial desde diferentes
dispositivos como ordenadores o sistemas embebidos, y que son libres, pero las más utilizadas, y por tanto las que más documentación tienen detrás, son las que se estudiaran en
detalle en esta sección para ser integradass en el proyecto. En este caso la función principal
de la visión artificial es la de reconocimiento de ciertos objetos simples (Torralba, Murphy,
Freeman & Rubin 2003).
23
2 ESTADO DEL ARTE
Entre las diferentes opciones de librerias se han seleccionado las siguientes:
• LTI
• VXL
• OpenCV + IPP
2.3.1.1 LTI
LTI es una biblioteca orientada a objetos con los algoritmos y estructuras de datos utilizadas en el procesamiento de imágenes y visión por ordenador. Ha sido desarrollada
en la Universidad de Tecnología de Aachen, en el marco de muchos proyectos de investigación en visión por computador que tratan sobre robótica, reconocimiento de objetos y
reconocimiento de gestos, etc. El objetivo principal de la LTI es proporcionar una librería
orientada a objetos en C++ que proporcione algoritmos rápidos que se puedan utilizar
en aplicaciones reales. Ha sido desarrollado utilizando GCC en Linux, y Visual C++ en
Windows, es decir, puede funcionar sobre estas dos plataformas sin problemas.
Muchas de las clases de la API encapsulan las funcionalidades de Windows y Linux con
el fin de simplificar el hecho de tratar con el código específico de cada sistema o de cada
hardware asociado. Un ejemplo es que existen clases para gestionar el “multi-threading”
y la sincronización, las medidas del tiempo, y el acceso al puerto serie).
Las funciones de LTI principalmente sirven para operaciones con Álgebra lineal como
matrices, vectores, ecuaciones lineales, estadísticas, etc. Aplicaciones de procesamiento
de imágenes para filtros lineales, filtros orientables, etc. Además, posee una serie de
herramientas para la visualización y herramientas de dibujo que nos sirven para dibujar
algo de información extra en la imagen (un poco de texto, elipses, cuadros, líneas o puntos).
Esto nos puede ayudar a ahorrar mucho tiempo de procesamiento.
Figura 2.10: Proceso de segmentación de una imagen con LTI.
24
PROYECTO FIN DE GRADO
2.3.1.2 VXL
VXL (Vision-something-Library) es una colección de bibliotecas de C++ diseñadas para
la investigación de la visión artificial por ordenador y su aplicación en productos finales.
Fue creado a partir TargetJr con el objetivo de hacer un sistema ligero, rápido y consistente.
VXL está escrito en ANSI / ISO C++ y está diseñado para ser multiplataforma. En el
núcleo de VXL hay varias bibliotecas que son:
• VNL (Números): Se encarga de la gestión de los contenedores y algoritmos numéricos. Por ejemplo matrices, vectores, descomposiciones, optimizadores.
• VIL (Imágenes): Librería para cargar, guardar y manipular imágenes en muchos
formatos de archivo, incluyendo imágenes muy grandes.
• VGL (Geometría): Aplica los principios de la geometría a los puntos, curvas y otros
objetos elementales en 1, 2 y 3 dimensiones.
• VSL (Streaming de Entradas y Salidas), VBL (Plantillas básicas), VUL (Utilidades):
Librerías de miscelánea independientes de cada plataforma.
Figura 2.11: Imagen obtenida con VXL aplicando un ltro de contornos.
Además de las bibliotecas del núcleo, existen librerías que cubren algoritmos numéricos,
procesamiento de imágenes, sistemas de coordenadas, la geometría de la cámara, gestión
del sonido, manipulación de vídeo, recuperación de la estructura del movimiento, modelos
de probabilidad, diseño de interfaces gráficas de usuario, la clasificación, estimación de
sistemas robustos, seguimiento de funciones, topología, manipulación de estructuras, imágenes en 3D, y mucho más. Cada librería del núcleo de la biblioteca es ligera, y se puede
utilizar sin referencia a las otras bibliotecas del núcleo. Del mismo modo, las bibliotecas
no estratégicas no dependen más que de lo absolutamente necesario, para poder compilar
y enlazar solamente las bibliotecas que realmente se necesiten para ahorrar recursos del
sistema.
25
2 ESTADO DEL ARTE
2.3.1.3 OpenCV
OpenCV es una biblioteca libre de visión artificial originalmente desarrollada por Intel
(Laganière 2011). Desde que apareció su primera versión alfa en el mes de enero de 1999,
se ha utilizado en infinidad de aplicaciones. Desde sistemas de seguridad con detección de
movimiento, hasta aplicativos de control de procesos donde se requiere reconocimiento de
objetos. Esto se debe a que su publicación se da bajo licencia BSD, que permite que sea
utilizada libremente para propósitos comerciales y de investigación con las condiciones en
ella expresadas.
OpenCV es multiplataforma, existiendo versiones para GNU/Linux, Mac OS X y Windows. Contiene más de 500 funciones que abarcan una gran gama de áreas en el proceso
de visión, como reconocimiento de objetos (reconocimiento facial), calibración de cámaras,
visión estéreo y visión robótica.
Figura 2.12: OpenCV diferenciando colores dentro de una Raspberry PI.
El proyecto OpenCV lo que pretende es proporcionar un entorno de desarrollo fácil de
utilizar y altamente eficiente. Esto lo ha logrado, realizando su programación en código C
y C++ optimizados aprovechando además las capacidades que proveen los procesadores
multi núcleo. OpenCV puede además utilizar el sistema de primitivas de rendimiento
integradas de Intel, un conjunto de rutinas de bajo nivel específicas para procesadores Intel
(IPP). Cuando OpenCV hace uso del código de IPP (que es un código muy optimizado)
consigue acelerar la ejecución. Y esto le da un minimiza de forma importante a su velocidad
de ejecución. IPP se activa por defecto al utilizar OpenCV en caso de tenerlo instalado.
26
PROYECTO FIN DE GRADO
2.3.2 Formatos de archivo de imagen
Los formatos de archivo de imagen son medios normalizados de organización y almacenamiento de imágenes digitales. Los archivos de imagen se componen de datos digitales en
uno de estos formatos que se pueden rasterizar para su uso en una pantalla de ordenador,
cualquier medio digital, o una impresora. Un formato de archivo de imagen puede almacenar los datos sin comprimir, comprimidos, o formatos vectoriales. Una vez rasterizada, una
imagen se convierte en una cuadrícula de píxeles, cada uno de los cuales tiene un número
de bits para designar su color, que es igual a la profundidad de color del dispositivo en
que se visualiza. En términos generales, en las imágenes de mapa de bits, el tamaño de
archivo de imagen se correlaciona positivamente con el número de píxeles de una imagen
y la profundidad de color o bits por píxel, de la imagen. Además, para ahorrar espacio
en disco, las imágenes se pueden comprimir de diversas maneras utilizando algoritmos
que almacenan una representación exacta o una aproximación de la imagen original en
un número menor de bytes. Teniendo en cuenta diferentes compresiones, es común que
dos imágenes del mismo número de píxeles y la profundidad de color, una comprimida, y
otra sin comprimir, puedan tener un tamaño muy diferente del archivo comprimido. Por
otra parte, las imágenes vectoriales, a diferencia de las imágenes normales, pueden ser de
cualquier dimensión independiente del tamaño del archivo. El tamaño del archivo de las
imágenes vectoriales solo aumenta con la adición de nuevos vectores. Hay dos tipos de
algoritmos de compresión de archivos de imagen, que son:
• Algoritmos de compresión sin pérdidas, que reducen el tamaño del archivo, preservando una copia perfecta de la imagen original sin comprimir.
• Algoritmos de compresión con pérdidas, que preservan una representación de la imagen original sin comprimir que puede parecer una copia perfecta, pero no es una
copia perfecta. A menudo, la compresión con pérdida puede alcanzar tamaños de
archivo más pequeños que los de compresión sin pérdidas. La mayoría de los algoritmos de compresión con pérdida permiten la compresión variable que baja la calidad
de imagen a cambio de reducir el tamaño de el archivo.
Incluyendo los tipos de imágenes propietarios, hay cientos de tipos de archivos de imagen.
Los formatos GIF, PNG, y JPEG son los que más a menudo se utilizan para mostrar
imágenes en Internet (Miano 1999). En la figura 2.13 podemos ver las diferencias de los
tres formatos en cuestión de tamaño. Todas están en la mejor calidad. Estos formatos
gráficos se enumeran y describen brevemente a continuación.
• GIF
• PNG
• JPEG
• Otros formatos
Además, se ha desarrollado una pequeña comparativa entre los formatos mas importantes de la web.
27
2 ESTADO DEL ARTE
Figura 2.13: Diferencia de tamaño de los formatos principales en la web.
2.3.2.1 GIF
El formato GIF (Graphics Interchange Format) está limitado a una paleta de 8 bits o
256 colores. Esto hace que el formato GIF sea adecuado para almacenar gráficos con pocos
colores como diagramas, formas, logotipos o imágenes del estilo de dibujos animados, y
apropiado para la web, ya que consume poco espacio (Amer, Iren, Sezen, Conrad, Taube
& Caro 1999). El formato GIF soporta animaciones y se utiliza mucho para proporcionar
efectos de animación. También utiliza compresión sin pérdidas que es más efectiva cuando
existen grandes áreas de un solo color, y un poco ineficaz para imágenes con detalle o
texturas.
2.3.2.2 PNG
El formato PNG (Portable Network Graphics) fue creado como la alternativa libre de
patentes, de código abierto, para suceder al formato GIF y en parte, también para las
imágenes TIFF. El formato de fichero PNG soporta imágenes con paleta de 8 bits (con la
transparencia opcional para todos los colores de la paleta) y 24 bits de color verdadero (16
millones de colores) o 48 bits de color verdadero con y sin canal alfa - mientras que GIF
sólo soporta 256 colores y un solo color transparente. En comparación con JPEG, PNG es
útil para imágenes con grandes áreas de color uniforme. Así, el formato sin pérdidas PNG
es el más adecuado para las imágenes aún en edición, y los formatos con pérdida, como
JPEG, son los mejores para la distribución final de las imágenes fotográficas, ya que en
este caso los archivos JPG son generalmente más pequeños que los archivos PNG. PNG
nos permite tener imágenes en color indexado, escala de grises, etc. además de un agregar
un canal alfa opcional (Roelofs & Koman 1999).
28
PROYECTO FIN DE GRADO
PNG está diseñado para funcionar bien en aplicaciones de visualización en línea, como
los navegadores web por lo que resulta muy interesante a la hora de desarrollar un video
visualizando progresivamente una serie de imágenes. PNG es robusto, proporcionando
tanto la comprobación de la integridad del archivo completo y la detección simple de
errores de transmisión comunes.
2.3.2.3 JPEG
JPEG (Joint Photographic Experts Group) es un método de compresión. Las imágenes
JPEG comprimidas se suelen almacenar en el formato de archivo JFIF (JPEG File Interchange Format). La compresión JPEG es, en la mayoría de los casos, compresión con
pérdida. La extensión de archivo JPEG / JFIF es JPG o JPEG. Casi todas las cámaras
digitales pueden guardar las imágenes en formato JPEG / JFIF, que soporta 8 bits en
escala de grises e imágenes a color de 24 bits, 8 bits para cada uno de los colores, rojo,
verde y azul. JPEG aplica una compresión con pérdida a las imágenes, lo que puede
resultar en una reducción significativa del tamaño del archivo. Es posible especificar la
cantidad de compresión que se quiere usar en una escala de cero a cien, ya que la cantidad
de compresión que se elija afectará a la calidad visual del resultado (Pennebaker 1992).
Cuando la imagen no es demasiado grande la compresión no disminuye notablemente de la
calidad de la imagen, sin embargo cuando se tiene una imagen muy grande se puede notar
a simple vista la pérdida de calidad de la imagen. Además, los archivos JPEG pueden
sufrir degradaciones cuando son editados y guardados en varias ocasiones. Aunque JPEG
también proporciona almacenamiento de imágenes sin pérdidas, esta versión sin pérdidas
no es muy compatible con los diferentes navegadores y aplicaciones, y no esta aconsejado
usarla.
2.3.2.4 Otros formatos
Aunque existen otros formatos de imagen como son TIFF, BMP, XBM, etc. es sabido
que sólo se deben utilizar los formatos GIF, PNG y JPEG en los sitios web de producción.
Todos los demás formatos de imagen sean o no compatibles con los navegadores, no se han
optimizado lo suficiente y de forma eficiente para su uso como imágenes dentro de una
página web.
29
2 ESTADO DEL ARTE
2.3.2.5 Comparativa entre los formatos mas importantes de la web
GIF
PNG
JPEG
Ventajas
Soporta animaciones.
Formato
ampliamente soportado (Standard).
Soporta transparencias. Sin
pérdidas.
Formato ampliamente soportado
(ISO 15948). Soporta
transparencias. Sin pérdidas.
Formato sin patente. Color 48 bits.
Sin pérdidas o con pérdidas.
Tamaño de archivo resultante muy
pequeño. Color 24 bits.
Desventajas
Relación compresion eficiencia
pobre. Limitado a 256 colores
(8 bits).
Tamaño
grande.
de
archivo
resultante
Calidad limitada en formato con
pérdidas. En caso de elegir buena
calidad, uso intensivo del
procesador.
Tabla 2.2: Comparativa entre los principales formatos de imagen en web.
2.4 HARDWARE
Respecto al hardware, se tienen que diferenciar tres partes diferentes implicadas en el
proyecto:
• Mecatrónica: que comprende los motores, drivers asociados, poleas, etc. así como la
forma de unión a los experimentos.
• Plataformas embebidas: encargadas de gobernar el resto de subsistemas y procesar
todas las tareas.
• Cámaras e iluminación: para maximizar la calidad de las imágenes que se ofrecerán
a través de la plataforma web y poder llevar a cabo el desarrollo de la visión artificial.
2.4.1 Mecatrónica
La mecatrónica es una disciplina que sirve para diseñar y desarrollar productos que
involucren sistemas de control para el diseño de productos o procesos inteligentes, lo cual
busca crear maquinaria más compleja para facilitar las actividades del ser humano a través
de procesos electrónicos en la industria mecánica principalmente. Su punto fuerte es la
versatilidad. Por otro lado, más allá de las cuestiones técnicas, la mecatrónica también se
ha adoptado como una disciplina científica aplicada, en la cual se hace modelado, análisis,
síntesis y control de sistemas de naturaleza multidominio y se ha tratado de homogeneizar
la ciencia para este tipo de sistemas. Algunos ejemplos de aspectos teóricos cuyo objeto
de estudio son los sistemas mecatrónicos desde un enfoque abstracto son el modelado por
“bond graph”, los sistemas hamiltonianos con puertos, las técnicas de control basadas en
la energía como lo es el moldeo de energía, el diseño óptimo de estructura y control, y más
recientemente a un grado más de integración como lo son los sistemas híbridos (Miu 1993).
30
PROYECTO FIN DE GRADO
En este caso se van a estudiar los siguientes dispositivos que integrará el proyecto:
• Motores
• Dispositivos para izado y arriado de los objetos sumergibles
• Estructura de sujeción
2.4.1.1 Motores
Los criterios que condicionan la elección de los motores para el izado y arriado de los
objetos a sumergir están relacionados principalmente con la alimentación que requieren y el
par que son capaces de generar. En este sentido, es necesario que los motores no requieran
una tensión de alimentación superior a 12V, puesto que esta es la tensión nominal que
proporciona la fuente disponible para el experimento. Además, el par motor debe ser
suficiente para poder soportar cargas de hasta un kilogramo.
En principio no hay ningún tipo de limitación en lo referente al tipo de motores utilizados, pero sí que resulta más conveniente que sean motores con alimentación de corriente
continua. Dentro de éstos, podemos distinguir tres grandes tipos:
• Motores paso a paso (PAP)
• Servomotores
• Motores DC (Direct Current)
Además, se ha desarrollado una pequeña comparación de las características mas interesantes de los diferentes tipos de motores.
2.4.1.1.1 Motores paso a paso (PAP)
Los motores paso a paso son dispositivo electromecánicos que convierten una serie de impulsos eléctricos en desplazamientos angulares discretos, lo que significa es que son capaces
de avanzar una serie de grados, lo que se llama el paso, dependiendo de sus entradas de
control. Los motores paso a paso se comportan de la misma manera que se comportan los
conversores digital-analógico DAC (Digital Analogic Converter) pudiendo ser gestionados
fácilmente por impulsos procedentes de sistemas lógicos (Kenjĺo & Sugawara 1984).
Estos motores presentan las ventajas de tener alta precisión y repetitividad en cuanto
al posicionamiento.
31
2 ESTADO DEL ARTE
Figura 2.14: Imagen de un motor paso
a paso de una impresora.
2.4.1.1.2 Servomotores
Un servomotor (también llamado servo) es un dispositivo similar a un motor de corriente
continua (explicado más adelante) que tiene la capacidad de ubicarse en cualquier posición
dentro de su rango de operación, y mantenerse estable en dicha posición. Este tipo de
motor cuenta con la capacidad de ser controlado, tanto en velocidad como en posición.
Normalmente se usan en sistemas de radio control y en robótica. Están formados por
un motor, una caja reductora y un circuito de control. En general los servomotores no
permiten que el motor gire 360 grados, sólo aproximadamente 180. Los servomotores
usan de la modulación por ancho de pulsos PWM (Pulse Wide Modulation) para controlar
la dirección o posición de los motores de corriente continua (Van de Straete, Degezelle,
De Schutter & Belmans 1998). La mayoría trabaja en la frecuencia de los cincuenta hercios,
así las señales PWM tendrán un periodo de veinte milisegundos.
Figura 2.15: Imagen
de
servomotor.
un
Los servomotores se caracterizan por tener fuerza, velocidad, baja inercia y un consumo
de energía reducido.
32
PROYECTO FIN DE GRADO
2.4.1.1.3 Motores DC (Direct Current)
Los motores de corriente continua convierten la energía eléctrica continua en mecánica,
provocando un movimiento rotatorio simple. Un motor de corriente continua se compone
principalmente de dos partes, un estator que da soporte mecánico al aparato y tiene un
hueco en el centro generalmente de forma cilíndrica y un rotor. En el estator se encuentran
los polos, que pueden ser de imanes permanentes o devanados con hilo de cobre sobre
núcleo de hierro. El rotor es generalmente de forma cilíndrica, también devanado y con
núcleo, al que llega la corriente mediante dos escobillas. El sentido de giro de un motor
de corriente continua depende del sentido relativo de las corrientes circulantes por los
devanados inductor e inducido. La inversión del sentido de giro del motor de corriente
continua se consigue invirtiendo el sentido del campo magnético o de la corriente del
inducido.
La principal característica del motor de corriente continua es la posibilidad de regular la
velocidad desde vacío a plena carga. Su fácil control de posición, par y velocidad los han
convertido en una de las mejores opciones en aplicaciones de control y automatización de
procesos (Yeung & Huang 2003).
Figura 2.16: Motor DC extraído de un
juguete.
2.4.1.1.4 Comparación entre los motores propuestos
A continuación se exponen a modo de resumen las ventajas e inconvenientes de cada
uno de estos tipos de motores.
33
2 ESTADO DEL ARTE
Tipo de motor
Motor PAP
Servomotor
Motor DC
Ventajas
No necesitan un Encoder o dispositivo de medición para calcular la
posición del motor. Proporcionan
un gran par a bajas velocidades. Excelente repetibilidad en el control de
posición. No pueden dañarse por sobrecargas mecánicas.
Pueden ser controlados, tanto en velocidad como en posición. Poseen
una fuerza y una velocidad considerable. Tienen un consumo energético
bajo. Tiene muy poca inercia.
Mantienen el para altas velocidades.
Son altamente eficientes. Son capaces de proporcionar un alto par
de aceleración. Alta relación potencia/tamaño.
Desventajas
Son muy ineficientes. El par disminuye considerablemente para velocidades altas. Baja potencia en
relación al tamaño y peso.
Normalmente tienen un ángulo de
giro de 180º
El control de posición requiere el
uso de un Encoder. El motor puede
verse dañado si se ve sujeto a sobrecargas mecánicas.
Tabla 2.3: Comparativa entre los tipos de motores propuestos.
2.4.1.2 Dispositivos para izado y arriado de objetos sumergibles
Para esta tarea se ha decido que la alternativa más adecuada incluye la utilización
de algún tipo de polea. Una polea, es una máquina simple, un dispositivo mecánico de
tracción, que sirve para transmitir una fuerza. Se trata de una rueda o disco, generalmente
maciza y rallada en su borde, que con el concurso de una cuerda o cable que se hace pasar
por el canal (”garganta”), se usa como elemento de transmisión para cambiar la dirección
del movimiento en máquinas y mecanismos. En nuestro caso la finalidad de la polea será
izar y arriar un objeto sumergible que podrá ser de diferentes formas y pesos, con el desafío
que esto implica a la hora de seleccionar la polea.
Figura 2.17: Representación
básica de una
polea.
34
PROYECTO FIN DE GRADO
Se ha realizado una gran búsqueda de poleas en el mercado, así como una importante
labor de testar el funcionamiento de las mismas en relación a diferentes materiales como
plástico PVC con o sin bulón, aluminio, y hierro fundido. Sin embargo, el resultado
obtenido exponía que ninguna de estas reunía los requisitos esperados al respecto, ya que
la adaptación a los diferentes motores que probamos no era posible. Tras barajar distintas
posibilidades, se ha determinado que la mejor opción radica en la fabricación customizada
de las poleas necesarias para este caso en concreto, por lo que se ha realizado el diseño y
fabricación de las mismas a través de en una impresora 3D. Las ventajas de estas poleas
resultan innumerables, ya que se adaptan perfectamente a los motores, y permite obtener
el tamaño deseado para su perfecta adaptación en la estructura unida a la pecera que se
ha construido. Estas poleas fueron construidas con material plástico de primera calidad, y
fueron pintadas en varios colores para que posteriormente, con visión artificial, se pudiera
diferenciar automáticamente entre ellas.
Figura 2.18: Diseño de la polea a medida en CAD.
2.4.1.3 Estructura de sujeción
Con la finalidad de que todo el hardware asociado a la pecera, incluyendo motores,
plataformas embebidas, etc. se adaptara al acuario, a la vez que estuviera bien sujeto era
necesario crear una estructura de sujeción robusta y que a la vez permitiera la respiración
del acuario, así como dar de comer a los peces. hay que recordar que los peces son seres
vivos que necesitan aire, agua, y comida. Para este propósito se determinó que las mejores
opciones eran las siguientes:
• Makerbeam
• Erector
• Lego Mindstorms
35
2 ESTADO DEL ARTE
2.4.1.3.1 MakerBeam
MakerBeam es un sistema de construcción de código abierto de ranura tipo Mini-T. la
ranura de tipo Mini-T es una versión en miniatura de la ranura de tipo T. La ranura de
tipo T es una tecnología que se utiliza ampliamente para la automatización industrial,
robótica y recintos de las máquinas. Gracias a ser Mini-T no sólo es lo suficientemente
pequeño como para trabajar como un sistema de construcción de modelos, sino que también es preciso y lo suficientemente fuerte como para construir máquinas y robots reales
(Hodges, Taylor, Villar, Scott & Helmes 2013). Se compone de vigas cuadradas de 10 mm
de aluminio extruido, varios conectores y el hardware necesario para construir cualquier
cosa. Es un material de muy buena calidad, y según explican en su web “no hay absolutamente nada que se puede no se pueda hacer con MakerBeam y un poco de imaginación”.
Como ventajas cabe señalar el hecho de que los montajes de motor se pueden atornillar
directamente a las vigas y que con el uso de sus escuadras pequeñas, se pueden integrar
incluso servos. Además, MakerBeam es totalmente de código abierto, así que es muy
recomendable para desarrollar y construir piezas propias para interconectar con el estándar de ranuras de tipo Mini-T, incluso ampliando aún más las posibilidades si quieres
integrarlas con el estándar de ranuras de tipo T.
Figura 2.19: Kit de piezas de MakerBeam.
2.4.1.3.2 Erector
Erector es una marca de juegos de construcción de metal de juguete, originalmente
patentado por Alfred Carlton Gilbert. Erector consta de varias vigas de metal con agujeros
regulares para el montaje con tuercas y tornillos. También posee otras serie de piezas
mecánicas, tales como poleas, engranajes, ruedas, y motores eléctricos pequeños que son
parte del sistema. Lo que convierte a Erector en único es la capacidad de construir
un modelo, desmontarlo y construir posteriormente otro modelo con las mismas piezas, o
incluso sumarle más piezas a la construcción anterior. Erector se convirtió rápidamente en
una de las plataformas de construcción de prototipos más populares en los Estados Unidos,
muy probablemente porque era la única construcción de hace unos años que permitía la
36
PROYECTO FIN DE GRADO
sujeción de motores. Actualmente se comercializan bajo la marca para “Montador”, que es
propiedad y está comercializado por Mecano. Erector tiene una gran cantidad de sets de
montaje que permiten dar respuesta a casi todas las necesidades. Como evidencia diversos
test realizados sobre estas estructuras, éstas son capaces tanto de sujetar motores como
de crear plataformas que soporten kilos sobre su estructura.
Figura 2.20: Propaganda de Erector de los años 70.
2.4.1.3.3 Lego Mindstorms
Lego Mindstorms es un juego de robótica para niños fabricado por la empresa Lego,
el cual posee elementos básicos de las teorías robóticas, Lego Mindstorms es un juego de
robótica para niños fabricado por la empresa Lego, el cual posee elementos básicos de
las teorías robóticas, como la unión de piezas y la programación de acciones, en forma
interactiva. Comercialmente se publicita como «Robotic Invention System», en español
Sistema de Invención Robotizado (RIS). También se vende como herramienta educacional,
lo que originalmente se pensó en una sociedad entre Lego y el MIT. La versión educativa
se llama «Lego Mindstorms for Schools», en español Lego Mindstorms para las escuelas.
Lego Mindstorms puede ser usado para construir un modelo de sistema integrado con
partes electromecánicas controladas por algún tipo de ordenador. Prácticamente todo
puede ser representado con las piezas tal como en la vida real, como un ascensor o robots
industriales. Lego Mindstorms trae algunas piezas extras que permiten dar flexibilidad y
movimiento a cualquier estructura que estemos construyendo.
37
2 ESTADO DEL ARTE
Figura 2.21: Piezas sueltas de Lego Mindstorm.
2.4.2 Plataformas embebidas
Entre las plataformas embebidas que se pueden usar para este proyecto se han decidido
destacar cinco principales que han sido valoradas de forma minuciosa, detalle a detalle.
Estas plataformas son las siguientes:
• Raspberry PI
• PandaBoard ES
• Arduino Mega 2560
• Fit-PC2
• BeagleBoard
Ademas, se ha desarrollado una pequeña comparación de las características mas interesantes de las mismas.
2.4.2.1 Raspberry PI
La Raspberry Pi es un mini ordenador del tamaño de tarjeta de crédito desarrollado en el
Reino Unido por la Fundación Raspberry Pi, con la intención de promover la enseñanza de
la informática básica en las escuelas. La Raspberry Pi tiene un chip Broadcom BCM2835,
que incluye un procesador ARM1176JZ-S a 700 MHz. Además, su firmware incluye una
serie de modos ”Turbo” para que el usuario puede hacer overclocking de hasta 1 GHz. Este
chip también tiene internamente una GPU VideoCore IV y dependiendo del modelo que
elijamos puede tener 256 MB o 512 MB de RAM. La Raspberry PI no incluye no incluye
38
PROYECTO FIN DE GRADO
disco duro o unidad de estado sólido , sino que utiliza una tarjeta SD para el arranque
y almacenamiento de datos a largo plazo. El objetivo de la raspberry PI es ofrecer dos
versiones, con precios de aproximadamente 25 euros la más sencilla y 35 euros la opción
superior. La Raspberry PI funciona fácilmente bajo Debian y distribuciones Arch Linux
ARM disponibles en su página web para su descarga, y tiene integradas herramientas
de desarrollo para utilizar Python como lenguaje de programación principal. Una de
las pegas de la Raspberry Pi es que no viene con un reloj de tiempo real, sin embargo,
podemos añadirle un reloj de tiempo real como el DS1307a través de la interfaz I²C
(Upton & Halfacree 2012). Además, el modelo B trae incorporado un conector Ethernet
para conectarlo a la red cableada directamente, los dos modelos incluyen pines GPIO para
entradas y salidas digitales.
Figura 2.22: Infografía de una Raspberry PI
modelo B.
2.4.2.2 PandaBoard ES
La PandaBoard ES es una plataforma de desarrollo de bajo costo y bajo consumo de
energía basado en el chip de Texas Instruments OMAP4430. Su precio ronda los 174 euros.
El OMAP4430 cuenta con una CPU de doble núcleo a 1.2GHz ARM Cortex-A9 MPCore
y una GPU PowerVR SGX540 a 304 MHz. Posee un acelerador de hardware multimedia
con un DSP IVA3 programable y 1 GB de memoria DDR2 SDRAM. Al igual que la Raspberry PI la unidad de almacenamiento primaria es una ranura para tarjetas SD que permite
usar tarjetas SDHC de hasta 32 GB. Además, incluye cable Ethernet 10/100, así como
conectividad Ethernet inalámbrica a través de WiFi, y Bluetooth. El dispositivo funciona
con un núcleo Linux, Android o Mozilla Firefox OS. Además, existen versiones optimizadas
de Android y Ubuntu que están implementadas a partir de Linaro (Instruments 2012).
39
2 ESTADO DEL ARTE
Figura 2.23: Imagen de la PandaBoard ES.
2.4.2.3 Arduino Mega 2560
La Arduino Mega 2560 es una placa que incluye un microcontrolador ATmega2560. Esta
placa lleva 54 entradas o salidas digitales y 14 de estas pueden utilizarse para salidas PWM.
Además lleva 16 entradas analógicas, UARTs (de inglés Universal Asinchronous Receiver
Transmitter).Posee, además, un oscilador de 16MHz, una conexión USB, un conector de
alimentación, un header ICSP y un pulsador para el reset. La placa lleva todo lo necesario
para soportar el microprocesador. Para empezar a utilizar la placa sólo es necesario
conectarla al ordenador a través de un cable USB, o alimentarla con un adaptador de
corriente AC/DC o una batería, y programarla en función de las necesidades del proyecto
a implementar (Bergmann, Wallace & Calia 2010). Tiene una memoria Flash de 256 KB,
el bootloader ocupa unos 8 KB, una SRAM de 8 KB y una memoria EEPROM de 4 KB.
Figura 2.24: Imagen de la Arduino Mega 2560.
40
PROYECTO FIN DE GRADO
Una de las características más interesantes de la MEGA 2560 es que no utiliza el convertidor USB-serial FTDI, sino que utiliza el microprocesador Atmega8U2 programado como
convertidor USB-serial, lo que nos permite que esta placa sea reconocida como cualquier
tipo de interfaz USB.
2.4.2.4 Fit-PC2
El Fit-PC2 proporciona un rendimiento completo similar al de un PC, pero a diferencia
de un ordenador normal requiere sólo 10W de potencia a pleno funcionamiento. El Fit-PC2
encaja en casi cualquier espacio, y además de su construcción está pensada para ambientes
industriales donde su uso es continuado veinticuatro horas al día y siete días a la semana, es
decir, es una plataforma bastante robusta. El Fit-PC2 no tiene ventilador y se diferencia
de las otras plataformas embebidas en que tampoco tiene GPIOs, por lo que con esta
plataforma no se podrían gobernar directamente los motores. El Fit-PC2 no encaja del
todo en este proyecto ya que no posee GPIO, sin embargo solo serviría para implementar
los algoritmos de visión artificial y desplegar el RLMS de WebLab-Deusto (Garcia-Zubia,
Angulo, Hernandez, Castro, Sancristobal, Orduña, Irurzun & de Garibay 2010).
Tiene una CPU basada en un chip de Intel US15W SCH, con una memoria RAM de 2GB
DDR2-533, además tiene un disco duro integrado SATA HDD. Para los gráficos una GPU
Intel GMA500 con aceleración de gráficos, además de una entrada Ethernet y tecnología
WiFi integrada.
Figura 2.25: Imagen del Fit-PC2.
41
2 ESTADO DEL ARTE
2.4.2.5 BeagleBoard
La BeagleBoard es una placa hardware de bajo consumo de código abierto producida
por Texas Instruments en asociación con Digi-Key. La BeagleBoard fue diseñada con el
desarrollo de software de código abierto en la mente, y como una manera de probar el
procesador de Texas Instruments OMAP3530. La placa fue desarrollada por un pequeño
equipo de ingenieros como recurso educativo que podría ser utilizado en universidades de
todo el mundo para enseñar hardware de código abierto y las capacidades del software de
código abierto (Gowtham 2011).
La BeagleBoard mide aproximadamente 75 por 75 mm y tiene toda la funcionalidad
de un ordenador muy básico. El procesador OMAP3530 incluye una CPU ARM CortexA8, que puede ejecutar Linux, FreeBSD, RISC OS, Android o Symbian. Posee un DSP
TMS320C64x acelerador de vídeo y una GPU PowerVR SGX530 para proporcionar acelerado y renderizado de imágenes 2D y 3D compatible con OpenGL. Tiene una única ranura
para tarjetas SD y MMC que soporta SDIO, un puerto USB, una conexión serial RS-232,
una conexión JTAG, y dos jacks estéreo de 3.5mm para audio.
Incorpora además 256MB de memoria flash NAND y 256 MB de RAM. La placa utiliza
hasta 2W de potencia y puede ser alimentado desde el conector USB, o una fuente de alimentación separada de 5V. Debido a su bajo consumo de energía, no requiere refrigeración
adicional ni disipadores de calor.
Figura 2.26: Imagen de la Beagleboard.
42
PROYECTO FIN DE GRADO
2.4.2.6 Comparación entre las plataformas embebidas propuestas
En la table 2.4 y 2.5 se puede ver una comparación entre las caracteristicas mas importantes de cada una de la plataformas embebidas.
Plataforma
Raspberry PI
PandaBoard ES
Arduino Mega 2560
Fit-PC2
BeagleBoard
CPU
ARM11
ARM Cortex-A9
ATmega2560
Intel Atom Z530
ARM Cortex-A8
GPU
VideoCore IV
PowerVR SGX540
NO
Intel GMA500
PowerVR SGX530
Tabla 2.4: Comparación de CPU y GPU de las plataformas embebidas.
Plataforma
Raspberry PI
PandaBoard ES
Arduino Mega 2560
Fit-PC2
BeagleBoard
Ethernet
3
3
7
3
3
WiFi
7
3
7
3
7
GPIO
26
28
74
7
32
Linux
3
3
7
3
3
Tabla 2.5: Comparación de las comunicaciones de las plataformas embebidas.
2.4.3 Cámaras e iluminación
El experimento remoto propuesto en este proyecto requiere de la utilización de cámaras
para la captación de imágenes de la pecera así como de iluminación para maximizar la
calidad de las imagenes obtenidas. Por tanto este apartado se dividira en dos subapartados:
• Cámaras
• Iluminación
2.4.3.1 Cámaras
Todas las imágenes obtenidas serán posteriormente procesadas mediante software para
detectar la posición de los elementos sumergibles respecto al nivel del agua. Las cámaras
utilizadas estarán conectadas a la Raspberry PI, encargada de procesar las imágenes.
Será necesario procesar un gran número de imágenes por segundo y, por ello, es preferible
evitar las operaciones de escritura y lectura en memoria física, ya que esto introduciría
considerables ralentizaciones en el programa.
Por este motivo y debido a que el puerto USB de algunas de las plataformas embebidas
propuestas están pobremente implementados y proporcionan velocidades de transferencia
muy bajas, se decidió que era preferible la utilización de cámaras IP, basadas en conexiones
de red inalámbrica (WiFi) (Torralba et al. 2003). Esto permite evitar el acceso a memoria
de disco y realizar la lectura de las imágenes partir de una dirección IP fija, reduciendo
43
2 ESTADO DEL ARTE
así considerablemente la latencia del sistema. Además, el uso de una cámara IP confiere
mayor flexibilidad de despliegue al sistema, ya que la cámara no debe necesariamente estar
colocada cerca de el sistema embebido que se encargue de procesar las imágenes.
Siguiendo este razonamiento, se buscaron modelos de cámaras IP de bajo coste y con una
confiabilidad testada en laboratorios remotos anteriores. Se encontraron las dos siguientes:
• D-Link DCS-5220 Pan/Tilt Camera
• D-Link DCS-930L Celestres N Network Camera
Ambos son modelos ampliamente utilizados anteriormente en WebLab-Deusto para otros
experimentos remotos.
La primera cámara, la D-Link DCS-5220, tiene como principal característica el hecho
de que se trata de un modelo Pan-and-Tilt, es decir, que incluye dos servomotores que
permiten rotar la cámara tanto en un eje vertical (“pan”) como en uno horizontal (“tilt”).
Esto resulta útil en situaciones en las que la vista de la cámara no llega a abarcar toda
la imagen que se quiere obtener. En este caso, la cámara puede moverse para enfocar las
zonas deseadas. En cuanto a características técnicas, soporta conexión Ethernet o 802.11g,
está equipada con un sensor CMOS de 0,5 Lux que la hace ideal para condiciones de baja
luminosidad y tiene zoom digital de hasta 4x.
Figura 2.27: Camara D-Link
DCS-5220.
La DCS-930L por su parte no se trata de un modelo Pan-and-Tilt, sino de un modelo
convencional. Esto la hace más ligera y fácil de instalar, pero menos flexible, ya que no
permite ajustar el ángulo de visión de la cámara. Sin embargo, a nivel de conexión, este
modelo ofrece 802.11n, emplea un sensor CMOS y también dispone de un zoom digital de
hasta 4 aumentos.
44
PROYECTO FIN DE GRADO
Figura 2.28: Camara D-Link DCS-930L.
Este experimento remoto, se basa en la recepción de imágenes de varias cámaras, ya
que resulta imposible captar la vista de toda la pecera desde un solo dispositivo. Podría,
no obstante, hacerse uso de una cámara Pan-and-Tilt, que rotara para visualizar toda
la pecera, pero el problema, en este caso, surgiría del elevado tiempo que utilizaría la
cámara en reposicionarse. Por ello, resulta más conveniente utilizar 3 cámaras simples:
una para una vista general y dos para captar dos objetos sumergibles cada una. En
base a lo anterior, tras considerar las necesidades del proyecto y las características de
cada cámara, se optó por la DCS-930L, al tratarse ésta de una solución que permite
implementar el protocolo 802.11n, de mayor cobertura y mayor tasa de transferencia de
datos que la versión 802.11g empleada por el modelo alternativo y resultar, asimismo, una
opción económica en términos de costes (Li, Babcock & Parkhurst 2006).
2.4.3.2 Iluminación
Respecto a la iluminación es necesario recalcar que igual que al igual que el ojo humano,
la visión artificial depende de la iluminación y la óptica para poder trabajar. Métodos
diferentes de iluminación pueden tener efectos visuales muy diferentes (Lee, Breneman &
Schulte 1990). A este respecto, es importante señalar que contar con una buena iluminación resulta trascendental a la hora de poder realizar un análisis sobre una imagen con
contraste suficiente entre las partes a inspeccionar y el fondo.
2.4.3.2.1 Técnicas de iluminación
Dentro de la iluminación podemos distinguir varios técnicas como son:
• Iluminación posterior o backlight
• Iluminación frontal oblicua y direccional
• Iluminación de campo oscuro o darkfield
45
2 ESTADO DEL ARTE
La iluminación posterior o backlight permite delinear el contorno de las piezas, minimizando la visibilidad de gabinetes traslúcidos en caso de que existan y permite visualizar
perforaciones pasantes. Esta técnica brinda un contraste muy alto y es fácil de implementar (Brosnan & Sun 2004). En las imágenes tomadas bajo esta técnica, el fondo aparece
uniformemente blanco y el objeto se visualiza mediante su silueta. Dentro de las técnicas
de iluminación posterior se pueden encontrar la difusa y la direccional. En la iluminación
posterior difusa los rayos de luz se transmiten en diversos ángulos y en la iluminación posterior direccional un colimador hace que todos los rayos de luz se propaguen en direcciones
paralelas como podemos ver en la figura 2.29.
Figura 2.29: Iluminacion posterior difusa y direccional.
La dirección de la iluminación, conocida como el ángulo de incidencia, es él ángulo
formado por el plano normal a la superficie y el rayo incidente. Cuando los haces de
luz forman un ángulo de 20 grados con la superficie, se puede maximizar el contraste en
objetos con relieves de manera que los bordes aparezcan brillantes frente al fondo oscuro
que forman las superficies planas del objeto. En la iluminación frontal direccional, el
ángulo entre los rayos incidentes y la superficie es de 30 grados, lo que reduce un poco el
contraste pero incrementa la cantidad de información obtenible de las superficies planas.
Entre los dispositivos comerciales se pueden encontrar los anillos y los domos. Los anillos
son adecuados para superficies planas y difusas. Están disponibles en espectro blanco, rojo,
IR, UV, azul, verde, iluminación continua o pulsante, con lente difusor o no difusor. Los
domos producen una iluminación difusa y uniforme. Se utilizan para iluminar superficies
reflectantes. Están disponibles con luz continua o pulsante y fuentes conectadas mediante
fibra óptica.
46
PROYECTO FIN DE GRADO
Figura 2.30: Iluminacion frontal oblicua y direccional.
La iluminación de campo oscuro o darkfield es luz directa de alta intensidad que se hace
incidir sobre el objeto con un ángulo muy pequeño respecto a la superficie donde descansa.
De esta manera se consigue que sobre superficies que presentan hendiduras o elevaciones,
éstas interfieran en la trayectoria de la luz produciéndose zonas brillantes. Esta técnica
consiste en hileras de LEDs montadas a 75 o 90º con respecto al eje óptico. La iluminación
puede ser continua o pulsante (strobe). Además del modelo en anillo, también se fabrican
con haces paralelos ajustables individualmente. La iluminación de campo oscuro realza el
contraste de los detalles superficiales tales como grabados, marcas y defectos.
Figura 2.31: Iluminacion de campo oscuro.
47
2 ESTADO DEL ARTE
2.4.3.2.2 Tipos de iluminación
Anteriormente, se presentaron las distintas formas de iluminar un objeto teniendo en
cuenta las técnicas de iluminación existentes para las diferentes aplicaciones. A continuación, el enfoque estará puesto en los dispositivos comerciales que se utilizan en la
actualidad:
• Fibra óptica
• Fluorescentes
• LED
• Láser
Cada uno de ellos presenta sus particulares ventajas y desventajas con respecto al uso
concreto que se le pretenda otorgar. Es por esto que, dependiendo del tipo de aplicación
resultará más conveniente uno u otro.
La elección estará basada en el análisis de los siguientes cuatro factores condicionantes
del tipo de iluminación:
• La intensidad lumínica necesaria para captar correctamente las imágenes y poderlas
procesar posteriormente con un dispositivo embebido.
• La duración de la iluminación escogida. No resultaría de utilidad el despliegue de
un laboratorio cuya utilización prevista es de veinticuatro horas al día, siete días a
la semana funcionando si fuera necesario cambiar la iluminación cada 300 horas.
• La flexibilidad de diseños que permita su adaptación al tipo de laboratorio que se
esté desarrollando, pero que además se disponga de recambios en caso necesario.
• El precio de adquisición de los diferentes componentes de la iluminación, así como
su fluctuación en el mercado.
Fibra óptica
La iluminación mediante fibra óptica proporciona una gran intensidad de luz uniforme,
con ausencia de sombras. Es ideal para iluminar objetos de reducidas dimensiones y se
puede sujetar al objetivo de la cámara o a la óptica de un microscopio. A los anillos de
luz se les pueden acoplar filtros de colores, polarizadores/analizadores, y difusores para
eliminar reflejos y aumentar el efecto difusor.
48
PROYECTO FIN DE GRADO
Fluorescentes
La iluminación mediante fluorescentes proporciona una luz brillante, sin sombras. Las
lámparas son diseñadas normalmente para suministrar el máximo de intensidad durante al
menos 7000 horas, lo que proporciona una mayor productividad. Existen lámparas blancas
en distintas temperaturas de color, Y también ultravioletas (UV). Esta iluminación se
aplica en entornos que requieren mucha luz, y ningún tipo de sombra, (análisis biológicos,
inspección y la microscopía, Ensamblaje, Inspección de circuitos, Industria, Laboratorios,
Visión Industrial, Fotografía, Control de Calidad, Robótica, etc.).
LED
La iluminación mediante diodos led proporciona una luz difusa muy útil para la aplicación en ciertos objetos. Pueden ser de iluminación directa y en anillo.
Láser
La iluminación mediante láser se basa en una serie de patrones láser que se utilizan
mayoritariamente en aplicaciones de medida de profundidad, y de superficies irregulares.
Mediante ópticas especialmente diseñadas se puede llegar a convertir un puntero láser en
diferentes formas y tamaños.
49
PROYECTO FIN DE GRADO
3. JUSTIFICACIÓN DE LAS
TECNOLOGÍAS UTILIZADAS
En esta sección se explicarán las tecnologías elegidas y sus motivos. Es importante
recalcar que todas las elecciones se han hecho teniendo en cuenta que la idea inicial era que
la arquitectura implementada se basará en sistemas de código abierto, así como hardware
libre en el caso de las plataformas embebidas. También resulta necesario tener en cuenta
que se utilizaran exclusivamente tecnologías libres, con licencia pública, y reconocidas como
estables y robustas para evitar problemas futuros. El uso de estas tecnologías permite
ofrecer un precio asequible, ahorrando licencias, así como la posibilidad de ofrecérselo a
una comunidad que con carácter adicional a su utilización, pueda mejorarlo y volver a
ofrecérselo a la comunidad creando una espiral que beneficie el desarrollo de soluciones
eficientes y en constante evolución. Además de ser libres, se pensó que estas tecnologías
deberían ser portables, es decir que funcionen tanto bajo sistemas Unix como bajo sistemas
Windows, y otros sistemas operativos.
3.1 SUBSISTEMA DE MANIPULACIÓN Y GESTIÓN REMOTA DEL
LABORATORIO
Como ya se ha señalado en el capítulo 2 de este proyecto este subsistema permite la
experimentación y gestión del laboratorio. A este respecto, ha sido necesaria la realización
de una gran cantidad de pruebas, así como el consejo de personal altamente cualificado con
experiencia en el área ppara poder satisfacer cada uno de los requisitos de este subsistema.
Las decisiones tomadas para la justificación de las tecnologías usadas en este subsistema
se pueden dividir en las secciones que a continuación se señalan:
• Arquitectura del subsistema
• Dispositivo embebido y sistema operativo asociado
• Mecatrónica
• Servicios web
• Lenguajes de programación
51
3 JUSTIFICACIÓN DE LAS TECNOLOGÍAS UTILIZADAS
3.1.1 Arquitectura del subsistema
A la hora de seleccionar la arquitectura del subsistema se ha determinado que la estructura más adecuada es aquella en la que todo el subsistema en su conjunto posee una
arquitectura distribuida frente a una centralizada o mixta, ya que permite tener una redundancia del sistema (Garcia-Zubia et al. 2008). Gracias esta redundancia se aumenta la
confiabilidad del sistema, es decir, se consigue una escalabilidad mayor y mucho más fácil
que con una arquitectura centralizada. Este aspecto constituye uno de los puntos fuertes
del sistema, ya que la idea es que sea posible replicar de manera rápida y fácil el laboratorio. Además una separación la arquitectura distribuida permite hacer una separación de
tareas en subtareas, lo que influye en una mejor respuesta del sistema. Es reconocido el
hecho de que al no basarnos en una arquitectura centralizada, en el eventual supuesto de
que se estropee uno de los sistemas, el fallo no implicaría una caída del sistema central.
Otra de las fortalezas de la elección considerada se basa en la apertura del sistema. Como
se ha señalado en capítulos anteriores, los sistemas distribuidos son normalmente sistemas
abiertos, lo que significa que se diseñan sobre protocolos estándar que permiten combinar
equipamiento y software de diferentes implementados en diferentes tecnologías (Tian-ran
& Dao-kui 2002). Además la concurrencia en un sistema distribuido permite que varios
procesos puedan operar al mismo tiempo sobre diferentes dispositivos de la red, lo que
puede redundar en una gran ventaja a la hora de procesar una gran cantidad de imágenes.
Estos procesos pueden comunicarse con otros paralelamente durante su funcionamiento
normal interactuando para minimizar los tiempos de procesado.
3.1.2 Dispositivo embebido y sistema operativo asociado
Uno de los principales requerimientos de este subsistema es que debe estar implementado
sobre una plataforma hardware de bajo coste, y si fuera posible libre para permitir, de esto
modo, la adicción de características customizadas en caso de que fuera necesario. En este
caso se ha escogido la plataforma llamada Raspberry PI, ya que usa un sistema operativo
basado en el núcleo Linux, que es popular entre programadores y desarrolladores e implica
un espíritu de colaboración, y todos los sistemas de WebLab-Deusto están basados en
Software libre (Hertel, Niedner & Herrmann 2003). Como desventaja de la Raspberry PI
cabe señalar que no es hardware libre.
Como inciso, y debido a que hay un gran debate detrás de los que es el hardware libre, a
continuación se detallan brevemente las características del software libre. Los dispositivos
de hardware libre son aquellos cuyas especificaciones, diseños y esquemas son de acceso
público (que no siempre implica gratuidad) y que, en cierta medida, lleva al mundo del
hardware la filosofía del software libre.
La raspberry PI tiene abiertas sus especificaciones, sin embargo no provee de sus diseños
ni esquemas. Se ha escogido un sistema Linux como sistema operativo ya que permite
ejecutar varios procesos a la vez de forma ininterrumpida, es decir, se puede disponer de un
servidor web en ejecución y, simultáneamente disponer de la utilización de otros programas
sin ningún inconveniente. Además la Raspberry PI posee una serie de características que
la hacen perfecta para el proyecto en cuestión.
52
PROYECTO FIN DE GRADO
La primera de las características es que posee varios puertos GPIO (General Purpose
Input Output), necesarios para la conexión y comunicación con dispositivos electrónicos
como los motores que se utilizan o señales audibles en ciertos eventos importantes del
sistema.
La segunda de las características que contribuyen a la idoneidad viene de la mano de
la conectividad. La Raspberry PI posee un controlador 10/100 Ethernet (RJ-45) vía hub
USB, le que permite conectividad con otros dispositivos a través de Ethernet. Además
existe un modulo USB llamado WiPI cuyo coste es de aproximadamente 20€ que prove
a la Raspberry PI de conectividad WiFi que el sistema operativo seleccionado soporta
nativamente.
El coste de la Raspberry PI modelo B es de aproximadamente 35 Euros, y su consumo
eléctrico es bastante ajustado. En base a varios estudios acometidos al respecto, se calcula
que el consumo mensual del dispositivo con una media de funcionamiento de 24 horas al
día, y una utilización de la CPU al 15% de media, oscila entre 0,5 y 1 € en la factura
eléctrica (Pi & An 2012). No obstante, estos estudios no son fácilmente aplicables a nuestro
proyecto ya que no consideran el movimiento de los motores por lo que previsiblemente,
el consumo de energia en este caso será mayor.
Respecto al sistema operativo que gobernará la placa se ha seleccionado la distribución
Raspbian Wheezy. Raspbian Wheezy, un sistema operativo Linux libre basado en Debian
Wheezy (Debian 7.0) diseñada específicamente para la Raspberry Pi (Trapp 2013), orientado a la enseñanza de informática. Raspbian Wheezy posee soporte para I2C, SPI y One
Wire, además, cuenta con un servidor SSH por defecto para acceder a la placa y ocupa
tan poco que cabe sin problemas en una tarjeta SD de 4GB.
3.1.3 Mecatrónica
En lo que a la mecatrónica se refiere, los motores serán controlados mediante los GPIOs
de la Raspberry PI. Tras la realización de diversos ensayos, se decidió descartar la utilización de los servomotores para este tipo de aplicación, puesto que el rotor debía ser capaz
de rotar 360º y los servomotores estudiados tenían una libertad de movimiento limitada a
180º como consecuencia de su método de construcción.
Por lo tanto, las opciones más convenientes en este caso serian por un lado slos motores
paso a paso y por otro, los motores DC. A este respecto,una característica deseable para
este proyecto es que los objetos a sumergir sean liberados lo más rápidamente posible, para
así simular en tanto en cuanto es posible una caída libre, se requieren altas velocidades
de revolución. Asimismo, es necesario prever que quizás sea necesario utilizar objetos
sumergibles de hasta un kilogramo. Esto decanta la elección a favor de los motores DC,
puesto que los motores paso a paso perderían demasiado par a altas velocidades.
Una vez determinada la opción de utilizar motores DC, se realizó un pequeño estudio
sobre varios modelos disponibles en el mercado a través de distribuidores conocidos y de
confianza.
53
3 JUSTIFICACIÓN DE LAS TECNOLOGÍAS UTILIZADAS
Como resultado, se obtuvo la siguiente lista de modelos (se incluyen además algunas de
sus características):
Motor
Pololu D3
Pololu II
M12V200
Cytron
EMG30
Voltaje
6VDC
12V
12V
12V
12V
Reductora
50:1
30:1
RPM
120
200
200
170
170
Par
3.6 kg·cm
12 kg·cm
3.59 kg·cm
2.75 kg·cm
1.5 kg·cm
Extras
Encoder
Encoder
Encoder
Encoder
Encoder y sensores de efecto Hall
Tabla 3.1: Comparativa entre los motores seleccionados.
Finalmente, se seleccionó el modelo EMG30, ya que es un motor de 12v totalmente
equipado con encoders y con una caja reductora 30:1. Este motor resulta ideal para
aplicaciones pequeñas como la nuestra, y nos proporciona una relación calidad coste de
las más altas de todos los motores que hemos estudiado. Además posee sensores de efecto
Hall necesarios en nuestra aplicación para la determinación de la posición de los motores
en cada momento.
Para poder manejar los motores a través los GPIO de la Raspberry PI fue necesaria una
electrónica asociada. Toda esta electrónica, fundamentalmente basada en la utilización de
resistencias, conectores y drivers L293N, así como una PCB (Printed Circuit Board) capaz
de controlar cuatro motores de manera independiente, fue desarrollada e implementada
en el experimento del acuario. Además, dado que los motores debían encargarse del izado
y arriado de los objetos sumergibles que acabarán en la pecera, y no existía en el mercado
ninguna solución que se adaptara a las necesidades del proyecto, se tuvieron que fabricar
unas poleas a medida. Para la fabricación de estas poleas a medida su tuvo hacer un estudio
tanto de las fuerzas implicadas como de las características necesarias para la adaptación
de las mismas a los motores seleccionados. Posteriormente se diseñaron las poleas desde
DeustoTech Telecom a petición del tutor de este proyecto, Nacho Angulo Martínez. Estas
poleas fueron diseñadas en una herramienta de edición 3D, teniendo en cuenta todo lo
anterior, y se imprimieron en una impresora 3D profesional.
Figura 3.1: Polea diseñada.
54
PROYECTO FIN DE GRADO
3.1.4 Servicios web
Este subsistema utiliza servicios web para todas las comunicaciones que lleva a cabo.
Todas estas comunicaciones se hacen contra el servidor de WebLab-Deusto, y desde el
comienzo se ha determinadoque sean comunicaciones asíncronas. En las comunicaciones
asíncronas el emisor envía la información sabiendo que puede no obtener una respuesta
inmediata. El receptor será consciente de la llegada de los mensajes sólo cuando este
acceda al canal específico. Por tanto, se suele decir que la disponibilidad del emisor o
receptor es incierta y marca de forma importante el contexto de la comunicación.
Para llevar a cabo todas estas comunicaciones se ha elegido utilizar REST (Representational State Transfer). Un concepto importante en REST es la existencia de recursos
(elementos de información), que pueden ser accedidos utilizando un identificador global
o URI (Uniform Resource Identificator). REST Está totalmente bajo las especificaciones
del protocolo HTTP (Hipertext transfer Protocol), en donde todo actúa como un único
recurso, ni siquiera los servicios se escapan, se trata el mensaje igual que si de un elemento
HTML se tratase (Hipertext Markup Language) (Wilde 2007). Además, no resulta tan
estricto como SOAP (Simple Object Access Protocol). Es decir, los datos pueden mantenerse estrictamente o de forma desacoplada, mediante la URI, y los recursos implicados
pueden consumirse fácilmente desde JavaScript (la mayoría de las aplicaciones que utilizan
OpenID o el protocolo OAuth utilizan JavaScript para realizar llamadas con REST, por
ejemplo twitter).
Por último, resulta importante enfatizar que para sistemas embebidos como los que se
desean manejar, se ha tratado de lograr que r que los mensajes transmitidos sean bastante
ligeros, de manera que no se vea perjudicado el rendimiento y la escalabilidad óptima
del sistema. Para poder alcanzar este propósito se estima que el formato más adecuado
resulta de la utilización de XML (Extensible Markup Language) o JSON (JavaScript Object
Notation) (Crockford 2006).
En el caso particular del presente proyecto, la comunicación entre los diferentes dispositivos hace uso de JSON, ya que desde el punto de vista del sistema interesa un formato
ligero para el intercambio de datos, frente a la principal alternativa XML, un lenguaje de
marcado de propósito general. La elección de JSON se debe asimismo a la velocidad en que
se procesa desde JavaScript (lado cliente) y a que resulta muy simple su procesado tanto
para humanos como para máquinas. Ademas, JSON está orientado a las estructuras de
datos de los lenguajes de programación modernos y no se necesita la validación mediante
esquemas de las respuestas, como en el caso de XML.
3.1.5 Lenguajes de programación
El lenguaje de programación escogido constituye un punto importante en este proyecto,
ya que, en parte, el tiempo de desarrollo del sistema depende de él. Además, se pretende
que este proyecto pueda ser reutilizado y reimplementado por un gran número de usuarios.
Por tanto, se debe escoger un lenguaje fácil de entender y rápido de aprender por personal
no especializado. En consecuencia, se ha escogido el lenguaje de programación Python
(Python Software Foundation 2013) para la implementación completa de los servicios
web.
55
3 JUSTIFICACIÓN DE LAS TECNOLOGÍAS UTILIZADAS
Python es un lenguaje de programación de alto nivel, fácil de aprender, y con librerías
creadas y fácilmente modificables para todas las tareas que necesitábamos desarrollar.
Asimismo, Python consituye un lenguaje de código libre y disponible para la mayoría de
los sistemas operativos actuales. Además genera un código fácil de leer y su biblioteca
estándar es muy completa. Este lenguaje es especialmente útil en la materialización de
los objetos en JSON para transmitirlos al lado del servidor. Las principales librerías que
se usan en este subsistema son WebIOPi (Eric Ptak 2013) para el control y debugueo de
los GPIO, así como, para tener una interfaz web que provee de acceso directo a los GPIO,
y Tornado para la creación de los servicios web. Gracias a WebIOPI se consigue tener
una API para la gestión de los GPIO de manera fácil y rápida, y permite relacionar la
Raspberry PI con el Internet de las cosas. Por otra parte, Tornado permite implementar
fácilmente servicios web asíncronos, pudiendo escalar a decenas de miles de conexiones
abiertas mediante el uso de conexiones no bloqueantes.
Para la programación de los motores se ha escogido el lenguaje de programación C. Se
ha detrminado que C es la opción más adecuada debido a la necesidad de rutinas de bajo
nivel. A pesar de usar programación C, en esta parte se creará una API para llamar a las
funciones desde Python, y que así, el tiempo de desarrollo sea menor.
3.2 IMPLEMENTACIÓN DE RLMS EN PLATAFORMA EMBEBIDA
DE BAJO COSTE
Uno de los puntos fuertes de este proyecto está constituido en base a la elección del RLMS
que gestionará el laboratorio remoto que se pretende diseñar. El RLMS está llamado a
encargarse tanto del acceso a los usuarios del sistema como de la compartición de archivos,
la gestión de colas, etc. pero también se tiene que encargar, por ser el caso especial de la
pecera, del procesado de las imágenes provenientes de la pecera, así como de mantener los
procesos asociados a estas imágenes. Por tanto, vemos se pueden diferenciar dos partes
importantes:
• RLMS
• Dispositivo embebido y sistema operativo asociado
3.2.1 RLMS
En cuanto a los RLMS que se testaron se determinó que la mejor opción, era el RLMS
WebLab-Deusto. Weblab-Deusto permite hacer uso de la autenticación basada en OpenID
o LDAP, lo que abre las puertas a que toda la comunidad educativa pueda disfrutar del
laboratorio remoto desarrollado.
Esta alternativa ofrece también la gestión de colas para manejar de forma transparente
las reservas del laboratorio basándose en tiempos, asi como en permisos de usuarios.
WebLab-Deusto permite asimismo escalar el experimento automáticamente, así como
extenderlo en el momento que lo necesitemos. Además, su interfaz web de adminis-
56
PROYECTO FIN DE GRADO
tración permite dar permisos a usuarios automáticamente dependiendo del dominio al
que pertenezca su logueo. Por último, y quizás lo más importante, Weblab-Deusto nos
provee de la capacidad de que el desarrollo que se haga en web valga tanto en ordenadores
como en dispositivos móviles, lo que implica que un mayor número de usuarios puedan
acceder al experimento (WebLab-Deusto 2005 onwards).
Además, la implementación del lado servidor de WebLab-Deusto está íntegramente realizada en Python, el lenguaje de programación en el que se pretende desarrollar el laboratorio entero y programar los servicios web. Esto, teóricamente, permite que la interacción
sea más fácil entre los distintos dispositivos implicados en el laboratorio remoto. El despliegue de WebLab-Deusto en esta plataforma es tan fácil como bajarse el código fuente
de Github, y seguir las instrucciones para su instalación. Además, los desarrolladores de
WebLab-Deusto se encuentran en la misma universidad en la que se desarrolla el proyecto,
luego, en caso de tener algún problema, es más fácil contactar con ellos que con los desarrolladores de otros RLMS como MIT iLabs o LabShare Sahara.
3.2.2 Dispositivo embebido y sistema operativo asociado
Respecto a la plataforma que ha sido usada para embeber WebLab-Deusto es preciso
señalar que existian básicamente dos candidatas principales que cumplían los requisitos
básicos, la Raspberry PI y la PandaBoard ES. La Raspberry Pi, ofrecía la ventaja de
ser muy económica, y de poder basar el laboratorio enteramente en Raspberry Pis. No
obstante, finalmente se seleccionó la PandaBoard ES. La PandaBoard ES fue seleccionada
ya que el laboratorio remoto tenía que implementar una aplicación de visión artificial que
presumiblemente necesitaría procesar imágenes de una manera fluida, y después de probar
la Raspberry PI se llegó a la conclusión que esta solo podía ofrecer unas cuatro imágenes
por segundo más el procesado asociado a las mismas, y eso, en las mejores condiciones.
Por otro lado, se realizaron pruebas con la PandaBoard ES y era capaz de procesar entre
veinte y veinticuatro imágenes por segundo sin ningún problema, además de guardarlas
en su tarjeta SD y ofrecerlas mediante un servicio basado en REST, como hemos descrito
anteriormente. La PandaBoard ES tiene un procesador Dual-Core de 1.2 GHz cada uno
para llevar a cabo las tareas y una GPU PowerVR SGX540 para hacer todo lo relacionado
con el procesado de imagen.
Dentro de la PandaBoard ES se ha elegido introducir también un sistema operativo
basado en Linux, ya que, WebLab-Deusto está más orientado a desplegarse en plataformas
con sistemas operativos de este tipo.
El sistema elegido ha sido Ubuntu Server 12.04 LTS (basado en Linaro por ser un
procesador ARM), ya que es LTS (Long Term Support), lo que implica que desde la fecha
que salió, hasta dentro de cinco años ofrecerá actualizaciones y soporte. Ubuntu ofrece un
sistema operativo fácil de usar, con un gestor de paquetes muy intuitivo frente a las otras
opciones que eran Armstrong o Linaro. Parece la opción más viable para un desarrollo
rápido en la PandaBoard ES. Además, en la PandaBoard ES existe la posibilidad de
programar directamente sobre un DSP (Digital Signal Processor) integrado que permite
el procesado de imágenes en tiempo real, algo muy importante en este tipo de proyectos.
57
3 JUSTIFICACIÓN DE LAS TECNOLOGÍAS UTILIZADAS
Para poder utilizar el DSP se ha decidido instalar los extras de TI OMAP (Texas Instruments, Open Multimedia Applications Platform) sobre la distribución escogida, Ubuntu
Server 12.04 LTS, así como volver a reconstruir el Kernel Linux para que sea un Kernel
Linux de tiempo real. A un sistema operativo de tiempo real RTOS (Real Time Operating
System) se le puede exigir que sea determinista, fiable, y tolerante a los fallos (Yodaiken
& Barabanov 1997).
3.3 IMPLEMENTACIÓN DE UNA INTERFAZ SENCILLA PARA
EL MANEJO DEL LABORATORIO REMOTO
La interfaz web es uno de los puntos más importantes de cara a la utilización del laboratorio remoto, ya que constituye la primera impresión en la experiencia de utilización del
laboratorio remoto. Una de las principales máximas que se debe respetar es la usabilidad,
así como la estética no recargada. Asimismo, los esfuerzos en este sentido deben encaminarse a que el laboratorio configurado logre probar la arquitectura propuesta en todas las
modalidades de laboratorio que existen. Por esto, en un momento inicial del proyecto se
pensó que sería más interesante implementar dos interfaces diferentes para probar los dos
tipos de laboratorios que tiene WebLab-Deusto, los laboratorios gestionados y los laboratorios no gestionados. Se decidió también que lo mejor sería que las dos interfaces se
implementaran usando tecnologías web y con la capacidad de acceder a todos los recursos de manera asíncrona, desde cualquier parte del mundo, y cuando fuera necesario, así
como crear interfaces compatibles con dispositivos móviles. Por tanto, se diferencian dos
alternativas:
• Interfaz web para laboratorios gestionados
• Interfaz web para laboratorios no gestionados
3.3.1 Interfaz web para laboratorios gestionados
Tras analizar las opciones existentes se determino que en la parte de los laboratorios
gestionados se usaría GWT (Google Web Toolkit).
La decisión de usar GWT se basó en el hecho de que permite crear aplicaciones web multiplataforma y multinavegador, desarrollando ágil y rápidamente, además de que reduce
el ancho de banda una vez cargada la aplicación en la caché y una cosa más importante
en nuestro caso, reduce la carga en el servidor (los datos que con otras tecnologías se
cargan en la sesión del servidor con GWT pasan al cliente). Además, en este caso no son
necesarios conocimientos de JavaScript, únicamente de Java, ya que posee un compilador
Java-to-JavaScript y un browser especial que ayuda en el debug de las aplicaciones. Ayudo
a decidir también el hecho de que la mayoría de los laboratorios actualmente desplegados en WebLab-Deusto poseen una interfaz de usuario basada precisamente en GWT que
además, hacen uso de diferentes servicios web.
58
PROYECTO FIN DE GRADO
3.3.2 Interfaz web para laboratorios no gestionados
Para la parte de laboratorios remotos no gestionados se determino que la mejor opción
se basa en la utilización de tecnologías diferentes a las que usa WebLab-Deusto, pero que
resultan plenamente compatibles con este. Así, que en cuanto a ejecución de código en
el navegador del usuario para determinar la disposición de los resultados, las alternativas
son básicamente dos: utilizar código JavaScript o una aplicación utilizando la tecnología
de Adobe Flash.
La primera alternativa está hoy presente en la práctica totalidad de los navegadores y,
aunque hay problemas por las diferencias entre los distintos intérpretes, existe cierto grado
de estandarización. La segunda nos permite evitar esas diferencias de ejecución en los
distintos navegadores si utilizamos la implementación oficial, sin embargo las aplicaciones
Flash son pesadas de cargar, su tecnología es privativa (lo que va en contra de la naturaleza
abierta de la web, y nuestro proyecto) y obligan al usuario a instalar un complemento a
su navegador que muchas veces no está disponible en todos los navegadores, como pasa en
los de los dispositivos móviles. Por esta razón se decidió usar JavaScript para el desarrollo
de la interfaz web del cliente para el laboratorio no gestionado. Debido a la falta de un
estándar claro de JavaScript/ECMAScript es aconsejable la utilización de una biblioteca
que permita no tener que preocuparse porque los desarrollos se ejecuten de formas distintas
en los diferentes navegadores. Además la utilización de grandes bibliotecas o framework
simplifican la manipulación del DOM (Document Object Model), el tratamiento de eventos
y la comunicación asíncrona. Dentro de la amplia variedad de librerías para JavaScript
disponibles se optó por el uso de jQuery por su velocidad y simplicidad, porque tiene una
baja curva de aprendizaje bastante fácil y cuenta con una excelente documentación y tiene
una gran cantidad de extensiones.
A la hora de hacer la disposición de resultados en la pantalla, una vez descartada la
tecnología Adobe Flash por las razones comentadas, queda básicamente la utilización de
HTML junto a Twitter Bootstrap. se usa HTML ya que HTML5 es aún un borrador,
y por tanto, no aportaría demasiadas funcionalidades, aunque en un futuro puede ser
una buena opción. HTML5 está aún en proceso de implantación y sólo disponible en
las últimas versiones de los distintos navegadores y en algunos casos parcialmente. En
cuanto a CSS se ha elegido desarrollar sobre Twitter Bootstrap (Twitter, Inc. 2013), un
framework CSS liberado por twitter que permite un desarrollo rápido de la interfaz web.
Bootstrap es una colección de herramientas de software libre para la creación de sitios y
aplicaciones web. Contiene plantillas de diseño basadas en HTML y CSS con tipografías,
formularios, botones, gráficos, barras de navegación y demás componentes de interfaz, así
como extensiones opcionales de JavaScript.
3.4 IMPLEMENTACIÓN DE VISIÓN ARTIFICIAL PARA EL LABORATORIO REMOTO
La visión artificial es uno de los puntos más críticos del experimento en cuanto a procesado de datos. Implica a los dispositivos hardware que capturarán las imágenes, en este
caso cámaras, y la plataforma que procesará estas imágenes y se las ofrecerá al sistema,
así como el software que se utilice para procesar estas imágenes.
59
3 JUSTIFICACIÓN DE LAS TECNOLOGÍAS UTILIZADAS
Se puede dividir en varias partes:
• Dispositivos de captura de imágenes
• Dispositivo embebido y sistema operativo asociado
• Software de procesado de imágenes
• Tipos de formatos de imagen
• Iluminación
3.4.1 Dispositivos de captura de imágenes
En cuanto a los dispositivos de captura de imágenes se ha elegido la opción de cámaras
web frente a las opciones alternativas, cámaras vía USB (Universal Serial Bus) o cámaras
integrada en las plataformas embebidas. Lo que determino que se optara por las cámaras
web fue la capacidad que tienen de guardar ellas mismas las imágenes y devolverlas a
través de un servicio web a una velocidad realmente rápida, en muchos casos triplicaba
la velocidad de realizar la misma tarea de una cámara vía USB. Las cámaras web permiten recoger imágenes en el momento que sean necesarias sin tener que preocuparse por
guardarlas en disco a cada momento. Si fuera necesario guardar estas imágenes a cada
momento el sistema se ralentizaría mucho. Esta ventaja se ve potenciada por el hecho de
que las cámaras web que han sido elegidas funcionan por WiFi, lo que evita una buena
parte del cableado que representa una tarea engorrosa en cualquier laboratorio remoto.
A pesar de esto, en caso necesario, estas cámaras tienen la opción de usar cableado
tipo Ethernet. Las cámaras web seleccionadas poseen algunas desventajas respecto a las
cámaras USB como son el hecho de que las cámaras vía USB presentan mucha calidad
de imagen por un precio razonable, mientras que con las cámaras web si quieres mucha
calidad de imagen los precios se disparan. Después de algunas pruebas se ha llegado a la
conclusión de que en este laboratorio la máxima calidad no es necesaria, con una cámara
de calidad media es suficiente.
Las cámaras web que han sido seleccionadas son las que corresponden al modelo DCS932L de la marca D-Link, ya que son cámaras muy fáciles de utilizar e instalar, simplemente
es necesario bajar un software al ordenador ysiguir los pasos que aparecen en su página
web.Este seria el proceso a seguir en sistemas operativos Windows, en nuestro caso se ha
utilizado el programa NMAP para hacer un mapeo de los dispositivos conectados a la red,
encontrar las cámaras y configurarlas. Por último es necesario añadir que estas cámaras
ya se usan en otros laboratorios y parece que tienen una calidad de imagen suficiente para
el laboratorio a desarrollar, y el precio es bastante ajustado.
60
PROYECTO FIN DE GRADO
3.4.2 Dispositivo embebido y sistema operativo asociado
En lo relativo al hardware utilizado para el procesado de las imágenes, después de varios
pruebas realizadas se ha decidido compartirlo con la plataforma que tendrá dentro el
RLMS, en este caso WebLab-Deusto, como hemos dicho más arriba. La primera idea fue
tener un dispositivo especializado únicamente en el procesado de imágenes como un DSP, o
una FPGA programada especialmente para el procesamiento y guardado de las imágenes,
así como para servir las mismas.
Debido al coste, y es que estos sistemas eran costos en general, y a que el uso de este
hardware específico complicaba un poco más el desarrollo de los sistemas web asociados
a este, se decidió utilizar la PandaBoard ES, un hardware de propósito general, con un
precio bastante ajustado, y lo más importante en este caso, con un DSP integrado para el
procesado de las imágenes y el servicio web que las compartiría con el RLMS.
3.4.3 Software de procesado de imágenes
Ya se han explicado las características de la PandaBoard ES anteriormente, por lo que no
se será objeto de reiteración en este apartado. Sin embargo, es preciso añadir que uno de
los motivos de elección de la PandaBoard ES es que al poder ejecutar sobre ella un sistema
operativo de propósito general como Ubuntu Server 12.04, el procesado de imágenes se
puede basar en bibliotecas ya hechas y testeadas sobre este tipo de plataformas durante
mucho tiempo.
Después de probar las diferentes bibliotecas de procesado de imagen que aceptaba esta
plataforma se decidió usar OpenCV, ya que además de ser software libre y tener API tanto
para C, C++ y Python, arrojó los tiempos de procesado menores en algunas de las tareas
de procesado que más se estimaba que se iban a usar. Para estas pruebas se usó un equipo
Pentium M a 1.7GHz, y se realizaron cuatro tareas diferentes que pretendían parecerse a
las que realizamos en el proyecto:
• 2D DFT: Transformada Discreta de Fourier de una imagen de 512 × 512 píxeles.
• Cambio de tamaño: Se pasó de una imagen de 512 × 512 píxeles. a otra de 384 ×
384 píxeles, mediante interpolación bilineal. Las imágenes eran de ocho bits y tres
canales.
• Flujo óptico: Se siguieron 520 puntos con una ventana de 41 × 41 píxeles. y 4 niveles
de la pirámide.
• Red neuronal: buscamos el punto de referencia de una red en FANN (Fast Artificial
Neural Network Library).
61
3 JUSTIFICACIÓN DE LAS TECNOLOGÍAS UTILIZADAS
Los resultados se pueden ver en la figura 3.2
Figura 3.2: Comparación de rendimiento de librerías de Visión Arti cial
Como podemos ver en la figura anterior, la librería que mejor rendimiento ofrece en
todos los casos es OpenCV, además, si se tiene instalado IPP se puede apreciar que los
tiempos de ejecución son más bajos. Esto se consigue gracias a la optimización de código
que ofrece IPP.
Como esta decisión constituía una elección de gran importancia, ya que todo el procesado
de imagen iba a desarrollarse con el software que fuera elegido, se comprobó entre las
diferentes opciones que OpenCV tenía para acceder directamente al DSP de la PandaBoard
ES. En el caso de OpenCV solo era necesario instalar un complemento, mientras que con
otras librerías era necesario volver a compilar algunas de las librerías del sistema operativo
cambiándoles algunos de los flags, lo que parecía ser bastante engorroso.
En cuanto al lenguaje de programación a utilizar para el procesado de imágenes se volvió
a seleccionar Python, ya que es el mismo lenguaje que se iba a utilizar para el desarrollo de
los sistemas web. Como se puede apuntar que programando con las librerías de OpenCV
con la API de C, o C++ existe soporte para más funciones, e incluso en algunas funciones
es posible seleccionar opciones a más bajo nivel. Sin embargo, en este proyecto todas las
necesidades quedan cubiertas programando con la API de Python. A modo de anécdota,
es necesario informar de que al principio se empezó a programar con la API de C, ya
que se pensaba que la API de Python no iba a tener implementadas todas las funciones
necesarias en el proyecto.
Después de comprobar de nuevo la documentación de OpenCV resultó evidente que
todas las funciones que se usaban en el proyecto de la API de C estaban también en la
API de Python, y las que no estaban eran de fácil implementación. Por este motivo, se
decidió cambiar inmediatamente. Además, se llegó a la conclusión de que la integración
directa de OpenCV en los servicios web reducía los tiempos a la hora de compartir las
imágenes entre las diferentes partes del sistema implicadas en el procesado de las mismas,
62
PROYECTO FIN DE GRADO
y a la hora de guardarlas.
3.4.4 Tipos de formatos de imagen
Respecto al formato de las imágenes, y después de hacer un estudio sobre todas las
opciones posibles buscando utilizar un único formato, se decidieron utilizar dos formatos
diferentes. Esta decisión fue tomada como consecuencia de que existían diferentes necesidades a cubrir que no se podían solucionar sólo con uno de los formatos.
Por una parte, para mostrar una sucesión de imágenes en tiempo real que generen la
sensación de vídeo en la pantalla del usuario se ha elegido usar el formato JPG (Joint
Photographic Experts Group), ya que este formato utiliza un algoritmo de compresión con
pérdida para reducir el tamaño de los archivos de imágenes con flexibilidad a la hora de
ajustar el grado de compresión. Así, los usuarios no necesitan descargarse tantos datos,
ni el servidor tiene que mandarlos y ocupar todo su ancho de banda.
Por otra parte, para las imágenes estáticas que le llegaran al usuario cuando las solicite
se le servirán en formato PNG, ya que se necesita hacer uso de transparencias, y JPG
no lo permite. Además, PNG es un formato sin pérdida de calidad con una excelente
compresión.
3.4.5 Iluminación
Dado que la iluminación era un factor importante se optó por desarrollar un sistema
de iluminación a medida. Este sistema de iluminación se determino en basea muchas
pruebas realizadas a lo largo de todo el proceso de desarrollo del proyecto. De este modo,
se determinó que la mejor forma de iluminación, de acuerdo con el presupuesto acordado,
consistía en una serie de tubos fluorescente por la parte trasera de 60W cada uno, así
como una lámina opaca para conseguir una iluminación difusa, y la adicción de otro tubo
fluorescente en la parte superior que iluminara directamente los objetos sumergibles.
La iluminación posterior no era suficiente ya que permitía marcar bien las siluetas pero
otorgaba poco color a los objetos sumergibles haciéndolos difícilmente identificables. estopor este motivo, se incluyó un fluorescente en la parte superior. Gracias a este fluorescente
es posible la identificación de los objetos sumergibles por color, además deconsiguir una
imagen visualmente más atractiva.
63
3 JUSTIFICACIÓN DE LAS TECNOLOGÍAS UTILIZADAS
Figura 3.3: Imagen de el acuario con la iluminación seleccionada.
64
PROYECTO FIN DE GRADO
4. DISEÑO E IMPLEMENTACIÓN
En este capítulo se presenta, en base a la justificación de las tecnologías utilizadas que
se ha hecho en el capítulo anterior, cómo fue diseñado y desarrollado el proyecto. Desde
el punto de vista de desarrollo, es necesario dividir la fase de ejecución en varios procesos
principales. Cada uno de ellos se ocupará de uno de los aspectos clave del proyecto:
• Subsistema de manipulación y gestión remota del laboratorio
• Implementación de RLMS en plataforma embebida de bajo coste
• Implementación de una interfaz sencilla para el manejo del laboratorio remoto
• Implementación de visión artificial para el laboratorio remoto
4.1 SUBSISTEMA DE MANIPULACIÓN Y GESTIÓN REMOTA DEL
LABORATORIO
Dentro del subsistema de manipulación y gestión remota del laboratorio se pueden diferenciar entre la parte software de este subsistema, y la parte hardware. Para ello se ha
decidido dividir esta sección en dos secciones que se complementan entre ellas:
• Dispositivo embebido y mecatrónica
• Servicios web
4.1.1 Dispositivo embebido y mecatrónica
Una vez definidos los elementos a utilizar, expuestos en el capítulo 3, se llevó a cabo
el diseño de una PCB que sirviera para establecer las comunicaciones entre el hardware
específico del laboratorio, los motores, drivers, etc. con la plataforma embebida seleccionada.
El primer paso después del diseño de esta PCB estuvo constituido por la puesta en
marcha de la raspberry PI. Para ello se hizo la instalación del sistema operativo, en este
caso Raspbian Wheezy, sobre una tarjeta SD de 4GB. La imagen de Raspbian Wheezy
se puede bajar de forma gratuita, ya que es un sistema operativo libre basado en Debian GNU/Linux, de la pagina web oficial del proyecto Raspberry PI (http://www.
raspberrypi.org/downloads), y una vez se tiene la imagen en un ordenador, y teniendo
en cuenta que estas instrucciones solo sirven para algunos sistemas Linux, como Ubuntu,
se debe ejecutar el comando mostrado en el bloque de código fuente 4.1.
65
4 DISEÑO E IMPLEMENTACIÓN
sudo dd if=/home/gustavo/2013−02−09−wheezy−raspbian.bin of=/dev/sdc bs=4M
Bloque de código fuente 4.1: Comando para la grabacion de Raspbian en la tarjeta SD.
Este comando permite copiar y convertir datos de archivos a bajo nivel. Con el parámetro
if se especifica el origen de los datos, y con el parámetro of se especifica el destino, que
en este caso es la tarjeta SD. Por último, con el parámetro bs se especifica el número de
bytes a leer y escribir en cada uno de los cachos que se vayan grabando.
Una vez instalado y configurado el sistema operativo Raspbian Wheezy dentro de la
Raspberry PI resultó necesario pensar en el número de motores que se decidirían mover con
cada Raspberry PI. En un primer momento se pensó que lo ideal sería que cada Raspberry
PI pudiera gestionar hasta seis motores, pero después de revisar la documentación de los
pines de la Raspberry PI y las especificaciones de los motores y drivers elegidos se llegó
a la conclusión de que cada Raspberry PI sólo podría gestionar un máximo de cuatro
motores. Además, sólo es posible la gestión de cuatro motores por cada Raspberry PI
si se conecta solo uno de los sensores de efecto Hall para cada uno de los motores (cada
motor posee dos sensores de efecto Hall). El hecho de solo poder conectar cuatro motores
encuentra su razón en que la Raspberry PI solo proporciona diecisiete GPIO totalmente
programables, y es necesario un mínimo de cuatro pines por cada motor, es decir, que se
usan un total de dieciséis pines para los cuatro motores, y el que sobra se ha usado para
poner un zumbador que avise ante ciertos eventos de la Raspberry PI.
Figura 4.1: Diagrama de pines de la Raspberry PI usando la librería
WiringPI.
66
PROYECTO FIN DE GRADO
Como se ha mencionado anteriormente, cada uno de los motores se gestiona a través de
cuatro pines conectados directamente a los GPIO de la Raspberry PI como se explica a
continuación:
• El primero de estos pines se usa para de la lectura de uno de los sensores Hall (el
segundo permitiría adivinar la dirección, que en este caso conocemos al gobernarla
directamente) permitiendo saber el número de vueltas que ha dado el motor en cada
momento.
• Dos de los pines de los motores se usan para gestionar el terminal positivo y el
terminal negativo del motor.
• El ultimo pin se conecto directamente al driver asociado al motor, en este caso el
L298N, más concretamente a su pin de “enable”, que se utiliza para ahorrar energía
activando las salidas del driver solo cuando es necesario.
En la figura 4.2 se puede observar el esquemático que fue desarrollado con el software
Eagle para el conexionado de los motores, sus drivers asociados, y los GPIO de la Raspberry PI en la PCB que se desarrolló. Se puede observar además que cada PCB tiene
conexión con sus cuatro motores EMG30 asociados que se ha comentado anteriormente,
así como dos drivers y los GPIO de la Raspberry PI. Es preciso señalar que señalar que
siguiendo los datasheets de cada uno de los componentes electrónicos usados se pusieron
una serie de resistencias y varios condensadores, pero cuando se ensamblaron todos los
componentes en el laboratorio resultó que no funcionaban correctamente, y después de un
estudio exhaustivo de la electrónica se decidieron quitar los condensadores e inmediatamente la PCB pasó a funcionar. En la documentación del driver L298N aparecen estos
condensadores como aconsejados, sin embargo en la práctica estos condensadores no sólo
no hacen falta, sino que en nuestro caso llevaron al mal funcionamiento de los motores. Se
puede apreciar también como cada uno de los sensores de efecto Hall llevan una resistencia
del tipo ”pull up” asociada.
Una pequeña anécdota con respecto al mal funcionamiento de esta PCB fue que la
primera que llegó se ensamblo como se suponía que debería funcionar siguiendo cada una
de las especificaciones. Sin embargo se olvidó deshabilitar los pines de comunicación serie
(TX-RX) de la Raspberry PI. Estos pines si no se deshabilitan mandan por el pin de
transmisión todos los mensaje de arranque del sistema por defecto. Como era de esperar
se quemaron varias pistas de la PCB y hubo que arreglarlas manualmente.
Aunque en el esquemático de la PCB no se aprecia se puede apreciar mejor en las figuras
4.3 y 4.4 que corresponden a la PCB creada, los conectores elaborados específicamente
para la placa. Fue preciso desarrollar dos librerías en Eagle para dos conectores diferentes
presentes en la placa.
67
4 DISEÑO E IMPLEMENTACIÓN
Figura 4.2: Esquemático de la PCB diseñada.
68
PROYECTO FIN DE GRADO
La primera librería que se creó fue dirigida a los conectores de los motores, estos conectores llamados JST PHR6 son unos conectores de muy bajo coste, pero también con muy
poca documentación, y por supuesto sin librerías para Eagle (o por lo menos no hubo suerte
a la hora de encontrarlas). La librería que se creó íntegramente, encajo perfectamente a
la hora de soldar los conectores, y por supuesto, fue liberada a la comunidad.
La otra segunda librería que se creó fue la de los pines para acoplarla a la Raspberry
PI como si fuera un shield de Arduino. Esta librería se obtuvo de Internet, pero al no
responder a las necesidades que se le demandaban, se sometió a diversas modificaciones.
Gracias a estas modificaciones, la placa quedó perfectamente encajada sobre la Raspberry
PI. También se liberó a la comunidad esta librería, y los esquemáticos de la placa entera.
Figura 4.3: Parte delantera de la PCB diseñada.
Figura 4.4: Parte trasera de la PCB diseñada.
69
4 DISEÑO E IMPLEMENTACIÓN
Una vez fabricada la PCB se procedió al montaje de la misma y a la ejecución de las
pruebas independientes de cada subsistema.
En este punto, y dado que se necesitaba comprobar que el trabajo que se había realizado
funcionaba efectivamente como se esperaba, se procedió al montaje la PCB que se había
creado con todos los componentes soldados sobre la Raspberry PI. En la figura 4.5 se
puede observar una figura que muestra exactamente el resultado.
Figura 4.5: PCB montada sobre la Raspberry PI.
Posteriormente, se incluyeron las cuatro poleas y se estableció la estructura capaz de
soportar tanto el peso de la Raspberry PI como el de los motores, sin eludir el peso de las
tres cámaras web que posteriormente se introducirían. Además este soporte debía considerar asimismo el espacio necesario para albergar el correcto funcionamiento del dispositivo
de suministro de comida para los peces , por lo que no podía tratarse de una placa sin
ningún tipo de agujero sobre la pecera, sino que debía de tratarse de una superficie específicamente diseñada a medida que permitirá suministrar el alimento a los peces asi como la
posible introducción de objetos en el agua. Esta estructura se construyó con MakerBeam
y termino resultando perfecta y de fácil adaptación al entorno de trabajo.
Como consecuencia de que en algunos puntos la estructura estaba demasiado vencida
por el peso de los diferentes componentes del sistema, se trato de liberar parte de la carga
enganchando unos pequeños anclajes al techo que se unían a la estructura mediante una
cuerda de pita desde el techo a la estructura. Esto liberó mucho la carga que soportaba la
estructura en algunos de los extremos, y mejoró la estabilidad de la misma. La estructura
quedó tal y como aparece en la figura 4.6.
70
PROYECTO FIN DE GRADO
Figura 4.6: Poleas y estructura montadas sobre el acuario.
Por último, se engancho cada uno de los elementos sumergibles, en este caso bolas de
ping pong con líquidos diferentes para conseguir pesos diferentes y, por tanto, densidades
diferentes, mediante cuerdas de pita a cada una de las poleas y se volvió a comprobar su
funcionamiento. La prueba fue totalmente positiva, el funcionamiento fue el esperado y
no existió ningún problema.
Adicionalmente, ya que se necesitaba mantener una línea de agua constante para que no
hubiera ningún problema al izar y arriar los elementos sumergibles seleccionados y tener
así un sistema fiable y robusto, se decidió instalar un dispositivo nivelador de agua. Este
dispositivo posee un sensor magnético que mide constantemente el nivel del agua y cuando
sobrepasa por debajo ese nivel una bomba empieza a bombear agua hasta llegar al nivel
óptimo. La inclusión de este dispositivo fue motivada como consecuencia de la observación
de que durante semanas la pecera perdía cerca de cinco litros de agua al día. En la figura
4.7 se puede ver una de las poleas con la bola de ping pong colocada.
71
4 DISEÑO E IMPLEMENTACIÓN
Figura 4.7: Poleas y estructura montadas sobre el acuario.
4.1.2 Servicios web
El siguiente estuvo constituido por la programación de los motores desde la Raspberry
PI. Para ello, se hizo uso del lenguaje de programación C.
El programa creado EMG30.c se encarga de la gestión de los motores. Este programa
permite decidir el número de vueltas que el motor sube o baja, así como saber en qué
posición se encuentran los motores gracias al sensor de efecto Hall integrado y un contador interno. Este funcionamiento es posible gracias a una serie de argumentos que se
introducen para su consideración a la hora de la llamada al mismo. En el bloque de código
fuente 4.2 se puede observar una parte del importante código programado que lo que llama
a la librería wiringPi, que es libre, está realizada en el lenguaje de programación C y se
encarga de gestionar fácilmente todos los GPIO de la Raspberry PI, lo que supone un
ahorro de tiempo importante en el desarrollo.
Se define el número de objetos sumergibles que tendrá la pecera y un número de vueltas
máximo que como depende del radio interior de la polea se ha calculado a base de prueba
y error. Y se define también una estructura de datos para describir los pines del motor.
Por último se definen dos funciones, una para mover el motor y la otra para mandar datos
a los pines del motor seleccionado. Estas funciones serán explicadas más adelante.
72
PROYECTO FIN DE GRADO
#include <wiringPi.h>
// Libreria de gestión GPIO para la Raspberry PI
#define maxBalls 4
#define maxTurns 12
//1 vuelta = 1/3 de vuelta del motor
typedef struct {
int pinMotorA;
int pinMotorB;
int pinEnable;
int pinSensor;
} motor;
// Pines asignados para el movimiento del motor
// Pin para habilitar el driver del motor
// Pin del sensor de efecto Hall sensor del Motor
void turnMotor(char sense, int turns, motor M); //gira el motor
motor setMotor(int ball);
//selecciona el motor
Bloque de código fuente 4.2: De nicion de la struct motor.
Una vez definida esta estructura del motor se define un nuevo motor en el main del
programa. Como se puede ver en bloque de código fuente 4.3 el main del programa acepta
tres parámetros:
• El primero de ellos es el sentido de giro del motor. Únicamente son válidos los valores
UP y DOWN para subir y bajar el motor respectivamente.
• El segundo es el número de bola que se desea mover. Este número tiene que estar
comprendido entre 1, y el valor de maxBalls.
• El último parámetro es el número de vueltas que debe dar el motor. Este número
tiene que estar comprendido entre 1, y el valor de maxTurns. En este parámetro
cada unidad representa exactamente un tercio de vuelta del motor.
Una vez recibidos los parámetros y comprobados que son correctos se selecciona el motor
al que se le quieren dar órdenes con la función setMotor y se le dan las órdenes de subir
o bajar los elementos sumergibles con la función turnMotor.
Estos parámetros que ahora mismo parecen no muy importantes pasan a ser trascendentales desde el momento que se decide que todo este funcionamiento tiene que pasar
a formar parte de un servicio web al que va a ser necesario llamar desde cualquier parte
del mundo. Es necesario advertir que se han eliminado algunas líneas de código que gestionaban los errores que pudieran ocurrir en la entrada de los parámetros para facilitar la
comprensión del mismo.
73
4 DISEÑO E IMPLEMENTACIÓN
int main(int argc, char * argv []) {
int numBall, numTurns;
char sense;
motor M;
sense = argv [1][0];
numBall = strtol(argv[2], NULL, 10);
numTurns = strtol(argv[3], NULL, 10);
if ((numBall <= maxBalls) && (numTurns <= maxTurns)) {
M = setMotor(numBall);
turnMotor(sense, numTurns, M);
}
return 1;
}
Bloque de código fuente 4.3: Main de programa del motor.
Se implementó también la función turnMotor, que, tal ycomo se ha apuntado anteriormente, sirve para mover el motor en función de los parámetros de entrada. Si recibe UP
mueve el motor en sentido horario para subir los elementos sumergibles, y si recibe DOWN
mueve el motor en sentido antihorario para bajar el elemento sumergible. Dependiendo
del número de vueltas que se le pase a la función el elemento sumergible subirá o bajara
más o menos.
Como se puede ver en el bloque de código fuente 4.4 para escribir un 1 o un 0 sobre un
pin digital utilizamos la función digitalWrite de la librería wiringPi y para leer su valor
utilizamos la función digitalread de la misma librería. Además, fue necesario crear una
variable cont que lleva de las vueltas que ha subido o bajado el elemento sumergible en
cada momento.
void turnMotor(char sense, int turns, motor M) {
int cont = 0;
digitalWrite(M.pinEnable, HIGH);
if (sense == ’U’) {
digitalWrite(M.pinMotorA, HIGH);
digitalWrite(M.pinMotorB, LOW);
} else {
digitalWrite(M.pinMotorA, LOW);
digitalWrite(M.pinMotorB, HIGH);
}
while (digitalRead (M.pinSensor) == 0);
while (cont < (turns * 30)) {
while (digitalRead (M.pinSensor) == 1);
while (digitalRead (M.pinSensor) == 0);
cont++;
}
digitalWrite(M.pinMotorA, LOW);
digitalWrite(M.pinMotorB, LOW);
digitalWrite(M.pinEnable, LOW);
}
Bloque de código fuente 4.4: Funcion turnMotor.
74
PROYECTO FIN DE GRADO
Por último se creó la función setMotor que únicamente sirve para seleccionar el motor
objetivo que queremos mover. Como se puede ver en el bloque de código fuente 4.5 se
definen los pines a los que mandar la información en función del motor seleccionado y
posteriormente se modifican las líneas para ser entradas o salidas. Se han eliminado líneas
de código ya que lo único que aportaban eran los números de los pines.
motor setMotor(int ball) {
motor M;
switch (ball) {
case 1:
// Lineas del motor 1
M.pinMotorA = 8;
M.pinMotorB = 9;
M.pinEnable = 0;
M.pinSensor = 7;
break;
case 2:
// Lineas del motor 2
...
...
default : break;
}
// Modificación de las líneas del motor
pinMode (M.pinMotorA, OUTPUT) ;
pinMode (M.pinMotorB, OUTPUT) ;
pinMode (M.pinEnable, OUTPUT) ;
pinMode (M.pinSensor, INPUT) ;
return M;
}
Bloque de código fuente 4.5: Funcion setMotor.
Para la integración de los motores con los servicios web se utilizo la librería WebIOPI.
WebIOPI es una librería que sirve para facilitar la creación de servicios web asociados
a estos GPIO de la Raspberry PI escrita en lenguaje de programación Python. Usando
WebIOPI lo que se hizo fue crear dos tipos de servicios web diferentes, el primero de ellos es
el que se ha quedado explicado en las páginas anteriores, para subir y bajar las elementos
sumergibles eligiendo el número de vueltas, y el segundo de ellos dirigido a devolvernos
el estado actual de los elementos sumergibles. En la figura 5.1.5 podemos ver cómo han
quedado configurados cada uno de los GPIO gracias a la interfaz web por defecto que
nos provee WebIOPI. Se puede apreciar como están ocupados todos los pines posibles y
que el número de salidas es trece, y el de entradas es cuatro por lo que hemos explicado
anteriormente de la distribución de las líneas de los motores y el zumbador para eventos
de la Raspberry PI.
75
4 DISEÑO E IMPLEMENTACIÓN
Figura 4.8: Interfaz web de WebIOPI.
El servicio web asociado a WebIOPI fue desarrollado para funcionar mediante REST
únicamente haciendo peticiones web de tipo POST y GET, y pasando los datos de un
dispositivo a otro en formato JSON. El servicio se creó buscando la fácil comprensión
del mismo para que en caso necesario se pudieran mejorar o incrementar las funciones
disponibles. En el bloque de código fuente 4.6 se puede ver parte del código que se
desarrolló utilizando WebIOPI. A este respecto,se ha decidido no mostrar todo el código
utilizando, omitiendo aquella parte del código que no aporta información. De este modo,
se puede observar que cuando se hace un GET a la URL /ballStatus/ el programa busca en
los archivos que guardan el estado de cada una de los elementos sumergibles y finalmente
transmite un JSON con estos datos al solicitante además de un código 200 de HTTP que
comunica que todo el proceso ha sido satisfactorio.
def do_GET(self, relativePath):
...
...
elif relativePath.startswith(”ballStatus/”):
(mode, numBall) = relativePath.split(”/”)
for num in range(1, max_balls + 1):
strPath=”/home/pi/emg30/ballStatus%s”, num
with open(strPath) as f:
ball_status[] = f.read()
out =json.dumps(”[’Balls’ : ball_status[] ]”)
return (200, out, M_PLAIN)
Bloque de código fuente 4.6: Servicio web para devolver el estado de los elementos
sumergibles.
76
PROYECTO FIN DE GRADO
Como se puede ver en el bloque de código fuente 4.7 para mover los motores también se
usa WebIOPI. En esta ocasión, en vez de responder a un GET, responde a un POST. Este
Post tiene que llevar como primer parámetro en la URL la palabra MOVE para indicar que
lo que se pretende realizar es el movimiento de los motores. Todos los demás parámetros
son los que se han explicado anteriormente en el código para mover los motores, UP o
DOWN, el número de motor y el número de vueltas. Esta función de Python lo que hace
es llamar a un proceso que alude al programa en C que se ha desarrollado para mover los
elementos sumergibles. Le proporciona un tiempo calculado para ejecutarse y en caso de
no responder correctamente finaliza el proceso y transmite un mensaje de un error. Si el
funcionamiento es el correcto, se mueve el elemento sumergible en función de la petición
y se transmite un código 200 de HTTP seguido de un string indicando que todo todo el
proceso ha sido satisfactorio.
def do_POST(self, relativePath):
if relativePath.startswith(”MOVE/”):
(mode, sense, numBall, numTurns) = relativePath.split(”/”)
cmd = ”sudo /home/pi/emg30/moveBall ” + sense + ” ” + numBall + ” ” + numTurns
proc = subprocess.Popen([cmd], stdout=subprocess.PIPE, shell=True)
for contador_timeout in range(5):
time.sleep(1)
if proc.poll () is not None:
break;
if proc.poll () is None:
proc. kill ()
out = ’Error: Ball is stuck’
else :
(out, err) = proc.communicate()
return (200, str(out)[2:−3], M_PLAIN)
Bloque de código fuente 4.7: Servicio web para mover los elementos sumergibles.
A continuación, se exponen ejemplos de llamadas a cada una de las funciones creadas,
así como una explicación para cada una de ellas y la respuesta recibida por parte de la
Raspberry PI. Es preciso señalar que todos los métodos disponen de una gestión efectiva
de errores tanto en hardware como en software, y en caso necesario se reinicia automáticamente tanto el software como el hardware, poniendo todos los objetos sumergibles en la
posición inicial.
En el caso del primer método que se va a explicar se trata de una petición GET estándar
a un servicio web. Esta petición corresponde a uno de los fragmentos de código fuente
explicados anteriormente. Obviando el hecho de que como se ha desarrollado todo dentro
de una red local se puede usar sin ningún problema el direccionamiento IP local, en este
método se ve como se hace una petición GET a la URL que aparece en el código 4.8, y en
este caso con el parámetro ALL, aunque podría ser también un número entero del uno al
número de motores que haya instalados. Lo que se espera que devuelva es un ”200 OK”
en caso de que la petición se realice correctamente, así como un JSON que debe contener
una lista con un número igual al número de elementos sumergibles presentes en el acuario
representando la posición en la que están mediante un cero para decir que están en la
posición más alta, o un número entero positivo indicando el número de vueltas que han
dado para estar en la posición que se encuentran. Es decir, si el elemento sumergible está
en la posición de arriba del todo el servicio devolverá un 0 para ese elemento sumergible
concreto. Si por el contrario el motor ha dado dos vueltas para que el elemento sumergible
este sobre el agua el servicio devolverá un seis.
77
4 DISEÑO E IMPLEMENTACIÓN
− Petición:
GET /get_status/ALL HTTP/1.1
Host: 192.168.0.130:8000
− Respuesta:
200 OK
Content−Type: application/JSON
{”status”: [0,1,0,7]}
Bloque de código fuente 4.8: URL /get_status/ con parametro ALL.
Este mismo método se puede usar para comprobar la posición de un elemento sumergible
en concreto simplemente poniendo como parámetro el número entero correspondiente a
ese elemento sumergible. Entiéndase que el elemento definido como uno será el que más
a la derecha se encuentra desde el punto de vista del observador. En el ejemplo que se
presenta a continuación, podemos ver lo que ocurre si solicitamos el estado de uno solo de
los elementos sumergibles.
Como podemos ver, por temas de compatibilidad y reutilización de código, si le hacemos
una petición a un solo elemento sumergible devuelve también una lista pero solo con el
número de vueltas de ese elemento.
− Petición:
GET /get_status/4 HTTP/1.1
Host: 192.168.0.130:8000
−Respuesta:
200 OK
Content−Type: application/JSON
{”status”: [7]}
Bloque de código fuente 4.9: URL /get_status/ con parametro numerico.
Otro de los métodos se llama haciendo una petición POST a la URL del bloque de código
fuente 4.10 con una serie de datos que se mandan al servidor a procesar, Estos datos son
únicamente el color de los elementos sumergibles, el líquido que contienen, el peso total de
elemento sumergible, y por último la densidad del líquido que contienen. Ninguno de estos
datos es obligatorio, es decir se puede cambiar en cualquier momento el color sin cambiar
el líquido del interior o el peso. Este método, en caso de que los datos se procesen bien,
es decir que sean añadidos a la base de datos correctamente en la Raspberry PI, devuelve
un JSON con una lista que contiene el número de elementos creados o modificados, y una
respuesta HTTP 201, que indica que un nuevo recurso ha sido creado. En este caso, para
simplificar el proceso se asume que el máximo de elementos sumergibles por el momento
es siempre cuatro, así como que la forma de estos elementos es siempre circular.
− Petición:
POST /calibrate_elements/ HTTP/1.1
Host: 192.168.0.130:8000
element1_color=white&element1_density=0.83&element2_color=yellow
−Respuesta:
201 Created
Content−Type: application/JSON
{”elements_created”: [2]}
Bloque de código fuente 4.10: URL /calibrate_elements/.
78
PROYECTO FIN DE GRADO
Existe otro método, que se nutre de la base de datos generada mediante el método
anterior, y que sirve para conocer el color y la forma de un solo elemento sumergible que
está en esos momentos en la pecera. Este método se llama haciendo una petición GET
a la URL del bloque de código fuente 4.11 seguida de un parámetro que es un número
entero positivo comprendido entre uno y el número de elementos sumergibles que hay en
la pecera. Este método devuelve un JSON con los datos que tiene la base de datos del
elemento seleccionado.
− Petición:
GET /show_element/1 HTTP/1.1
Host: 192.168.0.130:8000
−Respuesta:
200 OK
Content−Type: application/JSON
{”element_1”: {”color”: ”white”,”density”: 0.83}}
Bloque de código fuente 4.11: URL /show_element/.
Por último, existe un método que responde a los POST a otra URL, la del bloque de
código fuente 4.12, y le pasamos tres parámetros. El primero de los parámetros es un string
de texto, y solo tiene dos posibilidades, UP para subir la bola, y DOWN para bajarla. El
segundo de los parámetros es un número entero positivo que representa el número de bola
que queremos subir o bajar. Y el tercero, es otro entero positivo que representa el número
de vueltas que queremos que baje o suba el objeto sumergible.
− Petición:
POST /move_ball/UP/3/5 HTTP/1.1
Host: 192.168.0.130:8000
− Respuesta:
200 OK
Bloque de código fuente 4.12: URL /move_ball/.
La base de datos utilizada para interactuar con estos servicios web fue desarrolla sobre
MongoDB, ya que está pensada precisamente para guardar directamente los archivos de
tipo JSON y devolverlos más rápidamente que lo haría MySQL. Como no necesita esquema
si en algún momento se quiere agregar un nuevo campo temporal se puede hacer sin tener
que cambiar nada de su estructura.
4.2 IMPLEMENTACIÓN DE RLMS EN PLATAFORMA EMBEBIDA
DE BAJO COSTE
Instalar el núcleo del WebLab-Deusto en un sistema Linux es bastante sencillo, ya que
no requiere muchas librerías no instaladas por defecto. SSin embargo, para conseguir
características adicionales a las básicas y ajustar el rendimiento a máquinas especiales es
preciso acometer la realización de algunos pasos más complejos que la instalación básica.
En este caso vale con una instalación básica que implica un despliegue simple. No
requiere ningún servidor web instalado (como Apache o NGINX), ni un motor de base de
datos (como MySQL o MongoDB). En su lugar, WebLab-Deusto hace uso de su servidor
web interno y una base de datos SQLite simple.
79
4 DISEÑO E IMPLEMENTACIÓN
WebLab-Deusto se puede descargar desde github usando git. Esta es la forma recomendada de descargarlo, ya que permite actualizar WebLab-Deusto de forma automática en
el futuro, e incluso contribuir en la implementación de WebLab-Deusto fácilmente. Sin
embargo, se requiere la instalación de git. Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento
de versiones de aplicaciones cuando estas tienen un gran número de archivos de código
fuente. Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena. En la mayoría de las distribuciones de Linux, el paquete está disponible.
En la distribución Ubuntu 12.04 instalada en la PandaBoard ES simplemente es necesario
ejecutar el comando que aparece en el primer lugar en el bloque de código fuente 4.13 y
una vez instalado solo es necesario bajarse el código fuente de github con el comando que
aparece en segundo lugar en el bloque de código fuente 4.13.
sudo apt−get install git
git clone https://github.com/weblabdeusto/weblabdeusto.git weblab
Bloque de código fuente 4.13: Comandos para bajarse el codigo fuente de WebLab-Deusto.
El siguiente paso es instalar todos los requisitos. Lo primero y más importante es instalar
Python, sin embargo en Ubuntu 12.04 viene instalado por defecto. Lo siguiente es instalar
Java Development Kit (JDK) de los repositorios. Como en los repositorios no aparece
directamente el JDK de Sun se opto por instalar openjdk. Se instalaron tambien las
librerias de Python setuptools y python-pip. Para ello se ejecuto el comando que aparece
en el bloque de código fuente 4.14
sudo apt−get install openjdk−7−jdk
sudo apt−get install python−setuptools python−pip
Bloque de código fuente 4.14: Instalacion de Java y Python.
Para instalar propiamente WebLab-Deusto se debe ejecutar el comando que aparece en
el bloque de código fuente 4.15
sudo apt−get install openjdk−7−jdk
sudo apt−get install python−setuptools python−pip
Bloque de código fuente 4.15: Instalacion de WebLab-Deusto.
La primera vez que se ejecutó, pasaron varios minutos, unos veinte, antes de instalarse
entero.Además la cantidad de memoria RAM que requirió fue muy grande. Si alguna vez
se deseara cambiar algo del cliente, o se quisiera actualizar el sistema a través de git, se
podría hacer yendo al directorio del cliente y ejecutando el script Gwtc.sh.
Es bueno tener una instancia de WebLab-Deusto para producción y otra para desarrollo
en caso de que se implemente una interfaz web propia. Con esta intención se creo una
instancia para la web de producción en el puerto 80 y otra instancia para la web de
desarrollo en el puerto 8000 con los comandos que aparecen en el bloque de código fuente
4.16. Seguidamente ponemos ambas instancias en funcionamiento.s
weblab−admin.py
weblab−admin.py
weblab−admin.py
weblab−admin.py
create WebLab−Deusto−production −−http−server−port=80
create WebLab−Deusto−dev −−http−server−port=8000
start WebLab−Deusto−production
start WebLab−Deusto−dev
Bloque de código fuente 4.16: Creacion de instancias en WebLab-Deusto.
80
PROYECTO FIN DE GRADO
Al iniciarse el servidor se hace una conexión de prueba a http://localhost:80 y en esa
URL es en la que se encuentra la pantalla de registro de WebLab-Deusto como se puede
ver en la figura 4.9.
Figura 4.9: Página principal de WebLab-Deusto.
La primera vez que se establece una conexión se deben introducir los credenciales por
defecto que son admin como nombre de usuario y password como contraseña. Puede observarse ver que existen algunos laboratorios de muestra. Uno de ellos es local, aunque
realmente no existe. El resto de los laboratorios están efectivamente ubicados en la Universidad de Deusto. De forma predeterminada, se crean estos laboratorios y se asignan al
grupo de administradores. Estos laboratorios usan el modelo de federación de WebLabDeusto para conectarse a WebLab-Deusto y utilizar equipos reales allí.
En el caso de este laboratorio se decidió federarlo en el WebLab-Deusto ubicado físicamente en la Universidad de Deusto. Para federar el laboratorio es necesario crear un
usuario nuevo desde la interfaz de administración. En la figura 4.10 se puede apreciar
el proceso de creación de usuario. En este caso, como se observa en la figura, se creó
también un grupo llamado Go-Lab por si se diera el caso de querer agregar rápidamente
más laboratorios.
Para que este usuario funcione de forma federada, el WebLab-Deusto ubicado físicamente
en la Universidad de Deusto debe crear también un usuario idéntico al que se creó localmente en la plataforma embebida. De esta forma, y después de tocar unas pocas líneas
de código en el WebLab-Deusto ubicado en la Universidad de Deusto cualquier persona
que se conecte al WebLab-Deusto ubicado en la Universidad de Deusto podrá seleccionar el
experimento ubicado en cualquier parte del mundo gestionado mediante la plataforma embebida. Ademas, como es lógico se debe crear un experimento que apunte al experimento
que se ha creado. En la figura 4.11 se ve el proceso para crear el experimento.
81
4 DISEÑO E IMPLEMENTACIÓN
Figura 4.10: Proceso de creación de un usuario para la federación.
Figura 4.11: Proceso de creación de un experimento.
Al contrario de lo que sucedía al crear un usuario y federar un experimento, en el caso
de crear un experimento no hace falta crear el mismo en el WebLab-Deusto ubicado en la
Universidad de Deusto, ya que este experimento será gestionado desde la copia local de
WebLab-Deusto ubicada en la plataforma embebida.
82
PROYECTO FIN DE GRADO
4.3 IMPLEMENTACIÓN DE UNA INTERFAZ SENCILLA PARA
EL MANEJO DEL LABORATORIO REMOTO
Como ya se ha comentado anteriormente se hicieron dos interfaces webs diferentes, una
para el laboratorio gestionado, y otra para probar el nuevo módulo HTML de weblab para
laboratorios no gestionados. Por tanto esta sección se dividirá en dos módulos:
• Interfaz web para laboratorio gestionado
• Interfaz web para laboratorio no gestionado
4.3.1 Interfaz web para laboratorio gestionado
La interfaz del laboratorio gestionado se hizo con la API de Google Web Toolkit (GWT).
Como ya hemos comentado anteriormente, GWT es un framework creado por Google que
permite ocultar la complejidad de varios aspectos de la tecnología AJAX. El concepto
de Google Web Toolkit es bastante sencillo, básicamente lo que se debe hacer es crear
el código en Java usando cualquier IDE de Java y el compilador lo traducirá a HTML y
JavaScript. Para crear un nuevo laboratorio gestionado dentro de la plataforma WebLabDeusto fue necesario recorrer su estructura de carpetas hasta llegar a la carpeta client/src/es/deusto/weblab/client/experiments. dentro de esta carpeta se hizo una nueva
carpeta llamada aquarium en la se creo un archivo llamado AquariumCreatorFactory.java
que añade la estructura general del nuevo laboratorio, y otra nueva carpeta llamada ui
que debe de contener todos los elementos visuales que apareceran en la interfaz web. El
archivo AquariumCreatorFactory.java es el mismo que el de los demás laboratorios solo
cambiando el nombre de los demás laboratorios por aquarium. Este archivo implementa
el interface IExperimentCreatorFactory como se puede ver en el bloque de código fuente
4.17. y tiene dos métodos, getCodeName y createExperimentCreator. El método getCodeName, devuelve un código exclusivo de laboratorio y posteriormente se utilizará en el
despliegue. El metodo createExperimentCreator crea una clase ExperimentCreator donde
se define la compatibilidad en dispositivos móviles e internamente creará la interfaz de
usuario.
83
4 DISEÑO E IMPLEMENTACIÓN
public class AquariumCreatorFactory implements IExperimentCreatorFactory {
@Override
public String getCodeName() {
return ”aquarium”;
}
@Override
public ExperimentCreator createExperimentCreator(final IConfigurationRetriever
configurationRetriever) {
return new ExperimentCreator(MobileSupport.full, getCodeName()){
@Override
public void createWeb(final IBoardBaseController boardController, final
IExperimentLoadedCallback callback) {
GWT.runAsync(new RunAsyncCallback() {
@Override
public void onSuccess() {
callback.onExperimentLoaded(new AquariumExperiment(
configurationRetriever,
boardController
)) ;
}
@Override
public void onFailure(Throwable e){
callback.onFailure(e);
}
});
}
};
}
}
Bloque de código fuente 4.17: Codigo para la creacion de un experimento en Java.
Lo siguiente es crear los componentes de la interfaz de usuario. Lo primero es crear un
archivo que se llame AquariumExperiment.java y que gestionar el comienzo y la finalización
del laboratorio, así como todos lo widget asociados a él mismo. Este archivo posee un
método AquariumExperiment al que se le pasara toda la configuración y las referencias al
nuevo experimento que se debe crear. También tiene un método start que iniciara todos
los widgets asociados, cargará las configuraciones iniciales y se encargará del tiempo que
se le da a cada uno de los laboratorios. Tiene dos métodos más para refrescarse y para
servir mensajes al resto del sistema. Por último se deben de crear cada uno de los archivos
que contendrán los widgets por separado. En la figura 4.12 se puede ver la interfaz basada
en GWT acabada y funcionando correctamente.
84
PROYECTO FIN DE GRADO
Figura 4.12: Interfaz web del laboratorio gestionado.
4.3.2 Interfaz web para laboratorio no gestionado
Como se ha indicado anteriormente, esta interfaz es responsable de proporcionar la
GUI (Graphical User Interface), así como el control de la gestión del laboratorio. Esto
implica supervisar las comunicaciones entre la PandaBoard ES y la Raspberry PI, la
gestión de dispositivos como las luces o el comedero, y la conexión con una base de datos
que proporciona datos actualizados de cada uno de los diferentes objetos sumergibles. El
cliente también obtiene diferentes imágenes del acuario en tiempo real a través de las
cámaras web. En esencia, este cliente funciona del mismo modo que con la utilización de
servicios web. Se basa en el framework de desarrollo web Django (Django Project 2013),
escrito en el lenguaje de programación Python. Es importante señalar que, aunque Django
se utiliza para implementar las tecnologías del lado servidor, en este caso Django se utiliza
básicamente para ejecutar la aplicación cliente. Se ha implementado una interfaz web de
manera que el usuario pulsa cualquiera de los botones de flechas presentes en la interfaz
(escrita en HTML y Javascript), se envía como un comando POST para llamar a la función
de Python responsable de manejar las peticiones web y devolver las respuestas (Forcier,
Bissex & Chun 2008).
Como se ha comentado, la interfaz se ha implementado como una página web escrita
en HTML, CSS y Javascript, usando las plantillas proporcionadas por Twitter Bootstrap
como punto de partida. Twitter Bootstrap hace que sea mucho más fácil de utilizar las
funcionalidades gráficas e interactiva no avanzadas, como los mensajes emergentes, las
alertas, los botones interactivos, las barras de herramientas desplegables, etc. Twitter
Bootstrap viene incluido con muchos componentes prefabricados, que pueden también
ser fácilmente modificados en CSS para adaptarse a las necesidades particulares de cada
usuario.
85
4 DISEÑO E IMPLEMENTACIÓN
La pantalla principal de usuario incluye una vista frontal del acuario en el lado izquierdo
de la pantalla. Los controles de movimiento de los objetos sumergibles, los botones con
flechas, se colocan en el lado derecho de la pantalla para mejorar la experiencia de los
usuarios de la aplicación y que sean capaces de identificarlos nada más entrar a la aplicación. Debajo de éstos aparece imagen de una cámara secundaria del acuario. En la parte
superior de la pantalla se sitúa la barra de herramientas principal y en la parte inferior
de la imagen principal los botones básicos de la aplicación. En la esquina izquierda de
la barra de herramientas hay un botón con el título “How it works”. que si se presiona
muestra varias alertas pop-up en la pantalla que explica cómo utilizar el sistema. Además
tiene una zona para la formulación de hipótesis por parte del usuario
Una parte importante del código de la página web es el script que se encarga de la
gestión de las cámaras web. Las cámaras operan a través de WiFi, y se les da direcciones
IP estáticas, que se pueden utilizar para devolver capturas de imágenes en formato .jpeg
en tiempo real. La página web del cliente solicita periódicamente a estas cámaras las
imágenes actualizadas. La frecuencia de actualización es lo suficientemente alta de forma
que, si no fuera por la latencia de la red, las imágenes cambiarían lo suficientemente rápido
como para que el ojo humano no fuera capaz de detectar paradas en el movimiento, es
decir, la idea es que a partir de las imágenes, el usuario crea estar viendo un vídeo.
Figura 4.13: Interfaz web del laboratorio no gestionado.
4.4 IMPLEMENTACIÓN DE VISIÓN ARTIFICIAL PARA EL LABORATORIO REMOTO
Con el objetivo de recoger las imágenes proporcionadas desde la pecera, se determinó
el establecimiento de exactamente tres cámaras web principales y una de ellas secundaria.
Solo se hara un análisis de las tres primarias, ya que el propósito de la secundaria no tiene
nada en comun con la visión artificial.
86
PROYECTO FIN DE GRADO
La primera de ellas, la cámara principal, se sitúa en la parte frontal y exactamente en
el medio de la pecera, a una altura similar a la línea de agua de esta, y a una distancia
un poco más lejana que las otras dos de la parte frontal. Esta cámara se encarga de
mostrar las imágenes generales de la pecera, y es la imagen que aparecerá por defecto al
entrar en el laboratorio. Esta imagen permite hacerse una idea general de donde están los
objetos sumergibles y el número exacto que hay. No obstante, con las imágenes servidas
por esta cámara no haremos apenas procesado de imagen, ya que la resolución máxima
que puede entregar es exactamente de 640 x 480 píxeles, y los objetos que se muestran
no tienen, en general, la calidad ni nitidez necesarias para poder procesarlos y recoger
los datos que necesitamos acerca de ellos. Para conseguir este propósito se instalan las
otras dos cámaras que se situan también en la parte frontal de la pecera, pero un poco
más cerca del cristal que la anterior. Una de ellas está a la izquierda, y otra a la derecha,
y cada una de ellas enfocada a dos bolas con mayor detalle que la cámara general para
poder procesar esas imágenes de manera más sencilla y luego devolvérselas al usuario.
Estas cámaras son iguales que la anterior, es decir, que su resolución máxima es de 640 x
480 píxeles, aunque al enfocar a espacios más reducidos que la anterior nos permite mayor
calidad para los mismos objetos. Por último pusimos una cámara que se encuentra en un
lateral, y a una altura muy superior a las demás, por encima de las poleas. Esta cámara
no va a ser susceptible de que sus imágenes sean procesadas, sino que servirá solo para
fines demostrativos. Es el mismo tipo de cámara web que todas las anteriores y servirá
para mostrar como realmente se mueven las poleas cuando alguien usa las poleas desde
cualquier parte del mundo. En la figura 5.4.1 podemos ver la disposición de las cámaras
respecto a la pecera.
Figura 4.14: Disposición de las cámaras en el acuario.
87
4 DISEÑO E IMPLEMENTACIÓN
Para la parte software del sistema de visión artificial de este laboratorio se utilizó la
PandaBoard ES. Desde el principio se pensó en utilizar las librerías de visión OpenCV sobre
C++. Sin embargo, gracias a que a comienzos del proyecto se desarrolló una nueva versión
mucho más completa de OpenCV para Python, se acabó desarrollando sobre Python,
lo que permitía un ahorro de tiempo de desarrollo importante respecto a lo planificado
anteriormente en caso de programarlo en C++. Para la programación se utilizó el IDE
(Integrated Development Environment) Sublime Text 2, ya que permite la programación
orientada a Python, y más concretamente a Django, que es un Framework web basado en
Python que hemos utilizado para crear los servicios web en esta parte. Todo procesamiento
de imágenes está totalmente integrado en Django, para mejorar los tiempos de respuesta
ante las peticiones. Además a la hora de servir los recursos estáticos, las imágenes, se
sirven desde un servidor web NGINX desarrollado para este tipo de tareas.
El procesado de imágenes consta de varios pasos. El primero de los pasos es el reconocimiento de los objetos que están en la pecera cuando el usuario decide hacer una
foto y recibir esa foto procesada. Este procesamiento de imagen se hace basándonos en
el color y forma de los objetos sumergibles. La primera acción que lleva a cabo la PandaBoard es solicitar a la Raspberry PI el estado de los objetos, llamando a la URL del
bloque de código fuente 4.8 del servicio web que hemos explicado anteriormente. Una vez
la Raspberry PI nos devuelve las posiciones de todos los objetos, miramos cada una de
las posiciones distintas de “0”, que es la posición inicial e implica que el objeto está en
la base, y dependiendo de los objetos sumergibles que no estén en la base decidimos con
que cámaras tomar imágenes. En las pruebas que se han llevado a cabo con propósitos
explicativos se ha decidido dar tres vueltas a los motores de dos elementos sumergibles
con densidades diferentes, pero uno junto al otro. Debido a los materiales que contenían
estos objetos, se han quedado cercanos a la línea del agua. Para esta primera versión
asumimos también que todos los objetos van a ser solo de formas circulares, y que ni las
cámaras ni la línea de agua no se mueven. Entonces, empezamos a aplicar los algoritmos
de visión artificial necesarios para reconocer los objetos en pantalla sobre las imágenes que
obtengamos.
Lo primero que hace la PandaBoard una vez que tiene las posiciones de los elementos
sumergibles es pedir las imágenes de la cámara o cámaras que puedan tomar una imagen
de esos elementos sumergibles, pero sin contar con la cámara del medio. Se piden las
imágenes ya que son las de mayor calidad. En la figura 4.15 se puede ver la imagen que
devuelve la cámara de la derecha del acuario. Esta imagen tiene unas dimensiones de
640 x 480 pixeles, y se devuelve en formato JPG de muy alta calidad. Como podemos
ver en este caso los elementos sumergibles tienen densidades muy similares, y por eso su
flotabilidad es muy parecida.
88
PROYECTO FIN DE GRADO
Figura 4.15: Captura de imagen de la cámaras de la derecha.
Una vez la imagen es capturada, se selecciona el área que realmente interesa utilizando
OpenCV. Esta selección se lleva a cabo en función de la posición de cada elemento sumergible. Se usan las funciones boundingRect() para marcar la superficie a cortar y imwrite()
para escribir la nueva imagen en disco. La función boundingRect() recibe como parámetros una lista de cuatro puntos entre los que se encuentran los elementos sumergibles. Esta
función devuelve una imagen que contiene el rectángulo definido por esos cuatro puntos.
Estos puntos pasados se calculan en base al comportamiento esperado de cada una de los
elementos sumergibles implicados. Si la densidad del elemento sumergible es mayor que
la del agua, el elemento flotara y, por tanto, estará situado cercano a la línea de flotación.
Si el elemento tiene una densidad menor que la del agua tenderá a hundirse más y entonces se deberá usar la posición proporcionada por la Raspberry PI para afinar los puntos
necesarios. Una vez ha sido definido el rectángulo mediante la función boundingRect() se
guarda ese área en una variable llamada cropped y se llama a la función imwrite(). De
esta forma se guarda la imagen en disco para futuros usos, además de mantenerse en el
programa como la variable cropped que usaremos.
rect = cv2.boundingRect(point_list)
cropped = original[rect [0]: rect[0]+rect [2], rect [1]: rect[1]+rect [3]]
cv2.imwrite(’cropped.png’, cropped)
Bloque de código fuente 4.18: Codigo para recortar la imagen necesario para la vision
arti cial.
89
4 DISEÑO E IMPLEMENTACIÓN
En la figura 4.16 se puede ver la imagen guardada mediante la función imwrite().
Figura 4.16: Aplicacion de la funcion boundingRect().
La imagen obtenida pasa a ser una imagen de 640 x 200 pixeles, frente a los 640 x 480
pixeles de la imagen inicial, que contiene los elementos que realmente resultan interesantes
para nuestra aplicación. Esta nueva imagen supone un ahorro significativo de tiempo de
procesado en los siguientes pasos, ya que imágenes mayores suponen tiempos de procesado
más altos.
El siguiente paso es la detección los elementos circulares en la imagen. Primero es
necesario ajustar bien el contraste y brillo, para que los siguientes algoritmos puedan
diferenciar más fácilmente las formas y colores de los elementos sumergibles. Todas las
pruebas previas realizadas con la iluminación y las cámaras han llevado a afianzar un valor
de alpha de 1.5 para la mejora del contraste de la imagen. En la figura 4.17 se puede ver
cómo afecta el contraste a la imagen. A partir de este valor alpha se crea una matriz de
las mismas dimensiones y tipo que la imagen con todos sus elementos a ese valor alpha.
Una vez creada la nueva matriz se llama a la función multiply() que permite hacer la
multiplicación de la matriz de la imagen con la creada con los valores alpha elemento a
elemento. Realmente lo que hace esta función es un escalado de los valores de la matriz.
Por otra parte, para mejorar el brillo de las imágenes se usa un valor beta que gracias
a muchas pruebas previas se ha definido con un valor de 30. En la figura 4.18 se puede
ver cómo afecta el brillo a la imagen, y como un brillo de 30 la mejora notablemente. Se
vuelve a crear una matriz del mismo tamaño y tipo que la imagen y se usa la función
add() para sumar esta matriz a la creada en el paso anterior.
alpha = 1.5
beta = 30
contrasted = cv2.multiply(cropped, np.array([alpha]))
brighted = cv2.add(cropped, np.array([beta]))
// contrasted = cropped*alpha
// brighted = cropped*alpha + beta
Bloque de código fuente 4.19: Codigo para ajustar el contraste y el brillo en la imagen.
90
PROYECTO FIN DE GRADO
Figura 4.17: Captura de imágenes cambiando el contraste.
Figura 4.18: Captura de imágenes cambiando el brillo.
91
4 DISEÑO E IMPLEMENTACIÓN
A continuación se aplica la función cvtColor() a la imagen que se acaba de generar
para pasar de la imagen que se dispone en formato RGB (Red Green Blue), que es el
formato por defecto de OpenCV al coger las fotos, a escala de grises. Además se necesita
crear también una copia de la imagen en formato BGR (Blue Green Red) con el método
cvtColor() para que se pueda dibujar encima de ella texto y figuras que puedan ver los
usuarios. Y a la imagen en escala de grises, que es la que se usará para buscar formas, se
le aplica la función GaussianBlur(). Esta función permite desenfocar la imagen usando un
filtro Gaussiano, reduciendo el ruido y algunos detalles significativos. Matemáticamente,
aplicar un desenfoque Gaussiano a una imagen es la convolución de esa imagen con una
función de Gauss. Aplicar un desenfoque Gaussiano permite reducir las componentes de
alta frecuencia de la imagen, es decir, poner un filtro paso bajo. Gracias a este filtro se
evitan falsos positivos en la detección de círculos que se hará posteriormente.
gray = cv2.cvtColor(brighted, cv2.COLOR_RGB2GRAY)
sketch = cv2.cvtColor(gray, cv2.COLOR_GRAY2BGR)
blurred = cv2.GaussianBlur(gray, (0,0), 5)
Bloque de código fuente 4.20: Codigo para cambiar de espacio de color.
En la figura 4.19 se ve la imagen en escala de grises antes y despues de aplicarle el filtro
de desenfoque Gaussiano.
Figura 4.19: Aplicacion del desenfoque gaussiano.
Para el reconocimiento de los bordes en la imagen es necesario aplicar un filtro Canny
(Canny 1986) con la función Canny() a la imagen en escala de grises. El filtro Canny utiliza
un algoritmo de múltiples etapas para detectar una amplia gama de bordes en imágenes.
La función Canny() recibe dos parámetros importantes que se usan para delimitar los
umbrales por histéresis. El umbral alto, que aparece en el código aparece con un valor
120, marca los bordes más diferenciados.
92
PROYECTO FIN DE GRADO
Un valor más alto en este umbral permite reconocer un mayor número de bordes y
viceversa. El umbral bajo, que en el código aparece con un valor 80, se encarga del
seguimiento de las líneas, así como la reducción del ruido asociado. Un valor más bajo en
este umbral permite seguir un mayor número de bordes y viceversa. En la figura 4.20 se
puede ver la imagen con diferentes valores para el umbral alto y el bajo, y como cambian
los bordes detectados en función de estos umbrales.
Figura 4.20: Diferencia entre los diferentes valores para la función de Canny().
Tras realizar un número considerable de pruebas se dictaminó la necesidad de que, en
este caso, se usará un umbral alto de 120 y un umbral bajo de 80, ya que arrojaba los
mejores resultados para hacer frente a las necesidades de la aplicación.
low_threshold = 80
high_threshold = 120
edges = cv2.Canny(gray, low_threshold, high_threshold)
Bloque de código fuente 4.21: Codigo para aplicar el ltro canny a la imagen.
Se puede ver la imagen resultante de aplicar el filtro Canny con los parámetros utilizados
finalmente en el proyecto en la figura 4.21.
93
4 DISEÑO E IMPLEMENTACIÓN
Figura 4.21: Aplicacion del ltro Canny sobre la imagen en escala de grises.
Con carácter previo a encontrar las circunferencias en la imagen, se debe distinguir la
línea de agua, para poder medir las distancias que el elemento sumergible tiene por encima
y por debajo del agua. Medir la línea del agua no es una tarea fácil, ya que uno de los
requisitos es que la línea este totalmente alineada con el nivel de agua para tener medidas
fiables.
Para medir la línea se recurrió a la transformada de Hough, aunque se realizaron pruebas
también la transformada probabilística de Hough (Matas, Galambos & Kittler 2000), los
mejores resultados se consiguieron con la transformada de Hough, ya que es capaz de
interpolar líneas. Como se puede observar en la figura 4.22 la transformada estadística de
Hough nos devuelve segmentos pequeños de línea mientras que la transformada de Hough
nos devuelve líneas enteras.
El algoritmo de la transformada de Hough usa una matriz, llamada acumulador, cuya
dimensión es igual al número de parámetros desconocidos del problema. En este caso,
para detectar la existencia de una recta descrita por la ecuación:
y = (m ∗ x) + n
La dimensión del acumulador sería dos, ya sea su representación en coordenadas cartesianas de la forma (m,n), o en coordenadas polares (ρ, θ), son desconocidas. Las dos
dimensiones del acumulador corresponden a los valores cuantificados para (ρ, θ). Para
construir este acumulador es necesario discretizar los parámetros que describen la figura.
Cada celda del acumulador representara una figura cuyos parámetros se pueden obtener
a partir de la posición de esa celda.
Asi, por cada punto en la imagen se buscan todas las posibles figuras a las que puede
pertenecer ese punto. Esto se logra buscando todas las posibles combinaciones de valores
para parámetros que describen la figura (los posibles valores se obtienen a partir del
acumulador). Si es así, se calculan los parámetros de esa figura, y después se busca la
posición en el acumulador correspondiente a la figura definida, y se incrementa el valor
que hay en esa posición.
Como se puede observar en el codigo de abajo la funcion HoughLines() recibe la imagenes
que representa los bordes de la imagen real como primer parametro. El segundo parametro
94
PROYECTO FIN DE GRADO
que recibe se denomina rho, que es resolucion de la distancia al acumulador expresada en
pixeles. En nuestro caso hemos puesto la minima distancia, que es 1, y que es el minimo
valor para hacer una busqueda exhaustiva. El tercer parametro que recibe se denomina
theta y es la resolucion del angulo del acumulador expresada en angulos, en este caso, por
motivos de rapidez de respuesta se decidio poner un valor de π/180. En cuanto al ultimo
parametro se trata de un umbral de puntuacion, es decir, que las lineas que tengan una
puntuacion por debajo de ese umbral, no se tendran en cuenta (Shi & Tomasi 1994). En
este caso se ha puesto un umbral alto para evitar coger pequeños cachos de lineas.
def find_lines(sketch):
lines = cv2.HoughLines(edges, 1, math.pi / 180, 275)
for rho,theta in lines [0]:
a = np.cos(theta)
b = np.sin(theta)
x0 = a*rho
y0 = b*rho
x1 = int(x0 + 1000*(−b))
y1 = int(y0 + 1000*(a))
x2 = int(x0 − 1000*(−b))
y2 = int(y0 − 1000*(a))
cv2. line (sketch,(x1,y1),(x2,y2),(0,255,0) ,2)
Bloque de código fuente 4.22: Codigo para aplicar la busqueda de lineas.
La imagen de arriba figura 4.22 corresponde a la aplicación en la imagen de la transformada estadística de Hough, mientras que la de abajo corresponde a la aplicación de
la transformada de Hough. Ambas funciones se aplicaron con los mismos parámetros de
entrada, que se pueden ver en el código de más arriba, y generaron salidas totalmente
distintas. En el caso de la transformada estadística de Hough se puede observar como
las líneas que aparecen sólo segmentos de líneas, mientras que la transformada de Hough
efectúa también una interpolación de líneas.
El siguiente paso es aplicar la detección de circunferencias. A pesar de que con el filtro Canny que se ha utilizado anteriormente parece que se reconocen bien los elementos
sumergibles, sin embargo, se hicieron muchas pruebas y no era del todo fiable. Por tanto,
se decidió usar la de nuevo la transformada de Hough para este propósito. Aunque normalmente esta transformada se utiliza para la detección de rectas, también se puede usar con
el propósito de detectar circunferencias y algunas otras figuras geométricas. Entendiendo
que una circunferencia la podemos representar con la ecuación:
(x − a)² + (y − b)² = r²
donde (a, b) es el centro de la circunferencia, r es el radio y (x, y) son pixeles de la
imagen en los que nos vamos situando de forma progresiva.
Como se ha descrito anteriormente la transformada de Hough se basa en dar puntuaciones a diferentes áreas de la imagen variando la posición del centro de la circunferencia
(a, b), para cada píxel etiquetado (x, y), obteniendo los distintos valores del radio r.
Las circunferencias seleccionadas serán aquellas que superen un cierto umbral de puntos
recibidos. Su mayor inconveniente es su alto coste computacional. Sin embargo, gracias a
que la distancia de las cámaras al acuario es constante se puede ahorrar tiempo de computación prefijando una serie de valores del radio del círculo. Así, las posibles coordenadas
95
4 DISEÑO E IMPLEMENTACIÓN
Figura 4.22: Aplicacion de diferentes transformadas de Hough.
del centro del círculo darán una nube de puntos limitados. Esta forma de detección de
los circunferencias posee ventajas como la inmunidad al ruido y la capacidad de detectar
circunferencias aunque exista oclusión de estas.
La función utilizada para detectar circunferencias fue HoughCircles(). Esta función
recibe nueve parámetros. El primero es la imagen sobre la que se realizará la búsqueda de
circunferencias, que es la imagen en escala de grises, y con un ligero desenfoque gaussiano se
ha creado anteriormente. Como segundo parámetro recibe el método que se utilizara para
la detección de las circunferencias. Desgraciadamente OpenCV solo tiene implementado
un método de detección, que es el “2-1 Hough transform” (Yuen, Princen, Illingworth &
Kittler 1990), que permite ahorrar tiempo de computación implementando la transformada
de Hough en dos pasos, en primer lugar se busca el centro y en segundo lugar se buscan
los límites de la circunferencia. Únicamente tiene el problema de que si se comete un fallo
en el primer paso y se desvía el centro o se encuentra un falso centro llevará a errores en
el segundo paso. El tercer parámetro hace referencia a la resolución del acumulador en
función de la resolución de la imagen. La resolución del acumulador será inversamente
proporcional a este acumulador, es decir, si el valor esta puesto a 1 la resolución de
acumulador será la misma que la de la imagen, si esta a 2, la resolución de acumulador
será la mitad de la de la imagen. Este parámetro es importante a la hora de mejorar
tiempos de procesado. En la figura 5.4.10 se pueden observar los diferentes tiempos de
procesado en función de valor escogido para este parámetro. La aprecia claramente que a
menor resolución del acumulador, mayor tiempo de procesado. Esto es debido a que cuanto
más pequeño sea el acumulador más grande es la imagen usada para la transformada. Al
ser más grande tiene más número de pixeles, y por tanto tarda más en procesar. Después
de un análisis minucioso de estos tiempos se decidió que en este caso se iba a seleccionar
un valor de 1.3 para este parámetro, ya que ofrece unos tiempos de procesado óptimos a
la vez que permite una búsqueda de circunferencias muy buena.
96
PROYECTO FIN DE GRADO
Figura 4.23: Tiempos de procesado en segundos.
El siguiente parámetro, el cuarto, indica la mínima distancia entre los centros de las
circunferencias detectadas. Como en esta aplicación las circunferencias estarán separadas
claramente, se puede pensar que este parámetro siempre será superior al radio de las
circunferencias que queremos encontrar. Se entiende que las cámaras se mantiene fijas y
los elementos sumergibles tienen siempre el mismo radio y se mueven dentro del acuario
que también está fijo. Por esto mismo se conoce que los elementos sumergibles pueden
tener un radio de 35 a 45. Esto significa que es ente cuarto parámetro el menor valor a
poner será 18. El quinto parámetro lo único que hace es crear la matriz que contendrá las
coordenadas de las circunferencias encontradas. El siguiente parámetro que se ha utilizado
se llama param1, y hace referencia al umbral más alto de los explicados anteriormente en
el filtro Canny, automáticamente el umbral más bajo será la mitad que este. Aparece
otro parámetro importante llamado param2 que es el umbral del acumulador para la
fase de detección de circunferencias. Si este valor es muy bajo se detectarán muchas
circunferencias que en realidad no existan, y si es muy alto no se detectara ninguna.
Es importante ajustarlo bien. En la figura 4.24 se pueden observar las circunferencias
encontradas para diferentes valores de param2. Se aprecia como un umbral de acumulador
de 15 resulta demasiado pequeño y da muchos falsos positivos mientras que un umbral
de acumulador de 60 resulta demasiado grande y solo encuentra una circunferencia de las
dos. El umbral ideal parece situarse entre 30 y 40.
97
4 DISEÑO E IMPLEMENTACIÓN
Figura 4.24: Capturas con diferentes umbrales del acumulador.
Los últimos dos parámetros minRadius y maxRadius hacen referencia al mínimo y máximo radio esperado en las circunferencias, Como hemos dicho antes, estos valores se han
definido como 35 y 45 respectivamente.
def find_circles (gray):
circles = cv2.HoughCircles(gray, cv2.cv.CV_HOUGH_GRADIENT, 1.3, 20, np.array([]), param1
=20,param2=40,minRadius=35,maxRadius=45)[0]
for pos, c in enumerate(circles [:2]) :
cv2. circle (sketch, (c [0], c [1]) , c [2], (0,255,0) , 2)
cv2.putText(sketch, ”Bola %s” % pos, (c[0] + c[2], c[1] − c[2] ) , cv2.
FONT_HERSHEY_DUPLEX, 1.0,(0,255,0))
Bloque de código fuente 4.23: Codigo para aplicar la busqueda de circulos.
Como se puede observar en la figura 4.24, a veces, este procesado para buscar las circunferencias no es del todo exacto, y es necesario buscar los elementos sumergibles en base a
sus colores. Para esto, se crea una imagen nueva por cada uno de los elementos sumergibles encontrados. Esta imagen será una imagen de 200 x 200 píxeles, que contendrá el
elemento sumergible en el centro de la imagen. Para crear estas imágenes usamos la función GetSubRect(). Esta función recibe una matriz, en este caso la imagen que tenemos,
y el área de la imagen que se desea copiar y pegar en la nueva imagen creada. Este área
98
PROYECTO FIN DE GRADO
de la imagen se define con cuatro parámetros. Los dos primeros corresponden al eje X y
el eje Y que definen el centro del elemento sumergible, y los dos siguientes corresponden a
la distancia en el eje X y el eje Y desde el centro que cortaremos, es decir, las dimensiones
de la nueva imagen.
El centro de las imágenes creadas está basado en el centro que ha sido devuelto por
la función HoughCircles(), luego, puede ser que no sea el verdadero centro. Sobre cada
una de estas imágenes se aplica un filtro para pasar la imagen al espacio de color HSV
(Hue, Saturation y Value, que en castellano corresponde a Matiz, Saturación y Valor). El
espacio de color HSV es muy común a la hora de elegir o encontrar un color dentro de
imágenes. El matiz se representa como un grado de ángulo cuyos valores posibles van de
0 a 360, aunque en OpenCV va de 0 a 180. Cada valor corresponde a un color.
La Saturación se representa como la distancia al eje de brillo negro-blanco. Los valores
posibles van del 0 al 255. Cuanto menor sea la saturación de un color, mayor tonalidad
grisácea habrá y más decolorado estará. El valor Representa la altura en el eje blanconegro, los valores posible son de 0 a 255. Para pasarlas a el espacio de color HSV se usa
la función cvtColor(), y como parámetros le pasamos la imagen a transformar, y el tipo
de transformación a realizar.
Una vez pasada la imagen al espacio de color HSV se le debe aplicar un umbral de
colores para detectar un color en particular. En este caso se le aplicó un umbral para
detectar solo colores amarillos. La función para hacer este umbral es inRange(). A esta
función le pasamos la imagen en HSV y dos matrices con los límites de valores HSV que
queremos que detecte. Estos valores en principio se pueden obtener de tablas. Sin embargo
se tuvieron que ajustar en base a prueba y error, ya que se necesitaba unos valores muy
concretos que permitieran diferenciar claramente los colores del fondo. Para el propósito
de afinar en los colores HSV se creó un archivo llamado RGB2HSV_converter.py al que
se le pasaba un color en un matriz de tres valores RGB, y te devolvía ese color adaptado a
HSV para OpenCV. Ese pequeño archivo fue agregado con éxito a las librerías oficiales de
OpenCV para Python (Solem 2012), en este caso se usaron las librerias de cv2. Gracias
este pequeño programa creado se pudieron ajustar los valores para cada uno de los objetos
sumergibles sin problemas.
def find_circles_thresholded(blurred):
ball_image = cv.GetSubRect(blurred, (center_X, center_Y, 200, 200))
hsv_image = cv2.cvtColor(ball_image, cv.CV_BGR2HSV)
threshold_image = cv2.inRange(hsv_image, np.array((13., 75., 0.)), np.array((43., 255., 130.)))
Bloque de código fuente 4.24: Otro codigo para aplicar la busqueda de circulos.
En la figura 4.25 se puede ver las imágenes obtenidas correspondientes en primer lugar
al elemento sumergible centrado en una imagen de 200 x 200 pixeles. En segundo lugar
esta imagen en el espacio de color HSV. Y en tercer lugar esta imagen después de aplicarle
umbral para los colores amarillos.
99
4 DISEÑO E IMPLEMENTACIÓN
Figura 4.25: Proceso hasta llegar a aplicar un umbral a la imagen.
Como se puede observar este código es capaz de conseguir una réplica del objeto bastante
fiel al elemento sumergible original, sin embargo no es del todo fiel, por lo que se optó
a hacer una media entre la figura que sale usando la imagen umbralizada y la que sale
usando el algoritmo de Hough para encontrar circunferencias en la imagen. Gracias a
la función findContours() podemos buscar automáticamente los contornos de una imagen
después de aplicar un umbral.
A la función findContours() se le pasara la imagen con el umbral aplicado, el modo
de que se quiere usar para sacar los contornos y el método. Existen varios modos pero
se seleccionó el más general, el que devolvía todos los contornos de la imagen. También
existen varios métodos y se seleccionó el que hacía las operaciones más rápido. En la
figura 4.26 se puede ver una comparación entre aplicar el algoritmo de Hough con la
función HoughCircles(), a la izquierda, y aplicar la función findContours(), a la derecha.
Este ejemplo es uno de los más drásticos que se han visto en todo el proyecto, de hecho,
en la mayoría de los casos los puntos que aparecían coinciden. Sin embargo este ejemplo
resulta de utilidad para explicar cómo la suma de ambos puede corregir deficiencias de
cada uno de ellos.
Figura 4.26: Aplicación de algoritmos para la búsqueda de guras.
100
PROYECTO FIN DE GRADO
Una vez ejecutadas las dos funciones, se recogen los resultados de ambas y se hace media
de los puntos para sacar una circunferencia lo más cerca de la realidad posible. De esta
manera se consigue una reproducción de la circunferencia lo más fiel posible. Para este
propósito se recurrió a la lista de matrices que devuelve la función findContours(). Esta
función devuelve los contornos más grandes en última posición. Como el contorno que se
necesita es precisamente el más grande, solo se mira la última posición de esta lista. A
partir de este contorno se obtiene un nuevo centro y un nuevo radio que se comparará con
el anterior y se determinará una media entre ambos.
def print_new_circle(circle, contours):
max_value_x = 0
min_value_x = 200
for cnt in contours[−1]:
max_value_x = max(cnt[0][0], max_value_x)
min_value_x = min(cnt[0][0], min_value_x)
center_x = (max_value_x + min_value_x) / 2
radius = center_x − min_value_x
real_center_x = (center_x + circle[0]) / 2
real_radius = (radius + circle[2]) / 2
cv2. circle (img, (real_center_x,circle [1]) , real_radius, (0,0,255) , 2)
Bloque de código fuente 4.25: Codigo para generar nuevas imagenes.
Como se puede apreciar en la figura 4.27 la circunferencia dibujada sobre la figura
corregida corresponde exactamente a los bordes del elemento sumergible.
Figura 4.27: Circunferencia corregida.
101
4 DISEÑO E IMPLEMENTACIÓN
Además, se implementó una forma numérica de representar la flotabilidad de los elementos sumergibles sobre las imágenes. De esta forma, dependiendo de la posición de la línea
del agua y del elemento sumergible respecto a ella. De esta forma los usuarios pueden ver
directamente los tantos por ciento bajo el agua y sobre el agua de los elementos sumergibles sin tener que medirlos. En la figura 4.28 se puede ver cómo la imagen misma informa
edl tanto por ciento por encima y por debajo del agua que esta el elemento sumergible,
así como su color y el líquido que contiene. Esta información es totalmente customizable
y solo depende de la información que guardemos en la base de datos.
Figura 4.28: Imagen con texto sobre la posición de los elementos sumergibles.
Una vez se definieron las funciones para buscar la línea, y las circunferencias en la imagen
obtenida se pensó en reducir los tiempos de procesado de estas imágenes. Teniendo en
cuenta que el dispositivo embebido que se usa, la PandaBoard ES, tiene dos núcleos se
probó a ejecutar cada una de estas funciones en cada uno de los núcleos en vez por separado
en vez de dejar que el dispositivo lo gestionará automáticamente. Como se puede observar
en la figura 4.29 los resultados fueron satisfactorias, reduciendo el tiempo en casi 0.005
segundos. Puede parecer que esta mejora en el tiempo es insignificante, sin embargo,
cuando se tienen 400 peticiones seguidas esto representa una mejora de dos segundos.
Figura 4.29: Comparación de tiempos (en segundos) con y sin paralelización.
En el siguiente estado se ejecuta el guardado de las imágenes en disco, así como la generación de una carpeta específica que llevará como nombre un timestamp en formato unix.
Este nombre único de cada carpeta permite diferenciarlas sin problemas y recuperarlas
102
PROYECTO FIN DE GRADO
en un futuro si fuera necesario sabiendo la fecha y hora de conexión. El guardado de las
imágenes en disco representa un tiempo importante, más o menos 0.02 segundos, que es lo
mismo que es más que lo que tardamos en procesar la imagen. Al mismo tiempo, que se
guarda la imagen genera un JSON que contiene las imágenes solicitadas y la ruta a estas.
Este JSON pertenece a un servicio web creado con la idea de que cuando un usuario solicite
una imagen no le llegue directamente sino que esta imagen se guarde con otras utilidades
que podrá usar en el futuro. Realmente no es un solo servicio web, sino que son varios, sin
embargo, estos servicios web siempre devuelven lo mismo, rutas a imágenes y/o archivos
de excel generados en ese momento. Las diferentes URI a las que se puede llamar son
/image, que devolverá solo la imagen real en ese momento. /image_low_processed que
devolverá la imagen real y una imagen donde están marcados los elementos sumergibles y
la línea de agua. /image_medium_processed que devolverá las mismas imágenes que el
método /image_low_processed y además un excel donde se podrá ver el tanto por ciento
que los elementos sumergibles están dentro y fuera del agua. /image_high_processed
que devolverá la imagen real y una imagen con los elementos sumergibles y la línea de
agua marcada, así como el tanto por ciento que los elementos sumergibles están fuera y
dentro del agua directamente escrito sobre la imagen. Y por ultimo /image_virtual que
nos devolverá una representación en 2D de la imagen que vemos y datos como el peso del
elemento sumergible, la densidad, etc. Nótese que todos estos métodos se utilizan para
abarcar un mayor número de tipos de usuarios en nuestro laboratorio remoto. Como todos
los servicios son muy parecidos se va a explicar solo el más común. El servicio más común
consiste en llamar a la URI /image_medium_processed. Este servicio devolverá un JSON
con las rutas a los archivos especificados más arriba.
− Petición:
GET /image_medium_processed/ HTTP/1.1
Host: 192.168.0.155:8000
−Respuesta:
200 OK
Content−Type: application/JSON
{”real_image_[timestamp]”: ”192.168.0.155:8008/tmp/[timestamp].jpg”,
”processed_image”: ”192.168.0.155:8008/tmp/[timestamp]_processed.jpg”,
”excel_data”: ”192.168.0.155:8008/tmp/[timestamp].xls”}
Bloque de código fuente 4.26: URL /image_medium_processed/.
El parametro [timestamp] que aparece en el bloque de código fuente 4.26 es una marca
temporal en formato UNIX que es utilizada para localizar cada una de las imágenes, así
como saber en qué momento fueron solicitadas al servidor y eliminarlas en caso de que
tengan más de dos semanas de antigüedad. Como se puede apreciar en las líneas de arriba,
cuando un usuario solicita una imagen no recibe la imagen directamente, sino llama a un
servicio web que le devuelve la dirección de la imagen. De la devolución de la imagen se
encarga NGINX, que es un servidor web ligero de alto rendimiento. NGINX es software
libre y de código abierto, y permite servir las imágenes de manera mucho más rápida que
si se hiciera directamente desde la aplicación que se ha creado.
103
4 DISEÑO E IMPLEMENTACIÓN
Como este servicio es un servicio crítico, en caso de caerse tiene que volver a estar operativo en el menor tiempo posible. Para conseguir esto se instaló Supervisor. Supervisor
es un sistema cliente - servidor que permite a los usuarios monitorizar y controlar una
serie de procesos en los sistemas operativos tipo UNIX. Además, permite iniciar cualquier
programa en el arranque, por lo que en caso de que la máquina se reinicie el servicio configurado volverá a correr. Además posee una interfaz web que te permite ver y gestionar
estos procesos desde cualquier lugar del mundo.
Figura 4.30: Interfaz web de Supervisor.
104
PROYECTO FIN DE GRADO
5. PLANIFICACIÓN
Todo este proyecto se planificó de acuerdo a un período de trabajo de entre cuatro y
cinco meses, a partir de febrero de 2012, con el inicio de la colaboración del autor en
WebLab-Deusto. En el apartado de la planificación de un proyecto es muy importante
tener en cuenta dos tipos de planificaciones diferentes, pero que se complementan:
• Planificación económica.
• Planificación de tiempos.
5.1 PLANIFICACIÓN ECONÓMICA
Es sabido que un apoyo fundamental en la consecución del éxito a la hora de desarrollar e implantar proyectos de índole eminentemente tecnológica resulta de una cuidadosa
planificación financiera. En este sentido, un análisis de índole tanto cualitativo como
cualitativo, permite determinar qué recursos resultan imprescindibles para el proyecto, así
como determinar cuál es el coste asociado a los mismos. Desarrollar este análisis constituye un pilar básico ya que, sólo cuando se conoce y cuantifica el esfuerzo económico
necesario para desarrollar un proyecto se está en posición de iniciar un análisis centrado en
la viabilidad del negocio en torno a la variable principal de cualquier análisis económico, el
mercado al que pretendemos satisfacer. Por ello, si bien es cierto que podrían ser muchas
y muy distintas las variables a tener en cuenta a la hora de realizar una planificación
económica, la estructura de este apartado se centra en analizar aquellas variables que, con
carácter general, tienen un impacto decisivo a la hora de realizar la puesta en marcha de
un proyecto:
• Planificación de costes y recursos.
• Ingresos y mercado.
5.1.1 Planificación de costes y recursos
La instalación de un laboratorio remoto, y su puesta a disposición a través de una
plataforma digital con capacidad de transmitir en tiempo real imagen y sonido, requiere
de recursos precisos, cada uno categorizado en un estanco particular, y respecto de los
cuales se debe ser capaz de combinar perfectamente entre sí para constituir un sistema
homogéneo capaz de dar la mejor respuesta a los usuarios.
En concreto, a continuación se exponen los recursos necesarios, así como los costes
asociados a los mismos, necesarios para el desarrollo del proyecto:
105
5 PLANIFICACIÓN
• Recursos humanos.
• Recursos hardware.
• Recursos software.
• Material fungible.
• Costes fijos totales y mensuales.
5.1.1.1 Recursos humanos
El proyecto requiere de la dedicación de al menos dos ingenieros. El perfil del primero
de ellos sería informático, con una dedicación estimada de 150 horas, siendo su principal
responsabilidad la realización y desarrollo de la parte de programación de algoritmos, así
como la programación de partes del interfaz web y optimizacion del codigo. Por su parte,
resulta asimismo necesario, y con una presencia y dedicación mayor, esto es de 280 horas,
un ingeniero de telecomunicaciones, cuya labor se centra en el análisis e implementación de
toda la vertiente digital de la plataforma, como es el diseño de los servicios web, el diseño
y modelización de procesado de las imágenes, etc . Adicionalmente, el equipo estaría
completado por un diseñador gráfico con una dedicación estimada de 30 horas, así como
por un electricista y un carpintero con una dedicación de 10 y 8 horas respectivamente,
que asistan en las labores de instalación del acuario.
El subtotal ligado a los costes en el campo de personal asciende a 24.480 euros en
términos globales (dependiendo de las particularidades ligadas a las modalidades de contratación, a estos gastos podrían añadirse los costes de seguridad social, los cuales llegado
el caso serán objeto de un análisis más pormenorizado).
Figura 5.1: Costes asociados a los Recursos humanos.
5.1.1.2 Recursos hardware
Como no podía ser de otro modo considerando la naturaleza del proyecto, los recursos
hardware constituyen asimismo una vertiente fundamental de análisis a la hora de determinar los costes del proyecto. Entre los diversos dispositivos necesarios para la implementación del laboratorio remoto, cabe destacar por su impacto en costes el osciloscopio,
las poleas a medida y el propio acuario. El análisis adjunto incluye la mejor alternativa
106
PROYECTO FIN DE GRADO
en base a calidad-precio para cada uno de estos elementos, así como para el resto de dispositivos necesarios. A este respecto, conviene señalar que la calidad de los elementos
explícitamente señalados (acuario, osciloscopio o poleas), aunque todos los elementos son
importantes, resulta imprescindible a la hora de lograr el mejor rendimiento del laboratorio
remoto.
Figura 5.2: Costes asociados a los Recursos hardware.
5.1.1.3 Recursos software
Con carácter complementario a los recursos hardware señalados anteriormente, resulta
asimismo preciso contar con herramientas software que nos faciliten y aseguren, entre otros
aspectos, la calidad en la interacción del usuario con el laboratorio, aspecto decisivo en la
experiencia del usuario de este tipo de laboratorios. En la medida en que todo el apoyo
software se basa en la utilización de software libre, el coste de utilización resulta neutro y
por lo tanto, estas herramientas no constituyen un mayor coste necesario en la elaboración
de este tipo de laboratorios.
107
5 PLANIFICACIÓN
Figura 5.3: Costes asociados a los Recursos Software.
5.1.1.4 Material fungible
Intrínsecamente ligado a la actividad del laboratorio remoto, es necesario contar con
ejemplares de peces, los cuales lo son de distinta morfología, de este modo resulta sin
duda más atractivo de cara al usuario y en concreto al público al que nos dirigimos (como
por ejemplo, escuelas). El coste total en este caso asciende a 48 euros.
Figura 5.4: Costes asociados al material fungible.
5.1.1.5 Costes fijos totales y mensuales
Una vez determinada la estructura de costes fijos, los cuales ascienden a 29.398 euros (de
acuerdo con la figura adjunta), constituye asimismo objeto de análisis los costes variables
ligados al funcionamiento del laboratorio remoto.
Figura 5.5: Costes jos.
En concreto, para el desarrollo de la actividad sería preciso incurrir en unos costes
mensuales de 340 euros que incluyen la conexión a internet, el servicio de contratación
de backup 3.5G, la contratación de una IP fija y, gastos propios de mantenimiento de la
pecera así como los gastos de luz y agua.
108
PROYECTO FIN DE GRADO
Figura 5.6: Costes jos mensuales.
5.1.2 Ingresos y mercado
El proyecto se encuentra fundamentalmente dirigido hacia dos segmentos de mercado;
el primero de ellos estaría conformado por museos de orientación científico-tecnológica,
mientras que el segundo se centraría en el sector de conformado por los centros de educación. En concreto, en este segundo se estaría haciendo referencia por una parte a los
centros de educación primaria, secundaria y bachiller y por otra, a centros universitarios
de ingenierías superiores y escuelas técnicas superiores.
Determinado, lo que en marketing se define como “target market”, resulta preciso
analizar las siguientes cuestiones:
• Tamaño del sector y porcentaje de penetración.
• Estructura de obtención de recursos.
5.1.2.1 Tamaño del sector y porcentaje de penetración
Pese a que no existe un censo oficial en Europa que recoja el número total de museos
en Europa, se estima que la oferta de los mismos sólo en España es superior a 1.000
centros (Ministerio Estatal de Educación Cultura y Deporte 2012a). De la oferta total,
aproximadamente la mitad de ellos albergan con habitualidad exposiciones de contenido
científico-tecnológico, con lo que el tamaño de este sector sería de 500 museos solo a nivel
nacional.
Por su parte, en lo referente a centros educativos (enseñanza básica y superior), a
nivel nacional existen censados 210 centros de enseñanza superior (universitaria y técnica)
(Instituto Nacional de Estadística 2012) y 7.401 centros de impartición de enseñanza secundaria obligatoria (Ministerio Estatal de Educación Cultura y Deporte 2012b). Estimando
un porcentaje de penetración en cada uno de estos sectores del 1% para museos, 0,8%
para centros de educación obligatoria y 4,8% para universidades, se estaría atendiendo a
un total de 5 museos, 60 colegios y 10 universidades:
Es imprescindible señalar que estos datos están analizados a nivel nacional de manera que
el tratamiento de las cifras sea más manejable. No obstante, el proyecto es un programa
con un desarrollo a nivel europeo y de divulgación telemática por lo que la extensión del
mismo es con casi toda seguridad bastante mayor.
109
5 PLANIFICACIÓN
Figura 5.7: Porcentaje de penetración.
5.1.2.2 Estructura de obtención de recursos
La obtención de recursos económicos se centra en establecer un peaje por horas de acceso
a la plataforma. De este modo el precio por hora de acceso en el caso de museos asciende
a 12 euros mientras que en el caso de centros de educación el precio es de 10 euros la hora.
En el caso de museos, la demanda de horas al mes sufrirá variaciones en función del
número y duración de la exposición en aquellos museos con alternancia de exposiciones, si
bien, en aquellos dedicados íntegramente a la exposición de contenido científico-tecnológico
es previsible que demanden estos servicios con carácter permanente.
Por su parte, en el caso de centros de educación, debe advertirse que es predecible que
ciertos centros concierten estos servicios a lo largo de un trimestre/semestre al año. Para
realizar la estimación de ingresos, se ha fijado un porcentaje de penetración tal que entiende
que alternadamente la media de universidades que al mes demandarían los servicios seria
de 60 colegios y 10 universidades, si bien la demanda en ese segmento no sería homogénea
a lo largo del año. En concreto, la estimación realizada se recoge en la siguiente figura:
Figura 5.8: Estimación de penetración en el mercado.
Determinando un total de 12 meses para el caso de museos y, 10 meses lectivos en el
caso de centros educativos, el importe de ingresos anuales estimados es de 70.400 euros.
Figura 5.9: Estimación de ingresos anuales.
110
PROYECTO FIN DE GRADO
Ligando la estimación de ventas con la de costes y, asumiendo un incremento de ingresos
el primer año de un 5%, el segundo de un 3% y los sucesivos de un 1%, así como el
incremento correlativo de costes, el diagrama de flujos para el horizonte temporal de 5
años sería el siguiente:
Figura 5.10: Diagrama de ujos.
Determinado cuál sería el flujo de retorno económico de la inversión realizada, no conviene por otra parte desatender el papel fundamental que, en este caso, desempeña la
vertiente social del proyecto. Como suele ser habitual en estos casos, resulta complicado
trasladar a magnitudes monetarias el beneficio social de proyectos que no son estrictamente
diseñados desde el único prisma de la obtención de beneficios económicos en el mercado
al que estamos acostumbrados.
El proyecto GO-Lab, “learning from the experience” tal y como se ha descrito previamente, se configura como un proyecto europeo de trascendental calado en el desarrollo
del mundo de la educación e investigación. Desde esta perspectiva, se pretende adaptar la oferta de este tipo de servicios, fundamentales en el desarrollo social, al desarrollo
tecnológico e innovación de nuestros tiempos.
Con todo, estamos ante un proyecto que visiblemente se muestra como
rentable desde la doble perspectiva económico-social.
5.2 PLANIFICACIÓN DE TIEMPOS
Figura 5.11: Diagrama de tareas primarias para la consecucion de este proyecto.
El lector podra encontrar una explicacion mas detallada de tareas y tiempos en el Anexo
A.
111
PROYECTO FIN DE GRADO
6. CONCLUSIONES Y TRABAJO FUTURO
El resultado del proceso de trabajo de este proyecto ha desembocado en la generación
de los modulos software, hardware y documentación necesarios para el cumplimiento de
los requisitos del proyecto GO-Lab. Sin embargo, como parte de la continua investigación
en laboratorios remotos aplicados a la educación queda mucho que mejorar todavía. Estas secciones siguientes pretenden ofrecer una visión general de los objetivos que se han
logrado, y el trabajo futuro de investigación y desarrollo que queda por hacer.
6.1 RESULTADOS DEL PROYECTO
Repasando los objetivos técnicos, sociales y económicos del proyecto, tal como se describe
en la sección 1.1, se podría decir que la realización del proyecto ha cumplido con las
expectativas de manera exitosa. De hecho, se ha implementado un laboratorio remoto para
la experimentación con el principio de Arquímedes basado en una arquitectura asíncrona
distribuida. El experimento permite a los usuarios controlar los objetos sumergibles del
acuario, dar de comer a los peces, y lo más importante: experimentar con los conceptos
asociados al principio de Arquímedes. Para la consecucion de estos objetivos el desarrollo
del proyecto ha incluido ciertos modulo que pueden ser reutilizados en el futuro desarrollo
de nuevos laboratorios remotos:
• Una arquitectura de comunicaciones entre los diferentes subsistemas de un laboratorio remoto adaptable a las nuevas exigencias de los dispositivos embebidos.
• Un cliente web sencillo y reutilizable que permite la comunicación entre el laboratorio
y los usuarios.
Todo esto se ha desarrollado manteniendo la compatibilidad con la API WebLab-Deusto,
teniendo en cuenta que la integración dentro de este marco era una de las metas del
proyecto.
El diseño del laboratorio, así como la arquitectura asociada, se han mantenido simples
utilizando dispositivos hardware que facilitan el desarrollo y que por lo general han sido
validados en el laboratorio en experimentos anteriores. El proyecto también ha tratado de
hacer uso de las tecnologías apropiadas y únicamente de los recursos de software necesarios.
El proyecto en sí ha sido considerablemente multidisciplinar, ya que abarca aspectos
tales como las tecnologías de las comunicaciones, electrónica, diseño de PCB, mecatrónica,
diseño de software, programación, tecnologías web y desarrollo web. Por otra parte, no se
ha limitado al ámbito de la ingeniería, dado que el autor también ha llevado a cabo un
trabajo relacionado con la preparación de documentos, el diseño de interfaces de usuario
que mejoren la experiencia del usuario, etc.
113
6 CONCLUSIONES Y TRABAJO FUTURO
6.2 TRABAJO FUTURO
Una vez que la estructura básica y la funcionalidad del experimento se han definido e
implementado, se ha establecido la base para la mejora y la investigación futura de un
laboratorio remoto para la experimentación de los conceptos del principio de Arquímedes
basado en una arquitectura asíncrona distribuida. Los siguientes pasos de este proyecto se
refieren a la ampliación de su funcionalidad, mejoras generales en la usabilidad, y su uso
como punto de partida para la investigación pedagógica a mayor escala. En este sentido,
el futuro trabajo más relevante se puede clasificar en cuatro áreas:
• Integración completa del laboratorio en el entorno Graasp
• Integración completa del laboratorio no gestionado en WebLab-Deusto
• Mejoras en la interfaz gráfica de usuario
• Mejoras en el sistema de izado y arriado de elementos sumergibles
• Diseño de una nueva versión del laboratorio
Cabe señalar que todas estas tareas persiguen los propósitos principales de aumentar
la facilidad de uso y capacidad de aprendizaje desde la perspectiva del usuario, así como
llegar a ofrecer un cantidad mayor de posibilidades educacionales.
6.2.1 Integración completa del laboratorio en el entorno Graasp
Sobrepasando los objetivos del presente proyecto, el experimento desarrollado durante
el mismo ha sido integrado en el entorno no formal de aprendizaje colaborativo Graasp,
desarrollado por la EFPL (en frances École Polytechnique Fédérale de Lausanne). Para
llevar a cabo esta integraciónn todos los objetos individuales incluidos en el laboratorio han
sido dispuestos al usuario de forma independiente, mediante widgets, permitiendo adecuar
la interfaz de usuario a las necesidades de cada experimento individual. Este trabajo ha
sido desarrollado por el Doctor Pablo Orduña dentro de su aportación al proyecto GO-Lab.
Se puede observar la interfaz de usuario del laboratorio funcionando en el entorno no
formal Graasp en la figura 6.1. Se aprecia como todos y cada uno de los componentes del
laboratorio son representados mediante widgets.
6.2.2 Integración completa del laboratorio no gestionado en WebLab-Deusto
Dentro de este proyecto se ha desarrollado un cliente, así como un pequeño servidor
para los laboratorios no gestionados, implementados y probados siguiendo los requisitos
de la API WebLab-Deusto. En el caso del laboratorio no gestionado, el experimento no ha
sido desplegado en Internet como parte totalmente funcional de WebLab-Deusto. Durante
todas las pruebas se mantuvo ejecutando el servidor de la aplicación en un equipo local,
implemetado sobre la plataforma PandaBoard ES. En este punto hay que recalcar que este
experimento se desplegó con éxito para laboratorios gestionados.
114
PROYECTO FIN DE GRADO
Figura 6.1: Interfaz de usuario del laboratorio en Graasp.
El trabajo futuro en esta área se dedicará a una implementación completa del laboratorio dentro de WebLab-Deusto (https://www.weblab.deusto.es/). En este marco, el
experimento se pretende implementar como un laboratorio gestionado, beneficiándose así
de una serie de ventajas como son:
• No hay necesidad para el desarrollador del experimento de gestionar las comunicaciones, ya que estas son gestionadas directamente desde la API. Ademas, todo esta
información viaja desde el servidor de forma segura bajo SSL. A pesar de esto, todos
los comandos son HTTP puro, para que puedan atravesar los firewalls y servidores
proxy.
• Toda la información de la interacción entre el experimento y el usuario se almacena
en una base de datos. Esto es útil para los profesores y pedagogos a la hora de
estudiar el uso de los experimentos y los comandos enviados al laboratorio por los
alumnos y modelizar el mismo.
• Existe un balanceo de carga local, de modo que, en el caso de que existen múltiples
copias del mismo laboratorio, el servidor WebLab-Deusto gestiona internamente los
mensajes enviados por el cliente y los envía a la copia adecuada del laboratorio en
cada momento. La autenticación de los usuarios se realiza automáticamente desde
el servidor WebLab-Deusto.
• Todas la colas son gestionadas internamente por WebLab-Deusto.
115
6 CONCLUSIONES Y TRABAJO FUTURO
• Es posible la compartición de laboratorios entre las diferentes instituciones gracias
a la federación.
El grado de trabajo requerido para incorporar adecuadamente estas mejoras en el experimento actual no es muy grande, por lo que espera que esto se complete en las semanas
siguientes a la publicación de este documento.
6.2.3 Mejoras en la interfaz gráfica de usuario
La actual interfaz gráfica de usuario desarrollada como parte del cliente experimental es
funcional y ofrece acceso a los principales controles necesarios para gestionar y controlar el
laboratorio. Sin embargo, podría beneficiarse de algunas mejoras desde el punto de vista
del diseño, ya que actualmente no es lo bastante intuitiva.
Un aspecto del que actualmente carece es el desarrollo de un mecanismo apropiado para
mostrar las diferentes opciones que existen a la hora de procesar la imagen, así como una
descripción detallada de este proceso. En un primer momento también se pensó en proveer
de un sistema de recompensas que fomente la participación de los usuarios, así como su
integración en un Serious Game. Las diferentes propuestas incluyen una representación
gráfica interactiva de Arquímedes en un estado de angustia, que vaya desapareciendo a
medida que los usuarios adivinen el líquido que contiene los elementos sumergibles.
Por último, sería interesante desde el punto de vista del usuario pintar en cada una de
las imágenes que obtiene una regla que sea capaz de medir hasta milímetros para comparar
las distancias de los elementos sumergibles respecto de la línea de agua, o incluso respecto
del fondo.
6.2.4 Mejoras en el sistema de izado y arriado de elementos sumergibles
Un aspecto del que actualmente carece el experimento es el desarrollo de un mecanismo
apropiado para el intercambio rápido entre diferentes objetos sumergibles que puedan ser
utilizados. Existen algunas propuestas que intentan solucionar el problemas desde el punto
de vista del software que incluyen una representación gráfica interactiva de cada uno de
los objetos sumergibles que puedan ser movidas desde la interfaz gráfica. Desde el punto
de vista del hardware se plantea una pequeña grúa dirigible que deje caer y recoja estos
objetos sumergibles.
Otro aspecto planeada es incluir elementos sumergibles de formas diferentes, e incluso
líquidos diferentes donde dejar caer estos elementos. El hecho de incluir formas diferentes
podría funcionar mediante la preparación anterior de estos elementos en función de reservas. Los líquidos diferentes donde dejar caer los líquidos se podría solucionar teniendo
varios acuarios más pequeños.
116
PROYECTO FIN DE GRADO
6.2.5 Diseño de una nueva versión del laboratorio
Pese a que el laboratorio remoto desarrollado en este proyecto cumple todos los requisitos demandados y se ajusta perfectamente al diseño llevado a cabo durante la definición
del mismo (Anexo B), existen ciertas modificaciones recomendables. Como parte de la
etapa preliminar del proyecto Go-Lab, se han desarrollado una serie de presentaciones
(Visionary Workshops) de los diferentes laboratorios remotos incluidos en dicho proyecto,
incluyendo el Aqualab, a una representación de profesores de secundaria voluntarios que
han participado en una encuesta de satisfacción. Las principales conclusiones resultantes
de dichos workshops son las siguientes:
• Más allá de la fuerza de flotación y densidad, analizadas en la versión actual del
Aqualab, existen otras variables importantes que deberían ser analizadas: Volumen,
peso y flotabilidad.
• Las medidas principalmente demandadas por la comunidad de usuarios son Masa/Peso
de los objetos, desplazamiento resultante del agua e imágenes. La mayor parte de
los profesores encuestados asigna un peso considerable a los procesos de realidad
aumentada sobre los objetos sumergidos.
• Es preferible centrar el AquaLab en una aplicación real del principio de Arquímedes
o en una situación real en lugar de propiciar el descubrimiento del principio mediante
experimentos pequeños.
• El 70% de los profesores encuestados apoya el uso del bloc de hipótesis y las imágenes
procesadas y rechaza el empleo del mapa conceptual.
En base a estas conclusiones se han propuesto dos enfoques diferentes para la implementación de un nuevo laboratorio remoto que se acerque a lo demandado por la comunidad educativa:
• Implementar un acuario más grande y rediseñar la mecánica del experimento para
incluir un número superior de objetos sumergibles.
• Diseñar experimentos individuales para cada objeto. Cada experimento individual
consistirá en:
– Un tubo de ensayo pequeño, con una escala de medición, y un objeto llenado
con un determinado líquido.
– Un sistema mecatrónico para el control de los objetos: motor, driver, la polea,
la mecánica y la Raspberry Pi.
– Una cámara web y un sistema de iluminación.
– Un dinamómetro.
– Una caja para aislar el experimento.
117
6 CONCLUSIONES Y TRABAJO FUTURO
Con el segundo enfoque, el usuario será capaz de medir el desplazamiento de agua, el
peso y la flotabilidad. También se pueden tomar fotografías. El líquido en cada tubo
de ensayo se puede cambiar, pudiendo ser alterado periódicamente. Permite tener un
conjunto de objetos (más que el número de experimentos) y en función de la clase o el
escenario de aprendizaje que se pueden modificar.
Este enfoque está en consonancia con el WordPackage técnico del proyecto Go-Lab,
facilitando su integración en Graasp porque cada experimento puede ser fácilmente widgetizado. Elementos simples de realidad aumentada pueden ser agregados como una escala
o regla de medición.
118
PROYECTO FIN DE GRADO
AGRADECIMIENTOS
Después de escribir mas de cien páginas, uno empieza a sentir un ligero dolor de cabeza
y un cosquilleo en los pies cada vez que las vuelve a repasar. Sin embargo, es reconfortante
expresar mis agradecimientos en esta página a:
• Ignacio Angulo: Por dirigir este proyecto y por su inestimable ayuda incluso los
fines de semana. Por estar detras mio cada vez que me abstraia y por comerse mis
M&M’s cada vez que los veía.
• Javier García Zubia: Por saber dar buenos consejos y dirigir el proyecto GO-Lab.
Por las canciones y frases tan buenas que me ha pegado durante estos meses.
• Olga Dziabenko: Por toda la ayuda con las partes pedagógicas y su paciencia.
• Iñigo Iturrate: Por su ayuda con el desarrollo del hardware y por sus galletas
Principe todas las tardes a las 18:00.
• Pablo Orduña: Por ser el Lord del WebLab y ayudarnos a los meros mortales con
todas las cosas relacionadas con el software.
• Rubén del Río: Por llenarme la cabeza de antenas.
• Luis Rodríguez: Por su ayuda con la plantilla de LATEX.
• Iker de Echaniz: Por ser un modelo a seguir y por sus interminables conversaciones
sobre temas tan interesantes como los fallos de seguridad que tienen algunos sistemas
electrónicos en producción.
• Andoni Renart: Por aportar sus conocimientos en RTOS aunque no hayan servido
de mucho...
• Pedro Manuel Sasia: Por ayudar con los aspectos relacionados con la ética del
proyecto, algo tan necesario en estos tiempos.
• Mi novia, Nerea: Por aportar sus amplios conocimientos en este proyecto.
• Mis padres: Por estar ahí siempre, ser capaces de aguantarme durante estos largos
años y aún no haberme echado de casa.
• Todos los demás: Incluyendo profesores, amigos y compañeros. Porque no se
pueden incluir todos los nombres por escrito, pero sigo agradeciéndoos el estar ahí.
119
PROYECTO FIN DE GRADO
REFERENCIAS
Alonso, G., Casati, F., Kuno, H. & Machiraju, V. (2004), Web services, Springer.
Amer, P. D., Iren, S., Sezen, G. E., Conrad, P. T., Taube, M. & Caro, A. (1999),
‘Network-conscious gif image transmission over the internet’, Computer Networks
31(7), 693–708.
Arduino (2013a), ‘Arduino Language Reference’. [Online; accessed 2013-05-17].
URL: http://arduino.cc/en/Reference/HomePage
Arduino (2013b), ‘Arduino UNO Product Page’. [Online; accessed 2013-05-17].
URL: http://arduino.cc/en/Main/ArduinoBoardUno
Athitsos, V., Swain, M. J. & Frankel, C. (1997), Distinguishing photographs and graphics
on the world wide web, in ‘Content-Based Access of Image and Video Libraries, 1997.
Proceedings. IEEE Workshop on’, IEEE, pp. 10–17.
Bergmann, N. W., Wallace, M. & Calia, E. (2010), Low cost prototyping system for
sensor networks, in ‘Intelligent Sensors, Sensor Networks and Information Processing
(ISSNIP), 2010 Sixth International Conference on’, IEEE, pp. 19–24.
Bradski, G. & Kaehler, A. (2008), Learning OpenCV: Computer vision with the OpenCV
library, O’reilly.
Brosnan, T. & Sun, D.-W. (2004), ‘Improving quality inspection of food products by
computer vision—-a review’, Journal of Food Engineering 61(1), 3–16.
Canny, J. (1986), ‘A computational approach to edge detection’, Pattern Analysis and
Machine Intelligence, IEEE Transactions on (6), 679–698.
Crockford, D. (2006), ‘The application/json media type for javascript object notation
(json)’.
Django Project (2013), ‘Django Web Framework Documentation’. [Online; accessed 201307-01].
URL: https://docs.djangoproject.com/en/1.5/
Eric Ptak (2013), ‘WebIOPi Raspberry Pi Internet of Things framework’. [Online; accessed
2013-07-01].
URL: http://code.google.com/p/webiopi/
Forcier, J., Bissex, P. & Chun, W. (2008), Python web development with Django, AddisonWesley Professional.
121
Referencias
FriendFeed (2013), ‘Tornado Web Framework’. [Online; accessed 2013-07-01].
URL: http://www.tornadoweb.org/en/stable/
Garcia-Zubia, J., Angulo, I., Hernandez, U., Castro, M., Sancristobal, E., Orduña, P.,
Irurzun, J. & de Garibay, J. (2010), Easily integrable platform for the deployment
of a remote laboratory for microcontrollers, in ‘Education Engineering (EDUCON),
2010 IEEE’, IEEE, pp. 327–334.
Garcia-Zubia, J., Orduña, P., Angulo, I., Irurzun, J. & Hernández, U. (2008), ‘Towards
a distributed architecture for remote laboratories’, International Journal of Online
Engineering (iJOE) 4, 11–14.
Gonzalez, R. C. & Woods, Richard, E. (2002), Digital image processing, Prentice Hall
Press.
Gowtham, P. (2011), ‘An interactive hand gesture recognition system on the beagle
board’, International Proceedings of Computer Science and Information Technology
20, 113–118.
Harward, V. J., Del Alamo, J. A., Lerman, S. R., Bailey, P. H., Carpenter, J., DeLong,
K., Felknor, C., Hardison, J., Harrison, B., Jabbour, I. et al. (2008), ‘The ilab shared
architecture: A web services infrastructure to build communities of internet accessible
laboratories’, Proceedings of the IEEE 96(6), 931–950.
Hertel, G., Niedner, S. & Herrmann, S. (2003), ‘Motivation of software developers in open
source projects: an internet-based survey of contributors to the linux kernel’, Research
policy 32(7), 1159–1177.
Hodges, S., Taylor, S., Villar, N., Scott, J. & Helmes, J. (2013), Exploring physical prototyping techniques for functional devices using. net gadgeteer, in ‘Proceedings of the
7th International Conference on Tangible, Embedded and Embodied Interaction’,
ACM, pp. 271–274.
Instituto Nacional de Estadística (2012), ‘Instituto Nacional de Estadística’. [Online;
accessed 2013-07-01].
URL: http://www.ine.es/jaxi/menu.do?type=pcaxis&path=/t13/p405&file=
inebase&L=0
Instruments, T. (2012), ‘Pandaboard’, OMAP4430 SoC dev. board, revision A 2.
Jimenez, A., Ceres, R., Pons, J. et al. (2000), ‘A survey of computer vision methods for
locating fruit on trees’, Transactions of the ASAE-American Society of Agricultural
Engineers 43(6), 1911–1920.
Kenjĺo, T. & Sugawara, A. (1984), Stepping motors and their microprocessor controls,
Clarendon Press (Oxford and New York).
Kepski, M. & Kwolek, B. (2012), Fall detection on embedded platform using kinect and
wireless accelerometer, in ‘Computers Helping People with Special Needs’, Springer,
pp. 407–414.
122
PROYECTO FIN DE GRADO
Laganière, R. (2011), OpenCV 2 computer vision application programming cookbook, Packt
Publishing.
Lee, H.-C., Breneman, E. J. & Schulte, C. P. (1990), ‘Modeling light reflection for computer color vision’, Pattern Analysis and Machine Intelligence, IEEE Transactions
on 12(4), 402–409.
Li, D., Babcock, J. & Parkhurst, D. J. (2006), openeyes: a low-cost head-mounted eyetracking solution, in ‘Proceedings of the 2006 symposium on Eye tracking research &
applications’, ACM, pp. 95–100.
Lowe, D., Murray, S., Weber, L., de la Villefromoy, M., Johnston, A., Lindsay, E.,
Nageswaran, W. & Nafalski, A. (2009), ‘Labshare: Towards a national approach
to laboratory sharing’, AAEE 2009 .
Ma, J. & Nickerson, J. V. (2006), ‘Hands-on, simulated, and remote laboratories: A
comparative literature review’, ACM Computing Surveys (CSUR) 38(3), 7.
Martelli, A., Ravenscroft, A. & Ascher, D. (2008), Python cookbook, O’Reilly.
Matas, J., Galambos, C. & Kittler, J. (2000), ‘Robust detection of lines using the progressive probabilistic hough transform’, Computer Vision and Image Understanding
78(1), 119–137.
Miano, J. (1999), Compressed Image File Formats: JPEG, PNG, GIF, XBM, BMP, Your
Guide to Graphics Files on the Web, Addison-Wesley Professional.
Ministerio Estatal de Educación Cultura y Deporte (2012a), ‘Día Internacional de los
Museos. 2013’. [Online; accessed 2013-07-01].
URL:
http://www.ite.educacion.es/es/inicio/noticias-de-interes/
1012-18-de-mayo-dia-internacional-de-los-museos-2013
Ministerio Estatal de Educación Cultura y Deporte (2012b), ‘Registro Estatal de Centros
Docentes no Universitarios’. [Online; accessed 2013-07-01].
URL: https://www.educacion.gob.es/centros/home.do
Miu, D. K. (1993), ‘Mechatronics-electromechanics and contromechanics’, NASA STI/Recon Technical Report A 93, 20853.
Muros-Cobos, J. L. & Holgado-Terriza, J. A. (2012), ‘Rvlab: A server-side framework to
build remote and virtual laboratories’, Remote Engineering and Virtual Instrumentation .
Pennebaker, W. B. (1992), JPEG: Still image data compression standard, Springer.
Pi, R. & An, A. (2012), ‘Gnu/linux box for $25’, Take a byte .
Python Software Foundation (2013), ‘Python v2.7.5 documentation’. [Online; accessed
2013-05-17].
URL: http://docs.python.org/2/
123
Referencias
Roelofs, G. & Koman, R. (1999), PNG: The Definitive Guide, O’Reilly & Associates, Inc.
Shi, J. & Tomasi, C. (1994), Good features to track, in ‘Computer Vision and Pattern
Recognition, 1994. Proceedings CVPR’94., 1994 IEEE Computer Society Conference
on’, IEEE, pp. 593–600.
Solem, J. E. (2012), Programming Computer Vision with Python: Tools and algorithms
for analyzing images, O’Reilly.
Szeliski, R. (2011), Computer vision: algorithms and applications, Springer.
Tian-ran, W. & Dao-kui, Q. (2002), ‘Open system architecture for control system for
industrial robot [j]’, Robot 3, 013.
Torralba, A., Murphy, K. P., Freeman, W. T. & Rubin, M. A. (2003), Context-based vision
system for place and object recognition, in ‘Computer Vision, 2003. Proceedings.
Ninth IEEE International Conference on’, IEEE, pp. 273–280.
Trapp, B. (2013), ‘Raspberry pi: the perfect home server’, Linux Journal 2013(229), 1.
Twitter, Inc. (2013), ‘Twitter Bootstrap Homepage’. [Online; accessed 2013-05-17].
URL: http://twitter.github.io/bootstrap/
Upton, E. & Halfacree, G. (2012), Raspberry Pi User Guide, John Wiley & Sons.
Van de Straete, H. J., Degezelle, P., De Schutter, J. & Belmans, R. J. (1998), ‘Servo
motor selection criterion for mechatronic applications’, Mechatronics, IEEE/ASME
Transactions on 3(1), 43–50.
Vazquez, J. I., Almeida, A., Doamo, I., Laiseca, X. & Orduña, P. (2009), Flexeo: an
architecture for integrating wireless sensor networks into the internet of things, in
‘3rd Symposium of Ubiquitous Computing and Ambient Intelligence 2008’, Springer,
pp. 219–228.
WebLab-Deusto (2005 onwards), ‘WebLab-Deusto Documentation’.
2013-05-17].
URL: https://weblabdeusto.readthedocs.org/en/latest/
[Online; accessed
Wilde, E. (2007), ‘Putting things to rest’.
Yeung, K. & Huang, J. (2003), ‘Development of a remote-access laboratory: a dc motor
control experiment’, Computers in Industry 52(3), 305–311.
Yodaiken, V. & Barabanov, M. (1997), Real-time linux applications and design, in
‘Proceedings of the Linux applications development and deployment conference
(USELINUX)’.
Yuen, H., Princen, J., Illingworth, J. & Kittler, J. (1990), ‘Comparative study of hough
transform methods for circle finding’, Image and Vision Computing 8(1), 71–77.
124
PROYECTO FIN DE GRADO
ANEXOS
A TAREAS Y DIAGRAMAS DE GANTT
125
14
12
13
Finish
Predecessors
Inactive Task
Inactive Milestone
Inactive Summary
Manual Task
Duration-only
Milestone
Summary
Project Summary
External Tasks
Page 1
External Milestone
Wed 20/02/13Fri 22/02/13
Wed 20/02/13Thu 21/02/13
Wed 20/02/13Thu 21/02/13
Wed 20/02/13Tue 26/02/13
Wed
Tue 26/02/13
20/02/13
Wed 20/02/13Tue 26/02/13
Wed
Tue 26/02/13
20/02/13
Wed
Tue 23/04/13 4
27/02/13
Wed
Tue 26/02/13 1
20/02/13
Wed 20/02/13Tue 26/02/13
Wed
Tue 26/02/13
20/02/13
Fri 15/02/13 Tue 19/02/13 2
Fri 01/02/13 Tue 19/02/13
Fri 01/02/13 Thu 14/02/13
Start
Split
40 days
5 days
5 days
3 days
2 days
2 days
5 days
5 days
5 days
5 days
5 days
3 days
13 days
10 days
Duration
Task
Motores
Sistemas de poleas
Cámaras WiFi
Análisis de software
Framework del
servidor
Interfaz del cliente
Sistema de visión
artificial
Desarrollo e
Implementación
7
8
9
10
11
5
6
4
3
Definición del proyecto
Pruebas de concepto y
encuestas a agentes de
influencia
Documento de
requisitos y objetivos
Estudio de alternativas
tecnológicas
Análisis de hardware
Sistemas basados en
microcontroladores
Task Name
1
2
Task
Mode
Project: Planificacion_Aqualab
Date: Sun 30/06/13
ID
T
F
S
S
Progress
Deadline
Finish-only
Start-only
Manual Summary
Manual Summary Rollup
Resource Names
'13
04 Feb '13
M T W
T
F
S
S
Inactive Milestone
Inactive Summary
Manual Task
Duration-only
Milestone
Summary
Project Summary
External Tasks
Page 2
Inactive Task
Tue 11/06/13 Tue 11/06/13 20
Tue 11/06/13 Tue 11/06/13 25
24
22
23
21
14
15;16;17;18
Predecessors
External Milestone
0 days
0 days
2 wks
1 wk
1 wk
Tue 19/03/13
Finish
Wed
Tue 19/03/13
27/02/13
Wed
Tue 19/03/13
27/02/13
Wed
Tue 19/03/13
27/02/13
Wed
Tue 23/04/13
20/03/13
Wed 24/04/13Tue 11/06/13
Wed 24/04/13Tue 30/04/13
Wed
Tue 14/05/13
01/05/13
Wed 15/05/13Tue 21/05/13
Wed
Tue 28/05/13
22/05/13
Wed
Tue 11/06/13
29/05/13
Wed
27/02/13
Start
Split
Versión final del
laboratorio remoto
27
26
25
23
24
35 days
1 wk
2 wks
5 wks
3 wks
3 wks
3 wks
3 wks
Duration
Task
Pruebas y Debugeo
Pruebas internas
Primera fase de
debugeo
Pruebas externas
Seguna fase de
debugeo
Rediseño de
componentes del
sistema
Validación del sistema
20
21
22
19
18
17
16
Subsistema de
manipulación y gestión
remota
RLMS en plataforma
embebida
Interfaz gráfica de
usuario
Algoritmo de visión
artificial
Integración del sistema
Task Name
15
Task
Mode
Project: Planificacion_Aqualab
Date: Sun 30/06/13
ID
T
F
S
S
Progress
Deadline
Finish-only
Start-only
Manual Summary
Manual Summary Rollup
Resource Names
'13
04 Feb '13
M T W
T
F
S
S
11 Feb '13
M T W
T
F
S
Project: Planificacion_Aqualab
Date: Sun 30/06/13
S
S
Duration-only
Page 3
Manual Task
04 Mar '13
M T W
External Tasks
S
Project Summary
S
Inactive Summary
F
Summary
T
Inactive Milestone
25 Feb '13
M T W
Milestone
S
Inactive Task
S
External Milestone
F
Split
T
Task
18 Feb '13
M T W
T
F
S
S
T
F
S
Progress
Deadline
Finish-only
Start-only
Manual Summary
Manual Summary Rollup
11 Mar '13
M T W
S
18 Mar '13
M T W
T
F
S
S
11 Feb '13
M T W
T
F
S
Project: Planificacion_Aqualab
Date: Sun 30/06/13
S
S
Duration-only
Page 4
Manual Task
04 Mar '13
M T W
External Tasks
S
Project Summary
S
Inactive Summary
F
Summary
T
Inactive Milestone
25 Feb '13
M T W
Milestone
S
Inactive Task
S
External Milestone
F
Split
T
Task
18 Feb '13
M T W
T
F
S
S
T
F
S
Progress
Deadline
Finish-only
Start-only
Manual Summary
Manual Summary Rollup
11 Mar '13
M T W
S
18 Mar '13
M T W
T
F
S
S
25 Mar '13
M T W
T
F
S
Project: Planificacion_Aqualab
Date: Sun 30/06/13
S
S
Duration-only
Page 5
Manual Task
15 Apr '13
M T W
External Tasks
S
Project Summary
S
Inactive Summary
F
Summary
T
Inactive Milestone
08 Apr '13
M T W
Milestone
S
Inactive Task
S
External Milestone
F
Split
T
Task
01 Apr '13
M T W
T
F
S
S
T
F
S
Progress
Deadline
Finish-only
Start-only
Manual Summary
Manual Summary Rollup
22 Apr '13
M T W
S
29 Apr '13
M T W
T
F
S
S
25 Mar '13
M T W
T
F
S
Project: Planificacion_Aqualab
Date: Sun 30/06/13
S
S
Duration-only
Page 6
Manual Task
15 Apr '13
M T W
External Tasks
S
Project Summary
S
Inactive Summary
F
Summary
T
Inactive Milestone
08 Apr '13
M T W
Milestone
S
Inactive Task
S
External Milestone
F
Split
T
Task
01 Apr '13
M T W
T
F
S
S
T
F
S
Progress
Deadline
Finish-only
Start-only
Manual Summary
Manual Summary Rollup
22 Apr '13
M T W
S
29 Apr '13
M T W
T
F
S
S
06 May '13
M T W
T
F
S
Project: Planificacion_Aqualab
Date: Sun 30/06/13
S
S
Duration-only
Page 8
Manual Task
27 May '13
M T W
External Tasks
S
Project Summary
S
Inactive Summary
F
Summary
T
Inactive Milestone
20 May '13
M T W
Milestone
S
Inactive Task
S
External Milestone
F
Split
T
Task
13 May '13
M T W
T
F
S
S
T
F
S
Progress
Deadline
Finish-only
Start-only
Manual Summary
Manual Summary Rollup
03 Jun '13
M T W
S
T
11/06
11/06
10 Jun '13
M T W
F
S
S
PROYECTO FIN DE GRADO
B MOCKUPS DEL PROYECTO GO-LAB
133