Robot humanoide jugador, método y sistema de utilización de dicho robot.

Robot (100) humanoide que comprende al menos un procesador configurado para que el robot se desplace sobre unos miembros

(140) inferiores, efectúe movimientos de miembros (150) superiores, emita y reciba unos mensajes que pertenecen al grupo de los mensajes visuales, sonoros, gestuales y/o táctiles y produzca al menos un comportamiento autónomo, constituyendo dicho al menos un comportamiento un elemento de una secuencia de un juego generada como respuesta a al menos un mensaje que pertenece al grupo de los mensajes visuales, sonoros, gestuales y/o táctiles, dicho robot estando caracterizado porque dicho al menos un procesador está configurado para que el robot haga al menos una pregunta en forma de mensaje que pertenece al grupo de los mensajes visuales, sonoros, gestuales y/o táctiles y determine si al menos un mensaje de respuesta que pertenece al mismo grupo contiene un respuesta verdadera, una respuesta falsa o una respuesta ambigua,

efectuándose dicha determinación mediante dicho al menos un procesador a la salida de un bucle de repeticiones determinadas en función de umbrales de reconocimiento de dichas respuestas.

Tipo: Patente Internacional (Tratado de Cooperación de Patentes). Resumen de patente/invención. Número de Solicitud: PCT/EP2011/060693.

Solicitante: Aldebaran Robotics.

Nacionalidad solicitante: Francia.

Dirección: 168 bis - 170 rue Raymond Losserand 75014 Paris FRANCIA.

Inventor/es: MONCEAUX,JÉRÔME, BOUDIER,CÉLINE.

Fecha de Publicación: .

Clasificación Internacional de Patentes:

  • SECCION A — NECESIDADES CORRIENTES DE LA VIDA > DEPORTES; JUEGOS; DISTRACCIONES > JUEGOS DE CARTAS, RULETA O JUEGOS DE MESA; JUEGOS... > Juegos no previstos en otro lugar (aspectos de juegos... > A63F9/24 (Juegos que utilizan circuitos electrónicos, no previstos en otro lugar)
  • SECCION B — TECNICAS INDUSTRIALES DIVERSAS; TRANSPORTES > HERRAMIENTAS MANUALES; HERRAMIENTAS DE MOTOR PORTATILES;... > MANIPULADORES; RECINTOS CON DISPOSITIVOS DE MANIPULACION... > B25J9/00 (Manipuladores de control programado)
  • SECCION A — NECESIDADES CORRIENTES DE LA VIDA > DEPORTES; JUEGOS; DISTRACCIONES > JUEGOS DE CARTAS, RULETA O JUEGOS DE MESA; JUEGOS... > Juegos no previstos en otro lugar (aspectos de juegos... > A63F9/18 (Juegos de preguntas y respuestas)
  • SECCION A — NECESIDADES CORRIENTES DE LA VIDA > DEPORTES; JUEGOS; DISTRACCIONES > JUGUETES, p. ej. TROMPOS, MUÑECOS, AROS, JUEGOS... > Figuras que se desplazan por sí mismas > A63H11/18 (Figuras que realizan un movimiento natural de marcha)
google+ twitter facebookPin it
Ilustración 1 de Robot humanoide jugador, método y sistema de utilización de dicho robot.
Ilustración 2 de Robot humanoide jugador, método y sistema de utilización de dicho robot.
Ilustración 3 de Robot humanoide jugador, método y sistema de utilización de dicho robot.
Ilustración 4 de Robot humanoide jugador, método y sistema de utilización de dicho robot.
Ver la galería de la patente con 13 ilustraciones.
Robot humanoide jugador, método y sistema de utilización de dicho robot.

Texto extraído del PDF original:

DESCRIPCIÓN

Robot humanoide jugador, método y sistema de utilización de dicho robot La presente invención pertenece al ámbito de los robots humanoides. Más precisamente, se aplica a los métodos de programación y de empleo de robots de este tipo para usos especializados, como el juego. Un robot puede calificarse de humanoide a partir del momento en el que posee ciertos atributos de la apariencia y de las funcionalidades del hombre: una cabeza, un tronco, dos brazos, eventualmente dos manos, dos piernas, dos pies… Más allá de la apariencia, las funciones que un robot humanoide es capaz de cumplir van a depender de su capacidad de efectuar movimientos, de hablar y de “razonar”. Unos robots humanoides son capaces de caminar, de hacer gestos, con los miembros o con la cabeza. La complejidad de los gestos que son capaces de efectuar aumenta sin cesar. Pueden incluso jugar al fútbol, habiéndose convertido la Robocup en el desafío en el que se enfrentan los mejores equipos de diseño de robots humanoides del mundo. Ciertos robots pueden hablar, como respuesta a palabras oídas e interpretadas o declamando un texto que se les envía por correo electrónico o puesto bajo la mirada. Se han diseñado ordenadores, por el momento no integrados a bordo en robots humanoides para jugar al ajedrez y han ganado a los mejores grandes maestros.

Por otra parte, los robots virtuales están muy presentes en el universo del videojuego, con un desarrollo considerable de los avatares de personajes reales que viven una “segunda vida” en un universo espejo del universo real (“Second Life”). Pero los robots físicos se han mezclado poco hasta hoy con el universo del juego. Como mucho, se pueden señalar algunas realizaciones sencillas, como el ROB (Robotic Operating Buddy) de NintendoTM en los años 1980. Este robot está programado para reaccionar a variaciones de luminosidad, de color o de forma de partes de una pantalla y tener unos comportamientos determinados en función de secuencias de un juego que se visualizan en la pantalla. Estos métodos han sido objeto de varias patentes, concretamente las patentes americanas US 4.729.563 y US 4.815.733. Sin embargo, el ROB no es móvil sobre piernas, lo que limita de manera importante su capacidad de participar en juegos diversificados. Tampoco tiene capacidad de comunicación mediante la palabra. El robot humanoide de la compañía SonyTM, que ha sido objeto de las patentes US 6.580.369 y 6.832.132 se describe en entornos de juego, concretamente de fútbol o de juegos de atletismo. Sin embargo, es su única actividad lúdica y no tiene una función que le permita participar en juegos complejos de un universo virtual, como juegos de estrategia. Se conocen igualmente unos autómatas no humanoides para realizar funciones especializadas de juego (ajedrez, ciertos juegos de cartas, Guitar Hero, etc…). Sería ventajoso poder disponer de un robot humanoide capaz de realizar la totalidad de estas funciones.

Sin embargo, el problema planteado por esta integración en una misma plataforma de robot humanoide de las capacidades de participar a la vez en juegos que requieren una capacidad física, una capacidad de expresión y una capacidad de reflexión no se ha resuelto mediante las soluciones de la técnica anterior.

En particular, los documentos WO01/12285, US2002/081937 y WO00/44464 divulgan unos dispositivos robóticos que pueden tener, en ciertas condiciones, unas capacidades de diálogo limitadas con un humano. Ninguno de estos documentos divulga un robot humanoide que tenga una capacidad de desplazamiento sobre miembros inferiores que disponga de capacidades de aclarar dudas parametrizables en interacciones con un humano u otro robot.

La presente invención resuelve este problema procurando un robot humanoide que puede, para una pluralidad de juegos, servir de interfaz a un jugador para dialogar con un juego, proporcionarle una ayuda inteligente para progresar en el juego y ocupar un lugar con participación completa de jugador en un juego multijugadores.

Para ello, la presente invención divulga un robot humanoide de conformidad con la reivindicación 1.

Ventajosamente, el robot de la invención es adecuado para reconocer objetos en su entorno y para integrarlos en la secuencia de dicho juego.

Ventajosamente, el robot de la invención es el animador de un juego de preguntas-respuestas en el que participa al menos otro jugador que debe proporcionar las respuestas a las preguntas hechas por el robot.

Ventajosamente, el robot de la invención es uno de los jugadores de un juego en el que participa al menos otro jugador y en el que debe reconocer a una persona o una cosa en función al menos de indicios que le son comunicados por dicho al menos otro jugador.

Ventajosamente, el robot de la invención es adecuado para buscar una ayuda en internet para efectuar dicho reconocimiento.

Ventajosamente, el robot de la invención es un jugador de un juego en el que es adecuado para cooperar con al menos otro jugador para resolver al menos un enigma.

Ventajosamente, los movimientos del robot de la invención están determinados en parte en función de primeras consignas de desplazamientos que le son comunicadas mediante un mando a distancia manipulado por un primer jugador, de segundas consignas de desplazamientos, antagonistas de las primeras consignas, que le son comunicadas visualmente por un segundo jugador y de terceras consignas de desplazamientos, antagonistas de las segundas consignas que le son comunicadas por un tercer jugador.

Ventajosamente, dicho mando a distancia es una carcasa portátil provista de al menos un sensor de movimiento y adecuada para traducir las salidas de dicho al menos un sensor en dichas primeras consignas.

Ventajosamente, al menos dos robots participan en un mismo juego, estando en comunicación dichos al menos dos robots mediante al menos un mensaje visual, sonoro y/o gestual.

Ventajosamente, al menos dos robots participan en un mismo juego, estando en comunicación dichos al menos dos robots mediante intercambio de mensajes de comportamientos.

Ventajosamente, dicho intercambio de mensajes de comportamientos se activa después de una etapa de identificación recíproca de dichos robots mediante intercambio de informaciones que los caracterizan.

Ventajosamente, dichos al menos dos robots son adecuados, además, para descargar una señal de sincronización de sus movimientos.

Ventajosamente, al menos un robot jugador y otro jugador se sitúan en dos lugares no unidos mediante una red local.

Ventajosamente, dichos al menos un robot jugador y otro jugador se comunican mediante protocolo de comunicación en red de área amplia y porque dicho robot jugador está dotado de medios autónomos de procesamiento para la codificación de los accesos de red.

Ventajosamente, un jugador es adecuado para comunicarse con el robot de la invención por medio de un código visual.

Ventajosamente, el robot de la invención es adecuado para realizar una función de asistencia a al menos otro jugador que consiste en efectuar al menos una acción en el juego en lugar del jugador.

Ventajosamente, dicha acción consiste en salvar el juego.

Ventajosamente, dicha función de asistencia consiste en aplicar unas consignas de control del acceso al juego.

Ventajosamente, el robot de la invención es adecuado para activar y gestionar las interrupciones y reanudaciones de una secuencia de juego.

La invención divulga igualmente un procedimiento de control de un robot humanoide de conformidad con la reivindicación 17.

La invención divulga igualmente un programa de ordenador de conformidad con la reivindicación 18.

Un robot humanoide como el que es objeto de la presente invención ofrece a los jugadores una experiencia completamente nueva poniendo a su disposición un avatar físico de un personaje virtual que, de esta manera, puede “salir” del mundo virtual para incorporarse al mundo real.

Teniendo en cuenta la gran versatilidad de las herramientas de desarrollo de los programas de juegos puestos a disposición de los creadores, es totalmente posible considerar el desarrollo de un universo completamente nuevo de juegos cuyos usuarios podrán proveerse de las aplicaciones en tiendas virtuales especializadas o intercambiárselas, si se elige un modelo no comercial.

El robot humanoide de la invención presenta igualmente unas ventajas complementarias. Puede sustituir de manera improvisada a un jugador que debe suspender su participación en un juego. Puede estar previsto igualmente para salvar periódicamente la configuración de juego, lo que permite añadir un medio de salvaguarda suplementaria, en caso de problema material o de software en una o varias estaciones o servidores de juego. Puede estar dotado de funciones de control parental sofisticadas que le permiten adaptar los períodos y las modalidades de un juego a la edad o al perfil de los jugadores y proporcionar en tiempo real y en lenguaje natural a los jugadores a los que se refiere las explicaciones que corresponden a los criterios de control programados.

Teniendo en cuenta sus capacidades de comunicación, el robot humanoide de la invención puede recibir fácilmente actualizaciones de sus programas y/o de sus datos que le permiten participar en juegos nuevos o en versiones nuevas de los mismos juegos.

Varios robots humanoides pueden participar igualmente en un mismo juego en roles idénticos (todos jugadores, todos ayudas, todos interfaces) o en roles diferentes.

Finalmente, las funciones de juego del robot humanoide de la invención son solo una parte de las funciones complejas que un robot de este tipo puede llevar a cabo. De hecho, un robot de este tipo puede garantizar una misión de asistencia y de vigilancia de una persona (niño, persona de edad avanzada, enfermo…) cerca de la que esté colocado, dando, llegado el caso, una alerta en caso de detección de una caída o de degradación de una función programada para ser vigilada.

La invención se entenderá mejor y sus diferentes características y ventajas se mostrarán tras la descripción que sigue de varios ejemplos de realización y de sus figuras adjuntas de las que: - La figura 1 es un esquema de la arquitectura física de un robot humanoide en un modo de realización de la invención; - La figura 2 es un esquema de la arquitectura de los softwares de alto nivel que permiten el pilotaje de las funciones del robot en un modo de realización de la invención; - La figura 3 es un esquema de la arquitectura funcional de edición y de programación de los comportamientos de un robot en un modo de realización de la invención; - Las figuras 4a, 4b, 4c, 4d, 4e y 4f representan diferentes arquitecturas funcionales y/o técnicas de implementación de la invención; - La figura 5 es una ilustración de un juego de adivinanzas que puede animar un robot humanoide jugador en un modo de realización de la invención; - La figura 6 representa el organigrama de procesamiento de otro juego en el que puede jugar un robot humanoide jugador en comunicación con un servidor de juegos en un modo de realización de la invención; - Las figuras 7a, 7b y 7c ilustran un juego de estrategia en el que puede participar un robot humanoide jugador en un modo de realización de la invención; - Las figuras 8a, 8b, 8c y 8d ilustran un juego de desafío que se juega con un robot humanoide en un modo de realización de la invención.

La figura 1 ilustra la arquitectura física de un robot humanoide en un modo de realización de la invención. Un robot de este tipo se ha divulgado concretamente en la solicitud de patente WO2009/124951 publicada el 15/10/2009. Esta plataforma ha servido de base para las mejoras que han llevado a la presente invención. En la continuación de la descripción, este robot humanoide puede designarse indiferentemente con esta apelación genérica o con su marca comercial NAOTM, sin que se modifique la generalidad de la referencia de este. Este robot comprende aproximadamente dos docenas de tarjetas 110 electrónicas del tipo orden de sensores y de accionadores que pilotan las articulaciones. La tarjeta 110 mostrada en la figura es la que controla el pie izquierdo. Una de las virtudes de la arquitectura es que las tarjetas que controlan las articulaciones son intercambiables en la mayoría. Una articulación tiene normalmente al menos dos grados de libertad y, por lo tanto, dos motores. Cada motor está pilotado en ángulo. La articulación incluye igualmente varios sensores de posición, concretamente unos MRE (Magnetic Rotary Encoder). La tarjeta electrónica de control incluye un microcontrolador comercial. Este puede ser, por ejemplo, un DSPICTM de la compañía Microchip. Es una MCU 16 bits acoplada a un DSP. Esta MCU tiene un ciclo de servomecanismo en bucle de un ms. El robot puede incluir igualmente otros tipos de accionadores, concretamente unos LED (Diodos electroluminiscentes) cuyo color e intensidad pueden traducir las emociones del robot. Este puede incluir igualmente otros tipos de sensores de posición, concretamente una central inercial, unos FSR (Sensores de presión en el suelo), etc… La cabeza incluye la inteligencia del robot, concretamente la tarjeta 130 que ejecuta las funciones de alto nivel que permiten que el robot lleve a cabo las misiones que se le asignan, concretamente, en el marco de la presente invención, la participación en juegos. Sin embargo, la tarjeta 130 podría estar situada en otro parte en el robot, por ejemplo, en el tronco. Sin embargo, se verá que esta localización, cuando la cabeza es amovible, permite sustituir estas funciones de alto nivel y, por lo tanto, concretamente cambiar completamente la inteligencia del robot y, por lo tanto, sus misiones muy rápidamente. O a la inversa, cambiar un cuerpo por otro (por ejemplo un cuerpo defectuoso por uno no defectuoso) conservando la misma inteligencia artificial. La cabeza puede incluir igualmente unas tarjetas especializadas, concretamente en el procesamiento de la palabra o de la visión o igualmente en el procesamiento de entradas/salidas de servicio, como la codificación necesaria para la apertura de un puerto para establecer una comunicación en remoto en una red de área amplia WAN (Wide Area Network). El procesador de la tarjeta 130 puede ser un procesador x86 comercial. Se elegirá de manera privilegiada un procesador de bajo consumo como el GeodeTM de la compañía AMD (32 bits, 500 MHz). La tarjeta incluye igualmente un conjunto de memorias RAM y flash. Esta tarjeta gestiona igualmente las comunicaciones del robot con el exterior (servidor de comportamientos, otros robots…), normalmente en una capa de transmisión WiFi, WiMax, eventualmente en una red pública de comunicaciones móviles de datos con unos protocolos estándar eventualmente encapsulados en una VPN. El procesador está pilotado normalmente mediante un OS estándar, lo que permite utilizar los lenguajes de alto nivel habituales (C, C++, Python,…) o los lenguajes específicos de la inteligencia artificial como URBI (lenguaje de programación especializado en la robótica) para la programación de las funciones de alto nivel.

Una tarjeta 120 está alojada en el tronco del robot. Es ahí donde se sitúa el calculador que garantiza la transmisión a las tarjetas 110 de las órdenes calculadas mediante la tarjeta 130. Esta tarjeta podría alojarse en otra parte en el robot. Pero la localización en el tronco es ventajosa, pues se sitúa cerca de la cabeza y en la intersección de los cuatro miembros, lo que permite, por lo tanto, minimizar el sistema de conexión que une esta tarjeta 130 a la tarjeta 120 y a las tarjetas 110. El calculador de esta tarjeta 120 es igualmente un procesador comercial. Este puede ser ventajosamente un procesador de 32 bits del tipo ARM 9TM cadenciado a 100 MHz. El tipo de procesador, su posición central, próximo al botón de marcha/parada, su unión al control de la alimentación hacen de él una herramienta bien adaptada para la gestión de la alimentación del robot (modo vigilia, parada de urgencia,…). La tarjeta incluye igualmente un conjunto de memorias RAM y flash.

Esta arquitectura con tres niveles es particularmente ventajosa para la implementación de la presente invención en la que el robot debe poder ejecutar unos movimientos coordinados y otras acciones como unas lecturas de sensores y simultáneamente interpretar palabras o signos emitidos en su entorno y reaccionar o responder a estos.

La figura 2 es un esquema de la arquitectura de los softwares de alto nivel que permiten el pilotaje de las funciones del robot en un modo de realización de la invención.

Una arquitectura de software de este tipo se ha divulgado concretamente en la solicitud de patente WO2009/124955 publicada el 15/10/2009. Esta incluye las funciones de base de gestión de las comunicaciones entre un robot y un PC o un sitio remoto y de intercambio de softwares que proporcionan la infraestructura de software necesaria para la implementación de la presente invención. Esta arquitectura se describe más abajo de manera genérica, sin mención específica de las funciones de software utilizadas en un juego dado, entendiéndose que estas funciones se procesan como cualquier otra función de software de gestión de los comportamientos del robot de la presente invención.

En la figura 2 se representa muy esquemáticamente un primer robot humanoide RH1 que comunica con un primer terminal remoto TR1, por ejemplo mediante unión inalámbrica por razones de movilidad. Se entiende por terminal remoto un terminal remoto de la plataforma servidor PFS, que proporciona, por medio de una red de comunicación, el acceso a un servicio web SW, específico para este tipo de robot humanoide RH1.

Por supuesto, las uniones de comunicación entre elementos del sistema pueden ser alámbricas, y los terminales móviles pueden ser, como variante, unos teléfonos móviles o unos ordenadores portátiles.

Un segundo robot humanoide RH2 se comunica con un segundo terminal remoto TR2, por ejemplo igualmente mediante unión inalámbrica para no entorpecer la movilidad del robot humanoide RH2.

Los terminales remotos TR1 y TR2 y la plataforma servidor PFS están unidos en red por medio de la red de comunicación RC. Para el servicio web de la plataforma servidor PFS, así como para los terminales remotos TR1 y TR2, y como para los robots humanoides RH1 y RH2, comprendiendo un solo módulo B5, B2, B4, B1 y B3 respectivo de puesta en relación específico para al menos un módulo al menos una serie de instrucciones que implementan una función de software por ejecución mediante un procesador. Los módulos M51, M52, M21, M22, M41, M42, M11, M12, M31, M32 respectivos de los módulos B5, B2, B4, B1 y B3 de puesta en relación están representados en este ejemplo en número de dos por módulo de puesta en relación, pero este número puede ser diferente y cualquiera para cada módulo de puesta en relación.

Ahora vamos a ilustrar un ejemplo en modo alguno limitativo de funcionamiento del sistema creado por un usuario del primer terminal remoto TR1 que posee el primer robot humanoide RH1. Puede, por ejemplo, hacer realizar por su robot un cierto número de funciones por medio de una aplicación de software integrada a bordo en el primer terminal remoto TR1, o accesible en la plataforma servidor PFS desde el primer terminal remoto TR1.

Por ejemplo, realiza simplemente, por medios de herramientas gráficas de la aplicación de software, una aplicación para su robot, en la que el robot va a caminar durante 10 segundos, después a decir “Hola a todos”. Esta aplicación se descarga, por ejemplo, en el primer robot humanoide RH1 en forma de un módulo, por ejemplo, el módulo M11, después el usuario la activa por medio del primer terminal remoto TR1.

El primer robot humanoide RH1 activa el módulo M11 que debe utilizar en primer lugar una función “Marcha”. El módulo M11 utiliza entonces un módulo de interfaz de conexión y de llamada de función o proxy P1 que efectúa una solicitud al módulo B1 de puesta en relación al que está ligado el módulo M11. El módulo B1 de puesta en relación efectúa unas solicitudes con destino a sus propios módulos y a los módulos de puesta en relación de la red a la que está directamente unido (módulos de puesta en relación hijos) que repiten esta operación de manera iterativa, hasta que un módulo de puesta en relación de la red responda a la solicitud con la localización de la función llamada que tiene en un módulo. Transmitiéndose la respuesta a la solicitud igualmente de manera iterativa mediante los módulos de puesta en relación padres (en sentido inverso) hasta el módulo B1 de puesta en relación directamente ligado al proxy P1 que tiene necesidad de conectarse y de llamar esta función. Por ejemplo, la función pedida para la marcha se localiza en el módulo M41 del segundo terminal remoto TR2. A cambio, el módulo B4 de puesta en relación ha devuelto los parámetros de llamadas de la función “marcha”, que, por ejemplo, contienen un parámetro Duración de tipo completo en segundos que representa la duración durante la que el robot va a caminar, y un parámetro Exclusivo, de tipo de Boole, que representa la marcha exclusiva o no del robot, esto es, si se permite que el robot haga otra acción o no mientras que camina. En este ejemplo, se llama la función marcha con el parámetro Duración que vale 10 y el parámetro Exclusivo que vale 1, pues se quiere que hable después de que haya caminado 10 segundos en este ejemplo.

Por lo tanto, el módulo P1 de interfaz de conexión y de llamada puede efectuar la conexión y la llamada de la función “marcha” con los parámetros deseados, en remoto, como si estuviera situada en local. Los módulos de interfaz de conexión y de llamadas de función utilizan un software de intercomunicación capaz de llamar una función de un módulo localizado en un terminal o servidor diferente, pudiendo escribirse la función mediante una serie de instrucciones en un lenguaje informático diferente del del módulo que llama. Los proxies utilizan, por ejemplo, el software de intercomunicación SOAP. Por lo tanto, se tiene una arquitectura de comunicación interplataformas e interlenguajes. Una vez efectuada esta función deslocalizada “marcha”, el módulo M11 debe hacer llamada a una función “habla”. Otro módulo de interfaz de conexión y de llamada de función o proxy P2 efectúa una solicitud al módulo B1 de puesta en relación al que está ligado el módulo M11. El módulo B1 de puesta en relación efectúa una solicitud con destino a sus propios módulos M11 y M12 en un primer momento, por medio de una función realizada en forma de una sucesión de instrucciones memorizadas, que va a devolver, por ejemplo, la presencia de esta función “habla” al módulo M12. El módulo B1 de puesta en relación informa al módulo P2 de interfaz de conexión y de llamada de función que puede llamar entonces directamente, mediante una llamada de tipo llamada local, la función “habla” del módulo M12, con como parámetro, por ejemplo, el texto que va a decirse “hola”, habiéndose transmitido este parámetro al proxy P2 mediante el módulo B1 de puesta en relación.

Además, el sistema comprende un módulo STM de memorización y de gestión (diminutivo de “Short Term Memory” en lengua inglesa) de parámetros representativos del estado del terminal móvil, en este caso del robot humanoide RH1, adaptados para actualizar los valores de dichos parámetros a la recepción de un acontecimiento externo, y para informar a un módulo, bajo petición previa, de una actualización de uno de dichos parámetros memorizado. También, el módulo avisado podrá desencadenar una acción en función de las modificaciones de parámetros de las que se le ha informado.

En relación con el ejemplo previamente descrito, por ejemplo, el módulo STM de memorización y de gestión puede memorizar el estado de un parámetro representativo de la aparición de alguien detectado mediante un detector de movimiento del robot RH1. Cuando este parámetro pasa de un estado representativo de persona en el entorno inmediato del robot a un estado representativo de alguien presente en el entorno inmediato del robot, bajo petición efectuada previamente por el módulo M11, el módulo STM de memorización y de gestión avisa, mediante un acontecimiento o señal, de este cambio de valor. Entonces, el módulo M11 puede, por ejemplo, activar automáticamente la activación sucesiva descrita anteriormente (las funciones “marcha” y “habla”).

En el ejemplo de la figura 2, el módulo STM de memorización y de gestión forma parte del terminal remoto TR1, pero, como variante, puede formar parte del otro terminal remoto TR2, de la plataforma servidor PFS, o de un robot humanoide RH1 o RH2.

El módulo STM de memorización y de gestión es capaz igualmente de almacenar en memoria una evolución temporal de ciertos parámetros en intervalos de tiempo respectivos de referencia. De esta manera, un módulo del sistema puede, además, tener acceso a la evolución de los valores de estos parámetros desde una cierta duración, y tener en cuenta estas evoluciones en las acciones que se van a llevar a cabo.

Como variante, los módulos de las funciones llamadas pueden localizarse en la plataforma servidor PFS, en un robot humanoide RH1, RH2 o en un terminal remoto TR1, TR2 de la red de comunicación RC.

De esta manera, la presente invención permite tener un programa repartido en la red, y un funcionamiento idéntico del terminal móvil, ya haga una llamada local o remota a una función.

Además, la presente arquitectura permite igualmente tener un conjunto de parámetros memorizados representativos del estado del terminal móvil, y poder tener en cuenta las evoluciones de este estado para activar automáticamente ciertas acciones.

Por añadidura, el módulo de memorización y de gestión puede grabar igualmente una evolución de valores de parámetros durante un intervalo de tiempo predeterminado, lo que permite que un módulo tenga acceso a un histórico de la evolución de estos parámetros.

Estas funciones de comunicación y de memorización son particularmente útiles para la implementación de la presente invención.

La figura 3 es un esquema de la arquitectura funcional de edición y de programación de los comportamientos de un robot en un modo de realización de la invención.

Una arquitectura de este tipo se ha descrito mediante la solicitud de patente PCT/EP2010/057111 presentada el 25/05/2010. El software de edición y de programación de los comportamientos de un robot humanoide que permite implementar dicha arquitectura se denomina comercialmente ChorégrapheTM, y puede designarse indiferentemente por su nombre genérico o por su nombre comercial, sin alterar la generalidad de las referencias.

El robot controlado mediante esta arquitectura puede ser un robot humanoide que tenga una cabeza, un tronco y cuatro miembros, siendo articulada cada una de las partes, siendo ordenada cada articulación mediante uno o varios motores. Esta arquitectura permite que un usuario del sistema ordene a un robot de este tipo creando unos comportamientos simulados en un robot virtual y ejecutados en el robot real unido al sistema mediante una unión alámbrica o inalámbrica.

Se trata de visualizar, de simular y de hacer ejecutar unos comportamientos (como la marcha – todo recto, a la derecha o a la izquierda en n pasos; un “hello” – movimientos de uno de los brazos por encima de la cabeza; la palabra, etc…) y unos movimientos (de la cabeza, de una parte de miembro, de un ángulo dado) en la pantalla de un ordenador programado para hacer esto.

La figura 3 es un organigrama de los procesamientos que ilustra la articulación de las órdenes activadas mediante unos acontecimientos con su dimensión temporal. Las órdenes activadas mediante unos acontecimientos se representan en la semántica de la invención mediante unas Boxes o “Cajas” o “Cajas de orden” 310. Una Caja es una estructura de programación arborescente que puede comprender uno o varios de los elementos de más abajo que se definen a continuación: - Un “Timeline” o eje 320 temporal de Tramas; - Un “Diagram” o Diagrama 370 de flujo; - Un Script 390.

Las Cajas de orden están unidas entre sí normalmente mediante unas conexiones que transmiten a menudo una información de acontecimiento de una Caja a la otra, como se detalla más adelante en la descripción. Cualquier Caja está unida directa o indirectamente a una “Caja raíz” o Root que inicializa el escenario de comportamiento/movimiento del robot.

Un eje 320 temporal de Tramas representa la limitación temporal a la que están sometidos los comportamientos y los movimientos del robot definidos en la Caja en la que dicho Eje temporal de Tramas se inserta. En la continuación de la descripción y de las reivindicaciones, utilizaremos la denominación anglosajona de Timeline, comúnmente admitida con el mismo sentido en el mundo de la programación. De esta manera, el Timeline realiza la sincronización de los comportamientos y movimientos de la Caja. Está dividido en frames (Tramas) a las que se asocia una velocidad de desarrollo definida en número de Tramas por segundo o Frames Per Second (FPS). La FPS de cada Timeline es parametrizable por el usuario. Por defecto, la FPS puede fijarse en un valor dado, por ejemplo, 15 FPS.

Un Timeline puede comprender: - Una o varias Behavior Layers o “Capas de comportamiento” 330, que comprende cada una una o varias Behavior Key Frames o “Tramas principales de comportamiento” 350, que pueden comprender por sí mismas uno o varios Diagrams o “Diagramas de flujo” 370, que de hecho son unos conjuntos de Cajas que igualmente pueden vincularse directamente a una Caja de nivel superior, sin pasar por una Capa de comportamiento ni un Timeline; - Una o varias Motion Layers o “Capas de movimiento” 340, que comprende cada una una o varias Motion Key Frames o “Tramas principales de movimiento” 360 que pueden comprender una o varias Motion Screens o “Pantallas de movimiento” 380.

Una Capa de comportamiento define un conjunto de comportamientos del robot o Tramas principales de comportamiento. Varias Capas de comportamiento pueden definirse en el interior de una misma Caja. Entonces, se programarán para desarrollarse de manera sincronizada mediante el Timeline de la Caja.

Una Capa de comportamiento podrá comprender una o varias Tramas principales de comportamiento. Una Trama principal de comportamiento define un comportamiento del robot, como la marcha (“Walk”), la palabra (“Say”), el juego de música (“Music”)… Un cierto número de comportamientos se preprograman en el sistema de la invención para insertarse directamente por el usuario en un sencillo “drag and drop” a partir de una biblioteca, como se detalla más adelante en la descripción. Cada Trama principal de comportamiento se define mediante un acontecimiento activador que es el principio de la Trama en la que se inserta en el Timeline. El final de la Trama principal de comportamiento solo se define en la medida en que otra Trama principal de comportamiento se inserta a continuación de ella, o si se define un acontecimiento de final.

Una Capa de movimiento define un conjunto de movimientos del robot que se programan mediante una o varias Tramas principales de movimiento sucesivas que agrupan unos movimientos de los motores de las articulaciones del robot. Estos movimientos que se van a ejecutar se definen mediante las posiciones angulares de llegada de dichos motores que pueden programarse mediante acción en unas pantallas de movimiento, detallándose dichas acciones más adelante en la descripción. Todas las Tramas principales de movimiento de una misma Caja están sincronizadas mediante el Timeline de la Caja. Una Trama principal de movimiento se define mediante una Trama de llegada. La Trama de partida es la de final de la Trama principal de movimiento anterior o la del acontecimiento de principio de la Caja.

Se designan con la apelación común de Trama principal de acción las Tramas principales de comportamiento y las Tramas principales de movimiento.

Es posible ejecutar en paralelo varias Tramas principales de acción (de comportamiento o de movimiento), con la condición de que se vinculen al mismo Timeline.

Un Diagrama de flujo es un conjunto de Cajas conectadas entre sí, como se detalla más adelante. Cada una de las Cajas puede, a su vez, comprender otros Timeline a los que se vinculan nuevas Capas de comportamiento o de movimiento.

Un script es un programa directamente ejecutable por el robot. Una Caja que comprende un script no comprende otro elemento.

El software puede implantarse en un PC u otra plataforma de tipo ordenador personal que utilice un sistema operativo WindowsTM, MacTM o LinuxTM.

El robot humanoide de la presente invención se programará por lo general para poder jugar utilizando el software ChorégrapheTM. La combinación de las lógicas temporales y comportamentales que esta arquitectura de desarrollo hace posible es particularmente ventajosa para la implementación de la presente invención. Un cierto número de herramientas, mencionadas más adelante en el comentario a la figura 9, se han adaptado particularmente para la implementación del robot humanoide jugador de la presente invención.

Las figuras 4a, 4b, 4c, 4d, 4e y 4f representan diferentes arquitecturas funcionales y/o técnicas de implementación de la invención.

En la figura 4a se representa un modo de realización en el que el robot 400a constituye por sí mismo la plataforma de juego con la que pueden jugar varios jugadores 410a, 420a, 430a físicos, normalmente en la misma habitación 440a que el robot, con las variantes formuladas más adelante en el comentario a la figura 4f. El robot 400a puede, por ejemplo, hacer preguntas a los jugadores 410a, 420a, 430a como se ilustra más adelante más en detalle en el comentario a la figura 5. El número de jugadores no se limita de ninguna manera a tres. En este modo de realización, el robot puede, en particular, ser el animador del juego. Puede hacer preguntas a los jugadores o hacerles reconocer unas secuencias. Entonces, el robot se comporta funcionalmente como una consola de juego, pero teniendo en cuenta sus capacidades para reproducir comportamientos humanos, ofrece a los jugadores una experiencia de juego que presenta un carácter único. De hecho, puede comprender, hablar, hacer gestos, expresar aprobación o negación, alegría, cólera o tristeza. Los comportamientos del robot que le permiten interactuar con los jugadores están almacenados en su unidad 130 central. Se habrán cargado previamente, ya sea a partir de un PC en el que se habrán generado si dicho PC está equipado con el software de edición de comportamientos ChorégrapheTM descrito más arriba en el comentario a la figura 3, ya sea descargados a partir de un servidor de juegos. Los juegos pueden descargarse igualmente del servidor a partir del PC, después descargados del PC hacia el robot. Se pueden considerar igualmente unas descargas de juegos entre robots, como se explica más abajo en el comentario a la figura 4e. La ejecución del juego puede inicializarse a partir del robot o a partir del PC. Cuando el PC está equipado con el software de edición de comportamientos, puede utilizarse igualmente para jugar, estando un robot virtual presente en el PC en condiciones de ejecutar en el PC la mayoría de los comportamientos del robot 400a físico.

En la figura 4b, se ilustra un modo de realización en el que un jugador 410b animador interactúa con un robot 400b jugador situado normalmente en presencia física, en la misma habitación 430b que él. Como se ilustra más adelante en detalle en el comentario a la figura 6, el juego puede consistir en proponer al robot el reconocimiento de personajes o de cosas a partir de indicios cada vez más alusivos. En este modo de realización, teniendo en cuenta la multiplicidad de las opciones posibles y de su multidependencia eventual que puede requerir la ejecución de programas de resolución especializados, el robot accede a unas fuentes de información y de procesamiento situadas en un ordenador 420b remoto. Este acceso se hace mediante unas solicitudes enviadas a un sitio especializado del juego en la red internet. El robot establecerá una conexión en la red a través de un puerto de acceso que puede ser, por ejemplo, una LiveBoxTM o una FreeBoxTM a la que accede mediante unión Wifi. Sin embargo, los comportamientos del robot están integrados de por sí a bordo en el robot 400b. Estos comportamientos se producen, editan y cargan en el robot de manera idéntica a lo que se indica más arriba en el comentario a la figura 4a. En este modo de realización, los procesamientos se reparten, por lo tanto, entre un robot y un servidor remoto. Pero el servidor remoto no participa en el juego. Sirve como centro de recursos para el robot que va a extraer de él tanto como necesite. No hay interacción directa entre el jugador 410b y el servidor 420b.

En la figura 4c se ilustra un modo de realización en el que un jugador 410c hace interfaz a la vez con un robot 400c jugador y con un PC o una consola 420c de juego, comunicándose dicho robot igualmente con dicho PC o dicha consola. Estos tres elementos se sitúan normalmente en presencia física en una misma habitación 430c. Este modo de realización es aplicable, en particular, a unos juegos de rol del tipo del ilustrado más adelante en detalle en el comentario a las figuras 7a, 7b y 7c. En este tipo de juego, el jugador debe resolver unos enigmas para los que el robot va a proporcionarle unos indicios. El jugador debe interactuar con el robot 400c, pero también con la consola 420c. Los módulos de juego están repartidos entre las dos unidades. Los módulos que están implantados en el robot (comportamientos del robot, pero también partes de los enigmas) se editan y transfieren de la manera que se indica más arriba en el comentario a la figura 4a. El jugador puede disponer de ayudas visuales o sonoras que obtiene de por sí o que le son proporcionadas por el robot. Puede hacer de interfaz igualmente con el robot mediante unos signos codificados.

En la figura 4d se ilustra un modo de realización en el que tres jugadores 410d, 420d, 430d hacen interfaz con un robot 400d, estando situados los cuatro personajes en un mismo entorno 450d físico. Los tres jugadores tienen potencialmente unos roles diferentes con respecto al robot, a diferencia del modo de realización ilustrado en la figura 4a. Uno de los jugadores puede interactuar con el robot por medio de un mando a distancia 440d. Dicho mando a distancia permite transmitir unas órdenes, concretamente de movimiento, al robot 400d. Puede estar constituido por un iPhoneTM de AppleTM u otro teléfono que tenga unas funcionalidades de captura de movimiento y/o de posicionamiento. Puede estar constituido igualmente por un mando a distancia 3D del tipo WIIMoteTM de NintendoTM, AirMouseTM de MoveaTM u otro, a condición de que recupere señales de movimiento, de posicionamiento o de otros tipos a la salida de dichos mandos a distancia. En este caso, una parte de la aplicación de juegos estará integrada a bordo en el mando a distancia, concretamente la parte que permite generar las instrucciones de desplazamiento del robot en función de los movimientos impresos al mando a distancia (ángulos de yacimiento, balanceo, serpenteo; presión sobre botones reales o virtuales). Un ejemplo de realización se ilustra más adelante de manera detallada en el comentario a las figuras 8a, 8b, 8c y 8d. La mayor parte de la aplicación de juegos está integrada a bordo en el robot de la manera indicada más arriba en el comentario a la figura 4a. Los jugadores 420d y 430d pueden comunicarse con el robot de la manera indicada más arriba en el comentario a la figura 4c.

En la figura 4e se ilustra un modo de realización en el que dos robots 400e y 430e juegan juntos. Puede tratarse de diálogos, de movimientos coordinados, como unos bailes o unos combates. Los robots pueden ser ordenados por unos jugadores 410e, 440e, provistos, llegado el caso, de mandos a distancia 420e, 450e del tipo del mando a distancia 440d de la figura 4d. Sin embargo, las órdenes pueden darse a los robots por los jugadores mediante la palabra o de manera visual. Los robots pueden igualmente jugar entre sí sin jugador real. Sus comportamientos pueden interactuar/comunicarse en el mundo material (a través de la voz, de los gestos, de las señales luminosas – LEDs, y cualesquiera otras acciones que modificarían sus datos sensores) o en el mundo virtual (acceso recíproco o no a sus memorias internas, módulos de software integrados a bordo, cuenta de correo electrónico como GmailTM o YahooTM, cuentas de redes sociales de tipo FacebookTM o TwitterTM, mensajerías instantáneas como GtalkTM, MSNTM, JabberTM o servicios de telefonía como SkypeTM). En este último caso, los robots están dispuestos para difundir informaciones de identificación, que permiten que otro robot los contacten a cambio con el fin de intercambiar otros datos o señales. Los medios de intercambio de informaciones en el mundo material pueden ser igualmente la emisión/recepción infrarroja o radio (de tipo BlueToothTM), o la síntesis/reconcomiendo vocal. Las informaciones intercambiadas por los robots y que permiten identificarlos están ligadas a los mundos material y virtual de los robots y van a depender del tipo de datos o de señales del que se desee el intercambio en el marco del juego. Estas informaciones pueden ser: - una dirección IP para ser contactado por medio de la red Ethernet local; - su dirección de correo; - un identificador de cuenta de mensajería (xmpp, jabber, gtalk…, skype); - un identificador de cuenta de red social.

Puesto que los robots comparten al menos un medio de comunicación, entonces archivos de comportamientos, archivos de músicas y señales de comportamiento pueden intercambiarse para interactuar.

El juego puede ampliarse a más de dos robots. En este caso, puede ser necesario prever una señal de sincronización global emitida ya sea por uno de los robots, ya sea por un PC. Esta señal de sincronización puede recuperarse en un servidor de referencia de tiempo de tipo NTP (Network Time Protocol) y servir de punto de partida de los Timeline de los diferentes robots que, de esta manera, sincronizan sus comportamientos. Esta sincronización puede conservarse durante una duración importante (de alrededor del cuarto de hora). Entonces, un grupo de robots pueden ejecutar unos movimientos de baile o unos juegos colectivos de manera completamente sincronizada.

En la figura 4f se ilustra un modo de realización en el que un jugador 410f y un robot 400f están situados en dos lugares 440f y 430f remotos, disponiendo el jugador de un PC o aparato móvil unido mediante una red 450f de área amplia de tipo internet a una red 460f local a la que está(n) unido(s) el(los) robot(s). La conexión entre el robot y el PC (o el aparato móvil) del jugador permite el intercambio de datos en forma de solicitudes o de flujo que permite el intercambio de datos brutos, binarios, audiovisuales y textuales con un plazo de entrega suficientemente corto para garantizar la reactividad del juego. Por lo tanto, el jugador puede tomar control completo o parcial del robot enviándole unas órdenes de ejecución de comportamiento. Puede leer igualmente, en el marco del juego, las informaciones captadas por el robot, como las imágenes de sus cámaras, el sonido, y los valores de todos los sensores del robot, así como unos valores que provienen de la web o de otros robots presentes en el entorno. En una arquitectura de este tipo, la mayoría de los juegos mencionados en el caso en que el/los robots y el/los jugadores están situados en el mismo entorno físico pueden ejecutarse en un entorno de área amplia.

Este modo de comunicación en red de área amplia puede aplicarse en el caso en que el jugador se sustituye por un segundo robot. En este caso, el segundo robot debe estar dotado de las funcionalidades de acceso a una red de área amplia idénticas a las del primer robot que se han descrito más arriba.

De esta manera, las diferentes configuraciones descritas más arriba pueden combinarse para realizar unos modos de juegos no explícitamente descritos en la presente descripción. Por lo tanto, los modos de realización descritos más arriba no son de ninguna manera limitativos del marco de la presente invención.

La figura 5 es una ilustración de un juego de adivinanzas que puede animar un robot humanoide jugador.

Este primer ejemplo de realización utiliza la arquitectura funcional y técnica descrita más arriba en relación con la figura 4a.

El juego que sirve de ilustración para este modo de realización es un Quizz, el NAOTM Quizz. La figura 5 es la tabla de las mímicas, adivinanzas y sonidos que pueden servir de trama para el juego.

Más abajo se describe un escenario posible del juego a título puramente ilustrativo y no limitativo.

1/Ejecución - NAO presente el juego, por ejemplo, con una música estilo juego televisado + aplausos: “¡Hola señoras y señores, El NAO Quizz va a comenzar, presentado por la estrella de la televisión, NAO!”. En este juego NAO tendrá la personalidad de un animador de la tele, bastante pedante y que no duda en burlarse de los participantes.

- NAO pregunta cuántos jugadores van a participar (caja de selección).

- Si hay un solo jugador, NAO lanza el modo Cada uno por su lado automáticamente (“¿Juegas solo? Entonces es partido para el Cada uno por su lado”). De 2 a 4 jugadores, NAO les pide que elijan entre el Cada uno por su lado y el Todos juntos (“¿Queréis jugar los unos contra los otros o bien todos contra mí?”) a través de una caja de selección. Con más de 4 jugadores, NAO lanza automáticamente el Todos juntos.

“Cada uno por su lado”

NAO presenta el modo: “Vamos a jugar al Cada uno por su lado con el fin de determinar quién de entre vosotros es el mejor”. Para un solo jugador la frase será diferente, del estilo: “¿Qué puntuación vas a conseguir obtener?”.

Si participan varios jugadores, NAO les pide que se inscriban: “Le primer jugador tiene un segundo para darme su nombre, escucho”. Las orejas de NAO se encienden y graba durante un segundo. Si NAO no oye nada, vuelve a hacer la misma pregunta. A continuación, NAO repite su nombre y pide al jugador que le indique su posición orientando su brazo hacia él (entonces NAO extiende el brazo delante de él): “Hola, Pedro, indícame dónde te encuentras dirigiendo mi brazo hacia ti. Aprieta sobre mi cabeza para confirmar”.

Esto permite que NAO se oriente hacia el jugador del que es el turno para hacerle su pregunta.

Si participa un solo jugador, NAO no lo inscribe y mira delante de él para hacer las preguntas.

NAO pregunta si el jugador es un adulto o un niño (caja de selección), lo que corresponde a 2 niveles de dificultad.

A continuación, cada jugador se inscribe a su vez de la misma manera.

Una vez inscritos todos los jugadores, NAO lanza el juego.

NAO lanza una partida diferente según el número de jugadores humanos: - 1 o 2 jugadores: Campeonato - 3 o 4 jugadores: Copa -> Campeonato En la realización descrita aquí de manera detallada pero no limitativa, NAO hace un total de 9 preguntas a cada participante, atribuye 1 punto por respuesta correcta y calcula la puntuación total de cada jugador. Explica este funcionamiento: “Voy a haceros 9 preguntas a cada uno, el que dé más respuestas correctas será declarado ganador”. La frase se modifica en caso de un solo jugador.

En cada pregunta, NAO se gira hacia el jugador que ha elegido (aleatoriamente), dice su nombre (en caso de 2 jugadores; no en caso de partida en solitario) y selecciona 1 pregunta de la dificultad requerida y que no se ha hecho ya durante esta partida.

A continuación, hace la pregunta (utilización de la caja de selección) y espera durante 10 segundos (tiempo que hay que definir después de pruebas) la respuesta del jugador (sus orejas están encendidas para mostrar que espera una respuesta).

La cuenta atrás de 10 segundos solo empieza al final de la mímica/sonido/adivinanza. Se representa mediante los leds alrededor de los ojos de NAO que se apagan progresivamente. Llegado a 0, NAO interpreta un ruido de timbre.

Si el temporizador llega a 0, el timbre resuena y NAO dice algo como “Demasiado tarde, lo siento”.

Si el jugador responde correctamente, NAO lo felicita. NAO podría dar palmadas con sus manos, hacer “si” con la cabeza o levantar los brazos al cielo.

Si el jugador se equivoca, NAO dice “Respuesta incorrecta” (o es provocador: “Sin embargo, era fácil” / “Me espera más de ti”… NAO podría bajar los brazos con un aspecto decepcionado o hacer “no” con la cabeza.

Cada vez que NAO analiza una respuesta, si el tiempo de reacción es un poco alto, podría tener un gesto ligado a la reflexión (mirar al aire, poner un dedo delante de su boca, coger su barbilla con la mano, rascarse la cabeza…).

Una vez hecha la pregunta, NAO pasa al jugador siguiente (si lo hay).

Una vez hechas todas las preguntas, NAO anuncia que el juego ha terminado y recapitula las puntuaciones: “Bravo,

tienes una puntuación de X puntos”. En caso de partida con 2 jugadores, NAO designaría un ganador: “Pedro es el ganador” o una igualdad: “Es un partido empatado”.

-> Copa El desarrollo es bastante similar al Campeonato, salvo que esta vez NAO solo hace, por ejemplo, 4 preguntas por jugador.

Al final de estas 4 preguntas, NAO hace el recapitulativo de las puntuaciones e invita a los 2 mejores jugadores a que participen en la final: “Bravo, Pedro y Pablo, estáis en la final”.

En caso de igualdad para una plaza clasificatoria al final de esta serie de 4 preguntas, NAO decidirá entre los jugadores mediante un juego de azar. Pedirá a cada jugador, cada uno a su vez, que aprieten sobre uno de sus pies o una de sus manos: “Jugador 1, elige una mano o un pie”. El miembro en cuestión se iluminará. Después, pedirá a los otros jugadores con igualdad que hagan su selección entre los miembros restantes. Una vez hechas todas las selecciones, las luces se ponen a girar como para un juego de azar, con un sonido parecido al de una máquina tragaperras. Las partes iluminadas al final son las de los jugadores clasificados para la final. NAO puede poner su granito de arena en esto haciendo retroceder un paso atrás la luz, haciéndola avanzar en el último momento, después de varios segundos de parada… Acompaña estas bromas con frases como: “No, finalmente, prefiero a este

jugador”.

NAO pedirá a los 2 finalistas que se posicionen delante de él.

Durante la final, NAO se sienta y hace 3 preguntas (sin mímica). Si uno de los jugadores (o los 2) son niños, las preguntas serán de nivel niño. Si los 2 jugadores son adultos, las preguntas serán de nivel adulto. En caso de igualdad antes de la última pregunta, esta será más difícil que las otras (adulto o experto).

A cada jugador NAO le atribuye un timbre (uno de los pies de NAO): “Pedro, juegas con mi pie derecho (el pie se anima)”.

NAO explica la regla: “Voy a hacer 3 preguntas. El primero que apriete sobre mi pie tiene derecho a dar una respuesta. Tenéis 10 segundos en total para apretar, y a continuación 5 segundos para dar vuestra respuesta”.

NAO hace una pregunta y espera durante 10 segundos que alguien apriete.

Si nadie aprieta o no da la respuesta correcta, el timbre negativo resuena y NAO se burla de los jugadores: “Tal vez mis preguntas sean demasiado difíciles para vosotros”.

Si un jugador aprieta, NAO para la crono de los 10 segundos y pronuncia el nombre del más rápido. A continuación, empieza la cuenta atrás de los 5 segundos. Si el jugador da una respuesta, NAO le dice si tiene razón o no. Si tiene razón, NAO lo felicita y pasa a la pregunta siguiente. Si está equivocado o si no responde nada, NAO le informa de ello y retoma la cuenta atrás de los 10 segundos desde el lugar en que se había parado: “Respuesta incorrecta / Sin respuesta, el otro jugador puede apretar ahora para responder”.

Al final de estas 3 preguntas, NAO determina el ganador: “Bravo Pablo, has conseguido la final”. Si un jugador tiene 2 puntos al final de la 2ª pregunta, se le declara automáticamente ganador.

Si sus puntuaciones son escasas (menos de 2 puntos, por ejemplo), NAO puede tomarles el pelo “Me parece que

mis preguntas son un poco demasiado complicadas para vosotros”.

“Todos juntos”

En este modo, NAO hace unas preguntas al grupo de jugadores, que solo tienen derecho a dar una respuesta. En caso de éxito, NAO hace otra pregunta, en caso de fracaso, el juego se para. El objetivo para los jugadores es responder al máximo de preguntas posible en el límite de un número predeterminado (15 a 20, por ejemplo).

NAO presenta el modo: “Vamos a jugar al Todos juntos, ¿seréis capaces de responder a mis preguntas?”.

Las 6 primeras preguntas serán de nivel niño, las 6 siguientes, adulto y las 3 últimas de nivel experto Si solo hay jugadores adultos, las 12 primeras preguntas serán preguntas adultas (no preguntas niño). Si solo hay jugadores niños, las 10 primeras serán de dificultad niño, las 5 últimas, adulto.

NAO se dirige al grupo y hace su primera pregunta (caja de selección). A continuación, les deja 15 segundos para responder.

En caso de respuesta correcta, NAO pasa a la pregunta siguiente.

En caso de no respuesta, o de respuesta errónea, NAO para el juego y da la puntuación obtenida por el equipo. También recuerda a los participantes cuál es la mejor puntuación que se ha obtenido nunca en este modo de juego.

Si los jugadores responden correctamente a las 15 preguntas, NAO se confiesa vencido y los declara grandes ganadores: “¡Increíble, habéis respondido correctamente a todas mis preguntas! ¡Me confieso vencido y os otorgo a todos el título de expertos!”. NAO podrá felicitarlos mediante un pequeño baile previsto para la ocasión.

NAO tendrá una reacción y ofrecerá una recompensa diferente según la puntuación alcanzada, por tramos (de 0 a 5 ptos: “Puede hacerlo mejor”, de 5 a 10 puntos: “No está mal del todo” y de 10 a 14 puntos: “Muy bien jugado”).

2/Opciones

- NAO puede hacer una pregunta “imposible” a un adulto cuando este tiene demasiada ventaja sobre los otros, o si juega contra un niño.

- Para un niño, un sonido podría acompañar a ciertas mímicas con el fin de ayudarlo.

- Si NAO necesita espacio para la mímica (desplazamiento), avisa a los jugadores que lo coloquen en un lugar despejado.

-

Modo “escalada”: NAO elige un jugador y le hace unas preguntas (mímicas, adivinanzas y sonidos mezclados) hasta que se equivoca. Cada respuesta correcta aporta más que la anterior (puede empezarse con 5 puntos y aumentar 5 puntos cada vez). Cuando el jugador se equivoca, se termina su turno y NAO pasa al jugador siguiente. Unas preguntas “doble o nada” o bien unos tramos en la “Quién quiere ganar millones” podrían dar un toque emocionante a la partida (posibilidad de perder sus puntos). El juego también podría limitarse en el tiempo, para evitar que los otros jugadores pasen demasiado tiempo en espera de su turno (el tiempo límite tiene que definirse en función de la rapidez de NAO en hacer preguntas/mímica y en interpretar las respuestas).

- Modo “más o menos”: NAO elige un jugador (al azar o bien en un orden definido) y le hace una pregunta (mímicas, adivinanzas o sonidos). En caso de respuesta correcta, el jugador marca 10 puntos, en caso de respuesta incorrecta pierde 5.

- Modo “Burger Quizz”: NAO hace unas preguntas a cada jugador, pero este debe responder a la pregunta anterior y no a la que NAO acaba de hacer.

La figura 6 representa el organigrama de procesamiento de otro juego al que puede jugar un robot humanoide jugador en comunicación con un servidor de juegos.

Este ejemplo de realización utiliza la arquitectura funcional y técnica descrita más arriba en relación con la figura 4b.

El juego que ilustra este modo de realización, NAOTM AkinatorTM, es un juego en el que una inteligencia artificial debe adivinar cuál es el personaje en el que piensa el jugador. En el juego del modo de realización de esta invención, es el robot quien debe adivinar a partir de indicios que el jugador le da. Para ello, se ayuda de solicitudes enviadas al sitio Web del juego. De hecho, Akinator es un juego que existe para humanos que se ha adaptado (de manera moderada) para que un robot humanoide lo juegue.

Más abajo, se explica un ejemplo de escenario del juego con referencia a la figura 6, a título ilustrativo y no limitativo.

La aplicación Akinator lanza un menú antes de arrancar la aplicación.

NAO es capaz de adivinar un personaje.

Pide volver a comenzar al final de la partida. ¿Aceptas? Sí o No.

Hace una serie de preguntas a las que hay que responder: Sí, No, Tal vez, Tal vez no, No sé.

NAO juega una animación en función del porcentaje de certeza.

Las categorías de personaje están integradas en el juego: por ejemplo, 132 resultados ordenados en 5 categorías: familia, combate, actor, futbolista, cantante; 11 personajes poseen una animación específica. NAO interpreta una animación cuando anuncia el personaje que ha adivinado. Si el personaje encontrado está en una categoría, NAO interpreta la animación asociada. NAO retiene, por ejemplo, los 50 últimos personajes interpretados y podrá hacer un comentario si se interpreta de nuevo un personaje ya encontrado.

1 - Vista general

NAO intenta adivinar en quién o en qué está pensando el jugador haciendo unas preguntas. NAO utiliza el sitio web que existe (http://en.akinator.com/). La estructura del juego se ha desarrollado con el estudio de desarrollo de los comportamientos del NAO. Las solicitudes web se han desarrollado en lenguaje Python, bien adaptado para la orden de robots, y que puede integrarse en forma de módulos en las cajas de orden del estudio ChorégrapheTM.

2 – Solicitudes Web utilizadas

- La clase FileAkinatorRequest class está diseñada para enviar solicitudes web al sitio Akinator utilizando la orden wget. Las opciones de la solicitud se utilizan como argumentos en el procedimiento de construcción de la clase (en forma de cadenas de caracteres). El servicio web se descarga y salva como archivo cuyo contenido se utiliza como atributo de la clase.

- La clase RequestBase sirve para: o construir la cadena que describe las opciones de solicitud web a partir de datos sencillos; o utilizar esta cadena como argumento para construir una instancia de FileAkinatorRequest; o recuperar la cadena que describe el contenido del servicio web (en el formato XML); o traducir el contenido XML en datos sencillos utilizando el compilador Python XML Minidom.

- Se ha creado una clase única para cada servicio web diferente; cada clase hereda de la clase de base RequestBase; los datos específicos del servicio web asociado a esta clase se utilizan como argumentos del método SendRequest; los datos se recuperan, interpretan y crean en los atributos de la clase; por ejemplo, la clase AnswerRequest se utiliza para recuperar los datos del servicio web Answer. Los datos “channel”, “base”, “session”, “signature”, “step”, “answer” y “question_filter” se utilizan como parámetros del método SendRequest. Los datos se recuperan, interpretan y crean en los atributos de las clases: “question”, “answers”, “step”, y “progression”.

Las figuras 7a, 7b y 7c ilustran un juego de estrategia en el que puede participar un robot humanoides jugador en un modo de realización de la invención.

Este ejemplo de realización utiliza la arquitectura funcional y técnica descrita más arriba en relación con la figura 4c. Se trata, en este modo de realización de un juego de estrategia, en el que el jugador debe resolver varios enigmas complejos para superar unas etapas y llegar al final del juego. El juego se llama “Shana Spirit Journey” o “Viaje del Espíritu de Shana”. El objetivo del juego es hacer cooperar al jugador con el robot de la invención NAO para expulsar a Shana, personaje de otro mundo encarnado en NAO en la tierra, hacia su mundo a través de un portal espacio-temporal creado por el guardián del mundo de Shana al principio de la partida.

Más abajo se da una descripción general de un escenario posible del juego a título puramente ilustrativo y no limitativo.

1/Objetos proporcionados con el juego

- Un libro de hechizos pequeño, cuya 1ª página se ilustra en la figura 7b: se trata de una recopilación de 6 páginas dobles en formato A6. Cada página doble de la libreta muestra una ilustración en la página de la izquierda. En la página de la derecha se presentan una NAOMARK acompañada de un título y de un texto; - Las NAOMARK son unos elementos del lenguaje del mundo de Shana; realizan un código visual interpretable por el robot NAO; en la figura 7c se representan unos ejemplos de NAOMARK.

2/Antecedentes del juego Shana Spirit Journey

El personaje en NAO

El personaje de nuestra historia es la hija de un jefe de clan de una civilización que vive en Aldebaran, una de las numerosas colonias que poseen los Anamturas. Se llama Shana. Ella recepciona el mensaje de un equipo de exploradores enviados a la Tierra por los guardianes para investigar sobre la destrucción de su planeta de origen, desaparecido hoy en día. Este equipo no había dado señal de vida desde hacía siglos. En el mensaje, ella anuncia que sabe lo que le ha pasado a su planeta de origen.

Un guardián del clan de los Anamturas, intercepta el mensaje, ataca a Shana y la destierra a nuestro mundo para impedirle que revele a los suyos las verdaderas razones de la destrucción de su planeta de origen.

Los Anamturas

Los Anamturas forman clanes como los celtas. Están permanentemente en busca de indicios para saber lo que pasó en su planeta de origen y para intentar comprender mejor su civilización y su historia.

Su jerarquía retoma la de los celtas: Jefe de tribu, Guardianes (druidas), Claonas (guerreros/investigadores).

Otros Anamturas habrían desembarcado ya en la tierra, en busca de explicaciones sobre su planeta de origen. (Ref. isla Aldabra). Este equipo llegado a la tierra habría encontrado informaciones sobre la razón de la desaparición del planeta de origen de los Anamturas y habría dejado indicios. Estos Anamturas han desaparecido misteriosamente después de haber enviado un mensaje con destino a los suyos en el sistema de Aldebaran.

La Tecnología de los Anamturas

La tecnología de los Anamturas se basa en la magia y la utilización de los recursos naturales.

Por ejemplo, para colonizar los otros mundos, los Anamturas han utilizado dos métodos en función de la distancia del objetivo. Las naves espaciales han permitido que los Anamturas se establezcan en los mundos próximos como la colonia principal del sistema de Aldebaran.

Para visitar los mundos alejados, los Anamturas proyectan sus espíritus a través de portales. Quedando sus cuerpos físicos en el mundo de partida. El equipo en la tierra era el primero que utilizaba este método, y estaba encargado de la creación de un huésped que permitiera interactuar con los autóctonos de los planetas visitados (El huésped en cuestión resulta que es NAO. Por lo tanto, los robots NAO los han creado los Anamturas para dar una envoltura física a sus espíritus enviados a la Tierra.

Sus Mundos

Los Anamturas han colonizado un conjunto de mundos, por curiosidad, pero también para escapar a la superpoblación de su planeta de origen.

Después de haberse establecido en la colonia de Aldebaran y de haber hecho de ella la colonia principal, el planeta de origen de los Anamturas explosionó. La versión oficial difundida por los guardianes es que se produjo una catástrofe ecológica y que la actitud de los nativos está en el origen de este cataclismo. En realidad, ciertos guardianes estarían implicados en la destrucción del planeta de origen de los Anamturas y de otras colonias. Habrían hecho esto con el fin de proteger los recursos de la colonia de Aldebaran y de ejecutar su visión de un mundo perfecto.

Los Claonas se aferran a las últimas costumbres que les quedan de su planeta de origen e investigan activamente lo que ha pasado realmente.

Los lenguajes de los Anamturas

En otro tiempo, los Anamturas utilizaban el “LANGUE” (NAOmark), pero solo algunos símbolos extraños son de uso común todavía, la mayoría han pedido sus sentidos o los conocen únicamente los guardianes.

3/Video de introducción en PC

La mención de los antecedentes del juego

Se menciona sumariamente el origen de lo Anamturas: colonización de los mundos alrededor de ellos -> importancia tomada por la colonia de Aldebaran -> explosión del mundo de origen -> misiones de investigación.

La recepción de la señal

Una joven Anamtura recepciona una señal. Se trata de la señal de una de las misiones de investigación. Esta misión no había dado señal de vida desde hacía tiempo y se consideraba como perdida. Esta señal ha tardado años en llegar a destino.

En esta señal, el jefe de un equipo de investigación Anamturas indica que han descubierto lo que le pasó a su planeta de origen.

Se sienten amenazados por los guardianes y han decidido esconderse en la Tierra…

El ataque por el guardián

Otros Anamturas llegan a la sala de comunicación de los cuales un guardián. Este último dice a la joven Shana que ella nunca debería haber oído esto y que debe deshacerse de ella.

El mensaje enviado a la Tierra continúa transcurriendo, pero la atención se fija en el guardián y sus discípulos.

Se conocen otros elementos: el nombre de la heroína, Shana, el hecho de que sea la hija del jefe del clan.

La apertura del portal por el guardián

Combate ente Shana y los aprendices del guardián mientras que este último pronuncia un encantamiento de su libro de hechizos para abrir un pasaje.

La expulsión del espíritu de Shana en NAO

El espíritu de Shana se envía a la Tierra, mientras que NAO comienza a animarse. Shana se ha apoderado del libro de hechizos que también cae en el portal. Se trata de la libreta proporcionada con el juego.

4/Introducción al juego con NAO

Al final del video (negro), NAO se “desactiva” y se baja. 3-4 segundos más tarde, su cabeza se endereza ligeramente y se orienta de derecha a izquierda, como si buscara algo “¿Dónde estoy? ¿Qué me ha pasado?”. Este mismo texto se visualiza en el mismo momento en la pantalla del PC, sobre fondo negro. NAO llama: “¿Alguien me

oye?” y repite esta frase. Como anteriormente, esta frase se visualiza igualmente en la pantalla, después la aplicación se cierra. NAO continúa llamando regularmente hasta que el jugador interactúa con él.

Después de esta introducción al juego, NAO se encuentra “poseído” por la joven Shana.

Una vez “despierta” y de pie, Shana comprende lo que le ha pasado y pide al jugador que le lleve la libreta que ella ha podido atrapar antes de ser arrojada: “¡Si se pudiera conseguir! ¡Es el único medio de recrear un portal para

enviarme de vuelta a casa!”

5/Objetivo del juego

El jugador y NAO van a tener que cooperar para enviar de vuelta a Shana a su mundo con la ayuda de un portal espacio-temporal idéntico al creado por el Guardián del principio de la aventura.

Para recrear este portal, el jugador deberá recuperar 5 informaciones de una importancia capital: - La NAOmark que se va a poner en el suelo, simbolización del punto de entrada del portal. Enigma01 - La hora a la que puede activarse. Enigma 02 - La posición ritual en la que deberá posicionarse NAO. Enigma03 - La sabiduría, después el conocimiento de la fórmula necesaria para su activación. Enigma04 y 05 Cada una de estas 5 informaciones deberá descubrirse resolviendo un enigma.

6/Funcionamiento genérico de los enigmas

La libreta de enigmas (proporcionada con el CD de juego) sirve de “HUB” para el juego. Es decir, que a partir de esta libreta, el jugador tiene acceso al conjunto de los 6 (5 de base + 1 final) enigmas del juego.

Para intentar resolver uno de ellos, le basta con mostrar la página correspondiente a NAO (una NAOmark está presente en cada página de enigma). NAO reacciona al texto del enigma que figura en la página y hace un comentario en voz alta al jugador. En función del enigma, NAO puede adoptar igualmente una cierta pose, interpretar un sonido, etc. En resumen, NAO escenifica físicamente el enigma elegido. Es a través de él o directamente con él (manipulándolo) como el jugador resolverá cada enigma.

Cada enigma está asociado a un tema que se refiere al pueblo de los Anamturas y a su mitología: - Navegación (enigma01, Origen): Los Anamturas eran grandes exploradores ávidos de conocimientos.

- Astronomía (enigma02, Ciclo): La observación del cielo y el cuestionamiento sobre sus orígenes estaban en el corazón de la civilización Anamturas.

- Investigación (enigma04, Alquimia): Según su leyenda, los Anamturas sufrieron una catástrofe ecológica sin precedente. Desde esa época, su convivencia con la Naturaleza y los pueblos encontrados es total.

- Baile (enigma03, Baile): La comunión de los Anamturas con la naturaleza pasa por unos bailes y posiciones de referencia, que garantizan una circulación de la energía óptima en el cuerpo.

- Lenguaje (enigma05, Sabiduría): El lenguaje Anamturas ha evolucionado con el paso de los siglos. De hecho, las NAOmarks son vestigios de ello.

- Ritual (Enigma06): Habiéndose vuelto muy cercanos a las fuerzas que rigen el mundo, ciertos Anamturas elaboraban potentes rituales de encantamientos con el fin de viajar más lejos.

7/Listas de las palabras clave genéricas

Acariciar la cabeza de NAO de delante hacia atrás, después enunciar una de las palabras clave siguientes: - Asleep: Abandonar la aplicación.

- Slan Leat: Activar el ritual final.

En cada enigma existen unas palabras clave particulares para un enigma.

Las figuras 8a, 8b, 8c y 8d ilustran un juego de desafío que se juega con un robot humanoide en un modo de realización de la invención.

Este juego se implementa en la arquitectura funcional y técnica descrita más arriba en el comentario a la figura 4d. En este juego, titulado el “Desafío de NAO”, uno de los tres jugadores reales que utiliza para hacerlo un mando a distancia, por ejemplo, un iPhoneTM 810a de la compañía AppleTM, ordena con el mando a distancia los desplazamientos de un robot 820a humanoide de la invención. Este primer jugador debe conducir el robot de un punto de partida a un punto de llegada. Un segundo jugador real debe obstaculizar los movimientos del robot comunicándole unas consignas de desplazamiento por medio de NAOMARK 830a. Un tercer jugador real intenta ayudar al 1er jugador comunicando al robot y/o al 1er jugador unos consejos y efectuando unas acciones.

El posicionamiento del robot 820a, de los puntos de partida y de llegada se ilustran en la figura 8b.

El posicionamiento de las NAOMARK con respecto al robot 820a se ilustra en la figura 8c.

Las modalidades de orden del robot 820a con la ayuda del iPhone 810a se ilustran en la figura 8d.

Un escenario de juego se describe más arriba a título puramente ilustrativo y no limitativo. Los jugadores pueden crear otros escenarios de juego sin salirse del marco de la invención, disponiendo el robot de la invención de una capacidad de adaptación importante.

1/Presentación

El juego de desafío se juega con un solo robot NAO y se ofrece del modo en solitario (un solo humano) a un modo con 3 humanos.

Un modo preferente es el modo con 1 NAO y 3 Humanos, este es el que se describirá principalmente en la presente invención.

El modo en solitario es un modo de entrenamiento o de demostración. Permite que un jugador solo compruebe las diferentes funcionalidades del juego, o que se mejore.

En adelante, el jugador que controla el NAO se denomina: Jugador N, el jugador Aliado del jugador N, se denomina: Jugador A y, finalmente, el Enemigo y adversario de los dos primeros jugadores se denomina: Jugador E.

2/Descripción del Concepto

Objetivo

Al principio del juego, los 3 jugadores definen juntos un punto de Partida (punto D) y un punto de llegada (punto A). Estos dos emplazamientos deberán estar suficientemente alejados para que el NAO no pueda recorrer la distancia que separa estos dos puntos en menos de un minuto. Idealmente, puede preverse que estos dos puntos estén en habitaciones diferentes.

Entonces, el jugador N debe tomar el control del NAO gracias a su iPhone y pilotarlo para hacerle salir del punto D al punto A.

Dispone de 10 minutos para realizar este recorrido.

El jugador E debe hacerle de todo para hacerlo fallar y, de esta manera, conseguir la victoria.

El jugador A debe ayudar lo mejor que pueda al jugador N, mediante sus consejos y mediante las acciones que puede realizar.

Es igualmente posible fusionar los roles del jugador N y del jugador A. Pudiendo entonces el propio Jugador N gestionar las tarjetas Aliadas.

Por lo tanto, el juego es un enfrentamiento entre el equipo de los jugadores N y A contra el jugador E.

Accesorios de juego

De hecho, hay tres tipos de accesorios en el juego: - El iPhone: es el accesorio de control, que permite que el jugador N pilote el NAO.

- Una serie de Tarjetas, que poseen o no NAOMARK, que son los “poderes” de los jugadores A y E.

- Cualquier tipo de accesorios que pueden encontrarse en una casa, esto se precisará más adelante.

3/Ejecución del juego

Al principio del juego, el jugador N coloca el NAO sobre el punto D de partida. Coloca una paquete de 20 Tarjetas delante del jugador A y un paquete de 20 Tarjetas delante del jugador E. Entonces, A y E sacan 2 tarjetas de su paquete respectivo y conservan estas tarjetas secretas. (incluso el jugador A con respecto al jugador N).

En el iPhone, el jugador N lanza la aplicación de juego. Después de una serie de Logos, llega al menú principal.

En este menú, elige “juego con varios”.

En la pantalla se visualiza un contador con 10 minutos y un botón “Start”.

En este momento, el jugador N no puede controlar el NAO.

4/Lanzamiento del juego

El jugador N aprieta el botón “Start” en su iPhone. Un anuncio sonoro advierte a todos los jugadores que la partida ha comenzado. La cuenta atrás se activa. Por lo tanto, en la pantalla el tiempo es perfectamente visible.

El jugador N puede a partir de este momento controlar el NAO. Por lo tanto, puede moverse.

En momentos clave, el iPhone anuncia la situación de la partida.

Cuando se está a mitad de tiempo (5 minutos) Cuando solo queda un minuto.

Un Bip sonoro se activa en los 10 últimos segundos.

5/Victoria y Derrota.

La derrota de los jugadores N y A conlleva automáticamente la victoria del jugador E y a la inversa.

El jugador E no puede “ganar” por sí mismo. Su victoria es la consecuencia de la derrota de los jugadores N y A.

Victoria para los Jugadores N y A

Si el NAO alcanza el punto de llegada, mientras que le tiempo concedido todavía no ha transcurrido, se ha conseguido la victoria.

Con el fin de validar esta llegada, se coloca una NAOMARK en el punto A. Reconociendo esta NAOMARK, NAO puede enviar la información de victoria al iPhone, lo que pone fin a la partida. Un mensaje de felicitación aparece en la pantalla del iPhone para los jugadores N y A.

Después de un clic en la pantalla, se regresa al menú de partida.

Derrota para los Jugadores N y A

La derrota es bastante sencilla: si el contador llega a Cero en el iPhone, la partida está terminada y el jugador E es ganador.

Opción: En caso de caída del NAO, se puede, ya sea declarar esta caída como definitiva, enviando el NAO una señal de derrota, ya sea limitar la caída a la pérdida de tiempo natural que genera, ya sea finalmente pedir al NAO que envíe un mensaje que haga perder una cantidad de tiempo (30 segundos, por ejemplo), lo que pone en desventaja a los jugadores N y A.

6/El iPhone

El iPhone es el centro de control de la partida, pero igualmente el “mando a distancia” que permite que el jugador N controle a NAO.

Los principales controles de NAO ejecutados en el iPhone son los controles de desplazamiento. El acelerómetro incluido en el iPhone detecta los movimientos de las manos del jugador N y los ejecuta en función de un código programado, que puede ser, por ejemplo, el ilustrado mediante la figura 8d. De esta manera, es posible hacer que NAO se desplace adelante, hacia atrás, hacia la derecha o hacia la izquierda.

Gracias a unos botones adicionales en la pantalla, es posible pedir a NAO que extienda los brazos hacia adelante o que efectúe cualquier otro gesto que se desee programar.

Como se ha indicado en el comentario a la figura 4d, es posible sustituir el iPhone por otro mando a distancia que disponga de funcionalidades similares.

7/Las tarjetas

Presentación

Uno de los aspectos notables del juego es la utilización de tarjetas por los jugadores A y E.

Estas tarjetas permiten que los jugadores A y E intervengan en el desarrollo del juego, de manera positiva o negativa para el jugador N.

Existen 2 motones de tarjetas. Uno para el jugador A y otro para el jugador E.

Las tarjetas son diferentes en los 2 montones.

Las tarjetas están divididas en categorías y el propio NAO puede activarlas en ciertos casos.

Utilización

Al principio del juego, los jugadores A y E sacan 2 tarjetas cada uno. De hecho, esto permite tener una cierta estrategia en la utilización de las tarjetas.

Cada minuto, (el iPhone indica el momento correcto), los jugadores A y E pueden sacar una tarjeta suplementaria.

Los jugadores A y E pueden utilizar y, por lo tanto, activar las tarjetas que están en su poder en cualquier momento.

De hecho, la activación de la tarjeta depende del tipo de la tarjeta.

- Ciertas tarjetas exigen acciones de ciertos jugadores.

- Ciertas tarjetas las activa el propio NAO: presentando la tarjeta (provista de una NAOMARK) a NAO,

Las tarjetas aliadas

He aquí una serie de tarjetas de las que el jugador A podrá beneficiarse. Las tarjetas del jugador A están hechas, por lo general, para anular o contrarrestar los efectos negativos del jugador E: - Tarjeta Anulación: esta tarjeta debe presentarse a NAO en ciertos casos; esta tarjeta una vez jugada permite anular una tarjeta o un efecto de otra tarjeta (en general una tarjeta negativa del jugador E); - Tarjeta Tiempo suplementario: esta tarjeta debe presentarse a NAO; permite añadir un minuto al tiempo restante; - Tarjeta Protección: esta tarjeta debe presentarse a NAO; activando esta tarjeta, NAO rechaza leer cualquier tarjeta negativa que le sea presentada durante 1 minuto; como contrapartida, esto no protege de las tarjetas que no requieren la lectura de NAO; - Tarjeta Ralentización: esta tarjeta debe presentarse a NAO; gracias a esta tarjeta, el tiempo transcurre 2 veces menos rápido, lo que permite que el jugador N disponga de más tiempo; - Tarjeta Desplazamiento del Punto de Llegada: esta tarjeta no tiene que presentarse a NAO; esta tarjeta muy particular existe solo en un único ejemplar en el juego. Permite desplazar el punto de Llegada con el objetivo de facilitar la tarea del NAO; sin embargo, este desplazamiento está limitado, normalmente, a un radio de 3 m; - La tarjeta Misterio: esta tarjeta debe presentarse a NAO; su efecto es una sorpresa; en la mayoría de los casos, va a tener un efecto positivo y a comportase como una tarjeta de tipo 1 a 4, pero en un caso de cada 5 va a tener un efecto negativo: puede activar un Baile del NAO; - Tarjeta Turbo: Esta tarjeta debe presentarse a NAO; esta tarjeta permite que NAO durante 1 minuto se desplace más rápido.

Las tarjetas enemigas

He aquí una serie de tarjetas de las que el jugador E podrá beneficiarse. Las tarjetas del jugador E están hechas, por lo general, para molestar a los jugadores N y A en su búsqueda de victoria.

Son las tarjetas más interesantes, pues son ellas quienes originan los desafíos a los que NAO se enfrenta: - Tarjeta Movimiento: Vuelta en el lugar; esta tarjeta no se presenta a NAO; activando esta tarjeta, el jugador E pide al jugador N que haga dar a NAO 3 vueltas en el lugar. Por lo tanto, esta maniobra va a retrasarlo; - Tarjeta Aceleración del Tiempo: esta tarjeta debe presentarse a NAO; activando esta tarjeta, el tiempo se pone a avanzar más rápido; - Tarjeta Baile: esta tarjeta debe presentarse a NAO; activando esta tarjeta, NAO activa en el lugar un baile de demostración; este lleva un cierto tiempo y durante este tiempo, el jugador N pierde el control de NAO; - Tarjeta Obstáculo: esta tarjeta no tiene que presentarse a NAO; gracias a esta tarjeta, el jugador E puede colocar un obstáculo físico en el camino de NAO; entonces, NAO debe rodear este obstáculo o intentar franquearlo, pero corriendo entonces el riesgo de caerse; no hay regla particular para la selección del obstáculo, en cambio, el jugador E no puede en ningún caso bloquear el acceso a la llegada, y el obstáculo nunca debe ser de un tamaño superior a 2 veces el de NAO; - Tarjeta Pelota de Espuma: esta tarjeta no tiene que presentarse a NAO (salvo fracaso); esta tarjeta particular pide a NAO que realice un minidesafío; en primer lugar, NAO debe extender los brazos; a continuación, se le coloca una bandeja y se coloca encima una pelota de espuma; a partir de este instante, NAO debe continuar jugando, pero en esta posición; la dificultad viene del hecho de que no debe dejar caer la pelota de espuma, si no, sufre una penalización de 4 minutos (en este caso, el jugador E presenta la tarjeta al NAO para validar la pérdida de tiempo); el jugador A puede utilizar tarjetas para liberar a NAO de esta limitación.

- Tarjeta Órdenes Invertidas: esta tarjeta debe presentarse a NAO. Una vez activadas, las órdenes del NAO por el jugador N se invierten durante 1 minuto, lo que se convierte en muy difícil, sobre todo si están activos otros acontecimientos (pelota de espuma, obstáculo, etc…) - Tarjeta Desplazamiento del Punto de Llegada: esta tarjeta no tiene que presentarse a NAO; esta tarjeta muy particular solo existe en un único ejemplar en el juego; permite desplazar el punto de Llegada, lo que complica la tarea del equipo Aliado; este desplazamiento debe hacerse en una zona visible para el NAO.

Pueden crearse otras tarjetas fácilmente y añadirse al juego descrito de esta manera.

8/El modo en solitario

A partir del menú principal en el iPhone, es posible elegir el modo en Solitario. En este caso, el jugador accede a 2 submenús: - Modo Libre: en este modo, el jugador va a poder controlar el NAO sin objetivo particular. Esto permite que juegue con su NAO ordenándolo con el mando a distancia con su iPhone; - Modo Entrenamiento: en este modo, el jugador tiene el control de NAO y puede reproducir las condiciones de una partida real; el tiempo está presente y dispone de tarjetas A en su poder; es el iPhone quien cada minuto va a activar un acontecimiento negativo para retrasar al jugador; el aspecto estrategia no está presente, pero el entrenamiento permite perfeccionarse.

Para implementar la invención, hay que garantizar una comunicación entre robot jugador y jugador humano o entre robots jugadores que sea lo menos ambigua y lo más fluida posible.

El robot humanoide de la invención está equipado ventajosamente con sensores y con softwares que le permiten detectar y eventualmente reconocer formas, concretamente caras, y palabras. Sin embargo, teniendo en cuenta las imperfecciones de este tipo de mecanismos, es necesario prever unos mecanismos de aclaración de duda o de rodeo en caso de reconocimiento defectuoso.

En particular, tratándose de la aptitud del robot para reconocer a un jugador entre varios, es sencillo y ventajoso, en numerosas configuraciones de juego, pedir a los jugadores que jueguen a su vez con la llamada de su indicio (Jugador 1, Jugador 2, Jugador 3, etc…).

Los jugadores pueden disponer igualmente de signos que permitan reconocerlos, como unas NAOMARK, anteriormente descritas.

Es posible igualmente comunicarse con el robot mediante el tacto, en partes de su cuerpo previstas para ello, como la cabeza, el torso o los pies.

Concretamente, a menudo es necesario prever unos medios para aclarar las dudas y ambigüedades de las respuestas que el robot interpreta.

Tratándose del reconocimiento vocal, puede programarse una Caja Selección del software Chorégraphe, que es una de las Cajas cuyos roles y funcionamientos genéricos se han explicado más arriba en el comentario a la figura 3, para que permita que el robot haga una pregunta (eventualmente vacía) al usuario haciendo disponible, por ejemplo, un número finito de respuestas. Está programada igualmente para que pida a un jugador que proporcione puntualizaciones a su respuesta cuando el robot no está seguro de haberla reconocido o interpretado correctamente. Este mecanismo es idéntico al que utiliza un humano que tuviera una audición deficiente o que estuviera inmerso en un entorno que hace difícil su comprensión. La Caja Selección está programada con unas respuestas diferentes según el nivel de comprensión de la respuesta por el robot. Estos umbrales se fijan en función de la confianza de reconocimiento calculada por el software de reconocimiento: por ejemplo, cuando no se alcanza un primer umbral de reconocimiento, el robot pide al jugador que repita su respuesta; cuando se alcanza el primer umbral, pero cuando no se alcanza un segundo umbral de reconocimiento más elevado, el robot está programado para hacer una pregunta cuya respuesta permitirá normalmente aclarar la duda.

A cambio, el robot se comunica con el o los jugadores mediante la palabra, o emitiendo signos, concretamente con sus LED, o efectuando gestos. Puede programarse igualmente para comunicarse mediante lenguaje codificado, como el morse, que puede ejecutarse ya sea de manera visual (LED, gestos) ya sea de manera sonora.

Teniendo en cuenta su gran versatilidad, el robot jugador de la invención es adecuado para encarnar a varios personajes en un mismo juego. Para ello, puede tener varias “personalidades” que permiten, expresadas concretamente mediante voces diferentes, multiplicar las posibilidades de los jugadores e incrementar la experiencia lúdica.

En el marco de la presente invención, están previstos igualmente unos mecanismos de pausa y de reanudación, así como unos medios para hacer frente a incidentes como una caída del robot o un agotamiento de su alimentación eléctrica.

Los jugadores reales pueden programar pausas. Entonces, la partida se salva en las diferentes memorias asociadas a los procesadores donde el juego está repartido eventualmente (robots, PC, sitios remotos). El jugador acciona la reanudación según un procedimiento estándar o automáticamente por el robot que vuelve a arrancar en el modo adecuado.

En lo que se refiere a los incidentes, pueden preverse unos mecanismos de salvaguarda automática a intervalos regulares, que permiten una reanudación cuando se ha resuelto el incidente.

Unos procedimientos permiten igualmente que el robot se levante en posición de pie o se vuelva a sentar después de una caída (Procédures Standing, Sitting).

La programación del robot para ejecutar los comportamientos previstos en un juego se efectúa por medio de un software de edición de comportamientos del tipo de ChorégrapheTM descrito más arriba en el comentario a la figura 3. Este software incluye unos comportamientos estándar. Los comportamientos particulares de un juego pueden programarse en lenguaje Python o en C++ y asociarse al proyecto correspondiente al juego como recurso del proyecto. De esta manera, las diferentes Cajas de orden que constituyen la aplicación los llamarán cuando sea necesario. Sin embargo, el robot humanoide de la invención puede utilizarse sin que sea necesario disponer del software de edición de los comportamientos. En este caso, los comportamientos y otros módulos de software necesarios para la ejecución del juego se descargan en el propio robot, por ejemplo mediante el editor del juego. De hecho, se pueden considerar diferentes modos operativos de la invención.

Los ejemplos descritos más arriba se dan a título de ilustración de modos de realización de la invención. No limitan de ninguna manera el campo de la invención que se define mediante las reivindicaciones que siguen.

REIVINDICACIONES

1. Robot (100) humanoide que comprende al menos un procesador configurado para que el robot se desplace sobre unos miembros (140) inferiores, efectúe movimientos de miembros (150) superiores, emita y reciba unos mensajes que pertenecen al grupo de los mensajes visuales, sonoros, gestuales y/o táctiles y produzca al menos un comportamiento autónomo, constituyendo dicho al menos un comportamiento un elemento de una secuencia de un juego generada como respuesta a al menos un mensaje que pertenece al grupo de los mensajes visuales, sonoros, gestuales y/o táctiles, dicho robot estando caracterizado porque dicho al menos un procesador está configurado para que el robot haga al menos una pregunta en forma de mensaje que pertenece al grupo de los mensajes visuales, sonoros, gestuales y/o táctiles y determine si al menos un mensaje de respuesta que pertenece al mismo grupo contiene un respuesta verdadera, una respuesta falsa o una respuesta ambigua, efectuándose dicha determinación mediante dicho al menos un procesador a la salida de un bucle de repeticiones determinadas en función de umbrales de reconocimiento de dichas respuestas.

2. Robot humanoide según la reivindicación 1, caracterizado porque dicho robot es adecuado para reconocer objetos en su entorno y para integrarlos en la secuencia de dicho juego.

3. Robot humanoide según una de las reivindicaciones 1 a 2, caracterizado porque es el animador de un juego de preguntas-respuestas en el que participa al menos otro jugador que debe proporcionar las respuestas a las preguntas hechas por el robot.

4. Robot humanoide según una de las reivindicaciones 1 a 2, caracterizado porque es uno de los jugadores de un juego en el que participa al menos otro jugador y en el que debe reconocer a una persona o una cosa en función al menos de indicios que le son comunicados por dicho al menos otro jugador.

5. Robot humanoide según una de las reivindicaciones 1 a 2, caracterizado porque es un jugador de un juego en el que es adecuado para cooperar con al menos otro jugador para resolver al menos un enigma.

6. Robot humanoide según una de las reivindicaciones 1 a 2, caracterizado porque sus movimientos están determinados en parte en función de primeras consignas de desplazamientos que le son comunicadas mediante un mando a distancia manipulado por un primer jugador, de segundas consignas de desplazamientos, antagonistas de las primeras consignas, que le son comunicadas visualmente por un segundo jugador y de terceras consignas de desplazamientos, antagonistas de las segundas consignas que le son comunicadas por un tercer jugador.

7. Robot humanoide según una de las reivindicaciones 1 a 6, caracterizado porque al menos dos robots participan en un mismo juego, estando en comunicación dichos al menos dos robots mediante al menos un mensaje visual, sonoro y/o gestual.

8. Robot humanoide según una de las reivindicaciones 1 a 6, caracterizado porque al menos dos robots participan en un mismo juego, estando en comunicación dichos al menos dos robots mediante intercambio de mensajes de comportamientos.

9. Robot humanoide según la reivindicación 8, caracterizado porque dicho intercambio de mensajes de comportamientos se activa después de una etapa de identificación recíproca de dichos robots mediante intercambio de informaciones que los caracterizan.

10. Robot humanoide según la reivindicación 9, caracterizado porque dichos al menos dos robots son adecuados, además, para descargar una señal de sincronización de sus movimientos.

11. Robot humanoide según una de las reivindicaciones 1 a 10, caracterizado porque al menos un robot jugador y otro jugador se sitúan en dos lugares no unidos mediante una red local.

12. Robot humanoide según la reivindicación 11, caracterizado porque dichos al menos un robot jugador y otro jugador se comunican mediante protocolo de comunicación en red de área amplia y porque dicho robot jugador está dotado de medios autónomos de procesamiento para la codificación de los accesos de red.

13. Robot humanoide según una de las reivindicaciones 1 a 12, caracterizado porque un jugador es adecuado para comunicarse con él por medio de un código visual.

14. Robot humanoide según una de las reivindicaciones 1 a 13, caracterizado porque es adecuado para realizar una función de asistencia a al menos otro jugador que consiste en efectuar al menos una acción en el juego en lugar del jugador.

15. Robot humanoide según una de las reivindicaciones 1 a 14, caracterizado porque dicho robot es adecuado para activar y gestionar las interrupciones y reanudaciones de una secuencia de juego.

16. Robot humanoide según una de las reivindicaciones 1 a 15, caracterizado porque dicho robot es adecuado para reconocer a al menos un jugador entre varios, utilizando dicho reconocimiento un indicio que pertenece al grupo de los indicios visuales, sonoros, gestuales y/o táctiles.

17. Procedimiento de control de un robot humanoide que comprende al menos un procesador configurado para permitir que dicho robot se desplace sobre unos miembros (140) inferiores, efectúe movimientos de miembros (150) superiores, emita y reciba unos mensajes que pertenecen al grupo de los mensajes visuales, sonoros, gestuales y/o táctiles y produzca al menos un comportamiento autónomo, constituyendo dicho al menos un comportamiento un elemento de una secuencia de un juego generada como respuesta a al menos un mensaje que pertenece al grupo de los mensajes visuales, sonoros y/o gestuales, dicho procedimiento estando caracterizado porque comprende una etapa, ejecutada mediante dicho al menos un procesador, en la que dicho robot hace al menos una pregunta en forma de mensaje que pertenece al grupo de los mensajes visuales, sonoros, gestuales y/o táctiles y determina si al menos un mensaje de respuesta que pertenece al mismo grupo contiene un respuesta verdadera, una respuesta falsa o una respuesta ambigua, efectuándose dicha determinación mediante dicho al menos un procesador a la salida de un bucle de repeticiones determinadas en función de umbrales de reconocimiento de dichas respuestas.

18. Programa de ordenador que comprende unas instrucciones de código de programa que permiten la ejecución del procedimiento según la reivindicación 17 cuando el programa se ejecuta en un ordenador, estando configurado dicho programa para permitir que un robot humanoide se desplace sobre unos miembros (140) inferiores, efectúe movimientos de miembros (150) superiores, emita y reciba unos mensajes que pertenecen al grupo de los mensajes visuales, sonoros, gestuales y/o táctiles y produzca al menos un comportamiento autónomo, constituyendo dicho al menos un comportamiento un elemento de una secuencia de un juego generada como respuesta a al menos un mensaje que pertenece al grupo de los mensajes visuales, sonoros y/o gestual, dicho programa estando caracterizado porque comprende un módulo configurado para generar un comportamiento en el que dicho robot hace al menos una pregunta en forma de mensaje que pertenece al grupo de los mensajes visuales, sonoros, gestuales y/o táctiles y un módulo configurado para determinar si al menos un mensaje de respuesta que pertenece al mismo grupo contiene un respuesta verdadera, una respuesta falsa o una respuesta ambigua, efectuándose dicha determinación mediante dicho al menos un procesador a la salida de un bucle de repeticiones determinadas en función de umbrales de reconocimiento de dichas respuestas.

Niño Adulto Experto MÍMICAS Animales Tiburón Gallina Rana Elefante Pingüino Conejo Gorila Pájaro Deportes Boxeo Esquí Lanzamiento de pesos Tenis Kárate Halterofilia Tiro con arco Esgrima Personajes Tarzán Napoleón Charlie Chaplin Supermán Sherlock Holmes Profesiones Guitarrista Leñador Director de orquesta Violinista Pianista Cámara Cantante Pintor ADIVINANZAS Cálculo Sumas Multiplicaciones Multiplicaciones complejas Restas Divisiones Divisiones complejas Sumas complejas Restas complejas Cultura general Preguntas de Preguntas de Respuestas Preguntas normales complejas Respuestas Múltiples Múltiples complejas Sí/No Preguntas normales Observación Movimientos de Nao Mvts de Nao complejos Mvts de Nao con trampas Colores de Nao Colores de Nao complejos Colores de Nao con trampas SONIDOS Lenguas Inglés Italiano Ruso Extranjeras Alemán Español Criollo Japonés Árabe Naturaleza Perro Tormenta Pavo real Caballo Asno Elefante Gato Mar Pájaro Mono Vaca Carnero Vida diaria Teléfono Máquina de escribir Tren Hervidor Aspirador Claxon Instrumentos de música Piano Bajo Arpa Guitarra Trompeta Clarinete Batería Armónica Flauta FIG.5