Un microcontrolador ejecuta un programa y se comunica con entradas y salidas físicas. Conservamos variables, decisiones y funciones aprendidas con Python, pero necesitamos adaptar lenguaje, bibliotecas y entorno. En Arduino C++ para ESP32, setup() prepara el dispositivo al arrancar y loop() se repite mientras funciona. Las llaves delimitan bloques, muchas instrucciones terminan en punto y coma y la sangría ayuda a leer. Copiar un archivo Python no lo convierte a C++.

Un tipo expresa qué clase de dato maneja una variable. bool representa true o false; una constante declarada con const no debe reasignarse. Para tiempos del patrón de aula se usa unsigned long. Una función void no devuelve un valor al llamador, aunque puede realizar una acción como Serial.println(). Definir una función no la ejecuta: necesita una llamada con sus argumentos. El mensaje serie informa sobre el programa, pero no demuestra movimiento físico. Separar información y actuación permite comprobar primero decisiones sin acoplar todavía un mecanismo.

La alimentación suministra energía; la señal comunica información. Un módulo puede alimentarse de una forma y entregar una señal con requisitos diferentes. Un GPIO de ESP32 no admite cualquier tensión porque el conector del módulo indique 5 V. Antes del montaje se consulta el modelo exacto de placa, shield y componente para comprobar compatibilidad, polaridad y adaptación necesaria. No se deducen los pines por parecido con otra placa.

El número de un conector del shield puede no ser el número GPIO utilizado en el código. La ficha de montaje relaciona ambos y declara alimentación, señal y referencia común GND cuando la interfaz validada la requiere. Una entrada digital representa HIGH o LOW; que LOW signifique detección depende del módulo. Un pin sin nivel definido puede quedar flotante y cambiar sin una detección real. Pull-up y pull-down ayudan a establecer niveles, pero su uso depende del GPIO y del circuito. La configuración se valida con documentación antes de conectar el sistema desconectado.

Para que un controlador decida, primero necesita entradas con un significado acordado. pinMode configura el uso de un GPIO, digitalRead obtiene su nivel digital y digitalWrite fija el nivel de una salida configurada para ello. Sin embargo, HIGH y LOW describen niveles, no situaciones completas. El adaptador interpreta la polaridad del módulo y entrega a la lógica detección, parada y validez. Si la lectura es analógica, también hacen falta rango, resolución y relación con la magnitud: llamar distancia a un valor bruto no lo convierte en centímetros.

Esta traducción permite separar lectura, decisión de estado y aplicación de salida. La lógica trabaja con significados estables, mientras el adaptador reúne los detalles del hardware. Por eso puede comprobarse primero con condiciones conocidas generadas por serie. La orden 1 activa detección y 0 la retira; p activa parada, r la libera y x simula invalidez. Son entradas de ensayo que permiten repetir una secuencia. Al incorporar el sensor, se comprueba que su señal produzca el significado esperado.

Cada prueba demuestra una parte de ese recorrido. Simular invalidez comprueba cómo responde la lógica, pero no añade capacidad para descubrir una avería física. El lector digital básico no identifica automáticamente un cable desconectado; ese diagnóstico necesita una comprobación adicional validada. De igual modo, recibir una detección correcta todavía no demuestra que el mecanismo se mueva. La salida comienza desactivada y se aplica después de decidir el estado, de modo que las distintas condiciones se resuelvan antes de emitir una orden y no produzcan actuaciones contradictorias.

Un estado resume una situación anterior que importa para decidir ahora. REPOSO, DETECTADO, ACTUANDO y PARADO representan situaciones del mismo controlador, no dispositivos diferentes. Una transición relaciona estado actual, condición y estado siguiente. REPOSO pasa a DETECTADO cuando comienza una detección válida; DETECTADO conserva la verificación mientras continúa y pasa a ACTUANDO al cumplir el plazo. Si desaparece antes, vuelve a REPOSO y se pierde aquella verificación.

La parada o una lectura inválida tienen prioridad y llevan a PARADO desde cualquier estado, desactivando salida. Al liberar parada y recuperar validez, no se reanuda una actuación antigua: si sigue habiendo detección se inicia otra verificación. La tabla de transiciones obliga a describir estos casos, incluidos los que un dibujo omitiría. Un enumerado permite nombrar el conjunto de estados en el código. El orden de condiciones debe conservar la prioridad; varios if independientes pueden contradecirse si una rama posterior vuelve a activar lo que la parada había desactivado.

