Tele Me Tria

Proyecto Fin de Carrera

Ingeniería de Telecomunicación
Formato
Diseñodede
Publicación
un sistemade
delatelemetría
Escuela Técnica
para un
Superior de Ingeniería
monoplaza de Formula Student
Autor:Autor: Daniel
F. Javier Gómez
Payán Sanz
Somet
Tutor:Tutor:
Juan Alejandro Carballar
José Murillo FuentesRincón
Dep.Departamento de Ingeniería
Teoría de la Señal Electrónica
y Comunicaciones
Escuela
Escuela Técnica
Técnica Superior
Superior de Ingeniería
de Ingeniería
Universidad
Universidad de Sevilla
de Sevilla
Sevilla, 2015
Sevilla, 2013
Diseño de un sistema de telemetría para un

monoplaza de Formula Student
Autor:
Daniel Gómez Sanz
Tutor:
Alejandro Carballar Rincón
Profesor Titular
Departamento de Ingeniería Electrónica

Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2015
Proyecto Fin de Carrera: Diseño de un sistema de telemetría para un monoplaza de Formula Stu-
dent
Autor: Daniel Gómez Sanz

Tutor: Alejandro Carballar Rincón
El tribunal nombrado para juzgar el trabajo arriba indicado, compuesto por los siguientes profesores:
Presidente:
Vocal/es:
Secretario:
acuerdan otorgarle la calificación de:
El Secretario del Tribunal
Fecha:
Agradecimientos
F ue hace ya algún tiempo cuando embarqué en esta aventura universitaria, dispuesto a continuar una
formación que apenas había empezado, cargado de sueños e ilusión. Impulsado por una fuente inagotable
de motivación y buen hacer que me han llevado hasta las últimas pinceladas de la carrera.
Por supuesto, sin ayuda nada de esto podría haber sido posible. A día de hoy creo que todavía no soy
consciente de lo afortunados que podemos llegar a ser por tener una familia y amigos que nos arropan cada
día. En especial, todavía no he encontrado una palabra que sea capaz de describir lo que unos padres pueden
llegar a hacer por sus hijos y es posible que nunca lo haga, pues el amor, el cariño y la entrega que dedican
continuamente en la ayuda desinteresada que ofrecen, es sin duda el mayor de los tesoros que uno puede
encontrar en esta vida. Como seguramente en una vida no pueda devolver todo que ellos han hecho por mí, lo
único que puedo decir es: mamá, papá, gracias, soy feliz.
Del mismo modo, mi hermana ha sido esencial en el transcurso de todos estos años, gracias por cada
abrazo, por cada sonrisa y por cada tontería que hacen cada momento más bonito. A mis amigos y mis
compañeros de piso que han sabido aceptarme y aguantarme cada día, ¡ellos sí que tienen valor y paciencia!
Consciente de que esta página se parece más a una carta de amor que a una parte de un proyecto fin de
carrera, no puedo dejar de mencionar a personas importantes en este largo camino. Lucía, Swak, Antonio,
Brais, David, David Soto, Mariña, Felipe, Iván, Ale, Róber, Amanda, Dani, Rafa, Juanma, gente de Régimen
Binario, de Vigo y seguro que personas maravillosas que me han acompañado y no están en esta lista. Todos
y cada uno de vosotros os habéis quedado con un poquito de mí.
Agradecer a Manuel Torres su generosa ayuda en el diseño del soporte del sistema de telemetría y en
general a todo el equipo ARUS por haberme dejado participar durante dos años en un proyecto tan ilusionante
como el vuestro. Con vosotros he reído, llorado y sobre todo aprendido a que un sueño se puede cumplir con
esfuerzo y mucha voluntad.
Por último y no menos importante, me gustaría agradecer a Alejandro Carballar Rincón su apoyo, profe-
sionalidad y dedicación. Sin apenas haber disfrutado de su docencia, sí puedo admitir que desde el primer
momento aprecié una personalidad, carisma y tesón distintos a cualquier profesor de la escuela. He tenido la
suerte de coincidir con una persona maravillosa.
I
Resumen
E n cualquier diseño de un coche de competición, los métodos teóricos de cálculo, tanto estructurales como
termodinámicos, son excepcionalmente importantes. El ensayo real define con exactitud y realismo
la eficiencia de aquello que se ha diseñado u optimizado. Para demostrar los resultados teóricos y modelos
numéricos es necesario aplicar dichos estudios a la práctica, haciendo uso de la telemetría, radiotelemetría
o adquisición de datos en general. En el mundo del motorsport prácticamente todas las competiciones se
apoyan en sistemas de telemetría para mejorar la configuración de sus vehículos, desde el karting a turismos
adaptados a la competición como pueden ser los CER o GT’s, monomarcas como Fórmula 3, Fórmula
Renault, World Series y GP2 o las categorías reinas de Fórmula 1 o LMP1.
Este proyecto presenta un apoyo a la adquisición de datos de un coche de Fórmula Student, desarrollando
la implementación de un sistema de telemetría que sirva como complemento de seguridad del monoplaza y
como herramienta adicional que permita conseguir un correcto set-up del monoplaza.
III
Abstract
I n every racing car design, the structural and thermodynamic calculation methods are extremely important.
The real test accurately defines the efficiency of what has been previously designed or optimized. In
order to demonstrate the theoretical results and numerical models, it is necessary take this researches into
practice using the telemetry, radio telemetry and data acquisition. In the world of motorsport, almost every
competition are supported by telemetry systems to improve their vehicular configuration, as in the karting
competition, passengers cars adapted for competition (CER or GT’s), single-brand car race like Formula 3,
Formula Renault, World Series and GP2, and the blue band class, Formula 1 and LMP1.
This project sets out a model of data acquisition of a Formula Student car, which develops a telemetry
system used as safety complement and as additional tool that allows the proper set-up of the racing car.
V
Introducción
A modo de párrafo motivacional, este proyecto viene impulsado por el sueño de un niño que imaginaba
cómo sería posible aplicar un sistema de comunicaciones a un vehículo que era capaz de desplazarse
a velocidades tan altas, para qué serviría exactamente y cómo se trataría esa información que ‘volaba’ a
través de rectas interminables y estrechas curvas enlazadas. Largas hojas de cálculo e indescifrables gráficas
para mejorar el rendimiento de unos bólidos cada vez más y más complejos. Pero, ¿cómo un sistema de
telecomunicación puede ser tan útil? Aunque la solución se antoja difícil, el proyecto trata de dar respuesta a
cada una de las preguntas que ese niño formuló un día y que se propuso resolver.
A raíz del ímpetu, entusiasmo, buena voluntad y gran conocimiento del mundo del motor, un grupo de
estudiantes se embarcaron en la fundación de una escudería de la prestigiosa competición de automovilismo
Formula Student, organizada por la Sociedad de Ingenieros de Automoción (SAE, Society of Automotive Engi-
neers) y restringida exclusivamente a equipos de estudiantes representados por su universidad. Esta escudería
cobra el nombre de ARUS (Andalucía Racing Universidad de Sevilla) Team y está formada por estudiantes de
todas las disciplinas, cada una de ellas igual de importante, de forma que pueda ser posible abarcar un conoci-
miento amplio y completo de todos los sistemas que necesitan ser integrados en un monoplaza de competición.
El primer modelo de la temporada 2014, en el cual se priorizó la fiabilidad, solidez y consistencia de

un coche primerizo en la categoría, se llevó a cabo una filosofía conservadora en la que cada uno de los
diseños estaban enfocados a simplificar la estructura y funcionamiento del monoplaza, sobredimensionando
cada una de las partes que lo componen. El gran problema de la puesta en marcha de un vehículo de estas
características, desnudo y desprovisto de cualquier sistema electrónico de prevención de riesgos, es que da
pie a diversas averías que podrían haber sido detectadas a tiempo, evitando largos e incómodos periodos de
reparación.
Para impedir la reproducción de los problemas del pasado y eludir un mayor deterioro en la maquinaria
del prototipo de la temporada 2015, se ha encontrado la necesidad de elaborar un sistema que sea capaz de
notificar en tiempo real la amenaza de rotura o daño de la unidad motriz. Por esa razón puede llegar a ser
importante el diseño de un sistema de telemetría, el cual es capaz de monitorizar un importante volumen de
información que procesada correctamente puede fomentar nuevos caminos de desarrollo, pues sirve como
apoyo para mejorar y adecuar el set-up del coche a las características de una prueba o pista determinada.
Adicionalmente, la implementación de la telemetría en un vehículo FSAE puede cobrar gran importancia a la
hora de presentar el diseño del coche en las pruebas estáticas de la competición, donde unos jueces evalúan
los estudios y justificaciones acometidos en la construcción del prototipo.
Este documento comprende el análisis y los argumentos abordados para poner en práctica un sistema de
comunicación inalámbrica capaz de monitorizar la red sensorial del monoplaza. Si bien existen infinitas
soluciones para implementar el modelo, esta solución se argumenta siguiendo máximas como la minimización
del coste de implementación, reducción del volumen y peso total de los dispositivos y conseguir desplegar
una zona de cobertura tal que abarque de forma total un circuito de FSAE.
Con el fin de aportar conocimiento sobre lo que se va a discutir de forma clara, consisa y coherente, el
documento se ha estructurado de la siguiente forma:
VII
VIII Introduccion
• La competición: en este capítulo introductorio se intentará dar una visión global de la Formula
Student, del mundo tecnológico que lo soporta y de los valores que aporta. Se especificará brevemente
la descripción y objetivos de la competición, así como la estructura del equipo y las características del
monoplaza ART-15. Por último se comentará el peso de la telemetría en la competición.
• Elección de dispositivos: entrando en mayor detalle, se expondrán las restricciones que limitarán el
diseño del sistema y se justificará cuáles han sido los protocolos, dispositivos y soporte elegidos para
su implementación.
• Desarrollo del software de comunicación: aquí se describe la configuración de los equipos, así como
el desarrollo de la interfaz de visualización que muestra la monitorización de la información.
Tras los tres capítulos principales que conforman el cuerpo principal del documento, se detallarán los
problemas que se han encontrado durante la resolución del proyecto, las conclusiones finales y líneas futuras
de investigación que podrían tenerse en cuenta como complemento a este trabajo.
Índice
Resumen III
Abstract V
Introduccion VII
1. La competición 1
1.1. Descripción y objetivos 1
1.2. El equipo ARUS (Andalucía Racing Universidad de Sevilla) 3
1.3. El coche ART-15 4
1.4. Telemetría en la Formula Student 4
2. Elección de dispositivos 7
2.1. Restricciones generales 7
2.2. Comunicación 8
2.2.1. Protocolos de comunicación inalámbrica 8
Bluetooth 8
Wi-Fi 10
ZigBee 10
2.2.2. Tecnología escogida 12
2.3. Dispositivos 13
2.3.1. Electrónica open source 13
Arduino 13
Raspberry Pi 16
BeagleBone 17
2.4. Soporte 17
2.4.1. Agentes externos 17
2.4.2. Ubicación 18
2.4.3. Impresión 3D y elección de material 19
Características 19
Material 20
Diseño 20
Resultado final 21
3. Desarrollo del software de comunicación 23
3.1. Configuración de los equipos 23
3.1.1. Establecimiento de una red ZigBee 23
3.1.2. Configuración del microcontrolador Arduino 25
IDE 25
Lenguaje de programación 26
Sensores monitorizados 27
Sketch Arduino 27
3.1.3. Configuración de la centralita 29
3.2. Interfaz de visualización 31
IX
X Índice
3.2.1. Entornos de desarrollo 31

LabVIEW 31
Matlab 32
Aplicación web 33
3.2.2. Estructura 34
Base de datos MySQL 34
API REST de acceso a la base de datos 35
Script de escritura 36
Interfaz web 37
3.2.3. Puesta en marcha 40
4. Problemas encontrados y posibles soluciones 43
4.1. Unidad de control de motor 43
4.1.1. Solución 43
4.2. Bus CAN 43
4.2.1. Solución 46
5. Resultados de la competición 47
6. Conclusiones y líneas futuras de trabajo 51
Apéndice A.Bus CAN 53
A.1. Características principales del bus CAN 53
A.2. Protocolo de enlace de datos 54
A.3. Capas 55
A.4. Elementos que componen el bus CAN 55
A.5. Ejemplo funcional del bus CAN 57
Apéndice B.Datasheets 59
B.1. ATmega328P 60
B.2. XBee Pro S2B 61
B.3. MCP2515 65
B.4. MCP2551 66
Apéndice C.Código fuente 67
C.1. Arduino 67
C.2. API Rest 68
C.2.1. index.php 68
C.2.2. connect.php 68
C.2.3. get.php 69
C.2.4. getLast.php 69
C.2.5. post.php 70
C.3. Script de lectura Python 71
C.3.1. interfazSerial.py 71
C.4. Interfaz web 72
C.4.1. index.php 72
C.4.2. style.css 80
C.4.3. rpmdirecto.php 81
Índice de Figuras 83
Índice de Tablas 85
Bibliografía 87
1 La competición
1.1 Descripción y objetivos
La Formula Student, también conocida como Formula SAE, es una competición entre estudiantes de escuelas
de ingenierías de todo el mundo que promueve la excelencia en ingeniería a través de una competición donde
los miembros del equipo diseñan, construyen, desarrollan y compiten con un pequeño pero potente monoplaza.
Actualmente se celebran competiciones en numerosos países como Alemania, Reino Unido, España, Japón,
Brasil, Australia, etc. Todas ellas utilizan la misma normativa base original y llegan a reunir hasta 120
equipos y más de 2.000 estudiantes, como se aprecia en la Figura 1.1. Los resultados de las competiciones
son recogidos y puntúan en el ranking mundial.
Figura 1.1 Equipos participantes en el circuito de Hockenheim (Alemania). Julio 2015.
El objeto de la competición es simular, una situación en la cual una empresa de competición contrata a
estos ingenieros para desarrollar un prototipo y donde los compradores hipotéticos serían corredores amateur.
El coche debe por ello satisfacer unas prestaciones elevadas en aceleración, frenada, y estabilidad, pero
también debe ser fácil de mantener, barato, y fiable. Se valoran igualmente otros factores como la estética y
el confort. El precio máximo para el vehículo es de 21.000 euros y la victoria es para el equipo que mejor
logre superar todos estos requisitos.
1
2 Capítulo 1. La competición
En esta competición se evalúan los siguientes aspectos con las valoraciones que se indican en la Tabla 1.1
y las Figuras 1.2 y 1.3:
Tabla 1.1 Evaluación de la Formula Student.
Aspectos estáticos 325 puntos

Diseño 150
Análisis de costes 100
Plan de negocios 75
Aspectos dinámicos 675 puntos
Skid Pad (Pista deslizante) 75
Aceleración 75
Autocross (Eslalon) 100
Endurance (Resistencia) 325
Consumo 100
Total 1000 puntos
Figura 1.2 Participación de las pruebas estáticas y dinámicas en la puntuación final.
Figura 1.3 Participación de las diferentes pruebas en la puntuación.

1.2 El equipo ARUS (Andalucía Racing Universidad de Sevilla) 3
1.2 El equipo ARUS (Andalucía Racing Universidad de Sevilla)
El grupo técnico está formado por 55 estudiantes de la Escuela Superior de Ingenieros de Sevilla (con más de
50 alumnos en la reserva para dar continuidad al proyecto), con la colaboración de otros estudiantes de la
Universidad de Sevilla en el área de prensa, que comprende marketing, relaciones públicas y redes sociales.
El objetivo fundamental es el diseño, fabricación y ensamblaje de un monoplaza de competición. Con esto se
potenciarán aptitudes del alumno como el trabajo en grupo, el respeto por el equipo y la competitividad. Las
áreas en la que los integrantes están especializados comprenden Ingeniería de Telecomunicaciones, Ingeniería
Aeronáutica y todo tipo de especializaciones de la Ingeniería Industrial, a saber: Mecánica, Energética,
Eléctrica, Automática y Organización. Todo esto hace que el trabajo del que se encarga cada uno vaya acorde
a sus estudios y potencie de esta forma los conocimientos adquiridos, así como la oportunidad de aprender
del resto del equipo. También se debe de tener en cuenta que es una de las primeras ocasiones en que el
estudiante debe trabajar en grupo para conseguir una meta que nunca podría alcanzar trabajando de forma
individual. En la Figura 1.4 se presenta el ARUS Team en su última competición.
Figura 1.4 El ARUS Team participante en el circuito de Hockenheim (Alemania). Julio 2015.
El organigrama del equipo se presenta en la Figura 1.5, habiendo un profesor colaborador en cada área.
Figura 1.5 Organigrama del equipo ARUS.

4 Capítulo 1. La competición
1.3 El coche ART-15
A continuación se muestra una tabla resumen con las características principales del prototipo de la presente
temporada. Para conocer el coche en profundidad, desde la página web oficial del equipo se pueden encontrar
más detalles [54].
Tabla 1.2 Características principales del monoplaza ART-15.
Dimensiones Aerodinámica
Largo: 2954 mm Configuración: Carrocería de fibra de basalto
Ancho: 1453 mm Carga aerodinámica total y resistencia: CI = -1.01, Cd = 0.56
Altura: 1174 mm
Distancia entre ejes: 1550 mm
Electrónica Motor
ECU: Link G4+ Storm Motor: Honda CBR 600RR 2006, 4 cilindros/599 cc
Sistema de telemetría Tipo de combustible: sin plomo 98 octanos
Volante con display y vúmetro intregrados Relación de compresión: 12.0:1
Chasis Transmisión
Estructura tubular de acero reforzada con Diferencial: Helical Limited ; Slip Quaife QDF7ZR
fibra de basalto
Peso: 49 kg Relación final: 3,125:1
Mecánica
Frenos delanteros: GRIMECA, 220 mm con pinzas de 4 pistones AP Racing
Frenos traseros: GRIMECA, 200 mm con pinzas de 2 pistones AP RACING
Suspensión: doble brazos, pushrod delante, pullrod detrás y amortiguadores de 4 vías ajustables Ohlins.
Neumáticos: Hoosier 20, 5x7x13
Ruedas: Braid Formrace 16
Tras el transcurso de la temporada 2014, se han priorizado una serie de objetivos, de forma que se pueda
continuar con la evolución natural del coche. El modelo ART-14 pecó de ser un monoplaza sobredimensionado,
pues ante todo se buscó un diseño fiable y que evitara la rotura de cualquiera de sus sistemas motrices,y por
lo tanto muy pesado. Asimismo, otros factores como la configuración de motor y un paquete aerodinámico
básico afectaron negativamente al rendimiento del coche. Por consiguiente, para el diseño del prototipo
ART-15 se ha propuesto:
• Reducir el peso, de 300kg a 250Kg.
• Mejorar el rendimiento del motor Honda CBR 600RR.
• Potenciar la aerodinámica y crear un paquete aerodinámico completo.
• Implementar un sistema de telemetría.
El desarrollo de este último apartado es el objetivo de este Proyecto Fin de Carrera.
1.4 Telemetría en la Formula Student
Los sistemas de telemetría juegan un papel muy importante en la Formula Student porque contribuyen al
set-up del coche, permiten estudiar su comportamiento en ensayos y competición y mejorar sus prestaciones
en las siguientes competiciones. En la Figura 1.6 se presenta el esquema de telemetría estándar de un vehículo
de Formula Student.
1.4 Telemetría en la Formula Student 5
Figura 1.6 Estructura general de un sistema de telemetría en FSAE.
Dependiendo de las necesidades y objetivos del equipo, los sistemas de telemetría permiten la transmisión
de contenido multimedia como audio y vídeo, o únicamente la información procedente del bus CAN. Se debe
tener en cuenta que el envío de un gran volumen de datos implica directamente la adquisición de equipos
más sofisticados y costosos. En todo caso, por normal general están compuestos de dos transceptores, uno en
el coche y otro en el pit. El primero recibe la información de la unidad de control de motor del monoplaza,
la cual lee y procesa las señales de los sensores conectados. El segundo retransmite los datos a un PC que
mediante un software analiza, almacena y muestra el estado del coche a través de la monitorización de
información que se está llevando a cabo.
Las reglas de Formula Student no especifican el uso obligatorio de ningún protocolo específico de comuni-
cación y dan libertad de elección a los equipos para que utilicen el que mejor se adapte a sus necesidades.
Así, entre los sistemas a los que se ha podido tener acceso, los equipos de la Universidad de Zurich, Waterloo
y Barcelona han optado por tecnología WIFI, los de la Universidad de Lisboa y Politécnica de Madrid optado
por Zigbee, el de la Universidad de Western Australia ha optado por tecnología GSM. Otros equipos, como
el de la Universidad de Idaho, han optado por sistemas que utilizan protocolos propios no estandarizados.
2 Elección de dispositivos
2.1 Restricciones generales

