mascotas electrónicas

Las mascotas electrónicas son, y serán cada vez más, una de las principales aplicaciones de la inteligencia artificial y la robótica. Hace poco en una asignatura del posgrado de inteligencia artificial que estudio en la uned, unos compañeros, Carlos Delgado, Miguel López Delgado, Óscar Sánchez Cesteros y Carlos Javier Gasco Lallave, hicieron una presentación bastante interesante sobre este tema, de la que he extraido algo de información y la he adaptado.

Se pueden distinguir dos tipos de mascotas electrónicas: las mascotas robot (por ejemplo, el aibo) y las mascotas digitales (cómo el famoso tamagotchi). Creo que a largo plazo, se distingurán poco unas de otras, sólo se diferenciarán del plano en el que actúen: en el mundo físico unas y en el mundo virtual las otras (y a más largo plazo posiblemente existan implementaciones híbridas, con una doble existencia física y virtual).
Independientemente del tipo, ambas presentan las siguientes características que definen a una mascota electrónica:

  • Se trata de un ser con el que se establece un lazo afectivo.
  • Debería tener autonomía propia (un agente autónomo).
  • No debería implicar un peligro físico o psicológico para nadie.
  • En el caso de las mascotas electrónicas, hacen referencia a su carácter artificial basado en electrónica (algún día las mascotas artificiales biológicas también podrían llegar).

Los principales desafíos que presentan las mascotas robot son:

  • Interacción social: los robots deberían ser capaces de tener emociones artificiales y ser capaces de transmitir estas emociones para que exista una interacción social con las personas. Además, deberían ser capaces de reconocer las emociones de las personas y actuar en consecuencia.
  • Aprendizaje: no deberían ser seres estáticos, deberían aprender de su entorno y memorizarlo para interaccionar con él.

En el caso de las máscotas robóticas, he encontrado una lista con algunas de las mascotas más vendidas, que incluye al dinosaurio Pleo, a la foca Paro, al iCat, al desaparecido perro aibo y al robot Papero. Se echan en falta los robots de Wow wee que, aunque la mayoría son más parecidos a marionetas que a mascotas (en el sentido de que son más teleoperados que seres autónomos), tienen un chimpancé que tiene pinta de ser muy realista: alive chimpanzee.

Quien sabe si llegaremos al punto donde, como en ¿Sueñan los androides con ovejas eléctricas?, los animales cibernéticos sustituirán a los animales reales.

alimentación automática en estación base

Para los más manitas, Chris Schur ha publicado un resumen de técnicas de alimentación automática en estación base. A los que conozcan el roomba, les sonará la técnica. Se trata de señalizar de alguna forma la estación base del robot, añadir capacidad sensorial al robot para poder detectarla y que éste sea capaz de volver para anclarse y recargar las baterías automáticamente.

Cómo indica Chris, hay varios problemas:

- Que la estación sea detectable por el robot.
- Que el robot sea capaz de llegar a la estación sin perderse y con la posición adecuada.
- Suministrar energía al robot de forma segura.

Algunos modelos de roomba son capaces de hacerlo, aunque desconozco que técnica usan. Existe por ahí un sistema comercial para los robots Pioneer, que usa sensores de infrarojo para la detección de la estación base.

la era del turismo espacial

Poco a poco, casi sin darnos cuenta estamos entrando en la era del turismo espacial. A los primeros multi-millonarios turistas espaciales, les seguirá dentro de poco los sólo-millonarios turistas espaciales y después el resto de turistas.
¿Y a quién no le gustaría ver la tierra desde el espacio? ¿Y cuanto estarías dispuesto a pagar por ello? Pues por algo será que sir Richard Branson ha creado Virgin Galactic y están empezando a mostrar cómo será el futuro espacio puerto de donde saldrán las naves con los turistas.
Pero sorprendentemente para mí, otra empresa que se va a dedicar al turismo espacial es Galactic Suite, que se trata de una empresa española de Barcelona, que además tiene buena pinta ¿serán capaces de llevarnos al espacio?

Todo esto debería beneficiar a la robótica. Aunque sólo sea por poner un recepcionista robótico para que le dé un aire futurista…

elegantes armas

Hace poco he visto este chiste en xkcd que refleja a la perfección el sentimiento que se tiene al programar en lisp:


