Diseño de aplicaciones en la nube, basadas en IA

0. Motivación
1. Descripción
2. Desarrollo
3. Diccionario técnico
4. Agradecimientos y Fuentes de Información

0) Motivación

al hilo digital forma parte de mi concepto de observatorio, un producto nacido de mis inquietudes y desarrollado a partir de las limitaciones de la pandemia, siempre con un enfoque educativo y con contenido para distintos rangos de edad.

En este artículo quiero explicar, con un lenguaje sencillo, que para obtener un buen rendimiento de las herramientas que nos proporciona la IA, es imprescindible ser precisos y organizados.

Diseñar aplicaciones con vibe coding no es una tarea sencilla.

No basta con lanzar prompts al aire y esperar que el sistema “adivine” lo que queremos.

Sin una arquitectura clara, sin principios básicos y sin un contexto sólido para el Agent, el resultado es un proyecto que avanza a golpes de improvisación: ahora esto, ahora aquello, sin ton ni son.

Mi Observatorio es el ejemplo elegido para aplicar esta filosofía, no improvisar, de construir un sistema modular, gobernado y sostenible.

Y estos dos documentos — replit.md y procedimiento.md — son la prueba de ese método:

no son código, son criterio, la base que permite que un proyecto crezca sin romperse.

1) Descripción

Mi Observatorio es un observatorio urbano desarrollado al 100% con el Agent de Replit, bajo mi dirección, basado en 20 widgets o tarjetas configurables en un dashboard, que muestran información de interés en diferentes ámbitos y circunscrito a nivel nacional (me encanta aquello donde dice: Mi Observatorio — Hecho con ♡ en España).

Es un producto SaaS modular, es decir, una aplicación en la nube construida como un conjunto de módulos independientes, coherentes y actualizables, que funcionan juntos sin romperse.

Puedes encontrarlo en la siguiente dirección web y probarlo sin problemas, eso si a pesar de su buena apariencia, no hay un solo mes que no tenga que corregir algun bug, alguna caida de servicio, una tarjeta que no responde o no responde con lo esperado, requiere un mantenimiento y dedicación:

https://mi-observatorio.replit.app/

Cada tarjeta es un microservicio visual que:

• Consume una fuente de datos externa (API, scraping ligero, dataset propio).
• Procesa la información.
• La muestra en un formato compacto y visual.
• Se actualiza de forma independiente.

Esto sigue el patrón de diseño de un Urban Data Observatory, pero llevado a un formato personal, ligero y configurable.

En resumen, es un ecosistema de 20 micro‑observatorios, cada uno con su propia lógica.

1.a) En Mi Observatorio hay tres enfoques fundamentales

1.a.1) Modularidad real

Cada tarjeta es independiente.

Esto permite añadir, quitar o mejorar widgets sin afectar al resto.

1.a.2) Fuentes de datos heterogéneas

Se combinan:

APIs oficiales, APIs abiertas, Scraping ligero, Datasets propios, Fuentes nacionales e internacionales.

1.a.3) Diseño compacto y claro

Las tarjetas son:

Minimalistas, Rápidas de leer, Consistentes, Adaptadas a dispositivos móviles.

1.b) Dos herramientas fundamentales en Mi Observatorio

Diseñadas para que el Agent IA trabaje dentro de un sistema, con reglas, y no improvisando.

1.b.1) replit.md — La Arquitectura

• Visión general del proyecto
• Estructura del proyecto
• Servicios Backend
• Servicios Frontend
• Base de datos
• Ciclo de vida de un módulo nuevo
• Versionado
• Reglas de calidad
• Problemas conocidos y soluciones

1.b.2) procedimiento.md — El Método

• Principios del proyecto
• Reglas para integrar datos
• Contrato backend
• Contrato frontend
• Ciclo de vida de un módulo nuevo
• Sincronización dev → prod
• Reglas de calidad
• Errores comunes y cómo evitarlos
• Checklist antes de merge
• Checklist para integrar un módulo nuevo

2) Desarrollo

Ha sido toda una experiencia.

Ya conocía la herramienta: este IDE en la nube que me ha acompañado en muchos momentos.

Le debo cosas importantes, como haber servido de plataforma de enseñanza para una de mis hijas —HTML, CSS y JavaScript—, algún artículo y también para otros tantos experimentos con distintos lenguajes de programación.

Todo eso ocurrió antes de la IA, antes de que la empresa adoptara los modelos LLM como motor principal, como tantas otras, donde los lenguajes generativos han hecho su agosto.

Y no es malo, al menos en algunos aspectos.

Pero no debemos olvidarlo:

Las calles se pueden limpiar con máquinas,
pero para eso, las calles deben estar bien diseñadas.

Ahí es donde empieza la verdadera idea de una planificación correcta, la auténtica labor del ingeniero.

Porque la IA puede acelerar, puede ayudar, puede automatizar…, pero no puede sustituir el diseño, ni la arquitectura, ni el criterio.

Ese sigue siendo nuestro trabajo, me refiero a la parte humana.

En el formato empleado, es fácil seguir las reglas: en cierto modo, la base se repite.

Con un método de desarrollo claro, la dificultad y los verdaderos problemas se reducen a elegir buenas fuentes de datos: coherentes, honestas y actualizables.

El caparazón es común para casi todas las aplicaciones.

Y he de ser honesto: para esta aún me faltan muchas mejoras, pero incluso así, me parece un resultado muy respetable.

2.a) El caparazón

• Reglas para usuarios: cuentas, control de sesiones.
• Reglas para administradores: herramientas de mantenimiento.
• Panel de configuración: opciones, selección de widgets…
• Actualización de datos: fundamental cuando el sistema se pone tozudo.
• Temas: cómo quieres verlo, la UI.
• Créditos: explicación, contacto, o sea, yo.
• Privacidad: imprescindible si se piden permisos o se gestionan datos personales.
• Ayuda y versionado: aquí me he explayado; cuento cómo ha crecido la idea.
• Sistema de avisos: necesario para comunicar nuevas versiones, paradas, incidencias…

A futuro, ¿qué me quedaría?, entre otros:

• Sistema de alarmas: necesario para que no se te pase nada de nada.
• Más widgets: muchos más widgets.
• Relación de mecenazgo: lo más probable es que esta experiencia termine con mis ahorros.
• Y otros: ideas que irán apareciendo con el tiempo.

2.b) El alma: los widgets o tarjetas

Esto se repite en cada nuevo widget, es como un mantra.

Empiezas cada widget recordando replit.md y procedimiento.md, porque el Agent necesita contexto para comportarse como un ingeniero, no como un generador de código suelto.

Recordarle los documentos al Agent es tu forma de decir:

  “Este proyecto tiene reglas. No improvises. Construye dentro del sistema.”

¿Y cómo terminas?, pués Depurando bugs.

En cada nuevo widget la IA suele dejar un rastro de incorrecciones e incumplimientos de las reglas. Hay que estar atento y validar la información: en ocasiones hardcodea datos, los embebe en el código o usa fallbacks de primera sin criterio.

Regla de oro: nunca dés por bueno lo hecho por la IA.

Revísalo, ponlo a prueba, somételo a método.

Y entre medias, el desarrollo de cada widget: su núcleo gordiano, el punto donde se resuelve la complejidad y se define su comportamiento real.

Vamos a enumerar ciertos aspectos repetitivos respecto de este asunto:

2.b.0) Investigar, observar, coger ideas

Antes de escribir una línea de código, toca mirar alrededor: qué existe, qué funciona, qué inspira.

2.b.1) Elegir la fuente de datos

Fiable, pública y actualizable, a ser posible.

El ciclo de vida de los datos es tan importante como el widget en sí.

2.b.2) Método para obtener la información

API, scraping ligero o dataset propio.

Cada fuente exige un tratamiento distinto y unas reglas distintas.

2.b.3) Estructura de datos a utilizar

Normalmente un modelo JSON, claro y coherente.

Si la estructura falla, el widget falla.

2.b.4) Un layout aproximado

