Open Source Hardware Con

Los días 23,24 y 25 de Septiembre se va a celebrar en Madrid el OSHWCon. Un evento organizado por el colectivo Synusia donde se promociona el hardware libre, la afición a la electrónica, el DIY, etc.

La entrada es gratuita, pero hay que inscribirse. Habrá charlas, talleres, mesas redondas y proyectos personales. En mi caso he creido interesante dar una charla sobre telemetría.

Si os gusta la electrónica y la robótica no os podeis perder este evento único que hará las delicias de todos los aficionados a la electrónica, robótica y cacharreo en general.

Crear PCB de dos caras en una insoladora de una sola cara

 

Si os gusta fabricaros vuestras propias placas, ya sabreis que hacerlo con el método de insolación suelen quedar mejor que con el de transferencia. Asi pues si teneis una insoladora de una cara, ya sea comercial o casera podeis seguir las instrucciones del siguiente video para fabricar una de doble cara. Aunque están en inglés se entienden bien.

Por otro lado ya sabeis que normalmente se usa sosa caustica para revelar la placa, cosa que a mi me parece un poco peligroso para la salud si no se toman las medidas oportunas, por eso quería recomendaros otro tipo de revelador que no es nada peligroso y que cumple muy bien su función: Revelador sin hidróxido de sodio.

Proceso de fabricación profesional de PCB. ITead Studio

En el C.i.r.e estamos pensando en crear una placa para robots (con micro, puentes en h, sensores, etc.) y después mandarla a fabricar a China para que la gente pueda adquirirla a muy bajo coste sin tener que pelearse con placas fotosensibles, insolado, revelado, ataque, perforación, soldadura de componentes smd, etc. Pero hasta que eso ocurra he mandado a fabricar por mi cuenta una versión mejorada de la placa de mi robot E.V.A.

Después de un tiempo buscando sitios en internet donde fabricasen placas, encontré la empresa ITead Studio, la cual tiene uno de los precios más baratos (si no el que más) para fabricar pcb.

En mi caso seleccioné la opción de fabricar 10 placas verdes de doble cara con un tamaño máximo de 10×10 centímetros. El coste es de 28$ + 5$ de gastos de envío, que hacen un total de 33$. Lo solicité el día 11 de Abril y ese día el euro estaba a 1,40784 dólares en paypal, por lo que el coste total fué de 23,44€, o lo que es lo mismo, a 2,34€ cada placa. Un  precio bastante bueno dado el tamaño de la placa y la poca cantidad de unidades pedidas.

El servicio de compra incluye el testeo de las conexiones eléctricas de 5 placas para comprobar que están bien fabricadas, aunque yo he recibido hoy las 10 y realmente son 6 placas las que estaban marcadas como probadas. Por 10$ más te incluyen el testeo de todas las placas.

Me puse a mejorar el diseño de la placa del robot E.V.A. para incluirle la opción de añadir dos encoders de pololu (eso significa añadirle alimentación y un pin de entrada para cada encoder) o cualquier otro encoder que funcione a 5 voltios; y alimentar el módulo de bluetooth de 3,3 voltios con un LM2937-3,3. El esquema es este:

El IC2 es el LM2937 aunque en el esquema aparezca como 7805, y es que como no me he descargado la librería de eagle de ese componente, y dado que el encapsulado es igual que el del 7805, es decir,  TO-220, lo he añadido sin problemas sabiendo que en ese punto irá el regulador de 3,3 V.

Después he pasado el proceso de generación del circuito a través del auto-route del eagle y no veais que gusto dá que muestre 100% de finalización cuando se usa doble capa en vez de una sola para las pistas:

Una vez hecho esto quedan por hacer los ficheros gerber que habrá que enviar adjuntos por correo electrónico a la dirección pcb@iteadstudio.com poniendo como asunto el número de pedido que te darán cuando hayas hecho la compra del servicio en la web.

