Bitácora de Vuelo (Publicaciones sobre electrónica)

Fase uno del arranque de DSAF

Facundo Batista — Tue, 04 Jul 2023 00:30:00 GMT

Finalmente arrancó mi viaje de volver un poco a jugar con microcontroladores. Ya tenía la especificación que armé pero me faltaba ir a los bifes.

Me propuse hacer una primera versión apenas funcional para poder comenzar a darle estructura, porque es muy difícil arrancar algo tan complejo y multinodo. Ya tengo algo cumple con las mínimas condiciones:

En el nodo distribuido:

una clase ejemplo como Sensor Manager: leer el conversor analógico-digital y una entrada binaria
correr ese Manager periódicamente y reportar los datos que obtenga
mostrar el estado con sólo un led: prendido cuando está arrancando y luego ya en funcionamiento regular un parpadeo corto cada cinco segundos

En el nodo de administración: sólo escuchar en un puerto y mostrar lo que reciba del nodo distribuido

¡Lo tengo funcionando! Saqué tres videos muy muy cortitos al respecto. El primero es el "nodo distribuido" que prende el led al arrancar y luego parpadea:

Ese nodo va tirando logs, acá lo vemos mostrando que arranca, se conecta a la red, empieza a reportar lo del sensor, etc:

Y los logs del nodo de administración, que recibe y muestra la data del sensor:

(los videos podrían estar mejor sí, podría haber grabado directamente la terminal, pero los tomé rápido y después desarmé cosas, así que no los iba a volver a hacer)

Las cosas que me chocaron o desafíos que se me presentaron fueron varias.

Más allá de empezar a desempolvar las cosas de electrónica (por ejemplo, necesitaba una resistencia de 10kΩ y tuve que empezar a revolver todo) encontré que programar en MicroPython es fácil y podés empezar a tirar código funcional y rápido, pero tiene sus limitaciones... no es CPython, y eso se nota por muchos lados:

no encontré forma de extraer un traceback cuando hay una excepción (para mostrarla o enviarla como reporte)
no hay urllib.request! Buscando encontré que sí trae un urequest (micro request), que tiene un urlopen útil, pero no hay Request (esto me complicó la vida para mandar headers así que estoy mandando los bytes crudos sin decir que es JSON, es un detalle fácil de considerar en el server).
hay otros módulos que no están y uno ya los usa casi inconscientemente entonces se sufre al no tenerlos, como itertools o logging.

También es evidente que hay mayores restricciones por el entorno. Por ejemplo, memoria disponible. En el método NetworkManager.hit (en main.py) tuve que cerrar la respuesta antes de devolver el contenido... teóricamente esa respuesta se cerraría sola al limpiarse el objeto cuando la función termina, pero en la práctica pasaba que luego de una decena de hits se desconectaba con un error raro que por lo que encontré en Internet estaba relacionado con que se acababa la memoria.

Otro tema bien relacionado con el hardware puntual que estoy usando (el ESP8266) es que tengo disponible sólo un /timer/. Por ahora lo estoy usando para el parpadeo de la luz de estado, pero necesito más funciones periódicas (la otra luz, mandar automáticamente al server el status del nodo, etc). Voy a tener que implementar un "supertimer" arriba de este único timer...

Tener tests no es tan fácil tampoco, ya que módulos como network o machine están disponibles al correr en el microcontrolador, pero los tests lo corro en mi máquina... por ahora zafé estructurando el código de manera que lo que quise probar estuviese aislado del hardware, pero en algún momento hay que tener ahí stubs... tengo que ver si hay algo ya hecho, no quiero armarlo yo.

Y encontré que la funcionalidad que quería, con dos o tres cosas "sucediendo solas" además del funcionamiento del sensor, y la complejidad de los estados por los que puede pasar (que al mismo tiempo le da confiabilidad en el funcionamiento) no era tan fácil de implementar. Terminé armando una FSM <https://es.wikipedia.org/wiki/M%C3%A1quina_de_estados> chiquitita con sus transiciones y estados, y de paso dispuse que ese objeto maneje automáticamente las luces, justamente, de estado. Esto le dio robustez al funcionamiento y en la práctica simplificó bastante el código.

Conclusiones: con el tiempo invertido podría haber armado en C un hack sucio y desprolijo que haga más o menos lo que quería. Pero codear en Python es más alto nivel, puedo armar facilmente estructuras que hacen lo que me propuse de forma robusta y que me van a permitir escalar. Una gran elección.