La IA suele tener patrones de diseño de UI muy avanzados, pero conviene marcar un esquema previo para evitar improvisaciones visuales.

2.b.5) Probar y probar

Hasta quedarse conforme.

La prueba es el filtro que separa un módulo funcional de un módulo que solo “parece” funcionar.

2.c) Una reflexión necesaria: el papel del criterio humano

Trabajar con IA en el diseño de aplicaciones en la nube te obliga a recordar algo esencial:

la IA no entiende el proyecto, entiende instrucciones, el proyecto lo entiendes tú.

Por eso, aunque el Agent pueda generar código, sugerir estructuras o acelerar tareas, hay un punto donde siempre aparece la diferencia entre un sistema improvisado y un sistema bien diseñado: el criterio.

• La IA no sabe si una fuente de datos es honesta.
• No sabe si un widget rompe la coherencia visual.
• No sabe si un fallback es aceptable o si está ocultando un error grave.
• No sabe si un dato embebido en código es un parche o un problema futuro.

Ese juicio es humano.

Y aquí aparece la aportación clave:

la IA no sustituye la ingeniería, la amplifica.

Cuando tienes un método, cuando defines reglas, cuando documentas, cuando revisas…, la IA se convierte en una herramienta potentísima.

Pero sin ese método, sin ese criterio, sin ese caparazón, la IA solo genera ruido.

Por eso este tipo de proyectos —como Mi Observatorio— son tan valiosos:

demuestran que la IA funciona mejor cuando trabaja dentro de un sistema, no cuando improvisa fuera de él.

En el fondo, diseñar aplicaciones en la nube basadas en IA es un ejercicio de equilibrio:

entre automatización y criterio, entre velocidad y estructura, entre potencia y responsabilidad.

Ese equilibrio es, precisamente, lo que convierte un experimento en un producto.

3) Diccionario técnico del artículo

Este diccionario recoge los términos técnicos usados en el artículo, con su equivalente universal cuando existe, y una explicación sencilla para lectores no versados.

• Agente / Agent

Universal: AI Agent

Sistema de IA que ejecuta tareas siguiendo instrucciones y contexto.

En el artículo, es el motor que construye los widgets y necesita reglas claras para no improvisar.

• IDE en la nube

Universal: Cloud IDE

Entorno de programación accesible desde el navegador, sin instalación.

Replit es el IDE que usas para enseñar, experimentar y desarrollar Mi Observatorio.

• LLM

Castellanizado: Modelo de lenguaje

Universal: Large Language Model

Modelo de IA capaz de generar texto, código y razonamiento.

En el artículo, describes cómo Replit adoptó LLMs como núcleo de su plataforma.

• SaaS

Castellanizado: Software como servicio

Universal: Software as a Service

Aplicación que funciona en la nube, sin instalación, siempre actualizada.

Mi Observatorio es un SaaS modular.

• Widget / Tarjeta

Universal: Widget / Card Component

Pequeño módulo visual que muestra información concreta.

En tu proyecto, cada widget es un micro‑observatorio con su propia lógica.

• Microservicio

Universal: Microservice

Pequeña pieza de software independiente que realiza una función concreta.

Cada widget de Mi Observatorio actúa como un microservicio visual.

• Backend

Universal: Backend

La parte del sistema que procesa datos, llama APIs y prepara la información.

En tu proyecto, cada widget tiene su propio servicio backend.

• Frontend

Universal: Frontend

La parte visual del sistema: lo que el usuario ve y toca.

Tus widgets tienen una UI minimalista y compacta.

• API

Castellanizado: Interfaz de programación de aplicaciones

Universal: API

Puerta de acceso a datos externos.

Tus widgets consumen APIs oficiales, abiertas y heterogéneas

• Scraping / Scraping ligero

Castellanizado: Raspado web

Universal: Web Scraping

Técnica para extraer datos de páginas web cuando no existe API.

En tu proyecto lo usas de forma ligera y controlada.

• Dataset

Castellanizado: Conjunto de datos

Universal: Dataset

Archivo estructurado con datos organizados.

Algunos widgets usan datasets propios.

• Fallback

Castellanizado: Valor de reserva

Universal: Fallback

Dato alternativo que se usa cuando la fuente principal falla.

La IA tiende a usar fallbacks sin avisar, por eso deben controlarse.

• Hardcodear

Universal: Hardcoding

Incluir datos fijos dentro del código en lugar de obtenerlos dinámicamente.

La IA suele hacerlo y es una de las cosas que siempre hay que revisar.

• UI

Castellanizado: Interfaz de usuario

Universal: User Interface (UI)

Aspecto visual de la aplicación: colores, temas, disposición.

Tus widgets tienen una UI minimalista y coherente.

• Versionado

Universal: Versioning

Proceso de registrar cambios y evoluciones del proyecto.

En tu artículo explicas cómo documentas la historia del Observatorio.

• Mecenazgo

Universal: Patronage / Sponsorship

Apoyo económico voluntario para sostener un proyecto.

Lo mencionas como posible vía futura para mantener el Observatorio.

• Núcleo gordiano

Universal: no tiene equivalente directo

Metáfora que describe el punto crítico donde se concentra la complejidad de un widget: lógica, datos, reglas y validación.

Es el lugar donde realmente “se decide” si el módulo funciona.

• Layout

Castellanizado: diseño de disposición

Universal: Layout

Estructura visual de un widget: cómo se organizan los elementos, bloques, tarjetas y datos.

La IA suele proponer layouts avanzados, pero conviene definir uno previo para evitar improvisaciones visuales.

• Modelo JSON

Universal: JSON data model

Formato estándar para representar datos estructurados.

Es la base de casi todos los widgets del Observatorio.

• Ciclo de vida de los datos

Universal: Data lifecycle

Proceso completo que siguen los datos: creación, actualización, caducidad y reemplazo.

Elegir fuentes con buen ciclo de vida es clave para que un widget no quede obsoleto.

• Depurar bugs

Universal: Debugging

Proceso de encontrar y corregir errores en el código o en la lógica del widget.

Es el paso final de cada módulo y donde más se nota la intervención humana.

• Mantra de desarrollo

Universal: no tiene equivalente directo

Conjunto de pasos repetitivos que se siguen en cada widget: reglas, contexto, datos, layout, pruebas.

Es la forma de evitar improvisación y mantener coherencia en todo el sistema.

4) Agradecimientos y Fuentes de Información

Mi Observatorio no existiría sin el trabajo, la constancia y la transparencia de decenas de instituciones, organismos, medios y servicios públicos, que ofrecen datos abiertos, actualizables y de calidad y otros en el ámbito privado, igualmente necesarios. A todas ellas, gracias.

A continuación se enumeran las fuentes de información utilizadas, organizadas por temática para facilitar su consulta:

📰 Medios de comunicación (nacionales, regionales e internacionales)

20 Minutos (todas sus ediciones: Andalucía, Aragón, Asturias, Baleares, Barcelona, Canarias, Cantabria, Castilla y León, Castilla-La Mancha, Extremadura, Galicia, Internacional, La Rioja, Madrid, Murcia, Nacional, Navarra, País Vasco, Valencia, Viajes y Aviación)

ABC España, ABC Internacional

Diario Sur

Diario de Sevilla

El Mundo España

El País España, El País Internacional

Europa Press Andalucía, Europa Press Extremadura

Genbeta

Hipertextual

La Vanguardia Barcelona

Xataka

🌦️ Meteorología, clima y medio ambiente

AEMET Avisos

AEMET OpenData

Meteoalarm

Open-Meteo Air Quality (CAMS)

Open-Meteo Forecast API

Open-Meteo Marine API

OpenWeatherMap

Infomedusas (IEO)

MedusApp

MITECO Boletín

MITECO — Red de Parques Nacionales

SAIH

SICA — Mapa Estratégico de Ruido

ADEAC — Banderas Azules España

Punt d'Informació Aerobiològica (PIA)

🚦 Movilidad, transporte y tráfico

DGT Incidencias

Renfe AVE/LD GTFS-RT

Renfe Cercanías GTFS-RT

