El bolsillo de la colación: La @socalitybarbie y el carpe diem de cartón

Un tema que salió en dos semanas sucesivas en el The Clinic (ediciones 611 y 612, Jueves 10 y 17 de septiembre respectivamente [aunque la del 10 aparece como 3 en la portada, acabo de notarlo]) y que me llamó mucho la atención por afinidad es el de la selfie como emblema contemporáneo de la vanidad. En la primera edición que menciono, el tema se toca en una carta al director enviada por Patricio Antonio Olavarria titulada “Odio la Selfi”. En este artículo se hace una crítica a la selfie como una muestra de vanidad, de poca sinceridad con la realidad. En palabras del autor de la carta:

La selfi es la inmediatez, la captura de una fantasía absurda que no es otra cosa que ausencia de realismo y realidad.

Y luego sigue haciendo una comparación con la fotografía antigua. La reflexión se enfoca en una actitud distinta sobre la fotografía que refleja en parte la actitud de las distintas épocas.

Los antiguos retratos, que tampoco son exultantes de alegría y no por ello son la manifestación de viejos y amargados hombres y mujeres, hablan por qué no decirlo de una época en la que reír más bien era un gesto sincero, o absurdo pero nunca una pose. (…) Es sencillamente muy difícil encontrar en la pintura del siglo XIX a modelos simulando estar henchidos de alegría. Lo que hay, son miradas.

En la edición de la semana siguiente del The Clinic, en un artículo titulado #NOPIENSENQUESOYCOMUNYCORRIENTE por Constanza Michelson, artículo que tristemente no encontré en la versión online del Clinic para haberlo linkeado, se presenta a este personaje que traigo hoy: la Socality Barbie.

Esta cuenta viene a reflejar algo que hace tiempo aqueja a nuestra sociedad. Pero como toda muestra de estupidez, cuando se vuelve masiva, pasa a aceptarse implícitamente y a ser una parte de la cultura. Recuerdo cuando una vez, en un carrete con unos amigos, me fijé en unas tipas sentadas cerca que se empezaron a sacar fotos. No era la primera vez que lo pensaba, pero esa imagen se me marcó muy fuertemente. Las tipas sonreían de oreja a oreja, se acomodaban el pelo, buscaban el ángulo perfecto, tomaban la foto, guardaban su sonrisa, miraban la pantalla y notaban que no les gustó. Pum, vuelta al paso uno. ¿Dónde quedaba esa sonrisa grandota después de que se sacaban la foto?

En el artículo, se analiza la nueva evolución en el intento desesperado de mostrar el yo al resto. En algún momento de la historia, creo que reciente, asumimos que al resto le interesaba saber quién era yo. Y el que esté libre de pecado que lance la primera piedra, miren que uno que escribe un blog asumiendo que puede decir algo interesante no puede dar un paso al lado. Pero hay un punto en el que eso mismo en que eso es quizá una etapa de crecimiento y de validación personal, algo así como autoconocimiento púber (me río para mis adentros recordando cuando tenía un parche de Tronic en la mochila). A la vez esas cosas nos sirven de cierta forma para cohesionarnos en un grupo, como las chapitas de anime y para identificarnos mutuamente dentro de alguna subcultura. Pero hay un momento en que se cruza ese punto “sano” y la necesidad de validación personal se sale de control. Es cuando ya dejamos de necesitar decir “yo soy tal y tal cosa y pertenezco a tal y tal grupo” y pasamos a decir “yo soy esto, tan fabuloso, y soy distinto de todos ustedes, montón de criaturas aburridas” o caemos en el igualmente terrible “¡mírenme! ¡estoy feliz y mi vida es fabulosa! (igual no estoy tan satisfecho así como para disfrutarla callado/a, ¿así que me dejas un like?)”.

La Socality Barbie (a la que yo llamaba equivocadamente Sociality Barbie hasta hace un rato, antes de que Lineth, una amiga, me contara que un amigo de USA le explicaba que era Socality por @socality, un sitio de payasos hipsters cristianos con cámaras que cuestan veinte sueldos mínimos…) representa muy bien lo anterior. Me encanta la parodia que hace de toda esta versión decadente del Millenial (así como en el artículo anterior yo mostraba una arista más simpática) que anda dedicada a la prostitución de likes por Internet. Toda esta moda bien hipster de andando mostrando fotos de viajes, sonreír mirando a la cámara (o a algún punto en el vacío para hacernos los interesantes), mostrar los libros que andamos leyendo y ponerlos al lado de una taza de café, ya se está saliendo de control. Y como el humor muchas veces cumple un rol exquisitamente pedagógico, aquí llega una parodia que reúne todos estos elementos y se ríe de ellos, y a la vez nos muestra su vacío y su sinsentido. Y qué mejor que hacerlo con una Barbie hipster, mezcla entre el canon de lo plástico y el tipo que quiere ser distinto para no ser mainstream y termina siendo tan repetido que se convierte en lo que repudia: un lugar común.

Quiero citar un fragmento del artículo de Constanza Michelson porque simplemente me parece hermoso:

El enemigo lógico de la #vidaauténtica debiera ser lo que huela a simulación. Sin embargo, parece que a esta ideología no le importa tanto la tensión entre lo verdadero y lo falso, ya que asume con total descaro que una imagen ultra planificada, llena de filtros y a la espera de aprobación, está libre del polvo y la paja de la falsa conciencia. Lo auténtico, más bien, responde a una tensión entre lo exclusivo y lo masivo: mientras menos accedan a esos rincones del mundo donde nos refugiamos, más cerca estamos de lo genuino.

Es medio ridículo esto a lo que hemos llegado, y hablo en primera persona plural porque yo igual tengo una selfie ultrasensual de foto de perfil en Facebook (lo sé, me quedan bien los lentes, gracias, gracias), así que necesitamos burlarnos de eso para que no se vuelva demasiado serio. Riámonos de las ridiculeces de nuestra sociedad, a ver si en el futuro se convierten en uno de esos recuerdos que nos sonrojan como el peinado que nos hacíamos en el liceo creyendo que nos daba más estilo o de cualquier moda pasada. Y qué mejor que la @socalitybarbie para ayudarnos a reír de este mundo de necesidad de aprobación, saturado de palabras como “auténtico”, “orgánico”, “light” y un montón de hashtags que no hacen más que lanzar un grito silencioso en el que pedimos ser vistos y valorados por el resto.

Riámonos de la selfie y este carpe diem de cartón detrás del que se esconden días aburridos haciendo scroll en las redes sociales. Riámonos de la apariencia de interesantes y no nos preocupemos de lo que vaya a pensar el resto cuando nos ve (escribo mientras suena esta canción, comentario random). Salgamos feos en la foto y que no nos importe. Yo ya me río bastante de mis propias selfies como en este ejemplo en el que hasta la original parece la parodia de algo.

Para el que se quiera reir con la @socalitybarbie, que se de una vuelta por su cuenta de Instagram: https://instagram.com/socalitybarbie/

Como siempre, espero que hayan disfrutado leyendo y cualquier comentario será bien recibido.

El bolsillo de la colación: Charming Chilean Memes y las sopaipillas en inglés

Hace tiempo que vengo juntando las ganas para empezar a escribir una sección sobre cosas con las que me divierto en internet. Cómics, páginas de memes, cuentas de YouTube… Hay mucho contenido con el que paso buenos ratos y me pareció bonito el ir guardando esos “buenos lugares” de internet, para que quizás, a alguien que ande aburrido, le puedan servir.

El bolsillo de la colación

Quiero empezar haciendo un pequeño comentario sobre el nombre de esta nueva sección. Desde Kinder, y hasta ahora, que estoy en sexto año de Ingeniería Civil Informática, en mi casa compran colación para que llevemos por el día. La gente que me conoce de cerca sabe que en mi mochila hay un bolsillo mágico, como el de Doraemon, del que siempre sale comida. A veces quedan impresionados porque saco y saco comida y ofrezco y ofrezco cosas como Twistos, barritas de cereal, galletas… Además, en ese bolsillo se han guardado cosas random como un bigote postizo, una pokebola, entre otros. Por eso, el bolsillo de la colación es como aquel espacio mágico del que siempre salen cosas maravillosas. Espero que esta sección sea algo como eso, pero con comida de internet.

Dicho eso, empecemos con el primer artículo dedicado a la página de memes de Facebook “Charming Chilean Memes” [1].

Los millenials chilenos

El término millenial [2] se usa comúnmente para describir al tipo de persona “que vio el cambio de milenio”. Es una generación que creció en un ambiente de mayor prosperidad económica, que tiene una visión de mundo generalmente más amplia a la que tuvieron sus padres y una generación que se vio expuesta a la globalización. No sé si el millenial sea exactamente el término que busco, pero sirve como referencia para acercarme a lo que quiero llegar.

Un meme, en su definición estricta, es un elemento que se comunica de memoria-a-memoria (de ahí el nombre) [3]. Cuando hablamos de meme, nos referimos a elementos que se comunican entre individuos y se reparten por la población. De ahí se derivan los memes de internet que vienen a ser la aplicación digital del mismo concepto. Al final, aunque haya gente que no quiera aceptarlo, el meme viene a representar parte de la cultura, algo que se esparce entre las mentes de los individuos y que al final deja de pertenecer sólo a una persona y pasa a ser un elemento distintivo de la colectividad. Entonces, podríamos decir perfectamente que “el Guatón Loyola” es un meme chileno…

Cómo decir “sopaipilla” en inglés

Hablar de un “millenial chileno” es hacer una mezcla de estos dos conceptos. Primero, tenemos la emergencia de un sujeto que está más abierto al mundo, que vive conectado con la globalidad. Este sujeto que vive conectado “hacia afuera” también vive dentro del segundo concepto: “los memes chilenos”. El millenial chileno vive dentro de todas esas cosas que sólo entendemos en Chile: las sopaipillas con mostaza, la resistencia ante los desastres naturales, el humor frente a los desastres políticos…

Este individuo vive en un punto intermedio en la sociedad. Está en una generación que vive conectada con lo de afuera, con memes que se esparcen por todo el mundo, con el inglés como un idioma que se mete por todas las rendijas de la cultura, y a la vez está conectada con su propio país, con sus tradiciones y sus elementos característicos. Es una generación que vive entre dos tensiones, con chistes que no pueden contarle a sus papás porque simplemente no los entienden o no les hacen gracia. Aquí es donde Charming Chilean Memes adquiere relevancia.

Charming Chilean Memes es una página de Facebook que grafica perfectamente a este sujeto intermedio. Son imágenes llenas de elementos propios de la cultura chilena, pero tratados en inglés. Como le decía a mi hermano mientras teníamos una reflexión muy random sobre este fenómeno: el millenial chileno es el que se pregunta cómo decir sopaipilla en inglés. Esta página de Facebook es relevante porque es un retrato de un chileno que está con un pie adentro y otro pie afuera del país y siente esa tensión de esa mezcla cultural. De esa misma tensión nace este humor de frontera, así como una forma de construcción de identidad de este chileno intermedio: global y autóctono.

When you realize that 27F was an inside job…

No recuerdo cómo llegué a esa página, pero no me arrepiento, porque me ha sacado lágrimas de risa. Además, me sirvió como punto de partida para esta reflexión cultural sobre nuestra generación. Y parece que cada vez van apareciendo más evidencias de esta cultura de frontera o millenials chilenos, como los llamo a falta de una mejor expresión. Ejemplos de páginas que he encontrado del mismo estilo son “BKN screenshots without context” [4], que también me encanta, y la que encontré el otro día: “The same photo of porotos everyday” [5], en la que publican todos los días la misma foto de un plato de porotos with riendas.

Espero que les haya gustado el artículo y la sección nueva. También espero que si no conocían las páginas que mencioné, les saquen ojalá tantas risas como a mí. Si conocen alguna otra página de este mismo estilo, pueden dejarla en los comentarios 🙂

EDIT: Me estaba lavando los dientes y se me acaba de ocurrir que “chilenials” puede ser un buen término para referirse a lo de arriba. Eso.

