Tag Archives: arduino

processing.js

Posted on by
Reply

Para los que trabajen con arduino, sabrán que es un proyecto basado en Processing, un lenguaje y entorno de programación para aplicaciones multimedia e instalaciones interactivas. Lo que quizá no sepan es que processing se ha portado a javascript utilizando la nueva etiqueta canvas de html5: processing.js. En el estado actual, soporta muchas de las instrucciones de processing, excepto las instrucciones 3D, que esperan poder implementarlas cuando se desarrolle una etiqueta canvas 3D (para firefox ya hay un intento de implementación). Además processing.js fue portado por John Resig, creador entre otros proyectos de la librería jquery. Igualmente sorprendente para mí es que muchos de los ejemplos de chrome experiments están hechos con processing.js.

Una ventaja de processing.js sobre processing es que además de ejecutarse en navegadores recientes y aceptables sin ningún plugin (explorer no entra en esta categoría todavía) se integra fácilmente con el entorno web y se pueden agregar otras librerías javascript (jquery, por ejemplo) para realizar experimentos muy visuales.

El lado negativo está en el rendimiento, que no es nada bueno. En mi ordenador con 4 cores, se me quedaba bloqueado porque sólo tiraba de una cpu. Si alguien diseña un proyecto complejo, debería implementar parte de la lógica con web workers.

alternativas y complementos de arduino

Posted on by
Reply

Hace poco me encontré con un rediseño de arduino especializado para robótica. Echando un vistazo por la red he encontrado un par de alternativas a arduino que también tienen buena pinta:

  • La primera es pinguino, una tarjeta que nace con el objetivo de implementar un controlador pic al estilo arduino, pero a través de soporte USB en el microcontrolador, sin necesidad de un circuito adicional cómo sucede con arduino.
  • La segunda es illuminato, una ampliación de arduino, pero con más puertos de entrada-salida, más memoria y un diseño esclusivo con un montón de leds en la parte de atrás.

Por ahora me quedo con el arduino original, al que acabo de enchufarle un shield ethernet que funciona casi a la perfección. Hay un pequeño problema con el reset entre el shield ethernet y la tarjeta Arduino Duemilanove, que se resuelve conectando un condensador entre el pin de reset y tierra. Parece que el tiempo de reset de arduino Duemilanove es demasiado corto para el shield y hay que aumentar el tiempo conectando un condensador. Para robótica, si no encuentro ninguno más interesante creo que voy a comprar el shield de control de motores de Adafruit, que nos facilita el control de motores a través del circuito L293D. Entre el shield ethernet, una fonera que tengo suelta y el shield adafruit, creo que podré montar un robot móvil interesante.

roboduino

Posted on by
1

Vagando por internet para resolver un problema con mi arduino, me he encontrado con una tarjeta compatible pero especializada para robótica, que se llama roboduino. Es la ventaja de desarrollar hardware abierto, que facilita la existencia de productos especializados a diferentes campos. Hace tiempo que vi la tarjeta lilypad, una versión de arduino para coser en la ropa (muy friki americano). Seguro que existen más versiones adaptadas a diferentes nichos, y además existe la posibilidad de hacer shields, extensiones para arduino, tarjetas que se conectan a arduino y extienden la tarjeta de alguna forma.

moviendo un servo con arduino

Posted on by
1

Después de conectar con la librería windows live presence, el siguiente paso en el miniproyecto presencebot es controlar un servo con la tarjeta arduino.

Lo más fácil es seguir las indicaciones de la documentación de arduino que incluyen un ejemplo de control de un servo. Añadiendo un poco de código para leer el puerto serie, conseguimos un programa muy sencillo al que se le pueden enviar comandos con minicom para controlar el servo. Dado que presencebot sólo controla los eventos online/offline, por ahora sólo he implementaro los comandos de posición alta y posición baja y un comando que devuelve la posición actual del servo.

El único problema en la librería de control de servos es que limita la temporización de nuestro programa: no podemos poner las instrucciones delay que queramos. Existe una versión nueva de la librería (SoftwareServo) que obliga a hacer el refresco de forma implicita: hay que llamar a una función refresh cada 50ms para que el servo actualice su posición. También existe una librería de control de servos mediante hardware que no tiene la limitación de temporización, pero está limitada a 2 servos.

En mi caso estoy usando la librería software, aunque probablemente termine usando la librería hardware. Para resolver el problema de la temporización en el caso del encendido/apagado de un led, he creado una función que controla el momento en el que se encendió el led y si ha pasado el tiempo suficiente, lo apaga. Ésta función hay que llamarla periódicamente, pero aunque sería mejor tener interrupciones temporales, en arduino es normal tener un ciclo de control periódico.

Sobre el protocolo de comunicación, prefiero que sea lo más sencillo posible y preferentemente en modo texto, para que se pueda trazar leyendo el ASCII directamente. Aunque sea menos eficiente en el consumo de ancho de banda (por ahora no es una cuestión importante), prefiero saber qué está haciendo sin necesidad de interpretar instrucciones en hexadecimal.

La experiencia con arduino es buena, es una placa versátil y potente (y eso que tengo la versión NG que ya está algo desfasada), tiene un coste relativamente bajo y cada vez hay más código y ejemplos en internet para usar esta tarjetita.

presencia física

Posted on by
1

Me gusta la robótica porque es el punto dónde se mezcla el mundo físico con el mundo “programado”. En la mayoría de aplicaciones que programamos en ordenador, la interacción con el mundo físico se limita al teclado-ratón-monitor. Cómo mucho añadimos sonido y no siempre se suele hacer, salvo en los juegos.

Así que cuando vi un producto conceptual cómo availabot inmediatamente me pareció interesante y después de analizarlo pensé en hacer algo parecido. Al igual que a los autores de availabot, me ha llevado 2 años ponerme a ello, pero ya estoy trabajando en una versión preliminar de “presencebot”.

La idea es sencilla: representar de alguna forma física la presencia on-line, en este caso la presencia en messenger. Tengo pensado implementar una variante con facebook y/o jabber, e incluso aumentar la funcionalidad en el futuro haciendo que se le puedan enviar comandos tipo “levanta”, “saluda”, etc. En el caso de availabot, la presencia física se trata de un muñeco parecido físicamente al dueño. En mi caso se limita por ahora a mover un servo conectado a una placa arduino. Si encuentro un muñeco apropiado, el servo movería el muñeco igual que availabot. Pero es posible realizar cualquier tipo de presencia física que nos interese: una campana que suena, una lámpara que se enciende, un muñeco que baila, cualquier cosa.

Inicialmente lo implementaré con ruby, el lenguaje más rápido que conozco para hacer prototipos y usará la biblioteca msn live presence, con un api rest. La elección de msn es porque tiene un api muy sencillo de usar y porque msn messenger está muy extendido. Además la ventaja de un api rest, es que se puede acceder desde cualquier punto con acceso a internet, aunque la desventaja es que tarda un poco en reaccionar. La parte física estará implementada con arduino, con su lenguaje de programación propio y al igual que availabot, se conectará por usb.