AENA Noticias Aviación

📊 Economía, finanzas y energía

BCE — Euríbor 12 meses

Banco de España — BExplora (Tipo hipotecario)

Frankfurter API — Tipos de Cambio (BCE)

Yahoo Finance — Gas Natural TTF (TTF=F)

Yahoo Finance — Petróleo Brent (BZ=F)

Yahoo Finance — Índices Bursátiles

REE ESIOS — Mix de Generación

REE ESIOS — Precios Electricidad

Portal Estadístico del Notariado

España Stats — Estadísticas Inmobiliarias

INE — IPC General (variación anual)

🏀⚽ Deportes

API-SPORTS Women Basketball

ESPN Women Football

TheSportsDB

📚 Cultura, libros y divulgación

Google Books

Open Library

Blog Casa del Libro

OMDb API (Open Movie Database)

🌌 Ciencia y astronomía

NASA — Astronomy Picture of the Day (APOD)

CAHA — RSS Noticias

IAC — RSS Noticias

OAN — Observatorios Astronómicos (BD)

OAN — RSS Noticias

💧 Recursos hídricos

Embalses.net

iAgua DATA

Cada una de estas fuentes aporta una pieza del puzzle que hace posible Mi Observatorio:

datos fiables, públicos, actualizables y con un ciclo de vida adecuado para construir widgets sólidos y útiles.

Sin ellas, este proyecto no tendría sentido, ni habría sido posible

🧩 Las IAs usadas en este proyecto, como no mencionarlas, Replit (mi par en este desarrollo) y Copilot (ayuda a la redacción y generación de imágenes).

📜 Esto es solo un proyecto formativo

    Sin ánimo de lucro, por lo que si lo considerais útil en parte o en su totalidad, solo os pido a cambio una mención sobre el origen de la información, me haría gran ilusión saber que ha servido para que otros 'Devs', se animen a desarrollar su talento en el mundo de la IA (Inteligencia Artificial).

"Cuanto más observo, más me asombro - I am Robot”

El siglo XXI traerá transformaciones tecnológicas profundas y con ellas, cambiará nuestra forma de vivir. Los humanos se organizarán también, según el grado de aceptación - o resistencia - a estos cambios. Los sistemas de organización mundial que hoy conocemos quedarán obsoletos con rapidez y nuevos órganos de decisión, inmunes a las limitaciones del medio ambiente, tomarán el relevo.

Mientras tanto, la especie que un día creyó ocupar la cúspide de la pirámide, se enfrentará a su propia duda existencial.

Esto, solo es un guión cinematográfico, las historias - parte reales parte ficción - nos ayudan a entender y desarrollar algo esencial: el pensamiento crítico, el cuestionar o mantener opiniones contrarias, pretender la mejora continua, basada en una robusta metodología, es lo que nos permite evolucionar los sistemas… y también a nosotros mismos.

De eso vá este artículo. Del despertar de esa inquietud, de una ilusión, el sueño de aspirar a replicar el comportamiento propio de seres vivos o de cómo un conjunto de metal, silicio y baquelita, comienza a comportarse como algo más.

Estimados e inquietos lectores, estamos a punto de comenzar un viaje por: "Cuanto más observo, más me asombro - I am Robot”. Bon voyage.

🟧 Algo más que un montón de líneas de código

Cuando empezamos esta experiencia, el objetivo parecía sencillo: hacer que un robot (engendro electromecánico), siguiera una baliza roja.

Pero pronto descubrimos que el robot no era el único que tenía que aprender, también nosotros.

Lo que empezó como un ejercicio de programación con Python terminó convirtiéndose en una lección inesperada sobre "cómo pensar como un ingeniero":

• cómo lidiar con un hardware imperfecto y un entorno cambiante.
• cómo detectar errores usando logs y dashboard,
• cómo diseñar sistemas robustos en entornos ruidosos,
• y cómo transformar el caos en arquitectura estable y sostenible.

Este proyecto no va de servos, ni de cámaras, ni de distancias, va de algo mucho más importante:

La base para convertir un montón de líneas de código en un sistema que es capaz de tomar decisiones acertadas.

🧠 Robótica, ruido y pensamiento crítico

"Cómo un robot, que sigue una baliza, se convirte en una lección de ingeniería".

1. El mundo real no es un laboratorio.

La primera sorpresa llegó pronto: la batería y los sensores del Robot Hat V4 - cámara, ultrasonido, servos - no eran demasiado fiables.

• La capacidad de la batería, condicionaba las comunicaciones o respuestas.
• La cámara vibraba y generaba bounding boxes absurdos.
• El área de la baliza saltaba de 2000 a 40000 en un solo frame. Las luces y sombras contribuian con mas errores, a diferentes horas de prueba en el día, con diferentes resultados, bajo las mismas premisas.
• El ultrasonido daba 5 cm cuando estaba a 40.
• El robot perdía la baliza por un giro mínimo del chasis.

La primera lección fue inmediata:

   El hardware real es ruidoso el ruido no se elimina: se gestiona.

Aquí aparece el primer vínculo con el pensamiento crítico:

   No puedes confiar en un único dato. Necesitas contexto, criterios y validación.

2. El error clásico: programar reacciones, no sistemas

La primera versión del código era ingenua:

si veo la baliza → giro 
si no la veo → busco 
si está cerca → freno
          

Funcionaba en mi cabeza. Funcionaba en papel. Funcionaba incluso en el modo simulación, pero no en el robot en modo real:

• se quedaba mirando a un lado,
• entraba en bucles,
• perdía la baliza,
• se bloqueaba,
• o avanzaba cuando no debía.

El pensamiento crítico nos obligó a hacer la pregunta correcta: ¿Estoy reaccionando a los síntomas o entendiendo el sistema?

3. El caos como maestro

Durante semanas aparecieron fallos que parecían contradictorios:

• TRACK entraba en SEARCH sin motivo.
• RECENTER atrapado en un ángulo imposible
• TRACK arrollando la baliza
• NEAR se activaba demasiado pronto… o nunca
• SCAPE saltaba cuando no debía.
• RESET se encadenaba sin sentido.

Cada fallo era una pista. Cada pista me obligaba a cuestionar nuestras suposiciones.

Aquí aparece la segunda lección de pensamiento crítico:

   Cuando un sistema falla, no te preguntes “qué pasa”, pregunta mas bien “qué estoy asumiendo,  que no es cierto”.

4. La revelación: no necesitábamos más condiciones, mas código, mas desorden, sino mejor arquitectura

El punto de inflexión llegó cuando entendimos que:

• No era un problema de TILT.
• No era un problema de PAN.
• No era un problema de área.
• No era un problema de distancia.
• No era un problema de velocidad.

   Era un problema de arquitectura, del conjunto.

Estábamos intentando controlar un sistema complejo con condiciones sueltas, parcheadas. Eso nunca funciona.

La solución fue filosófica antes que técnica:

   Divide el mundo en zonas lógicas, espacios acotados, probados que funcionen y deja que cada estado gobierne su zona.

5. Nacen los validadores y la fusión de sensores

Aquí aparece la idea más poderosa del proyecto:

✔ No confíes en un único dato, construye conjunto de criterios que deban cumplirse.

Creamos dos validadores:

• valid_for_search → “¿esta detección es fiable para seguirla?”
• valid_for_near → “¿esta detección indica proximidad real?”

Y añadimos la capa de fusión visión + distancia:

• near_by_distance
• too_close_to_measure
• near_fused

Con ellos, el mundo del robot quedó dividido en zonas claras, con decisiones acotadas, mas precisas según el momento.

Esto es pensamiento crítico aplicado a robótica:

   No tomes decisiones por impulsos, fallo/corrijo. Tómalas por criterios.

6. La arquitectura final: simple, elegante, robusta

Con los validadores, los estados se volvieron puros, acotaban responsabilidad y daban su pase, de forma clara y segura:

• SEARCH → busca.
• RECENTER → alinea.
• TRACK → sigue.
• NEAR → gestiona proximidad.
• SCAPE → protege.
• RESET → estabiliza.

