Proyecto integrador · El micro:bit como vigía del barrio
Reto: Construye un vigía electrónico con micro:bit para un problema real de tu casa, colegio o barrio (alerta de inundación, vigilancia de cuarto a oscuras, conteo de personas en la biblioteca, alarma de puerta abierta, monitoreo de temperatura del aula, etc.). Debe usar al menos un sensor, lógica condicional compuesta con AND/OR/NOT, umbrales calibrados con datos reales y validación por escenarios. Termina con sustentación pública del oficio.
En los barrios de Cartago, hasta los años 90, hubo un personaje silencioso que llegaba a las casas con una caja de herramientas y un voltímetro: el electricista del barrio. Cuando se iba la luz de un bombillo o de toda una casa, su método no era cambiar piezas al azar: era lógica aplicada paso a paso. Empezaba preguntando: ¿cuándo se fue?, ¿se fueron las otras casas también? Después medía en distintos puntos: ¿hay corriente AND el bombillo no enciende?, ¿hay corriente OR solo en algunos tomacorrientes?, ¿es NOT problema de la red, sino del circuito de la casa?. Cada medición confirmaba o descartaba una hipótesis hasta llegar al fallo concreto. Esa práctica era lógica condicional aplicada a un problema físico real: el mismo if-else-if con AND/OR/NOT que ejecuta un micro:bit cuando lee sensores y dispara actuadores. La diferencia entre el electricista del barrio y un programador con MakeCode no es el oficio: es el medio.
- 📦 Kit micro:bit (1 por equipo) con cable USB
- 📦 MakeCode online (makecode.microbit.org) o app móvil
- 📦 Sensores adicionales si los hay: humedad, distancia, sonido
- 📦 Cuaderno de bitácora del relojero (papel o digital)
- 📦 Acceso a IA generativa para asistencia en pseudocódigo (no para reemplazar el oficio)
- 📦 Ambiente real para probar el vigía (casa, aula, biblioteca, jardín)
Las 10 sesiones del período cuyas competencias se ponen en juego en este proyecto.
- 1 Lógica avanzada: if-else con AND, OR y NOT
- 2 Tablas de verdad: reglas universales
- 3 Algoritmos: del pseudocódigo al diagrama de flujo
- 4 Sensores en MakeCode: micro:bit que siente
- 5 Actuadores: LEDs, sonido, coreografía
- 6 Sensores con variables y umbrales calibrados
- 7 Depuración: una hipótesis, una prueba, un resultado
- 8 Alertas con lógica compuesta y validación por escenarios
- 9 Proyecto de monitoreo: el micro:bit como vigía
- 10 Sustentación del proyecto técnico
Entregables del proyecto
4 entregablesCada entregable es una unidad cerrada: qué se entrega, cómo se hace, reflexión incrustada del triángulo (Dussel · Estoico · Floridi), y criterios observables.
Problema observado + algoritmo en pseudocódigo + diagrama de flujo
Dussel · voz reconocidaQué entregas
Documento de 1-2 páginas con: problema real observado en casa/colegio/barrio (no inventado), justificación de por qué importa, algoritmo en pseudocódigo (escrito en lenguaje natural con if-else-if + AND/OR/NOT) y diagrama de flujo con simbología correcta (rectángulos, rombos, óvalos, flechas).
Cómo se hace
- 1 Observar el problema durante 1-2 días tomando notas
- 2 Decidir qué sensor del micro:bit aplica (luz, temperatura, movimiento, sonido)
- 3 Escribir el algoritmo en pseudocódigo con condicionales compuestas
- 4 Diagramar en draw.io o papel con simbología correcta
- 5 Mostrar el pseudocódigo a otro equipo para verificar que se entiende
💭 A quién protege y a quién no este vigía
En el documento, agrega una sección titulada "A quién protege y a quién no este vigía". Reconoce honestamente qué personas se benefician del sistema y a quién no llega: vecinos sin el dispositivo, personas con discapacidad auditiva si la alarma es solo sonora, personas mayores que no entienden el LED. Explica el sesgo de tu diseño. Esa sección queda en el documento entregado al docente y al destinatario del vigía. La lente del nosotros pregunta por las personas que el sistema no alcanza.
Criterios observables
- ✓ Problema real observado (no inventado)
- ✓ Justificación clara (por qué importa)
- ✓ Pseudocódigo con if-else-if + AND/OR/NOT
- ✓ Diagrama de flujo con simbología correcta
- ✓ Sección Dussel publicada en el documento
Programa MakeCode + calibración de umbrales con datos reales
Estoico · disciplina del tiempoQué entregas
Programa de MakeCode funcional cargado en el micro:bit, con: variables nombradas con sentido (no x, y, z), al menos 1 sensor leído, al menos 1 condicional compuesta con AND/OR/NOT, al menos 1 actuador (LED, sonido, pin externo) y umbrales calibrados con 5+ mediciones reales del ambiente. Acompañado de bitácora de calibración: 5 mediciones con contexto (hora, condición, lectura).
Cómo se hace
- 1 Programar en MakeCode con variables descriptivas
- 2 Tomar 5+ lecturas del sensor en distintas condiciones del ambiente
- 3 Decidir el umbral del condicional con base en esas lecturas
- 4 Cargar el programa al micro:bit y probar
- 5 Documentar la bitácora de calibración (no inventar umbrales)
💭 Lo que decidimos no programar todavía
En el código (comentario al inicio) o en una nota acompañante, agrega un párrafo titulado "Lo que decidimos no programar todavía". Declara qué features quisieron incluir y decidieron dejar fuera a propósito para esta versión: una alarma adicional que distraía, una conexión a internet que volvía el sistema frágil, un sensor que no estaba calibrado. Esa nota queda dentro del código fuente o en la documentación del vigía. El estoico entiende que el oficio del programador disciplinado es saber dónde no meter más complejidad sin antes validar.
Criterios observables
- ✓ Programa MakeCode funcional cargado en micro:bit
- ✓ Variables con nombres descriptivos (no x, y, z)
- ✓ Condicional compuesta con AND/OR/NOT visible en el código
- ✓ Bitácora de calibración con 5+ mediciones reales del ambiente
- ✓ Párrafo estoico publicado en código o documentación
Validación por escenarios + bitácora del relojero (depuración)
Floridi · infoesferaQué entregas
Tabla de validación con todos los escenarios posibles (si tienes n condiciones binarias, debes probar 2\^n combinaciones, ej. 3 sensores binarios = 8 escenarios). Para cada escenario: salida esperada y salida real observada. + Bitácora del relojero: mínimo 3 bugs detectados y corregidos con anatomía del oficio (hipótesis, prueba, resultado, una sola cosa cambiada a la vez).
Cómo se hace
- 1 Listar todos los escenarios posibles (tabla de verdad)
- 2 Probar el vigía en cada escenario (forzando las condiciones del ambiente)
- 3 Anotar salida esperada vs salida real
- 4 Cuando hay un bug, aplicar el método del relojero: 1 hipótesis, 1 prueba, 1 resultado
- 5 Documentar 3+ bugs corregidos con el flujo completo
💭 Mi vigía en la cadena informacional del barrio
En la bitácora del relojero, agrega una sección titulada "Mi vigía en la cadena informacional del barrio". Reflexiona: ¿qué información agrega tu vigía a la conversación del entorno?, ¿enriquece la seguridad o la organización del lugar o solo agrega ruido más?, ¿qué responsabilidad asumes por las alarmas que dispara o no dispara? Si el vigía falla y nadie reacciona, ¿qué responsabilidad queda con quien lo construyó? Esa sección queda en la bitácora entregada al docente y al destinatario del vigía. La ética de Floridi pregunta por el efecto del sistema en la cadena informacional del entorno.
Criterios observables
- ✓ Tabla de validación con todos los escenarios (mínimo 2\^n)
- ✓ Salida esperada vs salida real documentada
- ✓ 3+ bugs detectados y corregidos con bitácora del relojero
- ✓ Una sola cosa cambiada por intento (disciplina del relojero)
- ✓ Reflexión Floridi publicada en la bitácora
Sustentación con demo en vivo + entrega del vigía al destinatario
Dussel · voz reconocidaQué entregas
Sustentación de 5 minutos frente al grupo con demo en vivo del vigía funcionando (no captura estática) + entrega real del vigía al destinatario del entorno (familia, biblioteca, aula, jardín) con instrucciones de uso impresas + carta firmada del equipo con compromisos del triángulo.
Cómo se hace
- 1 Preparar guion de 5 min con estructura clara
- 2 Ensayar la demo en vivo en el ambiente real al menos 2 veces
- 3 Imprimir instrucciones de uso del vigía (1 página)
- 4 Entregar formalmente el vigía al destinatario
- 5 Escribir carta con compromisos verificables del triángulo
💭 Compromisos del equipo programador
En la carta del equipo, dedica un párrafo a cada lente del triángulo como compromisos verificables, no retóricos. Por Dussel: a qué persona del entorno que no protege el vigía actual nos comprometemos a integrar en v2 (alarma visual además de sonora, instrucciones en otro idioma, etc.). Por el estoico: qué disciplina personal sostendremos como programadores (no agregar features sin validar, no abandonar el vigía si falla, mantener bitácora). Por Floridi: qué información honesta seguiremos publicando sobre el desempeño real del vigía (cuándo falló, qué corregimos). Cada uno con decisión concreta y fechada.
Criterios observables
- ✓ Sustentación de 5 min exactos cronometrados
- ✓ Demo en vivo del vigía funcionando en ambiente real
- ✓ Instrucciones de uso impresas entregadas
- ✓ Vigía entregado realmente al destinatario
- ✓ Carta con compromisos verificables del triángulo
Un criterio por entregable + uno transversal de comunicación/triángulo. Niveles: Excelente (5) · Aceptable (3) · Por mejorar (1).
| Criterio | 5 Excelente | 3 Aceptable | 1 Por mejorar |
|---|---|---|---|
| Entregable 1 | Problema real observado, pseudocódigo correcto, diagrama de flujo, Dussel visible | Pseudocódigo con errores menores o diagrama incompleto | Problema inventado o sin algoritmo |
| Entregable 2 | Programa funcional, condicional compuesta, 5+ mediciones reales, estoico visible | Programa funcional pero umbrales no calibrados o variables vagas | Programa no funciona o sin condicional compuesta |
| Entregable 3 | Validación completa por escenarios, 3+ bugs con bitácora del relojero, Floridi visible | Validación parcial o bugs corregidos sin método del relojero | Sin validación o sin bitácora de depuración |
| Entregable 4 | 5 min, demo en vivo en ambiente real, entrega real al destinatario, compromisos triángulo | Demo en vivo pero sin entrega real al destinatario | No sustentó o vigía no funcionó en la demo |
| Coherencia del vigía: problema, algoritmo, calibración, validación y entrega | Las 4 partes dialogan; el vigía protege al destinatario nombrado en el problema inicial | Coherencia parcial entre las partes | Las partes parecen ejercicios separados |
Guion sugerido para la presentación final ante el grupo y la profe/el profe.
- 1 30 seg · Problema real observado y destinatario
- 2 1 min · Algoritmo en pseudocódigo + diagrama (qué decide el vigía)
- 3 2 min · Demo en vivo del vigía funcionando en ambiente real
- 4 1 min · Validación: tabla de escenarios + 1 bug corregido con método del relojero
- 5 30 seg · Compromisos del triángulo + entrega formal del vigía
Tu carta del equipo debe declarar honestamente: (1) si usaron IA para pseudocódigo o ideas, en qué tareas. (2) qué partes del oficio se hicieron sin IA (la calibración con datos reales, la depuración con el método del relojero, la prueba en ambiente real). (3) qué decisión técnica tomaron como equipo sin IA y por qué. (4) las 3 lentes del triángulo como compromisos verificables.
Cierras el periodo 2 con tu primer vigía electrónico funcionando en un ambiente real. El periodo 3 (Multimedia y ciberética) te pedirá llevar este criterio al cómo se cuenta, se muestra, se comparte la información. El electricista del barrio se va contigo a editar video.
Marca esta proyecto como completada
Cargando tu progreso…
Envíaselo a quien lo necesite
Tus compañeras y compañeros, padres o profesores pueden abrir esto directamente en su celular sin instalar nada.