Referencias

  1. Charming Chilean Memes en Facebook -> https://www.facebook.com/chchmemes
  2. Millennials: la generación malcriada que quiere cambiar al mundo -> http://www.abc.es/20121103/sociedad/abci-millennials-generacion-201211021603.html
  3. Meme en Wikipedia -> https://es.wikipedia.org/wiki/Meme
  4. BKN screenshots without context -> https://www.facebook.com/BKNscreenshots
  5. The same picture of porotos everyday -> https://www.facebook.com/porotitosricos

Haciendo programas con opciones de consola con C++ y Boost

Cuando uno ya lleva unos años programando y se pone a ver sus códigos viejos generalmente piensa “joder, qué ***** más fea”. Mientras vamos adquiriendo más experiencia y vamos participando en proyectos más complejos, se nos va haciendo necesario el programar “como se debe”. Una de las cosas importantes al programar bien es hacer programas que sean fácil de ejecutar y que puedan configurarse mediante varias opciones sin tener que compilarse de nuevo. La idea es conseguir algo así:

programa --opción1 valor1 --opción2 valor2

Para eso, cuando trabajamos en C o C++ tenemos las variables argc y argv que contienen la cantidad de argumentos de consola y los argumentos mismos respectivamente. Con eso podríamos programar una recepción de argumentos usando esas dos variables. Pero, con tantos años que llevamos programando… ¿no se le habrá ocurrido a alguien una forma estándar de hacer eso mismo para no andar reinventando la rueda?

Boost

Boost es un conjunto de bibliotecas para C++ que abordan una cantidad inmensa de áreas, desde álgebra lineal hasta expresiones regulares, pasando por procesamiento de imágenes y multithreading [1][2]. No voy a entrar en detalles de todo lo que puede hacer Boost, ya que no lo sé y estaría vacuneando [3] si les inventara. Me voy a enfocar en este asunto particular de hacer un programa con opciones usando un módulo de Boost.

Primero hay que instalar Boost. Para eso, lo más sencillo es instalarlo como un paquete de consola. En Fedora, es llegar y correr lo siguiente:

sudo yum install boost-devel

De Boost nos interesa usar el módulo Program Options, que nos deja, valga la redun-dun-dancia, añadirle opciones a nuestros programas.

A codear

Para incluir el módulo en nuestro programa de C++, escribimos:

#include <boost/program_options.hpp>

Y declaramos nuestro espacio de nombres en una variable, para que sea más fácil de localizar:

namespace po = boost::program_options;

Ya dentro del código, generamos un objeto de tipo options_description, que guardará la información de nuestras opciones, los valores que reciben y sus descripciones.

po::options_description desc("Nuestras fabulosas opciones de programa");

Luego, con add_options vamos registrando las opciones que se van a ejecutar. Cada nombre de la opción luego será llamable en la consola de la forma –nombre. Para este ejemplo usaremos una instrucción –help que mostrará los comandos, otra instrucción –name que recibirá un nombre como string y una instrucción –age que recibirá un entero, para ejemplificar los tipos de datos.

desc.add_options()
    ("help", "Imprime este mensaje de ayuda.")
    ("name", po::value<string>(), "Un nombre como string.")
    ("age", po::value<int>(), "Una edad como entero.");

Cuando leamos las instrucciones de consola, se generará un objeto variables_map que consistirá en pares clave–>valor. Con store guardamos lo que se lee desde consola mediante parse_command_line usando la descripción en el mapa de variables. En caso de que tengamos una función que se desencadene ante la presencia de una cierta opción, usamos notify para ejecutarla.

po::variables_map vm;
po::store(po::parse_command_line(argc, argv, desc), vm);
po::notify(vm);

Para verificar si una opción fue ingresada (y posiblemente, acceder a su valor si es que tiene) usamos la instrucción count con el nombre que le asignamos a la opción. Por ejemplo, para ver si se ingresó la opción –help y mostrar el mensaje de descripción de las opciones, usamos lo siguiente:

if vm.count("help")
    cout << desc << endl;

Si recibimos algún valor junto a las opciones, llamamos al mapa de variables mediante el nombre de la opción y especificamos el tipo de variable que esperamos recibir. Por ejemplo, para recibir el nombre sería algo como:

cout << vm["name"].as<string>() << endl;

Ahora, para juntar todo, aquí hay un código que recibe la instrucción –help para mostrar la lista de opciones, o las opciones –name o –age para leer una string o un int respectivamente:

#include <string>
#include <iostream>
#include <boost/program_options.hpp>

using namespace std;
namespace po = boost::program_options;

int main( int argc, char** argv )	{
  po::options_description desc("Nuestras fabulosas opciones de programa");

  desc.add_options()
    ("help", "Imprime este mensaje de ayuda.")
    ("name", po::value<string>(), "Un nombre como string.")
    ("age", po::value<int>(), "Una edad como entero.");

  po::variables_map vm;
  po::store(po::parse_command_line(argc, argv, desc), vm);
  po::notify(vm);

  if(vm.count("help"))
    cout << desc << endl;
  else{
    if(vm.count("name")){
      cout << "Nombre ingresado: " << vm["name"].as<string>() << endl;
    }
    if(vm.count("age")){
      cout << "Edad ingresada: " << vm["age"].as<int>() << endl;
    }
  }
}

Compilé el programa como “test” y al correrlo con distintas opciones obtuve los siguientes resultados:

[bruno@marelle build]$ ./test --help
Nuestras fabulosas opciones de programa:
  --help                Imprime este mensaje de ayuda.
  --name arg            Un nombre como string.
  --age arg             Una edad como entero.

[bruno@marelle build]$ ./test --name Brunaldo
Nombre ingresado: Brunaldo
[bruno@marelle build]$ ./test --name Brunaldo --age 23
Nombre ingresado: Brunaldo
Edad ingresada: 23
[bruno@marelle build]$ ./test --age 23
Edad ingresada: 23

Este es un código bastante simple. Si quieren agregar más detalles, como bloques try/catch, pueden ver el tutorial oficial en [4]. (Eso suena coqueto)

Para compilar

Para compilar el código anterior, hay que linkear el módulo que usamos de Boost. Para eso usan la opción -lboost_program_options con su compilador regalón.

c++ ../src/test.cpp -lboost_program_options

Si les gusta compilar con CMake, pueden agregar lo siguiente a su archivo CMakeLists.txt:

include_directories(${Boost_INCLUDE_DIR})
find_package(
    Boost 1.40
    COMPONENTS
	program_options
    REQUIRED)
add_executable(
    test
    src/test.cpp)
target_link_libraries(
    test
    ${Boost_LIBRARIES})

En vez de ${Boost_LIBRARIES} pueden usar ${Boost_PROGRAM_OPTIONS_LIBRARY} para linkear este módulo en específico, pero así se aseguran de poder linkear cualquier otro módulo de Boost que le vayan a agregar a su programa.

Hasta aquí llega el tutorial. Ahora, a programar, carajo.

Referencias

  1. Boost en Wikipedia: https://en.wikipedia.org/wiki/Boost_%28C%2B%2B_libraries%29
  2. Sitio de Boost: http://www.boost.org/
  3. Vacuna: http://www.mainframe.cl/diccionario/diccionario.php?palabra=vacuna&accion=Buscar
  4. Tutorial oficial de boost::program_options: http://theboostcpplibraries.com/boost.program_options

Empezando a aprender japonés

"Japan", Mariusz Kluzniak, Algunos derechos reservados
“Japan”, Mariusz Kluzniak, Algunos derechos reservados

Allá por los años del liceo (por lo bajo, hace más de seis años) tuve ganas de comenzar a aprender japonés. Por años me ha gustado la animación japonesa y la cultura japonesa clásica (la de samurais, grandes campos y caligrafía con pincel, no esa que vende almohadas con forma de abrazo) y quise aprender el idioma, pese a lo desafiante que parece.

Aprender una lengua asiática, en un primer vistazo, puede parecer una cosa tremendamente intimidante principalmente por la forma diferente de escritura. Aprender lenguas occidentales se ve como algo mucho más atractivo porque usamos las mismas letras y las gramáticas son similares. Pero cuando uno cruza esa barrera y empieza a aprender el idioma, se da cuenta de que no es algo inalcanzable (por algo ellos mismos lo usan) y empieza a ver la belleza detrás del asunto.

Aclaro algo: no sé japonés. Estudié durante un tiempo la gramática del idioma y me aprendí como 100 kanjis, pero la ausencia de personas con las que practicar y la misma procrastinación personal me dejaron con esa aventura a medias. Ahora me decidí a retomarla. No sé si llegue al nivel de poder usar el idioma, pero por lo menos será un ejercicio mental provechoso. Ahora comento algunas referencias que estoy tomando como punto de partida.

Gramática

Captura de pantalla de 2015-08-16 16:21:11 La gramática japonesa es muy distinta de las gramáticas occidentales, aunque no por eso más difícil. Implica el aprender a ordenar las ideas de una forma distinta y quizás a entender más información dependiendo del contexto. Mi punto de partida, cuando por primera vez me acerqué al japonés fue un libro que creo haber encontrado buscando en el Ares (sí, soy de esa época y de esa generación que descargaba las canciones de a una). El libro se titula “Nociones básicas sobre el idioma japonés” y fue escrito por Juan Manuel Cardona Granada, de la Universidad Nacional de Colombia, con el fin de tener una guía de referencia en español sobre el idioma. Fue con el libro que partí y del que aprendí la estructura de la gramática japonesa. Además es el libro que volveré a leer para empezar de nuevo a aprender. Lo recomiendo mucho, ya que es muy claro en sus explicaciones y además es libre de descarga.

Pueden encontrarlo aquí: http://www.etnassoft.com/biblioteca/nociones-basicas-sobre-el-idioma-japones/

Diccionario

Para aprender un nuevo idioma hacen falta diccionarios. Sin un buen diccionario, basta cualquier palabra desconocida para espantarnos y hacernos huir de vuelta a nuestra cueva. Como es difícil conseguir un diccionario de japonés en papel, lo más cómodo es tener uno en digital. Para eso yo instalé (en Linux) Kiten, un diccionario japonés-inglés, inglés-japonés, (algo en español es difícil de encontrar) que es muy cómodo de usar y se puede instalar directamente desde el gestor de software del sistema (la aplicación es completamente libre).

Captura de pantalla de 2015-08-16 15:55:14Kiten nos permite encontrar definiciones en japonés de palabras escritas en inglés, o definiciones de palabras escritas en japonés (un poco más abajo sobre la escritura) en inglés. Además tiene un buscador muy completo de Kanjis organizado por niveles y cantidad de trazos. También tiene un buscador por radicales (pequeñas partes de un Kanji) que es ideal para quien aprende de libros como “Remembering the Kanji”.

Escritura

Otra cosa importante es el cómo escribir en japonés. Escribir a lápiz es una cosa de práctica y disciplina, pero escribir en el computador requiere herramientas adicionales.

Cuando tenemos un teclado basado en letras latinas, necesitamos una aplicación especial que nos deje escribir de manera asistida en un idioma con caracteres distintos. Este tipo de programas se llaman IME, por Input Method Editor. En Linux existe la posibilidad de habilitar la entrada de texto en japonés fácilmente yendo a las configuraciones de Región e Idioma. Aquí podemos añadir en Fuente de Entrada, cliqueando en el “+”, la compatibilidad con el japonés. Al seleccionar Japonés saldrá una lista con varias opciones; la opción que uso yo es Kana Kanji.

Captura de pantalla de 2015-08-16 16:48:44Esto habilitará la opción para seleccionar el tipo de entrada que queremos al escribir. Cuando activamos Japonés (Kana Kanji), al escribir las vocales, irán apareciendo sus equivalentes en Hiragana, y mientras escribimos, se irán convirtiendo en sílabas e ideogramas cuando corresponda.

Captura de pantalla de 2015-08-16 16:53:17Cuando exista más de una posibilidad de escritura de lo que hemos tipeado, podemos presionar Abajo y se mostrará la lista de las alternativas. Presionamos Enter y seguimos escribiendo.

Captura de pantalla de 2015-08-16 16:57:19Además de escribir japonés en el computador, quizás nos gustaría escribir japonés en el teléfono. Para eso, podemos instalar el teclado estándar de japonés para Android que nos sirve en cualquier aplicación de texto: https://play.google.com/store/apps/details?id=com.google.android.inputmethod.japanese

Al momento de escribir en cualquier aplicación, plegamos el menú de arriba y en la opción “Seleccionar método de entrada” cambiamos nuestra aplicación estándar por “Japanese – Entrada de japonés de Google” y nuestro teclado cambiará a este, organizado por grupos de sílabas. Para escribir una sílaba, basta tocar un botón y arrastrar en dirección de la variante particular (Por ejemplo, para escribir き(KI), presiono en か(KA) y arrastro hacia la izquierda. Para escribir か, presiono y suelto.) Acá hay un par de capturas del teclado para Android:

teclado teclado-japonésAprender a escribir Kanji

Aprender a escribir Kanji es una de las partes más desafiantes del idioma dada la cantidad de caracteres que lo componen. También es una de las partes más bellas del mismo, porque en ella se puede sentir la evolución de siglos de un idioma completamente distinto a los occidentales (¿y quién puede negar que esa caligrafía es hermosísima?). No tengo una clave para aprender a escribir Kanji de la mejor manera, pero por mi experiencia los libros “Kanji para Recordar” de James W. Heisig ayudan de gran manera por su forma mnemotécnica de explicar las partes de cada Kanji haciendo que sean recordables fácilmente. Captura de pantalla de 2015-08-16 17:09:28

El libro parte explicando los componentes básicos, el orden de los trazos, y luego va incrementando en complejidad aprovechándose de los elementos ya explicados para ir creando historias asociadas al concepto que cada símbolo representa. En los tomos siguientes del libro, se van enseñando las distintas lecturas de cada Kanji.

Generalidades del Idioma

Para quien esté algo perdido entre los términos que he usado arriba, explicaré un poco (dentro de lo poco que sé) sobre el idioma japonés como tal. El japonés (o NIHONGO, 日本語), es el idioma que se habla en las distintas islas de Japón. Gramaticalmente está compuesto de un orden tipo SUJETO-OBJETO-VERBO, a diferencia de las lenguas occidentales que son a grandes rasgos SUJETO-VERBO-OBJETO (llámese SUJETO-PREDICADO). Un ejemplo de una oración básica en japonés sería:

私は林檎を食べます。

WATASHI WA RINGO WO TABEMASU.

WATASHI WA: En cuanto a mí

RINGO WO: A la manzana

TABEMASU: Como

Por cierto, lo de las mayúsculas no es porque yo esté gritando. Es común ver que en los textos se “romanice” el japonés en mayúsculas. La escritura del japonés se basa en sílabas. No existen consonantes sueltas, a excepción de la N, por lo que para escribir una palabra no japonesa en japonés, se hacen ciertos arreglos. Por ejemplo, mi nombre, Bruno, se escribiría BURUNO (ブルノ). Existen dos silabarios principales: el Hiragana (ひらがな) y el Katakana (カタカナ). El Hiragana se utiliza dentro del idioma japonés para escribir palabras completas, partículas o sufijos, mientras que el Katakana se usa generalmente para escribir palabras extranjeras dentro del idioma.

El Kanji (漢字), es el método de escritura adoptado por Japón de los chinos, ya que el idioma japonés sólo existía de manera hablada. La escritura japonesa principalmente mezcla Kanjis para las raices de las palabras (son ideogramas en su mayoría) y Hiragana para las terminaciones verbales, partículas, entre otros elementos del idioma.

Todos estos temas se explican con mayor claridad en el libro mencionado más arriba por si quieren seguir profundizando.

Espero que este artículo sirva de ayuda a cualquier persona que quiera comenzar el estudio del japonés como idioma o que al menos quiera tener un par de datos freak con los que sorprender en las conversaciones. Al menos a mí me servirá para recordarme que tengo que seguir aprendiendo.

[Anime] Mushishi

Siento que con el tiempo he dejado de ver tanto anime como antes. No quiero sonar como viejo con esa actitud de “en mis tiempos las cosas eran mejores”, pero en las series nuevas me cuesta encontrar ese “algo” que me hace vibrar al verla, y que convierte una serie en una experiencia, un viaje, que se arraiga bien profundo dentro de uno. Con Mushishi encontré eso. Y que mejor palabra que un “viaje” para describir esta serie que nos pone a acompañar a Ginko, un experto en Mushi, en su travesía.

vlcsnap-2015-08-10-22h09m06s261La palabra Mushi en japonés puede traducirse como “bicho” o “insecto”, aunque aquí no se refiere a ninguno de los dos. El Mushi es una forma alterna de vida, que no puede ser descrita como planta o como animal, está mucho más abajo en el árbol de la vida, incluso más allá de los hongos, de las bacterias, muy cerca del origen de la “Vitalidad” o la vida como energía en su estado más puro. Los Mushi no son por definición buenos o malos, simplemente son una forma alterna de vida que se ha ido desarrollando oculta a los ojos de la mayoría de las personas. Existen distintas variedades, pues al igual que la vida celular, los Mushi han pasado por millones de años de evolución, produciendo criaturas tan diversas como Mushi pequeños que se alimentan de sonido u otros que se extienden por la superficie de algunas montañas casi como si fueran un tejido nervioso que vive en simbiosis con ellas.

vlcsnap-2015-08-03-22h08m20s031

Los Mushi sólo pueden ser vistos por algunas personas, y entre ellos, algunos toman como profesión el estudio de los Mushi. Estos “expertos en Mushi” son los Mushishi, que conocen las propiedades y comportamientos de una gran cantidad de Mushi, de las que han aprendido por tradición, viajes, textos antiguos, y en general, lo que se espera de un Japón rural cercano al periodo Edo.

La historia nos pone al lado de Ginko, un viajero en este Japón a la antigua, que va de pueblo en pueblo ayudando a la gente en distintas situaciones paranormales causadas por los Mushi. A diferencia de los habitantes de los pueblos, Ginko va vistiendo ropas que tienen un aire occidental, lo que refuerza su apariencia de forastero, de haber recorrido grandes distancias y haber visto cosas que uno no alcanza a imaginar. Poco a poco se van descubriendo aspectos de su personalidad, que van explicándolo y acercándonos a sus motivos.

vlcsnap-2015-08-10-22h11m10s454

El viaje de Ginko pasa en cada capítulo de la serie por una historia distinta, un lugar nuevo, un tipo peculiar de Mushi y vidas que se han visto afectadas por ellos. Uno podría pensar que este esquema se vuelve repetitivo, pero cada historia termina por volverse única, tanto así que cada capítulo podría verse sin ver los anteriores y disfrutarse con la misma intensidad. Al menos a mí me pasa que me debato entre las ganas de seguir viendo otro capítulo al terminar uno, o de quedarme un momento, tranquilo, “digiriendo” las sensaciones que me quedan de lo que acabo de ver. Y es de verdad que quedan sensaciones profundas después de cada capítulo, porque no son las típicas historias en las que alguien tiene un problema, llega el protagonista, lo soluciona, y todos se despiden de él felices mientras él se aleja hacia el atardecer y suena el ending. No, en Mushishi nos encontramos con un tipo de historias delicadas, en las que puede o no haber una solución alcanzable, donde el problema no es causado por la maldad del Mushi o de las personas, sino que emerge simplemente de la interacción entre formas de vida distintas que a veces pueden ser afines mientras que otras veces pueden ser conflictivas. Es como si la naturaleza de los conflictos fuera más ecológica que moral, y esa es una cosa que se agradece en el anime, especialmente con la gran cantidad de historias en las que casi nos dicen con flechitas “éste es el malo” y “éste es el bueno” y se alejan así de la realidad.

vlcsnap-2015-08-10-22h02m31s821Una de las cosas que me encantó de Mushishi es el ritmo narrativo. La serie inicia con una canción que de por sí es una referencia a un viaje, y nos pone en un ambiente muy cercano a la naturaleza, como si nos invitara a sentarnos alrededor de una fogata porque alguien nos va a contar la historia de sus viajes. Cada historia se narra de acuerdo a como la historia deba ser contada; a veces es Ginko quien tiene el foco principal, mientras que otras veces es algún personaje el que describe lo que pasa. Poco a poco vamos entrando en la historia y además en el ambiente, gracias a que se ocupan muchos cuadros en la tarea de mostrarnos el lugar en el que se desarrolla cada historia. Pueden estar dos personajes hablando, pero la imagen pasa por ellos y por los alrededores de una manera que nos va haciendo sentirnos ahí. Se aprovecha muy bien el silencio para esto mismo. Me atrevería a decir que hay más sonidos de ambiente que música, lo que produce ese entorno de tranquilidad, de atención, hasta de solemnidad. Y así se va desarrollando la historia hasta llegar al final, lo que también es una parte magistral del ritmo narrativo. La historia cierra con suavidad, cada capítulo se termina en su propio ending, que parece ser una proyección de la misma historia. Es como si nos diera un momento para quedarnos en silencio y asimilar lo que acabamos de ver, de convertirlo en una experiencia. Todo el capítulo termina por fluir de una forma cohesionada desde principio a fin, en unidad.

No pretendo ahondar más en la historia de Mushishi. Sólo dejo una invitación a ver la serie y a escuchar las historias que nos cuenta. Y que ojalá se queden con algo, bien adentro, con esa sensación de experiencias nuevas que a mí tanto me gusta.

La serie consta de 26 capítulos, además de varios OVAs, una segunda temporada y un Live Action, así que hay bastante material para disfrutar.

Robot, pórtate bien: Las Leyes de la Robótica

Buscando cosas fantabulosas en StumbleUpon, me encontré con un artículo [1] que menciona las Leyes de la Robótica de Tilden. Yo estaba familiarizado con las Leyes de la Robótica de Asimov, del que me declaro admirador, que han sido popularizadas por distintas obras de ciencia ficción y han pasado a ser un referente al hablar de robots. Estas leyes de Asimov funcionan estableciendo un cierto resguardo para guiar el comportamiento de robots inteligentes y lograr que no dañen a los humanos.

Varias veces me he puesto a darle vueltas al asunto de sobre qué implicancias tiene el definir estas reglas para los robots, y de cómo podría ser realizable la implantación de ellas. Por ejemplo, las leyes asimovianas se enfocan en el aspecto social del robot (la relación humano-robot) y en cómo se establece una jerarquía de relaciones de poder (humano > robot), mientras que las leyes de Tilden se enfocan principalmente en ver al robot como un organismo autónomo. Por eso, escribo este artículo para explorar ideas sobre cómo plantear reglas fundamentales para regir el comportamiento de un robot.

Lo primero, ¿qué es un robot?

La palabra “robot” se hizo conocida en 1920, en la obra R.U.R. de Karel Čapek [2]. Proviene del checo “robota” que significa “labor forzada” y hacía referencia a una forma de esclavitud, de trabajo obligado. En la actualidad vemos que los robots ya se han vuelto comunes como un elemento cultural de la automatización industrial, de la ciencia ficción e incluso del ambiente doméstico con varios proyectos que ya se están haciendo parte de los hogares. Aún así, pese a la masificación del concepto, no existe una definición estricta de sobre qué es un robot ni sobre qué elementos lo componen. Generalmente uno asocia el término a máquinas humanoides con una voz que pareciera venir rebotando desde dentro de un tarro, pero también se puede considerar como robots a programas de software capaces de funcionar de manera autónoma (por ejemplo, bots de conversación como cleverbot [3], o inteligencias artificiales de videojuegos), o más comunmente a máquinas no humanoides que realicen tareas de manera autónoma o semi-autónoma (un gran ejemplo de esto son los robots Kiva, altamente usados en las bodegas de Amazon para organizar sus productos más rápidamente [4]). Pese a las ambigüedades que aún existen para definir el concepto, podemos estar de acuerdo en que los robots son máquinas con un cierto de autonomía capaces de desempeñar ciertas labores.

Máquinas inteligentes

La autonomía de un robot no implica que sea una máquina inteligente, así como la inteligencia artificial no implica la existencia de inteligencia. Sobre esto último quizás me extienda en otra ocasión (la IA es una de las áreas que me apasionan) pero por ahora me limito a mencionar que la inteligencia artificial es, a grandes rasgos, la automatización de comportamientos “racionales”, es decir, lograr que la máquina entregue el resultado que entregaría un humano. Cuando hablamos de una máquina inteligente, en cambio, y nos mantenemos al margen del concepto de “artificial”, llegamos a la idea de sobre qué pasaría si las máquinas alcanzaran la verdadera inteligencia (otro tema que no tiene una definición absoluta). La inteligencia dotaría a la máquina de una autonomía mayor que la estructura dada por su programa o por su construcción, y la dotaría de elementos como la imaginación, la memoria no estructurada, y un aprendizaje similar al aprendizaje humano, capaz de adquirir conocimientos y habilidades en todo tipo de disciplinas. Esto ha sido tema de estudio durante muchos años y Alan Turing propuso un test con el que considerar a una máquina como inteligente. Este test se basa en la idea de que si un juez no puede distinguir a una máquina de un humano, la máquina se considera inteligente. Pero este test se enfoca en el aspecto conductual de la inteligencia, en cómo esta se exterioriza. Incluso ya hay un software que pasó el test de Turing [5]. Lo que no considera este planteamiento es el aspecto interno de la inteligencia, como los motivos o la consciencia.

Robótica Asimoviana

Isaac Asimov [6], gran escritor y científico que vivió entre 1920 y 1992, abordó estos últimos temas en su literatura de ciencia ficción y se volvió uno de los mayores referentes del género. En sus libros como “Yo Robot”, “Sueños de Robot” y “Visiones de Robot” se presenta a los robots como máquinas de mayor complejidad a la actual, capaces de ayudar a los humanos en labores diarias, e inteligentes hasta un cierto grado. Incluso existen robots que no se distinguen de un humano normal o robots que terminan convirtiéndose en uno (como en el cuento “El Hombre Bicentenario”. Sí, el cuento vino antes que la película). Todas estas capacidades se sustentan en la existencia de un “cerebro positrónico”, que es capaz de funcionar de manera análoga al cerebro humano y darles capacidades equivalentes o incluso superiores. Pero en estas obras, el ser humano, para no ser superado por su creación en un nivel de especie (porque es superado en varias capacidades), diseña reglas que pongan al robot, por definición, al servicio del hombre. Así nacen las leyes de la robótica clásicas de la literatura de Asimov:

  1. Un robot no debe dañar a un ser humano o, por su inacción, dejar que un ser humano sufra daño.
  2. Un robot debe obedecer las órdenes que le son dadas por un ser humano, excepto cuando estas órdenes están en oposición con la primera Ley.
  3. Un robot debe proteger su propia existencia, hasta donde esta protección no esté en conflicto con la primera o segunda Leyes.

En muchísimas obras de ciencia ficción se mencionan estas leyes como la base del comportamiento robótico (como por ejemplo, Eve no Jikan [7]), pese a que Asimov en sus mismos cuentos buscaba situaciones en las que estas leyes pudieran ser llevadas a contradicciones. De estas mismas contradicciones aparece una nueva ley, la llamada “Ley Cero” (o Zeroth):

  1. Ninguna máquina puede dañar a la Humanidad; o, por inacción, dejar que la Humanidad sufra daño.

En los mismos relatos de Asimov (se recomienda leer algún relato del Ciclo de Trántor [8]) se describe cómo estas leyes motivan a las máquinas a dedicarse durante miles de años a contribuir al desarrollo de la humanidad como especie, incluso contribuyendo en política y en el desarrollo económico.

Pero todo esto lleva a ciertas preguntas técnicas cuando uno piensa en llevar estas leyes a la práctica. ¿Cómo podemos implementar las leyes de la robótica de Asimov en robots reales? Asimov habla de un cerebro positrónico, pero ¿qué debe poder hacer este cerebro positrónico? Partiendo de la Ley 1, el robot debe ser capaz de entender lo que es un humano. Esto implica más que el solo hecho de “reconocer un humano” como se podría hacer con algoritmos de Visión Computacional y Aprendizaje de Máquina. Porque se habla de dañar a un humano, el robot debe entender al ser humano como un organismo vivo, conocer sus propiedades, sus reacciones, sus características físicas y psicológicas. Todo esto implica un tipo de máquina diferente a las que tenemos ahora, mucho más compleja y con un “cerebro” mucho más orgánico, capaz de razonamientos de nivel superior.

Quizás para llegar a ese nivel de razonamiento en las máquinas, debemos diseñarlas de tal forma en que puedan crecer como organismos naturales e ir incrementando en complejidad como un resultado emergente de su interacción con las personas, otras máquinas y el entorno. Aquí es donde es adecuado mencionar las leyes de Tilden.

Las leyes de Tilden (no de Tinder, de Tilden)

 Mark Tilden [9] es uno de los grandes robotistas modernos, famoso por su planteamiento de los robots BEAM. La robótica BEAM [10] (Biology, Electronics, Aesthetics and Mechanics) plantea un diseño de robots mucho más simple que los robots convencionales. Estos robots tienen una mayor tendencia a ser construidos con circuitos analógicos en vez de digitales, lo que muchas veces conlleva la ausencia de microprocesadores. La principal idea de estos robots es que se parezcan mucho más a organismos vivos en vez de a máquinas programables. Siguen siendo máquinas, pero con la ventaja de que pueden reaccionar de una forma mucho más natural a su entorno.

Mark Tilden
Mark Tilden

La idea de la robótica de Tilden es reducir el comportamiento de un robot a sus componentes esenciales, y como este planteamiento es distinto en complejidad de las leyes de Asimov, él planteó su propio conjunto de leyes:

  1. Un robot debe proteger su existencia bajo todo costo.
  2. Un robot debe obtener y mantener acceso a su propia fuente de alimentación.
  3. Un robot debe buscar continuamente mejores fuentes de alimentación.

Se puede ver en estas leyes que el planteamiento es mucho más sencillo en cuanto a costos y a los requerimientos de estas máquinas (en parte, lo que Tilden andaba buscando), lo que las hace mucho más fáciles de implementar en la práctica. A diferencia de las leyes de Asimov, son leyes mucho más “realizables” y abren toda una rama de estudio que ve la robótica de una forma distinta. A la vez, estas leyes plantean al robot de una manera muy similar a los organismos vivos, lo que implica que podrían, hasta un cierto grado, desarrollarse como tales y producir resultados nuevos que no podríamos haber imaginado.

Pero a fines prácticos, la robótica es la creación de herramientas autónomas, y para regularla como tal es que la EPRSC estableció algunos principios sobre los que se debe guiar su desarrollo comercial.

Regulando los robots de ahora

El año 2010, el Engineering and Physical Sciences Research Council (Consejo de Investigación en Ingeniería y Ciencias Físicas) en un conjunto con el Arts and Humanities Research Council (Consejo de Investigación en Artes y Humanidades), ambas instituciones de Reino Unido, desarrollaron un evento en conjunto con el fin de establecer ciertos principios para guiar la investigación en robótica, de manera que esta se pueda integrar en la sociedad para el máximo beneficio de los ciudadanos [11]. Estas leyes se inspiran en las leyes de la robótica de Asimov en el sentido de proteger al ser humano, aunque como se dice en la declaración de principios, estas leyes difícilmente son llevables a la práctica en la vida real ya que un robot no puede conocer todas las formas en las que un ser humano puede ser dañado. Estos principios plantean que la responsabilidad en la robótica cae sobre los humanos que los crean y que, en consecuencia, determinan el funcionamiento de la máquina.

Los principios obtenidos en la reunión de estas dos organizaciones se cristalizan en cinco reglas éticas para la construcción de robots. En sus palabras: “Las cinco reglas éticas de la robótica se consideran como un documento vivo. No se espera que se consideren como leyes rígidas, sino como un instrumento para informar las discusiones y para referencia futura”.

  1. Los Robots son herramientas multiuso. Los robots no deben ser diseñados única o principalmente para matar o dañar humanos, a excepción de casos de seguridad nacional.
  2. Los Humanos, no los Robots, son agentes responsables. Los Robots deben ser diseñados y operados dentro de las leyes existentes y los derechos y libertades fundamentales, incluyendo la privacidad.
  3. Los Robots son productos. Deben ser diseñados usando procesos que aseguren su seguridad.
  4. Los Robots son artefactos fabricados. No deben ser diseñados de una manera engañosa que pueda confundir a usuarios vulnerables; su naturaleza de máquina debe ser transparente.
  5. Siempre debe ser identificable la persona con la responsabilidad legal por un Robot.

Estos principios sirven como una base para la legislación sobre robótica, para guiar un desarrollo de la industria de una manera que asegure el beneficio de la ciudadanía. Como un complemento, se adjuntan siete “mensajes de alto nivel” para motivar la responsabilidad en la industria y la investigación en robótica.

  1. Creemos que los robots tienen el potencial de causar un impacto inmensamente positivo en la sociedad. Queremos motivar la investigación responsable en robótica.
  2. Las malas prácticas nos afectan a todos.
  3. Enfrentar las preocupaciones del público nos ayudará a progresar.
  4. Es importante demostrar que nosotros, como robotistas, estamos comprometidos con los mejores estándares de las prácticas.
  5. Para entender el contexto y las consecuencias de nuestras investigaciones, debemos trabajar con expertos de otras disciplinas incluyendo: ciencias sociales, leyes, filosofía y artes.
  6. Debemos considerar la ética sobre la transparencia: hay límites a lo que debe estar abiertamente disponible.
  7. Cuando vemos informaciones erróneas en la prensa, debemos tomar el tiempo para contactar a los periodistas responsables.

Así como para ir cerrando

Si me preguntan con cual de estas leyes me quedo, me pongo el sombrero y me voy enojado (no uso sombrero, es sólo una metáfora). Cada una de estas leyes se planteó en un contexto puntual que quería ser abordado. Las leyes de Asimov nacen en el contexto de la robótica de su ciencia ficción y deben siempre primero considerarse en ese contexto; para eso es recomendable además de conocer esas leyes, leer su literatura, no se van a arrepentir. Ponen una base de sobre cómo deben comportarse los robots con respecto a los humanos, y los plantea como herramientas que pueden ayudarnos a crecer como sociedad. Pero aún hay muchas tareas que los robots estándar que están siendo desarrollados aún no son capaces de abordar. Tilden nos abre todo un planteamiento distinto que se vale de varias disciplinas para conceptualizar a los robots como entes dinámicos capaces de desarrollarse de manera similar a los organismos vivos. Nos ayuda un poco a abrir la mente sobre cómo podemos plantear los problemas que queremos solucionar con máquinas y a la vez hace la bella tarea de integrar varias disciplinas en la discusión. Esto último se considera en las leyes propuestas por EPSRC / AHRC, que se encargan de plantear principios acordes a la robótica moderna como industria que se está integrando de gran manera en la sociedad.

Todos estos planteamientos contribuyen a que nos preguntemos cómo queremos que se desarrolle la robótica de aquí hacia al futuro. Quizás aún faltan leyes que plantear, cosa casi segura, y por eso las discusiones deben seguir abiertas y deben considerar desde el ingeniero más especializado en control hasta los niños que se crían con películas de ciencia ficción que les dan una perspectiva confusa de la robótica real, para que así podamos todos ser beneficiados por el desarrollo tecnológico y por estas criaturitas tan fabulosas.

¿Cierto que son adorables? ¿Sí? (Fuente de la imagen: http://www.notimerica.com/sociedad/noticia-nao-robot-poliglota-sera-nuevo-trabajador-bancos-tokio-2020-20150203145049.html)
¿Cierto que son adorables? ¿Sí? (Fuente de la imagen: http://www.notimerica.com/sociedad/noticia-nao-robot-poliglota-sera-nuevo-trabajador-bancos-tokio-2020-20150203145049.html)

Y bueno, ya que llegaron leyendo hasta aquí… ¿se les ocurre alguna ley que agregar? Súmense a la discusión 😉

Referencias

  1. Tilden’s Laws of Robotics: https://en.wikipedia.org/wiki/Tilden%27s_Laws_of_Robotics
  2. Origen de la palabra robot: http://www.xatakaciencia.com/robotica/el-origen-de-la-palabra-robot
  3. Cleverbot: http://www.cleverbot.com/
  4. CNET News – Meet the robots making Amazon even faster: https://www.youtube.com/watch?v=UtBa9yVZBJM
  5. ABC.es Ciencia – Un ordenador pasa por primera vez el test de Turing y convence a los jueces de que es humano http://www.abc.es/ciencia/20140609/abci-superordenador-supera-primera-test-201406091139.html
  6. Isaac Asimov – Divulgación científica y ciencia ficción: http://www.asimov.es/
  7. Eve no Jikan: http://myanimelist.net/anime/3167/Eve_no_Jikan
  8. Ciclo de Trántor: https://es.wikipedia.org/wiki/Saga_de_la_Fundaci%C3%B3n
  9. The Evolution of a Roboticist: http://www.botmag.com/the-evolution-of-a-roboticist-mark-tilden/
  10. Robótica BEAM: https://es.wikipedia.org/wiki/Rob%C3%B3tica_BEAM
  11. EPSRC Principles of Robotics: https://www.epsrc.ac.uk/research/ourportfolio/themes/engineering/activities/principlesofrobotics/

Entrando a picar más profundo en ROS

Si leyeron el artículo anterior, quizás les dieron ganas de profundizar más en ROS. Como el tutorial anterior era una introducción, no entré en tantos detalles. Ahora pretendo explicar más sobre los elementos fundamentales a entender cuando se trabaja con ROS.

Dentro de ROS existen ciertos conceptos clave que entender y algunas aplicaciones asociadas a estos elementos que nos harán la vida más sabrosa al trabajar. Dentro de esos elementos están los nodos, los tópicos, los servicios, los mensajes, el servidor de parámetros, y otros más. Más abajo iré explicándolos paso a paso y escribiendo las referencias oficiales de cada tema.

Logo ROS

ROS como un sistema distribuido

Como mencioné en el otro artículo, ROS es un framework distribuido. Su idea principal es que los robots son sistemas en los que una falla en un componente no debe dañar el funcionamiento de la máquina completa. Para esto, se pensó para funcionar implementado en programas con funciones puntuales, los nodos, que se comunican entre sí para obtener el funcionamiento completo del robot. Análogo a lo que en otros sistemas distribuidos hace la labor de coordinar el trabajo global, como el namenode en Hadoop, en ROS existe una aplicación que coordina la ejecución de todos los otros nodos: el roscore.

Roscore

El roscore [1] es un conjunto de herramientas necesarias para hacer funcionar los demás nodos de ROS. Es la primera aplicación que se debe ejecutar para que el resto funcione. Esta aplicación se encarga de llamar al nodo Master [2], que se encarga de hacer que los nodos se puedan encontrar unos a otros y de gestionar las llamadas a tópicos y servicios. También se encarga de llamar al servidor de parámetros [3], que se utiliza para almacenar variables que deben estar disponibles para todos los nodos mediante APIs. Por último, roscore abre un nodo que sirve como la salida estándar de ROS para generar logs e impresiones por consola que se publican en el tópico “/rosout”, el nodo rosout [4].

Para lanzar el roscore, basta llamarlo desde la consola y quedará funcionando. La mayoría de las aplicaciones incluidas al instalar ROS dependen de que el roscore esté funcionando.

roscore
... logging to /home/bruno/.ros/log/1976e978-2e49-11e5-aa44-b803058568da/roslaunch-cronidea-2483.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is &lt;1GB.

started roslaunch server http://cronidea:51918/
ros_comm version 1.11.13

SUMMARY
========

PARAMETERS
 * /rosdistro: indigo
 * /rosversion: 1.11.13

NODES

auto-starting new master
process[master]: started with pid [2497]
ROS_MASTER_URI=http://cronidea:11311/

setting /run_id to 1976e978-2e49-11e5-aa44-b803058568da
process[rosout-1]: started with pid [2510]
started core service [/rosout]

También existe otra forma de ejecutar aplicaciones, que es mediante roslaunch. Al ejecutar roslaunch, se ejecutará un archivo .launch que especifica mediante una notación XML una serie de parámetros y nodos a lanzar. Al usar roslaunch, si no está corriendo el roscore, se ejecuta automáticamente antes de ejecutar los contenidos del archivo .launch.

ROS también puede ejecutarse usando varias máquinas, de las que sólo una estará corriendo el roscore. Pero como aún no he trabajado con ROS en varias máquinas, prefiero hablar de eso cuando tenga más experiencia.

Paquetes y Nodos

Como ya mencioné varias veces, ROS está pensado para funcionar con programas puntuales llamados nodos [5]. Los nodos se organizan en paquetes (packages [6]) que generalmente incluyen varios nodos de funciones similares o complementarias. Los paquetes también se puede organizar en stacks, pero eso ya es irse por las ramas para el alcance de este tutorial. Lo habitual es que el sistema de un robot utilice distintos nodos para ejecutar las tareas necesarias. Por ejemplo, un nodo puede encargarse de recibir imágenes de la cámara y publicarlas en un tópico particular, otro nodo puede leer las imágenes desde ese tópico y aplicar algún proceso de detección de objetos. Otro nodo puede leer los resultados de la detección de objetos y planificar una ruta, mientras que otro nodo leerá la ruta y aplicará los comandos de movimiento que seguirán esa ruta.

Para ejecutar un nodo, se llama la instrucción rosrun seguida del nombre del paquete y el nombre del nodo. Por ejemplo, cuando en el tutorial anterior se ejecutó el simulador de tortuga, se llamó:

rosrun turtlesim turtlesim_node

y se comenzó a ejecutar el simulador.

También se pueden pasar argumentos a los nodos que se ejecuten, por ejemplo en el nodo “image_view” del paquete “image_view” que se encarga de mostrar imágenes, se puede especificar el tópico en el que se están publicando las imágenes usando la forma:

rosrun image_view image_view image:=/camera/image

Rosnode

Rosnode [7] es una herramienta para obtener información de los nodos en ejecución. Imaginemos que está funcionando el nodo del simulador de tortuga. Si ejecutamos “rosnode list” podemos ver la lista de nodos en ejecución. En este caso mostraría:

/rosout
/turtlesim

(Nótese que el nombre con el que se registra un nodo no es necesariamente el mismo nombre con el que se ejecuta el nodo)

Ahora podemos usar “rosnode info turtlesim” y obtener información sobre los tópicos a los que publica el nodo, a los que está suscrito y los servicios que tiene abiertos.

--------------------------------------------------------------------------------
Node [/turtlesim]
Publications:
 * /turtle1/color_sensor [turtlesim/Color]
 * /rosout [rosgraph_msgs/Log]
 * /turtle1/pose [turtlesim/Pose]

Subscriptions:
 * /turtle1/cmd_vel [unknown type]

Services:
 * /turtle1/teleport_absolute
 * /turtlesim/get_loggers
 * /turtlesim/set_logger_level
 * /reset
 * /spawn
 * /clear
 * /turtle1/set_pen
 * /turtle1/teleport_relative
 * /kill

contacting node http://cronidea:36697/ ...
Pid: 8877
Connections:
 * topic: /rosout
    * to: /rosout
    * direction: outbound
    * transport: TCPROS

Existen otras opciones más con las que se puede usar rosnode. Para verlas todas, basta con escribir “rosnode” en la terminal.

Tópicos

Dentro de un robot (o una simulación), son muchos los datos que fluyen de manera constante. Imágenes, datos de acelerómetros, nubes de puntos, estados de motores, necesitan estar siendo publicados continuamente para que el sistema funcione en tiempo real. Especificar canales de comunicación cada vez que un nodo quiere enviarle datos de este tipo a otro nodo no sería eficiente por varias razones: habría que saber de antemano desde donde y hasta donde hay que enviar los datos, hay que controlar la sincronía de los envíos… Para evitar estos problemas, ROS posee una forma de comunicación del estilo Publish/Subscribe [9] en el que un elemento envía mensajes (los publica) y otro elemento recibe mensajes (se suscribe a ellos). En ROS esto se hace a través de tópicos [8]. Los tópicos son un medio de comunicación pensado en la transmisión asíncrona de mensajes. Todos los datos que tengan que ser publicados constantemente y estar disponibles para que otros nodos se publican a través de tópicos.

Los nodos son quienes abren y leen tópicos. Para poder leer o publicar en un tópico, el mensaje entregado tiene que tener un cierto tipo. Existen tipos predefinidos para comunicar distintos datos, como el “geometry_msgs/Twist” que es el mensaje estándar para comandos de movimiento, y también se pueden definir tipos de mensajes de acuerdo a las necesidades de la aplicación.

Rostopic

Rostopic [10] es la herramienta para interactuar con los tópicos de ROS. Tiene funciones similares a las de “rosnode” y otras que son propias de la naturaleza de los tópicos. Una de las funciones más comunes es “rostopic list” que nos muestra la lista de los tópicos abiertos. En este caso la ejecuté habiendo lanzado el simulador de tortuga y me mostró lo siguiente:

/rosout
/rosout_agg
/turtle1/cmd_vel
/turtle1/color_sensor
/turtle1/pose

“rostopic info” puede mostrar información de un tópico en particular, por ejemplo “rostopic info /turtle1/cmd_vel” muestra:

Type: geometry_msgs/Twist

Publishers: None

Subscribers:
 * /turtlesim (http://cronidea:49932/)

Como sabemos que el tópico cmd_vel de la tortuga recibe comandos del tipo geometry_msgs/Twist (también podríamos haberlo sabido llamando directamente a “rostopic type /turtle1/cmd_vel”), podemos publicar un mensaje en este tópico para que la tortuga se mueva. Para publicar un mensaje usamos “rostopic pub”.
Escribimos:

rostopic pub -1 /turtle1/cmd_vel geometry_msgs/Twist -- '[2.0, 0.0, 0.0]' '[0.0, 0.0, 1.8]'

y verificamos que la tortuga del simulador se movió en la dirección indicada.

Figura 1: Tortuga moviéndose luego de un mensaje publicado en /turtle1/cmd_vel
Figura 1: Tortuga moviéndose luego de un mensaje publicado en /turtle1/cmd_vel

Para monitorear los mensajes publicados en un tópico, podemos usar “rostopic echo”. Antes de enviar el mensaje al simulador de la tortuga, ejecuté “rostopic echo /turtle1/cmd_vel” en una terminal y me mostró esto:

linear:
  x: 2.0
  y: 0.0
  z: 0.0
angular:
  x: 0.0
  y: 0.0
  z: 1.8
---

Existen varias opciones más con las que se puede ejecutar rostopic. Para verlas todas basta con escribir “rostopic” en la consola.

Servicios

Existe otra forma de comunicación en la que sólo en ciertas ocasiones necesitamos que se ejecute un procedimiento o necesitamos que la llamada venga acompañada de una respuesta. Esto en ciertos contextos se llama Remote Procedure Call o RPC, que permite que procesos intercambien información de manera directa. En ROS esta forma de comunicación se lleva a cabo mediante los servicios.

Los servicios se definen mediante un nombre y dos tipos de servicio: uno de consulta y otro de respuesta.

Rosservice

Una de las formas en las que se puede llamar un servicio es mediante rosservice. Imaginemos que estamos corriendo el simulador de tortuga y que queremos añadir una tortuga más a la simulación. Si ejecutamos “rosservice list” podemos ver que hay un servicio “/spawn” abierto.

/clear
/kill
/reset
/rosout/get_loggers
/rosout/set_logger_level
/spawn
/turtle1/set_pen
/turtle1/teleport_absolute
/turtle1/teleport_relative
/turtlesim/get_loggers
/turtlesim/set_logger_level

Ejecutando “rosservice info /spawn” podemos ver información sobre este servicio:

Node: /turtlesim
URI: rosrpc://cronidea:59998
Type: turtlesim/Spawn
Args: x y theta name

Ahí se puede ver que este servicio requiere 4 argumentos para llamarse, así que para generar una nueva tortuga podemos escribir:

rosservice call /spawn 5 7 1.57 William

Y tendremos una nueva tortuga llamada William en la simulación.

Figura 2: William, “el musculoso”, ha entrado en escena

Ahora, si llamamos a “rosservice list” podemos ver que se han habilitado servicios nuevos:

/William/set_pen
/William/teleport_absolute
/William/teleport_relative
/clear
/kill
/reset
/rosout/get_loggers
/rosout/set_logger_level
/spawn
/turtle1/set_pen
/turtle1/teleport_absolute
/turtle1/teleport_relative
/turtlesim/get_loggers
/turtlesim/set_logger_level

Podemos llamar a uno de ellos para cambiar la posición de William.

rosservice call /William/teleport_absolute 1 1 2.5

Y William juntará su Ki y se teletransportará.

Figura 3: William teletransportado
Figura 3: William teletransportado (It’s over 9000!)

Para ver todas las opciones de rosservice hay que llamarlo en la terminal.

Servidor de Parámetros

El servidor de parámetros es un espacio común para almacenar variables para todos los nodos. Es gestionado por el Master. Para ejemplificar el uso del servidor de parámetros es conveniente usar ejemplos más avanzados, por lo que los detalles pueden quedar para otra ocasión. Un ejemplo a grandes rasgos puede ser el lanzar un robot en simulación. Un robot se puede especificar en un archivo .xacro que es una sintaxis simplificada del estándar .urdf. Un nodo puede procesar el archivo .xacro y generar el .urdf correspondiente. Este archivo quedará en el servidor de parámetros, desde donde un nodo puede enviarlo al simulador. Así mismo en el servidor de parámetros se pueden guardar valores como por ejemplo las constantes PID del controlador de un motor.

Rosparam

Rosparam [12] es la herramienta estándar para interactuar con el servidor de parámetros desde la línea de comandos. Si llamamos a “rosparam list” vemos todos los parámetros almacenados. Al abrir el roscore se muestra algo así:

/rosdistro
/roslaunch/uris/host_cronidea__36626
/rosversion
/run_id

Lo mismo que antes: si queremos ver todas las opciones, escribimos rosparam en la consola.

Para ir cerrando

Así como para ir terminando el tutorial, estos son los elementos principales con los que se desarrollan las aplicaciones de ROS. Cuando se quieren desarrollar aplicaciones nuevas, generalmente el proceso consiste en implementar un paquete y programar sus nodos usando las bibliotecas disponibles de ROS (hasta donde sé, lo más común es trabajar con C++ y Python). Espero que a alguien le sea de utilidad este paseo por los elementos principales y que se motive a seguir aprendiendo. En tal caso, yo me motivaré a hacer más tutoriales.

Referencias

  1. Roscore: http://wiki.ros.org/roscore
  2. ROS Master: http://wiki.ros.org/Master
  3. ROS Parameter Server: http://wiki.ros.org/Parameter%20Server
  4. Rosout: http://wiki.ros.org/rosout
  5. ROS Nodes: http://wiki.ros.org/Nodes
  6. ROS Packages: http://wiki.ros.org/rosbuild/Packages
  7. Rosnode: http://wiki.ros.org/rosnode
  8. ROS Topics: http://wiki.ros.org/Topics
  9. Publish Subscribe Pattern: https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern
  10. Rostopic: http://wiki.ros.org/rostopic
  11. ROS Parameter Server: http://wiki.ros.org/Parameter%20Server
  12. Rosparam: http://wiki.ros.org/rosparam

Entrando al mundo de la robótica contemporánea con ROS

En los últimos años, la robótica ha dado saltos tremendos que si bien, no ha alcanzado esas sociedades extremadamente automatizadas que nos muestra la ciencia ficción (R. Daneel Olivaw [1], la humanidad necesita tu apoyo), ha logrado grandes progresos y contribuciones y, de lo que trata el tema de hoy, ha motivado a más gente a entrar al mundo de la robótica.

Es común ver, cuando se habla de educación en robótica, que en carreras de orientación tecnológica y que no necesariamente son de especialización robótica se hacen talleres en los que los participantes pueden interactuar con pequeños robots, o armar los suyos propios con diversos sensores y actuadores. Esto es una experiencia altamente recomendable y disfrutable para personas con cualquier nivel de experiencia, incluso niños o personas sin formación en áreas tecnológicas. Pero cuando uno quiere profundizar e investigar en el área se pregunta, ¿cómo se puede cruzar esa barrera que separa el taller de robótica de la robótica comercial que uno ve en la TV o en internet? Bueno, hacer un primer acercamiento no es tan difícil.

Las personas que me conocen de cerca me habrán escuchado hablar en algunas ocasiones sobre el Software Libre y la importancia de las tecnologías abiertas. Aún hay quien dice que las tecnologías abiertas no son oportunidades para competir en el mercado… pero yo creo que a esas personas les falta un poco de visión de mundo. Basta considerar el hecho anunciado recientemente de que 486 de los 500 supercomputadores más rápidos del mundo funcionan con Linux [2][3]. Bajo mi perspectiva, vivimos en una sociedad tan interconectada que es imposible que un sólo individuo se adueñe de una idea. Las ideas complejas que benefician a mucha gente, se desarrollan desde una colectividad, ya que es en la colectividad dónde pueden nutrirse y refinarse a una velocidad que las hace usables. Así, vamos poco a poco pasando de una economía enfocada en productos (ideas desde un único agente) a una economía basada en servicios, o sea, “qué es lo que hacemos con una idea”. Y en el mundo de la robótica hace tiempo se dieron cuenta de esto, de que el avance es demasiado rápido como para intentar hacerlo todo desde un único lugar para poder competir. Así es como nació ROS, uno de los frameworks de robótica más robustos y populares en la actualidad.

ROS: Robotic Operating System

Los orígenes de ROS se remontan al Laboratorio de Inteligencia Artificial de Stanford y posteriormente su desarrollo fue acogido por la incubadora de robótica Willow Garage [4]. Estos esfuerzos han dado origen a una gran comunidad y a un conjunto de herramientas abiertas que permiten avanzar sin tener que reinventar la rueda.

Logo ROSTécnicamente, ROS no es un sistema operativo. Generalmente, se lo considera un middleware o un framework y ambas expresiones son más acertadas. Si hablamos de sistemas operativos, lo común es que asociemos ROS a Ubuntu, que es donde funcionan la mayoría de sus aplicaciones. Existen iniciativas para utilizar ROS junto a otros sistemas operativos, pero lo más común es usar ROS junto con Ubuntu (existen formas de instalarlo en Fedora, pero no todos los paquetes funcionan [5]), así que está de más decir que es un framework pensado para trabajar en Linux (¡yay!).

ROS funciona en un sistema basado en nodos. Tenemos un nodo maestro que gestiona las comunicaciones entre los distintos nodos que se van conectando. Cada nodo puede ser un programa que implemente las bibliotecas de ROS y desarrolle una función puntual, así se logran diseños modularizados en los que el sistema general no depende de manera crítica en la presencia de un componente (“Por una yegua coja no vamos a perder la trilla.”). Y esto último es algo fundamental en la robótica, ya que el sistema debe ser robusto a errores imprevistos. Incluso, los nodos pueden ejecutarse en varias máquinas para aligerar el cómputo y desarrollarlo de manera distribuida.

rqt_graph: aplicación de ROS que permite ver los nodos funcionando y su comunicación mediante los tópicos
Figura 1: rqt_graph, una aplicación de ROS que permite ver los nodos funcionando y su comunicación mediante los tópicos

La comunicación en ROS se realiza mediante tópicos y servicios. Los tópicos son canales de comunicación al estilo publisher-subscriber [6]. Un nodo puede abrir un tópico en el que publica un tipo de dato particular. Por ejemplo, yo tengo un dron Parrot AR.Drone 2.0 (ya hablaré de esa criatura, ahora que llegó su repuesto y puedo volver a usarlo <3) que mediante un nodo llamado ardrone_autonomy [7] puede publicar las imágenes que se reciben del dron en el tópico ardrone/front/image_raw. Luego otra aplicación se comporta como suscriptor de ese tópico y lee los datos publicados. Así se separa el proceso de producir datos y de procesarlos, lo que hace posible el que los distintos nodos estén desarrollados en distintos lenguajes de programación. Existen tipos de datos predefinidos para levantar tópicos para las distintas labores habituales en la comunicación en robótica, ya sea recibir datos de sensores o publicar comandos de control. Además, se pueden definir nuevos tipos de mensajes de acuerdo a las necesidades particulares de cada aplicación.

Los servicios son interfaces que un nodo abre a una determinada función. Otro nodo cliente, puede realizar una llamada a un servicio y solicitar que otro nodo realice una tarea, e incluso que envíe cierta información de vuelta. A diferencia de los tópicos, que están constantemente publicando independientemente de si son leídos o no, los servicios funcionan de acuerdo a cuando son llamados. Un ejemplo de servicio es el abierto por el simulador Gazebo, que permite reiniciar una simulación, devolviendo todos los robots instanciados a sus posiciones originales; para ejecutarlo, basta con hacer una llamada a /gazebo/reset_simulation. También hay tipos de mensajes para los servicios y se pueden desarrollar otros nuevos.

Además, ROS cuenta con diversas herramientas que ayudan a trabajar sobre esta arquitectura orientada a nodos. Por ejemplo, están las herramientas rqt, como rqt_graph (Figura 1) que permite ver un grafo con todos los nodos funcionando y los tópicos como flechas desde los nodos que publican hacia los nodos que están suscritos.

También ROS cuenta con un servidor de parámetros que guarda variables y datos que sean comunes a todo el entorno que se está ejecutando, como por ejemplo el modelo de un robot que se esté simulando o las especificaciones de un robot real con el que se esté conectado.

Instalar ROS

El desarrollo de ROS se ha enfocado fuertemente en Ubuntu como plataforma principal. Existen otras plataformas sobre las que se puede instalar [8], pero yo tengo una instalación sobre Ubuntu, así que sobre esta puedo hablar con conocimiento de causa. ROS se basa en distribuciones, que son cambios mayores en sus herramientas principales junto con conjuntos de paquetes compatibles con estas herramientas. Las distribuciones llevan nombres de acuerdo a las letras del abecedario y sus logos tienen que ver con tortugas (creo que tiene que ver con que el ejemplo más básico en ROS se basa en gráficos de tortuga [9]). La versión actual es Jade Turtle, pero yo tengo instalada la versión anterior, que es Indigoo Igloo y es una de las versiones con más soporte (y sobre la que se desarrollaron unos módulos para el dron con los que quiero empezar a trabajar). Para comenzar, yo creo que es recomendable instalar cualquiera de las dos ya que la mayoría del desarrollo se ha estandarizado. Por ahora, para seguir con el conocimiento de causa, vamos con Indigo.

Instalar ROS en Ubuntu es relativamente sencillo si se hace instalando desde los repositorios. Se puede instalar desde los archivos fuente, pero no se recomienda a menos que la ocasión lo requiera. Los pasos de la instalación se pueden encontrar en inglés en [11].

Mi versión de Ubuntu es la 14.04.2 (Trusty Tahr). Indigo es compatible con las versiones 13.10 y 14.04.

Para comenzar la instalación, hay que asegurarse de que los repositorios permitan la instalación desde los componentes “restricted”, “universe” y “multiverse”. En mi instalación venían habilitados por defecto, así que no tuve que hacer ningún cambio. En caso de necesitar configurarlos, se pueden seleccionar en “Sistema > Administración > Orígenes del Software”o revisar el artículo [10].

Luego se configura el sistema para que acepte paquetes desde packages.ros.org y se acepta su clave:

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'
sudo apt-key adv --keyserver hkp://pool.sks-keyservers.net --recv-key 0xB01FA116

Es conveniente revisar que el índice de paquetes esté actualizado ejecutando:

sudo apt-get update

Luego, basta instalar el paquete que incluye todas las aplicaciones de ROS. El paquete más completo, y el que yo instalé, es ros-indigo-desktop-full que incluye todas las herramientas gráficas y las bibliotecas genéricas de robótica.

sudo apt-get install ros-indigo-desktop-full

También existen alternativas que incluyen menos cosas (porque creo recordar que esa versión pesaba como un giga) como ros-indigo-desktop y ros-indigo-ros-base.

sudo apt-get install ros-indigo-desktop

Además, se pueden instalar los paquetes de manera individual de la forma:

sudo apt-get install ros-indigo-NOMBRE_DEL_PAQUETE

Para gestionar las dependencias de paquetes de ROS que vayamos a instalar, se debe instalar rosdep. Esto sirve cuando vayamos a probar algún paquete descargado como código fuente.

sudo rosdep init
rosdep update

Para dejar el sistema listo para usar, hay que registrar las variables de entorno de ROS. Esto se puede hacer añadiendo un archivo de configuración predeterminado al final del archivo .bashrc.

echo "source /opt/ros/indigo/setup.bash" >> ~/.bashrc
source ~/.bashrc

Para seleccionar las variables de entorno de una versión particular de ROS, se puede ejecutar source con el archivo predeterminado.

source /opt/ros/indigo/setup.bash

Otro paquete conveniente de instalar es rosinstall que permite instalar aplicaciones y gestionar sus dependencias de manera más automática.

sudo apt-get install python-rosinstall

Para verificar que todo está instalado y funcionando, abrimos una terminal y escribimos “roscore” y presionamos Enter. Deberíamos ver lo siguiente:

... logging to /home/bruno/.ros/log/70729674-2d80-11e5-9a3d-b803058568da/roslaunch-cronidea-3040.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is &lt;1GB.

started roslaunch server http://cronidea:60080/
ros_comm version 1.11.13

SUMMARY
========

PARAMETERS
 * /rosdistro: indigo
 * /rosversion: 1.11.13

NODES

auto-starting new master
process[master]: started with pid [3053]
ROS_MASTER_URI=http://cronidea:11311/

setting /run_id to 70729674-2d80-11e5-9a3d-b803058568da
process[rosout-1]: started with pid [3066]
started core service [/rosout]

Esto significa que lanzamos el nodo principal (master) de ROS y sus componentes, y que ahora podemos empezar a abrir otros nodos.

Un primer ejemplo de funcionamiento

Para usar ROS, es necesario que esté corriendo el roscore. Si lo hicimos funcionar como se mencionó recién, ahora abrimos otra consola y lanzamos el nodo del simulador de tortuga. Este simulador dibuja una tortuga en la pantalla y queda a la escucha de comandos de control para moverla en dos dimensiones. Esta tortuga recibe mensajes del tipo “Twist” en el tópico “/turtle1/cmd_vel”, que es el tipo de mensajes estándar que se utiliza para controlar un robot. Puede servir para hacer demostraciones o incluso poner a prueba ciertos algoritmos.

Para lanzar el simulador de tortuga, escribimos:

rosrun turtlesim turtlesim_node

Las aplicaciones de ros se organizan en paquetes, los que pueden contener varios nodos. En este caso “rosrun” busca en el paquete “turtlesim” el nodo “turtlesim_node”. Si todo funciona bien, deberíamos ver en la consola algo como:

[ INFO] [1437246767.585809489]: Starting turtlesim with node name /turtlesim
[ INFO] [1437246767.603619905]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000]

y una imagen con el simulador funcionando.

Figura 2: turtlesim_node funcionando
Figura 2: turtlesim_node funcionando

Al lanzar el simulador de tortuga, se abrirán nuevos tópicos. El simulador abre el tópico mencionado antes “/turtle1/cmd_vel” en el que recibe comandos de movimiento, y dos tópicos más: “/turtle1/color_sensor” y “/turtle1/pose” en los que publica el color del pixel en el que está y la posición que tiene en la imagen. Para ver los tópicos actualmente abiertos, se puede ejecutar en otra terminal:

rostopic list

y aparecerá algo como:

/rosout
/rosout_agg
/turtle1/cmd_vel
/turtle1/color_sensor
/turtle1/pose

Ahora que la tortuga está suscrita a un tópico en el que recibe comandos, podemos publicar comandos a ese tópico. Para hacer un primer ejemplo, usaremos el nodo “turtle_teleop_key” que viene en el paquete “turtlesim”. Este nodo recibe las entradas de las flechas del teclado y publica mensajes para controlar la tortuga.

rosrun turtlesim turtle_teleop_key

Deberíamos ver:

Reading from keyboard
---------------------------
Use arrow keys to move the turtle.

Usando las teclas, la tortuga comenzará a moverse.

Figura 3: turtlesim_node recibiendo comandos de control
Figura 3: turtlesim_node recibiendo comandos de control

Si abrimos otra consola y lanzamos rqt_graph, podemos ver todos los nodos funcionando y sus respectivos tópicos.

rosrun rqt_graph rqt_graph
Figura 4: rqt_graph con los nodos y tópicos de la tortuga
Figura 4: rqt_graph con los nodos y tópicos de la tortuga

Dónde seguir

En este tutorial, mostré un poco sobre cómo funciona ROS, uno de los frameworks de robótica más populares en la actualidad. Para ver su popularidad, basta considerar la cantidad de robots del DARPA Robotics Challenge que lograron grandes resultados usándolo (18 de 23 equipos [12]). Estos mismos principios mostrados en el breve ejemplo de la tortuga, son los que subyacen a toda la arquitectura de ROS y permiten desarrollar complejas aplicaciones distribuidas de alto desempeño.

Para seguir aprendiendo, los pasos siguientes son profundizar en los nodos, los tópicos, los servicios y aplicaciones como el simulador Gazebo o el visualizador RViz. Un buen punto de partida son los tutoriales oficiales de ROS [13]. Además, pretendo hacer más tutoriales para ir profundizando en varios temas que he aplicado.

Referencias

  1. R. Daneel Olivaw en Wikipedia: https://es.wikipedia.org/wiki/R._Daneel_Olivaw
  2. “It’s Official: Linux is the King of Supercomputing”: http://fossbytes.com/supercomputer-operating-system-linux/
  3. Top 500 Supercomputers: http://www.top500.org/statistics/details/osfam/1
  4. Historia de ROS: http://www.ros.org/history/
  5. Instalando ROS en Fedora 19: http://www.jann.cc/2013/04/29/building_ros_on_fedora_19.html
  6. Patrón Publisher-Subscriber: https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern
  7. Nodo ROS ardrone_autonomy: http://ardrone-autonomy.readthedocs.org/en/latest/
  8. Instalación de ROS Indigo: http://wiki.ros.org/indigo/Installation
  9. Gráficas Tortuga: https://es.wikipedia.org/wiki/Gr%C3%A1ficas_tortuga
  10. Repositorios de Ubuntu: http://doc.ubuntu-es.org/Repositorios_desde_Ubuntu
  11. Instalación de ROS en Ubuntu: http://wiki.ros.org/indigo/Installation/Ubuntu
  12. ROS y la revolución en la robótica: http://www.zdnet.com/article/long-live-ros-why-the-robotics-revolution-is-being-driven-by-open-source-development/
  13. Tutoriales de ROS: http://wiki.ros.org/ROS/Tutorials/

Una selfie al estilo de la Inteligencia Artificial de Google

Hace algunos días llegó a mi correo un artículo [2] de pyimagesearch.com, en sitio de tutoriales sobre imágenes en Python del que ya he aprendido bastantes cosas. En este artículo hablaban sobre “la creación de imágenes artísticas usando sueños guiados” en base a los “Deep Dreams” o “Sueños Profundos” de Google, los que podemos describir como imágenes obtenidas desde las redes de Deep Learning de Google. Una explicación bastante completa de este tema puede ser encontrada en [3], pero para contextualizar podemos decir a grandes rasgos que Google está utilizando técnicas de Inteligencia Artificial para aprender patrones de una gran cantidad de imágenes (una GRAN cantidad de imágenes) para luego poder describir imágenes nuevas en base a los patrones aprendidos. Esto es lo que se conoce como Deep Learning, o el aprendizaje de patrones desde Redes Neuronales Artificiales de gran profundidad, que ya ha dado grandes logros como la descripción automatizada de imágenes en base a texto [7].

Una de las razones por las que se volvió llamativa la nueva investigación de Google para el público, fue que mediante estos modelos generados por el Deep Learning, se hizo el proceso inverso a la obtención de patrones. Es decir, en base a una imagen resultante, se le pide al sistema obtener los patrones que componen la imagen. Esto dio como resultado imágenes muy bizarras en las que la imagen original se convierte en una combinación de líneas y figuras, y luego de formas como ojos o caras de animales. La explicación completa desde Google se puede leer (en inglés) en [8].

Fuente: GoogleResearch Blog
Fuente: GoogleResearch Blog [8]

En el artículo que llegó a mi correo, se habla de un módulo de Python que permite utilizar este modelo generado por Google para producir una imagen usando otra imagen como guía. O sea, usamos una imagen de base y usamos otra imagen que orienta la búsqueda de patrones en el modelo de Google para que la imagen que entregamos se exprese como una combinación de patrones relacionados a la imagen que usamos de guía.

El módulo de Python que se nombra es bat-country, que se presenta en un artículo anterior del mismo sitio [4]. Por curiosidad, intenté instalarlo y aproveché de hacer un tutorial para registrar la experiencia.

Instalación de bat-country

Hay varias cosas que instalar antes de hacer el experimento. Voy a partir por lo que me jodió por más tiempo: instalar bat-country.

Instalar bat-country no es difícil, pero me quitó tiempo porque sus dependencias se demoran un rato en instalar (matplotlib, te estoy mirando a ti) y si uno no tiene ciertas dependencias de las dependencias, la instalación falla al final y hay que descargar todo de nuevo (sí, matplotlib, te sigo mirando a ti). Las dependencias de matplotlib que me hicieron tener que descargar todo de nuevo son freetype y png. Para los usuarios de sistemas debian como Ubuntu, encontré un tutorial de cómo instalarlas [6], pero como yo uso Fedora, los instalé con yum:

sudo yum install freetype-devel libpng-devel

Otra cosa que tuve que instalar antes de ejecutar el script de instalación de bat-country, fue scipy. Scipy es un conjunto de herramientas científicas para Python, entre las que se incluye el conocido módulo Numpy. Intenté instalar Scipy mediante pip, pero se puso pesado buscando otros módulos, así que como era tarde y yo quería ver luego si el experimento resultaba, lo instalé directamente desde Yum:

sudo yum install scipy

Ahora que estamos seguros de que la ausencia de freetype y png no nos va a obligar a descargar matplotlib de nuevo, empezamos a instalar bat-country (entiéndanme, con mi internet fue todo un asunto el descargar todo otra vez). Existen dos formas de instalar bat-country. Una es usando directamente los repositorios de pip, la herramienta para instalar módulos de Python. La otra es descargando directamente bat-country desde el repositorio de GitHub (y luego usando pip. Me gusta decir pip, suena chistoso).

Para instalar bat-country mediante pip:

pip install bat-country

Para instalar bat-country desde GitHub:

#Nos ubicamos en alguna carpeta de nuestro sistema y descargamos el repositorio
git clone https://github.com/jrosebr1/bat-country.git
#Descomprimimos el archivo
cd bat-country
pip install -r requirements.txt
python setup.py install

Mientras se instalan las dependencias del archivo requirements.txt podemos ir a darnos una vuelta por ahí, beber algo (esta vez fue sólo Pepsi) o ponernos a perder el tiempo en algo improductivo como Agar.io (aunque no lo hice esta vez. Fucking lag).

Ahora tenemos la biblioteca mágica instalada, ¿estamos listos para probar la magia?

Instalando Caffe [8]

La verdad es que no estamos listos. El poder utilizar un modelo de Deep Learning no es una cosa sencilla, pues se requiere una gran arquitectura funcionando por debajo. En este caso, bat-country se basa en el framework Caffe, desarrollado en Berkeley.

Caffe es un framework de Deep Learning. Es un conjunto de herramientas diseñado para implementar aplicaciones al nivel del estado-del-arte en aprendizaje automatizado, capaz de funcionar con un altísimo desempeño aprovechando al máximo los recursos de la máquina. Tiene la opción de funcionar sobre GPU, pero este no es mi caso… -se va a un rincón y llora-.

Para instalar Caffe, debemos descargarlo desde GitHub y compilarlo en nuestra máquina. Para eso, nos ubicamos en alguna carpeta en la que queramos instalarlo. Yo tengo una carpeta llamada src en mi carpeta personal para probar programas, así que lo descargué ahí.

cd ~/src
git clone https://github.com/BVLC/caffe.git
#Descomprimimos el archivo y entramos a la carpeta
cd caffe-master

Antes de compilar Caffe, se deben instalar algunas dependencias. Estas dependencias salen explicadas en la página oficial de instalación de Caffe. Aquí hay un tutorial para Ubuntu [10] y uno para Fedora, que es el que pongo a continuación [11].

sudo yum install protobuf-devel leveldb-devel snappy-devel opencv-devel boost-devel hdf5-devel
#Existen otras dependencias que se aplican para versiones recientes
sudo yum install gflags-devel glog-devel lmdb-devel
#Si no se encontraron ciertas dependencias, se pueden instalar las siguientes
# glog
wget https://google-glog.googlecode.com/files/glog-0.3.3.tar.gz
tar zxvf glog-0.3.3.tar.gz
cd glog-0.3.3
./configure
make && make install
# gflags
wget https://github.com/schuhschuh/gflags/archive/master.zip
unzip master.zip
cd gflags-master
mkdir build && cd build
export CXXFLAGS="-fPIC" && cmake .. && make VERBOSE=1
make && make install
# lmdb
git clone git://gitorious.org/mdb/mdb.git
cd mdb/libraries/liblmdb
make && make install

Para que Caffe funcione, necesita un módulo BLAS (Basic Linear Algebra Subprograms) funcionando en el sistema. Este tipo de módulos sirven para paralelizar operaciones vectoriales y matriciales a bajo nivel. No me manejo en el tema, así que no voy a intentar profundizar mucho (igual les dejo el artículo de Wikipedia, por si acaso: [12]). Existen varias alternativas para instalaciones de módulos BLAS como ATLAS, OpenBLAS y MKL (que es específico para CPUs Intel). El que viene por defecto en Caffe es ATLAS, pero para hacer la instalación más rápida, yo instalé OpenBLAS desde Yum:

sudo yum install openblas openblas-devel

(Nótese que es importante instalar openblas-devel, creo que openblas-dev en sistemas Debian, porque ahí se incluyen las bibliotecas que Caffe importará al compilar).

Ahora deberíamos estar dentro de la carpeta de caffe (caffe-master en mi caso) para empezar la compilación. Para compilar, necesitamos primero copiar la plantilla del Makefile que se incluye en Caffe y configurar ciertos parámetros. Primero, debemos seleccionar si utilizaremos la GPU o la CPU. Luego debemos seleccionar qué módulo de BLAS utilizaremos y luego indicar las rutas de las bibliotecas del módulo BLAS.

#Copiamos la plantilla de Makefile incluida en la carpeta de Caffe
cp Makefile.config.example Makefile.config
#Luego se configura el Makefile (explicación más abajo)
#Se ejecutan las instrucciones make
make all
make test
make runtest

Las configuraciones que hay que hacer en el Makefile son:

  1. Seleccionar la opción de compilar solamente con CPU (si tienen GPU pueden saltarse este paso).  Para eso hay que descomentar la línea que dice CPU_ONLY := 1
  2. Seleccionar el módulo BLAS. Bajo una línea que dice “#BLAS choice:” hay que modificar para que diga “BLAS := open” si estamos usando openblas, o las opciones que ahí salen indicadas para el módulo correspondiente de BLAS.
  3. Si cambiamos la opción de BLAS que viene por defecto, debemos indicar las rutas en las que se encuentran las bibliotecas a incluir. En mi caso, tuve que especificar estas dos líneas (recuerdo que así es para Fedora. Para otro sistema quizás las rutas sean distintas) “BLAS_INCLUDE := /usr/include/openblas/” y “BLAS_LIB := /usr/lib/”.

Habiendo hecho lo anterior, se ejecutan los comandos make y se espera que pase lo mejor. Si no aparece ningún error, significa que al fin Caffe está compilado y listo para funcionar.

Preparar los wrappers de Python (pycaffe)

No se desanimen, esto es cortito. Para poder correr bat-country, se deben activar los wrappers de Python. Los wrappers son funciones que encapsulan la llamada a una aplicación para usarse en otro lenguaje. Esto nos deja llamar a Caffe desde Python.

Primero debemos instalar las dependencias de Python necesarias para hacer funcionar Caffe (recuerden que seguimos dentro de la carpeta de Caffe). Aquí vuelve a aparecer el compadre pip:

for req in $(cat requirements.txt); do pip install $req; done

Luego, añadimos la ruta de Caffe a la variable de entorno PYTHONPATH para que Python pueda encontrar el módulo de Caffe. Ejecutamos lo siguiente en la consola:

export PYTHONPATH=$HOME/src/caffe-master/python:$PYTHONPATH

Esta instrucción modificará la variable de entorno sólo mientras la consola esté abierta. Para no tener que ejecutarla siempre, añadí esa instrucción al final de mi archivo .bashrc, lo que es totalmente opcional.

Después de esto, llamamos a make para generar el wrapper pycaffe:

sudo make pycaffe

Con esto ya podemos usar Caffe desde Python, y a la vez, el módulo bat-country.

Usando bat-country

En [8] se muestra el siguiente código, con el que se puede probar el módulo bat country:

# import the necessary packages
from batcountry import BatCountry
from PIL import Image
import numpy as np
import argparse

# construct the argument parser and parse the arguments
ap = argparse.ArgumentParser()
ap.add_argument("-b", "--base-model", required=True, help="base model path")
ap.add_argument("-l", "--layer", type=str, default="inception_4c/output",
	help="layer of CNN to use")
ap.add_argument("-i", "--image", required=True, help="path to base image")
ap.add_argument("-g", "--guide-image", required=True, help="path to guide image")
ap.add_argument("-o", "--output", required=True, help="path to output image")
args = ap.parse_args()

# we can't stop here...
bc = BatCountry(args.base_model)
features = bc.prepare_guide(Image.open(args.guide_image), end=args.layer)
image = bc.dream(np.float32(Image.open(args.image)), end=args.layer,
	iter_n=20, objective_fn=BatCountry.guided_objective,
	objective_features=features)
bc.cleanup()

# write the output image to file
result = Image.fromarray(np.uint8(image))
result.save(args.output)

Ese código se debe guardar en un archivo .py. Antes de ejecutarlo hay que hacer una última cosa. No se puede empezar la fiesta si no está el anfitrión principal: el modelo de Deep Learning generado por Google. Este modelo se puede descargar mediante Caffe. Para descargar el modelo abrimos una consola y nos ubicamos en la carpeta donde quedó Caffe. Para descargar el modelo ejecutamos un script que viene incluido de antemano:

./scripts/download_model_binary.py models/bvlc_googlenet/

Ese  código se encargará de descargar el modelo y guardarlo en la carpeta “models” como la carpeta “bvlc_googlenet”.

Ahora ya podemos ejecutar bat-country. Para ejecutar el código, se necesita especificar cuatro cosas:

  1. El modelo base: Aquí es donde especificamos el modelo con el que vamos a procesar las imágenes. Lo especificamos con “-b nombre_de_modelo” o “–base-model nombre_de_modelo”. Este “nombre_de_modelo” debe ser la ruta de la carpeta del modelo que vamos a usar. Para eso se puede apuntar con la ruta completa a la carpeta “models/bvlc_googlenet” dentro de Caffe, pero para no hacer la ruta tan larga, yo copié la carpeta “bvlc_googlenet” a la misma carpeta del script de Python. Al final esta parte quedó como “-b bvlc_googlenet”.
  2. La imagen de entrada: Esta imagen de entrada es la que queremos “interpretar” por el modelo. En este caso yo me tomé una foto (a fin de cuentas, todo esto fue con el fin de conseguir una selfie engorrosa y poco convencional) y la especifiqué con “-i imagen.jpg”.
  3. La imagen de guía: Para que la búsqueda de patrones para describir la imagen no sea completamente exhaustiva, le entregamos una imagen de guía, que va a darle prioridad a los patrones que se encuentren dentro de ella. Por ejemplo, si ponen una imagen de ojos, se puede conseguir una de esas composiciones bizarras en las que las figuras se componen de muchas formas de ojos. Se especifica con “-g imagen”
  4. La imagen de salida: Bueno, la descripción lo dice todo. Se especifica con “-o archivo_de_salida”.

En una línea de código, y asumiendo que el archivo de Python se llama bat-country-test.py y las imágenes están en la misma carpeta, se puede ejecutar todo con:

python bat-country-test.py -b bvlc_googlenet -i input.jpg -g guide.jpg -o output.jpg

Después hay que esperar un rato. Para generar la imagen de abajo, en mi PC se demoró como 400 segundos.

En mi caso, usé las siguientes imágenes:

Primero, una selfie como imagen de entrada.

Sé que tengo cara de zombie. Pero no se puede pedir mucho a las tres de la mañana.
Sé que tengo cara de zombie. Pero no se puede pedir mucho a las tres de la mañana.

Luego, pillé una imagen de un bosque en Google. Me gustan los bosques. Esta fue la imagen de guía.

¿Cierto que son bonitos los bosques?
¿Cierto que son bonitos los bosques?

Y taratarán… esta cosa fue lo que resultó.

No, no hagan chistes sobre Jesús. Mantengamos este blog como un espacio laico, por favor.
No, no hagan chistes sobre Jesús. Mantengamos este blog como un espacio laico, por favor.

Conclusión

Sí, es una forma terrible de conseguir una foto de perfil. Lo interesante, es que a través de todo este experimento me pude acercar a un montón de tecnologías nuevas. Sirvió un poco para ver cómo un modelo de aprendizaje profundo puede lograr reconstruir imágenes en base a patrones con los que se haya entrenado. Hasta ahora era muy poco lo que se conocía sobre los patrones generados internamente en las redes neuronales artificiales. El hecho de poder visualizarlas, ayuda de gran manera a que podamos entender mejor su funcionamiento y sus capacidades, y también, por qué no, entender un poco mejor las redes neuronales naturales que tenemos en la ca’eza.

Referencias:

  1. pyimagesearch.com
  2. Generating art with deep guided dreaming
  3. Las increíbles imágenes de los sueños de la inteligencia artificial de Google
  4. bat-country: an extendible, lightweight Python package for deep dreaming with Caffe and Convolutional Neural Networks
  5. bat-country en GitHub
  6. Matplotlib and its local dependencies
  7. How Google “Translates” Pictures into Words Using Vector Space Mathematics
  8. http://googleresearch.blogspot.com/2015/06/inceptionism-going-deeper-into-neural.html
  9. Caffe
  10. Instalación de Caffe para Ubuntu
  11. Instalación de Caffe para Fedora
  12. BLAS en Wikipedia