Detection of Human-Robot Collision Using Kinetic

IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013
149
Detection of Human-Robot Collision Using
Kinetic
L. Mathé, Member, IEEE, A. Caverzasi, Member, IEEE, F. Saravia, Member, IEEE, G. Gomez,
Member, IEEE, J. P. Pedroni, Member, IEEE
1
Abstract— In this work, a system capable of detecting humanrobot potential collisions is presented. It is intended to assist a
robotic arm on its movement around the working area. By
detecting risk zones, it prevents the robot from interfering with
the surgeons work. To accomplish this, it is necessary to place
both the robot and the surgeon on a coordinate system. The
tracking of the robot is achieved by detecting color labels that
were placed on the robot’s joints. On the other hand, the
physician’s position is obtained using Kinect’s depth stream. The
output of the system will be used by the robot to define risk zones
and to avoid them by modifying its trajectory.
Keywords— Human-Robot potential collisions, Tracking with
Kinect, Detecting color labels.
L
I. INTRODUCCIÓN
OPERACIONES quirúrgicas mínimamente invasivas,
necesitan de un brazo robótico que sostenga al
endoscopio, el cual debe interferir lo menos posible en los
movimientos que realice el cirujano.
El objetivo del proyecto es desarrollar un brazo robótico
llamado LAPABOT, capaz de asistir al médico durante una
cirugía mínimamente invasiva. El sistema tiene como
destinatario el Hospital de Niños de la provincia de Córdoba.
Se abordó la investigación utilizando el sensor Kinect de
Microsoft, el cual provee a la computadora streams de imagen,
profundidad y audio. A partir de estos datos, es posible
determinar la localización física de objetos contenidos en el
campo de visión de las cámaras, y hacer un seguimiento de sus
movimientos.
El objetivo consiste en el desarrollo de un sistema capaz de
detectar situaciones, en las que puedan ocurrir colisiones entre
el brazo robótico y los brazos del médico cirujano quien esté
realizando la operación.
El sensor Kinect (Microsoft) posee los siguientes
componentes de hardware [1]:
o Cámara VGA 640X480 a color.
o Cámara infrarroja 640x480.
AS
1
L. Mathé, Universidad Nacional de Córdoba, Córdoba,
[email protected]
A. Caverzasi, Universidad Nacional de Córdoba, Córdoba,
[email protected]
F. S. Rajal, Universidad Nacional de Córdoba, Córdoba,
[email protected]
G. Gomez, Universidad Nacional de Córdoba, Córdoba,
[email protected]
J. P. Pedroni, Universidad Nacional de Córdoba, Córdoba,
[email protected]
Argentina,
Argentina,
Argentina,
Argentina,
Argentina
o Proyector infrarrojo.
o Arreglo de micrófonos.
o Motor para controlar la inclinación.
La Figura 1 muestra la interacción entre la aplicación y el
sensor.
Figura 1. Interacción entre el hardware y la aplicación [5].
Durante el desarrollo se utilizaron los streams de imagen y
profundidad. El primero para la detección del brazo robótico y
el segundo para el seguimiento del médico.
La aplicación ha sido escrita en el lenguaje C# utilizando la
herramienta Microsoft Visual Studio 2010 10.0.40219.1
SP1rel [2]. Para la comunicación con Kinect, se utilizó el SDK
oficial de Microsoft [3].
II. DETECCIÓN DE LA UBICACIÓN DE LAS ARTICULACIONES
DEL MÉDICO
En general, el stream de datos de profundidad que provee el
sensor está compuesto de 20 puntos (Figura 2), los cuales son
identificados cuando una persona entra en su campo de visión.
Esto permite seguimiento en tiempo real de todos los
movimientos.
Para evitar una colisión entre el brazo del médico y el brazo
del robot es necesario realizar el seguimiento de los
movimientos de los brazos del médico para disponer de la
información necesaria que permita programar la trayectoria
del brazo del robot. Para lograr esto, se deben identificar las
articulaciones del médico. Esto se puede lograr seleccionando
sólo los 11 puntos superiores del médico (ver el rectángulo en
la Figura 2) desde el torso hacia la cabeza, incluyendo los
brazos. La posición de cada uno de esos puntos se actualizan
30 veces por segundo, ya que ésta es la frecuencia de refresco
del sensor Kinect. A continuación se muestra una
simplificación del esqueleto del cirujano obtenida a partir de
estos 11 puntos (Figura 3).
150
IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013
seleccionar el ángulo correcto para cada situación.
IV. SEGUIMIENTO DEL BRAZO ROBÓTICO
Para lograr el seguimiento del brazo roboótico, se pegaron
etiquetas de colores sobre cada una de las articulaciones del
mismo (Figura 4). Detectando y siguiendo dichas etiquetas, es
posible obtener el estado y la posición del robot. Se diseñaron
distintas técnicas de detección y seguimiento de colores parar
lograrlo, a continuación se describen algunas.
Figura 2. Posiciones de las articulaciones del esqueleto (20 puntos). Sólo se
utilizan los 11 puntos superiores encerrados en el rectángulo horizontal,
desde la espina dorsal hasta la cabeza incluyendo los brazos, para llevar a
cabo la detección y el seguimiento del médico.
Figura 4. Etiquetas de color ubicadas sobre cada articulación del robot.
Figura 3. Esqueleto del médico obtenido a partir de 11 puntos proveídos por
el sensor, desde la espina dorsal hacia arriba.
Inicialmente se encaró el problema utilizando una
implementación que provee el SDK (Kit de desarrollo de
Software Kinect que provee Microsoft [6]) para dibujar el
esqueleto humano. Para lograr visualizar el estado de los
sistemas de seguimiento, el médico y el robot debían ser
dibujados sobre el mismo Canvas. Pero dado que la
implementación de Microsoft hace un borrado completo de la
pantalla en cada refresco, el robot nunca era visible.
Para resolver este problema, se construyó un nuevo
esqueleto usando figuras básicas (círculos y líneas). Las
líneas, que representan los huesos, conectan cada una de las 11
articulaciones (representadas por círculos). En lugar de borrar
el canvas completamente en cada refresco, sólo se actualiza la
posición de las figuras, y esto hace posible tener muchas
figuras en el mismo canvas, sin tener que borrar ninguna de
ellas cuando llega un nuevo frame.
Antes que nada, se hace una breve descripción de como
Kinect se comunica con nuestra aplicación: los datos del
stream de colores obtenidos a partir de la cámara RGB son
recibidos como una matriz, es decir un arreglo bidimensional.
Cada pixel de color está representado por 4 bytes:
componentes rojo, verde, azul. El cuarto byte indica la
transparencia. Es decir, cada cuatro bytes, se define el color de
un pixel (Figura 5).
Figura 5. Representación del stream de colores.
Como se muestra en la Figura 4, cada etiqueta abarca más
de un pixel. Pruebas manuales y observaciones mostraron que
incluso dentro del perímetro de las etiquetas, las componentes
de color de los pixeles varían mucho. A partir de esto se puede
decir que un color RGB no define a una etiqueta. En cambio,
se necesitan rangos de valores para cada componente. El
inconveniente es que, mientras más largo sea el rango elegido,
habrá más posibilidades de detectar objetos de colores
similares, que podrían estar en la zona de trabajo.
III. AJUSTE DEL CAMPO DE VISIÓN DEL SENSOR
Se agregó al sistema una función de control de inclinación,
usando el motor de Kinect, que permite modificar el campo de
visión del mismo, lo cual le da una versatilidad a la aplicación
de tal manera de que se pueda ubicar fácilmente al médico y al
robot en la sala de operación. El propósito del mismo es
centrar al médico en el medio de la ventana de la aplicación.
El ángulo de control tiene un rango de ajuste vertical del
campo de visión de 54°, desde los -27° hasta los +27°. La
interfaz de la aplicación posee un menu desplegable para
Figura 6. Etiquetas de dos colores.
El primer enfoque —trivial— para seguimiento de colores
consistió en configurar manualmente los rangos de valores
para cada etiqueta para tratar de encontrarlos en la matriz. Este
método no solo encontraba las etiquetas, sino también otros
objetos de colores similares del lugar. Se necesitaban más
restricciones.
MATHÉ et al.: DETECTION OF HUMAN-ROBOT COLLISION
Un enfoque distinto está basado en la detección de patrones
de colores. Por ejemplo, dos etiquetas de color para cada
articulación, una al lado de la otra (Figura 6). En este caso,
para cada etiqueta se necesitan 6 rangos RGB (tres para cada
color). El algoritmo, además de buscar los colores, debe
verificar que estos dos se encuentran uno al lado del otro,
respetando el orden en el que aparecen. Esto hace que sea
dificil detectar etiquetas que estuviesen rotadas.
El algorítmo más exitoso contaba el número de pixels que
satisfacían los rangos dentro de una pequeña linea de pixeles
contiguos (Figura 7). Si el número era aceptable, el proceso se
repetía para la línea siguiente. Si ambas líneas pasaban la
prueba, se consideraba encontrada una de las etiquetas del
robot. Esto está basado en probabilidad: dada una zona de la
imagen, a más pixeles que satisfacen las restricciones, más alta
es la probabilidad de que éstos pertenezcan a una etiqueta.
151
Figura 9. Efectos de profundidad.
A: (izquierda) la etiqueta está cerca de la cámara; B: (derecha) etiqueta
l j
El siguiente es el pseudocódigo del algoritmo de 2 líneas:
/*
* Algorithm
*/
pixelNumber = 0
while
( (noMatch) && (pixelNumber < frame.length)) :
for each label in labels :
/ /checkthe current pixels and 2 nearby pixels to see if it’s a matching zone
/ /checkMatchreturns true if the currentPixel matches the label’s color values.
pixel1match ← checkMatch ( pixelNumber,label.red,label.blue,label.green)
pixel2match ← checkMatch ( pixelNumber + offset,label.red,label.blue,label.green)
pixel3match ← checkMatch ( pixelNumber + 2*offset,label.red,label.blue,label.green )
if ( pixel1match ANDpixel2match AND pixel3match) :
linecount 1 ← 0
/ /try to match the first line
for each pixel inline1:
if ( checkMatch ( pixel,label.red,label.blue,label.green ) ) :
linecount1 + +
if ( linecount1 > 0.6*label.width ) : / / at least 60% pixel matches
linecount2 < − 0
for each pixel inline2 :
if ( checkMatch ( pixel,label.red,label.blue,label.green) ) :
linecount2 + +
Figura 7 Representación de el algoritmo de dos líneas.
Este método fué capaz de detectar todas las etiquetas, y su
velocidad permitió el seguimiento en tiempo real. A su vez,
era menos sensible a otros objetos de color similar que
pudiesen estar en la misma escena.
Dado que las etiquetas son cuadrados (Figura 8A), no
varían con rotaciones de 90 grados. Para que el sistema
funcione con cualquier rotación posible, las líneas escaneadas
deben ser lo suficientemente pequeñas para que entren
horizontalmente en la ventana en el peor caso (Figura 8B).
if ( linecount2 > 0.6*label.width ) :
labelDetected + +
saveLabelPosition
if ( labelDetected == 3) :
noMatch = false
A. Entrenamiento de colores y profundidad
Para establecer el seguidor de colores, se alimenta el
algoritmo con siete valores para cada etiqueta: profunidad, y
mínimos y máximos para cada componente de color
(rojo,verde y azul). Primero se deben colocar las etiquetas
sobre las articulaciones del robot. Como se muestra en la
Figura 10, la imagen de color posee una mira negra capaz de
desplazarse sobre la imagen.
Figura 8. A: (izquierda) contexto simple; B: (derecha) contexto complejo.
Otro obstáculo que se presentó fue la escala. A medida que
las etiquetas se alejan de la cámara, se ven más pequeñas
(Figura 9). Para superar este problema, el algoritmo debe
adaptar la longitud de la línea a escanear según la profundidad
de las etiquetas. Más adelante se explicará el proceso de
configuración de la profundidad, junto con el aprendizaje de
los colores.
Figura 10. La mira se muestra en la esquina superior derecha.
La mira debe ser movida hasta que se ubica sobre una
etiqueta. La interfaz gráfica de la aplicación posee botones
para controlar el desplazamiento de la misma. También hay
botones (uno para cada articulación del robot: hombre, codo y
muñeca) para capturar el color que se encuentra bajo la mira.
Por ejemplo, para capturar el color de la articulación del codo,
el botón “codo” debe ser presionado. La mira debe ser llevada
dentro de la etiqueta y se debe presionar el botón de captura
152
IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013
más de una vez, para garantizar que se incluyan variaciones de
color dentro de una misma etiqueta.
Para establecer la profundidad, lo que no es siempre
necesario, se deben realizar las siguientes acciones antes de
entrenar el seguidor de colores: 1) Ubicar la mira sobre el
borde izquierdo de la etiqueta y presionar el botón de captura;
2) Mover la mira hasta el borde derecho y presionar el botón
de profundidad (Fig.11). Este proceso cuenta el número de
pixeles necesarios para cubrir la longitud de la etiqueta, y
guarda ese valor que será utilizado por el algorítmo de 2
líneas. Este número disminuye a medida que la profundidad
aumenta.
pequeño, el sistema detectará posibles colisiones cuando
ocurran. En cambio, si son grandes, detectarán posibles
colisiones antes de que ocurran, permitiendo evitarlas antes de
que ocurran.
Por otro lado, se definieron cinco puntos en el brazo
robótico, uno por cada articulación (3), y un punto medio en
cada línea que une dos articulaciones (2). Esto se muestra en
la Figura 14.
Figura 14. Puntos de interés del brazo robótico, utilizados para el algoritmo de
detección.
Figura 11. Izquierda: paso 1, borde izquierdo. Derecha: paso 2, borde derecho
Luego de configurar correctamente el sistema acorde a la
descripción anterior, éste debería ser capaz de hacer el
seguimiento del brazo robótico (Figura. 12).
B. Algoritmo de detección
Para cada uno de los puntos de interés del médico, se
calcula la distancia a cada uno de los puntos de interés del
robot. Por ejemplo, se toma el punto elbow_left (codo
izquierdo del médico) y se calcula la distancia a cada uno de
los puntos del robot, trazando rectas, tal como muestra la
Figura 15.
Figura 12. Izquierda: lo que la cámara ve. Derecha : Lo que la aplicación
ve.
V. DETECCIÓN DE POSIBLES COLISIONES
Como se puede ver en la Figura 13, hay círculos centrados
en las articulaciones con mayor riesgo de colisión del
esqueleto. Dichos círculos, representan el espacio que ocupa el
cuerpo, más un espacio adicional extra. La cabeza y la espina
dorsal, tienen menos probabilidad de estar involucrados en una
colisión. Por otro lado, la Figura 14 muestra los puntos de
interés definidos en las articulaciones del robot. Cada uno de
estos círculos son usados en el algoritmo de detección de
colisiones.
Figura 15. Rectas imaginarias dibujadas por el algoritmo de detección.
Luego, a partir de cada una de esas rectas, se generan cinco
círculos, y se obtienen sus perímetros. Después de eso, se usa
una sentencia condicional para comparar cada uno de los
perímetros calculados recientemente, con el perímetro del
circulo que tiene como punto central el codo del médico. Si el
perímetro del codo (elbow_left) es mayor a alguno de los otros
perímetros, se asume que hay riesgo de colisión, y el sistema
lanzará una excepción “Riesgo de colisión”.
El siguiente pseudocódigo muestra a grandes rasgos la
implementación de dicho algoritmo:
/*
* Variables and vectors definition
*/
int physicianJoints
Figura 13. Círculos definidos sobre los brazos del médico, usados para el
algoritmo de detección.
A. Definición de puntos de interés
Las articulaciones, que son el centro de los círculos, son
llamadas puntos de interés. Cada círculo denota una zona de
peligro de colisión. Los radios pueden ser ajustados
manualmente por quien maneje la aplicación. Si el radio es
[]
← { hand _ right, wrist _ right, elbow _ right, shoulder _ right, head,
shoulder _ center, spine, shoulder _ left, elbow _ left, wrist _ left, hand _ left }
[]
int radiusRobot [ ]
← { shoulder, shoulder _ elbow, elbow, wrist _ elbow, wrist }
int robotJoints
int radiusPhysician
← { 0, 0, 0, 0, 0 }
[]
← { hand _ rightRadius, wrist _ rightRadius, elbow _ rightRadius, shoulder _ rightRadius,
headRadius, shoulder _ centerRadius, spineRadius, shoulder _ leftRadius,
elbow _ leftRadius, wrist _ leftRadius, hand _ leftRadius }
int perimeterRobot
[]
← { 0, 0, 0, 0, 0 }
int perimeterPhysician ← 0
MATHÉ et al.: DETECTION OF HUMAN-ROBOT COLLISION
/*
* Algorithm
*/
for each i in physicianJoints[ ]
{
for each j in robotJoints[ ]
{
radiusRobot[ j ] ← distance( physicianJoints[ i ] , robotJoints[ j ] )
perimeterRobot[ j ] ← perimeter( radiusRobot[ j ] )
perimeterPhysician ← perimeter( radiusPhysician[ i ] )
if (perimeterRobot[ j ] < perimeterPhysician) throw warning "Risk of collision"
}
}
/*
* The function distance, calculates the distance between two integers that it recives, and returns
* another interger: the distance between the two points. And the function perimeter calculates
* the expresion 2 × π × Radius and returns an integer
*/
Finalmente, es importante destacar que las líneas dibujadas
en el Canvas no representan a escala el grosor del cuerpo
humano y esa es una de las razones de por qué es más
conveniente utilizar diámetros mayores para los círculos.
La Figura 16 muestra una situación donde puede ocurrir una
colisión. Ésta fue detectada por el sistema durante una prueba.
153
posición del brazo según los cambios en el entorno del robot.
La Figura 18 muestra un diagrama de lazo cerrado del
control de movimiento del robot Lapabot. El cirujano utilizará
el Joystick para posicionar el punto central del instrumento de
acuerdo a sus necesidades.
La salida del detector de colisiones es la entrada del bloque
generador de trayectorias, el cual determina la configuración
cinemática de las articulaciones que el robot debe adoptar,
para cumplir los requisitos del operador, y genera las
correspondientes curvas de posición y velocidad articular Los
valores instantáneos de las curvas son comparados con la
configuración actual de las articulaciones de robot, por el
compensador de movimientos, el cual luego determina el
comando de acción inyectado en cada uno de los motores de
las articulaciones, de acuerdo con la ley de control
programada.
Figura 18. Diagrama de lazo cerrado del control de movimiento del robot
Lapabot.
VI. FUTURAS MEJORAS
Figura 16. La aplicación lanza una excepción de advertencia sobre una
posible colisión, durante una prueba del sistema.
C. Salida del sistema
Como salida de la aplicación se obtiene un archivo de texto,
que registra la posición donde una posible colisión fue
detectada. Ésta es representada en pares de coordenadas x, y.
El tamaño del Canvas es de 300x400 pixeles, por lo tanto el
resultado obtenido estará contenido en esos valores.
El archivo de texto luego será leído por el controlador del
robot, para la planificación de su trayectoria.
A continuación, la Figura 17 muestra otra prueba, y el
archivo de salida que muestra que la última posible colisión
fue detectada en la posición x=207 e y=182 del canvas.
Figura 17. Archivo de texto que registra las coordenadas de cada una de las
posibles colisiones.
La salida del detector de colisiones tiene dos funciones
principales: a) Restringir el espacio de trabajo del robot
durante la generación de trayectoria, con el fin de evitar
invadir el espacio del cirujano; y b) una vez alcanzado el
equilibrio, determinar si se necesita hacer una corrección de la
En la fase de prueba del proyecto, se encontraron algunas
dificultades:
1) Profundidad: Actualmente, el algoritmo de detección de
colisiones sólo detecta posibles intersecciones en el plano
visible de la cámara del sensor, y no tiene en cuenta la
profundidad. Por ejemplo, si observa las manos de la
persona por delante y por detrás del robot, el sistema
detectará colisiones cuando la mano tape la visión del robot,
incluso en el caso de que la mano esté muy por delante del
mismo.
Solución propuesta: mapear los pixeles de la imagen de
color a los pixeles en el frame de profundidad. De esta
forma, es posible conocer la profundidad a la que se
encuentran las etiquetas de color, para compararlas con la
profundidad de las articulaciones del cuerpo. El equipo
oficial de Kinect de Microsoft declaran que están trabajando
en una función similar a ésta. Por el momento, se puede
investigar el método inverso:
GetColorPixelCoordinatesFromDepthPixel.
2) Variaciones de iluminación: Dependiendo de la
iluminación del entorno, un mismo color puede parecer otro.
Para disminuir este efecto se agregó la función de “entrenar”
el detector de colores.
Propuesta de perfeccionamiento: en el sistema actual, se
define un color según el modelo RGB (rojo, verde, azul) ya
que es el que utiliza Kinect. Pero con una simple rutina de
transformación esos valores pueden ser convertidos al
modelo HSV (matiz, saturación, valor) que es independiente
de la iluminación.
3) La sensibilidad: Se han detectado situaciones en las que
las que las coordenadas de las articulaciones del médico
154
IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013
provistas por el sensor no son totalmente precisas. Esto se
debe a que Kinect fue diseñado principalmente para
videojuegos, y su principal objetivo está relacionado con la
detección de la forma del esqueleto. Además, el detector de
esqueleto no tiene en cuenta los dedos de las personas.
Propuesta: Con el fin de tener en cuenta el espacio ocupado
por los dedos, los radios de los círculos del médico no deben
ser demasiado pequeños.
VII. CONCLUSIÓN
El sistema es capaz de detectar situaciones peligrosas, pero
no se encuentra totalmente preparado para ser utilizado en una
cirugía. Todavía hay muchos aspectos a probar y mejorar. Para
garantizar la continuidad y el mantenimiento del proyecto,
cada etapa de la implementación ha sido documentada, y se ha
escrito una propuesta de posibles mejoras.
Respecto del sensor Kinect, es un dispositivo que abre
camino hacia una gran cantidad de nuevas aplicaciones que no
han sido descubiertas aún. El desarrollo sobre esta plataforma
se encuentra en una etapa sumamente temprana. Desde que se
lanzó el SDK oficial, todos los días se crean nuevas
aplicaciones [4]. Es una excelente herramienta para el
desarrollo sobre imágenes 3D y procesamiento de muchos
tipos de imágenes.
AGRADECIMIENTOS
Se agradece el apoyo brindado por el Ministerio de Ciencia
y Tecnología de Córdoba y de la Secretaría de Ciencia y
Tecnología – SeCyT de la Universidad Nacional de Córdoba,
Argentina
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
(SlideShare) Juan Pablo Arbeláez (2011, March). Kinect, Como
Funciona. Disponible: http://www.slideshare.net/ArbelaezGroup/kinectcomo-funciona-7228721
(Visual Studio Developer Center) Microsoft. Get started with Visual
Studio. Disponible: http://msdn.microsoft.com/en-us/vstudio/ff431702
(Kinect for Windows) Microsoft. Kinect SDK. Disponible:
http://www.microsoft.com/en-us/kinectforwindows/develop/
(Coding4Fun)
Microsoft.
Project
Gallery.
Disponible:
http://channel9.msdn.com/coding4fun/kinect/
(Microsoft Research, Kinect for Windows) Microsoft (2011, July).
Programming guide, SDK beta.
(Microsoft Research, Kinect for Windows) Microsoft (2011, July).
SkeletalViewer Walktrough C++ and C#, SDK beta.
Ladislao Mathé (M’92) nació en Argentina en 1951. Se
graduó como Ingeniero Electricista Electrónico en la
Universidad Nacional de Córdoba, Córdoba, Argentina en
1976. En 1977, se unió al Departamento de Ingeniería
Electrónica de la Universidad Nacional de Córdoba, como
Profesor de Control. Sus áreas de interés incluyen mecatrónica, sensores
inteligentes y transductores, robótica y aviónica. Ha estado involucrado desde
1971 en diferentes proyectos R&D en el área aeroespacial y de sistemas
electrónicos, y robótica. Desde 2003 es Director del Grupo de Investigación
GRSI (Grupo Robótica y Sistemas Integrados) de la Universidad Nacional de
Córdoba. Fue presidente de la subsección Córdoba IEEE-Sección 9 durante
los años 2003-2004. En el presente, es presidente del Capítulo Argentino de la
Sociedad de Sistemas Aeroespaciales y Electrónicos de la IEEE (IEEEAESS). (email: [email protected])
Caverzasi Agustín (M’11) 1989, nacido en la ciudad de Las
Varillas, Córdoba, Argentina. Terminó sus estudios primarios
y secundarios en la Escuela Normal Superior Dalmasio Vélez
Sarsfield, de la misma ciudad, con especialidad en Economía
y Gestión de las Organizaciones, en el año 2007. En 2008
ingresó a la carrera Ingeniería en Computación en la Facultad
de Ciencias Exactas Físicas y Naturales de la Universidad Nacional de
Córdoba, Argentina. Actualmente se encuentra cursando el último año de
dicha carrera, comenzando a desarrollar el trabajo final en el Grupo de
Robótica y Sistemas Integrados (GRSI).
Saravia Rajal Fernando (M’11) 1990, nacido en Salta,
Argentina donde completo sus estudios primarios. Luego se
mudó a Davis, California durante su primer año de secundaria
en la Emerson Junior High. En 2004, regresó a Salta, donde
finalizó sus estudios de secundaria. En 2008 ingresó a la
carrera Ingeniería en Computación en la Facultad de Ciencias Exactas Físicas
y Naturales de la Universidad Nacional de Córdoba, Argentina. Actualmente
se encuentra cursando el último año de dicha carrera, comenzando a
desarrollar el trabajo final en el Grupo de Robótica y Sistemas Integrados
(GRSI).
Gómez Gabriel (M’96) nació en Córdoba, Argentina, en
1974. Se recibió de Ingeniero Electrónico en la Universidad
Nacional de Córdoba, Córdoba, Argentina, en 2000. En 2002,
se unió al Departamento de Ingeniería Electrónica de la
Universidad Nacional de Córdoba, como Profesor de “Control
de procesos Industriales” (Ingeniería Electrónica) y desde 2009 es Profesor de
“Robótica en Medicina” (Ingeniería Biomédica). Sus áreas de interés incluyen
sensores inteligentes, redes industriales, sistemas instrumentados de seguridad
y robótica. Desde 2010, es Subdirector del Grupo de Investigación GRSI
(Grupo de Robótica y Sistemas Integrados). Es miembro Senior de ISA desde
2010.
Juan Pablo Pedroni (M’10), nació en Córdoba, Argentina, in
1977. Es graduado en Ingeniería Electrónica de la
Universidad Nacional de Córdoba. En 2007, recibió el título
de Especialista en Ingeniería en Control Automático de la
Universidad Tecnológica Nacional Regional Córdoba, donde
está estudiando por un título de Maestría en la misma especialización.
Desde 2003 es Profesor Auxiliar en las Cátedras de Sistemas de Control y
Teoría de Redes y Control en el Departamento de Ingeniería Electrónica,
Ingeniería Biomédica, e Ingeniería en Computación de la Universidad
Nacional de Córdoba. Es miembro del Grupo de Investigación GRSI (Grupo
de Robótica y Sistemas Integrados), donde ha participado de manera activa en
el desarrollo del brazo robótico para laparoscopía. Es miembro de la IEEE
desde 2010. ([email protected]).