“Elegantes armas, para una época mucho más civilizada.”

Lisp es el lenguaje de programación de la inteligencia artificial (clásica) por antonomasia. Paul Graham, que además de emprendedor es un gran defensor de lisp, tiene varios artículos a favor de lisp. Estos son algunos de sus argumentos a favor de este lenguaje (escribo de memoria, que alguien me corrija si me equivoco):

  • Tiene una sintaxis concisa. Paul sostiene que cuanto más conciso es un lenguaje de programación, más potente es.
  • Es posible redefinir el propio lenguaje, permitiendo crear nuevos lenguajes, por lo que en realidad es un meta-lenguaje.

Paul argumenta que los lenguajes de programación se están lispificando y creo que esto es más o menos lo que está pasando. Tomemos por ejemplo ruby y groovy. Ruby es un lenguaje de programación interpretado muy potente. Groovy es la versión javaficada de ruby (también existe Jruby, que es ruby ejecutado sobre la máquina virtual de java). Groovy es más bien una reinterpretación de java como lenguaje interpretado y creo que terminará imponiendose a medio plazo al propio java, para ciertos ámbitos de aplicación. Ambos son lenguajes relativamente modernos, ambos son interpretados y tienen closures que a su vez (y entre otras cosas) permiten la creación de lenguajes específicos de dominio (DSL’s). Aún así, no llegan a la potencia de las macros de lisp que permite redefinir el lenguaje y que existan dialectos del lenguaje (como scheme). ¿Máquinas virtuales? Lisp ya era interpretado en los años 60 y sólo ahora que el hardware lo permite se están redescubriendo las ventajas de los lenguajes interpretados.
El principal problema de lisp es su sintaxis, recargada de paréntesis como los del chiste, lo que lo hace difícil de mantener porque ser muy difícil de leer, aunque Paul Graham lo ve cómo un problema menor. Pero en esto discrepo y creo que es mejor usar ruby o groovy, que mantienen parte de las ventajas de lisp, sin la desventaja del mantenimiento.
En general también pienso que los lenguajes se están lispificando. Es lógico que cuanto más haga un ordenador por tí, mejor. Y por eso creo que no sólo se están lispificando, sino que poco a poco los lenguajes se están convirtiendose en algo más cercano al lenguaje natural, hasta que (idealmente) algún día no programemos, sino que hablemos directamente con los ordenadores.
Pero tampoco abogo por el “todo en ruby”. Es impensable implementar ciertas aplicaciones con un lenguaje interpretado (en particular en robótica) pero a alto nivel, es mejor tender hacia lenguajes cada vez más abstractos, que permitan, como lisp desde hace mucho tiempo, decir mucho con poco y adaptar el lenguaje a cada situación.

otro híbrido: patinador – andador

En robots.net nos muestran un robot japonés híbrido patinador – andador. En el video siguiente, el robot comienza caminando sobre sus patas y cuando llega a una carretera cambia a patinar sobre ruedas. Casualmente estoy aprendiendo a patinar y creo que este tipo de movimiento es muy complejo (al menos sobre 2 patas).
¿Cuál es el sentido de los robots de propulsión híbrida? Es una cuestión de eficiencia y de utilidad. La propulsión sobre ruedas es de las más eficientes energéticamente hablando, sin embargo en la naturaleza apenas existen animales u objetos que se desplacen rodando (excepto las plantas típicas de los western), porque no es un método práctico, las ruedas necesitan un terreno más o menos plano para rodar y si no se quedan enganchadas. Las patas no tienen ese problema, andan por casi cualquier terreno. También se puede diseñar un robot con orugas como los tanques, o con ruedas 4×4 dependiendo del terreno. Los híbridos tienen la ventaja de poder aprovechar el sistema de locomoción más apropiado a cada situación, a costa de una mayor complejidad mecánica (lo que se traducirá en un mantenimiento más caro).
Sólamente a largo plazo se podrá evaluar si realmente merece la pena hacer un diseño híbrido o no, pero mi opinión es que probablemente sea mejor hacer un diseño específico para la aplicación con un sólo medio de locomoción, creo que es difícil que un híbrido tenga sentido, por lo menos a corto plazo.
Pero como experimento es igual de válido que cualquier otro y hasta divertido probar con un robot que tiene varios modos de locomoción.