Cada estado hace una sola cosa y la hace bien, pasando correctamente al estado siguiente.

En resumen

Esta experiencia me enseñó algo que va mucho más allá de la robótica, de las líneas de código:

• El pensamiento crítico no es dudar de todo, es dudar de lo que importa.
• No es añadir más condiciones, es diseñar mejores estructuras.
• No es reaccionar al ruido, es entenderlo y darle significado.
• No es luchar contra el caos, es darle forma.
• No es corregir errores aislados, es entender y gestionar, dando lugar al correcto comportamiento.

Imágenes del Robot Hat V4

📚 Referencias

    Esto es solo una breve descripción, podreis encontrar mas información al respecto con todo el código en https://github.com/jmcaneda/picarx-pet

📜 Esto es un proyecto educativo

    Sin ánimo de lucro, por lo que si lo considerais útil en parte o en su totalidad, solo pido a cambio una mención sobre el origen de la información, me haría gran ilusión saber que ha servido para que otros 'Devs', se animen a desarrollar su talento en el mundo de la robótica con Python.

   ¿A quién puede beneficiar en el plano educativo?

Aficionados a la robótica

• Un proyecto accesible pero profundo
• Un robot que muestra comportamientos emergentes
• Un camino claro para aprender visión + control + lógica

Estudiantes de la ESO y bachillerato

• Introducción práctica a la robótica
• Comprensión real del ruido en sensores
• Pensamiento lógico y estructurado
• Motivación por ver “vida” en un robot

   No descarto en un futuro próximo, la realización de monográficos acerca de los problemas a los que nos enfrentamos a lo largo del desarrollo del proyecto, medidas que se fueron adoptando o sobre conocimientos básicos necesarios.

📜 Que necesitas saber y tener

    Este es un proyecto sencillo, pero aún así requiere de un conocimiento en programación Python, manejo de utilidades de consola, placa base y algo de robótica. Por otro lado es necesario contar con el hardware apropiado:

Conocimiento recomendado

• Lenguaje de comandos en línea: Shell.
• Editores de programación, nano, micro, VS Code.
• Lenguaje de programación Python.
• Conocimiento del Hardware de placa base y extensiones.
• Modos de conexión con dispositivos a distancia, por terminal o por escritorio remoto.
• Sistema para el control de versiones Git.
• Repositorio de código remoto Github.

Hardware recomendado

• Raspberry Pi 3B+ o superior.
• Robot Hat V4 (Picar‑X) de Sunfounder.
• Elementos auxiliares como cables USB-C, bridas, tuercas, tornillos...
• Bateria externa auxiliar, en mi caso INIU Power Bank 10000 mAh.

✨ Especial mención.

Promotores y medios formativos (la formación gratuita de calidad constituye una de las mejores palancas para el cambio y progreso, ayudándonos a enfrentar con éxito, los nuevos retos, día a día), la formación gratuita es dos veces buena, prácticala y ayuda a extenderla.

Entre castigo y bendición, el regalo que me hizo mirar hacia la robótica https://docs.sunfounder.com/projects/picar-x-v20/es/latest/index.html

La ayuda en línea, si quieres llegar lejos, acompañate de los pares https://forum.sunfounder.com/latest

A los profesores y alumnos

Que viven este camino, con admirable interés y entrega.

Entre entusiastas y detractores

El uso de la llamada Inteligencia Artificial se está generalizando en el mundo de las marcas y aplicaciones. El tiempo de las versiones Beta a dado paso, masivamente, a las versiones oficiales y no existe hoy en día, una marca que se precie, que no haya incorporado esta tecnología a su buque insignia.

Yo como aficionado a las tecnologías no paro de sorprenderme de la rapidez en su avance y la curiosidad me llama.

Entre entusiastas y detractores no es un artículo que pretende ahondar en la brecha abierta por el uso de estas tecnologías, sino más bien en su buen uso, para el desarrollo de nuevas ideas, provocando el cambio en los modelos de aprendizaje, derribando fronteras y procurando un cambio progresivo y beneficioso al conjunto de la sociedad.

Uno de los grandes miedos hacia esta, podría ser, la dependencia que se crea con su uso generalizado y para ello, nada mejor que el debate abierto y permanente. Una mente lucida, nunca deja en manos de otro, lo que considera importante, al menos sin una correcta supervisión. Y esta, ¿la dejaremos también en manos de la que podiamos llamar "IA vigilante"?.

Para el ejemplo que os traigo he usado Replit, un IDE en la nube que incorpora dos poderosas herramientas basadas en Inteligencia Artificial, Agent y Assistant. No se trata de contar las bonanzas de la aplicación, que sin duda las tiene. Tampoco tengo claro, si lo que hay detrás es unicamente la IA, o un equipo mixto (Humano/Máquina > 1 o Humano/Máquina < 1), así que me gustaría pensar que el merito se debe a su gran equipo humano de desarrollo.

La idea, que no es original pero para mí novedosa y bastante técnica, trata de crear un "input remote" o mando a distancia para un videojuego desarrollado con Unity, utilizando para ello un dispositivo móvil. Como siempre, esto es solo un prototipo de desarrollo, sin animo de lucro, con el foco puesto en el aprendizaje. Todas las herramientas usadas, son solo para uso particular y poder dar una salida a mi inquietud y curiosidad. A continuación os muestro un enlace de YouTube, donde se puede ver en que consiste facilmente Vídeo InputRemote

Las explicaciones y el código que he usado en este desarrollo lo podeis consultar libremente en https://github.com/jmcaneda/MobileJoystickControllerDef

Para llevarla a cabo, he tomado uno de "mis pequejuegos", el que mejor podría adaptarse, desarrollado en Unity.

Vamos a comenzar por a describir el apartado del videojuego con el motor Unity y el código que tiene mas relación con esta idea.

Unity

En la Build Settings

• Utilizo como plataforma WebGL, que como sabéis significa Web Graphics Library, es una API (interfaz de programación de aplicaciones) utilizada para renderizar gráficos 3D y 2D en navegadores web sin necesidad de plugins y permite a los desarrolladores crear gráficos interactivos y animaciones utilizando JavaScript y el estándar de gráficos OpenGL ES. La mayoria de los navegadores web ya incorporan este framework por defecto.

En Player Settings. Estos parámetros han sido consultados en el manual de Unity https://docs.unity3d.com/2022.3/Documentation/Manual/webgl-deploying.html

• Compression Format: a Gzip.
• Data Caching: a check.
• Decompression  Fallback: a check.

¿Qué nos proporciona la Build?. Las carpetas Build, TemplateData y el archivo index.html. Si comprimimos el conjunto en un archivo .zip y lo subimos a la Plataforma de videojuegos Indie itchio, indicándole que se pueden ejecutar en un navegador web, ya podriamos disfrutar del mismo, utilizando como mando del videojuego, el propio teclado.

Pero..., ¿dónde colocamos todo este código para que podamos ejecutar nuestra aplicación correctamente?. Pues colocamos el resultado de la Build en Unity en la carpeta static del servidor, tal cual, sin modificar nada. ¿Quiere decir esto que si en vez del juego utilizado MaribelProject, lo cambio por otra Build, respetando su ubicación, funcionaría el resto?. La respuesta es si. Podemos reutilizar todo el código y solo, crear nuestro juego y podremos manejar los inputs, desde cualquier dispositivo móvil. Esto es lo fantástico!!!.

Archivos de la Build en Unity

static/Build/ ├── Builds.data ├── Builds.framework.js ├── Builds.loader.js └── Builds.wasm

static/TemplateData/ ├── style.css └── [assets visuales]

index.html

Del código C#, el que mayor interés tiene para la cuestión que estamos tratando es PlayerController.cs, de este extraeremos la parte que nos interesa resaltar. Son la declaración de clases de los diferentes tipos de datos que manejaremos en los diferentes eventos.

void HandleJoystickInput(string jsonData)

En este evento se recibirán los datos x e y del Joystick para el desplazamiento del personaje.

void HandleButtonInput(string jsonData)

En este evento se recibirán los datos state y action, acerca de las teclas pulsadas para el desplazamiento del personaje y visión de cámara.

void HandleInputMethod(string jsonData)

En este evento se recibirá el dato state, sobre el método de input elegido, a off, desde teclado, a on, desde dispositivo móvil.

      
      
      void HandleJoystickInput(string jsonData)
      {
          if (GameManager.instancia.inputRemote)
          {
              JoystickData data = JsonUtility.FromJson(jsonData);
              movement = new Vector3(data.x, 0, data.y) * moveSpeed;

              animator.SetFloat("Horizontal", data.x);
              animator.SetFloat("Vertical", data.y);
          }
      }

      void HandleButtonInput(string jsonData)
      {
          if (GameManager.instancia.inputRemote)
          {
              ButtonData data = JsonUtility.FromJson(jsonData);
              if (data.state == "pressed")
              {
                  switch (data.action)
                  {
                      case "up":
                          {
                              movement = Vector3.forward * moveSpeed;
                              animator.SetFloat("Horizontal", movement.x);
                              animator.SetFloat("Vertical", movement.y);
                              break;
                          }
                      case "down":
                          {
                              movement = Vector3.back * moveSpeed;
                              animator.SetFloat("Horizontal", movement.x);
                              animator.SetFloat("Vertical", movement.y);
                              break;
                          }
                      case "left":
                          {
                              movement = Vector3.left * moveSpeed;
                              animator.SetFloat("Horizontal", movement.x);
                              animator.SetFloat("Vertical", movement.y);
                              break;
                          }
                      case "right":
                          {
                              movement = Vector3.right * moveSpeed;
                              animator.SetFloat("Horizontal", movement.x);
                              animator.SetFloat("Vertical", movement.y);
                              break;
                          }
                      case "A":
                          {
                              break;
                          }
                      case "B":
                          {
                              // Iniciar el desplazamiento a la siguiente esquina
                              GameManager.instancia.indiceEsquinaActual = (GameManager.instancia.indiceEsquinaActual + 1) % GameManager.instancia.esquinas.Length;
                              GameManager.instancia.offset = GameManager.instancia.esquinas[GameManager.instancia.indiceEsquinaActual];
                              break;
                          }
                  }

              }
              else if (data.state == "released")
              {
                  if (data.action != "A" && data.action != "B")
                  {
                      movement = Vector3.zero;
                  }
              }
          }
      }
      
      void HandleInputMethod(string jsonData)
      {
          InputMethodData data = JsonUtility.FromJson(jsonData);
          switch (data.state)
          {
              case "on": GameManager.instancia.inputRemote = true; break;
              case "off": GameManager.instancia.inputRemote = false; break;
          }
      }
      
      [System.Serializable]
      public class JoystickData
      {
          public float x;
          public float y;
      }

      [System.Serializable]
      public class ButtonData
      {
          public string action;
          public string state;
      }

      [System.Serializable]
      public class InputMethodData
      {
          public string state;
      }
    
    

Objeto importante en Unity

En Unity, debe existir el objeto MaribelController y tener como componente, entre otros el script PlayerController.cs

Python y JavaScript

Esta es la parte en la que la asistencia de la IA de Replit, no con pocos intentos en la fase de depuración, facilitó las claves para encaminar este desarrollo, a buen término.

Este proyecto implementa una comunicación bidireccional en tiempo real,       entre un controlador móvil y un juego Unity WebGL, utilizando WebSocket como protocolo de comunicación.

Componentes Principales

Servidor WebSocket (app.py)

Implementado con Flask-SocketIO

Gestiona conexiones y desconexiones

Retransmite eventos entre el controlador y Unity

Cliente Controlador (controller.js)

Implementa la interfaz de usuario del controlador

Captura eventos táctiles y de botones

Emite eventos WebSocket al servidor

Cliente Unity (websocket.js)

Recibe eventos del servidor

Comunica con el juego Unity via SendMessage

Gestiona la conexión WebSocket del lado del juego

Vamos a verlo sobre un diagrama de bloques.

[Dispositivo Móvil] --> (WebSocket) --> [Servidor Flask] --> (WebSocket) --> [Unity WebGL] ^ | | Feedback | +--------------------------------------------------------------------------- +

Partes del código que cabe resaltar

game.html, este es el verdadero contenedor de Unity. Tomamos todo lo que nos interesa del código index.html, de la build de Unity y lo reescribimos en este.

websocket.js, recibe los eventos del servidor y los comunica a Unity vía SendMessage. 

handleGameControl(data) {
        if (!this.gameInstance) {
            console.warn('Game instance not ready, retrying connection...');
            setTimeout(() => this.socket.connect(), 1000);
            return;
        }

        // Send the control data to Unity
        switch(data.type) {
            case 'joystick':
                this.gameInstance.SendMessage('MaribelController', 'HandleJoystickInput', 
                    JSON.stringify(data.data));
                break;
            case 'button':
                this.gameInstance.SendMessage('MaribelController', 'HandleButtonInput',
                    JSON.stringify(data.data));
                break;
            case 'inputMethod':
                this.gameInstance.SendMessage('MaribelController', 'HandleInputMethod',
                    JSON.stringify(data.data));
                break;
        }
}
        

Importante, se puede observar que SendMessage busca un objeto llamado MaribelController y los métodos HandleJoystickInput, HandleButtonInput y HandleInputMethod, incluidos en el componente PlayerController.cs

Error en la versión de producción (Deployments)

Cuando ya disponía de todo el código probado en desarrollo, al pasarlo a producción en Replit (Deployments), se producía un error, que pese a estar documentado en parte en los manuales de Unity, no lo estaba para su uso con servidores Flask. Paso a describirlo, junto con la solución adoptada.

"WebAssembly streaming compilation failed! This can happen for example if "Content-Encoding" HTTP header is incorrectly enabled on the server for file /static/Build/Builds.wasm, but the file is not pre-compressed on disk (or vice versa)".

En app.py podrás ver como se ha resuelto este tema y la clave, en el siguiente código.

    @app.route('/static/Build/')
    def serve_build(filename):
        try:
            response = send_from_directory('static/Build', filename)
            if filename.endswith('.wasm'):
                response.headers['Content-Type'] = 'application/wasm'
                response.headers['Cross-Origin-Embedder-Policy'] = 'require-corp'
                response.headers['Cross-Origin-Opener-Policy'] = 'same-origin'
                response.headers['Cross-Origin-Resource-Policy'] = 'cross-origin'
                response.headers['Cache-Control'] = 'no-cache'
                response.headers['Accept-Ranges'] = 'bytes'
                # Asegurarse de que no haya compresión
                response.direct_passthrough = True
                if 'Content-Encoding' in response.headers:
                    del response.headers['Content-Encoding']
                if 'Content-Length' in response.headers:
                    del response.headers['Content-Length']
            return response
        except Exception as e:
            app.logger.error(f'Error serving {filename}: {str(e)}')
            return str(e), 500
      

Técnica empleada y herramientas adicionales🔧

• Replit
• Unity versión 2022.3
• Copilot como asistente en programación C#
• Información adicional en https://github.com/jmcaneda/MobileJoystickControllerDef

Asset Store 🏬

He utilizado los siguientes packages de Asset Store, casi siempre en su versión free o con mínima inversión.

• vintage-style-radio.
• toony-tiny-people-demo.
• low-poly-streets-and-cars-pack.

Links de interés 🔗

He utilizado los sonidos de nuestro querido "Chiquito de la calzada".

• Sonidos de Chiquito de la calzada
  

El juego original, sin input remote, en WebGL y teclado, podéis probarlo sin problemas. Este es un videojuego regalo y me sirve como base para el desarrollo de este artículo. Gracias Maribel.

• https://jmcaneda.itch.io/maribelproject

Elementos necesarios 🔑

• La app requiere un dispositivo móvil, con capacidad para el escaneo de código QR y navegador web, compatible o habilitado para JavaScript (la mayoría ya lo tienen configurado por defecto).