Para la elección de dispositivos se ha de tener en cuenta diversos factores que afectan directamente al diseño
del sistema. Los principales agentes a tener en cuenta son:
• El rango necesario que debe cubrir la red para establecer cobertura total en la zona de funcionamiento.
El alcance se ha establecido acorde a la distancia máxima a la que se situará el monoplaza en la carrera,
supuesto a unos 300 metros.
Figura 2.1 Longitud máxima del circuito de FSAE de Hockenheimring (Alemania).
• El tamaño y el peso de los dispositivos debe ser reducido, pues el sistema debe cumplir también el
objetivo general del diseño del coche, que no es otro que el de reducir la carga total, sin dejar de lado la
eficiencia y fiabilidad. Además, debido a la ubicación disponible, se debe evitar la elección de cualquier
equipo voluminoso.
• El coste también debe ser reducido. El presupuesto total del equipo es bajo y se han priorizado aquellas
partes del monoplaza fundamentales para su funcionamiento. El sistema de telemetría colabora en
la prevención de cualquier problema grave durante la realización de un test o carrera, pudiendo en
muchos casos proteger la mecánica del coche, aunque se ha de comprender que no es fundamental
para la puesta en marcha del automóvil. Por consiguiente, se ha destinado un máximo de 250Ä para el
diseño del sistema, de un total de 15.000Ä del presupuesto total.
7
8 Capítulo 2. Elección de dispositivos
A continuación se procede a realizar un estudio de las distintas tecnologías de comunicación inalámbrica

y dispositivos que se van a tener en cuenta, de forma que se cumplan las restricciones comentadas en el
apartado anterior.
2.2 Comunicación
2.2.1 Protocolos de comunicación inalámbrica
A lo largo de los últimos años la tecnología orientada a la conectividad inalámbrica ha experimentado un

notable crecimiento, ofreciendo una serie de servicios imposibles en una red cableada y dotando al usuario
de una autonomía cada vez mayor. Aunque el comienzo fuera exclusivamente doméstico, la propia evolución
ha permitido extender el uso local al de pequeñas redes de monitorización de sistemas y hasta grandes redes
empresariales con transferencias de gran cantidad de información.
El diseño de un sistema de telemetría no difiere demasiado de la creación de cualquier red inalámbrica en

un hogar, empresa o red urbana, pues al fin y al cabo el objetivo es establecer la conexión entre dos equipos
que intercambian pequeños paquetes de información, con el único inconveniente de que uno de los dos
dispositivos se encuentra en movimiento a una velocidad moderada. Por consiguiente, el estudio se simplifica
bastante, pues los protocolos son bien conocidos.
En primer lugar es indispensable conocer la banda de frecuencia en la que se va a trabajar. Las dos
principales bandas de comunicaciones inalámbricas son las infrarrojas (IR) y las de radiofrecuencia (RF). La
primera no es adecuada para este sistema, ya que requiere distancias muy próximas y visibilidad directa para
su funcionamiento. En cambio, las comunicaciones por RF permiten establecer una conexión entre puntos
más distantes y sin necesidad de que se encuentren en línea directa de visión.
Dentro de la banda RF cabe destacar la banda ISM (Industrial, Scientific and Medical), reservada para uso
no comercial y abierta para todo tipo de usuario, sin necesidad de licencia alguna. Muy extendida para redes
WLAN (Wireless Local Area Network) y WPAN (Wireless Personal Area Network). Los dispositivos que
operan en esta banda lo hacen principalmente a la frecuencia de 2.4 GHz lo que provoca altos niveles de inter-
ferencia. A su vez, en la banda de ISM también se puede trabajar a las frecuencias de 868 MHz (Europa) y 915
MHz (Estados Unidos), que pese a tener la limitación geográfica ofrecen mayor alcance y menos interferencias.
En esta banda es común la utilización de los estándares Wi-Fi, Bluetooth y ZigBee, cada uno de ellos
orientados a un fin concreto y ofreciendo distintas características como tasa de transmisión, rango de
funcionamiento, potencia nominal, ancho de banda, tipo de modulación, etcétera. Estos serán los tres
estándares que se ha procedido a estudiar en el momento de la realización del proyecto, pues los tres son
candidatos a cumplir los requisitos del sistema y ofrecen una amplia gama de dispositivos que elegir.
Bluetooth
Bluetooth es un estándar de comunicación para Redes Inalámbricas de Área Personal (WPAN) que posibilita
la transmisión de voz y datos en la banda ISM de 2.4 GHz. Debido a las altas probabilidades de interferencia
en esta banda, Bluetooth está basado en la técnica de modulación en espectro ensanchado adaptable con
salto de frecuencia (del inglés Adaptable Frequency Hopping o AFH), la cual mejora la resistencia a la
interferencia de radiofrecuencia y la eficiencia de transmisión a lo largo del espectro, evitando las frecuencias
de hacinamiento en la secuencia de salto. Estos saltos pueden darse en un total de 79 frecuencias con intervalos
de 1 MHz y con un máximo de 1600 saltos por segundo.
El estándar Bluetooth se basa en el modo de operación maestro/esclavo. El término piconet se utiliza para
hacer referencia a la red formada por un dispositivo y todos los dispositivos que se encuentran dentro de su
rango. Pueden coexistir hasta 10 piconets dentro de una sola área de cobertura. Un dispositivo maestro se
puede conectar simultáneamente con hasta 7 dispositivos esclavos activos (255 cuando se encuentran en
modo en espera).
Bluetooth permite que dos piconets puedan conectarse entre sí para formar una red más amplia, denominada
scatternet al utilizar ciertos dispositivos que actúan como puente entre las dos piconets.
2.2 Comunicación 9
Figura 2.2 Scatternet Bluetooht formada por dos piconets.
El rango de los dispositivos que utilizan esta tecnología varía en función de la potencia máxima permitida,
estableciéndose una clasificación compuesta por tres clases.
Tabla 2.1 Clases Bluetooth.
Clase Potencia máxima permitida (mW) Potencia máxima permitida (dBm) Alcance aproximado
Clase 1 100 mW 20 dBm 100 metros
Clase 2 2.5 mW 4 dBm 5-10 metros
Clase 3 1 mW 0 dBm 1 metro
A su vez, según la capacidad del canal los dispositivos Bluetooth pueden clasificarse según la siguiente tabla:
Tabla 2.2 Relación entre las distintas versiones Bluetooth y su capacidad.
Versión Capacidad del canal (Mbps)

1.2 1
2.0 3
3.0 24
4.0 24
Wi-Fi
Es otra de las tecnologías WLAN más comunes, la cual tiene como principal objetivo garantizar la interope-
rabilidad entre los equipos conectados a la misma red según la norma IEEE 802.11, independientemente de
su fabricante.
El estándar IEEE 802.11 define el uso de los dos niveles inferiores de la arquitectura o modelo OSI (capa
física y capa de enlace de datos), especificando sus normas de funcionamiento en una WLAN. A raíz de esta
norma han surgido una serie de estándares aceptados bajo la marca Wi-Fi:
• El estándar IEEE 802.11b. Tiene una velocidad de transmisión teórica de 11 Mbps y utiliza el método
de acceso CSMA/CA (acceso múltiple con escucha de portadora y evasión de colisiones), protocolo
que controla el acceso a redes de bajo nivel que permite que múltiples estaciones utilicen un mismo
medio de transmisión. Funciona en la banda de 2.4 GHz. Al igual que en Bluetooth, debido al gran
número de interferencias en la banda, este estándar utiliza una técnica de ensanchado de espectro DSSS
(Direct Sequence Spread Spectrum), técnica que genera un patrón de bits redundante por cada uno de
los bits que componen la señal.
• El estándar IEEE 802.11g. Es la evolución del anterior y por lo tanto opera en la misma banda de 2.4
GHz, pero es capaz de alcanzar velocidades teóricas de hasta 54 Mbps utilizando modulación OFDM
(Orthogonal Frequency Division Multiplexing). Se pueden alcanzar distancias de hasta 100m.
• El estándar IEEE 802.11ac, conocido como WIFI 5, el cual opera en la banda de 5 GHz. La principal
ventaja respecto a los anteriores es que dispone de una menor interferencia al no existir otras tecnologías
que trabajen a dicha frecuencia. Como contrapunto cabe destacar que su alcance es algo menor al
operar en frecuencias más altas.
La tecnología Wi-Fi permite principalmente tres tipos de disposiciones lógicas de la red: Ad-hoc, infraes-
tructura o malla. Las redes Ad-hoc, también llamadas redes entre pares, conforman la comunicación de varios
dispositivos sin necesidad de puntos de acceso, útil para usos temporales como reuniones o conferencias. La
topología en infraestructura dispone de una red en la que los equipos intercambian información a través de
un punto de acceso (PA). Por último, una red en malla está compuesta por un conjunto de nodos (puntos
de acceso), que dan lugar a una única red con una zona de cobertura mayor en la que todos los dispositivos
tienen la capacidad de comunicarse entre ellos a través de los PA. Cada una de las topologías estudiadas
pueden comprobarse en la siguiente imagen:
Figura 2.3 Posibles topologías Wi-Fi.
ZigBee
Por último, ZigBee es otro de los protocolos de comunicaciones inalámbricas que se estudiarán en el presente
documento. Definido en el estándar IEEE 802.15.4 y basado en los niveles físicos (PHY) y el control de acceso
2.2 Comunicación 11
al medio (MAC). Este protocolo utiliza la misma modulación que Wi-Fi, la modulación de espectro expandido
(DSSS). Ha sido diseñado para dispositivos con aplicaciones que requieren comunicaciones seguras con baja
tasa de envío de datos, maximización de la vida útil de sus baterías y bajo coste. Estos dispositivos son capaces
de operar en múltiples frecuencias, como la banda de 868 MHz para Europa y la de 915 MHz para Estados
Unidos, incluyendo la de 2.4 GHz a lo largo del territorio mundial. Los anchos de banda y rendimientos son
muy distintos en cada caso, pues mientras en la banda de 868 MHz existen 300 MHz de ancho de banda dispo-
nible, permitiendo hasta 20 kbps, a frecuencias de 2.4 GHz la tasa de transmisión puede alcanzar los 250 kbps.
Uno de los puntos fuertes del protocolo ZigBee es su simplicidad hardware y software. Desde el punto de
vista hardware, puede decirse que ZigBee ha sido optimizado para el bajo coste a gran escala, tiene pocas
partes analógicas y utiliza circuitos digitales siempre que sea posible. Desde el punto de vista software, puede
llegar a ser algo más complejo aunque todavía por debajo de competidores como Bluetooth y Wi-Fi.
Una red ZigBee está compuesta por tres tipos de dispositivos. El coordinador ZigBee se encarga de
controlar la red y los caminos que deben seguir los dispositivos para conectarse entre ellos. El router ZigBee
interconecta dispositivos separados en la topología de red, además de ofrecer un nivel de aplicación para la
ejecución del código de usuario. Por último, el dispositivo final tiene la capacidad de comunicarse con su
nodo padre (coordinador o router), pero no puede transmitir información destinada a otros usuarios. Una red
ZigBee debe de tener al menos un coordinador y dispositivo final para su correcto funcionamiento.
Figura 2.4 Red ZigBee con topología en malla.
Otra gran ventaja de este protocolo es su gran abanico de posibilidades a la hora crear una topología de
red, pues permite tanto topologías en estrella, como en árbol y malla. Como puede observarse en la imagen
anterior, la topología en malla puede llegar a ser muy interesante para redes que tengan un gran número
de nodos y que necesiten alta disponibilidad, pues de esta manera se disponen caminos redundantes que
mantienen la red activa después de la caída de alguno de los nodos.
2.2.2 Tecnología escogida
A modo de resumen, en la siguiente tabla se muestra una comparativa de las tres tecnologías estudiadas.
Tabla 2.3 Comparativa entre los protocolos de conexión inalámbrica contemplados.
Estándar Bluetooth Wi-Fi ZigBee

Especificación IEEE 802.15.1 802.11a/b/g 802.15.4
Banda de frecuencias 2.4 GHz 2.4 GHz; 5GHz 868/915 MHz; 2.4 Ghz
Tasa máxima de señal 4 Mbps 54 Mbps 250 Kbps
Alcance 10-100 m 100 m 400 m
Potencia de txón nominal 0-10 dBm 15-20 dBm (-25) - 0 dBm
Canales RF 79 14 (2.4 GHz) 1/10; 15
Ancho de banda 1 MHz 22 MHz 0.3/0.6 MHz; 2 MHz
BPSK, QPSK, COFDM,
Modulación GFSK BPSK (+ ASK), O-QPSK
CCK, M-QAM
Ensanchamiento FHSS DSSS, CCK, OFDM DSSS
Célula básica Piconet Ad-Hoc Estrella
Célula extendida Scatternet Infraestructura, malla Árbol, malla
Número máximo de
8 2007 >65000
nodos permitodos
Cada protocolo está basado en un estándar IEEE. En general, tanto ZigBee como Bluetooth están enfocados
a redes WPAN (alcance aproximado de 10 metros), mientras que Wi-Fi está orientado a las WLAN (alcance
aproximado de 100 metros). No obstante, ZigBee puede alcanzar distancias superiores a los 100 metros en
diversas aplicaciones.
Las tasas de transmisión son muy distintas en cada caso. Mientras Bluetooth es capaz de alcanzar los 4
Mbps, Wi-Fi podría obtener una tasa de hasta 54 Mbps. En esta parcela ZigBee queda un poco descolgado,
pues en el mejor de los casos transmite a 250 Kbps. Todas estas tasas están supeditadas a la cobertura
requerida, a las interferencias en la zona de trabajo y a otra serie de factores. En el caso del sistema de
telemetría, al no contar con la transmisión de información de alta capacidad como vídeo o datos de gran
volumen, la tasa de envío de ZigBee podría ser suficiente.
El siguiente punto a estudiar en la tabla anterior es el alcance que ofrece cada tecnología. Como ya se
observó en las restricciones generales de este capítulo, se necesitan al menos 300 metros de cobertura para
recibir información en tiempo real sin algún tipo de corte. De la tabla se obtiene que solamente ZigBee ofrece
esta característica sin necesidad de repetidores.
La potencia es una propiedad algo menos importante para la elección de la tecnología, pues aunque podría
ser recomendable escoger la tecnología de menor potencia para valorar un menor consumo y calentamiento del
dispositivo, cualquiera de los estándares ofrece un amplio margen que evita los malfuncionamientos del diseño.
Al igual que ocurría con la tasa de transmisión, el hecho de recibir del bus CAN poco tráfico de información,
abre la posibilidad de elegir protocolos con un ancho de banda también bajo, como lo son Bluetooth y ZigBee.
Por último, cabe destacar que como el sistema a implementar es punto a punto, pues solo se va a tener un
coordinador de red y un dispositivo final, es irrelevante el tipo de topología de red que es capaz de desplegar
cada protocolo, pues tanto una piconet, como una red en árbol, estrella o malla son válidos para el sistema.
Recapitulando, se puede afirmar que ZigBee es el protocolo ideal para el sistema de telemetría que se
quiere desarrollar, pues cumple los requisitos de alcance, banda de frecuencia, tasa de transmisión, y ancho
de banda necesarios. Además, habría que tener en cuenta también que existe una amplia gama de dispositivos
basados en el estándar 802.15.4, siendo en la mayoría de los casos más baratos que los basados en Bluetooth
o Wi-Fi.
2.3 Dispositivos 13
2.3 Dispositivos
2.3.1 Electrónica open source
Esta sección se encarga de comparar y elegir el hardware necesario para llevar a cabo el diseño del sistema de
telemetría. Para ello, se tendrán en cuenta los sistemas más comunes y utilizados del mercado, pues implica
directamente un buen soporte y en muchos casos un bajo coste en los dispositivos. En concreto, el estudio se
centrará en las plataformas abiertas y versátiles para el desarrollo de productos electrónicos enfocados al
público no experto, como son Arduino, Raspberry Pi y Beaglebone. Al contar con hardware libre, existe
la posibilidad de reutilizar, adaptar y mejorar infinidad de código ya programado para estas plataformas,
facilitando el aprendizaje y el desarrollo del sistema.
Arduino
Es una plataforma de hardware libre, basada en una placa con un microcontrolador y un entorno de de-
sarrollo, diseñada para facilitar el uso de la electrónica en proyectos multidisciplinares. Debido a su bajo
coste y a la sencillez a la hora de programar el microcontrolador, pues está basado en el lenguaje C y tiene
una amplia comunidad que da soporte a esta tecnología, Arduino se convierte en una solución muy interesante.
Desde la página oficial https:// store.arduino.cc/ se puede acceder a toda la gama de productos que ofrece
la marca, entre los cuales se pueden encontrar diversos boards y shields que se deben tener en cuenta a la
hora de sopesar los costes y la dificultad de diseño.
Considerando las características que ofrece cada una de las placas (boards) y los requisitos que es necesario
cubrir, se puede determinar que la placa básica y al mismo tiempo más barata correspondiente al modelo
Arduino UNO Rev3 [20], es suficiente para satisfacer las demandas del proyecto. Estas propiedades quedan
resumidas en la siguiente tabla:
Tabla 2.4 Especificaciones técnicas Arduino.
Microcontrolador ATmega328
Voltaje operativo 5V
Voltaje de entrada recomendado 7-12V
Entradas/Salidas digitales 14
Entradas/Salidas digitales PWM 6
Entradas analógicas 6
Memoria Flash 32 KB
Velocidad de reloj 16 MHz
Precio 25 Ä
Figura 2.5 Visión frontal del Arduino UNO Rev3.

