Archivo de la categoría: Joanillo Productions

cnchollow script. Generador de G-Code para fresar diferentes tipos de cavidades

Hemos estado programando un script en C++ para hacer cavidades. Cavidades de diferente tipo: rectangulares, rectangulares con cantos redondeados, circulares y elípticas. Además, la profundidad de la cavidad puede ser constante (cavidad cilíndrica) o bien una cavidad esférica. Por tanto, hay 8 posibilidades de cavidades diferentes, como se ve en la imagen, con diversos parámetros que puedes controlar. El script genera el G-Code directo para ser fresado.

Si quieres utilizar el script, primero tendrás que mirar las ilustraciones que hay en la documentación, y así entender los diferentes parámetros. Básicamente tenemos que introducir el origen de coordenadas de la cavidad (allá donde está centrada); los semiejes en el caso de los rectángulos-elipse, o el radio en el caso del círculo; la profundidad final en el caso de cavidades cilíndricas; el radio esférico en el caso de cavidades esféricas, que dará lugar a más o menos profundidad esférica. En función de la broca que tengamos y de la resolución que queramos, también hemos de definir el paso lineal y el paso de profundidad (parámetros -m y -n).

Para las cavidades cilíndricas hay suficiente con utilizar brocas normales de fresar (las de 2mm de diámetro son las más pequeñas que he conseguido). Pero para las cavidades esféricas es interesante utilizar una broca tipo round nose bit, y así conseguimos un mejor acabado, como se puede apreciar en la foto.

El primer proyecto para utilizar mis cavidades es fresar el juego del mancala (o awalé o otros nombres), donde quiero fresar varias cavidades diferentes. Ya informaremos cuando esté acabado.

Es un proyecto escrito en C++, no requiere ninguna librería especial, por tanto su compilación es directa. Para la versión 1.0.6, la última versión:

$ g++ -o cnchollow cnchollow-1.0.6.cpp
Ex:
$ ./cnchollow -f rectangle -t cylindrical -x 100 -y 100 -r 30.23 -s 15.21 -z -10.3 -m 3.0 -n -1.0 -o ./cnchollow.ngc

Referencias:

Fresar una foto en blanco y negro con CNC

Estos días estamos viviendo unos días inciertos en Catalunya. Es necesario salir a la calle y defensar el gobierno legítimo, rehusar de pleno la aplicación del artículo 155 de la Constitución Española, y no dejar pasar la oportunidad que representa las elecciones del 21D. Así que hemos hecho unos carteles para llevarlos a la manifestación del 11N, y todas las que sean necesarias. Actualmente, tenemos en las prisiones españolas: Jordi Sánchez, Jordi Cuixart, Oriol Junqueras, Dolors Bassa, Meritxell Borràs, Josep Rull, Raül Romeva, Carles Mundó, Joaquim Forn y Jordi Turull. Y el número puede aumentar.

Aquí expongo mi workflow para hacer un cartel en blanco y negro, a partir de una foto.

1. GIMP. A la hora de escoger la foto hemos de procurar que el fondo sea claro y contrastado con la foto, de manera que el GIMP detecte bien los contornos. Abrimos la foto con el GIMP, y desaturamos la foto (convertiéndola a escala de grises), y con la herramienta Umbral de color blanco-negro, escogemos la imagen que queremos fresar.

2. LibreCAD es el software que utilizo para generar el DXF. Importo la imagen, y creo una capa para definir las líneas de fresado. Como la broca que utilizaré es de 2mm, escojo un trazo de 2mm, y de esta manera me puedo hacer una buena idea de cómo quedará el resultado final. Resigo todos los contornos, lo hago de manera manual.

3. Todavía en el LibreCAD, he de definir los puentes de manera que no haya ninguna isla que se pueda desprender cuando después haga el fresado. Genero el fichero dxf.