• La aplicación comenzará con el linkado desde el navegador web, compatible con WebGL (la mayoría ya lo son por defecto). Recomiendo que se realice desde equipo de sobremesa o portátil.

• https://input-remote-jmcaneda.replit.app/

• Desde el dispositivo móvil escanearemos el código QR y dispondremos el mismo en apaisado. Es importante que veamos el "connected" en verde, esto es indicativo que podemos hacer uso del dispositivo.

• El foco debe estar puesto en el navegador, esto lo podemos conseguir posicionando el ratón en el mismo. Cambiaremos el input mode, en el dispositivo móvil, de Off a On y ya está, podremos manejar a nuestro personaje "Maribel", en su recorrido por las calles, escuchando los mensajes y procurando no ser convertida por los "UrbanZombies", de dos maneras: como Joystick o por medio de los botones de desplazamiento. El botón "B", esta programado para el cambio de posición de la cámara.

• Requiere de una conexión a internet.

_

✨ C.A.C. (Soho Málaga), supuso para nosotros (los de entonces), un lugar de encuentro.

¿De que hablamos hoy?. CO2, definición, origen, usos y consecuencias.

Objetivo.

   Esta microfromación tiene por objetivo dar a conocer este compuesto químico: CO₂, junto con su definición, origen, usos y consecuencias para con el Medio Ambiente.

Definición.

   El dióxido de carbono (fórmula química CO₂) es un gas incoloro. Antes de las normas de la IUPAC de 2005, era también conocido como anhídrido carbónico. Este compuesto químico está compuesto de un átomo de carbono unido con enlaces covalentes dobles a dos átomos de oxígeno. El CO₂ existe naturalmente en la atmósfera de la Tierra como gas traza en una fracción molar de alrededor de 400 ppm. La concentración actual es de alrededor 0,04 % (420 ppm) en volumen, un 45 % mayor a los niveles preindustriales de 280 ppm.

Origen.

   Fuentes naturales incluyen volcanes, aguas termales, géiseres y es liberado por rocas carbonatadas al diluirse en agua y ácidos.

   Dado que el CO₂ es soluble en agua, ocurre naturalmente en aguas subterráneas, ríos, lagos, campos de hielo, glaciares y mares.

   Está presente en yacimientos de petróleo y gas natural.

   El CO₂ atmosférico, es la principal fuente de carbono para la vida en la Tierra y su concentración preindustrial desde el Precámbrico tardío era regulada por los organismos fotosintéticos y fenómenos geológicos. Como parte del ciclo del carbono, las plantas, algas y cyanobacterias usan la energía solar para fotosintetizar carbohidratos a partir de CO₂ y agua, mientras que el O₂ es liberado como desecho.​ Las plantas producen CO₂ durante la respiración.​

   Es un producto de la respiración de todos los organismos aerobios. Regresa a las aguas gracias a las branquias de los peces y al aire mediante los pulmones de los animales terrestres respiradores, incluidos los humanos. Se produce CO₂ durante los procesos de descomposición de materiales orgánicos y la fermentación de azúcares en la fabricación de vino, cerveza y pan. También se produce por la combustión de madera (leña), carbohidratos y combustibles fósiles como el carbón, la turba, el petróleo y el gas natural.

Usos.

   Es un material industrial versátil usado, por ejemplo, como un gas inerte en soldadura y extintores de incendio, como presurizador de gas en armas de aire comprimido y recuperador de petróleo, como materia prima química y en forma líquida como solvente en la descafeinización y secador supercrítico. 

   Se agrega a las bebidas y en gaseosas incluidas la cerveza y el champán para agregar efervescencia. Su forma sólida es conocida como "hielo seco" y se usa como refrigerante y abrasivo en ráfagas a presión.

Consecuencias del aumento de su concentración en la atmósfera.

El dióxido de carbono es un importante gas de efecto invernadero. La quema de combustibles de carbono desde la Revolución Industrial ha aumentado rápidamente su concentración en la atmósfera, lo que ha llevado a un calentamiento global.

   La paralización que ha supuesto para la actividad humana la pandemia por Covid-19, ha influido en su ritmo de crecimiento, siendo una buena muestra de nuestra influencia en el fenómeno.

Detección y cuantificación.

   El dióxido de carbono puede ser detectado cualitativamente en la forma de gas por la reacción con agua de barita (Ba(OH)₂) con la cual reacciona formando carbonato de bario, un precipitado blanco insoluble en exceso de reactivo pero soluble en soluciones ácidas. La cuantificación de dióxido de carbono se hace por métodos ácido-base en forma indirecta y por métodos instrumentales mediante infrarrojo.

Unidades de medida, definiciones, equivalente de CO₂, Índice GWP.

   Repasemos algunas de las unidades y formulas que son de interés para comprender el estudio que queremos hacer.

   Partes por millón (ppm) es una unidad de medida con la que se mide la concentración. Determina un rango de tolerancia. Se refiere a la cantidad de unidades de una determinada sustancia (agente, etc.) que hay por cada millón de unidades del conjunto.

   Es un concepto homólogo al de porcentaje, solo que en este caso no es partes por ciento sino por millón.

1 ppm = 1 ml/m³

1.000.000 ppm = 100% en volumen, p.e.: 420 ppm = 0,042% en volumen

   El volumen molar de una sustancia, simbolizado Vm, es el volumen de un mol de esta. La unidad del Sistema Internacional de Unidades es el metro cúbico por mol: m³/mol.

   Un mol de cualquier sustancia contiene partículas. En el caso de sustancias gaseosas moleculares un mol contiene NA moléculas. De aquí resulta, teniendo en cuenta la ley de Avogadro, que un mol de cualquier sustancia gaseosa ocupará siempre el mismo volumen (medido en las mismas condiciones de presión y temperatura).

   La ecuación que describe normalmente la relación entre la presión, el volumen, la temperatura y la cantidad (en moles) de un gas ideal es: P V = n R T , donde Presión absoluta (P), Volumen (V), moles del gas (n), constante universal de los gases ideales ( R), temperatura absoluta (T).

Volumen molar (Vm) = V/n = (R T)/P

   Experimentalmente y mediante la ley de los gases ideales, se ha podido comprobar que el volumen que ocupa un mol de cualquier gas ideal en condiciones estándar (Presión de 10⁵ pascales (1 bar), Temperatura de 273,15 K, 0 °C) es de 22,7 litros. Si se utiliza como presión 1 Atm (101325 Pa) en vez de 1 bar, este valor cambia y es 22,4 L (22.3983 L para ser más específicos). Este valor se conoce como volumen molar normal de un gas. También por tanto para el CO₂ = 22,4 L.

   La masa atómica del carbono (C) es 12 g/mol; para el oxígeno (O) es de 16 g/mol. Esto significa que 6.022 x 10²³ átomos de carbono pesan 12 gramos.

   Según esto, el peso molecular del CO₂ es: 12 g/mol [C] + 2 x 16 g/mol [O₂] = 44 g/mol.

Relación ppm (x) y mg/m³ (y)