Como complemento del microcontrolador, es necesario adquirir un total de dos shields, dos módulos
y un adaptador para tener la capacidad de recibir las lecturas del bus CAN y poder recibir y transmitir la
información de forma inalámbrica.
En primer lugar, la CAN-BUS Shield, de Seeed Studio, a través del controlador MCP2515 [29] y el
transceptor CAN MCP2551 [30] permite leer y enviar paquetes a través del puerto serie RS232 o los canales
alto y bajo del bus, utilizando el sistema normalizado del protocolo CAN. Este shield tiene un precio
aproximado de 33 Ä [22].
Figura 2.6 Visión frontal del CAN-BUS Shield.
Para poder establecer una conexión inalámbrica entre el monoplaza y el ordenador que se encontrará en la
zona de cobertura, es necesario adquirir otro shield que tenga la capacidad de dar este soporte. Para ello,
el distribuidor oficial tiene a disposición del cliente el producto Wireless SD Shield, el cual a través de su
cabezal adaptado a los módulos XBee de Digi [25] posibilita la adquisición de información a través de estos
dispositivos de manera inalámbrica. Además, tiene integrada una ranura para una tarjeta microSD, la cual
puede ser de gran utilidad en caso de necesitar algún sistema de almacenamiento adicional. Este shield tiene
un coste aproximado de 29Ä [24].
Figura 2.7 Visión frontal del Wireless SD Shield.
Por último y tal y como se ha comentado en el párrafo anterior, es necesario utilizar algún módulo con el
patillaje del Wireless SD Shield. En este caso, la gama XBee es ideal para el proyecto [26], pues dispone de las
características necesarias para cubrir las necesidades que se comentaron en apartados anteriores. En particular,
es el modelo XBee PRO S2B con conector RPSMA el elegido para actuar de receptor/transmisor en el sistema.
2.3 Dispositivos 15
Este equipo opera en la banda de 2.4 GHz y trabaja sobre el estándar 802.15.4, ofreciendo una comunicación
bidireccional entre microcontroladores, ordenadores o prácticamente cualquier dispositivo que disponga
de puerto serie o USB. En la tabla que se muestra a continuación se pueden apreciar las características del
equipo:
Tabla 2.5 Especificaciones técnicas XBee Pro S2B RPSMA.
Alimentación 3.3V @ 215 mA

Velocidad de transferencia 250 Kbps
Potencia de salida 63 mW (+17 dBm)
Alcance 1500 metros aprox.
Conector RPSMA para antena externa
Certificado FCC
6 pines ADC de 10-bit
8 pines digitales IO
Encriptación 128-bit
Configuración local o de forma inalámbrica
Comandos AT o API
Figura 2.8 Visión frontal del XBee PRO S2B RPSMA.
Este módulo tiene un precio aproximado de 57Ä [27]. Para completar el sistema, el receptor necesita un
adaptador del módulo XBee, para poder leer a través del puerto USB. De entre todos los modelos, se ha
decantado por el vendido por el mismo distribuidor que los productos anteriores, de forma que se puedan
minimizar costes en el envío. El adaptador puede encontrarse por un total de 28Ä aproximadamente [28].
Figura 2.9 Visión frontal del XBee Explorer.
A modo de resumen, el coste total del sistema sería el siguiente:

Tabla 2.6 Presupuesto total del sistema con la plataforma Arduino.
Elemento Unidades Precio

Arduino UNO Rev3 1 25 Ä
CAN-BUS Shield 1 33 Ä
Wireless SD Shield 1 29 Ä
XBee PRO S2B RPSMA 2 114 Ä
Antena RPSMA 2.2 dB 2 16 Ä
XBee explorer 1 28 Ä
Total 245 Ä
Como podrá comprobarse posteriormente, Arduino es la solución ideal para el diseño del sistema, convir-
tiéndose en la plataforma de hardware libre elegida por razones presupuestarias y técnicas, ya que dispone de
multitud de posibilidades a la hora de adaptar diversos módulos compatibles al microcontrolador, además de
ofrecer un entorno de desarrollo muy sencillo.
Raspberry Pi
Otra de las soluciones de bajo coste es la del ordenador de placa reducida (SBC), Raspberry Pi, desarrollado
en el Reino Unido bajo la Fundación Raspberry Pi con el objetivo de estimular la enseñanza de ciencias
de computación en las escuelas [31]. A diferencia de Arduino, este ofrece un procesador central (CPU),
procesador gráfico y memoria RAM, de forma que gracias a los puertos integrados como el USB, Ethernet,
entradas de vídeo y audio y entradas/salidas de propósito general (GPIO), hacen de Raspberry Pi un ordenador
de dimensiones reducidas y prestaciones más que aceptables. En la tabla que se muestra a continuación se
representan las especificaciones técnicas del modelo B+ de Raspberry Pi 2:
Tabla 2.7 Especificaciones técnicas Raspberry Pi 2 modelo B+.
SoC BroadcomBCM2835
CPU ARM 1176JZF-S a 700 MHz
GPU Broadcom VideoCore IV
Memoria (SDRAM) 512 MiB
Puertos USB 4
Entradas de vídeo Conector MIPI CSI
Salidas de vídeo Conector RCA y HDMI
Salidas de audio Conector de 3.5 mm
Almacenamiento MicroSD
Conectividad de red 10/100 Ethernet (RJ-45)
Consumo energético 600 mA (3 W)
Fuente de alimentación 5 V vía Micro USB o GPIO Header
El precio aproximado de Raspberry Pi 2 modelo B, es de 50 Ä [32].
Figura 2.10 Raspberry Pi 2 modelo B+.
El principal problema que ofrece este tipo de SBC es la adaptación a un sistema que sea capaz de leer la
2.4 Soporte 17
información transmitida a través del bus CAN y de realizar una comunicación inalámbrica tal y como sucedía
en Arduino. La primera solución que podría proponerse es la de diseñar una placa de circuito impreso (PCB)
que permita conectar tanto el adaptador de un módulo XBee como la extensión que ofrezca la posibilidad de
realizar las lecturas del bus correspondiente. El segundo recurso sería comprar un shield [33] que sostenga
una adaptación entre los zócalos de Raspberry Pi y Arduino, de forma que a través de los puertos de propósito
general se puedan realizar las operaciones oportunas para establecer una correcta comunicación en tiempo real.
La adquisición de los módulos de la serie XBee y los adaptadores comentados en el apartado anterior,
implicarían un aumento directo de la complejidad hardware y software del sistema. Por este motivo y el
considerable incremento del coste, Raspberry Pi queda descartada del diseño pese a proporcionar unas
mejores prestaciones que Arduino UNO Rev3.
BeagleBone
En el caso de Beaglebone, de Texas Instruments [34], se encuentran los mismos problemas que para Rasp-
berry Pi. Es un ordenador de tamaño reducido con unas prestaciones y procesador bastante similares al
anterior, destacando en proyectos de domótica y monitorización de redes de sensorización y automatización
de procesos.
Figura 2.11 Vista preliminar de Beaglebone.
Se prescinde del análisis de este mini PC por claros motivos de complejidad hardware, software y coste
(algo más caro que el modelo B de Raspberry Pi 2 [35]).
2.4 Soporte
En este apartado se explicará el diseño del soporte sobre el que se colocarán los dispositivos correspondientes al
sistema. Se han tenido en cuenta distintos materiales y ubicaciones, así como los agentes externos que pueden
afectar al funcionamiento de la telemetría, intentando priorizar en la medida de lo posible el rendimiento de
la misma.
2.4.1 Agentes externos
En un monoplaza de competición, donde gran parte del coche está al descubierto y una vez que se encuentra
en movimiento es propenso a recibir impactos y suciedad, es importante proteger de una forma apropiada
todos los elementos que componen el sistema. Por este motivo, es necesario diseñar una caja a medida o
adaptar cualquier otra con el fin de obtener el hermetismo necesario para evitar el contacto con cualquier
fluido o residuo. Recuérdese que pueden darse condiciones de lluvia, pueden existir fugas en el monoplaza y
además con casi total seguridad se adhieran trozos de goma, grava, polvo, fibra, etc.
En consecuencia, los elementos que componen el sistema deben estar protegidos por algún tipo de cofre
con pequeñas salidas controladas para la antena, alimentación y can BUS. Tiene que ser fácilmente accesible
desde el exterior para poder ser manipulado en caso de que fuera necesario y debe tener la propiedad de ser
un buen aislante térmico, impermeable y ajeno a cualquier impacto exterior.
2.4.2 Ubicación
Con el fin de encontrar el lugar idóneo para situar el sistema, se ha propuesto el tren trasero y delantero del
monoplaza como posibles ubicaciones. Se descarta la posibilidad de colocar los dispositivos en el lateral por
la falta de espacio y por ser zonas propensas a recibir algún tipo colisión.
El área correspondiente a la parte superior del tren trasero se ha valorado positivamente para este propósito,
ya que dispone una altura más que correcta para la comunicación con el otro extremo, además de estar libre
de riesgo de impacto. Pese a ello, esta zona ha sido descartada debido a su proximidad a la fuente principal
de calor (motor) y porque la cogida a esa barra del chasis estaría sometida a las vibraciones provocadas tanto
por el motor como por la fuerza ejercida por el alerón trasero.
Figura 2.12 Vista de la parte trasera del monoplaza. En rojo, las posibles ubicaciones del soporte del sistema.
De este modo, es el tren delantero la zona la elegida para esta finalidad. En concreto, en la figura 2.13 se
puede observar que la parte posterior al salpicadero es ideal, tanto por su protección como por la proximidad
a la parte superior del chasis donde saldría la antena del dispositivo. Asimismo, por la estructura y longitud
del bus CAN, el sistema de telemetría actuaría como dispositivo intermedio de una comunicación con fin en
la electrónica del volante.
2.4 Soporte 19
Figura 2.13 Vista de la parte delantera del monoplaza. En rojo, la posible ubicacion del soporte del sistema.
2.4.3 Impresión 3D y elección de material
Debido a que el equipo ARUS Team dispone de dos impresoras 3D, se procederá a realizar el diseño de un
molde personalizado para el sistema de telemetría. De esta forma, con la elección correcta del material, se
puede conseguir una estructura que aguante correctamente pequeños impactos y aisle correctamente del
calor, además de tener las dimensiones adecuadas para los dispositivos que se van a utilizar, ahorrando peso
y espacio en el monoplaza.
Características
La impresión 3D es una nueva tecnología en continuo desarrollo que dará muchos frutos en un futuro cercano.
Sus principales ventajas respecto a la fabricación tradicional son:
• El ahorro en los costes y tiempo de producción. El precio de un diseño pasa a depender única y
exclusivamente del volumen del objeto fabricado y por tanto la cantidad de material utilizado.
• Tiempo de producción menor.
• No es necesario el ensamble de piezas. Las impresoras 3D actuales permiten crear objetos ya ensam-
blados, evitando el proceso de montaje posterior, que suele suponer un importante gasto de personal y
de tiempo de fabricación, que a su vez afecta al tiempo de producción de los objetos.
• Un producto puede ser impreso bajo demanda, sin necesidad de contar con estocaje.
• No son necesarias habilidades especiales. La fabricación tradicional y artesanal necesita de ciertas
habilidades que en ocasiones requiere años de práctica, como por ejemplo en la artesanía. La impresión
3D borra de la ecuación esta limitación, permitiendo a cualquiera que sepa manejar un software de
diseño acerarse a la producción de objetos en igualdad de condiciones, y por tanto, una vez más,
abriendo la puerta a nuevos emprendedores.
• Fabricación compacta y portátil. En la fabricación tradicional, las máquinas usadas para fabricar objetos
pesan cientos o miles de kilos, y producen objetos diminutos en comparación con el tamaño de dichas
máquinas. Sin embargo, las impresoras 3D fabrican objetos casi tan grandes como ellas mismas, lo
que implica menos necesidad de espacio para montar un taller de fabricación, y a su vez, permite una
total movilidad de éste.
• Menos material de deshecho. La fabricación de objetos metálicos mediante sistemas tradicionales
desperdicia, según los autores, hasta un 90 % del material. Esta tasa de desperdicio es ínfima en las
impresoras 3d que imprimen en metal. Esto es aplicable casi a todos los materiales. Esto afecta a los
costes, y también al medioambiente.
• Infinitos materiales de fabricación. La fabricación tradicional usa técnicas agresivas que cortan, com-
primen, funden, estiran, perforan materiales, etc. Eso limita mucho la posibilidad de mezclar materiales.
Sin embargo, una de las ventajas de la impresión 3d es la posibilidad de mezclar materiales en distintas
proporciones, lo que implica poder imprimir en infinitas variaciones de materiales mezclados entre sí.
• Capacidad de crear réplicas exactas. La tecnología de escaneado combinada con una impresora 3d nos
permitirá, cada vez mas, replicar a la perfección objetos existentes.
Material
Respecto al material utilizado para impresión, el diseño se realizará con el termoplástico ABS (Acrilonitrilo
Butadieno Estireno). Este material es ampliamente conocido por su dureza y resistencia a grandes impactos,
por lo que es generalmente útil para piezas que no se pueden utilizar en ambientes inferiores a -20ºC o en ex-
ceso de 80ºC. Cada uno de estos componentes aporta características diferentes a este material. El acrolonitrilo
aporta rigidez, resitencia a ataques químicos, dureza y estabilidad a altas temperaturas. El butadieno aporta
tenacidad a bajas temperaturas y resistencia a impacto. Por último, el estireno aporta resistencia mecánica,
rigidez, brillo y dureza. La mayor desventaja del ABS en el apartado de calidad de impresión es su tendencia
a curvarse y su posible deformación en la parte inferior de la pieza. El ABS también tiene problemas cuando
hablamos de pequeños detalles de impresión, como en el caso de esquinas afiladas cuando realmente lo que
queremos son esquinas redondeadas.
En cuanto a otros materiales de impresión como PLA (Poliácido Láctico), el ABS tiene un impacto más
perjudicial para el medioambiente, además de no poder conseguir impresiones redondeadas tan perfectas
como con el PLA.
Diseño
El desarrollo de las piezas se ha llevado a cabo en el software de diseño, fabricación e ingeniería asistida
comercializado por Dassault Systemes, CATIA (computer-aided three dimensional interactive application).
Como la fabricación de la cubierta del sistema se considera fuera del objetivo del proyecto, se ha acudido a
un compañero para su elaboración.
Cabe mencionar que para la optimización de recursos y espacio, el recubrimiento del sistema será apro-
vechado a su vez por otro microcontrolador destinado a la adquisición de algunos sensores situados en la
suspensión del monoplaza. Este microcontrolador es el modelo Arduino Due, del mismo fabricante que
el que se utiliza para la telemetría del coche. Por este motivo, la caja donde irán situados los dispositivos
tendrá un tamaño adaptado al Arduino DUE, el cual tiene una mayor longitud que el UNO y dispone de los
mismas cogidas en su parte inferior. Cuando exista la necesidad de aplicar la adquisición de los sensores de
suspensión, el sistema de telemetría quedará inutilizado, sustituyendo el modelo UNO por Due y empleando
únicamente el Wireless SD Shield, de forma que se pueda registrar en una memoria externa todos los datos
a procesar. A priori la suspensión solo necesitará ser comprobada y ajustada en las primeras pruebas, sin
interferir posteriormente en la puesta en marcha del sistema del proyecto.
El soporte está compuesto de dos partes, unidas un tornillo de métrica cuatro en cada una de sus esquinas.
En las figuras 2.14 y 2.15 se puede apreciar el diseño realizado por Manuel Torres. En la parte inferior se han
habilitado dos zonas que dan acceso a la alimentación y bus CAN a la placa del microcontrolador. En la parte
superior será necesario realizar una apertura para la antena del sistema, la cual será realizada manualmente
tras la impresión de los moldes.
2.4 Soporte 21
Figura 2.14 Vistas de la parte inferior del soporte del sistema.
Figura 2.15 Vistas de la parte superior del soporte del sistema.
Resultado final
Una vez fabricado, el resultado final puede apreciarse en la Figura 2.16.
Figura 2.16 Vista lateral y superior de las dos piezas fabricadas.

3 Desarrollo del software de comunicación
3.1 Configuración de los equipos
En este capítulo del proyecto se procede a explicar la configuración de los módulos de comunicación
inalámbrica XBee, así como el bus CAN de la centralita y el microcontrolador del Arduino. A su vez, también
se detallará cómo se produce la adquisición de datos en el receptor y el proceso de desarrollo de la interfaz
de visualización.
3.1.1 Establecimiento de una red ZigBee
Como ya se comentó en el apartado 2.2.1, ZigBee ofrece la posibilidad de crear una red en malla, árbol
y estrella, pudiendo interconectar hasta 65000 nodos al mismo tiempo. Esto permitiría a nuestro sistema,
tras la configuración correspondiente, tener varios monoplazas enviando información a tiempo real a varios
receptores, de tal forma que si se elige y coloca al coordinador de red de manera adecuada, se podría mejorar
la zona de cobertura y velocidad de transmisión de los equipos, ofreciendo una mayor calidad a la red.
Debido a las limitaciones del equipo, únicamente se establecerá una comunicación punto a punto entre
los dos módulos XBee adquiridos, uno será el coordinador de red y otro el dispositivo final, pudiendo estar
indistintamente en el monoplaza o en el ordenador remoto.
Para la configuración de los dos módulos, en primer lugar, se apuntará el número de serie asociado a cada
equipo, el cual aparece en la parte posterior de cada uno de ellos tal y como se puede apreciar en la figura 3.1.
Figura 3.1 Dirección de red de los módulos ZigBee.
23
24 Capítulo 3. Desarrollo del software de comunicación
Esta dirección de 64 bits está compuesta por una parte alta común a los dos dispositivos (0013A200) y una
parte baja unívoca. Estas direcciones cobran importancia a la hora de que un equipo pueda comunicarse con
su par. A partir de este momento, la asociación de cada dispositivo será la mostrada en la siguiente tabla:
Tabla 3.1 Direcciones de red de los dos dispositivos utilizados.
Coordinador de red Dispositivo final

40D61A4F 40D619DF
A continuación se procederá a descargar [36] e instalar el software XCTU, el cual permite configurar
fácilmente y de una forma gráfica los dos módulos necesarios. Una vez conectado el dispositivo a través del
XBee explorer y un cable mini-USB, se procede a reconocer el módulo a través de XCTU. Se le debe indicar
la tasa de transmisión, por defecto a 9600 baudios, el resto de campos no deben ser modificados tal y como
aparece en la Figura 3.2. De esta forma, el software intentará reconocer en el puerto correspondiente alguno
de los módulos compatibles.
Figura 3.2 Búsqueda de módulo XBee en XCTU.
Una vez finalizada la búsqueda, XCTU imprimirá en el panel izquierdo el tipo de dispositivo conectado, su
función, el puerto, la velocidad y su dirección MAC. A continuación y tal y como se puede observar en la
Figura 3.3, se configurará el coordinador de red.
Figura 3.3 Vista de la conexión del módulo ZigBee en XCTU.

3.1 Configuración de los equipos 25
En el panel derecho se encuentran cada uno de los parámetros de configuración del dispositivo, entre los
cuales solo se considera necesario modificar:
Tabla 3.2 Valores para la configuración de XBee.
Campo Descripción Valor

