A veces, en ingeniería, el reto no es solo crear algo nuevo, sino hacer que conviva con lo que ya existe. Hace poco estuve trabajando en un proyecto muy interesante que resume perfectamente esta idea: un sistema de gestión y registro de baterías (Datalogger) capaz de hablar dos “idiomas” distintos.
El problema: Lo viejo vs. Lo nuevo
En el mundo de las baterías hay, básicamente, dos grandes grupos conviviendo:
Las baterías “inteligentes” (SBS): Son las modernas. Ellas mismas te dicen “estoy al 80%”, “tengo esta temperatura” o “me quedan tantos ciclos de vida”. Se comunican digitalmente.
Las baterías “tradicionales” (Analógicas): Son las de toda la vida. No “hablan”, así que para saber cómo están tienes que medir físicamente su voltaje, la corriente que entra y sale, y usar sondas externas para vigilar que no se calienten.
El objetivo era crear un cerebro único que pudiera manejar ambas situaciones sin despeinarse.
La solución: Un sistema híbrido
Desarrollé un firmware capaz de trabajar en dos modos. Si el sistema detecta una batería moderna, se comporta como un “host” digital: lee directamente los datos internos (voltaje, amperaje, salud de la batería) a través de protocolos de comunicación estándar. Es limpio y preciso.
Pero, si conectamos una batería analógica, el sistema cambia el chip. Pasa a usar sensores físicos para leer la corriente y el voltaje, y gestiona sondas de temperatura externas para asegurarse de que todo opera dentro de los márgenes de seguridad.
¿Por qué es útil esto?
Lo bonito de este desarrollo es la versatilidad. El dispositivo no solo gestiona la carga, sino que actúa como una “caja negra”:
Registro de datos: Guarda un historial diario en una tarjeta SD con todo lo que pasa (ciclos de carga, temperaturas, potencias…).
Seguridad: Tiene alarmas programadas. Si una batería se calienta demasiado o baja de cierto nivel, el sistema avisa y corta para prevenir daños, da igual si la batería es digital o analógica.
Visualización: Toda la info se muestra sencilla en una pantalla OLED para que el usuario sepa qué pasa de un vistazo.
Al final, este proyecto ha sido un buen ejercicio de adaptación. La electrónica sirve para hacer de puente entre tecnologías distintas, alargando la vida útil de los equipos y mejorando la seguridad, sea cual sea la batería que se use.
Este proyecto implementa un sistema básico para medir la humedad del suelo mediante un microcontrolador, optimizando el consumo de energía de la sonda gracias a un pin de alimentación controlado por software. Está diseñado para facilitar la integración en entornos de bajo consumo o alimentados por baterías.
Obtener lecturas confiables del nivel de humedad del suelo mientras se evita la corrosión y el consumo innecesario de corriente de la sonda, encendiéndola solo durante el tiempo mínimo necesario para la medición.
Estructura del proyecto
El código está organizado en tres partes principales:
1. Encabezado (moisture.h)
Define la interfaz de uso:
moistureInit(): inicializa los pines para alimentar la sonda y leer la señal analógica.
moistureSetWarmup(): permite configurar el tiempo de precalentamiento antes de la medición.
moistureRead(): realiza la lectura del valor crudo del ADC.
2. Implementación (moisture.cpp)
Contiene la lógica de funcionamiento:
Al inicializar, configura el pin de alimentación como salida y lo apaga por defecto.
Durante la lectura, habilita la alimentación, espera el tiempo de calentamiento configurado (300 ms por defecto) y luego toma la muestra analógica.
Apaga la alimentación inmediatamente después de la lectura para reducir la corrosión y el consumo.
3. Sketch principal (moisture1.ino)
Ejemplo de uso que inicializa el sensor con pines definidos, configura el precalentamiento si es necesario y lee los valores de humedad periódicamente, mostrando los resultados por el puerto serial.
Características destacadas
Control programático de la alimentación de la sonda.
Configuración flexible del tiempo de precalentamiento.
Lectura directa del valor analógico en formato crudo (0–1023).
Diseño modular para facilitar la reutilización en otros proyectos.
Aplicaciones
El sistema está pensado para proyectos de riego automático, monitoreo de jardines o cultivos, y cualquier implementación que requiera reducir el consumo y prolongar la vida útil de sondas de humedad
Proyecto de programación de acciones e iteraciones en Software para ubicar las esferas en diferentes posiciones.
Un brazo robótico es un dispositivo mecánico controlado por computadora que se utiliza para manipular objetos de manera similar a un brazo humano. Estos brazos robóticos se pueden programar para realizar una variedad de tareas, desde simples movimientos hasta operaciones más complejas. La programación de acciones e iteraciones en software es fundamental para controlar y coordinar los movimientos del brazo robótico.
Arduino es una plataforma electrónica de código abierto que se utiliza ampliamente en proyectos de robótica, incluidos los brazos robóticos. Proporciona una forma fácil de controlar y programar componentes electrónicos, lo que permite a los ingenieros y aficionados crear sus propios sistemas robóticos.
La ingeniería mecatrónica es una disciplina que combina elementos de ingeniería mecánica, electrónica y de control para diseñar y construir sistemas automatizados. Los brazos robóticos son un ejemplo común de aplicación de la ingeniería mecatrónica, ya que requieren conocimientos en estas áreas para su diseño y programación.
Primeros pasos con ESP32 Bluetooth Low Energy (BLE) en Arduino IDE – Bluetooth de Bajo Consumo de Energía
El ESP32 cuenta con con Bluetooth Clásico y Bluetooth Low Energy (BLE)
Esta publicación es una introducción a BLE con el ESP32.
En esta sección: ¿Qué es BLE y para qué se puede usar?
También algunos ejemplos con el ESP32 usando Arduino IDE.
¿Qué es Bluetooth de baja energía?
Bluetooth Low Energy, BLE para abreviar, es una variante de ahorro de energía de Bluetooth. La aplicación principal de BLE es la transmisión a corta distancia de pequeñas cantidades de datos (bajo ancho de banda).
A diferencia de Bluetooth Clásico, que siempre está activado, BLE permanece en modo de suspensión constantemente, excepto cuando se inicia una conexión.
Comparado con Bluetooth clásico, Bluetooth Low Energy está diseñado para proporcionar un bajo consumo de energía, manteniendo un rango de alcance de comunicación similar.
Esto hace que consuma muy poca energía. BLE consume aproximadamente 100 veces menos energía que Bluetooth (según el caso de uso).
Además, BLE admite no solo la comunicación punto a punto, sino también el modo de transmisión y la red de malla.
Servidor y cliente BLE
Con Bluetooth Low Energy, hay dos tipos de dispositivos: el servidor y el cliente.
El ESP32 puede actuar como cliente o como servidor. El servidor anuncia su existencia, por lo que otros dispositivos pueden encontrarlo y contiene datos que el cliente puede leer. El cliente escanea los dispositivos cercanos y, cuando encuentra el servidor que está buscando, establece una conexión y escucha los datos entrantes. Esto se llama comunicación punto a punto.
Hay otros modos de comunicación posibles, como el modo de transmisión y la red de malla.
GATT
GATT significa Atributos Genéricos y define una estructura de datos jerárquica que está expuesta a los dispositivos BLE conectados. Esto significa que GATT define la forma en que dos dispositivos BLE envían y reciben mensajes estándar. Comprender esta jerarquía es importante porque facilitará la comprensión de cómo usar BLE con el ESP32.
Perfil: colección estándar de servicios para un caso de uso específico;
Servicio: recopilación de información relacionada, como lecturas de sensores, nivel de batería, frecuencia cardíaca, etc.;
Característica: es donde se guardan los datos reales en la jerarquía (valor);
Descriptor: metadatos sobre los datos;
Propiedades: describe cómo se puede interactuar con el valor característico. Por ejemplo: leer, escribir, notificar, difundir, indicar, etc.
En nuestro ejemplo, crearemos un servicio con dos características.
Uno para la temperatura y otro para la humedad.
Las lecturas reales de temperatura y humedad se guardan en el valor bajo sus características. Cada característica tiene la propiedad de notificación, de modo que notifique al cliente cada vez que cambien los valores.
UUI
Cada servicio, característica y descriptor tiene un UUID (Universally Unique Identifier). Un UUID es un número único de 128 bits (16 bytes).
Por ejemplo:
55072829-bc9e-4c53-938a-74a6d4c78776
Hay UUID abreviados para todos los tipos, servicios y perfiles especificados en el SIG (Bluetooth Special Interest Group).
Si su aplicación necesita su propio UUID, puede generarlo utilizando este sitio web generador de UUID.
En resumen, el UUID se utiliza para identificar información de manera única. Por ejemplo, puede identificar un servicio particular proporcionado por un dispositivo Bluetooth.
Conectando el ESP32
Este ejemplo funcionaría para cualquier placa de desarrollo actual con ESP-32. En este caco se utilizaron las siguientes placas: