Ya estamos de vuelta para contaros nuestra experiencia en el Big Data Spain 2018. El equipo de datahack estuvo presente siendo uno los patrocinadores del evento y dando información desde nuestro stand de los distintos servicios que ofrecemos tanto de formación en el master de Big Data e Inteligencia Artificial y los servicios de DH Seed como del proyecto de investigación DIA4RA, que mezcla robótica con Deep Learning, que desarrollamos en el área de Labs. Al final, lo interesante de estos eventos es la posibilidad de hablar con gente del sector y compartir las experiencias y problemas que nos encontramos en nuestro día a día de trabajo.

EL PANORAMA DEL SECTOR DE LA INTELIGENCIA ARTIFICIAL Y EL BIG DATA

El entorno de la Inteligencia Artificial y del Big Data es un sector muy influido por las tendencias marcadas por las grandes compañías tecnológicas. Por eso es muy necesario no olvidar cuál es el propósito que se quiere alcanzar con este tipo de tecnologías, tratar de conocer las bases que dan lugar a comportamientos “inteligentes” con el fin de modelar el entorno que nos rodea y poder predecir eventos futuros o emplear dicha inteligencia para mejorar la calidad de vida de las personas. Se trata de un objetivo muy ambicioso y es muy fácil perderlo de vista cuando se mezclan otros tipos de intereses como es la obtención de beneficios a corto plazo.

DIA4RA, PROYECTO PIONERO EN ROBÓTICA ASISTENCIAL E INTELIGENCIA ARTIFICIAL

En datahack estamos desarrollando el proyecto de investigación DIA4RA, cuyo propósito es dotar a un robot Pepper de las habilidades necesarias para poder asistir a pacientes con Alzheimer y ayudar al personal sanitario empleando la plataforma del robot y sus procesos cognitivos para recopilar información valiosa sobre la evolución de esta enfermedad en los pacientes. Teniendo todo esto en mente, quisimos ofrecer una charla (Teaching a Robot Guess Who? From Deep Learning To Brain Spikes) para mostrar, por un lado, cómo habíamos implementado la funcionalidad de reconocimiento facial del robot y, por otro, para enseñar caminos alternativos para acercarnos al objetivo de conseguir desarrollar modelos que imiten de forma más fiel la inteligencia humana.

Implementar un modelo de reconocimiento facial en la charla Teaching a Robot Guess Who? From Deep Learning To Brain Spikes

Sobre la implementación del modelo de reconocimiento facial, la idea era comenzar dando un repaso teórico a los ladrillos con los que hemos construido esta funcionalidad. Me estoy refiriendo a las Redes Neuronales Convolucionales. La intención era mostrar cómo su implementación matemática, empleando un aprendizaje supervisado mediante Backpropagation, hace que no se obtenga un modelo robusto frente a grandes variaciones de los datos datos de entrada. Durante el proceso de entrenamiento, la Red Neuronal aprende los valores de los kernels de las capas convolucionales, de forma que esos kernels sean capaces de distinguir de forma jerárquica las features visuales de las clases presentes en el conjunto de datos de entrenamiento. En este tipo de redes, después de una capa convolucional se suele emplear también la capa de Pooling. A muy grandes rasgos, esa capa se encargará de reducir la dimensionalidad de los Feature Maps de salida de dicha capa convolucional preservando su información más importante. Es decir, permite reducir la cantidad de parámetros de la red (lo cual es una ayuda en redes con muchas capas) realizando un resumen de la información de salida. El problema es que, al realizar estos resúmenes, se está perdiendo información espacial (dónde se encuentran unas features con respecto a otras). Y esa información espacial es muy valiosa cuando se está trabajando el objetivo de obtener un modelo que se comporte de forma robusta cuando tenga que reconocer su entorno en tiempo real.

Uno de los resultados del proyecto DIA4RA, que estamos actualmente desarrollando en datahack y cuyo objetivo es dotar a un robot humanoide “Pepper”, de una serie de capacidades cognitivas que le permitan asistir a personas con Alzhéimer, ha sido la creación de un modelo de speech to text, es decir, un software que convierte la voz humana a texto, gracias al uso de técnicas de deep learning.

Dentro del proyecto DIA4RA, este modelo es el encargado de transcribir la voz humana a texto, de modo que otros modelos y sistemas implementados en el robot puedan interpretar lo que dicen los humanos que se dirigen a él. Así, este modelo es fundamental para la operativa de la máquina de estados, encargada de definir los diferentes estados que puede adoptar el robot y de la orquestación de todos los modelos y sistemas implicados en el funcionamiento del robot.

speech to text con tensorflow

A priori, uno puede pensar que para hacer esto se podría recurrir a alguno de los servicios cognitivos disponibles en la red, y no tener que embarcarse en el desarrollo de un modelo de deep learning, con todas las implicaciones que ello conlleva. Sin embargo, en datahack se decidió optar por la creación de un modelo Speech to Text propio, por la siguientes razones:

Trabajando con información secuencial

El Speech to Text es un caso de uso donde se trabaja con información secuencial, es decir, una serie o sucesión de cosas que siguen un orden y/o guardan entre sí una determinada relación.

Tradicionalmente este tipo de información se ha tratado con redes neuronales recurrentes (Recurrent Neural Networks o RNN), redes neuronales con memoria que se usan para trabajar con información secuencial.

En este tipo redes la neuronas se disponen de forma secuencial, una a continuación de la otra. Cada una de ellas representa un momento temporal y tienen la capacidad de pasar la información recopilada a la siguiente. Así, a la hora de hacer las predicciones (O),  se tendrá en cuenta tanto el vector de entrada (X) como un vector de estado (h). Así, teniendo en cuenta el siguiente gráfico, para predecir Ot se tendrá en cuenta Xt  y ht-1, vector de estado resultante de la etapa anterior. Además de predecir el valor de Ot , se generaría un nuevo vector de estado ht que sería usado en la siguiente etapa (h+1). Esto se iría repitiendo de forma sucesiva.

speech to text con tensorflow

Figura 1 - Disposición de las neuronas y flujo de información en una capa de RNN

Un problema de las Redes Neuronales Recurrentes y su solución

Uno de los problemas de las Redes Neuronales Recurrentes (RNN) es que sufren lo que se conoce como el short-term memory, es decir, funcionan muy bien cuando la información útil está próxima al estado actual, pero su rendimiento va empeorando conforme esta se va alejando, es decir, no capturan bien las long-term dependencies, dependencias de larga distancia. Esto se debe a que con secuencias muy largas (más de 100 elementos), sufren lo que se conoce como vanishing gradient y tienden a “olvidar” el principio de las mismas. Así, teniendo en cuenta el siguiente ejemplo:

El gato, que ya había comido mucho pollo con verduras, estaba lleno.

Podría ocurrir que al llegar al verbo “estaba”, la RNN puede haber olvidado el principio de la frase y no sea capaz de ver que esta relacionado con la palabra “gato”.

Para minimizar este problema se usan: las GRU (Gated Recurrent Unit) y las LSTM (Long-Short Term Memory), dos tipos especiales de neuronas que cuentan con una célula de memoria, que les permite capturar mucho mejor las long-term dependencies. Y las  BRNN (Bidirectional Recurrent Neural Networks), que tienen en cuenta tanto la información anterior como  posterior a la hora de hacer una predicción en el momento actual.

Todo esto se puede combinar y crear BRNN con GRU o LSTM, con un aumento considerable de la capacidad de computación requerida durante el entrenamiento de la red neuronal.

Todo esto, aplicado al Speech to text...

En el caso del Speech To Text, donde la entrada es una secuencia y la salida también, se pueden reducir los costes de computación, haciendo uso de la arquitectura seq2seq. Está se caracteriza por tener una estructura encoder-decoder compuesta por dos Redes Neuronales Recurrentes, que usan LSTM o GRU (normalmente más la primera) y trabajan de forma que la primera red (encoder) memoriza el audio, codificándolo en un vector de contexto o sentence embedding, y la segunda red (decoder) y la segunda genera el texto correspondiente, a partir del vector de contexto que ha creado la primera.

speech to text con tensorflow

Figura 2 - Estructura encoder(verde) - decoder(morado)

Aunque esta estructura mejora los costes de computación, tiene el problema de que cuando la secuencia de audio entrante es muy larga, la red neuronal encoder tiende a olvidar la primera parte de la mismas, tras concluir su procesamiento. Para resolver esto, surgieron los mecanismos de atención.

De los mecanismos de atención y de más cosas hablaremos en el próximo post.

Muchas gracias por vuestra atención, ¡valga la redundancia! 🙂


Javier Moralo, Data & AI Creative de datahack


dia4ra cdtiEl proyecto empresarial de DATAHACK CONSULTING SL., denominado “DESARROLLO DE INTELIGENCIA ARTIFICIAL EN ROBOTS APLICADOS AL TRATAMIENTO DEL ALZHEIMER Y LA DEMENCIA” y número de expediente 00104725 / SNEO-20171211 ha sido subvencionado por el CENTRO PARA EL DESARROLLO TECNOLÓGICO INDUSTRIAL (CDTI)

MÁSTER EXPERTO EN BIG DATA & ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

Retomamos el blog de AIDA con menos avances de los que desearíamos. Por un lado, desde el punto de vista de cada modelo de Deep Learning, nos hemos dado cuenta de que no estamos completamente satisfechos con casi ninguno de los conseguidos hasta el momento. Todos tienen algo que nos gustaría mejorar, cambiar o directamente volver a empezar. Todo ellos son poco viables en mayor o menor medida, ya que tenemos que estar siempre con un ojo en la planificación y, como dice nuestro compi Marcelo con mucha razón, si por nosotros fuera estaríamos un año con cada modelo: dándole vueltas, ampliando el dataset, tratando de introducir perturbaciones...

Problemas encontrados en los modelos de Deep Learning

Nos hemos encontrado (o más bien dado de bruces) con nuestras propias limitaciones y también las del Deep Learning, sobre las cuales otro de los compis de Labs (Rubén Martínez o @eldarsilver en Twitter) ha estado leyendo largo y tendido. La cantidad ingente de imágenes que requiere el resolver robustamente problemas del campo de la visión computacional hace que abordar modelos como el face recognition (reconocimiento facial) se convierta en poco más o menos que una odisea... Si es que no se dispone de una cantidad considerable de imágenes de cada sujeto en distintos entornos y en distintas circunstancias vitales.

Al final, nos encontramos con que abordar un problema de aprendizaje supervisado (aquel que consiste entrenar un modelo con ejemplos etiquetados del problema que queremos que resuelva) es muy difícil de conseguir mediante Deep Learning….Y si no es Deep Learning ¿qué hacemos? ¡buena pregunta! aunque compleja de responder...sería algo así como ¿cuál es el camino que lleva al futuro? ¿podrían ser las Spiking Neural Networks que desgranaremos en otro post?

En todo caso se acerca el final del 2018 y este es el balance que podemos extraer, estad con los ojos bien abiertos en el 2019 para no perderos por donde irán los tiros.

También hay cosas buenas: la máquina de estados finita

Igual que, con la transparencia que nos caracteriza, os transmitimos nuestras preocupaciones, no queremos despedirnos de vosotros este año sin compartir otro pequeño paso que no hubiera sido posible (de nuevo) sin los compañeros del Departamento de Robótica de la URJC: la implementación de una máquina de estados finita, simple pero funcional.

Por si alguien no ha tenido la oportunidad de disfrutar la asignatura de Teoría de Autómatas y Lenguajes Formales, básicamente el concepto alude a un modelo matemático que normalmente es representable mediante un grafo y que consta de un número finito de estados pudiendo estar en uno y solo uno en cada momento. Por supuesto, el paso de un estado a otro será posible como consecuencia de algún tipo de entrada externa que motive este cambio (o en lenguaje de Teoría de Autómatas: transición). De hecho una máquina de estados finita (o FSM: Finite State Machine) viene definida por su estado inicial, una lista de sus estados y las condiciones para que ocurra cada transición.

Si aun con todo, sigue sonando muy abstracto, pensad en las máquinas de vending, los ascensores o los candados con combinación...todos ellos son ejemplos cuya lógica interna responde a una FSM. Ahora bien, si queréis saber si hemos convertido a AIDA en una expendedora de gominolas y refrescos o si existe otro motivo mucho más interesante por el que queramos implantar en ella una máquina de estados…¡estad atentos a la siguiente entrada!. No os olvidéis de ser felices, ¡Feliz Navidad!

dia4ra cdtiEl proyecto empresarial de DATAHACK CONSULTING SL., denominado “DESARROLLO DE INTELIGENCIA ARTIFICIAL EN ROBOTS APLICADOS AL TRATAMIENTO DEL ALZHEIMER Y LA DEMENCIA” y número de expediente 00104725 / SNEO-20171211 ha sido subvencionado por el CENTRO PARA EL DESARROLLO TECNOLÓGICO INDUSTRIAL (CDTI)