PAN ID Identificador de red de área personal (PAN) 4B9
DH Parte alta de la dirección de red. 13A200
DL Parte baja de la dirección de red. 40D619DF
Tasa de transmisión Establece la velocidad de transmisión de interfaz serie entre los dispositivos. 38400 baudios
El identificador de la red se expresa en hexadecimal y tiene un rango de 0 a 0xFFFFFFFFFFFFFFFF,

siendo indiferente el valor elegido mientras dicho campo sea igual para todos los dispositivos de la red. Como
se está configurando el coordinador, éste debe contener la parte baja de la dirección de red de su par (ver
Tabla 3.1).
Figura 3.4 Interfaz de configuración en XCTU.
Una vez que se ha introducido cada uno de los valores de la tabla 3.2 y para finalizar con la configura-
ción de este dispositivo, se reescribe el firmware del módulo XBee desde el botón correspondiente del software.
A continuación se debe proceder de la misma forma con el otro equipo, el cual tendrá el papel de dispositivo
final de la red. Para ello se operará igual que para el coordinador, indicando el mismo identificador de red,
tasa de transmisión y parte alta de dirección de red. De la configuración anterior únicamente difiere la parte
baja de dirección de red, la cual se corresponde al valor indicado en la parte posterior del coordinador (ver
Tabla 3.1).
3.1.2 Configuración del microcontrolador Arduino
IDE
IDE (Integrated Development Environment) es un entorno de programación compuesto por diferentes
herramientas que ayudan a desarrollar determinadas aplicaciones. Se compone de un editor de código fuente,
un compilador, depurador e interfaz gráfica. El desarrollo de esta IDE no sería posible sin el carácter open-
source de la plataforma Arduino. Esta IDE incorpora barra de herramientas, editor de código, terminal de
mensajes del compilador y monitor serie entre otras muchas.
Figura 3.5 Entorno de programación de Arduino.
Para cargar un sketch (software desarrollado para Arduino) en la placa, debe conectarse el dispositivo al
ordenador vía USB tal y como puede apreciarse en la siguiente imagen:
Figura 3.6 Conexión USB entre la placa Arduino y un PC.
Lenguaje de programación
Cada uno de los sketchs de Arduino están basados en los lenguajes de programación C/C++ y en librerías
estándar de este lenguaje (AVR Libc). Una vez que se ejecuta el compilador se convierte el código visual en
instrucciones de lenguaje máquina, combinando el código desarrollado con las distintas librerías utilizadas. El
resultado de esta operación es un único archivo hexadecimal que contiene los bytes que necesitan ser escritos en
la memoria del chip ATmega328P, los cuales son transmitidos a través de una conexión USB o serial a la placa.
El código básico de un sketch está dividido en dos funciones principales, setup() y loop(). La primera
es llamada una única vez al comienzo del sketch, siendo el lugar donde se deben inicializar los pines de la
placa, librerías y algunas variables determinadas. La función loop() es el corazón del sketch y se ejecuta en
bucle indefinidamente una vez que se ha llamado a setup(), controlando y operando sobre las distintas salidas
digitales y analógicas del Arduino.
A continuación se muestra un ejemplo básico, donde se controla el parpadeo de un LED conectado al pin
número 13 de la placa. En él puede apreciarse como se inicializa el pin 13 como salida y se manda un pulso a
nivel alto y bajo cada segundo a través de la función digitalWrite().
Figura 3.7 Ejemplo básico en Arduino. Parpadeo de un LED.
Sensores monitorizados
Como ya se ha comentado en apartados anteriores, el diseño del sistema de telemetría tiene el objetivo de
prevenir daños irreversibles en el monoplaza, así como conocer en tiempo real otra serie de parámetros
adicionales que puedan ayudar a realizar un mejor set-up del coche y mejorar el pilotaje.
Debido a la baja tasa de transmisión de nuestro sistema, existe un mayor interés en monitorizar pocas medidas
a alta frecuencia de muestreo que tener un mayor número de parámetros con un desfase grande. Esto se debe
a que es necesario que parámetros críticos como la temperatura lleguen al instante, pues el retraso de unos
segundos puede provocar problemas graves en el motor.
En la tabla que se muestra a continuación se puede apreciar el tipo de medida y función utilizada para
cada uno de los sensores monitorizados:
Tabla 3.3 Sensores monitorizados por telemetría.
Elemento del motor Función Arduino

Temperatura del agua (ECT o Engine Coolant Temperature) getEngineCoolantTemp()
Temperatura del aire de admisión (IAT o Intake Air Temperature) getIntankeAirTemp()
Revoluciones getEngineRPM()
Sensor de velocidad getVehicleSpeed()
Posición del acelerador (TPS o Throttle Position Sensor) getThrottlePosition()
Sketch Arduino
El primer paso para desarrollar un código que tenga la capacidad de recibir y leer correctamente datos del
can BUS, ha sido el de buscar una librería compatible con la placa que pueda llevar a cabo tal acción. Para
ello, se ha importado la librería CAN BUS, de Cooking-Hacks [37]. A través de los identificadores usados en
herramientas de diagnosis de vehículos, llamados OBD-II PIDs (On-board diagnostics Parameter PIDs), la
librería realiza una operación básica en cada caso. De esta forma, una vez que se llama a cualquiera de las
funciones de la tabla 3.3, se utiliza el identificador correspondiente para capturar el valor actual de dicho
parámetro del bus CAN. Pueden observarse todas las operaciones realizadas en la siguiente tabla, siendo A
el valor leído del bus.
Tabla 3.4 OBD-II PIDs de los valores monitorizados.
PID (hex) Bytes devueltos Descripción Valor mínimo Valor máximo Unidades Fórmula
05 1 ECT -40 215 ºC A-40
0C 2 RPM 0 16,383.75 rpm ((A*256)+B)/4
0D 1 Velocidad 0 255 Km/h A
0F 1 IAT -40 215 ºC A-40
((A*256)+B)
11 1 TPS 0 100 %
/ 100
En cada iteración del bucle principal loop() se realizan las llamadas a las funciones de la tabla 3.3 de forma
que se obtengan los valores de cada sensor, almacenando cada parámetro en una variable para posteriormente
poder enviarlos de forma sencilla. Asimismo, se ha considerado la mejor opción y también más sencilla,
construir una cadena JSON con todos los valores almacenados, con el fin de que puedan ser enviados y
recibidos correcta y fácilmente.
JSON (Javascript Object Notation) es un formato para el intercambio de datos, describiéndolos con una
sintaxis dedicada que se usa para identificar y gestionar los datos. Una de sus mayores ventajas es que puede
ser leído por cualquier lenguaje de programación, creando interoperabilidad entre tecnologías. Tal y como se
verá en el próximos apartados, el uso de JSON en el sistema permite que la placa Arduino sea programada en
C/C++ y no haya restricción para el lenguaje utilizado en la otra parte de la comunicación, donde en concreto
se utiliza un script desarrollado en Python para realizar las lecturas. A continuación se muestra un ejemplo
de la estructura de objeto y un array con formato JSON:
Código 3.1 Ejemplo de objeto JSON simple.
Código 3.2 Ejemplo de array JSON.
Finalmente, el código desarrollado para la placa Arduino puede evaluarse en el apéndice C.

3.1.3 Configuración de la centralita
La unidad de control de motor utilizada en el monoplaza es la Link G4+ Storm, de LinkECU© [39] , encargada
de controlar todas las funciones del motor, así como llevar a cabo la lectura de todos los sensores analógicos y
digitales del coche, analizando posteriormente individualmente cada uno de ellos y mostrando la información
en el software propio correspondiente. Además de tener las entradas y salidas suficientes para dar cabida a
todos los elementos necesarios, las funciones indispensables de data logging y bus CAN, se encuentran otras
características interesantes como una alta resolución de los mapas de motor ajustables, características de
calibración de la ignición, combustible y arranque en frío, control de impulso y ralentí, control digital y otras
características adicionales como control de tracción y arranque.
Figura 3.8 Vista frontal de la unidad de control de motor Link G4+ Storm.
LinkECU© ofrece a sus clientes un software personalizado [40] que permite configurar a tiempo real todas
las funciones de la unidad de control de motor adquirida, así como otras características avanzadas tales como
la sintonización automática, análisis de registros de datos y actualizaciones del firmware.
Figura 3.9 Vista previa del software de la ECU.
El objetivo de este proyecto se centra exclusivamente en la configuración del bus CAN, por consiguiente
se procederá a describir el proceso de envío desde la unidad, dejando de lado la configuración del resto de
opciones básicas.
Así pues, desde la configuración del bus CAN del software de la centralita se pueden utilizar varios modos
que vienen por defecto para distintos modelos de coche definidos, además de seleccionar la tasa de bit, el
puerto de salida y personalizar tramas para optimizar la información enviada por el bus. Para este último caso
se han realizado diversas pruebas y se ha comprobado que el comportamiento de la centralita es inestable,
por lo que se procederá a utilizar un modo semiautomático en el que se enviarán aquellos valores que hayan
sido modificados desde el último muestreo.
Figura 3.10 Configuración del bus CAN de la centralita.
De este modo, se obtiene que para un modo personalizado y una velocidad de 125 Kbps, la unidad de
control de motor inyecta al bus aquellos parámetros de sensores que han modificado su valor, alterando
la frecuencia de muestreo para generar solamente el caudal máximo seleccionado. Esto podría llegar a
convertirse en un arma de doble filo, pues aunque son pocos los bytes generados por cada medida, si en algún
momento del tiempo de funcionamiento se sobrepasa el volumen de información máximo, se estaría perdiendo
información. Pese a este inconveniente, se ha priorizado tener un mayor rango de cobertura utilizando una
menor tasa de transmisión, pues en conjunto la calidad del sistema será adecuada para las exigencias del diseño.
Tener una caracterización más visual del conexionado de la unidad de control de motor facilitará el
entendimiento de este apartado, por ello en la tabla 3.5 se muestran los elementos del motor y la entrada/-
salida correspondiente a la que se han sido conectados. Como es lógico, únicamente aquellos dispositivos
configurados como entradas generarán cambios en el can BUS.
3.2 Interfaz de visualización 31
Tabla 3.5 Relación entre elementos del motor y la ECU.
Elemento del motor Entrada/Salida de la ECU

Posición del cigüeñal (CKP o Crankshaft
Trigger 1
position)
Posición del árbol de levas (CMP o Camshaft
Trigger 2
position)
Posición del acelerador (TPS o Throttle Position
Analog Volt 1
Sensor)
Sensor de presión absoluta del colector (MAP o
Analog Volt 2
Manifold Absolute Pressure sensor)
Temperatura del agua (ECT o Engine Coolant
Analog Temp Input 1
Temperature)
Temperatura del aire de admisión (IAT o Intake
Analog Temp Input 2
Air Temperature)
Bujías 1-4 Ignition 1-4
Inyectores 1-4 Injection 1-4
Sensor de velocidad Digital input 1
Bomba de combustible Auxiliary Output 1
Ventilador Auxiliary Output 2
Piloto LED de temperatura de agua Auxiliary Output 3
3.2 Interfaz de visualización
Este apartado trata de esclarecer la implementación de la interfaz del sistema de telemetría llevada a cabo,
explicando cada una de las plataformas que se han tenido en cuenta para su desarrollo y cuál ha sido finalmente
la elegida. Acto seguido se comentará la estructura del back-end y su desarrollo, terminando con la interacción
del usuario con el software o front-end correspondiente.
3.2.1 Entornos de desarrollo
A continuación se procede a explicar cada una de las plataformas o entornos de desarrollo utilizados para el
sistema. Por su larga trayectoria en el sector de la ingeniería, se han probado los softwares de apoyo LabVIEW
y MATLAB, los cuales disponen de extensos manuales y una amplia comunidad de soporte que ayuda en la
elaboración de programas dedicados como el que se va a desarrollar para el sistema de telemetría. Además,
por la experiencia del autor del documento en programación web y por la posibilidad de acceder a una extensa
gama de librerías de código libre, también se va a intentar desarrollar una pequeña página que sirva de base
para la monitorización de medidas del monoplaza.
LabVIEW
LabVIEW es un software de desarrollo de sistemas comercializado por National Instruments [41]. Es un
entorno de desarrollo diseñado específicamente para acelerar la productividad de ingenieros y científicos, con
una sintaxis de programación gráfica que facilita visualizar, crear y codificar sistemas de ingeniería. Durante
décadas, pionero en la creación e implementación de sistemas basados en IoT (Internet of Things).
LabVIEW permite programar a un nivel alto tanto el back-end como el front-end del sistema. Al igual que
en cualquier lenguaje de programación, existen librerías propias que facilitan y agilizan el desarrollo. En
este caso se ha utilizado una que crea una compatibilidad directa entre la placa Arduino y las lecturas por el
puerto serie del ordenador.
En la figura que se muestra a continuación puede apreciarse un ejemplo de las lecturas obtenidas de un
sensor de temperatura LM35 conectado a la placa Arduino en el pin analógico número 2. El microcontrolador
está conectado vía USB al ordenador por el puerto COM5 a una velocidad de 38400 baudios. La lectura
obtenida del pin 2 necesita ser multiplicada por un factor de 100 para obtener un valor decimal correcto, para
posteriormente ser representada.
Figura 3.11 Diagrama de bloques de la lectura de un sensor LM35 con LabVIEW.
Es decir, la interacción con este tipo de microcontroladores es bastante sencilla e intuitiva, aunque no así
el procesado de la información leída, pues habría que realizar un análisis adecuado de la estructura JSON
recibida por el puerto serie. Los bloques de comparación de cadenas que dispone LabVIEW son bastante
simples para la distinción de cada uno de los campos del objeto JSON, factor decisivo para descartar esta
opción como entorno de desarrollo del sistema de telemetría.
A continuación se muestra el prototipo de interfaz de telemetría que se intentó desarrollar con la utilización
de LabVIEW. Se puede contemplar como a través de este software y de una forma muy visual se podría
haber obtenido un resultado más que correcto, teniendo la capacidad de representar pequeños historiales de
medidas y el valor actual de ciertos valores.
Figura 3.12 Interfaz de telemetría con LabVIEW.
Matlab
MATLAB© es el lenguaje de alto nivel y el entorno interactivo utilizado por millones de ingenieros y cien-
tíficos en todo el mundo. Permite explorar y visualizar ideas, así como colaborar interdisciplinarmente en
procesamiento de señales e imagen, comunicaciones, sistemas de control y finanzas computacionales.
Al igual que ocurría con LabVIEW, MATLAB se encarga tanto del front-end como del back-end del sistema.
A través de la herramienta GUIDE (entorno de desarrollo GUI) [42] se proporcionan las herramientas para
diseñar interfaces de usuario para aplicaciones personalizadas. Mediante el editor de diseño de GUIDE, es
posible diseñar gráficamente la interfaz de usuario, generando de manera automática el código de MATLAB
para construir la interfaz, el cual se puede modificar para programar el comportamiento de la aplicación.
GUIDE comprende una gran gama de elementos como botones, sliders, casillas de verificación, representación
de gráficas, texto estático y dinámico, tablas y un largo etcétera.
Por lo tanto, cada elemento utilizado en la interfaz gráfica está asociado a una función (Callback) que
realiza la función programada una vez que el elemento es activado por el usuario. Para la interfaz de telemetría,
sería suficiente con representar el valor actual y un pequeño historial de medidas de cada parámetro recibido,
en un elemento de texto y una gráfica correspondientemente. Además, se ha añadido un pequeño panel para
indicar el puerto serie al que está conectada la placa Arduino y la tasa de transmisión utilizada. El resultado
puede observarse en la siguiente imagen:
Figura 3.13 Interfaz de telemetría con Matlab.
El funcionamiento de esta aplicación es sencillo. Una vez conectado el Arduino al PC y conocido el puerto
y la tasa a la que se recibirán los datos, solamente es necesario pinchar en el botón ‘Inicio’ para ejecutar
el script. La función asociada a dicho botón se encarga de leer del puerto serie a la velocidad indicada,
representando cada muestra en la zona habilitada.
En esta ocasión, al operar a nivel más bajo que LabVIEW, es sencillo programar una función que sea capaz
de analizar una trama JSON, evitando los problemas del entorno de desarrollo anterior.
Como aspecto negativo, se ha encontrado una inestabilidad inadmisible en la ejecución de GUIDE, pues
parece que las funciones Callbacks no están preparadas para soportar un bucle de funcionamiento como al
que se ha visto sometido, lo que provoca el cierre inesperado de la aplicación en la mayor parte de los casos.
Una vez más, es necesario descartar el uso de esta solución debido a que un bloqueo de la interfaz en un
momento inadecuado evitaría la prevención de un contratiempo en el monoplaza.
Aplicación web
Una interfaz web puede llegar a ofrecer las herramientas suficientes para conseguir el objetivo, ordenar
y representar una serie de paquetes que llegan por el puerto serie. A diferencia de LabVIEW y MATLAB,
una aplicación web solo se ocupa del front-end, pues se encarga de la parte visual del usuario y no de la
administración de la lectura o almacenamiento de datos (back-end). Por ello, se necesita algún script o sistema
adicional que se asuma la ejecución de dicha acción.
La mayor ventaja de desarrollar una aplicación web es el hecho de tener infinidad de posibilidades a la
hora de personalizar la interfaz. Una página dinámica puede estar basada en los lenguajes de programación
HTML5, CSS3, PHP5 y Javascript, todos con una extensa documentación que facilita la incorporación de
nuevas y complejas funciones al código, dejando a un lado el hermetismo que pueden llegar a tener los dos
entornos de desarrollo anteriores. Asimismo, en el caso participar de Javascript, existen numerosas librerías
que tienen la capacidad de representar de una forma elegante y sencilla los parámetros recibidos de la placa
Arduino.
Figura 3.14 Ejemplo de gráficas Javascript con Highcharts.
Por otro lado, el back-end de la aplicación web está compuesto principalmente por un script desarrollado
en el lenguaje de programación Python y por una base de datos relacional MySQL. El script tiene la fun-
ción de escuchar por el puerto serie y esperar a las tramas JSON que envía el microcontrolador Arduino,
almacenándolas en el caso de que sean correctas en la base de datos de forma ordenada, para su posterior
representación.
En este caso no se han encontrado problemas de inestabilidad en el funcionamiento de la aplicación, motivo