4. Vuelvo al GIMP y relleno de negro las superfícies que quedarán vacías. De esta manera me puedo hacer una buena idea del resultado final, y prever el éxito de la pieza.

5. Con el script de python dxf2gcode puedo definir las propiedades del fresado. Concretamente, la profundidad del corte. Si la plancha de madera que utilizaré es de 3mm, la profundidad será de 3mm. Genero el fichero G-Code.

6. Con LinuxCNC ya puedo fresar la pieza, con una broca de 2mm. Una vez finalizado el trabajo, se lija y se corrigen posibles imperfecciones.

Todo el proceso está explicado en el video. En la imagen se ve cómo queda el resultado final con la foto de Raül Romeva, ahora en prisión. Ahora sólo queda hacer los carteles, y salir a la calle. La lucha continua.

Referencias:

Probando mesas B2S en Virtual Pinball

Estos días estoy haciendo una nueva máquina de Pinball, igual que la primera, con configuración FS (FullScreen), es decir, de una sola pantalla. Aprovechando que tengo un ordinador con el que hacer pruebas, en un segundo disco quiero instalar el Visual Pinball con configuración B2S (Backglass to Screen), es decir, con dos pantallas: la principal es el playfield, y la secundaria es el backglass.

Así pues he instalado el Visual Pinball y el VPinMAME, y he mirado los tutoriales para ver cómo funciona esto del B2S. Y ya tengo las primeras mesas funcionando. No es difícil de entender y de implementar, pero lo que sí es cierto es que tendré que ir una por una de las más de 200 mesas que tengo implementadas y clasificadas.

Lo primero que hay que hacer es bajarse los archivos de backglass (con extensión .directb2s). A partir de las dos pantallas que tengo (una de 22» 1920×1080; y otra de 17» 1280×1024), creo el fichero screenres.txt, relacionado con la geometría de las dos pantallas. Y entonces he de ir una por una de las mesas, entrar en el script (el código), y configurar el script para que funcione el modo B2S. Ejecutar la mesa (jugar un rato :-)), comprobar que todo funcione correctamente, y ajustar algún parámetro si es necesario. En particular, las mesas que tienen DMD (Dot Matrix Display), ajustaré la geometría para que el display DMD aparezca en la pantalla del backglass, en una posición que no sea invasiva.

En la configuración FS tengo implementadas 200 mesas. Algunas de ellas no se han portado todavía a B2S, pues no tienen el fichero de backglass, o me han dado problemas. Si tengo tiempo, miraré de implementar algunas mesas más que vea que son divertidas, y así recuperar el valor de 200 mesas implementadas. En el futuro, miraré de introducir el display de DMD, aunque yo siempre tengo un ojo puesto en la simplicidad.

Cuando tenga configuradas las mesas B2S será el momento de hacer el mueble de pinball con dos pantalls, de momento en un formato pequeño: pantallas de 22» y 17», y un mueble lo más pequeño posible que integre estas dos pantallas. Esta será la parte más divertida y original. Además, si tengo tiempo, quiero poner un plunger analógico, un accelerómetro para el nudge, y un monedero. Pero esto será otra historia. De momento ya hay mucha faena configurando las mesas B2S.

Xiangqi (ajedrez chino)

Hace unos días que he acabado el tablero de Xiangqi y las piezas, y ya he jugado algunas partidas. He estado probando diferentes maneras de rellenar con color negro o rojo las piezas. Las piezas negras (y el tablero) los he rellenado con silicona negra. El resultado es correcto, pero el problema es que al barnizarlo queda un poco pegajoso. Es por esto que finalmente el tablero no lo he barnizado. Las piezas rojas las he rellenado con Aquaplast mezclado con pintura acrílica roja, y el resultado es más que correcto. Me gustaría hacer más pruebas, por ejemplo algún otro tipo de silicona o bien resina epoxi o de poliéster.

Como mi máquina CNC es de 30x40cm, el tablero lo he tenido que dividir en dos parts, que he tenido que juntar con cola blanca y espigas de madera. El tablero es de madera de pino, y las fichas son de madera de boj de 5 cm de diámetro. Es un proceso lento y laborioso hacer las fichas de una en una (son 32 piezas en total). Evidentmente, el proceso sería mucho más rápido utilizando un tablero de pino.

A lo largo del proceso de construcción he hecho unas cuantas fotos, cuelgo un video de todo el proceso. Para mejorar el procedimiento de barnizado, he hecho un jig donde puedo barnizar por delante y por atrás las piezas de 8 en 8.

Prototipo PCB de doble cara con CNC

Estos días he estado perfeccionando cómo hacer un prototipo de PCB con la fresadora CNC.

Antes que nada he tenido que implementar el auto-probe para compensar la nivelación superficial de la placa donde quiero fresar. Este proyecto requiere la máxima precisión. El tema del auto-probe fue especialmente rápido y fácil de conseguir, cosa rara pues las cosas fáciles normalmente se complican de forma inesperada… Está documentado en [1].

Una vez el auto-probe está funcionando, ya puedo mirar de hacer las placas de doble cara. El principal reto está en girar la placa y que los agujeros en una capa y en la otra coincidan exactamente. Como se ve en la foto, esto se ha conseguido bastante bien, y la buena noticia es que hay margen para centrar bien los agujeros en la capa top (pues en la foto se ve que los agujeros no están exactamente centrados). Todo está bien documentado en el enlace [2]

Ahora que ya tengo el proceso bastante claro, ya puedo afrontar un pequeo proyecto que requiere una placa de doble cara. Consiste en montar un mini-ordenador, con finalidad puramente académica, con un microprocesador Z80 [3]. Pero antes de hacerlo, primero vendrá el programador de EEPROM [4], pues al ordenador se le ha de meter un programa en una EEPROM. No sé si todo estará listo antes de vacaciones.

En el pasado había hecho placas con el método UV y con el método de la plancha. Hay que decir que siempre he tenido dificultades varias en consegur placas con cualidad óptima. Ahora, con la CNC, estoy buscando una manera rápida de hacer prototipos. En gran medida creo que lo he conseguido. Ahora bien, el proceso, aunque satisfactorio, es más lento de lo que me pensaba.

Juego del Simon. Extraescolar de Robótica en el Balmes

Ya hemos acabado la extraescolar de Robótica al Balmes. Este año hemos programado el juego del Simon con una Raspberry Pi. Toda la documentación (y la programación didáctica) está en la wiki [1].

Durante estas 13 sesiones hemos ido trabajando sobre diferentes temas, que nos llevaban al objetivo final de hacer un prototipo de Simon:

  • Hemos programado el script con Python, viajando por las diferentes versiones a medida que necesitábamos incorporar nuevas funcionalidades.
  • Hemos conectado botones y LEDs a los pines GPIO de la RPi.
  • Hemos visto cómo, utilizando transistores, podemos disparar desde los pines GPIO señales de 12V para encender tiras de LEDs blancos.
  • Hemos discutido sobre la alimentación de todo el sistema, y alternativas.
  • Hemos discutido sobre cómo producir el sonido y su amplificación.
  • Hemos diseñado el mueble final, utilizando herramientas de fabricación digital como la impresora 3D y la fresadora CNC.

Al final ha sido un curso muy multidisciplinar, hemos tocado muchas cosas, aunque por falta de tiempo, conocimientos e infraestructura, muchas cosas las ha implementado el professor y las ha mostrado en clase. Pero al final la experiencia ha sido enriquecedora para todos.

El resultado final se puede ver en la foto y en este video:

Referencias:

Amstrad PCW8256. Probando el emulador Joyce