MÁSTER EXPERTO EN BIG DATA & ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

Retomamos con fuerza el diario de DIA4A para poneros al día de los avances realizados hasta la fecha. Como recordaréis, hemos conseguido que el modelo de detección de objetos y personas desempeñe su cometido sobre las imágenes capturadas a través de la cámara frontal del robot. Ahora que llegan los primeros resultados es momento de traducirlos a entregables. Entre estos, contamos la documentación técnica y ejecutiva de cada modelo y, por supuesto, el cuaderno de pruebas.

Para elaborar el cuaderno de pruebas, hemos desglosado cada modelo en sus funcionalidades básicas. Para acreditar que estas se han alcanzado, hemos acordado grabar un vídeo del robot desempeñando cada funcionalidad. Con la idea de que el vídeo fuese más vistoso y, sobre todo, no abusar del uso de comandos escritos, de cara a hacerlo más atractivo para alguien con un perfil no tan técnico, optamos por aprovechar la Google Cloud Speech To Text API. Como imaginareis, es un servicio de Google que permite la transcripción multi-idioma de voz a texto. Hacemos un paréntesis aquí, para indicar que paralelamente estamos desarrollando nuestro propio modelo de Speech To Text en castellano.

El objetivo para registrar nuestra prueba unitaria para este primer modelo (y para el resto de pruebas unitarias) era grabar un vídeo en el que:

  1. Se explica la prueba a realizar.
  2. Una persona se acerca al robot y le da una orden concisa en forma de comando de voz (por ejemplo: empieza)
  3. El robot en ese momento activa el modelo y empieza a publicar la salida de lo que va reconociendo.
  4. La persona le pide al robot que detenga la prueba mediante otro comando de voz (por ejemplo: termina)
  5. Una segunda persona explica las salidas generadas.

Entrando en detalles:

Para los que os gusta algo más de detalle, os explicamos un poco más a fondo el proceso. Lo primero es comentar algo sobre el nodo de ROS que encapsula la llamada a la API Speech To Text de Google. Este nodo se encuentra desplegado en el robot (a diferencia del nodo que encapsula el modelo desarrollado, que se encuentra en nuestras máquinas ya que requiere del uso de GPU para sus predicciones). La razón de esto es que se trata un nodo ligero que no realiza una computación per se, sino que delega en la API de Google, entonces lo primero será conectarse al robot y levantar este nodo.

Con ello, esperamos que la transcripción de cualquier voz humana que se detecte a través de los micrófonos del robot, sea publicada a través de un topic de ROS. A partir de aquí, se trata de escuchar en dicho topic y detectar el comando de activación de la prueba (algo así como “empieza” o “reconoce”) tras el cual se ejecuta una suscripción al topic de la cámara del robot y el modelo desarrollado comienza a identificar, hasta que se pronuncia el comando de finalización de la prueba (por ejemplo “termina”) “ y se desconecta del topic de la cámara, deteniéndose las predicciones.


Gracias a los compañeros de la URJC por el nodo que encapsula la Google Cloud Speech To Text API.

dia4ra cdtiEl proyecto empresarial de DATAHACK CONSULTING SL., denominado “DESARROLLO DE INTELIGENCIA ARTIFICIAL EN ROBOTS APLICADOS AL TRATAMIENTO DEL ALZHEIMER Y LA DEMENCIA” y número de expediente 00104725 / SNEO-20171211 ha sido subvencionado por el CENTRO PARA EL DESARROLLO TECNOLÓGICO INDUSTRIAL (CDTI)

MÁSTER EXPERTO EN BIG DATA & ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

Ya estamos aquí para continuar el relato donde lo dejamos en el artículo anterior de esta serie. La trama quedó en suspense después de mostrar que un programa de Tensorflow se divide en 2 fases. La primera consiste en la construcción del grafo que alberga por un lado las operaciones a realizar y por otro los tensores que contienen los valores que alimentan a dichas operaciones. La segunda etapa se basa en la creación de un objeto de sesión que permitirá ejecutar el grafo sobre dispositivos locales o remotos. Sigamos con este recorrido por los principales componentes del Core de Tensorflow.

Sesión

La clase tf.Session permite conectar un programa cliente, que actúa como frontend en alguno de los lenguajes disponibles como Python, gracias al “Tensorflow Distributed Execution Engine” de C++. Un objeto de esta clase tf.Session proporciona el entorno para ejecutar objetos tf.Operation y evaluar objetos tf.Tensor. Esto lo hace tanto en dispositivos (como CPUs, GPUs, TPUs) de la máquina local como de máquinas remotas. También proporciona el entorno para cachear el grafo que tenga asociada dicha sesión.

Como se ha comentado, en DIA4RA vamos a emplear la API de alto nivel Estimator que, entre otros beneficios, creará y gestionará el objeto tf.Session por nosotros. Además, nos permitirá abstraernos de escribir el código de bajo nivel necesario para poder realizar un entrenamiento distribuido entre múltiples máquinas. Por ello, aunque no vayamos a manejar sesiones de forma explícita en nuestro proyecto, vamos a mostrar una pequeña introducción en las siguientes líneas.

El constructor de esta clase recibe de forma opcional 3 argumentos:

Una práctica habitual a la hora de crear una sesión es la de hacerlo mediante un bloque “with” de Python. De esta forma, la sesión estará activa dentro del ámbito de dicho bloque y al salir se cerrará automáticamente y se liberarán sus recursos. En caso de no emplearse un bloque “with” será necesario cerrar explícitamente esa sesión mediante tf.Session.close para que se liberen sus recursos.

Para realizar la ejecución propiamente dicha se emplea el método tf.Session.run que recibe una lista con los tf.Operation o/y tf.Tensor que se pretenden ejecutar y que deben estar presentes en el grafo asociado a dicha sesión.

En la siguiente captura de pantalla se muestra la creación del grafo por defecto que contendrá la operación creada mediante tf.add que trabajará sobre los arrays de numpy “a” y “b” (cuyo valor se obtiene inmediatamente al no ser tensores de Tensorflow). A continuación, se genera mediante un bloque “with” la sesión “sess” y dentro de su ámbito se ejecuta empleando sess.run la operación de suma. Al finalizar el ámbito del bloque “with” se cerrará automáticamente la sesión.

Programando con la API de Bajo Nivel de Tensorflow

A continuación, se puede ver otra imagen en la que se ha creado el grafo “g1” al que se le ha añadido la operación creada mediante tf.multiply que trabajará sobre los arrays de numpy “d” y “e”. Una vez hecho eso, se crea la sesión “sess1” que operará sobre el contenido del grafo “g1” únicamente. Mediante sess1.run se ejecuta la multiplicación presente en “g1” y como la sesión no se ha creado mediante un bloque “with”, como buena práctica cuando ya no se va a emplear más dicha sesión, se cierra utilizando sess1.close.

Programando con la API de Bajo Nivel de Tensorflow

En estos ejemplos se han utilizado sesiones que trabajan sobre recursos presentes en la máquina local. La API de Bajo Nivel de Tensorflow permite que la sesión pueda acceder a dispositivos presentes en otras máquinas que trabajen conjuntamente formando un clúster permitiendo un cálculo distribuido. En DIA4RA emplearemos la abstracción de ejecución distribuida que ofrece la Estimator API para realizar entrenamientos en paralelo entre múltiples máquinas presentes en el Cloud.

Los clúster distribuidos de Tensorflow

Un clúster distribuido de Tensorflow estará formado por uno o más jobs, de forma que cada job puede contener una o más tasks. Las tasks de un job colaboran en una ejecución distribuida de un grafo. Normalmente cada task se ejecuta en una máquina diferente pero también es posible ejecutar varias tasks en la misma máquina, por ejemplo, empleando un dispositivo diferente presente en dicha máquina (si dispone de varias GPUs). Cada tarea estará asociada a un tf.train.Server que estará formado por un master para crear sesiones y por un worker para ejecutar operaciones del grafo.

Una técnica muy utilizada cuando se realiza un entrenamiento distribuido consiste en emplear procesos que actuarán como Parameter Servers. Las variables serán repartidas entre los parameter servers disponibles en función de su tamaño para balancear la carga.  Cuando un proceso worker necesite un variable almacenada en un parameter server, hará referencia directamente a ella. Cuando un worker calcule un gradiente, será enviado al parameter server que almacene esa variable concreta.

Para crear un clúster será necesario por un lado crear un objeto de la clase tf.train.ClusterSpec y uno o varios tf.train.Server.

La clase tf.train.ClusterSpec permite indicar todas las tasks del clúster. Su constructor recibirá un diccionario mapeando cada nombre de job a una lista de direcciones de red de las tasks de ese job o a otro diccionario en el que cada clave será un índice de task y su correspondiente valor será la dirección de red de dicha task.

El siguiente fragmento de código crea la configuración de un clúster formado 2 workers y 1 parameter server.

cluster = tf.train.ClusterSpec({“worker”: [“192.168.1.120:3333”, “192.168.1.121:3335”],
                                            “ps”: [“192.168.1.122:3335”]
                                            })

A continuación, lo que habrá que hacer es instanciar  los servers correspondientes a los 2 workers y al parameter server.

server0 = tf.train.Server(cluster, job_name=“worker”, task_index=0)
server1 = tf.train.Server(cluster, job_name=“worker”, task_index=1)
serverPs = tf.train.Server(cluster, job_name=“ps”, task_index=0)

El siguiente paso será emplear la función tf.device para especificar en qué proceso se colocará cada operación:

with tf.device(“/job:ps/task:0”):
    var0 = tf.Variable( … )
    var1 = tf.Variable( … )
    var2 = tf.Variable( … )
with tf.device(“/job:worker/task:0”):
    res0 = tf.matmul(var0, var1)  
with tf.device(“/job:worker/task:0”):
    res1 = tf.matmul(var1, var2)

En este punto, se crearán las sesiones necesarias y cada una de ellas se asociará con un server (2 workers y 1 parameter server).

sessPs = tf.Session(target=serverPs.target)
sess0 = tf.Session(target=server0.target)
sess1 = tf.Session(target=server1.target)

Dichas sesiones se emplearán para ejecutar las operaciones asociadas a esos servers (tasks). En un futuro artículo se presentará de forma práctica un entrenamiento distribuido empleando la API de Bajo Nivel de Tensorflow. Pero antes, vamos a continuar con el recorrido por sus componentes básicos.

Asignación de dispositivos mediante tf.device()

En Tensorflow los dispositivos disponibles para ejecutar operaciones son CPUs y GPUs. La notación que se emplea para referenciarlos es la siguiente:

La secuencia seguiría aumentándose el índice de la GPU si existiesen más de estos dispositivos. Por defecto, si una operación está implementada para poder ejecutarse tanto en CPU como en GPU, los dispositivos GPU tendrán prioridad a la hora de recibir esa operación.

En primer lugar, para visualizar los dispositivos disponibles en la máquina se podrá ejecutar el siguiente código:

from tensorflow.python.client import device_lib
device_lib.list_local_devices()

Programando con la API de Bajo Nivel de Tensorflow

Si se desea colocar una o varias operaciones en un dispositivo en concreto la forma de hacerlo será empleando un bloque “with” con la función tf.device() que recibirá el nombre de dicho dispositivo.

with tf.device(“/gpu:0”):
    a = tf.constant([2, 7, 3])

Constantes

Se trata de un tensor que tiene un valor constante que se crea mediante la función tf.constant() y dispone de los siguientes argumentos:

Programando con la API de Bajo Nivel de Tensorflow

Variables

Una variable de Tensorflow permite almacenar un tensor cuyo valor puede ser cambiado ejecutando una serie de operaciones sobre ella. Esas modificaciones son visibles desde múltiples objetos tf.Session lo que permite que diferentes workers puedan acceder al valor de una misma variable.

A bajo nivel la clase que se encarga de su implementación se trata de tf.Variable. En cuanto a la creación de variables la forma recomendada es mediante la función tf.get_variable, que recibe el nombre de dicha variable y su shape entre otros argumentos opcionales como su valor inicial.

var1 = tf.get_variable(“test”, [2, 1, 4], dtype=tf.int64)

Ese comando creará una variable llamada “test” de 3 dimensiones y shape [2, 1, 4], cuyos valores serán de tipo tf.int64 (en caso de no indicarse el parámetro dtype, el tipo por defecto será tf.float32) y su valor inicial se establece por defecto a partir a partir de la distribución aleatoria determinada por tf.glorot_uniform_initializer.

Esta función (también llamada inicialización Xavier) generará muestras aleatorias entre [-a, a], donde:

Si se desea indicar un initializer en concreto se puede hacer de la siguiente forma:

var2 = tf.get_variable(“test2”, [5, 2, 4, 1], dtype=tf.int32, initializer=tf.zeros_initializer)

En caso de que el initializer sea un tf.Tensor entonces no habrá que indicar el shape en el constructor de tf.get_variable ya que lo inferirá a partir del shape de ese initializer ([2, 3]):

var4 = tf.get_variable(“test4”, initializer=tf.constant([2,3]))

Las “collections” de Tensorflow son listas con nombre de tensores u otros objetos como variables. Cuando se crea una variable se añadirá por defecto en las colecciones tf.GraphKeys.TRAINABLE_VARIABLES (son las variables para las que Tensorflow calculará sus gradientes) y tf.GraphKeys.GLOBAL_VARIABLES (variables que pueden ser compartidas entre múltiples dispositivos).

Para hacer que una variable no sea tenida en cuenta a la hora de calcular los gradientes habría que pasar el parámetro “trainable=False” a la hora de su creación.

var5 = tf.get_variable(“test5”, [4, 2], trainable=False)

Se pueden crear collections personalizadas utilizando cualquier cadena como nombre. Para añadir un objeto ya creado a una colección se empleará el método tf.add_to_collection.

tf.add_to_collection(“col1”, var4)

La forma de conocer todos los objetos de una collection es mediante la siguiente función:

tf.get_collection(“col1”)

Hasta este punto hemos visto cómo crear variables y cómo unirlas a collections. Pero antes de poder utilizar una variable hay que añadir una operación al grafo para que la inicialice explícitamente, lo que permite evitar que se vuelvan a ejecutar initializers que pueden consumir un tiempo importante, por ejemplo, al volver a cargar un modelo desde un “checkpoint”.

La función que emplearemos para inicializar una única variable será:

sess = tf.Session()
sess.run(var1.initializer)

Pero como ir inicializando variable por variable puede ser muy tedioso, hay una función que viene a nuestro rescate, tf.global_variables_initializer(). Se encarga de añadir una única operación al grafo que, cuando sea ejecutada, inicializará todas las variables presentes en la collection  tf.GraphKeys.GLOBAL_VARIABLES.

init = tf.global_variables_initializer()
sess1 = tf.Session()
sess1.run(init)

Esta función no asegura el orden en que serán inicializadas las variables. De forma que si hay variables que dependen de otras y no estamos seguros de si ya han sido inicializadas, una forma de programar de forma segura es empleando en la variable dependiente la función var_de_la_que_se_depende.initialized_value().

a = tf.get_variable(“a”, [1,2], initializer=tf.zeros_initializer())
b = tf.get_varible(“b”, initializer=a.initialized_value() * 2)

Si se quiere asignar un nuevo valor a una variable se podrán emplear la familia de funciones assign, assign_add.

sum = a.assign(a + 7.0)
sum2 = a.assign_add(8.0)

La instrucción tf.get_variable puede encontrarse en un bloque de código (una función) que puede ser ejecutado repetidas veces. No quedaría claro si lo que se pretende es volver a crear la misma variable o reutilizarla. Una forma de solucionar esto es creando una variable dentro de un bloque “with” con tf.variable_scope (eso añadirá el nombre del variable_scope al principio del nombre de la variable) y cuando se quiera reutilizar dicha variable, la instrucción tf.get_variable se incluirá en el interior de  un tf.variable_scope con el mismo nombre que cuando se creó pero que además recibirá el parámetro "reuse=True".

En caso de no utilizar el flag "reuse=True", si la variable ya había sido previamente creada mediante una llamada a get_variable, al volver a intentar crearla se obtendrá una excepción o si no se creó mediante una llamada a get_variable. Esto permite evitar reutilizar variables por error. Una vez establecido reuse a True ya no se puede poner a False dentro del bloque. También se puede fijar el flag reuse a True dentro del bloque llamando a scope.reuse_variables().

A continuación, vamos a ver un ejemplo de utilización de la función get_variable para crear una variable compartida si no existe o reutilizarla en caso de que exista. Esto se controla dentro del scope "relu". Si se definen otros variable scopes dentro del actual, heredarán el flag "reuse=True".

Las variables creadas usando get_variable siempre se nombran utilizando el nombre de su variable scope como prefijo. Por ejemplo, relu/threshold. Si se crea un scope con un nombre que ya había sido utilizado por otro scope, se añadirá un sufijo "índice" para que el nombre sea único.

Se definirá una función "relu()" que reutilizará una variable relu/threashold. Dicha variable será creada fuera de la función inicializándola a 0.0. A continuación se construirán 5 relus llamando 5 veces a la función "relu()".

tf.reset_default_graph()

def relu(X):
    with tf.variable_scope("relu", reuse=True): # Reutilización de la variable threshold
        threshold = tf.get_variable("threshold", shape=(), initializer=tf.constant_initializer(0.0))
        w_shape = int(X.get_shape()[1]), 1
        w = tf.Variable(tf.random_normal(w_shape), name="weights")
        b = tf.Variable(0.0, name="bias")
        linear = tf.add(tf.matmul(X, w), b, name="linear")
        return tf.maximum(linear, threshold, name="max")

X = tf.placeholder(tf.float32, shape=(None, n_features), name="X")
with tf.variable_scope("relu"): # Creación de la variable threshold
    threshold = tf.get_variable("threshold", shape=(), initializer=tf.constant_initializer(0.0))
relus = [relu(X) for i in range(5)]
output = tf.add_n(relus, name="output")

Placeholders

Un tf.placeholder es una estructura que almacenará datos pero dichos datos serán cargados en tiempo de ejecución. Por tanto, nos permitirá definir un almacén de información que podrá ser añadido al grafo sin tener que alimentarlo hasta que se cree una sesión y se desee ejecutar operaciones que dependan de este placeholder.

Para ello, el método sess.run deberá recibir como parámetro además de las operaciones a ejecutar, un argumento llamado feed_dict que será un diccionario donde cada clave será el nombre de un placeholder y su correspondiente valor será justamente el valor que queramos que reciba esa estructura.

import tensorflow as tf

a = tf.placeholder(“float”, None)
b = a + 7

with tf.Session() as sess:
    r = sess.run(b, feed_dict={a:[6,3]})

Como se ha podido apreciar, no es necesario definir estáticamente un tamaño para los datos que albergará un tf.placeholder. También puede tener cualquier número de dimensiones y cuando alguna de sus dimensiones sea “None”, significa que puede tener cualquier número de elementos en ella.

import tensorflow as tf

a = tf.placeholder(“float”, [None, 2])
b = a + 7

with tf.Session() as sess:
    r = sess.run(b, feed_dict={a:[[1, 4], [3, 5], [7, 9]]})

---

Hasta aquí este breve repaso a los componentes básicos del Core de Tensorflow. En próximos artículos continuaremos viendo APIs de más alto nivel de este potente framework de Google.

 

dia4ra cdtiEl proyecto empresarial de DATAHACK CONSULTING SL., denominado “DESARROLLO DE INTELIGENCIA ARTIFICIAL EN ROBOTS APLICADOS AL TRATAMIENTO DEL ALZHEIMER Y LA DEMENCIA” y número de expediente 00104725 / SNEO-20171211 ha sido subvencionado por el CENTRO PARA EL DESARROLLO TECNOLÓGICO INDUSTRIAL (CDTI)

MÁSTER EXPERTO EN BIG DATA & ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

Cuando tienes que abordar un proyecto tan grande como DIA4RA, cuyo objetivo es el de dotar de inteligencia a un robot humanoide para que sea capaz de asistir y ayudar a pacientes con Alzheimer,  un punto clave consiste en elegir qué herramientas se van a emplear para conseguirlo.

Creemos que, para que comprendáis por completo las dimensiones del proyecto, debéis conocerlas (o, por lo menos, que os suenen). Así pues, vamos a aprovechar el diario para compartir con vosotros una serie de artículos en los que se pretende tanto discutir las elecciones realizadas como mostrar una introducción al funcionamiento de dichas herramientas.

ROS

Por un lado se necesita un framework que permita distribuir la información procedente de los múltiples sensores del robot y enviar órdenes a sus actuadores. Para conseguir esto, se decidió utilizar ROS (como dijimos en artículos anteriores, significa Robot Operating System). Puede considerarse como la solución más robusta y potente, en cuanto a las posibilidades que ofrece, cuando hay que trabajar a nivel profesional con componentes robóticos.

Además en datahack contamos con la colaboración del grupo de Robótica de la URJC de Fuenlabrada. Ellos disponen de amplia experiencia en este ámbito avalada por sus publicaciones, su contribución a proyectos Open-Source por sus continuas participaciones en congresos y torneos internacionales como Robocup, iROS, etc.

Tensorflow

Por otro lado es necesario disponer de otro framework con el que desarrollar los algoritmos que implementarán la inteligencia de AIDA (como dijimos en el primer post del diario, es nuestro robot y sus siglas significan Artificial Intelligence Datahack Ambassador). Para este propósito nos decantamos por Tensorflow debido al fuerte impulso que está recibiendo por parte de Google y de la comunidad de investigadores en Inteligencia Artificial.

Google Cloud

Además, tuvimos que decidir entre:

  1. si adquirir la infraestructura de máquinas equipadas con GPU’s potentes para entrenar todos los modelos que necesita el robot y ponerlos en producción
  2. si era preferible emplear el Cloud de alguno de los grandes proveedores, que nos permitiese desplegar el entorno necesario para entrenar algoritmos y realizar las predicciones con los modelos generados.

Hay que tener en cuenta que, cuando el robot sea plenamente funcional, deberá contar con al menos 8 modelos predictivos ejecutándose en paralelo. A eso habrá que sumar el planificador global de tareas que controlará el comportamiento de AIDA, así como los recursos necesarios para la gestión de su Sistema Operativo y de los demonios de ROS.

Nuestro compañero Alejandro se encargó de implementar una arquitectura hardware que soportase todos los requisitos tanto para el entrenamiento como para la inferencia.

En paralelo, iniciamos contactos con Nvidia y Google con el objetivo de presentarles nuestro proyecto y buscar distintas formas de colaboración. Como resultado, pasamos a formar parte tanto del programa “Inception” de Nvidia, con el que proporcionan recursos, soporte y promoción, como del programa “Google Cloud for Startups” en el que entre otros beneficios se dispone de créditos para entrenar y servir modelos empleando la infraestructura de Google Cloud Platform.

Teniendo todo esto en cuenta, la aproximación que hemos tomado ha sido la de “prototipar” el código de los algoritmos en nuestras máquinas de trabajo, que disponen de tarjetas GPU de Nvidia. Luego hemos adaptado dicho código a los requisitos de Tensorflow para que pueda ser entrenado empleando el Cloud. Esto nos da la flexibilidad de poder utilizar el mismo código tanto en una arquitectura on-premise como en la nube.

¡Seguro que ahora quieres saber más sobre cómo aplicamos estas herramientas en el proyecto!

Pues no temas, porque vamos a desarrollar todo esto un poquito más (en la sección DIA4RA para programadores, porque la cosa se pone un poco más técnica). Y es que, como puedes comprobar, el proyecto DIA4RA ya lleva un tiempo corriendo. No ha empezado, ni mucho menos, con la llegada de AIDA.

Por eso decidimos hacer esta serie de artículos “flashback” dedicados a las herramientas de programación que se emplearán en DIA4RA. Comenzaremos mostrando la estructura que deberá tener el código de Tensorflow para que pueda ser entrenado de forma distribuida y servido en el Cloud. El siguiente paso consistirá en presentar los principales componentes de ROS, para finalizar enseñando cómo integrarlos con los modelos de Tensorflow. De esta forma, os mostraremos el recorrido cuya meta es la de combinar modelos predictivos de Deep Learning con Robótica.

Y es que, una vez realizada esta introducción, empieza lo realmente divertido para nosotros, ponernos manos a la obra con la parte técnica.


Rubén Martínez, Data engineer en datahack

dia4ra cdtiEl proyecto empresarial de DATAHACK CONSULTING SL., denominado “DESARROLLO DE INTELIGENCIA ARTIFICIAL EN ROBOTS APLICADOS AL TRATAMIENTO DEL ALZHEIMER Y LA DEMENCIA” y número de expediente 00104725 / SNEO-20171211 ha sido subvencionado por el CENTRO PARA EL DESARROLLO TECNOLÓGICO INDUSTRIAL (CDTI)

MÁSTER EXPERTO EN BIG DATA & ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

Una vez cumplido nuestro deber con el Call for papers del Big Data Spain, volvemos a la carga con AIDA. En la entrada de la pasada semana veíamos unos conceptos básicos de ROS (como por ejemplo la noción de qué es un topic). Esta semana toca empezar a explotar la información que recibimos a partir de los distintos sensores del robot.

Tomando los modelos que ya hemos hecho

Nuestro primer objetivo era tomar un modelo que se desarrolló hace unos meses. Este se hizo para poder incorporarlo algún día al robot Pepper de nuestros compañeros de la URJC. En realidad, se trataba de dos modelos en uno:

SSD entrenado con el dataset COCO

El primero de los modelos consistía en una arquitectura single shot detector (SSD) mobilenet entrenado con el dataset COCO (Common Objects In COntext). Este estaba entrenado a su vez con 80 clases diferentes. Su objetivo era detectar personas de forma fiable en una imagen, para después trazar un bounding box a su alrededor.

diario dia4ra SSD entrenado con el dataset COCO bounding box

(ssd_mobilenet en acción detectando una persona y una silla. Los recuadros con el nombre de la clase y la confianza que el modelo atribuye a la predicción se conocen como bounding boxes)

En caso de detectar una persona, se hacía un crop de la misma en base a su bounding box. Esto es como si con unas tijeras se recortara la parte de la imagen delimitada por el bounding box con la etiqueta person. El resultado se pasaba a otra red cuyo objetivo era detectar el tipo de prenda que la persona llevaba y el color de la misma. Inicialmente estaba limitado a vaqueros, zapatos, vestidos y camisetas de color blanco, rojo o azul.

Es posible que a alguien le surja la pregunta. ¿De dónde sacamos las imágenes sobre las cuales realizamos la identificación? Para hacer pruebas tenemos una cámara ASUS Xtion PROTM. La conectamos a alguna de nuestras torres mediante un USB y la conectamos con ROS a través del paquete openni2_launch. Así nos suscribimos al topic de la cámara y los frames que se reciben se van suministrando al modelo (o más bien doble modelo) anteriormente descrito.

Así que la primera prueba de concepto consistía básicamente en quedarnos solo con la parte de la SSD mobilenet (ya que en principio nos interesará reconocer personas y otros objetos sin necesidad de fijarnos en más detalles). Una vez ajustado el código, solo quedaba cambiar el topic al que se suscribía para que fuera el de una de las cámaras del robot. Y, claro…¡ver que funcionaba!

Efectivamente, el resultado fue bueno, lo que robot “veía” le llegaba al modelo. Este era capaz de identificar en la imagen cualquiera de los 80 objetos del dataset COCO que estuviera presente en ella. Luego, trazaba alrededor de cada uno su correspondiente bounding box.

Experimentando con el sonido

Paralelamente a esto, estamos trabajando en un modelo de Speecht2Text (es decir, capaz de traducir voz a texto) en castellano. Aparte, evaluamos otras posibilidades como por ejemplo la API de Google Speech.

Esto nos permitirá tener una noción de la capacidad del micrófono del robot para captar voz. También de cuál es el estado del arte ahora mismo en este tipo de modelos. ¡Vamos a ver cómo nos desenvolvemos con el sonido!


Alejandro Arranz, Data Engineer en datahack

dia4ra cdtiEl proyecto empresarial de DATAHACK CONSULTING SL., denominado “DESARROLLO DE INTELIGENCIA ARTIFICIAL EN ROBOTS APLICADOS AL TRATAMIENTO DEL ALZHEIMER Y LA DEMENCIA” y número de expediente 00104725 / SNEO-20171211 ha sido subvencionado por el CENTRO PARA EL DESARROLLO TECNOLÓGICO INDUSTRIAL (CDTI)

MÁSTER EXPERTO EN BIG DATA & ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

La semana pasada nos habíamos quedado a las puertas de desplegar ROS (Robotic Operating System) en AIDA (para aquellos que recién se incorporen al blog, indicar que AIDA es un robot PepperTM). No obstante, debido a diversos fallos de compilación, tuvimos que abortar el proceso y esperar. Esta semana, los compañeros del departamento de Robótica de la URJC nos han proporcionado los paquetes que faltaban para solucionar los problemas de compilación y además nos han asistido mediante conexión remota para controlar que llevábamos a buen puerto la instalación.

Por qué tiene tanta importancia ROS

Vamos a profundizar un poco más para ver donde está la gracia de desplegar ROS en el robot. Es decir, si ya trae de fábrica su propio sistema operativo (NaoQi) ¿por qué meterle otro?

Anteriormente, se había comentado que la razón de esto es el poder aplicar los modelos de Deep Learning que vayamos desarrollando al robot. Vamos a intentar ser más exactos y a la vez comprensibles: en ROS existe el concepto de topic. En pocas palabras, se utiliza para publicar la información que el robot captura a través de sus diferentes sensores (cámaras, micrófonos, bumpers…). Por ejemplo, existirá un topic concreto en el cual se publicarán las imágenes que el robot capture a través de sus cámara. Cuando nos conectamos al robot, podemos ver, mediante el comando rostopic list, la lista de topics que ahora mismo hay disponibles:

diario dia4ra robotica labs

Usando la cámara frontal

Centrémonos en uno de los primeros topics que nos van a ser de utilidad para dotar de inteligencia al robot, el topic de la cámara frontal: /pepper_robot/camera/front/image_raw. Podemos ver que el robot está continuamente publicando en ese topic mensajes que representan a los frames que captura a través de su cámara:

diario dia4ra robotica labs

Quizá el ver una torrente continuo de píxeles no nos diga mucho, afortunadamente ROS nos ofrece herramientas como rviz que permite, entre otras funcionalidades, ver lo que el robot está viendo. Si seleccionamos el topic /pepper_robot/camera/front/image_raw esto es lo que vemos:

diario dia4ra robotica labs

¿Cómo se explota el contenido publicado en un topic?

Bueno, de igual manera que es posible publicar en un topic, también es posible suscribirse al mismo. De esta manera, podemos hacer “algo” con el contenido que se vaya publicando. Por ejemplo, que cuando se publique una imagen en el topic, esta se utilice como entrada para un modelo de Deep Learning que (a efectos de pruebas) estará corriendo en uno de los ordenadores. Ese modelo tendrá que discriminar si en las imágenes que le van llegando hay caras humanas y, si las hay, determinará a quien pertenecen...

Pero, antes de seguir, tenemos que preparar algo interesante para el call for papers del Big Data Spain. El año pasado nuestro datahacker Rubén Martínez se marcó una impresionante charla sobre cómo un atacante puede engañar a un sistema de detección de malware mediante Reinforcement Learning. No obstante, lo que prepararemos para este año seguramente tenga que ver con el robot...¡así que permaneced atentos!


Alejandro Arranz, Data Engineer en datahack

 dia4ra cdtiEl proyecto empresarial de DATAHACK CONSULTING SL., denominado “DESARROLLO DE INTELIGENCIA ARTIFICIAL EN ROBOTS APLICADOS AL TRATAMIENTO DEL ALZHEIMER Y LA DEMENCIA” y número de expediente 00104725 / SNEO-20171211 ha sido subvencionado por el CENTRO PARA EL DESARROLLO TECNOLÓGICO INDUSTRIAL (CDTI)

MÁSTER EXPERTO EN BIG DATA & ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

Hola a tod@s,

Toca hacer la primera entrada del diario de DIA4RA y, como ha sido una semana intensa, vamos a hablaros de lo que hemos estado haciendo con nuestro nuevo robot. AIDA no ha dejado indiferente a nadie, incluso los datahackers más familiarizados con el mundo tecnológico han sucumbido a sus encantos. Y es que, desde el momento en que se pulsa el botón de encendido, se puede ver cómo el robot se incorpora, se despereza (literalmente) y saluda en su idioma: algo bastante... humano.

Una vez inicializado, el robot permanece en su sitio, pero siempre orientando su cabeza y su mirada a aquel lugar de la habitación donde “escuche” una voz humana. Todo esto hace que, cuando nos quedamos solos en la habitación con él, nos dé la impresión de que realmente hay alguien más.

En resumen, AIDA ha entrado en datahack como el fichaje superestrella de un equipo que, sin haber todavía entrado en juego, ya tiene encandilada a la afición. ¿Qué ocurrirá cuando se logre integrar con el primer modelo de Deep Learning?

Justamente este objetivo es prioritario de cara al proyecto que tenemos entre manos (y del cual pronto sabréis más) y esta primera semana hemos empezado a trabajar en dos líneas que implican al robot. Por un lado el despliegue de ROS (Robotic Operating System o Sistema Operativo del Robot) en AIDA. Por otro, investigar y comenzar a explotar las posibilidades que el sistema operativo que el propio robot lleva montado de fábrica (NaoQi) pueda ofrecer.

Desplegando ROS

En cuanto a la primera línea de trabajo que hemos seguido, ROS es muy importante. Esto es porque constituye las bases de la infraestructura necesaria para ejecutar los diferentes modelos de Deep Learning que tenemos planificados. Lo que ocurre es que esta tarea no es ni mucho menos trivial o sencilla. Por eso, esta semana hemos estado codo con codo con los compañeros del departamento de Robótica de la Universidad Rey Juan Carlos I (URJC). Ellos ya habían trabajado previamente con este tipo de despliegues y tenían preparada una metodología para llevarlos a cabo.

Básicamente, la metodología consiste en construir, en una imagen Docker, todas aquellas dependencias y requisitos que, junto con ROS, necesitarán desplegarse en el robot. Una vez se hayan realizado las compilaciones correspondientes en la propia imagen, esta se desplegará en el robot... Esa es la teoría. Como era de esperar, los errores de compilación no han tardado en aparecer y ahora mismo estamos trabajando con ellos para resolverlos y poder conseguir nuestro primer hito, ¡nadie dijo que fuera a ser fácil!

Probando el robot

Pero bueno, no todo han sido errores, aunque es una semana de puesta en marcha también hemos hecho algún avance. La segunda línea de trabajo era hacer una serie de pruebas y chequeos en AIDA, además de irla presentando a todos nuestros compañeros de datahack. Para ello, usamos el Choregraphe, una herramienta con la que pudimos conectarnos a ella e interactuar con el sistema NAOqi, que como ya hemos dicho es el que trae instalado.

Una vez realizado todo esto, empezamos a hacer chequeos del estado de los componentes de AIDA y una serie de pruebas de sensores, movimientos posturales y desplazamientos. No obstante, lo más interesante vino cuando le implementamos un paquete canal básico de comunicación e hicimos una primera prueba de conversación interactiva con ella. Podríamos escribir mucho sobre ello, pero preferimos grabar un vídeo para que lo pudierais ver vosotros mismos: aún no tiene del todo claro que se llama AIDA y se equivoca algunas veces, pero no pasa nada, ¡son las primeras pruebas! Disfrutad la experiencia y buen fin de semana:

dia4ra cdtiEl proyecto empresarial de DATAHACK CONSULTING SL., denominado “DESARROLLO DE INTELIGENCIA ARTIFICIAL EN ROBOTS APLICADOS AL TRATAMIENTO DEL ALZHEIMER Y LA DEMENCIA” y número de expediente 00104725 / SNEO-20171211 ha sido subvencionado por el CENTRO PARA EL DESARROLLO TECNOLÓGICO INDUSTRIAL (CDTI)

MÁSTER EXPERTO EN BIG DATA & ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

Esta semana ha pasado algo muy importante en datahack: se ha incorporado a la familia un nuevo miembro... robótico.
El robot se llama AIDA (Artificial Intelligence Datahack Ambassador) y ya es la niña mimada de la oficina. Pero lo más importante es que nos dará una gran agilidad y libertad para llevar a cabo la aventura de dia4ra.
*Para el que no lo sepa, dia4ra es nuestro proyecto pionero a nivel mundial que integra robótica asistencial e inteligencia artificial para la prevención, detección y tratamiento de enfermedades degenerativas).

La llegada de AIDA: un hito más entre muchos logros.

El equipo de labs lleva ya mucho tiempo trabajando (con robots más básicos o gracias a la inestimable ayuda del equipo de la URJC) en este proyecto. Todo empezó con el Turtlebot y, desde entonces, hemos logrado grandes avances en ROS y self driving, modelos de segmentación, Bounding Boxes, planificación y desarrollo de modelos, cloud deep learning...
Sí, ya lo sabemos, todos esos "palabros" suenan un poco a chino, pero no os preocupéis. Aunque empecemos el diario de labs ahora (porque en algún momento hay que empezar, y cuál mejor que ahora, que ha llegado AIDA, estrenamos la nueva web hace poco y tenemos a una persona de marketing disponible para convertir nuestros apasionados discursos técnicos en un texto digerible), os lo vamos a contar todo. Cómo hemos llegado aquí y todo lo avanzado hasta la fecha. Los retos que afrontamos. Los avances que consigamos. Las dificultades que encontremos. El día a día con AIDA.
Os aseguramos que será un viaje apasionante, ¿nos acompañas?

dia4ra cdtiEl proyecto empresarial de DATAHACK CONSULTING SL., denominado “DESARROLLO DE INTELIGENCIA ARTIFICIAL EN ROBOTS APLICADOS AL TRATAMIENTO DEL ALZHEIMER Y LA DEMENCIA” y número de expediente 00104725 / SNEO-20171211 ha sido subvencionado por el CENTRO PARA EL DESARROLLO TECNOLÓGICO INDUSTRIAL (CDTI)

MÁSTER EXPERTO EN BIG DATA & ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.

chevron-down