suficiente para descartar los entornos LabVIEW y MATLAB. Se puede concluir y afirmar que la aplicación
web se convierte así en la opción más interesante para el diseño del sistema de telemetría.
3.2.2 Estructura
Base de datos MySQL
MySQL es un sistema gestor de bases de datos (SGBD, DBMS por sus siglas en inglés) muy conocido y
ampliamente usado por su simplicidad y notable rendimiento. Aunque carece de algunas características
avanzadas disponibles en otros SGBD del mercado, es una opción atractiva tanto para aplicaciones comercia-
les, como de entretenimiento precisamente por su facilidad de uso y tiempo reducido de puesta en marcha.
Esto y su libre distribución en Internet bajo licencia GPL le otorgan como beneficios adicionales (no menos
importantes) contar con un alto grado de estabilidad y un rápido desarrollo.
Para poder trabajar con esta base de datos relacional, se ha instalado el entorno de desarrollo XAMPP
[44], un servidor local compatible con cualquier plataforma, de software libre y que consiste principalmente
en el sistema de gestión de base de datos MySQL, el servidor web Apache y los intérpretes para lenguajes de
script PHP y Perl. En la figura 3.15 se puede ver el panel de administración de PHPMyAdmin, desde donde
se pueden gestionar las bases de datos MySQL.
Figura 3.15 Vista del panel de administración de PHPMyAdmin.
Una vez creada la base de datos y tabla correspondiente, en este caso llamada telemetría y medidas
respectivamente, se procede a establecer la estructura de la misma tabla. Sencillamente se compone de un
identificador de medida (IdLogMedida), de forma que se puedan tener cada una de las medidas ordenadas
cronológicamente por orden de llegada, de una columna por cada parámetro a almacenar (ECT, IAT, SPEED,
TP y RPM) y una marca de tiempo (time).
Figura 3.16 Estructura de la base de datos.
El campo de identificador de medida tiene carácter autoincremental, es decir, cada vez que se inserta un
conjunto de medidas, este campo toma el siguiente valor entero que último registrado en la tabla. La marca
de tiempo se registra automáticamente con la fecha y momento exacto del instante de la inserción.
API REST de acceso a la base de datos
La Interfaz de Programación de Aplicaciones (Application Programming Interface, API), se encarga de

mantener el diálogo con la base de datos, para poder llevar a cabo el acceso y manipulación de la información.
La función de la API es la de ser el único punto de acceso entre las aplicaciones y la base de datos, de forma
que mediante una simple petición HTML se puede insertar u obtener la información solicitada. El termino
REST (REpresentational State Transfer o transferencia de representación de estado) define un servicio sin
estado, es decir, cada llamada a la aplicación debe contener el estado necesario. La principal ventaja de REST
es que como las peticiones no guardan ningún tipo de sesión, se evitan los problemas de memoria en el servidor.
Tal y como puede apreciarse en la figura 3.17, el script de lectura se encarga de leer por el puerto serie los
datos recibidos por el módulo XBee, momento en el que realiza una petición HTML POST para insertar
la información obtenida en la base de datos a través de la API. A sí mismo, tanto la interfaz de telemetría
como la de data logging (se verá posteriormente) también interactúan con la base de datos a través de la API,
esta vez con una petición HTML GET. Se demuestra así mediante un esquema básico de funcionamiento del
sistema, que la API REST diseñada es el único punto de acceso a la base de datos.
Figura 3.17 Esquema del receptor usando la API REST.
Esta API REST está basada principalmente en el framework Slim [47], el cual proporciona, entre otras
cosas, una potente herramienta para gestionar peticiones HTTP. El framework está programado en lenguaje
PHP y ha sido instalado en el servidor local a través de XAMPP, por lo tanto para acceder a la API solamente
es necesario realizar la petición HTTP a la dirección correspondiente. En la siguiente tabla se muestran las
acciones que han sido consideradas necesarias para la implementación de la API REST.
Tabla 3.6 Acciones y direcciones de la API REST.
Nombre Descripción Dirección

Recibe una trama en formato JSON e inserta cada campo
post http://localhost/api/post
en su lugar correspondiente de la base de datos
get Devuelve,una trama JSON con el contenido de todos los http://localhost/api/get
registros de la base de datos
getLast Devuelve,una trama JSON con el contenido del último http://localhost/api/getLast
registro de la base de datos
El código desarrollado para la API REST puede estudiarse en el apéndice C.2
Script de escritura
Este script tiene el objetivo de mantener una escucha activa al puerto del PC donde se ha conectado el receptor
XBee, realizando una petición POST a la API REST anterior por cada lectura obtenida.
Ha sido desarrollado en el lenguaje de programación Python, apoyándose en el GUI (Graphical User

Interface) TkInter, una de las interfaces gráficas más simples y utilizadas del lenguaje. Su funcionamiento es
bastante similar el de GUIDE de MATLAB, permite incluir en la interfaz ciertos elementos como menús
desplegables, botones simples y cuadros de texto dinámico.
En la figura 3.18 puede observarse la estructura visual del script. En primer lugar es necesario seleccionar
el puerto y la tasa de transmisión en los dos menús de la parte superior. Una vez realizado, únicamente habría
que pulsar el botón Inicio para comenzar la ejecución del script.
El back-end del script es sencillo y está compuesto por tres funciones principales. La primera es lanzada
por el botón Inicio y se encarga de capturar los valores del puerto y velocidad para realizar la lectura
correspondiente del receptor XBee. Una vez que se reciba una trama, se crea un hilo (permite a la aplicación
ejecutar operaciones de forma concurrente en el mismo espacio de proceso) y se llama a la función leer, la
cual realiza la petición POST a la API REST e imprime en el cuadro de texto la trama recibida. Por último,
pulsando el botón Parada se invoca a la función que detiene la ejecución del script.
Figura 3.18 Vista del script de lectura desarrollado con el GUI TkInter.
El código desarrollado para el script de lectura puede estudiarse en el apéndice C.3
Interfaz web
La interfaz web es el front-end de la aplicación, donde se representarán las distintas lecturas generadas por
algunos de los sensores del motor (ver tabla 3.3). Tal y como se explicó en el apartado 3.2.1, está interfaz ha
sido desarrollada en HTML5, CSS3, PHP y Javascript, cada uno cumpliendo una función específica. HTML
(HyperText Markup Language o lenguaje de marcas de hipertexto) es un estándar que sirve de referencia para
la elaboración de la estructura básica y definición de contenido de la interfaz. CSS (Cascading style sheets o
hoja de estilo en cascada) es el lenguaje empleado para diseñar la parte visual del documento estructurado
HTML, a través de una sintaxis muy sencilla y utilizando los identificadores de los bloques del documento,
define los estilos de la página aplicando las reglas aceptadas por el World Wide Web Consortium (W3C) [48].
PHP es un código del lado del servidor originalmente diseñado para el desarrollo web de contenido dinámico,
siendo el encargado de realizar las consultas a la base de datos a través de la API REST del servidor local
XAMPP. Por último, Javascript se utiliza en su forma del lado cliente, automatizando, entre otras cosas, las
gráficas que interpretan las lecturas en tiempo real a través de unas sencillas librerías. Cada una de las partes
del código puede ser meticulosamente revisada en el apéndice C.4
Con el fin de aprovechar los recursos existentes en su totalidad, se ha decidido añadir a la interfaz de
telemetría un área donde se muestran todos los registros almacenados en base de datos, a modo de data
logging. Así pues, una vez el monoplaza haya finalizado la prueba, se podría observar detenidamente y con
calma toda la información generada, teniendo la posibilidad de mejorar los reglajes del coche o incluso la
conducción del piloto desde esta misma interfaz.
Por consiguiente, la propia interfaz está compuesta de dos partes claramente diferencias, una primera en la
que se muestran una serie de gráficas que representan los datos obtenidos del módulo XBee conectado al PC, y
una segunda que expone una tabla dinámica con todos los registros almacenados en base de datos. Para una ma-
yor comodidad y poder aprovechar el ancho de la pantalla, cada una de las partes se mostrará individualmente
en la misma página, pudiendo acceder a la otra a través de una pestaña situada en la parte superior de la interfaz.
Dicha pestaña ha sido programada en el lenguaje de programación Ajax (Asynchronous Javascript And XML).
Telemetría
En primer lugar se ha de mencionar que el diseño ha estado motivado por softwares empleados en el mundo
de la competición. En la figura 3.19 se puede ver como de forma superpuesta y bajo el mismo eje temporal,
se encuentran las lecturas de velocidad (blanco), revoluciones (rojo), posición del acelerador (azul), marcha
(amarillo) y ángulo del volante (morado). Concretamente, la imagen es propia del software Wintax [49],
utilizado en las máximas categorías del automovilismo como F1, DTM, WRC, Le Mans Series, MotoGP y
Superbikes.
Figura 3.19 Telemetría del software de competición Wintax.
La interfaz se ha desarrollado de una forma más simple pero con la misma estructura. En la parte derecha
se pueden contemplar los valores instantáneos de cada una de las medidas, mientras que a su izquierda se
representan las mismas medidas bajo el mismo eje temporal. Este diseño es muy útil si se considera que la
configuración del motor no es ideal y pueden encontrarse desfases e irregularidades entre la posición del
acelerador (TP) y la respuesta del motor en revoluciones y velocidad. De este modo la interfaz también podría
ser de utilidad a la hora de realizar pequeñas modificaciones en los mapas de motor y en los reglajes del
monoplaza. En la imagen que se muestra a continuación se muestra el diseño final de la interfaz.
Figura 3.20 Vista previa de la interfaz de telemetría.
Para la incorporación de las gráficas se ha utilizado la librería Highcharts [50], desarrollada en Javascript,
la cual permite añadir gráficas interactivas en páginas y aplicaciones web de una forma simple. Su punto
fuerte es que permite actualizar las gráficas con un tiempo de refresco bastante pequeño, ofreciendo al usuario
la experiencia de representación en tiempo real. Comprende muchos tipos de representaciones como líneas,
áreas, barras, anillos, superficies, manómetros, burbujas, radiales, además de tablas y ciertas representaciones
dinámicas muy interesantes, aunque para esta interfaz solamente se han utilizado las líneas básicas para
conservar un diseño lo más limpio posible.
Data logging
La segunda parte del front-end del sistema es una tabla dinámica que comprende todos los registros
almacenados en la base de datos. Sus características de ordenación y filtrado convierten a este data logging
en una herramienta útil a la hora de estudiar los parámetros recibidos del monoplaza.
Al igual que ocurría en la parte de telemetría, ésta se basa en otra librería Javascript, DataTables [51].
Esta herramienta ofrece la posibilidad de, a través de una consulta PHP, dibujar una tabla dinámica con
un campo de búsqueda, seleccionar el número de entradas a mostrar y ordenar la tabla en función de la
columna seleccionada. Estas sencillas opciones ofrecen distintas posibilidades a la hora de querer estudiar un
parámetro determinado o un rango acotado en el tiempo.
Figura 3.21 Vista previa de la interfaz de data logging.

3.2.3 Puesta en marcha
Para un mayor entendimiento del proceso y como resumen del capítulo, se va mostrar paso a paso el fun-
cionamiento del sistema de telemetría diseñado. Se suponen todos los equipos configurados y conectados
correctamente, así como la interfaz de telemetría abierta.
En primer lugar, siempre que el monoplaza y por lo tanto la unidad de control de motor estén encendidos,
el bus CAN estará continuamente enviando información de todos aquellos parámetros que han sufrido alguna
modificación desde el último muestreo. Todos los paquetes son recibidos por la placa Arduino del coche, la
cual se encarga de formar una trama JSON con los nuevos parámetros y enviarlos mediante su módulo de
comunicación inalámbrica XBee.
En la parte del receptor, es el otro dispositivo XBee el que captura todos los paquetes enviados por el otro
extremo, aunque en este caso no realiza ningún tipo de alteración de la información, únicamente retransmite
cada una de las tramas hacia el puerto USB al que ha sido conectado. Una vez el script de lectura haya sido
lanzado (adjudicando puerto y tasa correspondientes) realizará una lectura continua del puerto indicado,
almacenando los datos en la base de datos a través de la API REST del servidor local. En el momento que
existan nuevos registros en la base de datos, la interfaz de telemetría irá representando en su eje temporal los
valores de las revoluciones y velocidad del motor, posición del acelerador y temperaturas de agua y aire de
admisión.
Figura 3.22 Esquema global de funcionamiento del sistema.
A continuación se va a suponer un escenario en el que solamente se encuentran monitorizados los sensores

de temperatura y posición del acelerador del monoplaza. Tanto la temperatura del agua como del aire de
admisión permanecen constantes a 25ºC y 30ºC respectivamente, mientras que la posición del acelerador
modifica su valor desde el punto mínimo hasta alcanza el máximo (0º y 100º respectivamente), decrementando
su posición una vez que llega al punto más alto. Esta acción se repite en el tiempo. En la figura 3.23 se puede
observar como el script de lectura captura las tramas JSON enviadas por la ECU del monoplaza.
Figura 3.23 Vista de las tramas JSON recibidas mediante el script de lectura.
Una vez que se almacenan los distintos paquetes en la base de datos, se puede comprobar mediante el data
logging de la interfaz cómo han sido registrados correctamente.
Figura 3.24 Vista de la interfaz de data logging en el escenario supuesto.
Por último, a medida que se van agregando las tramas en la base de datos, los parámetros son representados
en la interfaz de telemetría automáticamente. En la figura 3.25 se puede apreciar como aumenta y disminuye
el valor del TP y como las temperaturas no sufren ninguna alteración.
Figura 3.25 Vista de la interfaz de telemetría en el escenario supuesto.

4 Problemas encontrados y posibles
soluciones
4.1 Unidad de control de motor
El principal problema de nuestro sistema ha sido el bloqueo del puerto del bus CAN de la centralita de motor
durante las pruebas. Se ha considerado una dificultad insuperable, pues por las características de la ECU no
se permite la transmisión de tramas por el bus al mismo tiempo que realiza el almacenamiento y procesado
interno a través de un data logging.
Debido a las circunstancias de preparación del prototipo, solamente se consiguieron realizar algunas
pruebas dinámicas la víspera del día de partida hacia la competición en Alemania, momento en el que se
priorizó el data logging propio de la centralita, pues de esta forma se consigue un mayor nivel de detalle
en la adquisición de datos y por consiguiente mayor información para poder estudiar detenidamente el
comportamiento del monoplaza.
Desafortunadamente, en la competición Formula Student Germany (FSG) el monoplaza ART-15 tuvo

que retirarse debido a un problema en el módulo de encendido, responsable de controlar la duración del
flujo de corriente a través del arrollamiento primario de la bobina de encendido, permitiendo la activación
de las bujías en el instante correcto. Pese a haber conseguido buenos resultados en las pruebas estáticas,
este inesperado problema impidió que el monoplaza pudiera completar siquiera el exigente scrutineering
(inspección técnica previa a las pruebas dinámicas).
Este bloqueo ha provocado que solamente se haya podido probar la funcionalidad del sistema en un estado
estático, donde la telemetría desenvuelve un papel prácticamente inútil.
4.1.1 Solución
No se ha podido encontrar ninguna solución en un periodo tan corto, pues es un inconveniente que trae la
centralita de serie y ni fabricante ni distribuidor tienen solución para habilitar el almacenamiento interno y
transmisión por el bus CAN de forma simultánea. Esto obliga, o a la no utilización del data logging de la
unidad de control de motor, o bien a asociar el sistema de telemetría a otra centralita compatible con bus
CAN, solución que queda propuesta para el próximo prototipo de la escudería.
4.2 Bus CAN
Como ya se mencionó en el apartado 3.1.3, la configuración del bus CAN de la ECU permite la personalización
de las tramas que se transmiten, pudiendo elegir qué parámetro es enviado, en qué orden y qué frecuencia.
Esta herramienta ofrece la posibilidad de enviar solo aquella información que el receptor está esperando,
evitando que en algún momento se llegue al caudal máximo y se pierda información en un periodo acotado.
En la siguiente imagen se observa la interfaz de configuración:
43
44 Capítulo 4. Problemas encontrados y posibles soluciones
Figura 4.1 Configuración de las tramas CAN con PCLink.
Para comprobar la viabilidad de la configuración, se han realizado diversas pruebas con distintas tramas y
frecuencias de muestreo. Para ello, se ha conectado la placa Arduino al bus CAN de la ECU y a su vez al
PC, de forma que se pueda observar el resultado de la operación. Se ha cargado a Arduino un sketch que
devuelve las tramas en formato JSON con los parámetros ECT (Engine Coolant Temperature o temperatura
del refrigerante del motor), EOT (Engine Oil Temperatura o temperatura del aceite del motor), SPEED
(velocidad) y TP (Throttle Position). Debido al estado del motor, solamente se recibirán valores válidos del
sensor de posición de acelerador y de temperatura del agua.
A continuación se van a representar dos pruebas, la primera a la frecuencia de 1 Hz y la segunda a 50 Hz.

