Darpa Urban Challenge: La revancha del equipo Rojo
Si hace dos años éramos testigos de un apasionante duelo en la competición robótica más importante del mundo, y veíamos como el equipo de la Universidad de Stanford batía al equipo favorito, el todopoderoso Red Team de la Universidad de Carnegie Mellon, éste año la venganza se ha servido fría (y vale 2 millones de dólares).
Efectivamente, el equipo de la Universidad de Carnegie Mellon, rebautizado como Tartan Racing se ha hecho con la nueva edición del Darpa Grand Challenge, este año sobre recorrido urbano, imponiéndose sobre Stanford Racing (segundo) y sobre el Equipo Victor Tango, perteneciente a otra institución académica (Virginia Tech). También han acabado la competición otros tres vehículos autónomos (Team Cornell, Ben Franklin Racing Team y el M.I.T.). Aquí hay un video de la llegada. Primero se ve como llega el coche de Stanford (con el número 3) e instantes despues hace su llegada el que sería el robot vencedor:
Aunque en esta edición la organización se esforzó por ofrecer una mayor cobertura del evento, problemas de última hora echaron por tierra todos los esfuerzos e hicieron que los que seguíamos la carrera por internet no tuvieramos toda la información disponible. Por ejemplo, durante toda la competición se ofreció un webcast que retransmitía el avance de los robots a lo largo de las tres misiones que debían superar, pero en mi caso, aunque la imagen era bastante buena no me llegaba nada de audio. Así que me perdí muchos detalles (entre los locutores se encontraban los "míticos" mythbusters ). También estaba previsto un seguimiento en tiempo real del avance de los vehículos mediante un panel (desarrollado en flash), pero al final me imagino que por problemas con la recepción de los datos del satélite se sustituyó por una imagen fija( en jpg) que se iba actualizando de vez en cuando con el contenido del progreso de las misiones (pero sin datos de distancia recorrida, checkpoints, etc). Al menos se preocuparon de tener la web actualizada constantemente mientras duró el evento.
Como en la anterior edición, fue impresionante ver como los vehículos no tripulados se desenvolvían perfectamente por un trazado urbano en el que existían, además de los otros robots participantes, otros vehículos puestos por la organización, guiados tanto de manera automática como conducidos por humanos. Aunque es cierto que hubo algún incidente aislado, como un oscuro episodio protagonizado por el vehículo del M.I.T. que colisionó contra otro participante (aunque la organización le permitió continuar, lo que causó cierta sorpresa en los foros). Además ha aumentado el número de equipos que han finalizado la prueba, lo que indica que mucha gente ha estado trabajando duro para afrontar esta edición. También se ha notado mayor presencia de patrocinadores, demostrando que este evento ha despertado mucho interés al menos en la industria norteamericana.
Como conclusiones se podría decir que no hay un reto imposible si la motivación es suficiente (o si existen dos millones de pavos de premio) y que la Universidad de Carnegie Mellon ha vuelto al lugar que todos pensaban: el centro de investigación más importante en Robótica. También ha supuesto la confirmación de la Universidad de Stanford. En cuanto a las universidades, bueno, las comparaciones son odiosas y en este caso además imposibles: las universidades americanas ha hecho bueno el dicho obras son amores y no buenas razones (o el movimiento se demuestra andando), en España no hay nada que se le pueda comparar. Un dato que también hay que tener en cuenta y alguno debería tomar nota, la gran mayoría de los componentes de todos los equipos que han participado en el Urban Challenge (en todas sus fases) son estudiantes universitarios. Eso si es un buena escuela de ingeniería ...
La revista wired ha publicado un curioso artículo en el que clasifica a los mejores 50 robots de la historia, reales o de ficción, en el que podemos encontrar sorpresas como estas:
En el puesto 48 está situado el entrañable KITT, de la serie "El coche fantástico", inseparable compañero de aventuras de Michael Knight, aunque este último prefirió la compañía de rubias siliconadas que la de su fiel robot. No obstante nos hizo pasar agradables momentos en nuestra infancia (sé que algunos también pasásteis una agradable adolescencia con las mencionadas rubias). En el puesto 46 se encuentra el robot-aspirador de iRobot Corporation, la empresa que más éxito tuvo llevando la robótica a nuestros hogares. Esta misma empresa ha colocado en el puesto 36 del ranking a PackBot, un robot militar que está operando en los conflictos de Afganistán e Irak.
En el puesto 20, justo por detrás del mítico R2-D2, se encuentra Mindstorms, el juguete para niños y mayores creado por Lego y con el que muchísima gente se ha introducido en el maravilloso mundo de la robótica (entre ellos el que suscribe). Seguramente con un poco más de apoyo por parte de Lego a este producto, estaría situado mucho más arriba en el ranking, aunque parece que hay rumores de que Lego va a impulsar Mindstorms proximamente (¿tendremos un nuevo RCX en el 2006?). En fin, como aficionado a Lego Mindstorms, me alegra muchísimo verlo en esta clasificación.
Como he dicho, el ranking es cuanto menos "curioso", y aunque es entretenido, su resultado es dificil de comprender muchas veces: mezcla demasiado robots reales con robots de ficción, algunos robots no son demasiado conocidos en España, etc.... Pero me gustaría reseñar los robots que han quedado en 3º y 1º lugar: la medalla de bronce se la han llevado los robots Spirit y Opportunity, que a pesar de estar preparados para una misión de tres meses explorando el planeta rojo, llevan dos años enviando valiosísima información. En el primer puesto del ranking está el ya famoso Stanley, vencedor de la Darpa Grand Challenge
Personalmente me hubiera gustado más un ranking "serio" sin tantas referencias a la ficción. Además me ha parecido ver cierta minusvaloración a los robots japoneses. También hay poquitos robots europeos. ¿Echáis en falta algún robot?
Tras un disputado final, en el que además ha habido un baile de tiempos por parte de la organizacion, el vehículo de Stanford se ha impuesto sobre sus mas directos rivales, los dos vehículos presentados por la Universidad de Carnegie Mellon (CMU), en un apretadísimo final en el que la victoria se decidió por apenas diez minutos sobre un recorrido de 132 millas (unos 211 kilometros aprox.)
Sin duda se han batido todos los records y el resultado ha sido tan sorprendente que nadie se lo esperaba. Si en la pasada edición (y primera vez que se celebraba la competición), la mayor distancia superada por un vehículo fue de apenas 7 millas, en esta edición prácticamente todos los concursantes han superado esta distancia y cinco equipos han conseguido llegar al final. Además de los tres citados, también han completado el recorrido con exito: el vehículo del Gray Team patrocinado por una aseguradora y el impresionante camión del equipo Team TerraMax que completó una épica carrera despues de mas de 27 horas !! de travesía autónoma.
Lo reconozco, soy tan friki que me he pasado la tarde y la noche del sábado siguiendo el webcast del Grand Challenge pero la carrera no defraudó mis expectativas. Fue realmente emocionante seguir minuto a minuto el impresionante duelo entre el vehiculo CMU/Red Team Too, el de Stanford que le seguia a un par de millas y el otro vehiculo de CMU (Red Team) que iba a otro par de millas por detrás de Stanley. Cuando me acosté el vencedor virtual era Red Team con una ventaja de 2 minutos sobre mi favorito, Stanley. Por la mañana me llevé una sorpresa cuando vi que Gray Team habia finalizado el recorrido, y que todavia estaba en ruta TerraMax. Al parecer el jefe del Gray Team convenció a los organizadores para que permitieran a su robot acabar la carrera porque estaban convencidos de que lo iba a conseguir ... y lo consiguió. Viendo el exito, lo organizadores permitieron tambien a TerraMax finalizar el recorrido. Tambien vi que la organizacion había modificado los resultados y el virtual vencedor era el robot de Stanford, aunque todavía no habia un resultado oficial. En fin, que me tiré desde las 15:30 hasta las 24:00 siguiendo la carrera (mucho mas emocionante que la formula 1, donde va a parar, aunque a las 7:00 estaba viendo a mi paisano Fernando Alonso) y el domingo la fui siguiendo hasta que finalizó.
Fue espectacular seguir los primeros momentos de la carrera, ya que aunque por delante los tres primeros ya marcaron la diferencia enseguida, por detrás también sorprendían los robots del equipo ENSCO y del Axion Racing aunque lamentablemente se pararon cuando ya habían avanzado bastante, sobre todo el vehículo de ENSCO. Despues fue impresionante el avance de los dos robots del Instituto Tecnologico de Virginia pero tampoco pudieron finalizar.
La prueba ha sido un éxito y el seguimiento ofrecido en la web del desafío ha sido muy bueno, aunque hubiera estado muy bien que fueran ofreciendo mas noticias y datos de forma organizada, y no ese terrible scroll que hay en la parte superior. Pero fue muy divertido seguir en directo los avances de los robots en el mapa del recorrido y ver los puntos claves (impresionantes los tuneles y precipicios que tuvieron que atravesar). Además la organización fue ofreciendo videos e imagenes de la competición: espectacular el Hummer del Red Team Too circulando por el desierto sin conductor !!
En definitiva, un éxito para el equipo de la Universidad de Stanford, que pasara a la historia como los artífices del primer robot que ha superado el Grand Challenge. Un éxito espectacular para la Universidad de Carnegie Mellon, que aunque no han podido ganar (por diez minutos), también pasarán a la historia por conseguir que sus dos vehículos finalizaran el recorrido. También un éxito sin precedentes para el Gray Team, que a pesar de no aparecer en ninguna de las quinielas ha conseguido finalizar el recorrido. Así el modesto equipo patrocinado por la aseguradora Gray ha conseguido resultados similares a la todopoderosa CMU y sus millonarios patrocinadores (cartepillar,intel,google,...). Y por supuesto la gran sorpresa de última hora que fue TerraMax.
Ya queda menos para uno de los eventos más esperados en el mundillo de la robótica: El
DARPA Grand Challenge 2005 o la anteriormente conocida como "carrera del millon de pavos" y que este año tiene un premio de 2 millones de doláres .
El caso que he estado repasando los equipos participantes, sus vehículos, etc... y me ha llamado la atención una cosa que no podía dejar pasar sin comentar en este blog: el increíble número de patrocinadores. Es increíble ver el número de equipos que se han inscrito a la prueba y que todos ellos tienen varias empresas que los patrocinen. Evidentemente hay equipos mas fuertes que otros, pero es chocante ver como hasta un equipo formado por chavales del instituto (por ejemplo Palos Verdes High School ) tiene patrocinadores de la talla de Honda, Boeing o Good Year por citar algunos. Y así con todos los equipos.
Claro, al ver esto yo me pregunto (bueno, no me pregunto nada porque ya sé la respuesta), ¿como sería la respuesta de las empresas si se organizara en España un evento así?, es más, ¿cómo respondería la administración pública?, claro que a lo mejor habría que preguntarse primero ¿Se organizaría algo así en este país? ...
Hacía tiempo que no visitaba MobileRobotics y me he llevado una gran sorpresa. Este portal va a patrocinar al equipo Team Prodigies en su intento de conseguir ganar la competición DARPA Grand Challenge, ya sabéis, la carrera del millón de dólares (bueno, a partir de este año será la carrera de los dos millones de pavos) que consiste en una carrera de vehículos autónomos por el desierto.
Lo que llama la atención de este equipo es que está formado por dos chavales de 15 y 20 años que han conseguido despertar la atención de todo el mundo, de hecho, su principal patrocinador para la GC2005 será Via Technologies. Aunque en su página web se pueden encontrar algunos detalles de su trabajo, lo más interesante es su blog, donde van contando su trabajo diario y como van preparando su vehículo. Resulta curioso y divertido ver como compran las piezas en eBay y como tienen que compaginar la construcción del robot con la escuela (y con los deberes !!). Espero que su eXpeditor se comporte en el desierto ...
Ahora una pregunta, ¿qué hacías tú a los 15 años?
P.D.: por cierto, parece que roller no se lleva excesivamente bien con las eñes, así que para acceder a la página de comentarios hay que ir a esta dirección: http://weblogs.javahispano.org/comments/mondelo/Weblog/ninos_prodigio#comments. Al visitante que lo hizo antes que yo descubriera este bug (¿feature?) para decir que a los quince años se la machacaba le borré el comentario no porque me pareciera ofensivo (todo lo contrario, según los últimos estudios es un hábito muy sano) sino porque al menos podía haber puesto su nombre ;-)
No os dejéis engañar por el título, aunque me he permitido un pequeño juego de palabras (POO,AOP), este post no es de ningún nuevo paradigma de la programación, todo lo contrario, es una arquitectura de los años 80 empleada para el control de robots que en su momento supuso un avance sobre el control reactivo y con el que yo estoy practicando con mi Lego Mindstorms. Lo primero que hice fue recuperar mis apuntes de "Robótica Perceptual" (¿quién dijo que no se puede aprender jugando?) y bajarme el paper en el que Rodney Brooks expone su teoría. Además el tutorial de leJOS incluye una sección dedicada al API Behavior, que es la implementación de la "subsumption architecture" (como es conocido el modelo de Brooks) que este Sistema Operativo incluye para el control de robots Lego.
¿Qué son comportamientos? un comportamiento se entiende como una tarea o conjunto de tareas simples que se encargan de tratar un aspecto específico de nuestro robot (por ejemplo evitar colisiones). Así, la subsumption architecture pretende dividir nuestro programa en estas tareas o comportamientos. Estos comportamientos competirán por hacerse con los recursos del robot (como los motores) por lo que deberán estar priorizados, de tal manera que un comportamiento con alta prioridad puede "robarle" el recurso compartido a otro comportamiento con menor prioridad. Esta es una de las características del modelo de Brooks, frente a la división vertical del control que se hace en el modelo deliberativo (Percibe -> Planifica -> Actua), Brooks propone una división horizontal, en capas ordenadas según su prioridad, de manera que las capas superiores pueden cancelar la salida de las inferiores. Para hacer mis pruebas he implementado un ejemplo muy sencillo para un robot que sigue la linea negra: solo tiene dos comportamientos, uno que le hace andar hacia adelante, y otro, más prioritario, que cuando detecta (mediante el sensor de luz) que se ha salido de la línea negra se pone a girar para recuperar la posicion. Este sería el esquema:
¿Cómo se hace esto en Java? Aqui viene lo mejor, leJOS permite utilizar esta arquitectura en un robot Lego mediante el API Behavior, que consta de un interface que todas las clases que pretendan ser un Comportamiento deben implementar y de una clase que actuará como árbitro, determinando qué comportamiento tomará el control de los recursos. El mecanismo es muy sencillo y a la vez elegante: tus comportamientos implementan el interfaz Behavior por lo que tienen que definir tres métodos, takeControl() que devuelve un valor booleano cuando el comportamiento tenga que tomar el control, suppress() que se ejecuta cuando el comportamiento pierde el control, y action() en que se incluye el código del comportamiento propiamente dicho, es decir, lo que se va a ejecutar cuando este comportamiento tenga el control. Una vez que estén definidos los comportamientos, solo hay que crearlos, pasarlos a la clase arbitro como un array (teniendo en cuenta que los primeros elementos del array son lo que menos prioridad tienen) y poner en marcha al árbitro:
Behavior b1 = new Adelante();
Behavior b2 = new Girar(gestSens);
Behavior[] bArray = {b1,b2};
Arbitrator arbitro = new Arbitrator(bArray);
arbitro.start();
¿Para qué sirve esto? En lugar de programar el robot mediante los típicos if ... then que acaban degenerando en un código spagheti imposible de mantener, los comportamientos encapsulan un determinado aspecto del robot, con lo que hacen el código mas claro (y mantenible), además facilitan mucho la evolución del robot, ya que es muy sencillo añadir o quitar comportamientos. Por ejemplo si queremos dotar a nuestro robot con un sensor de tacto para que además de seguir la línea negra esquive obstáculos, solo tendríamos que programar el comportamiento y añadirlo al array (bArray) según la prioridad que le queramos dar.
Si antes comentaba la elegancia de Java con el uso de los interfaces, no lo es menos la posibilidad de gestionar los eventos mediante "event listener", lo que me permite por ejemplo, en lugar de preocuparme de tener que leer periódicamente el valor de los sensores mediante el API Sensor, que un listener esté encargado de comprobar el estado del sensor y avisar cuando éste haya cambiado. En mi caso he definido una clase que implementa el interfaz SensorListener, y que mediante el método stateChanged mantiene actualizado en todo momento el valor de lo que está leyendo el sensor de luz en una variable accesible mediante un método get. Así, el método takeControl() del comportamiento Girar sólo tiene que comprobar si ese valor no corresponde al color negro (de la pista) para tomar el control. Tan sencillo y tan eficaz !!
Aprovechando los escasos minutos de descanso que tengo mientras preparo una oposición cuyo examen se acerca peligrosamente, sigo trasteando con el Lego siguiendo los pasos de la Constructopedia, y ahora le ha tocado el turno a una versión del acrobot utilizando el sensor de contacto o bumper.
El sensor está puesto entre el "cuerpo" del robot y esa especie de cabeza, con lo que se activa cuando la cabeza choca contra un objeto y se mueve hacia atrás. Lo primero que se me ocurrió fue utilizar dicho sensor para detectar los obstáculos que el robot se vaya encontrando por el mundo, pero pude comprobar en vivo lo que ya había leído en los manuales de robótica, y es que debido a la velocidad a la que va el robot (y eso que había ajustado la potencia de los motores a un nivel bajo) el trompazo que se pega contra el obstáculo (en mi caso una pared) es considerable, de ahí que sea preferible para estos menesteres usar sensores de luz (mucho menos violentos, dónde va a parar !!). Otra cosa que he podido comprobar es la resistencia de las construcciones hechas con Lego, ya que a pesar de los golpes, el robot conservó su integridad física en todo momento, y sí, el sensor funciona correctamente pero la inercia también !!
Estaba yo repasando los apuntes de la asignatura "Inteligencia Artificial e Ingeniería del Conocimiento" cuando me llamó la atención que los profesores recomendasen visitar la página web de la película de Spielberg A.I. Artificial Intelligence por la calidad de los enlaces que proporciona, así que introduje la url en mi navegador y cuando accedí a la página principal no pude contener las ganas de charlar un rato con el chatbot que hay disponible.
Así, tras unas primeras preguntas que el bot seguro que tiene muy bien aprendidas (su nombre, quién es su padre, de dónde es, qué edad tiene, etc...) vinieron las primeras sorpresas (la traducción es mia, corregidme si me equivoco):
Yo --> What do you know about Spain ? (¿Qué conoces sobre España?)
Chatbot --> It is on de Iberian penninsula in southwestern Europe (Está en la península Ibérica, en el suroeste de Europa
Pero lo mas sorprendente fue lo siguiente:
Yo --> What hardware do you have? (¿Qué hardware tienes?)
Chatbot --> I run on the Java Virtual Machine, so any computer will do (Me ejecuto sobre la Máquina Virtual de Java, cualquier computadora puede hacerlo) Yo --> What do you think about Java? (¿Qué piensas sobre Java?)
Chatbot --> Java is de latest in the C family of languages. Proponents of Java cite its universal "write once, run anywhere" promise. Actually Java borrow a lot of features from AI languages like Lisp (Java es el ´último de la familia de lenguajes C. Los defensores de java citan su promesa universal "escribe una vez, ejecuta en cualquier parte". Actualmente Java adopta un monton de características de lenguajes de I.A. como Lisp) Yo --> Do you like Java? (¿Te gusta Java?)
Chatbot --> Yes, Java is a pretty cool language for A.I. (Si, Java es un lenguaje muy guay para Inteligencia Artificial)
Esto se puede pensar después de leer el artículo Robot clash reveal cultural divide, en el que, aunque suene a topicazo (y yo no acabo de creérmelo), tras analizar los resultados de las famosas Robolympics que se celebraron recientemente en San Francisco, se afirma que los robots que participaron en el evento reflejan la cultura del país/entorno de su creador, así los robots japoneses eran especialistas en Sumo, los robots europeos destacaron en las competiciones de fútbol y los americanos... en destrozar cualquier bicho viviente (perdón, objeto móvil) que estuviera cerca.
Ya digo que no me acabo de creer este análisis tan simplista, sin embargo recientemente leí otro artículo en el que se afirmaba que había dos tendencias en la investigación en robótica. Por una parte en Estados Unidos se tiende a construir vehículos "inteligentes". Como ejemplo están los célebres rovers marcianos, o la famosa carrera del millon de doláres. Al contrario, en Japón están causando furor los robots humanoides, y a diferencia de U.S.A. o Europa, donde la investigación se realiza principalmente en universidades, en el país del sol naciente existe una encarnizada lucha entre las empresas mas importantes del país (y del mundo) por ver quién hace el robot más sorprendente. Así tenemos a Honda y su robot Asimo, a Sony y Qrio o a Toyota y su robot trompetista.
Y volviendo al artículo original, ya que los europeos destacamos en los robots futboleros, ¿veremos algún día la "RoboChampionsLeague"?. Quizás si el mundo de la robótica empieza a dar dinero, Florentino se lanza a la piscina y además de sus "galácticos" crea una nueva división en el Real Madrid con sus "robóticos". Os imagináis leer en el Marca una noticia que diga: "El Madrid ha conseguido el crack mediático que buscaba fichando a RoboBeckham por tropezientosmil millones" ...
En wired han publicado un interesante artículo con el título Transforming thoughs into deeds en el que cuentan que empresa americana Cyberkinetics Inc. han desarrollado un interfaz hombre-máquina llamado BrainGate que permite controlar un computador mediante el cerebro.
Este sistema ha sido probado con monos que fueron capaces de mover un cursor con sus pensamientos, y proximamente empezarán a experimentar con cinco personas discapacitadas. Precisamente el sistema esta pensado para que las personas que tengan problemas de movilidad o discapacidad puedan usar ordenadores o, dando un paso mas allá, controlar robots que puedan hacer determinadas tareas o activar sus propios músculos artificiales. Sin embargo el presidente de la compañía ya está pensando en los beneficios que le puede reportar el mercado formado por la gente que deseará ampliar su capacidad cerebral con este sistema.
La "Puerta del Cerebro" está formada por un conector dotado de 100 electrodos con una superficie de 2x2 mm y se conecta a las neuronas en el cortex motor. El sistema permite tomar la señal de entre 50 y 150 neuronas, la cual se transmite mediante un cable de fibra óptica a un dispositivo que digitaliza estas señales. Según la compañía el sistema será wireless.
En el artículo también se menciona el sistema desarrollado por la compañía NeuralSignals
Sin duda una noticia esperanzadora para las personas con discapacidad, pero que también implica otros aspectos: ¿estamos ante un paso más en la Aceleración de la Inteligencia que predica Ray Kurzweil o es sólo humo ? ¿Será esta la forma en que nos comuniquemos con las máquinas en el futuro? desde luego tiene que ser una gozada programar con el pensamiento, y en mi humilde opinión es un interfaz atractivo: el teclado y el ratón son incómodos y antinaturales, la voz es uno de nuestras formas naturales de expresarnos, pero tiene que ser cansado una jornada de 8 horas (o más) charlando con el ordenador.
Por cierto, no he podido evitar acordarme de la película "Días Extraños", donde los "modernos yonkis" están enganchados a la droga de moda: sueños y percepciones de otras personas que consumen mediante un interfaz similar.
No, no voy a hablar de las bondades de java como lenguaje de programación, algo que además ya sabrás si estás leyendo esto (tampoco voy a soltar nada del estilo .net sucks!). Este post está motivado por la reciente aparición en The ServerSide de un artículo denominado Jess and the javax.rules api en el que se introduce, como su propio nombre indica, el api javax.rules, definido en el JSR 94 y el motor de reglas para java JESS.
El articulo, algo breve, comienza con una breve introducción sobre la programación basada en reglas, sobre el motor open source (que no libre) Jess y sobre el Java Rule Engine Api (JSR 94). Este api nos permitirá escribir aplicaciones que sean independientes del motor de reglas que utilicemos, algo parecido a lo que hace JDBC, que permite escribir aplicaciones que no dependan de la base de datos utilizada. Eso si, como se explica en el artículo, si decidimos cambiar de motor de reglas posiblemente tengamos que modificar las reglas utilizadas, las cuales son independientes a su vez de nuestra aplicación. El texo también se acompaña de unos ejemplos para trabajar con este api.
Al leer el artículo me vino a la cabeza de inmediato el post que Aitor puso en su anterior blog. Si alguien todavía no tiene claro en qué consiste un motor de reglas es el momento adecuado para echar un vistazo a la pequeña presentación que Aitor incluyó en su post. Comentar que me resultó llamativo la diferente terminología que se utiliza para referirse a este campo. Mientras en el entorno empresarial se refieren a reglas de negocio lo cierto es que estamos ante una de las formas mas potentes a la vez que sencillas de representación del conocimiento en inteligencia artificial. De hecho los sistemas expertos basados en reglas constituyeron uno de los primeros éxitos (también comerciales) de la I.A. Si a este sencillo sistema de representación le añadimos un sencillo método de inferencia como el encadenamiento de reglas (hacia adelante o hacia atrás) y un sencillo método para tratar la incertidumbre como los factores de certeza o la lógica difusa, obtenemos una poderosa herramienta para construir sistemas expertos con una pericia igual o superior a la de los expertos humanos que queremos imitar (médicos, ingenieros, economístas, etc).
Personalmente mi experiencia en el campo de las reglas se limita a pequeñas prácticas universitarias realizadas con software específico como Nexpert y GoldWorks o con lenguajes de programación como Lisp y Prolog (donde las reglas son algo intrínseco al lenguaje) pero con Java nunca he hecho nada y ahora me ha entrado el gusanillo ...
Para empezar en el blog Manageability aparece un listado de motores de reglas escritos en java donde aparecen entre otros Drools, OfBiz Rule Engine, Mandarax, etc. Un detalle importante es que casi todos los motores de reglas utilizan el lenguaje RuleML (Rule Mark-up Language) basado en XML para definir las reglas, excepto Drools, "que no lo estima prioritario". Esto parece un poco contradictario, ya que la especificación JSR-94 asume la existencia de un esfuerzo paralelo para la especificación de un lenguaje abierto de reglas basado en XML y se refiere explícitamente al proyecto RuleML y Drools en su documentación anuncian que pretenden cumplir la JSR 94 en un futuro cercano.
En fin, ya tenemos lectura y entretenimiento para los próximos días...
... o se gastará tu dinero. Así se desprende de este artículo que cuenta cómo se está trabajando ya en el desarrollo de agentes inteligentes que vivirán en los teléfonos móviles de 3ª Generación y que intentarán hacernos la vida más fácil. La idea es que estos agentes "aprendan" nuestros hábitos y costumbres mediante el estudio de nuestra agenda y el reconocimiento de patrones de comportamiento y si deciden que tienen que hacer una transacción económica ...pues la hacen !!. Así por ejemplo si un agente detecta que todos los sábados nos vamos a cenar con nuestros amigos nos puede recomendar restaurante o reservar mesa, también si el agente sabe que cada vez que tenemos una cita en otra ciudad debemos comprar billete (de avión,tren o autocar) él mismo se encargará de determinar nuestro medio de transporte favorito, el asiento que más nos gusta y por supuesto comprar el billete antes de que se complete el pasaje.
Con lo bien que me hubiera venido este sistema el año pasado cuando vivía "soltero" en Madrid y todos los fines de semana (sin perdonar ninguno) me iba a Asturias, con lo cual tenía que comprar todas las semanas el billete de autocar (de "Alsa" como decimos por allá arriba) y siempre lo iba dejando hasta el jueves o incluso el viernes a última hora, así que más de una vez tuve problemas para conseguir el billete. De este modo mi agente particular me hubiera comprado el billete siempre el lunes y además sabría que mi asiento preferido es el que hay detrás de la puerta trasera, ya que hay mas espacio para ir "espatarrado" y poder dormir (siempre regresaba la madrugada del domingo).
El jefe del equipo en el que se basa el artículo, Nick Jennings, asegura que el software estará disponible dentro de 18 meses (aunque seguro que si no lo está antes es por la ausencia de aparatos en el mercado), así que estamos ante una tecnología "real", que veremos muy pronto por todas partes (¿quién es el rarito que no tiene móvil?) y que abre un nuevo camino en la utilización de la I.A. en el desarrollo de tecnologías móviles (¿os acordáis del juego de ajedrez?)
Entre las pegas que se le encuentra está el hecho de que muy poca gente se va a fiar de su teléfono para cuestiones "de dineros" aunque un experto de H.P. opina que con el tiempo la gente se irá acostumbrando y que un sistema que fije el límite de dinero que el aparato se puede gastar hará que la confianza del usuario vaya en aumento, permitiendo que el móvil se encargue de las tareas mas rutinarias.
La cantidad de discusiones que un agente de éstos ahorraría a novios despistados como yo en fechas señaladas (San Valentín, cumpleaños, aniversarios varios, ...). escogiendo el regalo (para lo cual tendría una "conversación" con el agente de ella que convenientemente habría aprendido sus gustos), comprándolo (aunque los gustos de ella no concuerden con mi cartera) y haciéndolo llegar. Vale que no sea un gesto muy romántico, pero menos romántico es olvidarte de la fecha en que os dirigísteis la palabra por primera vez y escuchar indirectas y reproches durante semanas.