Estos últimos días he revivido el ordenador Amstrad PCW8256 que teníamos en casa hacia el 1986. Lo utilizaba mi padre para escribir, pero también lo utilizábamos para los trabajos del instituto. Venía con una pantalla monocroma verde, el teclado y la impresora de agujas. Toda la electrónica estaba en el monitor, incluso la placa de la impresora. Y en el monitor también había la disketera de 3», que tenía dos caras.

He instalado el Joyce en la Raspberry Pi, y me ha gustado revivir este sistema. Evidentmente, se ha de escoger la opción de letras verdes, simulando la pantalla de fósforo verde.

El ordenador venía con dos disketes, que eran discos de arranque. El primer era el CP/M, el sistema operativo, desde el que se podía acceder al intérprete de Basic (Mallard Basic). El segudo diskette, tambié bootable, era el Locoscript, que es el processador de textos con que venía. He hecho un documento con LocoScript sobre los ríos de Catalunya, simulando como si fuese un trabajo del insti.

También he jugado un rato al Tetris. El emulador emula muy bien la máquina original. Si quieres jugar al Tetris, has de hacer eject del disket inserido (el CP/M)(el SO ya está cargado en la RAM), y meter el disket del Tetris (Insert). Entonces, ya desde la línea de comandos, ya se puede llamar al ejecutable y jugar al Tetris, com se ve en la imagen.

Qué tiempos aquéllos! El link en la wiki:

Calibración del sensor de temperatura DS18B20

Ya tengo prácticamente acabado el proyecto IoT con una REST Api [3][4] para leer la temperatura de un sensor DS18B20.

El problema (y grave) es que las temperaturas que estoy cogiendo del sensor son erróneas. Para saber cuál es la temperatura real en mi barrio (Gràcia-Barcelona) cojo como referencia la web de meteo.cat. La estación meteorológica automática más cercana es la de Zona Universitaria, aunque en realidad la temperatura no será la misma exactamente. La calle Joan Blanques, donde tengo el sensor, es estrecha y enmedio de la ciudad y del barrio; la Zona Universitaria es un espacio más ancho y abierto, posiblemente las temperaturas mínimas tiendan a ser más bajas…

Calibrar el sensor DS18B20 puede ser una tarea difícil. Aquí tenemos un artículo [1] muy interesante sobre cómo proceder para la calibración. El artículo es realmente interesante, pero no tengo el tiempo (ni las ganas) de implementarlo. Lo que sí que tendría que haber hecho, y esto era fácil, era comprar 10 sensores DS18B20 (son baratos), descartar aquéllos que se desvíen bastante de la temperatura real, y promediar la temperatura con el resto de sensores escogidos, por ejemplo 5. Esto no sería ningún problema, en la RPi tengo muchos pines GPIO disponibles.

Otra posibilidad es utilizar otro sensor de temperatura. Peo ejemplo, utilizar el BMP280, que además de la temperatura también tengo la presión y la humedad relativa (y es barato). Es muy interesante este artículo [2] donde se utiliza el BMP280 para construir una estación meteorológica alimentada per un panel solar.

La conclusión es que confiar en que el sensor que tengo dé la temperatura correcta es un grave error. El objetivo del proyecto es hacer un ejemplo didáctico de IoT, RestFul API, y gráficas como frontend. Esto ya está implementado, ahora sólo falta que la temperatura que leo sea real. Por tanto, lo que haré es encontrar una recta de regresión para aproximarme a la temperatura real a partir de los datos que me da mi sensor, suponiendo que la mejor aproximación sea una recta.

En la imagen se pueden ver dos gráficas. En la de arriba se ve la diferencia entre la temperatura real y la de misensor. En la de abajo se puede deducir la recta de regresión para convertir los datos del sensor en datos reales. De todas maneras, estos datos se corresponden a dos días y medio. Esperaré una semana más (y que suban las temperaturea del mes de mayo, y así tener más rango) para poder hacer una recta de regresió.

Enlaces:

Internet of Things, Restful API con Python y Flask, Raspberry Pi Zero y sensor de temperatura