Se puede comprobar como a frecuencias bajas el comportamiento de la transmisión es perfecto, incluso en la
figura 4.2 se puede apreciar cómo detecta perfectamente un cambio en la salida del sensor de posición del
acelerador, mientras que la temperatura del agua (tempref) permanece constante a 30 ºC.
En la segunda prueba, en esta ocasión a 50 Hz y tal y como se puede observar en la figura 4.3, el factor
de error es bastante alto, pues se registran medidas erróneas en ambos parámetros. En el caso de ECT, se
obtienen valores en parte aleatorios, pues -15ºC y 2281ºC no son resultados válidos, mientras que la posición
del acelerador no debería ser nula en ningún momento (se configuró el valor mínimo a 9º). Esto es debido a
una mala transmisión o recepción de las tramas, siendo los valores anteriores el resultado de las operaciones
de las fórmulas de la tabla 3.4.
4.2 Bus CAN 45
Figura 4.2 Prueba de funcionamiento del bus CAN a 1 Hz.
Figura 4.3 Prueba de funcionamiento del bus CAN a 50 Hz. En rojo, las tramas erróneas.
46 Capítulo 4. Problemas encontrados y posibles soluciones
4.2.1 Solución
Como no es viable trabajar a frecuencias muy bajas y pese que a 1 Hz la tasa de error era nula, se ha
decidido desechar la posibilidad de personalizar las tramas del bus CAN, optando por la forma automática de
transmisión que permite la ECU. De esta forma se enviarán todos aquellos parámetros configurados como
salida que hayan modificado su valor desde el último periodo, pudiendo no enviar toda la información en
su totalidad debido a la baja tasa de transmisión de los equipos, aunque debido al bajo número de sensores
conectados, esto solo ocurriría en momentos muy puntuales y sin reducir la calidad del sistema. En este
modo automático no se ha detectado ningún fallo de transmisión.
5 Resultados de la competición
Pese a no haber tenido la posibilidad de poner en funcionamiento el sistema de telemetría diseñado, debido
al ya mencionado bloqueo del puerto del bus CAN de la unidad de control de motor, se va a demostrar el
funcionamiento y la utilidad del data logging del monoplaza. De esta forma se puede tener una idea de lo que
sería la monitorización de esta información en tiempo real y a distancia.
En primer lugar, el data logging que se va a mostrar a continuación se corresponde con el de la competición
Formula Student Spain, la cual tuvo lugar del 26 al 30 de agosto de 2015.
Figura 5.1 Data logging de una de las pruebas de la competición Formula Student Spain.
En la imagen anterior se puede apreciar cómo en la parte izquierda se ha representado tanto las revoluciones
del motor, como la posición del acelerador y las temperaturas del aire de admisión y agua de refrigeración.
A la derecha se muestran aquellos parámetros que también pueden ser representados, pues la interfaz es
totalmente personalizable y puede ser ajustada al estudio que se esté llevando a cabo. En la zona inferior de
la figura se distingue la evolución del almacenamiento bajo un eje temporal, pudiendo acotar un sector y
realizar un análisis completo de una porción determinada.
47
48 Capítulo 5. Resultados de la competición
El objetivo del data logging de la centralita es distinto que el del sistema de telemetría, pues mientras el
primero se centra en ofrecer un almacenamiento de la información del motor de una manera precisa para
poder ser estudiada meticulosamente, el segundo se centra en presentar un medio alternativo de seguridad
mediante el que se podrían evitar problemas graves en la mecánica del vehículo. Pese a esta diferencia,
la representación de ambos sistemas es parecida, tal y como se puede comparar entre la imagen anterior
y la figura 3.20. Por consiguiente la interpretación de ambas lecturas es prácticamente idéntica, añadien-
do un factor adicional de simplicidad a la hora de llevar a cabo los ensayos del comportamiento del monoplaza.
A modo de demostrar la respuesta del motor ante variaciones rápidas de la mariposa de admisión, la cual es
accionada directamente a través de acelerador, se va a acotar una zona del data logging anterior y representar
únicamente las revoluciones del motor y la posición del acelerador. El resultado se muestra en la siguiente
figura.
Figura 5.2 Análisis de la respuesta del motor a través del data logging.
Se puede apreciar cómo un cambio brusco en la respuesta del sensor TP provoca una alteración de la
rotación del motor. Por ejemplo, al comienzo de la gráfica se da un estado inicial de 2000 revoluciones
por minuto para una abertura de la mariposa del 80 %, una vez que esta aumenta al 100 % las revoluciones
alcanzan las 8500 vueltas, descendiendo a cero a medida que la mariposa se va cerrando. El comportamiento
se replica de forma idéntica en el resto de la representación, pudiendo concluir que el set-up actual del motor
provoca una respuesta rápida y precisa, aunque quizás el régimen de funcionamiento no sea el ideal, pues
para ocasiones puntuales como la inicial, el motor se encuentra a ralentí cuando la posición del acelerador
está en un punto alto de abertura.
Se pueden realizar estudios similares con otro tipo de sensores, como la presión de la admisión (MAP),
velocidad de rotación del motor o sonda lambda (mide la concentración de oxígeno a la salida del colector
del escape). Todos ellos son parámetros esenciales a la hora de diseñar los mapas de motor que controlan el
comportamiento del monoplaza en los distintos regímenes de funcionamiento, y por consiguiente deben ser
analizados detalladamente en los registros almacenados del data logging o telemetría.
A través de la monitorización remota del sistema de telemetría se podría llegar a conclusiones similares
que con el almacenamiento interno de la ECU, pues aunque no dispone de la frecuencia de muestreo de
49
la unidad de control de motor, en muchos casos es suficiente para realizar ajustes rápidos sin necesidad de
conectar físicamente un PC a la centralita del coche, evitando retrasos innecesarios.
6 Conclusiones y líneas futuras de trabajo
El propósito de este documento ha sido el de desarrollar un sistema de telemetría que sea capaz de monito-
rizar en tiempo real la salida de un conjunto de sensores a través de dispositivos basados en la plataforma
open-source Arduino. Si bien la solución se expone sobre el prototipo ART-15, el resultado de este proyec-
to es perfectamente replicable a cualquier vehículo con unidad de control de motor compatible con el bus CAN.
Sin duda, a la realización del proyecto hay que sumar la satisfacción personal que ha producido el poder
colaborar en el diseño, fabricación y ensamblado de este prototipo, pues se lleva a cabo un importante auto-
aprendizaje sobre tecnologías, nuevas plataformas, materiales, métodos de producción y un esencial manejo
de herramientas. Asimismo, también se ha tenido la oportunidad de mejorar las habilidades comunicativas al
tener que estar en un continuo contacto con empresas, llevar una coordinación dentro del equipo y finalmente
haber tenido que defender el proyecto en la competición alemana ante un exigente jurado.
Pese a haber alcanzado parcialmente el objetivo de este proyecto, por motivos presupuestarios se han
producido numerosos retrasos en el proceso de fabricación del monoplaza, que han impedido probar los
sistemas diseñados a lo largo de un año de trabajo. Por esta razón, se deja para líneas futuras de trabajo probar
en profundidad el correcto funcionamiento y puesta en marcha del diseño del presente proyecto.
Con el fin de definir una evolución natural de este sistema o como extensión del mismo, se considera
importante invertir en algún dispositivo que tenga la capacidad de transmitir a una mayor tasa de bit, sin
reducir la zona de cobertura alcanzada con los módulos XBee Serie 2. Esto será necesario para dar cabida a
nuevos sensores en el sistema, los cuales serán incorporados en el paquete de mejoras del nuevo prototipo.
Asimismo, se deberá solucionar el bloqueo del puerto OBD de la centralita a través de la adquisición de una
nueva ECU o diseñando un controlador que tenga la capacidad de procesar y almacenar la información de los
distintos sensores del monoplaza.
51
Apéndice A
Bus CAN
A lo largo del proyecto se ha mencionado en numerosas ocasiones la utilización del bus CAN de la unidad
control de motor. Para tener un conocimiento global de esta tecnología se ha llevado a cabo un meticuloso
estudio de las características, componentes y forma de envío del bus.
Bus CAN (Controller Area Network) es un protocolo de comunicación en serie desarrollado por Bosch en
los años 80 para el intercambio de información entre unidades de control electrónicas del automóvil, aunque
actualmente ya ha despertado el interés de otros sectores del área de control y automatización industrial.
La robustez del bus CAN se basa en su arquitectura multimaestro. Este sistema permite compartir una gran
cantidad de información entre los diferentes módulos de control conectados a la red, lo que produce una
reducción importante tanto del número de sensores utilizados como de la cantidad de cables que componen
la instalación eléctrica. De esta forma aumentan considerablemente las funciones actuales en los sistemas del
automóvil donde se emplea el CAN Bus sin aumentar los costes, además de que estas funciones pueden estar
repartidas entre dichos módulos de control.
Figura A.1 Módulos conectados mediante BUS CAN..
A.1 Características principales del bus CAN
• La información que circula entre las unidades de mando a través de los dos cables (bus) son paquetes
de bits con una longitud limitada y con una estructura definida de campos.
• Uno de los campos actúa de identificador del tipo de dato que se transporta, de la unidad de mando
que lo trasmite y de la prioridad para trasmitirlo respecto a otros. El mensaje no va direccionado a
53
54 Capítulo A. Bus CAN
ninguna unidad de mando en concreto, cada una de ellas reconocerá mediante este identificador el
mensaje que le interesa.
• Todas las unidades de la red pueden ser trasmisoras y receptoras, y el número de módulos conectados
a la red es variable.
• Cualquier módulo introduce un mensaje en el bus con la condición de que esté libre, si otra lo intenta
al mismo tiempo el conflicto se resuelve por la prioridad del mensaje indicado por el identificador del
mismo.
• El sistema está dotado de una serie de mecanismos que aseguran que el mensaje es trasmitido y recibido
correctamente. Cuando un mensaje presenta un error, es anulado y vuelto a trasmitir de forma correcta
(automáticamente), de la misma forma un módulo con problemas avisa a los demás mediante el propio
mensaje, sila situación no se soluciona, este módulo queda fuera de servicio pero el sistema sigue
funcionando.
A.2 Protocolo de enlace de datos

Consta de un gran número de bits enlazados. La cantidad de bits de un protocolo depende del tamaño del
campo de datos. En la figura se muestra la estructura de un protocolo de enlace de datos. Es idéntico en
ambos cables del bus.
Figura A.2 Estructura de la trama..
• El campo de comienzo de trama marca el comienzo del protocolo de enlace de los datos. En el cable
CAN-High se transmite un bit con aprox. 5 voltios (en función del sistema) y en el cable CAN-Low se
transmite un bit con aprox. 0 voltios.
• El campo de estado define la prioridad del protocolo. Si, por ejemplo, hay dos unidades de control que
intentan transmitir simultáneamente su protocolo de datos, se concede la preferencia al protocolo de
prioridad superior.
• En el campo de control se especifica la cantidad de información que está contenida en el campo de
datos. De esa forma, cada receptor puede revisar si ha recibido la información completa.
• En el campo de datos se transmite la información para las demás unidades de control.
• El campo de verificación sirve para detectar fallos en la transmisión.
A.3 Capas 55
• En el campo de confirmación los receptores señalizan al transmisor, que han recibido correctamente el
protocolo de enlace de datos. Si detectan cualquier fallo, informan de inmediato al transmisor. A raíz
de ello, el transmisor repite su transmisión.
• Con el campo de fin del trama finaliza el protocolo de datos. Es la última oportunidad posible para dar
un aviso de error, que conduzca a una repetición.
A.3 Capas
Capa física
La capa física es responsable de la transferencia de bits entre los distintos módulos que forman la red. De-
fine aspectos como niveles de señal, codificación, sincronización y tiempos en que los bits se transfieren al bus.
Capa de enlace
El método de acceso al medio utilizado en bus CAN resuelve la colisión de varias tramas, con la supervivencia
de la trama a la que se ha identificado como de mayor prioridad.
A.4 Elementos que componen el bus CAN
Cables
La información circula por dos cables trenzados que unen todos los módulos que forman el sistema. Esta
información se transmite por diferencia de tensión entre los dos cables, de forma que un valor alto de tensión
representa un 1 y un valor bajo de tensión representa un 0. La combinación adecuada de unos y ceros forman
el mensaje a transmitir. En un cable los valores de tensión oscilan entre 0V y 2.25V, por lo que se denomina
cable L (Low) y en el otro, el cable H (High) lo hacen entre 2.75V. y 5V. En caso de que se interrumpa la
línea H o que se derive a masa, el sistema trabajará con la señal de Low con respecto a masa, en el caso de
que se interrumpa la línea L, ocurrirá lo contrario. Esta situación permite que el sistema siga trabajando con
uno de los cables cortados o comunicados a masa, incluso con ambos comunicados también sería posible el
funcionamiento, quedando fuera de servicio solamente cuando los dos cables se cortan. Es importante tener
en cuenta que el trenzado entre ambas líneas sirve para anular los campos magnéticos, por lo que no se debe
modificar en ningún caso ni el paso ni la longitud de dichos cables.
Figura A.3 Línea CAN.
Elementos de cierre o terminadores

Son resistencias conectadas en los extremos de los cables H y L. Sus valores son habitualmente 120 Ohmios
(aunque pueden variar) y se colocan para adecuar el funcionamiento del sistema a diferentes longitudes de
cables y número de módulos conectados, ya que impiden posibles efectos parásitos que nos pueden trastocar
el mensaje. Estas resistencias las colocamos en la mismísima placa del módulo, para así ahorrar en soluciones
externas y para mayor seguridad de funcionamiento.
Figura A.4 Resistencias de cierre.
Controlador
Es el elemento encargado de la comunicación entre el microprocesador del módulo y el trasmisor-receptor.
Trabaja acondicionando la información que entra y sale entre ambos componentes. Habrá un controlador por
cada módulo de nuestra red. Este elemento trabaja con niveles de tensión muy bajos y es el que determina la
velocidad de trasmisión de los mensajes, que será más o menos elevada dependiendo de nuestra aplicación y
lo que esperemos de ella. El controlador también interviene en la sincronización entre los diferentes módulos
para la correcta emisión y recepción de los mensajes.
Figura A.5 Ubicación del controlador.
Transceptor
El transceptor es el elemento que tiene la misión de recibir y de trasmitir los datos, además de acondicionar y
preparar la información para que pueda ser utilizada por los controladores. Esta preparación consiste en situar
los niveles de tensión de forma adecuada, amplificando la señal cuando la información se vuelca en la línea y
reduciéndola cuando es recogida de la misma y suministrada al controlador. El transceptor es básicamente un
circuito integrado que está situado en cada una de los módulos, trabaja con intensidades próximas a 0.5 A y
en ningún caso interviene modificando el contenido del mensaje. Para su buen funcionamiento se sitúa entre
los cables que forman la línea CAN Bus y el controlador.
Figura A.6 Ejemplo de un módulo.

A.5 Ejemplo funcional del bus CAN 57
A.5 Ejemplo funcional del bus CAN
Figura A.7 Ejemplo práctico de CAN.
Los módulos que se conectan al sistema bus CAN son los que necesitan compartir información, pertenezcan
o no a un mismo sistema. Por ejemplo, si hablamos de coches, cabría decir que la velocidad de transmisión
de los datos del ABS deberían ser muy rápidos por lo importante que supone la información utilizada y sin
embargo la del climatizador no haría falta tener una línea muy rápida ya que el muestreo se puede hacer más
pausadamente. El sistema bus CAN está orientado hacía el mensaje y no al destinatario. La información en la
línea es transmitida en forma de mensajes estructurados en la que una parte del mismo es un identificador
que indica la clase de dato que contiene. Todos los módulos reciben el mensaje, lo filtran y solo lo emplean
las que necesitan dicho dato. Como se supone, todos los módulos conectados al sistema son capaces tanto
de introducir como de recoger mensajes de la línea. Cuando el bus está libre cualquier módulo conectado
puede empezar a transmitir de nuevo. En el caso de que uno o varios módulos quieran introducir un mensaje
al mismo tiempo, lo hará la que tenga una mayor prioridad. Esta prioridad nos la indica el identificador. El
proceso de trasmisión de datos se desarrolla siguiendo varios pasos:
• Suministro de datos. Un módulo recibe información de los sensores que tiene asociados (RPM de
un motor, velocidad, temperatura del motor, puerta abierta, en nuestro caso botones, etcétera) Su
microprocesador pasa la información al controlador donde es gestionada y preparada para a su vez ser
pasada al transceptor donde se traducirá en señales eléctricas.
• Transmisión de datos. El controlador de dicho módulo transfiere los datos y el identificador junto con
la petición de inicio de trasmisión, asumiendo la responsabilidad de que el mensaje sea correctamente
transmitido a todas los módulos de la red. Para transmitir el mensaje ha tenido que encontrar el bus
libre, y en caso de conflicto con otro módulo intentando transmitir al mismo tiempo, tener una prioridad
mayor. A partir del momento en que esto ocurre, el resto de módulos se convierten en receptores.
• Recepción del mensaje. Cuando todos los módulos reciben el mensaje, verifican el identificador para
determinar si el mensaje va a ser utilizado por ellos. Los módulos que necesiten los datos del mensaje
lo procesan, si no lo necesitan, el mensaje se ignora. El sistema bus CAN dispone de mecanismos para
detectar errores en la trasmisión de mensajes, de forma que todos los receptores realizan un chequeo
del mensaje analizando una parte del mismo, llamado campo CRC. Otros mecanismos de control se
aplican en los emisores que mirarán el nivel del bus, la presencia de campos de formato fijo en el
mensaje (verificación de la trama), análisis estadísticos por parte de los módulos de sus propios fallos,
etcétera. Estas medidas hacen que las probabilidades de error en la emisión y recepción de mensajes
sean muy bajas, por lo que es un sistema extraordinariamente seguro. El planteamiento del bus CAN,
como puede observarse, permite disminuir notablemente el cableado de nuestra utilidad, puesto que si
un módulo dispone de una información, como por ejemplo, la temperatura ambiente, esta puede ser
utilizada por el resto de módulos sin que sea necesario que cada una de ellos reciba la información de
ese sensor de temperatura. Otra ventaja palpable es que las funciones pueden ser repartidas entre los
distintos módulos para que así si necesitamos más funciones no nos supone un problema económico
importante.
Apéndice B
Datasheets
59
60 Capítulo B. Datasheets
B.1 ATmega328P
Datasheet completo [53]

B.2 XBee Pro S2B 61
B.2 XBee Pro S2B

B.2 XBee Pro S2B 63

B.3 MCP2515 65
B.3 MCP2515

B.4 MCP2551
MCP2551
High-Speed CAN Transceiver
Features Package Types
• Supports 1 Mb/s operation
• Implements ISO-11898 standard physical layer PDIP/SOIC
requirements
• Suitable for 12V and 24V systems TXD 1 8 RS
• Externally-controlled slope for reduced RFI
emissions VSS 2 7 CANH
• Detection of ground fault (permanent Dominant)
on TXD input VDD 3 6 CANL
• Power-on Reset and voltage brown-out protection RXD 4 5 VREF
• An unpowered node or brown-out event will not
disturb the CAN bus
• Low current standby operation
• Protection against damage due to short-circuit
conditions (positive or negative battery voltage)
• Protection against high-voltage transients
• Automatic thermal shutdown protection
• Up to 112 nodes can be connected
• High-noise immunity due to differential bus
implementation
• Temperature ranges:
- Industrial (I): -40°C to +85°C
- Extended (E): -40°C to +125°C
Block Diagram
VDD
TXD Thermal
Dominant Shutdown
VDD Detect
TXD Driver
Control
Slope Power-On CANH

RS
Control Reset
0.5 VDD
RXD GND
CANL
Reference Receiver
VREF
Voltage
VSS
2010 Microchip Technology Inc. DS21667F-page 1

Apéndice C
Código fuente
C.1 Arduino
Sketch importado a la placa Arduino utilizada en el presente proyecto. Invocando a las funciones de la tabla
3.3 es capaz de obtener el valor actual de cada uno de los parámetros solicitados. Posteriormente construye y
envía una trama JSON con el valor de cada uno de los sensores monitorizados.
#include <CAN.h>
#include <SPI.h>
// Se crea una instancia de la clase CAN