No hagais como yo e intenteis crear los ficheros gerber por vuestra cuenta, dado que es muy probable que no os incluya alguna capa y os la echen para atrás como me pasó a mi. El día 11 de Abril envié los ficheros gerber comprimidos en zip al correo electrónico. Dos días más tarde me dijeron que enviaban los gerber a la a fábrica y que podrían tardar en fabricarlos entre 4 y 5 días laborables (Por cierto la fábrica es la misma que usa el servicio de fabricación de PCB de SeeedStudio). En ese mismo día recibo un correo donde me dicen que los ficheros gerber que envié no son correctos. Así que hice caso de la página donde te ofrecen un fichero .CAM para generar los ficheros gerber desde el eagle. Para quien no lo haya hecho es tan simple como:

  • Guardar el fichero .cam en el directorio cam donde esté instalado el eagle.
  • En el menú de la ventana del circuito seleccionar File/Cam Processor.
  • En la ventana que aparece seleccionar File/Open/Job y seleccionar el fichero ITeadstudio_CAM.cam.
  • Pulsar el botón Process JOB y en el directorio de nuestro proyecto se habrán generado los ficheros gerber.
  • Comprimir y enviar los que tengan extensión .GTL, .GBL, .GTS, .GBS, .GTO, .GBO y .TXT.

El 19 de Abril me enviaron un correo diciéndome que me enviarían el pedido. Me dieron un número de seguimiento equivocado que empezaba por RR y depués de varios correos con el departamento de pedidos me dijeron que se equivocaron y que era el mismo número pero que empezaba por RA.

En correos de España aparecía el 19 de Abril como Admitido y el 23 de Abril como Salida de la Oficina Internacional de origen. Y hoy 4 de Mayo ya lo he recibido:

Si pulsais en la foto podreis verla aumentada. Vereis que vienen en una caja, con protector de burbujas y separadas las 4 placas normales de las 6 testeadas eléctricamente (con una señal roja en uno de sus bordes). Una cosa curiosa es que vienen con un código que debe imprimir la propia fábrica además de la serigrafía que puse en su momento como podeis ver en la siguiente foto donde se ven las dos caras de la placa (esquina inferior derecha de la placa izquierda):

Las placas miden 8 x 5 cm.

Es importante hacer las cosas bien: pensar y repasar antes de enviar. En mi caso los 4 agujeros de las esquinas son demasiado pequeños para meter unos tornillos y tendré que agrandarlos con la dremel. Otro fallo es que el texto que pone alimentaencoder se cruza con el texto encoder1. Pero salvando esto ya tengo placas para hacer varios robots E.V.A.

Si os pasais algún viernes a la tarde por el medialab prado y estoy por ahí quizá tenga una placa de estas para regalaros.

Calculadora on-line de timers del PIC

Hace tiempo hice una calculadora para mi uso interno la cual calculaba los valores que había que poner a un timer de un microcontrolador PIC (con su preescaler, su frecuencia, etc) para llegar a un retardo determinado, o viceversa, dado un valor del timer calcular qué retardo provoca. Es muy sencilla y está hecha integramente en html y javascript:

https://www.sistemasorp.es/blog/temporizadores_pic.html

Robot EVA

Tenía pendiente publicar el modo en el que había construido mi robot Eva. Este robot hizo el segundo mejor tiempo en la clasificación del cosmobot de 2011 y quedó entre los 8 primeros, desbancado por su hermano VELORP (otro de los robot Zero) en cuartos de final. Básicamente comparte muchas características del robot Zero ya que ha sido también probado en el medialab y se han sacado las mismas conclusiones, sin embargo la placa es distinta y la programación también.

Los componentes que tienen en común son:

Sin embargo las ruedas son las del miniz, ya que logran poner el chasis más pegado al suelo y derrapan menos.

La batería no es una Lipo 1S sino 2S (7,4 V.) enchufada directamente a la baby orangutan. Esta se encuentra entre los motores para dejar el centro de gravedad en medio y centrar más el peso en las ruedas.

Como no tiene conversor DC-DC que mantenga un voltaje continuo hacia los motores, he usado un divisor de tensión que mide el voltaje de la batería y así puede calcular el PWM que tengo que enviar a los motores según esté más o menos cargada la batería. Esto se consigue con la siguiente fórmula:

PWM * 7,4 / batería

  • PWM: Es el PWM que queremos enviar al motor.
  • 7,4: Es el voltaje normal que tiene una batería de Lipo 2S.
  • batería: Es el voltaje que tiene la batería en un momento dado.

Así si le meto 180 de PWM y tengo 8,4 voltios en la batería al final mando al motor 159 de PWM.
Si en el anterior caso en la batería tengo 7,4 voltios entonces da los 180 exactos de PWM.
Si la batería está a 7 voltios le metería al final 190 de PWM.