Detalles que me quedaron para la(s) próxima(s) iteración(es) antes de pensar en más funcionalidad según la spec:

dejar de usar el led interno para el (único) estado y poner dos leds verdes y azul como corresponde, y manejarlos correctamente
que la config no esté hardcodeada (aunque todavía no quiero depender del Configurator) y que soporte que la misma no exista
implementar el "supertimer", y poder mandar periódicamente estado del nodo al server
que el Sensor Manager no acceda directamente al hardware, sino a través de una capa ofrecida por el Framework
poder leer el estado de la batería e incorporar eso en el estado
manejar "batería baja" correspondientemente
que el logger sólo arme las cadenas y muestre en pantalla si el nivel corresponde

Les contaré más en el futuro.

Facilitar la instalación distribuida de sensores y actuadores

Facundo Batista — Mon, 29 May 2023 18:34:00 GMT

Uno de los proyectos que tenía anotado de hace rato para volver a jugar un poquito con electrónica era armar un framework para poder instalar sensores (y en un futuro) actuadores por ahí sin tener que preocuparme por cableado, juntar los datos, y varios detalles más.

El último par de semanas estuve trabajando en una especificación inicial para eso, la puse en el README del proyecto de Github donde voy a ir subiendo todo: Distributed Sensors and Actuators Framework.

El framework a grandes rasgos tiene tres tipos de nodos:

Manager: El nodo central con la interfaz administrativa para el operador humano y una API para exponer todo. Permitiría ver toda la data que mandan los sensores, poder interactuar con los mismos, etc.
Sensores y actuadores: Los nodos que generan y transmiten la info, o reciben data y actúan acordemente. Acá la idea es tener un hardware basado en ESP32 programado en Python.
Configurador: Es el nodo que configura los nodos distribuidos para que puedan conectarse al Manager. Se usa una sola vez por cada nodito distribuido para que se configure automáticamente.

Vayan al proyecto para leer bien el detalle de a qué habilita el nodo central de administración, toda la funcionalidad de los nodos distribuidos y cómo trabaja el configurador, más gráficos, etc.

¡Se agradecen comentarios!

Minecraft y la electrónica

Facundo Batista — Mon, 14 Dec 2020 23:26:00 GMT

Una de las cosas que más me cautivó siempre de Minecraft, además de su total libertad para construir y alterar "el mundo", es que esas construcciones no son pasivas, sino que existen actuadores, generadores de energía, etc.

Claro, todo es un poco simplificado y "raro" a nivel de la física como la conocemos, pero eso es en pos de la jugabilidad, y aunque a veces puede ser un incordio (hay que aprenderse esos detalles), no es realmente un problema.

Como muestra basta un botón. Digo, como ejemplo sólo basta un interruptor. En nuestra realidad un interruptor corta o permite el flujo de corriente por el mismo, pero en Minecraft un interruptor es un generador de energía: sólo con poner "cerca" ese botón con un actuador (por ejemplo, una puerta), tenemos el circuito armado.

Ahí no hay nada más que lo que vemos, la puerta y el botón sobre el bloque de piedra. Si en el juego vamos y apretamos ese botón, la puerta se abre.

El polvo rojo

Pero Minecraft introduce un elemento más que lo cambia todo: la "piedra roja", o "redstone". Se encuentra en las profundidades del planeta, y cuando la minamos con pico de hierro o diamante, nos da polvo de piedra roja (o polvo de redstone, como normalmente se lo denomina).

Tiene muchos usos. Si lo aplicamos directamente sobre otros bloques cumple la función de "cableado", ya que transmite energía. También podemos hacer antorchas de redstone, que son simplemente generadores de energía, y nos permite armar (con otros componentes) muchísimos más elementos "de alto nivel", como comparadores, repetidores, placas de presión, relojes, brújulas, pistones, etc.

Una vez que empezás a combinar los elementos, casi que sólo la imaginación es el límite. En la imagen de recién puse el botón y la puerta, como al principio, pero cableados entre sí (porque están lejos) y con un repetidor en el medio (al que se le puede configurar el tiempo de demora al repetir): el efecto es que uno aprieta el botón, y la puerta se abre unos segundos después.

La inquietud

Durante mucho tiempo estuve con la idea de hacer algo de electrónica dentro del juego, el otro día me decidí, y armé una compuerta NAND.

Una compuerta NAND es una de los elementos clásicos de la electronica, y no es más que una AND negada. Aunque al aprender las compuertas lógicas en electrónica digital siempre se empieza por ANDs y ORs, que son más fáciles, la electrónica realmente gira alrededor de las NANDs porque toda la lógica siempre se puede implementar con NANDs y su implementación (su fabricación) es la más sencilla de todas.

Al tratar de armar esto dentro del juego me di cuenta que se aplicaban esas reglas raras que a veces tiene el juego en general o la redstone en particular, y tuve que buscar por ahí cómo se podía hacer la compuerta. No es tan difícil, pero implica usar "antorchas de piedra roja" (redstone torches), que es una especie de antorcha hecha con polvo de piedra roja (no como las antorchas comunes, que las hacemos con carbón), y sirven tanto de generación de energía como de inversores de señal.

Armé entonces la compuerta NAND, como muestra la imagen: con dos antorchas cableadas juntas, y usando dos palancas como entradas de señal (que generan un 0 o un 1 en función de la posición) y una puerta para mostrar el estado de salida (abierta representa un 1).

Ahí vemos la tabla de verdad de la NAND (o sea, cada salida para todas las combinaciones de entrada).

Electrónica más compleja

Una vez que tuve la NAND, el resto es cuestión de escalar en complejidad. Entonces decidí hacer un flip-flop, para que mediante dos botones pudiera mantener un estado de salida.

Podríamos argumentar que si en Minecraft queremos una salida estable podemos usar una palanca y ya, pero por un lado acá vamos por el aprendizaje, no la sencillez, y por el otro tengamos en cuenta que en la entrada podemos tener algún dispositivo automático que genere energía por un momento (por ejemplo, un sensor de presencia), y podemos querer agregarle "estado" a eso.

Volvamos. Un flip-flop es el elemento electrónico más básico que puede mantener un estado estable durante un tiempo indefinido (efectivamente almacenando información... o sea, "recuerda" si está en cero o en uno, podemos decir que es la memoria estable más básica).

Hay de distintos tipos, pero apunté al más sencillo, el set-reset, que sólo tiene dos entradas, una para poner al flip-flop en 1 ("set", o S), y la otra para ponerlo en 0 ("reset", o R).

Entonces, armé ese circuito, y puse una puerta en una de las salidas (la otra no me interesa). Fíjense en el diagrama de arriba que la entrada "set" y "reset" están negadas (la barrita horizontal arriba de la S y la R). Estuve viendo cómo hacer un negador simple en Minecraft y no me salió (teoricamente las antorchas redstone funcionarían, pero como del otro lado estaban cableadas no me anduvo en el apurón), así que opté por un viejo truco del electrónico, usar una NAND (¿les dije que son la base de todo?) con las entradas unidas.

Me terminaron quedando los dos botones cerquita, uno para abrir la puerta y otro para cerrarla (le puse cartelitos como recordatorio). A la izquierda y derecha de cada botón está su NAND-negador correspondiente, y más adelante las dos NANDs cruzadas que arman el flip-flop (se puede ver mejor el cruce de los "cables" en la segunda imagen).

El circuito anda de perlas. Ahora tengo ganas de hacer algo más complejo, pero tendría que ver de hacer ese flip-flop más compacto sin que se "toquen los cables" (no es fácil con el polvo redstone), y ver de simplificar esos negadores.

Ya les contaré.

¡Yo quiero!

Facundo Batista — Thu, 19 Jul 2007 13:53:02 GMT

Dos dispositivos maravilla.

El primero, es una computadora tamaño mínimo, Linutop.

Pesa menos de 300 gramos, y tiene un procesador AMD de 433MHz, 256 MB de RAM, 4 puertos USB, audio, salida VGA, y red. No tiene disco rígido, pero viene con un disco USB de 1GB preparado para bootear Linux, ¡sólo se enchufa y se usa!

El segundo es un teclado, hecho artesanalmente.

La electrónica y los mecanismos de las teclas son "reciclados" de un teclado común, pero el flaco este armó toda la estructura rígida; las superficies de las teclas las recicló algunas de una máquina de escribir, fabricó el resto.

En el sitio pueden ver instrucciones paso a paso de cómo armarlo, e incluso videos para comprenderlo mejor.

Gracias a Dave y a Ramón por los enlaces originales de ambos dispositivos.

Bueno, ya saben que me pueden regalar en el próximo cumpleaños, :p.