La detección del proyecto debe mantenerse durante 1000 ms, es decir, un segundo, antes de permitir la actuación. Durante ese intervalo siguen importando las demás entradas: una parada puede llegar mientras se verifica la detección. delay(1000) detiene la continuación de la secuencia que lo ejecuta y puede retrasar una parada comprobada allí. La temporización sin bloqueo resuelve esa necesidad conservando el instante de inicio y consultando el tiempo después, mientras loop continúa su recorrido de lectura y decisión.

millis() proporciona un contador en milisegundos. El patrón utiliza tiempos unsigned long y calcula ahora – inicioDeteccion para saber cuánto ha transcurrido desde el comienzo. La comparación >= incluye el momento en que se alcanza el plazo. El inicio se guarda al entrar en DETECTADO; actualizarlo en cada vuelta haría comenzar de nuevo la cuenta una y otra vez. En cambio, perder la detección antes del plazo sí obliga a abandonar aquella verificación: el requisito pide continuidad, no sumar intervalos separados.

Cumplir el tiempo es solo una de las condiciones para actuar. En las vueltas del bucle también se revisan detección, validez y parada, cuya prioridad se conserva durante la espera y la actuación. El contador tiene tamaño finito, por lo que se mantiene el patrón de resta sin signo en lugar de sustituirlo por sumas arbitrarias. Además, el programa observa el plazo cuando vuelve a comprobarlo. Otras instrucciones pueden introducir retrasos y la frecuencia de loop limita esa observación; temporizar sin bloqueo no promete respuesta instantánea ni precisión ilimitada.

Un mecanismo relaciona piezas para transmitir o guiar movimiento. Una barrera idealizada gira alrededor de un eje: una variable angular independiente describe su posición y, en ese modelo, tiene un grado de libertad. Contar posiciones cerrada, intermedia y abierta no añade grados de libertad. Una base móvil se desplaza y orienta sobre una superficie; un brazo articulado combina articulaciones; una configuración cartesiana desplaza según ejes. No se deduce toda su movilidad contando motores.

La elección depende de tarea, alcance, carga, espacio de trabajo y estructura. Para la maqueta, un indicador comprueba primero la orden sin movimiento. Si después se incorpora servo, se revisan alimentación, señal, biblioteca y recorrido admisible del modelo. La orden de posición no garantiza por sí sola un ángulo físico exacto ni un trayecto libre. El soporte debe permitir movimiento, retorno, acceso y mantenimiento sin forzar topes ni cables. Se revisa mecánicamente con el sistema desconectado antes de una prueba funcional supervisada, conservando piezas desmontables y reutilizables.

Una prueba lógica comprueba decisiones con entradas conocidas; una prueba física añade sensor, conexiones, alimentación y mecanismo. Ambas son necesarias y aportan evidencias distintas. Para investigar un fallo, recorre lectura, interpretación, estado, orden y efecto físico. El primer punto que discrepa orienta una hipótesis, sin demostrarla todavía. Una fotografía final no permite reconstruir el recorrido ni decidir si un mensaje corresponde a la versión actual del programa.

Si el sistema permanece en DETECTADO, puede reiniciar continuamente el tiempo o recibir una detección inestable. Una entrada serie estable ayuda a distinguirlos antes de modificar el filtro. Si aparece ACTUANDO y no hay movimiento, revisa el tramo de salida y montaje con la ficha validada; no alteres al azar las transiciones que ya funcionan. Tras reparar, repite el caso inicial y otros relevantes, incluida parada y recuperación. Registra versión, condiciones, esperado, observado, hipótesis y resultado. Una mejora sostenible puede facilitar mantenimiento o reutilización, pero debe conservar la función comprobada del conjunto.

Una prueba de aceptación vincula un requisito con una acción y un resultado observable. El controlador debe desactivar salida en reposo, ignorar una detección menor de 1000 ms y actuar cuando continúa hasta el plazo. También debe atender parada o invalidez desde actuación y volver a verificar tras recuperarse. El caso exacto de igualdad temporal importa, igual que una parada durante la verificación; no son equivalentes a probar solo el inicio y el final.

El registro declara si la entrada procede del sensor o de serie y qué capacidad de diagnóstico existe realmente. Una invalidez simulada verifica prioridad lógica, sin acreditar detección física de desconexión. Para el producto se reúne código editable, ficha de conexiones, esquema de mecanismo y pruebas del montaje integrado. La mejora necesita comparación antes y después bajo condiciones descritas, y cada integrante debe explicar una decisión y una modificación. Reconocer límites forma parte del resultado: la maqueta ensaya control educativo y no certifica protección de personas, precisión mecánica ni seguridad de una puerta real.