07 ene 24 Sistema de telemetría 2.0, basado en ESP32
Hace ya algunos años, cuando aún vivíamos en Irlanda, desarrollé un sistema de telemetría casero para el Mercedes C180 Sportcoupe que teníamos allí, basado en una Raspberry Pi y un receptor GPS, junto con un conector OBD-II por Bluetooth para leer datos de la centralita del coche. Fue un sistema que estuvo funcionando estupendamente bien, pero que dejé de utilizar, por razones que no vienen al caso.
En fechas recientes me he decidido a revivirlo (también por razones que no vienen al caso), pero quería darle una vuelta de tuerca al sistema, para cambiar algunas características que -estando bien- no se amoldaban del todo a mis necesidades. La principal de ella es que el sistema original dependía de una conexión Bluetooth con un teléfono móvil que hiciera de módem sobre este medio, a fin de proporcionar conectividad al exterior. Buscaba que la nueva versión del entorno tuviera conectividad independiente, a fin de poder hacer seguimiento del coche de manera más sencilla. Mi primera idea fue conectar un modem USB a la Raspberry Pi, pero se trata de un modelo 2 de la RPi, que sólo dispone de 2 conexiones USB, y ambas estaban en uso: una para el receptor GPS, y otra para el dongle Bluetooth que se necesita para conectar con la centralita del coche. Pensé en portar todo a una RPi más moderna, pero fue aquí cuando entró en danza el siguiente artilugio:
LilyGO TTGO T-A7670G
Se trata de un dispositivo LilyGO TTGO T-A7670G. Se trata de un ESP-32 que proporciona, de manera simultánea, conectividad Bluetooth, zócalo para tarjetas de telefonía 4G, receptor GPS, e incluso un zócalo para conectar una batería 18650, todo ello en una sola placa. Ya tenía experiencia trabajando con ESP-32 en Arduino, lo cual era una gran ventaja para mí, además de trabajar con estos componentes por separado, pero nunca lo había hecho con una placa de fabricante que proporcionara todos estos elementos de manera integrada. Mucho mejor que tener que ir montando componentes por separado.
El fabricante, además, proporciona un repositorio en GitHub donde acceder a librerías, ejemplos de código, documentación, e incluso esquemáticos de carcasas, lo que ha hecho que haya podido imprimir una caja para el dispositivo:
TTGO con carcasa 3D y receptor GPS
Con todo esto, he podido realizar una nueva versión del sistema de telemetría, con las siguientes características:
- Hago uso de una tarjeta de datos 4G española, de tipo MicroSIM, con un funcionamiento excelente. El sistema apenas consume sobre 2-3 MB de datos, haciendo envío de información cada 10 segundos a la plataforma.
- La conectividad, como en el caso original, está basada en el envío de datos en formato JSON a un servidor MQTT. Posteriormente esa información es consumida de diversas maneras, tanto para proporcionar ubicación en tiempo real, como para realizar analítica de datos sobre el viaje. A diferencia del caso original, el envío de información se hace directamente al MQTT remoto, en vez de componer un MQTT local que se sincroniza con el remoto, cosa que se hacía para preservar el envío de información en caso de pérdida de conectividad. En este caso, he podido comprobar que no se producen pérdidas de datos significativas, por lo que he preferido simplificar.
- El sistema hace uso del GPS integrado para recibir información GPS. Este es un punto importante en el caso de esta placa. Existen diversas variantes de la misma, con cobertura GPS regional, global, o sin cobertura GPS. En mi caso, hago uso de la placa “A7670G R2 With GPS”, que es el que proporciona cobertura GPS global, y más compatibilidad con sistemas de telefonía, pero tiene el detalle de que el módulo GPS no está integrado en la placa, sino como módulo anexo, en la trasera de la misma, junto al zócalo de la batería 18650. Esto implica que el modo de uso del GPS es distinto, haciendo uso de la librería GPSShield, en vez del ejemplo convencional que indica el fabricante. Esto me tuvo un tiempo dando vueltas, hasta que me di cuenta de ello.
Además, la placa viene con una antena GPS pasiva. Esto está bien si el dispositivo se encuentra directamente al aire libre, pero era problemático si estaba dentro de una casa o de un coche, ya que apenas tenía cobertura. Para solucionar este inconveniente tuve que hacer uso de una antena GPS activa con conector SMA, y hacer uso de un pigtail UFL/U.FL/IPX a RP-SMA/SMA. Nada grave, pero sí un poco molesto. Ahora bien, en cuanto dispuse de esta antena activa el sistema pasó a ser capaz de detectar señal GPS incluso en interiores. Todo una diferencia, y sin necesidad de reprogramar.
- La telemetría OBD-II es algo que no he conseguido hacer funcionar aún del todo. Si bien la placa es capaz de conectar correctamente con mi conector OBD-II por Bluetooth, no es capaz de extraer correctamente los datos de la centralita. Hago uso para ello de la librería ELMduino, que conocía desde hace algunos años, pero con la que no he tenido resultados muy buenos hasta ahora. Antes hacía uso de un ESP-32 convencional, y esperaba que con esta placa funcionara mejor, pero no ha sido el caso. Puede ser tema del dongle Bluetooth, que es de los baratillos. He encargado otro, para probar, así que espero mejoras al respecto.
En estos días he estado haciendo algunas pruebas, y al margen de la captura de datos de la centralita, el resultado es bastante bueno. Espero poder seguir haciendo mejor al respecto en las próximas semanas.
Etiquetas: a7670, arduino, bluetooth, esp32, gps, impresora 3d, lilygo, mqtt, obd-ii, telemetría
20 feb 17 Mejoras en el sistema de telemetría
Este fin de semana he estado con Ana y unos amigos en Waterford. Ha sido la oportunidad perfecta para probar el sistema de telemetría. Y la verdad es que se ha portado de fábula. Como muestra, un botón:
Telemetría del viaje a Waterford
Como se puede apreciar, la recogida de datos funcionó a la perfección durante las dos hora de viaje desde Dublín a Waterford. Por ello, me he decidido a realizar algunas modificaciones en el sistema de telemetría:
- Recogida de parámetros adicionales: Hasta ahora recogía 3 valores de la centralita del coche: velocidad, revoluciones por minuto y flujo de aire entrante en el motor, este último, junto con la velocidad, para realizar el cálculo del consumo de combustible. Ahora voy a pasar a recoger 14 parámetros en total, que son los que proporciona la centralita del coche. En otros vehículos más modernos se pueden recoger muchos más parámetros, pero por el momento tengo información más que suficiente de múltiples valores: temperaturas, sensores de depósito, % de potencia utilizada, % de recorrido del acelerador… El detalle de los parámetros recogidos es el siguiente:
PIDs OBD II Mercedes W203
- Modificación en la frecuencia de recogida de valores: Dado que paso a recoger más parámetros, y anteriormente he tenido problemas de uso del canal de comunicación Bluetooth, voy a reducir la frecuencia de recogida de valores desde los 2 segundos a los 5. Si el sistema se sigue mostrando estable, consideraré volver a recoger valores cada 2 segundos.
- Cálculo de distancia recorrida: Uno de los valores que la centralita no proporciona es la distancia recorrida. Así que he introducido el cálculo de la misma, basado en los datos proporcionados por el sensor GPS.
- (En desarrollo) Incorporación de acelerómetros: De nuevo, un valor no proporcionado por la centralita. En este caso, se trata de medir la aceleración del vehículo en los ejes X, Y y Z. La centralita no los proporciona, y la Raspberry Pi tampoco. Así que he encargado un acelerómetro con giróscopos incorporados, que proporcionará información a través del los puertos GPIO de la RPi.
Etiquetas: gps, raspberry pi, telemetría
29 ene 17 Sistema de telemetría y geoposicionamiento para vehículos
Escribía en mi entrada anterior que estaba trabajando en un sistema de telemetría para el Mercedes. Durante estas últimas semanas he estado realizando algunas mejoras en el sistema, y si bien aún es posible incorporar algunas más, en este momento ya empieza a tener un desarrollo bastante definido. En pocas palabras, se trata de un sistema de telemetría que recoge datos de dos fuentes, la centralita del coche y un módulo GPS, para transmitirlo a un servidor donde se almacenan los datos para su posterior tratamiento. En este momento, el tratamiento consiste en dos actividades: representación gráfica de velocidad, revoluciones por minuto y consumo del coche, y geoposicionamiento en mapas en tiempo real. Este es un esquema básico de la plataforma:
Esquema del sistema de telemetría
El sistema está compuesto por los siguientes elementos:
- Sonda de captura de datos: La sonda de captura de datos consiste en una Raspberry Pi que se conecta con la centralita del coche mediante un módulo bluetooth. La centralita del coche se ha equipado, a su vez, con un módulo OBD-II con bluetooth. Esta sonda, de igual manera, dispone de un módulo GPS para proporcionar datos relativos a la posición del vehículo.
- Programa de telemetría: En la sonda de posicionamiento he desplegado un programa que recopila información de las fuentes anteriores, que he desarrollado en Python. Este programa, en líneas generales, comprueba el estado de las fuentes de datos antes mencionados, recopila la información y la prepara para su transmisión. Para ello, se apoya en un broker MQTT instalado en la propia sonda. Por último, se hace un almacenado local en ficheros csv de la información recopilada, junto con una marca de tiempo.
- Broker MQTT local: Para realizar la transmisión de datos al servidor de almacenamiento y procesado de datos se hace uso de un broker MQTT local. MQTT es un protocolo ligero de mensajería para pequeños sensores y dispositivos móviles ideado por IBM. Está optimizado para realizar la transmisión de datos incluso en redes no confiables y en entornos de alta latencia, por lo que es ideal para delegar en él la capa de transmisión de datos del programa anterior, ya que es presumible que el vehículo pueda encontrarse en situaciones de escasa cobertura o incluso pérdida total de la misma, además de en situaciones en las que la transmisión de datos haya de efectuarse haciendo uso de redes GSM de escasa capacidad. Además, tiene la ventaja de que produce menos sobrecarga que otros protocolos como HTTP, y (en teoría) hace un menor consumo de datos. La idea es la siguiente: el programa anterior delega en el broker MQTT el establecer el envío de paquetes al servidor. El broker MQTT actúa además como buffer local de los paquetes transmitidos, en caso de pérdida o inestabilidad de las comunicaciones. Este buffer local, gracias a una pequeña base de datos interna, es persistente incluso ante reinicios inesperados de la sonda. El broker MQTT local está sincronizado con otro broker MQTT desplegado en el servidor de recepción de datos, y es capaz de garantizar la correcta sincronización, como se ha comentado, incluso en situaciones de pérdida total de conectividad y reinicios en la sonda de datos.
- Envío de datos mediante tethering bluetooth: El broker local MQTT es dotado de conectividad a Internet mediante tethering bluetooth con un teléfono móvil. Si bien a priori sería más interesante hacer uso de tethering wifi para esto mismo, hay tres buenas razones para optar por bluetooth: La primera es que al hacer uso de MQTT el volumen de información a intercambiar es bastante reducido, por lo que es posible hacer uso de bluetooth para ello, con el consiguiente impacto positivo en el consumo de energía necesario para establecer el canal de datos. La segunda es una limitación física en la sonda. La Raspberry Pi 2 que utilizo tiene sólo dos puertos USB, uno usado con el módulo GPS y otro con el módulo bluetooth para conectar con la centralita, por lo que no queda sitio para un módulo WiFi. Y la tercera, es que todo es mejor con bluetooth.
- Servidor de recepción de datos: El segundo bloque del sistema es el servidor de recepción y análisis de datos. Consiste en líneas generales en un servidor Graphite donde se almacenan los datos proporcionados por la sonda de captura de datos, y que permite su posterior utilización, bien para la representación de gráficas de dichos datos mediante Grafana, bien para la el geoposicionamiento del vehículo en tiempo real, con información añadida del resto de parámetros proporcionados por la sonda.
- Broker MQTT: La comunicación, como se ha comentado, se realiza mediante un broker MQTT que sincroniza con el broker MQTT de la sonda. Este broker recibe los datos proporcionados por la sonda, y los inyecta, mediante una pasarela desarrollada en Python, en el servidor Graphite. Dado que es posible que la información proporcionada por el broker MQTT de la sonda no se reciba en tiempo real debido a posibles cortes en las comunicaciones, se hace uso de la marca de tiempo incluida en cada transmisión de la sonda remota para inyectar los datos en el servidor Graphite con información de tiempo de creación correcta.
- Servidor Graphite: El servidor Graphite consolida la información proporcionada por la sonda de captura de datos, la almacena en una sistema de base de datos buffer de corta duración (Carbon) y posteriormente la consolida en una base de datos da larga duración (whisper).
- Servidor Grafana: Los datos consolidados en el servidor Graphite son consumidos por Grafana, software para visualización de métricas. Se han creado una serie de gráficas que permiten acceder a la información relativa a la velocidad, revoluciones por minuto, entrada de aire en el motor, consumo de combustible y altitud con respecto al mar, así como a sus valores medios en un rango de tiempo establecido. Grafana proporciona, además, la capacidad de integrar estas gráficas en una plataforma de terceros.
- Sistema de geoposicionamiento: El broker MQTT permite, además, el procesamiento de la información proporcionada por la sonda para representar en tiempo real la ubicación geográfica del vehículo, así como la traza de las posiciones anteriores mediante una línea de posición. Además, se proporciona información en tiempo real de los parámetros proporcionados por la sonda. Este sistema está basado en Node-RED, una herramienta desarrollada por IBM para permitir una interconexión sencilla de diversas aplicaciones y dispositivos IoT. También hace uso de OpenStreetMap, mediante la librería WorldMap.
Captura de posicionamiento de vehículo con datos en tiempo real
Todo este sistema lo he compilado en la siguente web para su visualización: Telemetría (www.eniac2000.com/telemetria)
Dado que la información mostrada en esa URL proporciona datos en tiempo real, he realizado una captura de datos obtenidos en vivo:
Captura del sistema de telemetría
…así como un vídeo en el que se aprecia la información, si bien realizando la captura de la información desde las dos fuentes de datos separadas, y no desde el mismo portal:
Como comentaba, el sistema está aún en una fase muy temprana, pero el potencial de mejora es grande. Los principales puntos en los que estoy trabajando son los siguientes:
- Mejora en la seguridad de comunicaciones entre brokers MQTT
- Mejora en la fiabilidad de la comunicación OBD-II
- Reemplazo del sistema de base datos de larga duración de Graphite por un sistema NoSQL, presumiblemente un InfluxDB
- Dotar de redundancia a los elementos de la plataforma
- Proporcionar un sistema de persistencia de la información
- Creación de un portal multiusuario con soporte de múltiples dispositivos
- Otros…
Si bien este proyecto empezó como algo personal, con la idea de comprobar cuánto consumía mi coche en los desplazamientos, tengo el convencimiento de que puede convertirse en algo más que en un mero pasatiempo. Esperemos que así sea.
Etiquetas: bluetooth, gps, grafana, graphite, ibm, iot, mqtt, node-red, obd-ii, python, raspberry pi, telemetría, tethering
08 ene 17 Sistema de telemetría para el Mercedes
Pues eso. Me he montado un pequeño sistema de telemetría para el Mercedes:
Sistema de telemetría para el Mercedes
No es un sistema de Fórmula 1, pero me proporciona datos en tiempo real, accesible por Internet. Otro día escribiré con algo más de tiempo. Pero las palabras claves son: Raspberry Pi, OBD-II, tethering, gps, sockets, Graphite, Grafana y Bluetooth. Porque todo es mejor con Bluetooth.
Etiquetas: bluetooth, gps, grafana, graphite, obd-ii, raspberry pi, telemetría
20 nov 11 MTB a Fondo
El ciclismo, como sabe cualquiera que lea un poco estas páginas, es una de mis grandes pasiones. Disfruto con el ciclismo de carretera, pero tengo especial predilección por el ciclismo de montaña. Afición que, afortunadamente, comparto con una buena cantidad de amigos. Hace ya algún tiempo, en una charla con Mané, estuvimos hablando sobre la creación de un foro para nuestro grupo de amigos en el que pudiéramos charlar de las etapas, planificar salidas, y poder contar cosas en general sobre nuestra común afición.
Tiempo después, me encontré con un pequeño problema: desde hace un año registro todas las salidas que hacemos con la bici en archivos GPX, a fin de tenerlas documentadas para posteriores salidas, así como material para realizar los relatos con los que me gusta recordar las etapas. El almacenaje de esos gpx se estaba volviendo un tanto caótico (ya que no contenía referencias o datos más allá de la fecha del fichero), por lo que se me ocurrió poder utilizar algún gestor documental para almacenar las etapas de manera más ordenada, y que a la vez me sirviera de copia de seguridad de mi registro de archivos.
Fue entonces cuando se me ocurrió que podía aprovechar un gestor de contenidos con el que tengo bastante esperiencia, WordPress, para solucionar ambos problemas. Y fruto de esa idea fue como nació MTB A Fondo.
Captura de pantalla de MTB a Fondo
MTB a Fondo ha sido creado como una pequeña red social especializada en ciclismo; su principal función es que los aficionados al ciclismo podamos compartir noticias, ideas, experiencias y conocimiento. Es una herramienta pensada para ser usada por nuestro grupo de amigos, pero que está abierta a cualquiera que quiera participar. Originariamente fue creada como una sección de mi página principal (www.eniac2000.com), pero como me aconsejó mi buen amigo Manolo, si quería darle algo de vidilla, era más conveniente crear la red como una web aparte. Y así fue como me decidí a compar el dominio www.mtbafondo.es
En cuanto a su estructura, está formada por los siguientes elementos:
- WordPress: Es un gestor de contenido. Aunque está principalmente enfocado a la creación de blogs, la gran cantidad de plugins que admite hace que se pueda extender su funcionalidad habitual mucho más allá, y dotar al sistema de capacidades adicionales, como en este caso.
- BuddyPress: Es un plugin para WordPress que permite dotarlo de funcionalidades de red social (una especie de Feisbuk, para entendernos): un muro en donde puedes colgar rápidamente entradas rápidas o pequeños mensajes, una sección de usuarios ampliada, en la que se pueden establecer amigos y enviar mensajes privados, un foro integrado, una sección de grupos, donde se pueden crear agrupaciones de interés para temas comunes (y que se integra con el foro y el muro), etc…
- Plugins adicionales: Además de este plugin, he añadido otros más a la red social, que permiten extender las funciones anteriores: un gestor de eventos, para gestionar las quedadas ciclistas, un gestor de archivos, para almacenar ficheros (caso de los GPX que citaba antes, además de imágenes), o un sistema de suscripción por correo electrónico, que permite que los artículos o novedades que se publiquen en la web sean enviados de manera automática a una dirección de correo, permitiendo escoger de qué secciones quieres recibir correos de aviso.
He hablado un poco de las principales funcionalidades que ofrece MTB a Fondo, pero existen otras dignas de destacar:
- Suscripción RSS: MTB a Fondo dispone, como todo sitio basado en WordPress, de fuente de contenidos RSS, que permite que el contenido del sitio pueda ser seguido sin tener que acceder a la página, a traves de lectores como Google Reader o aplicaciones ajenas a navegadores, como lectores de correo o aplicaciones específicas para móvil
- Avisos por correo a usuarios: Cada vez que un usuario de la red cita a otro en sus comentarios (insertando una “@” delante de su nombre), el usuario citado recibe automáticamente un correo electrónico de aviso, lo que permite seguir de manera más ágil las conversaciones que se generan el el sitio.
- Mensajes privados entre usuarios: Además de los mensajes públicos del sitio, se pueden enviar mensajes privados a usuarios, sin publicidad para el resto de la web.
- Chat integrado: Además de la parte de red social convencional, MTB a Fondo dispone de un chat integrado, visible sólo para los usuarios registrados. Este chat, al estilo de Google Talk, permite una mayor agilidad de comunicación entre los usuarios del sitio.
- Integración de sitios externos: ¿Escribes en otra página y no quieres tener que repetir contenido en este sitio? ¡Sin problemas! Ese es exactamente mi caso: escribo entradas de ciclismo en mi sitio habitual (www.eniac2000.com), y no me apetece tener que repetir lo que escribo en MTB a Fondo. Para ello he instalado un plugin (FeedWordPress) que permite hacer uso el RSS/Atom de tu sitio habitual para que el contenido de éste sea publicado de manera automática en tu usuario de MTB a Fondo.
- Acceso optimizado para teléfonos móviles: Otra aplicación que le he instalado permite detectar automáticamente si se está accediendo a la web por un dispositivo móvil (Android, iPhone, etc…), y presenta una interfaz optimizada para acceder de manera más cómoda con estos dispositivos.
- Integración con Twitter: Otra de las vocaciones de esta red es la facilidad de compartir información. Cada una de las entradas publicadas tiene la posibilidad de ser compartida fácilmente con Twitter, y hacer un seguimiento de su actividad. Y es más, se puede sincronizar el usuario del MTB a Fondo con nuestro usuario de Twitter, de tal manera que los comentarios que se publique en MTB a Fondo puedan ser enviados automáticamente a Twitter, tan sólo añadiendo el tag #twitter delante de nuestra entrada.
Icono de contenido RSS
Escribiendo un mensaje privado
Aspecto general del chat integrado
Captura de pantalla de MTB a Fondo en un Android
Compartiendo información con Twitter
Otros Mundos
Otra de las cosas que he procurado proporcionar con MTB a Fondo es una facilidad para seguir la actividad del sitio. Esto no se limita al seguimiento mediante RSS que comentaba antes, sino que he integrado la publicación de la actividad de la página en Facebook y en Twitter:
- Facebook: Para lograr la integración con Facebook, he creado una página (MTB a Fondo en Facebook) en la que se publican automáticamente las nuevas entradas de MTB a Fondo. Por desgracia, la sincronización no es bidireccional, por lo que, si bien es posible publicar cosas en la versión de FaceBook, estas publicaciones no aparecerán en MTB a Fondo. Pero espero mejorar esto. La sincronización se realiza mediante la aplicación de Facebook NetworkedBlogs.
- Twitter: ¡Tambien estamos en Twitter. Además de lo comentado anteriormente con respecto a Twitter, la propia MTB a Fondo tiene su correspondiente Twitter (MTB a Fondo en Twitter), donde igualmente se publican las novedades del sitio, y facilita seguir las novedades que acontezcan mediante esta popular aplicación.
MTB a Fondo en Facebook
MTB a Fondo en Twitter
Creo que con esto he desgranado lo más importante de la página, en lo que se refiere a los aspectos técnicos. Pero una web social no es nada sin sus usuarios. Por ello, animo a cualquiera que quiera participar en el sitio a que se registre, participe, disfrute con la página, y que la haga suya. ¡Adelante! 
Etiquetas: buddypress, facebook, gps, gpx, mtb, mtb a fondo, twitter, wordpress
Medidor de entropía
