martes, 20 de septiembre de 2011

Lottie Lemon: el robot oficial de arduino diseñado por jóvenes españoles

Hola querido lector,

revisando las noticias del día, me he tropezado con esta en el blog de Bricogeek: http://blog.bricogeek.com/noticias/arduino/nuevos-arduinos/
Concretamente, con una novedad inesperada: un robot oficial de arduino, diseñado para facilitar los primeros pasos en robótica, pero lo más llamativo es que ha sido desarrollado por los chicos de Complubot, quienes cuentan con diversos premios en concursos internacionales de robótica.
El vídeo de presentación del robot es altamente recomendable: http://www.youtube.com/watch?v=NAiXv0Nvt0E&feature=player_embedded

Y repito: un robot oficial, avalado por el equipo de arduino.
De hecho, si has visto el vídeo, sabrás que fueron los padres de arduino quienes ofrecieron a los chicos de Complubot realizar este proyecto.


Llena de orgullo, y resulta esperanzador ver como, con esfuerzo, tesón y dedicación, todo es posible, en contra de los altos cargos en educación más pesimistas, incapaces de valorar, invertir y fomentar en el talento local.

miércoles, 14 de septiembre de 2011

Exposición fotográfica

Hola querido lector,

hoy tengo el placer, y el honor, de comentar que este viernes, día 16 de Septiembre, y hasta el día 30, los compañeros de la asociación FotoGranCanaria, y un servidor, expondemos en el Centro Comercial Atlántico, sito en Vecindario, Gran Canaria.

El mismo viernes por la tarde estaremos a las 19:00 con familiares, amigos, y aquellas personas que quieran compartir un rato.

¡Espero que lo disfrutes!



martes, 13 de septiembre de 2011

Pilas y flashes, flashes y pilas

Hola querido lector,

hoy voy a hablarte de mi experiencia con un quebradero de cabeza: las pilas y los flashes externos.

Opciones.
Voy a analizar la elección de las pilas, tomando en cuenta estas variables:

- Coste: las pilas no son nada económicas, máxime si hablamos de las alcalinas.
- Autodescarga: todas las pilas tienden a descargarse, es algo inherente a su química, unas lo harán más lento que otras.
- Carga: las pilas alkalinas dan un voltaje más elevado que las recargables, pero tienen menos carga (se acaban antes).
- Tiempo de reciclado: es vital porque no puedes tener al persona esperando mucho tiempo, ni perder una buena foto por esperar a las pilas.
- Frecuencia de uso: no es lo mismo usar el flash un par de veces al mes, que varios días a la semana.

Una vez vistas, hay una base para poder valorar, y decidir.
Obviamente, la variable más importante es el coste: las pilas no son nada económicas, y si usamos el flash con asiduidad, es una locura.
La siguiente variable importante es la frecuencia de uso: si usamos las pilas varias veces a la semana, o más de una vez, hay que replantearse las cosas.

¿Y el resto de variables? Dependen del tipo de pilas: alkalinas o recargables.

Como he dicho, me baso en mi experiencia, luego voy a dividir las opciones en dos: pilas alkalinas y pilas recargables.

- Pilas alkalinas: muy potentes (1.5V nominales y 1.7V a plena carga) , baja autodescarga (se pueden dejar en el cajón), pero muy caras y con poca carga.
- Pilas recargables: menos potentes (1.2V nominales y 1.4V a plena carga), alta autodescarga (está diseñadas para un uso frecuente), son caras pero tienen mucha carga (duran más).

¿Cuál elegir? Bajo mi experiencia, insisto, depende del uso:

- Varias veces al mes: pilas recargables, sin duda.
- Uso medio (2-3 veces al mes como yo): te recomendaría pilas normales, las puedes conseguir en Ikea por 2-3 euros y vienen en un pack de 8. Reciclan rápido, duran bastante guardadas sin usar.
- Uso esporádico: directamente, compra las pilas cuando te hagan falta.

