PROYECTO A.R.E.S.
Arquitectura Robótica Híbrida de Exploración y Seguridad
para Entornos Inaccesibles
Electrónica III | Ingeniería en Telecomunicaciones | Unicafam
Alexander Quiroga · Jesús Aconcha · Kevin Ballestas · Samuel Saiz
Bogotá, 2026 – Versión Corregida (v2)
1. Resumen
El presente documento describe el diseño y desarrollo de A.R.E.S. (Arquitectura Robótica de
Exploración y Seguridad), un vehículo a escala 4WD concebido para inspeccionar y navegar entornos
donde el acceso humano está restringido por barreras físicas o riesgos a la integridad. Para resolver las
limitaciones de procesamiento a bordo, se implementa una arquitectura de robótica híbrida
(Cliente/Servidor). La capa de alto nivel emplea un módulo ESP32-CAM para transmitir video IP
mediante Wi-Fi a un servidor local, donde un script de visión artificial procesa el entorno y envía
comandos de navegación vía Bluetooth. Simultáneamente, la capa de bajo nivel, regida por un
microcontrolador Arduino Mega 2560, ejecuta rutinas de supervivencia autónomas: freno de emergencia
por ultrasonido y seguimiento de trayectoria mediante control PID y sensores infrarrojos.
Palabras Clave: Robótica Híbrida, Visión Artificial, Control PID, Edge Computing, Telemetría.
2. Introducción
La exploración de entornos colapsados, ductos industriales o zonas de desastre presenta un desafío
crítico: son lugares a los que el ser humano promedio no puede o no debe ingresar. Frente a esta
problemática, la robótica móvil se posiciona como la solución ideal para labores de reconocimiento.
El proyecto A.R.E.S. nace como una respuesta técnica a esta necesidad, proponiendo un vehículo
explorador de bajo costo pero alta redundancia. El proyecto integra directamente los saberes adquiridos
durante el semestre: el acondicionamiento de potencia para motores y procesadores (Electrónica 3), la
transmisión inalámbrica de video y comandos estructurados (Telecomunicaciones), el procesamiento de
la información del entorno mediante algoritmos matemáticos (Señales y Sistemas), y la integración lógica
a nivel de microcontrolador (Sistemas Digitales).
Objetivo General
Diseñar y construir un vehículo explorador 4WD tolerante a fallos, utilizando una arquitectura
computacional distribuida para navegar en entornos inaccesibles de forma remota y autónoma.
Objetivos Específicos
1. Implementar un enlace de transmisión de video Wi-Fi y recepción de datos por Bluetooth.
2. Diseñar un sistema de redundancia local que asuma el control autónomo del vehículo en caso
de pérdida de conexión con el servidor.
3. Programar un algoritmo de control PID para la corrección milimétrica de la trayectoria.
4. Desarrollar un sistema de freno activo independiente gestionado por interrupciones de
hardware.
3. Marco Teórico
3.1 Robótica Distribuida y Edge Computing
Consiste en trasladar la carga computacional pesada —como el procesamiento de imágenes— desde
el hardware móvil hacia un servidor externo local, utilizando el vehículo únicamente como nodo de
recolección de datos y ejecución de acciones físicas [1].
Aplicación en A.R.E.S.: El módulo ESP32-CAM actúa como nodo sensor que transmite el stream de
video vía Wi-Fi a un servidor PC local. Dicho servidor ejecuta el script de visión artificial (OpenCV) que
analiza el entorno y devuelve comandos de movimiento por Bluetooth. De este modo, el microcontrolador
Arduino Mega 2560 no requiere procesar imágenes y puede dedicar todos sus ciclos de reloj a las tareas
de control de bajo nivel (PID, ultrasonido), cumpliendo directamente con el Objetivo Específico 1.
3.2 Control PID
Es un mecanismo de control por retroalimentación utilizado para calcular el valor de error entre una
variable medida y un valor deseado. Su ecuación en el dominio del tiempo es:
u(t) = Kp·e(t) + Ki·∫₀ᵗ e(τ) dτ + Kd·[de(t)/dt]
Kp = ganancia proporcional Ki = ganancia integral Kd = ganancia derivativa e(t) = error = setpoint –
medición
Aplicación en A.R.E.S.: La regleta infrarroja QTR-8A entrega una lectura de posición que es comparada
con el valor deseado (trayectoria en línea recta). El error resultante se alimenta al algoritmo PID
implementado en el Arduino Mega 2560, el cual ajusta la velocidad diferencial de los motores derecho e
izquierdo para corregir la dirección sin oscilaciones abruptas, cumpliendo con el Objetivo Específico 3.
3.3 Frenado Dinámico Activo
A diferencia del frenado por inercia, el frenado activo en puentes H se logra cortocircuitando los
terminales del motor DC, lo que genera una fuerza contraelectromotriz que bloquea el rotor casi
instantáneamente [3].
Aplicación en A.R.E.S.: Los drivers TB6612FNG implementan esta técnica al recibir la señal de freno
desde Arduino. Cuando el sensor ultrasonido HC-SR04 detecta un obstáculo a menos de 15 cm, una
interrupción de hardware activa el frenado dinámico en menos de 12 ms, reduciendo la distancia de
frenado a 4 cm a 1 m/s, cumpliendo con el Objetivo Específico 4.
3.4 BMS y Regulación DC-DC Conmutada
El Battery Management System (BMS) protege el banco de baterías de iones de litio evaluando
continuamente el voltaje de cada celda, mientras que un convertidor Buck (LM2596) reduce la tensión
de forma eficiente mediante conmutación de alta frecuencia.
Aplicación en A.R.E.S.: El banco 3S (11.1V nominales) alimentado por el BMS de 20A asegura la
estabilidad de energía; el convertidor Buck LM2596 regula la salida a 6.0V para los drivers y el Arduino,
eliminando disipación térmica excesiva y maximizando la autonomía operativa del rover.
4. Metodología
La metodología de diseño se divide en tres fases iterativas: Hardware, Comunicaciones y Lógica de
Control. Cada fase está directamente vinculada con los objetivos específicos del proyecto.
Fase Actividades desarrolladas Obj. Específico(s)
Ensamblaje del chasis 4WD, integración BMS 3S,
OE3, OE4 (Bases de
Fase 1: Hardware regulador Buck LM2596, puentes H TB6612FNG y
hardware para PID y freno)
sensores (HC-SR04, QTR-8A, ESP32-CAM).
Configuración del stream MJPEG sobre Wi-Fi
Fase 2: (ESP32-CAM), protocolo de comandos Bluetooth OE1 (Enlace Wi-Fi /
Comunicaciones HC-05, pruebas de latencia y pérdida de Bluetooth)
paquetes.
Programación del algoritmo PID sobre lecturas
QTR-8A, sintonización de Kp y Kd,
Fase 3: Lógica de OE2, OE3, OE4
implementación de la interrupción de freno activo
Control (Redundancia, PID, freno)
y lógica de conmutación autónoma por pérdida de
señal.
Fase 1: Hardware — Enfoque Electrónica III
Esta fase concentra los saberes de Electrónica III: diseño de circuitos analógicos, acondicionamiento de
potencia, manejo de semiconductores y eficiencia energética.
1. Gestión y Protección de Potencia (BMS)
El banco de baterías opera en configuración 3S (11.1V nominales). El BMS de 20A actúa como circuito
de protección activa basado en comparadores de ventana y MOSFETs de corte, interrumpiendo la
carga/descarga si una celda cae por debajo de 3.0V o supera los 4.2V. Esto garantiza la estabilidad de
suministro para todo el rover durante la operación en campo.
2. Regulación DC-DC Conmutada (LM2596)
Para reducir los 11.1V/12.6V del banco a 6.0V estables, A.R.E.S. emplea un convertidor Buck LM2596
en lugar de reguladores lineales (LM78XX) que disiparían el exceso en calor. La alta eficiencia se logra
mediante conmutación rápida del transistor interno, filtrado por inductor y capacitor de salida, entregando
DC limpia a los actuadores.
3. Actuación de Estado Sólido (TB6612FNG)
El control de giro de los 4 motores DC se realiza mediante dos drivers TB6612FNG. A diferencia del
L298N (BJT), estos utilizan transistores MOSFET con RDSon extremadamente bajo, minimizando
caídas de tensión y eliminando la necesidad de disipadores térmicos, optimizando la transferencia de
potencia al sistema 4WD.
Fase 2: Sistema de Comunicaciones
Se estableció el enlace Wi-Fi para transmisión de video y Bluetooth para recepción de comandos. El
ESP32-CAM transmite el stream MJPEG a 640×480 px hacia el servidor local. El servidor ejecuta el
script de visión artificial (Python/OpenCV) y envía comandos codificados ('F', 'B', 'L', 'R', 'S') por el módulo
HC-05 al Arduino. Esta arquitectura cumple íntegramente el Objetivo Específico 1.
Fase 3: Lógica de Control
La lógica de control implementa dos capas de seguridad independientes:
5. Freno activo por interrupción hardware (Objetivo 4): al detectar obstáculo < 15 cm, el ISR
desactiva PWM y cortocircuita motores.
6. Redundancia autónoma (Objetivo 2): ante pérdida de señal Bluetooth > 500 ms, el sistema
conmuta automáticamente a modo PID con sensores QTR-8A.
7. Control PID de trayectoria (Objetivo 3): la diferencia entre la lectura del QTR-8A y el setpoint
(valor central = 3500) define el error. u(t) = Kp·e(t) + Kd·[Δe/Δt], ajustando la velocidad
diferencial de los motores.
// Lógica de Interrupción de Seguridad — Arduino Mega 2560
void verificarSeguridad() {
long distancia = medirUltrasonido(); // HC-SR04
if (distancia > 0 && distancia < 15) { // Umbral: 15 cm
frenoActivoMotor(); // Cortocircuito MOSFET
modoOperacion = MODO_EMERGENCIA;
[Link]("ALERTA: OBSTÁCULO. SISTEMA BLOQUEADO.");
}
}
// Control PID de trayectoria (modo redundante autónomo)
void controlPID() {
int posicion = leerQTR8A(); // Lectura 0–7000
int error = posicion - SETPOINT; // SETPOINT = 3500
int u = Kp*error + Kd*(error - errorAnterior);
[Link](BASE_SPEED - u);
[Link](BASE_SPEED + u);
errorAnterior = error;
}
5. Desarrollo y Resultados
El prototipo A.R.E.S. fue ensamblado en su totalidad y sometido a pruebas de estrés en pista controlada,
evaluando los dos escenarios críticos de operación: control remoto vía servidor y modo autónomo por
redundancia.
Tabla 1: Análisis de Latencia y Tiempos de Reacción
Latencia Promedio Dist. de Frenado a 1
Prueba Medio de Control
(ms) m/s (cm)
Frenado por Servidor Wi-Fi + Bluetooth 240 ms 35 cm
Frenado Autónomo
Interrupción Arduino 12 ms 4 cm
Local
Análisis: Como muestra la Tabla 1, depender exclusivamente del servidor para el frenado resultaba en
colisiones frecuentes por el "lag" de red (240 ms). La implementación del freno autónomo local mediante
interrupción hardware redujo la latencia a 12 ms y la distancia de frenado de 35 cm a 4 cm, validando el
Objetivo Específico 4. En las pruebas de pérdida de señal, el sistema conmutó exitosamente al modo
PID-QTR-8A, manteniendo el vehículo en trayectoria sin intervención del servidor, validando el Objetivo
Específico 2.
6. Conclusiones
8. Enlace de comunicaciones (OE1): Se logró implementar exitosamente el enlace Wi-Fi entre el
ESP32-CAM y el servidor local, transmitiendo video MJPEG de forma continua. La recepción de
comandos vía Bluetooth HC-05 fue validada con latencias de 240 ms en condiciones de entorno
controlado. Este objetivo se encuentra cumplido, aunque se identifica la saturación de la banda
de 2.4 GHz como un factor que degrada el rendimiento y que requiere manejo en la integración
final.
9. Sistema de redundancia autónoma (OE2): El mecanismo de conmutación automática al modo
QTR-8A ante pérdida de señal Bluetooth fue probado con éxito. El vehículo sostuvo el
seguimiento de trayectoria de forma autónoma durante el período de desconexión en todos los
ciclos de prueba ejecutados. Este objetivo está técnicamente cumplido en la fase de pruebas; su
validación definitiva se realizará en las pruebas finales de campo.
10. Control PID de trayectoria (OE3): El algoritmo PID fue implementado y las constantes Kp y Kd
se sintonizaron empíricamente mediante pruebas iterativas en pista. El vehículo sigue la línea
sin oscilaciones visibles en velocidad nominal. La sintonización de Ki (componente integral) está
en proceso de ajuste para eliminar el error estacionario en curvas pronunciadas. Este objetivo se
considera en progreso, con la fase de sintonización fina pendiente.
11. Freno activo por interrupción hardware (OE4): Este es el resultado más contundente del
proyecto: la reducción de la distancia de frenado de 35 cm (vía servidor) a 4 cm (interrupción
local) demuestra empíricamente la superioridad de la arquitectura híbrida con redundancia local
sobre el control exclusivamente remoto. El objetivo se considera plenamente cumplido.
12. Conclusión general: A la fecha de esta entrega, el Proyecto A.R.E.S. ha demostrado la
viabilidad técnica de una arquitectura de robótica híbrida de bajo costo para exploración de
entornos inaccesibles. Los Objetivos Específicos 1, 2 y 4 están verificados en pruebas; el OE3
requiere ajuste final de la componente integral del PID. La integración completa de las cuatro
asignaturas del semestre —Electrónica III, Telecomunicaciones, Señales y Sistemas, y Sistemas
Digitales— se refleja en cada capa funcional del vehículo, desde la gestión de potencia hasta los
algoritmos de control.
Retos identificados
• La saturación de la banda de 2.4 GHz en el entorno de pruebas generó pérdida de paquetes de
video, validando la necesidad del sistema de redundancia autónoma.
• La sintonización del componente Ki del PID requiere tiempo adicional de prueba en curvas de
diferente radio de curvatura.
Mejoras propuestas
• Migrar el cerebro central a una Raspberry Pi ejecutando ROS, eliminando la dependencia del
servidor externo.
• Integrar un módulo LiDAR para mapeo 3D del entorno, ampliando las capacidades de exploración
autónoma.
• Cambiar el canal de video a 5 GHz (módulo ESP32-S3) para evitar interferencia en ambientes
con alta densidad de redes Wi-Fi.
7. Referencias
[1] G. Hu, W. Tay y Y. Wen, "Cloud Robotics: Architecture, Challenges and Applications," IEEE Network,
vol. 26, no. 3, pp. 21-28, May-June 2012.
[2] K. Ogata, Ingeniería de control moderna, 5ta ed. Madrid: Pearson Educación, 2010.
[3] S. Monk, Programming Arduino Next Steps: Going Further with Sketches, 2nd ed. McGraw-Hill
Education, 2018.
Proyecto A.R.E.S. | Electrónica III | Unicafam 2026