Como la tensión de la batería no es constante sino que tiene picos, es mejor tener 10 valores de tensión y luego calcular la media arimética para tener un valor más coherente.

El divisor de tensión también es útil para saber cuando la batería está cerca de agotarse y parar el robot, salvando así que las celdas pasen por debajo de los 3 voltios.

Este es el esquema de la placa:

A comentar:

  • Tiene un pin auxiliar por si fuese necesario usarlo para algo.
  • Tiene unos pines para añadirle un módulo bluetooth (se baja la tensión con un par de diodos para lograr 3,6 V.).
  • Usa un 7805 para alimentar los sensores y el bluetooth.

El código fuente que he desarrollado lo expongo a continuación. Este implementa el control Proporcional Derivativo y hace uso de las librerías que provee Pololu para poder manejarse con los sensores y con la baby orangutan.

velocistaB_2.h

velocistaB_2.c

Como habeis podido leer en el código fuente tiene un sistema de calibrado por el cual guarda en la EEPROM los valores minimos y máximos de los sensores la primera vez que se calibra y ya no es necesario hacerlo en futuras ocasiones a no ser que cambien las condiciones de iluminación.

La calibración consiste en dejar el robot en la pista, pulsar el botón y que de unas vueltas sobre sí mismo, lea los valores de blanco y negro y los guarde además en la EEPROM. Las siguientes veces que pulsemos el botón ya no se hará la calibración y empezará a correr el robot.

Para realizar la calibración la EEPROM debe estar vacía, y eso se consigue con el siguiente programa:

Y por último un video (gracias Puck2099) de cómo funcionó en la cosmobot (tuve que bajarle un poco el PWM porque al final derrapa un poco y cambia de sentido):

Me he cambiado de hosting

Después de 5 años en Hostony he decidido cambiar de hosting ya que últimamente estába teniendo muchos problemas (errores del servidor, cambio de un día para otro la configuración provocando que algunos PHPs no se pudieran ver, me quitaban el acceso ssh después de haberselo pedido, hora desfasada, etc). Como en España los hosting siguen siendo caros para los servicios que ofrecen he optado por otro hosting americano llamado Bluehost, a ver que tal me va.

Sistema de riego automático

Muchas veces me ha surgido la necesidad de regar las plantas que tenía en casa mientras estaba fuera unos días. Por desgracia algunas de ellas han perecido por no ser regadas cada poco tiempo.

De esa necesidad surge este proyecto y para llevarlo a cabo he usado una bomba de agua, un bidón, un detector de nivel y una placa basada en un pic 16f628 con un relé.

La bomba de agua puede ser la que se usa para renovar el agua de una pecera o para mantener el chorro de una pequeña fuente. Sólo hay que conectarla a la alimentación de la casa para que empiece a bombear agua. Es muy importante que cuando esté enchufada tenga siempre agua, porque si no el motor se puede llegar a quemar. Por otro lado la altura de la manguera que va desde la bomba hasta el tiesto no puede ser mayor de un metro, ya que estos motores van perdiendo fuerza de bombeo a medida que crece la altura por donde tienen que enviar el agua.

El bidón que he usado en el proyecto es uno de los de agua mineral de 5 litros de cualquier marca. Al ser de plástico es fácilmente manejable para poder hacer un agujero y meter el detector de nivel.

El detector de nivel es necesario para evitar que la bomba siga extrayendo agua y se queme el motor por no tener agua que bombear. Yo he usado el de sure electronics.

La placa gobernada por un pic 16f628a es la que activará o desactivará la bomba de agua mediante un relé. Puede ser configurado mediante jumpers tanto el tiempo de riego como el intervalo. También se puede activar el riego manualmente mediante un botón.

Los componentes de la placa que he usado son:

  • Microcontrolador PIC 16F628A
  • 2 diodos led
  • 2 resistencias de 220 ohm.
  • 1 resistencia de 68K ohm.
  • 1 transistor BC237
  • 1 diodo 1N4148
  • Un relé de 12 voltios RA12W-K
  • Un botón
  • Un regulador 7805
  • Un condensador de 1000 uf
  • Un condensador de 100 uf
  • 2 bornes de 2 tomas y uno de 3 tomas.
  • Pines y jumpers
  • Fuente de alimentación de 12 V. y 0,5A.