Sobre las pilas recargables.
No te ofusques: no necesitas un cargador super sofisticado y carísimo, pero tampoco te compres uno rápido, hazme caso, si ves uno, sal corriendo y no mires atrás.
¿Por qué? Porque cargan las pilas con un voltaje muy superior al que admiten, logrando una carga muy rápida, pero a la vez, calentándolas en exceso, lo cual redunda en un tiempo de vida cada vez más corto.
En las primeras recargas no lo notarás, salvo cuando saques las pilas y te quemen al tacto (verídico), y pasado un tiempo, notes que te duran cada vez menos.
Si quieres un buen cargador, este modelo es interesante: http://www.amazon.co.uk/TechnoLine-BC-700-intelligent-Battery-Charger/dp/B004X4OZYG/ref=pd_cp_ce_1, no es caro y puede mostrar la capacidad de cada pila, cargarlas por separado, protección por exceso de temperatura, etc...
Sobre las pilas, te recomiendo las eneloop: tienen buena fama (las usan muchos usuarios exigentes, vaya), muy poca autodescarga y puedes conseguirlas por ebay o amazon con facilidad a precios interesantes.
Un detalle importante: búscalas de mucho amperaje. Cuanto más amperaje, más carga, y más durarán mientras las uses. Normalmente vienen de 2400-2500 mA. Desconfía de marcas poco conocidas y amperajes superiores (3000, 3200, etc...), porque suelen tener una carga real muy inerior a la indicada.

En caso de que te estés preguntando por qué no recomiendo usar esas pilas directamente, dado el bajo perfil de autodescarga, te invito a revisar este cálculo basado en el uso que les doy:

Dos veces al mes, aproximadamente, uso el flash, agotando, en el peor de los casos, 4 pilas.
Si me decanto por usar pilas de ikea, cada paquete me durará 2 meses.
Esto implica un gasto de aproximadamente, 1.5€/mes en pilas.
En cambio, si me decanto por las pilas recargables, tengo que conseguir un cargador, salvo que tenga uno, y comprar las pilas.
En el peor caso, unos 35 euros por el cargador y 4 pilas.

Haz tú mismo las cuentas ...

Conclusión.
En fin, como todo en esta vida, hay necesidades y necesidades, la cuestión es analizar y saber elegir.
Sin duda, la opción ideal sería tener pilas recargables con un buen cargador, pero si eres tan despistado como yo, y haces un par de salidas al mes, te vas a volver loco comprobando qué pilas están cargadas, cargarlas el día antes, etc...

Espero haberte ayudado.

¡Hasta la próxima!

La obsesión por la foto perfecta

Un artículo muy interesante http://www.dzoom.org.es/noticia-9117.html enviado por el compañero Suso.
No hay que ofuscarse con la imagen perfecta, sólo disfrutar ... o acabas frustrado porque nada te parece suficientemente bueno.

domingo, 11 de septiembre de 2011

Reducir el consumo de arduino

Hola querido lector,
si recuerdas la última entrada, expuse el proyecto de hacer un robot autónomo, y, como adelanto de la próxima entrega, hoy voy a hablarte, de manera breve (lo prometo, no muy extenso), sobre cómo reducir el consumo de arduino, concretamente, de los microcontroladores ATMega328 que montan las placas Duemillanova/Uno.
¿Por qué reducir el consumo? Si tienes tu arduino conectado a una toma de corriente, o un puerto usb, no será relevante, por supuesto, pero si pretendes montar un sistema alimentado por baterías (li-po, pilas, etc), el consmo pasa a ser crítico.
Un ejemplo práctico: el robot autónomo que estoy diseñando, agota una batería li-po de 2A en, aproximadamente, 36 horas.
No resulta especialmente crítico si puedes recargar la batería manualmente, pero después de unas pocas recargas, te darán ganas de tirarlo por la ventana.
Hay una solución, y es analizar el consumo energético de los componentes implicados.
En esta ocasión, voy a acotar el problema, y centrarme en la propia placa Duemillanova.