CAN myCAN = CAN();
void setup () {
// Se inicializa la comunicación serial
Serial . begin(38400);
// Se configura el can BUS a 125 Kbps

myCAN.begin(125);
}
void loop () {
// En cada iteraci ón del bucle se obtienen las medidas

// correspondientes a monitorizar
int ECT = myCAN.getEngineCoolantTemp();
int TP = myCAN.getThrottlePosition () ;
int IAT = myCAN.getIntankeAirTemp();
int RPM = myCAN.getEngineRPM();
int SPEED = myCAN.getVehicleSpeed();
// A continuaci ón se construye y envía una cadena JSON

// con los valores le ídos del bus.
String resultado = "";
resultado += "{ \" ECT\": \"";

resultado += String (ECT);
resultado += "\", \" IAT\": \"";
resultado += String (IAT);
resultado += "\", \" SPEED\": \"";
resultado += String (SPEED);
resultado += "\", \" RPM\": \"";
resultado += String (RPM);
67
68 Capítulo C. Código fuente
resultado += "\", \" TP\": \"";

resultado += String (TP);
resultado += "\" }";
Serial . println ( resultado ) ;
C.2 API Rest
C.2.1 index.php
Este archivo comprende el cuerpo principal de la API REST. Contiene las rutas de todos los métodos
desarrollados.
<?php
// Se importan las funciones del framework
require ’Slim/Slim.php’;
\Slim\Slim :: registerAutoloader () ;
// Se inicializa la aplicaci ón Slim

$app = new \Slim\Slim() ;
// Se definen los modos de funcionamiento
// GET: Obtener todas las medidas

$app >get(’/get ’, function () use($app) {
include (’ get .php’) ;
}
);
// GET: Obtener última medida

$app >get(’/ getLast ’, function () use($app) {
include (’ getLast .php’) ;
}
);
// POST: Insertar una medida

$app >post(’/post ’, function () use($app){
include (’ post .php’) ;
}
);
// Se lanza la aplicaci ón
$app >run();
C.2.2 connect.php
Este archivo contiene la variable necesaria para establecer la conexión con la base de datos.
<?php
// Variable que indica los datos de conexión a la base de datos
$mysqli = mysqli_connect (’127.0.0.1’, ’ root ’, ’’, ’ telemetria ’) or die (’ error : fallo de conexion ’) ;
?>
C.2 API Rest 69
C.2.3 get.php
Este script PHP comprende uno de los métodos GET de la API REST del servidor local. Realizando la
petición correspondiente se obtienen todas las medidas almacenadas en la base de datos.
<?php
// Se importa la variable de conexión

include _once(’connect .php’) ;
// Se realiza la consulta a la tabla "medidas"

$data = array () ;
$sql = "SELECT FROM medidas";
$ result = mysqli_query($mysqli , $sql ) ;
$numrows=mysqli_num_rows($result);
if ($numrows>0){
$data = array (
" result " => "ok",
" additionalInfo " => "",
"countReadings" => $numrows);
$ lecturas = array () ;
// Se construye la trama JSON

for ($ i=0; $i<$numrows; $i++){
$row=mysqli_fetch_array($ result , MYSQLI_NUM);
$ lectura = array (
"idLogMedida" => $row[0],
"ECT" => $row[1],
"IAT" => $row[2],
"SPEED" => $row[3],
"TP" => $row[4],
"RPM" => $row[5],
"time" => $row[6]
);
array _push($ lecturas , $ lectura ) ;
}
// Se guarda y envía la trama JSON
$data [" lecturas "]=$ lecturas ;
echo json_encode($data) ;
} else {
echo "no he encontrado nada";
}
?>
C.2.4 getLast.php
Este script PHP comprende uno de los métodos GET de la API REST del servidor local. Realizando la
petición correspondiente se obtiene la última medida almacenada en la base de datos.
<?php

// Se obtiene la última medida insertada en la tabla

$sql = "SELECT FROM medidas ORDER BY idLogMedida DESC LIMIT 1";
$numrows=mysqli_num_rows($result);
if ($numrows>0){
// Se construye la trama JSON

$row=mysqli_fetch_array($ result , MYSQLI_NUM);
$ lectura = array (
"idLogMedida" => $row[0],
"ECT" => $row[1],
"IAT" => $row[2],
"SPEED" => $row[3],
"TP" => $row[4],
"RPM" => $row[5],
"time" => $row[6]
);
// Se devuelve el resultado de la operaci ón

echo json_encode($ lectura , JSON_NUMERIC_CHECK);
} else {
echo "No se han encontrado resultados ";
}
?>
C.2.5 post.php
Este script PHP comprende el método POST de la API REST del servidor local.
<?php

// Se obtiene los parámetros a insertar

$reading = json_decode($app >request >getBody());
// Se realiza la inserci ón de cada uno de los campos automáticamente

$sql = "INSERT INTO medidas(";
$sql2 = ") VALUES(";
$ jsonIterator = new RecursiveIteratorIterator (new RecursiveArrayIterator ($ reading ) ,

RecursiveIteratorIterator :: SELF_FIRST);
foreach ($ jsonIterator as $key => $val) {

$sql = $sql ."$key ,";
$sql2 = $sql 2."’$ val ’,";
}
$sql = rtrim ($ sql , ",") ;
$sql2 = rtrim ($ sql 2, ",") ;
$sql = $sql .$ sql 2.") ";
$data = array (
" result " => "",
" additionalInfo " => "") ;

$ affected _rows = mysqli_ affected _rows($mysqli) ;
if ($ affected _rows>0){
$data [" result "] = "ok";
} else {
$data [" result "] = " error ";
$data [" additionalInfo "] = "No se ha podido insertar la medida: ". mysqli_ error ($mysqli) ;
}
C.3 Script de lectura Python 71
// Se devuelve el resultado de la operaci ón

echo json_encode($data) ;
?>
C.3 Script de lectura Python
C.3.1 interfazSerial.py
Script desarrollado en Python que se encarga de leer por el puerto serie de las tramas enviadas por el módulo
XBee. Para más información, consultar el apartado 3.2.2.
#Se importa todos los paquetes necesarios para la ejecuci ón del script
from Tkinter import
import serial #Import Serial Library
import pycurl
from urllib import urlencode
import time
import threading
#Se crea el objeto principal del GUI

root = Tk()
#Tí tulo del script

root . title (" Telemetria ARUS")
# Variables auxiliares
var1 = StringVar ()
var2 = StringVar ()
#Menús desplegables con las opciones del puerto y tasa de transmisi ón

opt1 = OptionMenu(root, var 1, ’COM1’, ’COM2’, ’COM3’,’COM4’,’COM5’,’COM6’,’COM7’,’COM8’)
opt2 = OptionMenu(root, var 2, ’9600’, ’38400’, ’115200’)
#Ubicación en la interfaz de los menús anteriores

opt 1.pack( side=TOP, fill =X)
opt 2.pack( side=TOP, fill =X)
#Mensaje de los menús

var 1. set (’ Seleccionar puerto ’)
var 2. set (’ Seleccionar velocidad ’)
bandera_ inicio = 0
puerto = ""
velocidad = 0
threads = list ()
# inicio () se encarga de captura los valores de los menús,

# lee del puerto serie indicado y crea un hilo llamando a la
# función leer () . Es activada cuando se pincha el botón Inicio
def inicio () :
global bandera_ inicio
bandera_ inicio = 1
puerto = var 1. get ()
velocidad = var 2. get ()
arduinoSerialData = serial . Serial ( puerto , velocidad )
t = threading .Thread( target =leer , args=( arduinoSerialData ,) )

threads . append(t )
t . start ()
# parada () bloquea el funcionamiento del script

# Es activada cuando se pincha el botón Parada
def parada () :
global bandera_ inicio
bandera_ inicio = 0
# leer () recibe los datos recibidos por el puerto serie y los

# imprime en el cuadro de texto . Posteriormente realiza una
# petici ón POST a la API REST.
def leer ( arduinoSerialData ) :
if bandera_ inicio == 1:
lectura = arduinoSerialData . readline ()
print lectura
T. insert (’1.0’, lectura )
c = pycurl . Curl ()
c . setopt (c .URL, ’http :// localhost / telemetria / api / post ’)
c . setopt ( pycurl .HTTPHEADER, [’Accept: application/json’])
c . setopt (c .POSTFIELDS, lectura)
c .perform()
c . close ()
root . after (500, leer ( arduinoSerialData ) )
#Se crea una barra de herramientas para los dos botones

toolbar = Frame(root)
b = Button( toolbar , command=inicio, text =’ Inicio ’)

b.pack( side=LEFT)
b = Button( toolbar , command=parada, text=’Parada’)
b.pack( side=LEFT)
#Se carga la barra

toolbar .pack( side=TOP, fill =X)
s = Scrollbar ( root )
T = Text ( root )
T.focus_set ()
s . pack( side=RIGHT, fill=Y)
T.pack( side=LEFT, fill =Y)
s . config (command=T.yview)
T. config (yscrollcommand=s.set)
#Se lanza la aplicaci ón

root . mainloop()
C.4 Interfaz web
C.4.1 index.php
Este archivo comprende la estructura HTML general de la interfaz. Se importan las librerías y se establecen
las funciones necesarias para lanzar las gráficas del paquete HighCharts y las tablas dinámicas de dataTables.
<!DOCTYPE html>
<html class ="no js" lang="en" >
C.4 Interfaz web 73
<! Cabecera de la interfaz . En este lugar se importarán la hoja

de estilos y las librer í as Javascript . También de declarar án los
distintos scripts desarrollados >
<head>
<meta charset ="utf 8">
<meta name="viewport" content="width=device width, initial scale=1.0">

< title >Telemetría ARUS</title>
<link rel =" stylesheet " type=" text / css" href=" style . css">
< script src="js / jquery 2.1.4.min. js "></ script >

< script src="js / highcharts . js "></ script >
< script src="js / highcharts more.js"></ script >
< script src="js /modules/exporting . js "></ script >
< script >
var chart ;
var chartRPM;
/
requestRPM solicita cada décima de segundo al archivo ’ rpmdirecto .php’
el valor de las revoluciones del motor. Actualiza el valor como texto
y lo representa en la grá fica correspondiente .
/
function requestRPM(){
$. ajax ({
url : ’ rpmdirecto .php’,
success : function ( point ) {
var series = chartRPM.series [0],
shift = series . data . length > 100;
// Añade el punto
chartRPM.series [0]. addPoint( point , true , shift ) ;
document.getElementById(’panelRPM’).innerHTML=point[1];
// Vuelve a llamar a la función
setTimeout(requestRPM, 100);
},
cache: false
}) ;
}
/
Función que representa un historial con los valores obtenidos
de las revoluciones de motor.
/
$(document).ready( function () {
chartRPM = new Highcharts.Chart({
chart : {
renderTo: ’RPM’,
defaultSeriesType : ’ spline ’,
events : {
load : requestRPM
}
},
title : {
text : ’’
},
xAxis: {
type : ’ datetime ’,
tickPixelInterval : 150,
maxZoom: 20 1000
},
yAxis: {
minPadding: 0.2,
maxPadding: 0.2,
title : {
text : ’RPM’,
margin: 20
}
},
series : [{
name: ’RPM’,
data : []
}]
}) ;
})
var chartSPEED;
/
requestSpeed solicita cada décima de segundo al archivo ’ speeddirecto .php’
el valor de la velocidad de motor. Actualiza el valor como texto
y lo representa en la grá fica correspondiente .
/
function requestSpeed () {
$. ajax ({
url : ’ speeddirecto .php’,
var series = chartSPEED.series [0],
// Añade el punto
chartSPEED.series [0]. addPoint( point , true , shift ) ;
document.getElementById(’panelSPEED’).innerHTML=point[1];
setTimeout( requestSpeed , 100);
},
cache: false
}) ;
}
/
de la velocidad de motor.
/
chartSPEED = new Highcharts.Chart({
chart : {
renderTo: ’speed ’,
events : {
load : requestSpeed
}
},
title : {
text : ’’
},
xAxis: {
maxZoom: 20 1000
C.4 Interfaz web 75
},
yAxis: {
minPadding: 0.2,
maxPadding: 0.2,
title : {
text : ’Speed’,
margin: 20
}
},
series : [{
name: ’Speed’,
data : []
}]
}) ;
})
/
requestTP solicita cada décima de segundo al archivo ’ tpdirecto .php’
el valor del sensor de posici ón del acelerador . Actualiza el valor
como texto y lo representa en la grá fica correspondiente .
/
function requestTP () {
$. ajax ({
url : ’ tpdirecto .php’,
var series = chart . series [0],
// Añade el punto
chart . series [0]. addPoint( point , true , shift ) ;
document.getElementById(’panelTP’).innerHTML=point[1];
setTimeout(requestTP , 100);
},
cache: false
}) ;
}
/
del sensor de posici ón del acelerador .
/
chart = new Highcharts . Chart({
chart : {
renderTo: ’ tp ’,
events : {
load : requestTP
}
},
title : {
text : ’’
},
xAxis: {
maxZoom: 20 1000
},
yAxis: {
minPadding: 0.2,
maxPadding: 0.2,
title : {
text : ’TP’,
margin: 20
}
},
series : [{
name: ’TP’,
data : []
}]
}) ;
}) ;
var chartTemp; // global

/
requestTemp solicita cada décima de segundo al archivo ’ temperaturadirecto .php’
el valor de las temperaturas de agua y aire de admisión. Actualiza el valor como
texto y lo representa en la grá fica correspondiente .
/
function requestTemp() {
$. ajax ({
url : ’ temperaturadirecto .php’,
var series = chartTemp. series [0],
// Añade la temperatura de agua

chartTemp. series [0]. addPoint( point [0], true , shift ) ;
document.getElementById(’tempECT’).innerHTML=point[0][1];
// Añade la temperatura de aire de admsión
chartTemp. series [1]. addPoint( point [1], true , shift ) ;
document.getElementById(’tempEOT’).innerHTML=point[1][1];

setTimeout(requestTemp, 100);
},
cache: false
}) ;
}
/
de las temperaturas del agua y del aire de admisión.
/
chartTemp = new Highcharts . Chart({
chart : {
renderTo: ’ temperatura ’,
events : {
load : requestTemp
}
},
colors : [’#0000FF’, ’#FE0000’],
title : {
text : ’’
},
xAxis: {
maxZoom: 20 1000
C.4 Interfaz web 77
},
yAxis: {
minPadding: 0.2,
maxPadding: 0.2,
title : {
text : ’Temperature ( o¯ C) ’,
margin: 20
}
},
series : [{
name: ’ECT’,
data : []
},
{
name: ’EOT’,
data : []
}]
}) ;
}) ;
/
La función activarTab permite darle la funcionalidad correcta a la pesta ña
superior de la interfaz . Pinchando en cualquier de ellas , muestra u oculta
el contenido correspondiente .
/
function activarTab (unTab) {
try {
var id = unTab.id ;
if ( id ){
var tr = unTab.parentNode || unTab.parentElement;

var tbody = tr .parentNode || tr . parentElement;
var table = tbody.parentNode || tbody.parentElement;
if ( table . getAttribute (" data filas ")!= null ){

var filas = tbody.getElementsByTagName("tr");
var filaDiv = filas [ filas . length 1];
tbody. insertBefore ( tr , filaDiv ) ;
}
var desde = table . getAttribute (" data min");

if (desde==null) desde = 0;
var hasta = table . getAttribute (" data max");
if ( hasta ==null) hasta = MAXTABS;
var idTab = id . split (" tabck ");
var numTab = parseInt (idTab [1]) ;
var esteTabDiv = document.getElementById("tabdiv " + numTab);

for ( var i=desde; i<=hasta; i++) {
var tabdiv = document.getElementById("tabdiv " + i ) ;
if ( tabdiv ) {
var tabck = document.getElementById("tabck " + i) ;
if ( tabdiv . id == esteTabDiv. id ) {
tabdiv . style . display = "block ";
tabck . style . color = " slategrey ";
tabck . style .backgroundColor = "rgb(235, 235, 225)";
tabck . style .borderBottomColor = "rgb(235, 235, 225)";
} else {
tabdiv . style . display = "none";
tabck . style . color = "white ";
tabck . style .backgroundColor = "gray ";
tabck . style .borderBottomColor = "gray ";

}
}
}
}
} catch (e) {
alert (" Error al activar una pesta ña. " + e .message);
}
};
/
Esta pequeña función javascript habilita la tabla de data logging .
/
$(’# data ’) .DataTable() ;
} );
</ script >
<! Hoja de estilo de dataTables >

<link rel =" stylesheet " type=" text / css" href="DataTables 1.10.7/media/css / jquery . dataTables . css">
<! Se importan las librer í as de dataTables >

< script type=" text / javascript " charset ="utf8" src="DataTables 1.10.7/media/ js / jquery . dataTables . js
"></ script >
</head>
<! En este punto comienza el cuerpo de la interfaz >

<body>
<! Es necesaria la creaci ón de una tabla que contenga el contenido de la interfaz de telemetr ía
y data logging
en celdas distintas . De este modo se puede mostrar un contenido u otro en función de la pesta ña
>
<table class ="tabs" data min="0" data max="2">
<tr>
<th class ="tabcks"> </th>
<th class ="tabck" id="tabck 0" onclick=" activarTab ( this )" style ="color : rgb(112, 128, 144);
border bottom color: rgb(235, 235, 225); background color: rgb(235, 235, 225);">
Telemetry</th>
<th class ="tabck" id="tabck 1" onclick=" activarTab ( this )" style ="color : white; border
bottom color: gray; background color: gray;">Data Logging</th>
</ tr >
<tr class =" filadiv ">
<td colspan="5" id="tab 0">
<div class ="tabdiv" id="tabdiv 0" style =" display : block;">
<! Aquí empieza la pestaña de telemetr ía >
<table id=" table 1">
<tr>
<td width="80%"><div id="RPM" style="min width: 310px; height: 150px; margin: 0
auto"></div></td>
<td width="20%">
<table id="panel">
<tr>
<td id="cab_panel">RPM</td>
</ tr >
<tr>
<td><div id="panelRPM">0</div></td>
</ tr >
</ table >
</td>
C.4 Interfaz web 79
</ tr >
<tr>
<td width="80%"><div id="speed" style="min width: 310px; height: 150px; margin: 0
auto"></div></td>
<td width="20%">
<table id="panel">
<tr>
<td id="cab_panel">SPEED</td>
</ tr >
<tr>
<td><div id="panelSPEED">0</div></td>
</ tr >
</ table >
</td>
</ tr >
<tr>
<td width="80%"><div id="tp" style="min width: 310px; height: 150px; margin: 0
auto"></div></td>
<td width="20%">
<table id="panel">
<tr>
<td id="cab_panel">TP</td>
</ tr >
<tr>
<td><div id="panelTP">0</div></td>
</ tr >
</ table >
</td>
</ tr >
<tr>
<td width="80%"><div id="temperatura" style="min width: 310px; height: 150px;
margin: 0 auto"></div></td>
<td width="20%">
<table id="panel">
<tr>
<td id="cab_panel">ECT</td>
<td id="cab_panel">IAT</td>
</ tr >
<tr>
<td><div id="tempECT">0</div></td>
<td><div id="tempEOT">0</div></td>
</ tr >
</ table >
</td>
</ tr >
</ table >
</div>
<! Aquí comienza la pestaña de data logging >
<div class ="tabdiv" id="tabdiv 1">
<?php
$ch = curl _ init () ;
curl _ setopt ($ch,CURLOPT_URL,’http://localhost/telemetria / api / get ’) ;

curl _ setopt ($ch,CURLOPT_RETURNTRANSFER,true);
$output=curl_exec($ch) ;
curl _close ($ch) ;

$json = json_decode($output) ;
?>
<table id="data" class =" display ">

<thead>
<tr>
<?php
foreach ($json >lecturas [0] as $campo => $valor){
echo "<td>".$campo."</td>";
}
?>
</ tr >
</thead>
<tbody>
<?php
foreach ($json >lecturas as $key => $value) {
echo "< tr >";
foreach ($value as $campo => $valor) {
echo "<td>".$ valor ."</ td >";
}
echo "</ tr >";
}
?>
</tbody>
</ table >
</div>
</td>
</ tr >
</ table >
</body>
</html>
C.4.2 style.css
Este documento comprende la hoja de estilos del cuerpo principal de la interfaz, definido en index.php [C.4.2]
body{
width:100%;
height :100%;
}
# table 1,# table 2{
width:100%;
max height: 300px;
}
table td{
padding: 0;
}
#velocidad , #temperatura , #panel{
max height: 300px;
}
#panel{
height : 70%;
width: 80%;
margin: 0 10% 0 10%;
border : 1px solid #ddd;
border radius: 4px;
webkit box shadow: 0 1px 1px rgba(0,0,0,.05) ;
box shadow: 0 1px 1px rgba (0,0,0,.05) ;
}
#panel td{
padding: 8px;
}
#cab_panel{
C.4 Interfaz web 81
color : #333;
background color: #f5f5f5;
font family: " Helvetica Neue", Helvetica , Arial , sans serif ;
font size: 18px;
height : 20%;
text align: center ;
}
#panel span{
font size:30px;
font weight:bold;
}
#panel div{
font size:70px;
}
table . tabs {
width: 100%;
border collapse: separate ;
border spacing: 0;
background color: transparent ;
font size: 0.9em;
}
th . tabck {
border : gray solid 1px;
border bottom: 0;
border radius: 0.5em 0.5em 0 0;
background color: transparent ;
padding: 0.3em;
cursor : pointer ;
}
th . tabcks {
border : 0;
border bottom: gray solid 1px;
}
th . tabcks : first child {
border left : gray solid 1px;
}
th . tabcks : last child {
border right: gray solid 1px;
}
table . tabs tr : first child th . tabcks {
border left : none;
border right: none;
}
table . tabs [ data filas ] th . tabck {
box shadow: 0 0.15em 0.1em 0 white;
}
div . tabdiv {
border : 0;
padding: 0.5em;
overflow : auto ;
display : none;
width: 100%;
height : auto ;
}
C.4.3 rpmdirecto.php
A través de este script, la función javascript requestRPM obtiene el último valor de las revoluciones de motor
almacenado en base de datos.
<?php
// Cabecera JSON
header("Content type: text / json ") ;
// Se utiliza funciones de la librer ía cURL para realizar una petici ón

// al método getLast de la API REST
$ch = curl _ init () ;
curl _ setopt ($ch,CURLOPT_URL,’http://localhost/telemetria / api / getLast ’) ;

curl _ setopt ($ch,CURLOPT_RETURNTRANSFER,true);
// Se almacena la respuesta en $output

$output=curl_exec($ch) ;
// Se cierra la conexión
curl _close ($ch) ;
// Se descompone la respuesta en los distintos parámetros contenidos en

// la trama JSON
$json = json_decode($output) ;
// Se accede al campo correspondiente

$y = $json >RPM;
// Se haya el tiempo del servidor y se transforma a un formato correcto

// para ser representado
$time = $json >time;
$unixtime = strtotime ($time) ;
$x=$unixtime 1000;
// Se crea un array para poder devolver el valor solicitado y la hora

// exacta en la misma respuesta .
$ ret = array ($x, $y);
echo json_encode($ret ) ;
?>
Los archivos speeddirecto.php, tpdirecto.php y temperaturasdirecto.php operan de la misma forma, acce-

diendo al campo correspondiente de la respuesta de la API REST del servidor.
Índice de Figuras
1.1. Equipos participantes en el circuito de Hockenheim (Alemania). Julio 2015 1

1.2. Participación de las pruebas estáticas y dinámicas en la puntuación final 2
1.3. Participación de las diferentes pruebas en la puntuación 2
1.4. El ARUS Team participante en el circuito de Hockenheim (Alemania). Julio 2015 3
1.5. Organigrama del equipo ARUS 3
1.6. Estructura general de un sistema de telemetría en FSAE 5
2.1. Longitud máxima del circuito de FSAE de Hockenheimring (Alemania) 7

2.2. Scatternet Bluetooht formada por dos piconets 9
2.3. Posibles topologías Wi-Fi 10
2.4. Red ZigBee con topología en malla 11
2.5. Visión frontal del Arduino UNO Rev3 13
2.6. Visión frontal del CAN-BUS Shield 14
2.7. Visión frontal del Wireless SD Shield 14
2.8. Visión frontal del XBee PRO S2B RPSMA 15
2.9. Visión frontal del XBee Explorer 15
2.10. Raspberry Pi 2 modelo B+ 16
2.11. Vista preliminar de Beaglebone 17
2.12. Vista de la parte trasera del monoplaza. En rojo, las posibles ubicaciones del soporte del sistema 18
2.13. Vista de la parte delantera del monoplaza. En rojo, la posible ubicacion del soporte del sistema 19
2.14. Vistas de la parte inferior del soporte del sistema 21
2.15. Vistas de la parte superior del soporte del sistema 21
2.16. Vista lateral y superior de las dos piezas fabricadas 21
3.1. Dirección de red de los módulos ZigBee 23

3.2. Búsqueda de módulo XBee en XCTU 24
3.3. Vista de la conexión del módulo ZigBee en XCTU 24
3.4. Interfaz de configuración en XCTU 25
3.5. Entorno de programación de Arduino 26
3.6. Conexión USB entre la placa Arduino y un PC 26
3.7. Ejemplo básico en Arduino. Parpadeo de un LED 27
3.8. Vista frontal de la unidad de control de motor Link G4+ Storm 29
3.9. Vista previa del software de la ECU 29
3.10. Configuración del bus CAN de la centralita 30
3.11. Diagrama de bloques de la lectura de un sensor LM35 con LabVIEW 32
3.12. Interfaz de telemetría con LabVIEW 32
3.13. Interfaz de telemetría con Matlab 33
3.14. Ejemplo de gráficas Javascript con Highcharts 34
3.15. Vista del panel de administración de PHPMyAdmin 35
3.16. Estructura de la base de datos 35
3.17. Esquema del receptor usando la API REST 36
83
84 Índice de Figuras
3.18. Vista del script de lectura desarrollado con el GUI TkInter 37

3.19. Telemetría del software de competición Wintax 38
3.20. Vista previa de la interfaz de telemetría 39
3.21. Vista previa de la interfaz de data logging 39
3.22. Esquema global de funcionamiento del sistema 40
3.23. Vista de las tramas JSON recibidas mediante el script de lectura 41
3.24. Vista de la interfaz de data logging en el escenario supuesto 41
3.25. Vista de la interfaz de telemetría en el escenario supuesto 42
4.1. Configuración de las tramas CAN con PCLink 44

4.2. Prueba de funcionamiento del bus CAN a 1 Hz 45
4.3. Prueba de funcionamiento del bus CAN a 50 Hz. En rojo, las tramas erróneas 45
5.1. Data logging de una de las pruebas de la competición Formula Student Spain 47
5.2. Análisis de la respuesta del motor a través del data logging 48
A.1. Módulos conectados mediante BUS CAN. 53

A.2. Estructura de la trama. 54
A.3. Línea CAN 55
A.4. Resistencias de cierre 56
A.5. Ubicación del controlador 56
A.6. Ejemplo de un módulo 56
A.7. Ejemplo práctico de CAN 57
Índice de Tablas
1.1. Evaluación de la Formula Student 2

1.2. Características principales del monoplaza ART-15 4
2.1. Clases Bluetooth 9

2.2. Relación entre las distintas versiones Bluetooth y su capacidad 9
2.3. Comparativa entre los protocolos de conexión inalámbrica contemplados 12
2.4. Especificaciones técnicas Arduino 13
2.5. Especificaciones técnicas XBee Pro S2B RPSMA 15
2.6. Presupuesto total del sistema con la plataforma Arduino 16
2.7. Especificaciones técnicas Raspberry Pi 2 modelo B+ 16
3.1. Direcciones de red de los dos dispositivos utilizados 24

3.2. Valores para la configuración de XBee 25
3.3. Sensores monitorizados por telemetría 27
3.4. OBD-II PIDs de los valores monitorizados 28
3.5. Relación entre elementos del motor y la ECU 31
3.6. Acciones y direcciones de la API REST 36
85
Bibliografía
[1] Cocco, L., and Daponte, P. Metrology and Formula One Car. In Instrumentation and Measurement
Technology Conference Proceedings, 2008. IMTC 2008. IEEE (may 2008), pp. 755 –760.
[2] Hadaller D., Li H., Sung A. Formula SAE Telemetry Collection Unit. http:// www.flamenet.ca/ uw/
courses/ cs856_f04/ proj/ sae-report11.pdf . Fecha de consulta: 8 de agosto 2015.
[3] Loiselle, J.T. Design and Analysis of a FSAE Racecar. Major Qualifying Project Report. Worcester
Polytechnic Institute. 2012
[4] Mancini., B Greene B., Fiederlein E., Doelger G and Tung K. The Complete Design of an Engine
Management System for RIT’s Formula SAE Team. Multi-Disciplinary Engineering
[5] Design Conference. Project Number: 07222Kate Gleason College of Engineering. Rochester Institute
of Technology. Rochester, New York. 2007
[6] Mclaren-Electronics. Advanced Telemetry Linked Acquisition System. http:// www.mclarenelectronics.

com/ Products/ Product/ vTAGServer Fecha de consulta: 15 de agosto 2015.
[7] MoTeC i2 Pro Telemetry Monitor. http:// www.motec.com.au/ telemetry/ telemetryoverview/ Accessed
on 8th August 2015.
[8] Pearce, J. Electric Vehicle Telemetry. Honour thesis, The University of Western Australia, October
2010.
[9] SAE-International. Competition History. http:// www.sae.org/ students/ fsaehistory.pdf , April 2005.
Fecha de consulta: 8 de agosto 2015.
[10] SAE-International. About Formula SAE. http:// students.sae.org/ competitions/ formulaseries/ about.htm.
Fecha de consulta: 8 de agosto 2015.
[11] Walter, T. Development of a User Interface for Electric Cars. Master thesis, University of Stuttgart,
December 2010.
[12] Braune N. Telemetry Unit for a Formula Student Race Car. Swiss Federal Institut of Technology. Zurich.
2014.
[13] Pfarr A., Peterman E., Young C.,Cooper C. Telemetry System for the University of Idaho Formula SAE
Vehicle. 2006.
[14] Hadaller D., Li H., Sung A. Formula SAE Telemetry Collection Unit. Project Report. University of
Waterloo (Belgium). 2004.
[15] Pearce J. Electric Vehicle Telemetry. School of Electrical, Electronic and Computer Engineering.
University of Western Australia. 2010.
[16] Rua Copeto D. Automotive data acquisition system – FST. Insituto Superior Técnico. Universidade
Técnica de Lisboa. 2009.
87
88 Bibliografía
[17] Gascón Domingo D. Telemetria basada en WiFi per a l’equip del Formula Student de Barcelona. 2014.
[18] Iglesias Hernández J. Sistema de telemetría para un vehículo de fórmula S.A.E. Universidad Politécnica
de Madrid. 2013.
[19] López Fresno J., Nodo de comunicación basado en el BUS CAN. PFC. Universidad Rovira i Virgili.
2004.
[20] Fecha de consulta: 26 de agosto 2015. https:// www.arduino.cc/ en/ Main/ ArduinoBoardUno
[21] Fecha de consulta: 26 de agosto 2015. http:// www.seeedstudio.com/ wiki/ CAN-BUS_Shield
[22] Fecha de consulta: 26 de agosto 2015. ttps:// www.arduino.cc/ en/ Main/ ArduinoBoardUno
[23] Fecha de consulta: 26 de agosto 2015. https:// store.arduino.cc/ product/ A000065
[24] Fecha de consulta: 26 de agosto 2015. http:// tienda.bricogeek.com/ shields-arduino/ 419-arduino-

wireless-sd-shield.html
[25] Fecha de consulta: 26 de agosto 2015. http:// www.digi.com/ lp/ xbee/
[26] Fecha de consulta: 26 de agosto 2015.http:// www.digi.com/ products/ xbee-rf-solutions/ modules/ xbee-
zigbee
[27] Fecha de consulta: 26 de agosto 2015. http:// tienda.bricogeek.com/ modulos-radiofrecuencia/ 229-xbee-

pro-63mw-serie-2b-rpsma.html
[28] Fecha de consulta: 26 de agosto 2015. http:// tienda.bricogeek.com/ modulos-radiofrecuencia/ 156-xbee-

explorer-usb.html
[29] Fecha de consulta: 26 de agosto 2015. http:// ww1.microchip.com/ downloads/ en/ DeviceDoc/ 21801G.
pdf
[30] Fecha de consulta: 26 de agosto 2015. http:// ww1.microchip.com/ downloads/ en/ DeviceDoc/ 21667f.pdf
[31] Cellan-Jones, Rory (5 de mayo de 2011). «A £15 computer to inspire young programmers».
BBC News: http:// www.bbc.co.uk/ blogs/ thereporters/ rorycellanjones/ 2011/ 05/ a_15_computer_to_
inspire_young.html
[32] Fecha de consulta: 28 de agosto 2015. http:// tienda.bricogeek.com/ placas-raspberry-pi/ 718-raspberry-

pi-2-model-b-1gb.html
[33] Fecha de consulta: 28 de agosto 2015. https:// www.cooking-hacks.com/ shop/ raspberry-pi/ raspberry-
pi-to-arduino-shield-connection-bridge
[34] Fecha de consulta: 28 de agosto 2015. http:// www.ti.com/ devnet/ docs/ catalog/ thirdpartydevtoolfolder.
tsp?actionPerformed=productFolder&productId=9680
[35] Fecha de consulta: 28 de agosto 2015. http:// es.farnell.com/ element14/ bbone-black-4g/ beaglebone-
black-rev-c-cortex/ dp/ 2422228
[36] Fecha de consulta: 31 de agosto 2015. http:// www.digi.com/ products/ xbee-rf-solutions/ xctu-software/
xctu
[37] Fecha de consulta: 31 de agosto 2015. https:// www.cooking-hacks.com/ media/ cooking/ images/
documentation/ CANBus/ CANBUS_for_Arduino.zip
[38] Fecha de consulta: 31 de agosto 2015. https:// geekytheory.com/ json-i-que-es-y-para-que-sirve-json/
[39] Fecha de consulta: 31 de agosto 2015. http:// www.linkecu.com/
[40] Fecha de consulta: 31 de agosto 2015. http:// www.linkecu.com/ Software-and-Support/ PC-Link-

Downloads
[41] Fecha de consulta: 31 de agosto 2015. http:// spain.ni.com/

Bibliografía 89
[42] Fecha de consulta: 31 de agosto 2015. http:// es.mathworks.com/ discovery/ matlab-gui.html

[43] Fecha de consulta: 1 de septiembre 2015. http:// ocw.uoc.edu/ computer-science-technology-and-
multimedia/ bases-de-datos/ bases-de-datos/ P06_M2109_02151.pdf
[44] Fecha de consulta: 1 de septiembre 2015. https:// www.apachefriends.org/ es/ index.html

[45] Fecha de consulta: 1 de septiembre 2015. http:// www.hipertexto.info/ documentos/ b_datos.htm
[46] Fecha de consulta: 1 de septiembre 2015. http:// www.desarrolloweb.com/ articulos/ ventajas-
inconvenientes-apirest-desarrollo.html
[47] Fecha de consulta: 1 de septiembre 2015. http:// www.slimframework.com/

[48] Fecha de consulta: 1 de septiembre 2015. http:// www.w3c.es/
[49] Fecha de consulta: 1 de septiembre 2015. http:// www.magnetimarelli.com/ business_areas/ motorsport/
software/ wintax4
[50] Fecha de consulta: 1 de septiembre 2015. http:// www.highcharts.com/

[51] Fecha de consulta: 1 de septiembre 2015. https:// datatables.net/
[52] Fecha de consulta: 5 de septiembre 2015. http:// ftp1.digi.com/ support/ documentation/ 90000976_W.pdf
[53] Fecha de consulta: 5 de septiembre 2015. http:// www.atmel.com/ Images/ doc8161.pdf

[54] Fecha de consulta: 5 de septiembre 2015. http:// www.arusteam.com

Tele Me Tria

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tele Me Tria

Transféré par

Droits d'auteur :

Formats disponibles

Proyecto Fin de Carrera

Proyecto Fin de Carrera

Diseño de un sistema de telemetría para un

Departamento de Ingeniería Electrónica

Autor: Daniel Gómez Sanz

acuerdan otorgarle la calificación de:

El Secretario del Tribunal

El primer modelo de la temporada 2014, en el cual se priorizó la fiabilidad, solidez y consistencia de

3.2.1. Entornos de desarrollo 31

1.1 Descripción y objetivos

Figura 1.1 Equipos participantes en el circuito de Hockenheim (Alemania). Julio 2015.

Tabla 1.1 Evaluación de la Formula Student.

Aspectos estáticos 325 puntos

Figura 1.2 Participación de las pruebas estáticas y dinámicas en la puntuación final.

Figura 1.3 Participación de las diferentes pruebas en la puntuación.

1.2 El equipo ARUS (Andalucía Racing Universidad de Sevilla)

Figura 1.5 Organigrama del equipo ARUS.

1.3 El coche ART-15

Tabla 1.2 Características principales del monoplaza ART-15.

• Reducir el peso, de 300kg a 250Kg.

• Mejorar el rendimiento del motor Honda CBR 600RR.

• Potenciar la aerodinámica y crear un paquete aerodinámico completo.

• Implementar un sistema de telemetría.

El desarrollo de este último apartado es el objetivo de este Proyecto Fin de Carrera.

1.4 Telemetría en la Formula Student

Figura 1.6 Estructura general de un sistema de telemetría en FSAE.

2.1 Restricciones generales

Figura 2.1 Longitud máxima del circuito de FSAE de Hockenheimring (Alemania).

A continuación se procede a realizar un estudio de las distintas tecnologías de comunicación inalámbrica

2.2.1 Protocolos de comunicación inalámbrica

A lo largo de los últimos años la tecnología orientada a la conectividad inalámbrica ha experimentado un

El diseño de un sistema de telemetría no difiere demasiado de la creación de cualquier red inalámbrica en

Figura 2.2 Scatternet Bluetooht formada por dos piconets.

Tabla 2.1 Clases Bluetooth.

Tabla 2.2 Relación entre las distintas versiones Bluetooth y su capacidad.

Versión Capacidad del canal (Mbps)

Figura 2.3 Posibles topologías Wi-Fi.

Figura 2.4 Red ZigBee con topología en malla.

2.2.2 Tecnología escogida

Tabla 2.3 Comparativa entre los protocolos de conexión inalámbrica contemplados.

Estándar Bluetooth Wi-Fi ZigBee

2.3.1 Electrónica open source

Tabla 2.4 Especificaciones técnicas Arduino.

Figura 2.5 Visión frontal del Arduino UNO Rev3.

Figura 2.6 Visión frontal del CAN-BUS Shield.

Figura 2.7 Visión frontal del Wireless SD Shield.

Tabla 2.5 Especificaciones técnicas XBee Pro S2B RPSMA.

Alimentación 3.3V @ 215 mA

Figura 2.8 Visión frontal del XBee PRO S2B RPSMA.

Figura 2.9 Visión frontal del XBee Explorer.

A modo de resumen, el coste total del sistema sería el siguiente:

Tabla 2.6 Presupuesto total del sistema con la plataforma Arduino.

Elemento Unidades Precio

Tabla 2.7 Especificaciones técnicas Raspberry Pi 2 modelo B+.

El precio aproximado de Raspberry Pi 2 modelo B, es de 50 Ä [32].

Figura 2.10 Raspberry Pi 2 modelo B+.

Figura 2.11 Vista preliminar de Beaglebone.

2.4.1 Agentes externos

2.4.3 Impresión 3D y elección de material

Figura 2.14 Vistas de la parte inferior del soporte del sistema.

Figura 2.15 Vistas de la parte superior del soporte del sistema.

Figura 2.16 Vista lateral y superior de las dos piezas fabricadas.

3.1 Configuración de los equipos

3.1.1 Establecimiento de una red ZigBee