(CO₂ a 25º y 1 atm) => Vm = 24,4 [L/mol] , x [ppm] = (y [mg/m³] x 24,4 [L/mol]) / 44 [g/mol] CO₂

   Así podríamos determinar y escenificar, ¿Qué volumen ocupa una tonelada (1.000.000 g) de CO₂ en condiciones normales?. Tiene un volumen de 509.400 L (1.000.000 [g] x 22,4 [L/mol])/ 44 [g/mol]. 

   Esto corresponde aproximadamente al volumen de una piscina de 10 m x 25 m x 2 m.

   El equivalente de CO₂ o equivalente de dióxido de carbono (CO₂eq o Carbon Dioxide Equivalent, en inglés), es una medida en toneladas de la huella de carbono. Huella de carbono es el nombre dado a la totalidad de la emisión de gases de efecto invernadero.

   La masa de los gases emitidos es medida por su equivalencia en CO₂ (dióxido de carbono).

   El CO₂ es el más conocido y es también la referencia del resto de los gases de efecto invernadero, a los que se considera causantes del calentamiento del planeta. Como unidad se utiliza tCO₂eq que supone un volumen de emisión de gas de efecto invernadero equivalente a una tonelada de CO₂.

   Se elige el CO₂ como el equivalente al total de los gases de efecto invernadero porque, a pesar de tener un potencial de calentamiento mucho menor que el de otros gases, como el metano o los óxidos nitrosos, es el que más crecimiento ha experimentado en la atmósfera terrestre y el más abundante en porcentaje de todos ellos.

   Dicha medida de CO₂ equivalente es usada para calcular la Huella de Carbono de un individuo, producto, actividad o servicio. De esta manera se puede cuantificar un impacto ambiental atendiendo a la categoría de calentamiento global provocado por la emisión de gases de efecto invernadero.

   Los gases de efecto invernadero distintos del dióxido de carbono (metano, óxido nitroso, hidrofluorocarburos, etc.) son convertidos a su valor equivalente en dióxido de carbono, multiplicando la masa del gas en cuestión por su Potencial de calentamiento global (GWP).

   P.e.: El metano es un gas con efecto invernadero potente que contribuye al calentamiento global del planeta Tierra, ya que tiene un potencial de calentamiento global (GWP) de 28, según la última evaluación (Fifth Assessment Report, AR5). Esto significa que en una media de tiempo de 100 años, cada kg de CH4 calienta el planeta Tierra 28 veces más que la misma masa de CO₂.

   Se ha calculado que la emisión de gases efecto invernadero de la India al año supone 1 tCO₂eq per cápita, la de Europa 10 tCO₂eq y un estadounidense más de 20 tCO₂eq per cápita.

   Índice GWP (acrónimo del inglés Global-warming potential - GWP = Potencial de calentamiento global) es una medida relativa de cuánto calor puede ser atrapado por un determinado gas de efecto invernadero, en comparación con un gas de referencia, por lo general dióxido de carbono.

   El potencial de calentamiento GWP para otros gases, puede ser calculado para periodos de 20, 100 o 500 años, siendo 100 años el valor más frecuente. Así, el dióxido de carbono tiene un valor GWP de 1.

Casos prácticos de utilización del CO₂.

   Ahora que ya conocemos algo mas sobre este compuesto, vamos a ver como participa en dos casos prácticos diferentes, en el primero mostraremos como la medición del CO₂ puede darnos información sobre la calidad del aire en el interior de las salas y el segundo veremos que es la reacción de Sabatier y cual es su papel en la generación de oxigeno en la ISS (Estación Espacial Internacional).

Primer caso, calidad del aire en ambientes interiores, medición concentración de CO₂.

   Todos sabemos que el riesgo de contagio de Covid-19 en ambientes interiores es superior al riesgo en el exterior. Por tanto, las actividades en exterior son siempre preferibles.

   En ambientes interiores, las partículas en suspensión, también llamadas aerosoles, susceptibles de contener virus, se pueden acumular. De la exposición a este aire pueden resultar infecciones. La reducción del riesgo de contagio se consigue reduciendo emisión y exposición.

   La emisión se puede reducir mediante:

• Disminución del número de personas.
• Silencio o volumen de habla bajo (al hablar fuerte o gritar la emisión es 30 veces superior).
• Actividad física relajada (al aumentar intensidad de actividad se aumenta la emisión).
• Uso de mascarilla bien ajustada.

   La exposición se puede reducir mediante:

• Uso de mascarilla bien ajustada, incluso en ausencia de otras personas si estas han abandonado la sala muy recientemente.
• Reducción del tiempo de exposición.
• Aumento de la distancia interpersonal.
• Ventilación o purificación del aire, para eliminar o reducir la concentración de virus en el aire.

   Y en esta última se basa el estudio de este primer caso.

   La renovación de aire se puede denominar por sus siglas en inglés ACH, Air Changes per Hour. Si un espacio tiene 1 ACH (1 renovación de aire por hora) significa que en una hora entra en la sala un volumen de aire exterior igual al volumen de la sala y debido a la mezcla continua del aire, esto resulta en que el 63% del aire interior ha sido reemplazado por aire exterior. Con 2 renovaciones se reemplaza el 86% y con 3 renovaciones el 95%.

   La ventilación necesaria para reducir el riesgo de contagio depende del volumen de la sala, el número y la edad de los ocupantes, la actividad realizada, la incidencia de casos en la región y el riesgo que se quiera asumir.

   La guía de Harvard recomienda 5-6 renovaciones de aire por hora para aulas de 100 m², con 25 estudiantes de 5-8 años, y establece esta clasificación:

6 IDEAL, 5-6 EXCELENTE, 4-5 BUENO, 3-4 MÍNIMO, menos de 3 BAJO.

Otra forma de medir la ventilación necesaria es con una estimación de litros de aire por persona y segundo que se requieren del exterior.

   Un valor adecuado para reducir riesgo de contagio es 14 litros por persona y segundo.

   La relación entre ambos parámetros es: 

ACH = (litros por persona y segundo * número personas * 3600 segundos/hora * 0.001 m³/litro) / volumen sala en m³

   Estos valores de ACH se pueden ajustar según el riesgo que se quiera o se pueda asumir. El riesgo cero no existe. Cuanto mayor sea la ventilación, menor es el riesgo de contagio.

   En el aire exterior, las concentraciones de CO₂ son de aproximadamente 420 ppm. En interiores, en espacios ocupados, las concentraciones de CO₂ son elevadas por el CO2 exhalado por los ocupantes.

   Dichas concentraciones se pueden medir para verificar si la renovación de aire en un espacio determinado es la adecuada. La ventilación de espacios y por tanto la disminución de la concentración de CO₂, podemos conseguirla por medios naturales, mecánicos o mixtos.

   Por cualquiera de los métodos descritos podremos calcular la ventilación necesaria (m³/h) y en función de esta determinar el número de elementos mecánicos requeridos.

Caudal (m³/h) =ACH ventilación calculada * volumen aula

   En resumen, en un espacio interior ventilado podemos conocer la calidad del aire que respiramos mediante la medición y control de la concentración de CO₂.

Segundo caso, reacción de Sabatier y cual es su papel en la generación de oxigeno en la ISS (Estación Espacial Internacional)..

¿Qué es la reacción de Sabatier?.

La reacción de Sabatier es un proceso mediante el cual, se hacen reaccionar hidrógeno (H₂) y dióxido de carbono (CO₂) a altas temperaturas y presiones para transformarlos, con ayuda de un catalizador de níquel, en agua (H₂O) y metano (CH₄).

   Opcionalmente se puede optar por rutenio en alúmina que constituyen un mejor catalizador.

CO₂ + 4H₂ → CH₄ + 2H₂O

   Fue descubierta por el químico francés Paul Sabatier, ha sido propuesto como un paso clave en el envío de misiones tripuladas a Marte.

   En estas misiones se podrían llevar tanques llenos de hidrógeno de la tierra, o bien producirlo a partir de agua marciana mediante un proceso de electrólisis, consiguiendo además oxígeno. Aparte se tomaría el dióxido de carbono de la atmósfera de Marte, consiguiendo así un considerable ahorro de peso.

   La reacción es exotérmica y produce una energía de aproximadamente 165 kJ (aunque este valor es referencial, ya que varía según las condiciones). La reacción se lleva a cabo en un reactor, cuyas paredes están revestidas de níquel que actúa como catalizador.

   Conocemos un caso interesante, entre otros donde se utiliza esta reacción.