Es importante que las pistas (o los cables de una placa de topos) que van a los contactos del relé sean más anchos para soportar la intensidad de la corriente.

Para no tener que pelar el cable de la bomba de agua, he usado un alargador que será al que se enchufe la bomba, pero que está cortado por uno de sus cables para poder engancharlo al relé:

El código fuente del PIC:

main.h

main.c

En el array repeticiones se ponen los milisegundos que dura el intervalo entre riegos, para poder seleccionarlo luego con los jumpers. En el array duraciones se ponen los milisegundos que dura el riego, para poder seleccionarlo luego con los jumpers.

Nada más arrancar el sistema empieza a contar los segundos que quedan para el siguiente riego, según esté configurado en los jumpers. Cuando llega ese momento o se pulsa el botón, el led de trabajo parpadea 4 segundos, permaneciendo encendido al igual que el relé para que funcione la bomba de agua mientras dure el tiempo de riego, según este configurado en los jumpers. Después el led se apaga, se desactiva el relé (y por consiguiente la bomba) y se espera de nuevo al evento de activación (por tiempo o hasta que se pulse de nuevo el botón).

Si el nivel del agua cae por debajo del sensor mientras se está regando se para automáticamente el riego desactivando el relé y encendiendo el led de alarma, que no se apagará hasta que el nivel esté otra vez por encima del sensor. Las siguientes veces que salte el evento por tiempo o por el botón, no activará el relé, protegiendo así a la bomba de estropearse.

Finalmente un video de cómo funciona el conjunto:

Usar el nunchuk en tus proyectos con Arduino

Una de las mejores cosas que tiene la electrónica es que puedes usar aparatos que se fabrican en serie con unas características increibles a precios muy bajos. En esta ocasión voy a explicar cómo usar el nunchuk de la wii para poder adaptarlo a vuestros proyectos electrónicos. En este artículo me centraré en la plataforma Arduino.

No es necesario tener la wii para adquirir un nunchuk, de hecho ni siquiera tiene por qué ser el oficial, un clónico puede llegar a costar 7 €. Por otra parte es necesario tener el wiichuck, que es un adaptador para el nunchuk con una tira de pines y hace más manejable el uso de este (no supera los 4€).

El nunchuk trabaja con una tensión de 3,3 v., pero también puede hacerlo a 5 v. (Limitando su vida útil, pero por 7€ …). Funciona mediante el bus I2C en su variante Fast (400Kb/s) y lo que podemos leer son los datos del acelerómetro XYZ, del joystick y de los dos botones que contiene. Lo que haré en este artículo es recuperar esa información y mostrarla por el puerto serie.

Para empezar hay que inicializar el nunchuk de la siguiente forma:

  • Enviar a la dirección 0x52 los bytes 0xF0 y 0x55.
  • Enviar a la dirección 0x52 los bytes 0xFB y 0x00.

A partir de entonces cada vez que queramos leer los datos tenemos que:

  • Enviar a la dirección 0x52 el byte 0x00.
  • Leer de la dirección 0x52 seis bytes.

Los 6 bytes que hemos leido contienen la información del acelerómetro, del joystick y de los botones, pero vienen formateados:

  • Primer byte: La posición X del joystick (0-255)
  • Segundo byte: La posición Y del joystick (0-255)
  • Tercer byte: Los 8 bits de mayor peso del eje X del acelerómetro (Finalmente tendrá un valor entre 0 y 1023)
  • Cuarto byte: Los 8 bits de mayor peso del eje Y del acelerómetro (Finalmente tendrá un valor entre 0 y 1023)
  • Quinto byte: Los 8 bits de mayor peso del eje Z del acelerómetro (Finalmente tendrá un valor entre 0 y 1023)
  • Sexto byte: que contiene
    • los dos bits de menor peso del eje Z del acelerómetro
    • los dos bits de menor peso del eje Y del acelerómetro
    • los dos bits de menor peso del eje X del acelerómetro
    • Un bit indicando el estado del botón C (0 si pulsado, 1 si no lo está)
    • Un bit indicando el estado del botón Z (0 si pulsado, 1 si no lo está)