¿Por qué consume tanto?
Porque la placa no integra sólo el microcontrolador, sino un regulador de tensión, conversor Serie-USB, leds, condensadores, resistencias, cristal (marca los pulsos de reloj para hacer funcionar el microcontrolador a 16Mhz), diodos, etc.
Si juntamos todos los consumos, se dispara.
No cabe duda de que es una placa muy cómoda y sencilla de usar: enchufar y listo, si nos equivocamos con algún cable, los fusibles nos protegen, y l regulador de tensión se encarga de hacer el trabajo sucio si conectamos el arduino a un transformador.
Maravilloso, ¿verdad?
Pero es fácil perder de vista una cuestión clave: arduino se diseñó como una plataforma para facilitar el acceso a la computación física por parte de artistas, aficionados, etc... y ello supone un coste.
Si tienes curiosidad, puedes mirar el esquema de una placa duemillanova en http://arduino.cc/en/uploads/Main/arduino-duemilanove-schematic.pdf
Te adelanto que podemos reducir el esquema, y dejar sólo el microcontrolador.


Reducir el consumo
Antes de entrar en materia, y como ya dije, facilitar el acceso a la computación física tiene un coste, aunque por ahora, voy a centrarme en lo relativo al consumo eléctrico.

LO QUE VOY A COMENTAR A CONTINUACIÓN SE BASA EN MI EXPERIENCIA PERSONAL.
NO ME HAGO RESPONSABLE DE POSIBLES DAÑOS O CONTRATIEMPOS OCASIONADOS O DERIVADOS POR LA MANIPULACIÓN DE CUALQUIER COMPONENTE

El consumo de una placa duemillanova, como te dije, viene dado por la cantidad de componentes electrónicos que monta.
Si sabes un poquito de electrónica, reconocerás la función que desarrolla cada uno, pero si apenas tienes nociones, o no sabes nada, te hago un breve resumen.
Para alimentar el arduino a 16 Mhz, hace falta una fuente de alimentación que suministre 5V de manera estable (el puerto USB lo hace perfectamente), y según la cantidad de componentes que montemos en el circuito (sensores, leds, etc...), el consumo aumenta (necesitamos más amperios).
¿Cuál es el problema? El regulador de tensión, el adaptador USB-Serie, los leds, etc... consumen corriente, aunque no estén en funcionamiento.
Ojo, que depende de cada componente el pico de consumo: el regulador de tensión consumirá más cuando se le enchufe a un transformador, pero mientras, tiene un consumo mínimo.
Esta situación desencadena en alimentar una serie de componentes sin que tengan uso, siempre desde el punto de vista de un sistema autónomo alimentado por baterías.
Para ilustrar desde un punto de vista práctico el consumo, he montado el siguiente circuito:

Un circuito muy simple: arduino, led, alimentación (uso un portapilas con elevador de tensión para facilitar las medidas de corriente con el polímetro).
El código fuente lo tienes en los sketchs de ejemplo: Basic -> Blink
Midiendo con el polímetro, arroja un consumo de 29 mA.

Puede parecer poco, pero hagamos unas cuentas rápidas usando una batería de 2A:

(2000mA/Hora)/29mA = 69 horas

Es decir: tenemos una batería que suministra 2 amperios/hora (simplificando), y un circuito que demanda 29 miliamperios.
Convertimos amperios en miliamperios, dividimos y obtenemos un tiempo de vida aproximado de 69 horas.
Y digo aproximado, porque según se descargue la batería, el voltaje irá en descenso también (será más o menos lineal la caída de tensión), hasta no suministrar más corriente.
No está mal, ¿verdad? Podemos tener un led parpadeando durante, aproximadamente, 2 días y medio.
¡Pero se puede mejorar!
Antes comenté que la placa duemillanova funciona a 16 Mhz, una velocidad más que adecuada (todavía recuerdo mi i286 a 16 Mhz...), pero no necesariamente fija.
Si echas un ojo a las diferentes versiones de arduino, verás que hay placas que corren a 8 Mhz.
¿Por qué reducir la frecuencia del reloj e ir más lento? Porque consume menos.
Piensa: si procesas menos instrucciones por segundo, necesitas menos electricidad.
Es como el cuerpo humano: no es lo mismo andar, que ir corriendo, ¿verdad?
Habrán casos en los que se pueda sacrificar la capacidad de proceso (estamos basándonos en los ciclos de reloj), con tal de ganar batería.
Pero vayamos un paso más allá: como recordarás, el consumo de los componentes de la placa es constante, y créeme, elevado, para lo que es.
Vamos a hacer lo siguiente: pongamos el microcontrolador en una protoboard, sin nada más.
No voy a entrar en detalles, porque es una cuestión bien documentada en la página oficial: http://arduino.cc/en/Tutorial/ArduinoToBreadboard
Verás varias opciones: me voy a basar en Minimal Circuit (Eliminating the External Clock)
Aunque es un proceso muy bien detallado, NO LO HAGAS SI NO ESTÁS SEGURO.

