es-robot.com

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.

Estoy empezando a hacer algunas pruebas con presencebot, un experimento sencillo que consiste en reflejar de forma física la presencia virtual en messenger de microsoft.

Para obtener el estado online de una persona, estoy utilizando la librería Windows Live Presence API, que no es más que un api json para obtener el estado online de un usuario de messenger, que previamente se tiene que haber registrado. Usar este api tiene la ventaja de que es web y por lo tanto accesible desde cualquier lugar con conectividad a internet y la desventaja de que al ser web es más lento que un plugin local de messenger.

Otra ventaja es que el funcionamiento del api es muy sencillo, sólo hay que seguir los siguiente pasos:

1. Aceptación de condiciones: Antes de usar el API, la aplicación debe hacer que el usuario se inscriba en el servicio y acepte las condiciones de uso. El registro se hace en la siguiente url:

http://settings.messenger.live.com/applications/websignup.aspx?returnurl=[URL]&privacyurl=[URL]

Los parámetros que debemos enviar son returnurl con la dirección de vuelta una vez que el usuario ha aceptado (ó rechazado) la entrada en el servicio y privacyurl que debe apuntar a un texto explicativo de las condiciones de privacidad de nuestra aplicación.

Si el usuario acepta, es envíado a returnurl, cón los siguientes parámetros id y result. Result nos informa del resultado del registro: Accepted si acepta registrarse, Declined si rechaza el registro, NoPrivacyUrl si privacyurl no es válida. Id nos devuelve el identificador del usuario, que se necesitará para hacer la consulta propiamente dicha.

2. Consulta del estado: Después del registro, el estado del usuario se puede consultar en la siguiente url:

http://messenger.services.live.com/users/[ID]/[resource]

Id es el recibido en returnurl y sirve para identificar al usuario. Hay que tener en cuenta que es case sensitive así que cuidado con las mayúsculas/minúsculas. Resource puede tomar los valores presence ó presenceimage. En el primer caso se obtiene un objeto json con el estado online del usuario y en el segundo la url de una imagen que representa el estado online.

En esta url se pueden encontrar los elementos devueltos en el objeto json. El que me interesaba en este caso es “status” que puede tener los valores conocidos de msn:

Online, Away, Idle, BeRightBack, Busy, OutToLunch, OnThePhone, Offline

Con ruby se puede hacer un programa que chequee el estado online en apenas 15-20 líneas, cuando tenga terminado el proyecto publicaré el código fuente.

Realmente es un api muy sencillo de usar, con la única pega de que una vez que el usuario se ha registrado, cualquier aplicación puede acceder a esta url para consultar el estado del usuario, lo que no es demasiado bueno de cara a la privacidad.

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.

Al final he decidido trasladar el blog a wordpress y de paso lo he rediseñado. Después de haber probado wordpress, me parece mejor opción que blogger, con más opciones de configuración y administración. Aunque blogger es más que suficiente para publicar, me parece que wordpress es más potente.

El rediseño no estaba planificado, pero después de intentar adaptar la plantilla de wordpress y de buscar una plantilla parecida, al final me ha parecido mejor hacer un diseño nuevo. Lo he hecho yo mismo basándome en una plantilla existente aeros de thebuckmaker y la imagen de fondo es una modificación de una imagen de :mrMark: titulada We .. were .. waiting .. ages” they droned.

Espero que os guste.

La habitación china se trata de un experimento conceptual propuesto por John Searle en 1980 que se ha convertido en un clásico de la inteligencia artificial.

El experimento consiste en lo siguiente: tenemos a una persona que no habla, ni comprende el chino, encerrada en una habitación. A esta persona, le llegan una serie de textos escritos en chino a través de una rendija. En la habitación tiene una serie de normas y procedimientos en papel, que describen lo que debe escribir en cada caso. Cuándo le llega un texto, sólo tiene que seguir esas normas escritas y escribir la respuesta, que estará correctamente escrita en chino.

Para pasar el test de Turing un juez debe determinar, haciendo preguntas en chino y examinando las respuestas, si han sido generadas por un ser humano. Si el juez es engañado, podemos decir que la habitación es inteligente.

Suponiendo que conseguimos una habitación con una serie de normas escritas que superan el test de turing y engañan al juez, el argumento de Searle es que el test no es válido para identificar una máquina inteligente, puesto que la persona en el interior de la habitación ni siquiera comprende el lenguaje chino y el resto de elementos de la sala no son inteligentes.

El experimento pretende demostrar que una máquina que se limite a realizar un procesamiento sintáctico (seguir unas reglas para componer un mensaje escrito) no puede ser inteligente. Como consecuencia, cualquier intento de crear inteligencia artificial a través de ordenadores no tendrá éxito, puesto que un programa de ordenador no es más que un procesador sintáctico de símbolos (las normas escritas en papel). Además invalida el test de Turing cómo herramienta para identificar inteligencia, puesto que la máquina descrita no es inteligente y sin embargo pasa el test.

Sin embargo, si suponemos que la habitación pasa el test de Turing, esto implica que el juez (si ha comprendido bien el test) está realizando preguntas que implican un nivel semántico profundo. Por ejemplo, le preguntará a la máquina qué entiende por existencia, qué piensa del amor, qué recuerda de su infancia, a lo que la habitación china debe responder inteligentemente. Si después de un rato el juez repite las mismas preguntas, la máquina (como ser inteligente) deducirá que el juez no le ha comprendido y matizará las respuestas (si una persona repitiese exactamente lo mismo cada vez que le preguntamos algo, no lo juzgaríamos como inteligente). A pesar de que la sala funciona mediante el procesamiento sintáctico de símbolos, si supera el test es porque ha conseguido generar una comprensión semántica.

Mi argumento es que el test no está correctamente planteado. No se puede demostrar que siguiendo una serie de reglas sintácticas puede surgir este comportamiento semántico, pero tampoco lo contrario. No sabemos si ejecutando millones de reglas obtenemos un sistema capaz de comprender a nivel semántico. Sólo podemos decir que la sala para superar el test debe estar a un nivel semántico. Ni el experimento, ni los contraejemplos eliminan la duda de si esto es posible con una máquina de turing, con lo que el experimento de la habitación china está por ahora en tablas. Creo que es posible conseguirlo, pero ahora mismo es una cuestión de fé.

Me gusta compararlo con la mecánica cuántica y la mecánica clásica. Si sólo conocieramos las leyes de la mecánica cuántica y estuvieramos jugando con un puñado de átomos sería imposible prever las leyes de la mecánica clásica. Necesitamos un número gigantesco de átomos para tener planetas y gravedad.