¿De dónde sacan los astronautas el oxígeno para respirar en el espacio? 

   Algunos astronautas pueden llegar a pasar meses o incluso años en la Estación Espacial Internacional (ISS por sus siglas en inglés o EEI por sus siglas en español). Y, como es obvio, no se puede almacenar tanta cantidad de oxígeno (el tamaño es reducido), igual que tampoco se puede estar constantemente llevándolo (esto supondría que lo astronautas estarían respirando un oxígeno que tendría un valor de 500 000 dólares diarios.

   La solución está en un sistema diseñado por la NASA y que fue enviado en 2007. Este sistema recibe el nombre de Oxygen Generation System (OGS por sus siglas en inglés), que en español significa Sistema Generador de Oxígeno y consiste básicamente en una máquina que mediante procesos químicos convierte agua que ya no es útil en la ISS en el tan preciado oxígeno.

   Estas aguas (aproximadamente de forma diaria se usan unos 23 litros), por medio de la electrólisis (un proceso químico en el que se inyecta electricidad proveniente, en este caso, de las energías renovables de la estación; concretamente se inyectan 50 A), se separan en Oxígeno (O₂) e Hidrógeno (H).

   Para que el proceso sea más efectivo, se usa Hidróxido de potasio en una proporción de 30%.

   Posteriormente el oxígeno se libera a la atmósfera para que sea respirado por los astronautas y el hidrógeno (que es nocivo para los humanos, además de altamente inflamable) no se libera al espacio, como mucha gente piensa, sino que, mediante otra reacción química, la reacción de Sabatier y junto con CO₂, se produce agua (H₂O) y metano (CH₄). El agua entra de nuevo en el circuito de la OGS y el metano sí que se ‘flota’ al espacio.

   El sistema genera entre 2,3 y 9 kg de oxígeno diarios, lo que es suficiente para mantener a los 6 astronautas que viven allí de forma semipermanente. Diariamente se consume 5 kg de oxígeno (unos 840 gramos por persona por día), por lo que en ocasiones se produce un excedente.

   De esta forma, los astronautas son capaces de vivir allí sin la necesidad de estar preocupándose por el oxígeno y por cuándo llegará más (además de que sería carísimo recibir oxígeno regularmente).

   En resumen, acabamos de ver como participa el CO₂ en las reacciones necesarias para su utilización en el Sistema Generador de Oxigeno de la ISS.

Propuesta para el alumnado.

   Hemos visto algunos casos concretos. Existen multitud de proyectos de investigación y desarrollo relacionados con el CO₂ y con la disminución de la emisión de gases de efecto invernadero.

   La propuesta es recopilar información acerca de aquellos, de iniciativa pública, privada o de ambas, de vuestra preferencia o que conozcáis de vuestro entorno cercano, que se hayan iniciado, en proceso o ya materializado y que sirvan de base para el desarrollo de vuestro trabajo.

   Se rellenará una breve cuestionario para generar el índice de todos los trabajos que son de vuestro interés, se pueden indicar varios, pero al menos uno debe servir para el desarrollo del trabajo. El trabajo se subirá a la plataforma habitual en respuesta a la tarea o bien si se ha utilizado p.e., un blog personal, también se indicaría su URL.

   El trabajo que mayor interés haya despertado será expuesto por el grupo y su autor. 

   Será elegido por todos mediante votación mediante formulario de Google y presentado por composición de breves videos hilados (cada uno de entre uno y tres minutos de duración), que traten conceptos o cuestiones concretas.

   El tiempo necesario para la realización del trabajo será de una semana, más una sesión para el visionado y debate.

Temporalización.

Una semana de microformación y una semana para la realización del trabajo.

Herramientas digitales.

   En esta ocasión recomendamos la utilización de Blogger, documentos o presentaciones de Google, para el desarrollo de los trabajos individuales.

   Usaremos la conexión de formularios con hojas de cálculo de Google, para enumerar los proyectos propuestos por el alumnado y también para recoger los resultados de la votación.

   Utilizaremos Spark Camera, InShot, Tik Tok, Screenity para explicaciones con compartición de escritorio o cualquier otra herramienta digital para la creación de videos y presentaciones.

   El formulario siguiente servirá para recoger las propuestas y estas se irán reflejando en la hoja de cálculo.

   De un modo similar se recogerán las propuestas elegidas, las cuales se someterán a votación, para transformarla por el grupo, en una presentación mediante videos hilados.

Evaluación con Rúbrica.

   Documento para el alumnado, de forma que aporte claridad y que este conozca los principales puntos donde se incidirá a la hora de evaluar el trabajo realizado, ya sea por coevaluación o por evaluación por docente. Se puede utilizar con el complemento CoRubrics, para facilitar la evaluación y la comunicación de resultados.

Enlace a rúbrica proyecto CO₂, en nueva ventana.

Catalogación

    Curso recomendado: ESO, Bachillerato.

    Asignatura: FyQ, TIC.

    Competencias clave trabajadas: 

• Competencia en Comunicación Lingüística.
• Competencia Matemática y Competencias básicas en Ciencia y Tecnología.
• Aprender a Aprender.
• Competencias Sociales y Cívicas.
• Sentido de la iniciativa y Espíritu emprendedor.
• Competencia Digital.

Agradecimientos

   Gracias por tu interés en esta recopilación de material educativo. Si lo usas y compartes, no olvides mencionarme por Instagram (@jmcaneda), Twitter (@CanedaPernas) o en mi blog, me hará muchísima ilusión.

   También puedes comentar cual ha sido tu experiencia respecto de su contenido o utilización. Recuerda que el contenido pertenece a sus autores y que mi trabajo se limita a pequeñas aportaciones y una nueva composición, que facilite la comprensión del tema elegido, junto con algunas herramientas digitales que considero apropiadas y de utilidad para la mejora en las competencias digitales.

Términos de uso

    Puedes usar este material para uso personal o como inspiración para crear el tuyo personal.

    NO ESTÁ PERMITIDO: vender, comercializar o redistribuir este material.

Atribución, Créditos, Referencias, Notas bibliográficas, Herramientas digitales

DIGITAL.CSIC: Guía para ventilación de las aulas CSIC - Desde https://digital.csic.es/handle/10261/221538

Ministerio para la Transición Ecológica, guia_huella_carbono_tcm30-479093.pdf (miteco.gob.es) - Desde https://www.miteco.gob.es/es/cambio-climatico/temas/mitigacion-politicas-y-medidas/guia_huella_carbono_tcm30-479093.pdf

¿Cuánto es una tonelada de CO2? (miteco.gob.es) - Desde https://www.miteco.gob.es/es/ceneam/recursos/mini-portales-tematicos/cuanto_es_1t_co2_tcm30-70715.pdf

Educación y Comunicación frente al Cambio Climático (miteco.gob.es) - Desde https://www.miteco.gob.es/es/ceneam/recursos/mini-portales-tematicos/cambio-climatico.aspx

Global-Warming-Potential-Values.docx (ghgprotocol.org) - Desde https://ghgprotocol.org/sites/default/files/ghgp/Global-Warming-Potential-Values%20(Feb%2016%202016)_1.pdf

El oxígeno de los astronautas de la Estación Espacial, ¿de dónde proviene? (elespanol.com) - Desde - https://www.elespanol.com/omicrono/tecnologia/20180224/oxigeno-astronautas-estacion-espacial-proviene/287472119_0.html

Wikipedia Desde

https://es.wikipedia.org/wiki/Di%C3%B3xido_de_carbono https://es.wikipedia.org/wiki/Huella_de_carbono https://es.wikipedia.org/wiki/Partes_por_mill%C3%B3n https://es.wikipedia.org/wiki/Volumen_molar https://es.wikipedia.org/wiki/Ley_de_los_gases_ideales https://es.wikipedia.org/wiki/CO%E2%82%82_equivalente https://es.wikipedia.org/wiki/%C3%8Dndice_GWP https://es.wikipedia.org/wiki/Reacci%C3%B3n_de_Sabatier

OneNote - Preparación, esquema y contenidos.

Imagen huella de carbono CO₂, desde el banco de imágenes de Adobe Stock.

Infografía CO₂ - Desde Statista - https://es.statista.com

Hojas de cálculo de Google - https://docs.google.com/spreadsheets

Formularios de Google - https://docs.google.com/forms

Rúbrica para evaluar una página web” de CeDeC - Desde Banco de rúbricas y otros documentos | Cedec (intef.es) - Desde https://cedec.intef.es/banco-de-rubricas-y-otros-documentos/