DETALLE: el arduino que va a recibir el nuevo bootloader, EL QUE ESTÁ EN LA PROTOBOARD, debe tener un cristal de 16Mhz o no será capaz de cargar el código. NO hará falta de nuevo cuando hayas cargado el nuevo bootloader. Es un pequeño error en la documentación oficial.

El nuevo montaje queda asi:


Si te fijas, no hay cristal para microcontrolador, ni electrónica adicional.
Esto es muy peliagudo: si enchufamos mal la alimentación, podemos romper los componentes.
Y te refresco la memoria: estoy usando un portapilas con elevador de tensión, no pilas sin más.
Una vez más, vamos a medir la corriente consumida: 11 mA.
Hemos reducido el consumo en 18mA, no parece mucho, pero hablamos de más del 50%, una magnitud respetable, ¿verdad?

Y aún podemos ir un paso más allá reduciendo la frecuencia hasta 1 Mhz.

Lento pero seguro.
Una característica muy interesante de prescindir del cristal externo, es poder reducir la frecuencia del microcontrolador: 8Mhz es una velocidad interesante, pero dependiendo de las necesidades, podemos bajar hasta 1 Mhz.
¿Por qué no usar siempre esta frecuencia? Según la capacidad de cálculo que necesites, puede ser una velocidad muy muy lenta, pero para casos muy simples, puede ser más que suficiente.
Hay dos maneras de hacerlo: modificar el bootloader (complejo y requiere un grabador), o modificar el reloj del sistema dinamicamente. Si tienes un portátil, te sonará aunque sea de oídas: se modifica la frecuencia del procesador según demanda, economizando en batería.
Aquí vamos a hacerlo mismo, pero con un microcontrolador, claro.
Si quieres profundizar en esta cuestión, puedes leerte este post del foro de arduino: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1163418637/all

En esencia, la manera de modificar la frecuencia del reloj en un microcontrolador ATMega328, es insertar este código fuente en el programa allá donde querramos modificar la frecuencia:

CLKPR = (1<<CLKPCE);
CLKPR = B00000011;

La primera línea activa el escalado dinámico, y la segunda, indica la cifra por la que se divide el reloj interno (extraído de http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1163418637/all):