Estoy montando un proyecto académico de Internet of Things. Se pretende medir la temperatura exterior en mi barrio con un sensor DS18B20 conectado a una Raspberry Pi Zero. Tal como se ve en la foto, he tenido que conectar un lápiz Wifi USB. Idealmente sería mejor hacer el proyecto con la nueva Raspberry Pi Zero W que acaba de salir hace un mes, y que lleva wifi incorporada.

La temperatura se va almacenando cada 10 minutos en una base de datos MongoDB. La parte más interesante del proyecto es programar una Restful API, y para hacerlo lo haré con Python y el microframework Flask, a partir de algún ejemplo que he encontrado (ver los enlaces). En la versión 1 sólo había un servicio, que era el bolcado de todas las temperaturas. La versión 2 ya hace más cosas: bolcar todas las temperaturas; recuperar la temperatura actual; filtrar por un día; filtrar por varios días al mismo tiempo.

Otra parte importante es la capa de presentación, y para ello utilizo la librería Highcharts.com, que da unos resultados muy espectaculares. Para cada función de la API se dará un ejemplo html, para ejemplificar cómo se pueden digerir los datos.

En las futuras versiones de la API se calcularán las medias de temperatura diarias, mensuales y anuales, de manera que se puedan hacer comparativas entre días, meses,… De momento todavía no está disponible.

La API todavía no es pública, estoy en fase de desarrollo. En el momento que sea estable y pública ya lo anunciaré. De momento la tengo dentro de casa, bajo los efectos del termostato de la calefacción, con lo que los resultados no son interesantes. Pero la idea es después de Semana Santa trasladarlo todo al local, el sensor en el exterior, y la Raspberry Pi dentro del local. Se podrá acceder a la API en el domini ohttp://joanqc.no-ip.biz/, pero todavía no está disponible.

La idea de desarrollar esta API es, a parte de que programar es divertido, poder utilitzar open data en formato JSON en la asignatura de Javascript (M06) en el ciclo de Desarrollo de Aplicaciones Web (DAW), en el instituto. Evidentmente, hay muchos ejemplos disponibles de open data y format JSON. Pero un ejemplo donde los alumnos vean de dónde salen realmente los datos, siempre será interesante.

En el primer enlace tenemos la documentación y discusión de toda la puesta a punto. Es el punto de partida principal si se quiere reproducir el proyecto. En el segundo enlace se documenta la API, en sus diferentes versiones.

Adaptación de los emuladores MAME y gngeo para limitar el tiempo de partida

Tenía pendiente desde octubre conseguir esta funcionalidad. Se trata de una máquina en que la operación está controlada por el tiempo. Una moneda son 15 minutos de juego. Los emuladores MAME y gngeo (NeoGeo) tienen el botón de COIN que permite dar créditos para jugar. Ahora bien, el monedero controla el contador de tiempo, y es necesario meter monedas para dar tiempo a las partidas. La comunicación entre el front-end y los dos emuladores se hace sencillamente con un fichero de texto donde se lee y se graba el valor del contador. La funcionalidad implementada es:

  • Cuando estoy en el front-end el tiempo no corre. Si se mete una moneda, suma el tiempo establecido (15 minutos por defecto).
  • Cuando entro en el emulador (mame4all o gngeo), se lee el valor del tiempo restante, y empieza a descontar el tiempo, que está siempre visible.
  • Desde el emulador puedo poner una moneda, suma el tiempo, y se actualiza el contador correctamente.
  • Cuando salimos del emulador y volvemos al frontend, el tiempo queda bien guardado.
  • Si mientras juego se acaba el tiempo, se vuelve al front-end, esperando la inserción de una nueva moneda.

Cambios en el código y documentación:

    \t

  • http://wiki.joanillo.org/index.php/M%C3%A1quina_Arcade_amb_monedes_i_limitaci%C3%B3_de_temps._MAME_i_neogeo#Introducci.C3.B3_2

Y el video: