Uno de los principales problemas que enfrentamos al diseñar un vehículo autónomo de naturaleza exploratoria es el cómo generar un registro seguro de los datos recopilados.
En nuestro caso tenemos como objetivo lograr un almacenamiento seguro en tres medios:
- En una base de datos SQLite gestionada por la aplicación en el smartphone Android principal.
- En una planilla de cálculo en la nube mediante Google Drive.
- En una tarjeta SD externa como respaldo local de los datos de los sensores que se envían al celular principal.
Es este último caso el que nos ocupó esta semana, que es un caso clásico de "caja negra": un dispositivo que registra, de forma automática y constante, los datos de navegación del vehículo, y que, por seguridad, se dispone en un compartimento "más seguro" en caso de que el vehículo sufra un accidente. De esa manera, aún si todo el resto del equipamiento y registros se pierde, un registro de los datos más importantes se mantiene seguro y la misión no es un fracaso total.
Esta idea estaba en los listados originales de funciones planeadas, pero tuvo que descartarse cuando el módulo SD que obtuvimos falló constantemente, con tremendos problemas de corrupción de archivos en la tarjeta SD.
![]() |
El módulo SD genérico que usamos en nuestra sonda (ya sé, ya sé, la tarjeta SD es una pieza de museo, pero es útil para pruebas). |
En su momento se decidió que el módulo tenía una falla de fábrica y se continuó adelante. Al recomenzar el trabajo este año le dimos una nueva oportunidad, esta vez suponiendo que la falla la cometimos nosotros en el cableado del módulo. Así que investigamos más y descubrimos nuestro error: nos faltaron unos resistores en el circuito, lo cual causaba los problemas que tuvimos antes.
Cuando vimos que el módulo funcionaba bien, volvimos a la mesa de diseño y la "caja negra" volvió al listado de funcionalidades de nuestra sonda.
El diseño implicó un poco más de trabajo mental, ¿cómo debe funcionar esta "caja negra"? hay dos posibilidades:
- Un registro activo: o sea, que la aplicación en el smartphone o el sketch en el Arduino Nano que controla los sensores envían un registro a la "caja negra" cada vez que se genera una lectura de los mismos. Eso implicaría desviar tiempo de proceso (y por lo tanto recursos) para esa acción específica y que podrían faltarnos a la larga.
- Un registro pasivo: la "caja negra" registra los datos "de pasada", sin intervención del smartphone o el Nano. Esta opción es, de hecho, la que se asemeja más al diseño de las cajas negras usadas en los aviones, pero tiene la desventaja de que los registros no tendrían marca de tiempo, ya que esta es agregada por la aplicación en el smartphone al guardar el registro en la base de datos. Afortunadamente, es un problema que se puede resolver con cierta sencillez, mediante un módulo RTC (Real Time Clock, ó "Reloj en Tiempo Real").
![]() |
Módulo RTC basado en el integrado DS1302 |
Si bien los DS1302 tienen algo de mala fama (al parecer tienden a tener problemas en el cristal), es el que tenemos a mano y vamos a jugarnos la camiseta con el.
La obtención de los datos se realiza mediante el pin TX de un Arduino Nano conectado en paralelo a la línea serial que va del Nano principal al IOIO OTG, de forma que cada vez que el Nano principal "le habla" al IOIO, al mismo tiempo la "caja negra" lo registra, obteniendo la marca de tiempo del DS1302 y añadiendo esa información a un archivo de texto en la tarjeta SD. Eso nos deja tan solo la obtención de la fecha y hora actuales, que sí debe hacerse de forma activa. Para ello dispusimos una línea serial que comunicará el IOIO OTG con la "caja negra" que es la que permite establecer esos valores, una tarea que, en principio, se realizará de forma manual mediante las funciones de diagnóstico de la aplicación en el smartphone (que de todas maneras hay que ejecutar en el momento previo al lanzamiento). Al final le agregamos un LED RGB para tener una idea del estado de funcionamiento del sistema y un botón de reset.
El resultado final es este prototipo:
Esa monstruosidad de cables se explica un poco mejor en el siguiente esquema realizado con Fritzing:
Usamos extensivamente la documentación oficial de Arduino, sin la cual hubiera sido imposible. Para el manejo del DS1302 usamos la librería proporcionada por el blog Osoyoo.com en esta publicación, la cual fue muy útil para desarrollar nuestro sketch de Arduino.
Prof. Sebastián de los Ángeles
No hay comentarios.:
Publicar un comentario