0000 - 1
0001 - 2
0010 - 4
0011 - 8
0100 - 16
0101 - 32
0110 - 64
0111 - 128
1000 - 256
Es decir: vamos a dividir por 8 la frecuencia interna del reloj, quedando en 1Mhz. OJO: no se puede incrementar la frecuencia, sólo dividirla. Para el caso que estamos manejado, con el parpadeo de un led, vamos a insertar este código en la función setup, antes de ejecutar nada. Tranquilo: puedes usar este código sin problema, no afecta al microcontrolador de manera permanente, es inocuo, y sólo funciona mientras funcione el programa en ejecución. Bien, cargamos el programa, ejecutamos y ... el led parpadea muy despacio, se mantiene mucho tiempo encendido. ¿Qué es esto?¿Se ha roto algo? Calma, está todo bien.
Como sabrás, hemos reducido la frecuencia del reloj, por lo cual, se ralentizan todas las funciones de entrada/salida, delay, etc...
Esto se deriva de las librerías de arduino: para facilitarnos el trabajo, encapsulan las llamadas al sistema, cálculos, etc ... dejando en nuestras manos un API muy sencillo.
Y me reitero: todo tiene un coste: en este caso, no poder controlar, aparentemente, la duración de dichas llamadas cuando se modifica la frecuencia del sistema.
¿O sí? Claro que sí.
Como dije, las librerías de arduino encapsulan la parte más compleja, y entre las abstracciones, está la de adecuar la velocidad de las llamadas de entrada/salida, y delay, a la frecuencia del sistema.
Esta frecuencia ha de definirse al compilar el código fuente, y si no indicamos al compilador que la nueva frecuencia es 1Mhz, tendremos unas llamadas que funcionan 8 veces más lentas (hemos pasado de 8Mhz a 1Mhz).
Cuidado con este baile de frecuencias: en este ejemplo tan simple, podemos ajustar la frecuencia a 8Mhz o 1Mhz, pero debes tener claro en qué momentos te conviene modificarla dinamicamente, y en qué va a afectar, o te volverás loco solucionando errores.
Hecha la aclaración, veamos donde indicar la nueva frecuencia del reloj del microcontrolador.
Editamos el fichero breadboard/breadboards.txt (recuerda leer el enlace donde se explica el proceso para usar un arduino en una protobard sin necesidad de cristal externo), y cambiamos la línea 18:

atmega328bb.build.f_cpu=8000000L


pasa a ser:
atmega328bb.build.f_cpu=1000000L


Compilamos, cargamos el código ... ¡et voilá! El led parpadea de manera correcta.
¿Y el consumo de corriente? ¿Ha variado? ¡Sí, y mucho! Ahora consume 5mA, un 50% menos que funcionando a 8Mhz, y un 17% menos que la placa duemillanova a 16 Mhz.
Impresionante, ¿verdad?

Aún se puede reducir más el consumo poniendo el microcontrolador en modo de reposo (sleep), aunque este modo implica no ejecutar ninguna instrucción (igual a cuando dejamos la tele en standby o el portátil durmiendo). Dejo para una próxima entrega la implementación y el análisis de consumos.
En resumen, para el ejemplo de parpadear un led:

Duemillanove 16Mhz: 29 mA
Protoboard 8Mhz: 11 mA
Protoboard 1Mhz: 5 mA

Me reitero en lo dicho: no hay una solución universal, todo depende de las necesidades que tengamos.
No es lo mismo manejar una matriz de leds, haciendo transiciones, o un motor de corriente contínua con las salidas PWM, que recopilar información de sensores a intervalos de tiempo, sin contar con la complejidad del código (más instrucciones, más ciclos y más tiempo procesando).
Hasta aquí esta entrega, espero que te haya resultado útil.
¡Hasta la próxima!

martes, 6 de septiembre de 2011

Facebook y los cambios constantes

Hola querido lector,

hoy me voy a permitir el lujo de hablar sobre esta gran red social, y digo gran, por el número de usuarios y la comunidad, porque en otros aspectos, bajo mi experiencia como usuario y desarrollador, cada vez languidece más.
Por una parte, hace pocos días advertí un cambio a la hora de visualizar imágenes: en vez de mostrar un popup (cuadro emergente) con fondo negro, como venía siendo habitual, se muestra uno con fondo blanco.
¿Qué relevancia tiene? Pues mucha: el fondo blanco distrae, el enlace para cerrarlo no es suficientemente visible, las flechas de navegación tampoco, y no favorece tampoco a las imágenes.
Si no, está el ejemplo de flickr: cuando realizó el último cambio de interfaz, añadió la posibilidad de ver las fotos sobre un fondo negro, y vaya si realza la imagen y ayuda a aislarla del entorno, porque, en definitiva, se trata de eso: centrar la atención en la imagen, sin distracciones, y realzarla.
Y esto sin hablar con los cambios en la disposición de la barra de chat, cada vez menos accesible.
Pero lo más molesto, pero realmente molesto, son los cambios en el API, y la cantidad de agujeros en la misma, algo que, personalmente, me pone nervioso: no sólo tienes que atender los requisitos de un desarrollo, sino encima, pelearte con un API mutante, que cambia sin previo aviso y no tiene el suficiente soporte, como para migrar.
Está muy bien mejorar, de hecho, debería ser una exigencia, tanto personal como profesional: la constante mejora y la excelencia, pero no a costa de dejar atrás a usuarios y desarrolladores.
Y es que nada frustra más que pegarte horas y horas indagando cómo hacer algo a base de atar cabos sueltos, buscando ejemplos (no todos usamos PHP) y haciéndolos funcionar.

Un ejemplo práctico: se me dio la necesidad de publicar en el muro de una página de Facebook, desde una aplicación en Ruby On Rails.
¿Problemas? A punta pala, como se dice en mi pueblo.
El problema radica en la arquitectura del API, y me corrija alguien si me equivoco: todas las publicaciones se hacen usando como identificador el ID de una aplicación, y un valor denominado ACCESS TOKEN, el cuál está ligado al objeto donde quieres publicar (página, aplicación, etc...).
Visto así, parece fácil, ¿cierto? Pero aún queda otro problema: ¿cómo obtienes el valor ACCESS TOKEN?
Para una aplicación es trivial: en la configuración de la misma, te viene dado, pero si quieres usar el muro de una aplicación, la cosa cambia enormemente.
A grandes rasgos: hay ejemplos, y se agradecen que existan, en stack overflow, pero pueden funcionarte (ves la ventana de Facebook pidiendo autorización para dar permisos de una aplicación sobre tu página y luego obtienes el ACCESS TOKEN), o no (obtienes el ACCESS TOKEN).
¿Solución? Usar el explorador del Graph API, poner el ID de la página para ver la información de la misma (al lado de donde pone GET), pulsar sobre "Get Access Token", ¡et voilá!: tienes el cuadro de diálogo pidiendo los permisos.
Asignas los permisos (publish_stream, manage_pages, offline_access), obtienes el ACCESS TOKEN y ¡¡maravilla!! tu aplicación postea en el muro de la página.

En esta página tienes un ejemplo de uso: http://stackoverflow.com/questions/4883699/easy-way-of-posting-on-facebook-page-not-a-profile-but-a-fanpage

Y aquí termina esta entrada, no sin antes aclarar que no comento con acritud, pero sí con ánimo de animar y mejorar una plataforma puntera, y facilitar la vida a quienes desean colaborar y crear alrededor de.

¡¡Hasta la próxima!!

viernes, 2 de septiembre de 2011

Robot autónomo con arduino

Hola querido lector,

tras un largo período sin publicar, vuelvo a retomar este pequeño rincón virtual, armado de nuevos proyectos y técnicas por experimentar.
¿Qué mejor manera de celebrar la vuelta que documentando un proyecto basado en arduino?
A grandes rasgos, consiste en desarrollar un robot capaz de recabar información sobre su entorno (temperatura, humedad, etc...), que no requiera intervención humana (autónomo) y tolerante a fallos.
Visto asi, el proyecto suena muy ambicioso, pero nada más allá de la realidad: en vez de comenzar desde cero y lidiar con mil y un problemas, voy a documentar a lo largo de varias entregas, el proceso, yendo desde el robot más básico (avanza, gira, avanza, gira), hasta un sistema tan autónomo como sea posible.
Y digo bien: tan autónomo como sea posible.
No es mi intención analizar un problema que podría dar para varias tesis doctorales, sino realizar un aprendizaje gradual, y por supuesto, compartirlo.
Huelga decir que estoy abierto a sugerencias, mejoras y críticas constructivas. Animo a cualquier persona que esté interesada, a participar activamente.
Dicho esto, aquí está el enlace al primer documento con los primeros pasos, y nunca mejor dicho: el robot empezará en una terraza semitechada, huyendo del sol con un algoritmo muy simple.
¡Hasta la próxima!