Tomaremos los 3,3 v. y la masa que ofrece arduino, conectaremos el pin de data del wiichuck al pin analógico 4 y el pin de clock al pin analógico 5. No son necesarias las resistencias pull-up típicas del bus I2C ya que los pines analógicos 4 y 5 ya las tienen implementadas internamente y son activadas al inicializar la librería wire:

El código fuente simplificado al máximo:

Y así es como se ven los datos de una de las pruebas que he hecho:

Si os ha gustado me plantearé hacer otro artículo donde explico cómo hacer lo mismo para microcontroladores AVR y PIC.

Interactuar con la videocámara MD80 y un microcontrolador

Hace poco escribí una reseña sobre el clon de la videocámara MINIDV MD80. Al ser una videocámara de tamaño reducido se puede usar en los proyectos de electrónica que queramos, sin embargo su autonomía viene marcada por la batería que contiene, además de que el proceso de encendido/apagado y grabación/parada es manual. Mi intención ha sido sustituir la batería por otra fuente de alimentación (una batería más grande, un transformador de la corriente eléctrica, etc) y que tanto el encendido como la grabación se hagan a través de un microcontrolador. En este artículo voy a explicar los pasos que he seguido para conseguir mi objetivo.

En principio he desmontado la carcasa de la videocámara y he extraido la electrónica y la batería:

He desoldado la batería y en su lugar he puesto dos cables para unirlos a una protoboard (aunque podrían soldarse a una placa de topos o a una pcb). Después he soldado dos cables de wrapping a los terminales traseros del botón de encendido y otro cable de wrapping al terminal trasero izquierdo del botón de grabación:

A partir de aquí ya se puede usar la cámara con un microcontrolador. Para este artículo me he decantado por un pic 12f683. La idea es usar dos transistores NPN para que hagan la simulación de pulsar tanto el botón de encendido como el de la grabación, para este artículo he usado 2 BC547. El microcontrolador activará la base del transistor a través de una resistencia de 390K. y comunicará el colector con el emisor como si de una pulsación manual del botón se tratase. Sólo hay que tener en cuenta que para el botón de encendido, el cable de wrapping de la derecha tiene que ir al colector y el cable de la izquierda al emisor, y en el botón de grabación el único cable va al colector y el emisor va a masa (GND).

La batería que trae la videocámara es una LiPo de una sola celda y tiene una capacidad de 230 mAh. Esto nos da la pista de que a la cámara debemos alimentarla con una tensión de 3,7 v. Para ello he usado un regulador Step-Down basado en el chip AX3022 de sure electronics. Este regulador ofrece hasta 1,5 A., más que suficiente para alimentar la videocámara y el microcontrolador (que puede funcionar a 3,7 v.).

Finalmente así queda el conjunto en una protoboard:

El ejemplo que he programado en el microcontrolador es muy sencillo: Espera 5 segundos, activa el transistor del botón de encendido durante medio segundo, esto hace que la videocámara se encienda, espera otros 5 segundos, activa el transistor del botón de grabación durante medio segundo, esto hace que la videocámara empiece a grabar, espera 10 segundos, activa el transistor del botón de grabación durante medio segundo, esto hace que la grabación pare, espera 5 segundos y finalmente activa el transistor del botón de encendido durante medio segundo, que provoca que la videocámara se apague:

El código fuente del programa del pic:

Cuando vayamos a conectar la videocámara a un puerto USB para ver las grabaciones, no debemos olvidarnos de desenchufar los cables de alimentación que hemos soldado, ya que la fuente de alimentación ya no es la batería original que contenía.

Listar los grupos de un usuario de Active Directory en C#

Queremos hacer una aplicación para windows (o para la Web) en .NET donde debemos comprobar si un usuario pertenece o no a unos grupos determinados del dominio.  Esto nos sirve para saber si el usuario puede entrar en la aplicación y qué permisos tiene. Lo normal es que un grupo contenga a un usuario directamente, pero, ¿que sucede si un usuario no pertenece directamente a un grupo A, sino que pertenece a un grupo B que a su vez pertenece al grupo A?.

Para que funcione en todos los casos se debe buscar el aributo tokenGroups de la cuenta del usuario en el Directorio Activo. Este atributo contiene todos los SIDs de los grupos a los que pertenece el usuario directa o indirectamente.

Aquí pongo un ejemplo comentando de cómo se puede hacer: