• No se han encontrado resultados

PLATAFORMA PARA ROBÓTICA DE SERVICIO E INTERACCIÓN HUMANO MÁQUINA

N/A
N/A
Protected

Academic year: 2020

Share "PLATAFORMA PARA ROBÓTICA DE SERVICIO E INTERACCIÓN HUMANO MÁQUINA"

Copied!
13
0
0

Texto completo

(1)

PLATAFORMA PARA ROBÓTICA DE SERVICIO E INTERACCIÓN

HUMANO MÁQUINA

PLATFORM FOR SERVICE ROBOTICS AND HUMAN MACHINE

INTERACTION

Montecillo-Puente, Francisco Javier; Samano-Abonce Obed Noé; Medina-Reza Alejandro; Villaseñor-Aguilar Marcos Jesús

Instituto Tecnológico Superior de Salvatierra

Resumen

(2)

plataformas permitirá explorar nuevas áreas de investigación y contribuir a la solución de problemas que la comunidad de robótica plantea.

Palabras clave

Plataforma robótica, componentes de software, lógica de intercambio de información, robótica de servicio, interacción humano máquina.

Summary

The robotic research platforms consist of the integration of real robots, sensors, computers, software components and information exchange logic. ROS, YARP, Genom and OpenHRP are some examples of existing platforms. Generally, robots have at least one processor and include a real-time or embedded operating system to perform control and processing tasks. In these platforms, robots are programmed to perform some predetermined activity or behave reactive, that is, they execute instructions that are sent through a communication protocol by an external system. The central function of the robot is to control its actuators and sensors. However, to provide the robot with greater capacity, additional processing is used, whether it is embedded in the robot or remote. Basic processing tasks are computer vision, voice recognition, speech synthesizing, decision making, collision detection and movement planning. This processing comes in the form of software components and is integrated with the robot through an information exchange logic. In this paper, we present the development and implementation of a robotic platform that includes the Kuka robot or Nao robot, software components and information exchange logic. The software components are: computer vision, robot simulation, motion planning, generation of trajectories of movement and collision detection. The operation of the platform is evaluated through a demonstration that performs visual tracking of objects using color. In addition, collision detection, physical parameters of the robot are considered and the latency of the system is analyzed. The results of the evaluation of the monitoring system shows that the platform has the requirements for service robotics and human-machine interaction. The frequency for the visual tracking demonstration is approximately 25 ms for Nao and 10 ms for the Kuka robot. Having this type of platform will allow exploring new areas of research and contribute to the solution of problems that the robotics community poses.

Keywords

(3)

1. Introducción

La incursión de la robótica tuvo como principal objetivo el sector productivo, la Federación Internacional de Robótica (IFR) estima que 2.5 millones de robots estarán instalados en la industria para el 2019, (1). Actualmente, la investigación sobre la robótica industrial se considera agotada respecto a mecanismos, sistema de control, protocolos de comunicación, planificación de movimientos, así como efectores finales sencillos de dos dedos. Sin embargo, nuevas áreas y aplicaciones de la robótica se han originado, una de estas es la robótica de servicio. La IFR define un robot de servicio como un robot que realiza tares útiles para los humanos o equipo excluyendo aplicaciones de automatización industrial, (1). Esta área da origen a nuevos retos y problemáticas, para visualizar la transformación robots industriales a robots de servicio en las tareas que realizan se establecen dos ejes relacionados con el tipo de tarea y su complejidad, (2). En un primer eje la tarea puede ser rutinaria (repetitiva) o no rutinaria, y 2) en otro eje la tarea puede ser manual o cognitiva. En el primer cuadrante se encuentran los robots industriales que se utilizan para realizar tareas que requieren habilidades bajas como las realizadas en líneas de ensamble, que son manuales y repetitivas. En el cuadrante opuesto se encuentran los robots de servicio que realizan actividades que requieren de habilidades altas o especialidades, tales como robots médicos o carros autónomos. Por tanto, los robos de servicio requieren de mayores capacidades cognitivas y destreza.

La robótica de servicio a diferencia de la robótica industrial ocupa de características como percepción, toma de decisiones, ejecución de acciones, interacción y autonomía. Algunas plataformas robóticas que incluyen o que pueden desarrollar estas características han sido implementado, tales como ROS, YARP, GenoM y OpenHRP, (3;4;5;6;7). Esta plataformas consideran robots reales con sistema operativo y de control propios, sensores para percepción, componentes de software (percepción, planificación, detección de colisiones, acción), una capa de comunicación entre robots o computo remoto. Estas plataformas fueron diseñadas para dar soporte a robots de investigación, que en un principio no están a la venta y por tanto replicar la arquitectura es un tarea de grandes dimensiones. El robot RP2, (8) , es un robot de dos brazos y montado sobre una plataforma con locomoción a ruedas cuyo sistema fue desarrollado completamente en ROS por la incubadora de tecnología Willow Garage. Un robot que utiliza YARP es el robot iCube cuyo propósito en un principio fue el desarrollo de métodos cognitivos, (9), por Istituto Italiano di Tecnologia como parte del proyecto EU RobotCub. Actualmente, 20 laboratorios en el mundo cuentan con la plataforma. En el LAAS-CNRS su robot Jido es desarrollado utilizando GenoM, (10). ASIMO el robot de Honda que se considera el robot mas autónomo a la fecha, fue desarrollado en secreto y sobre su implementación se conocen pocos detalles, (11). Además, los robots HRP2 del AIST de Japón y el robot Hubo del Kaist de Corea del Sur han mostrado grandes avances en sus plataformas (7;12).

(4)

rol muy importante para en la integración del robot con sus nuevas capacidades. Principalmente la lógica de intercambio de información y el computo distribuido son dos herramientas proveer esenciales de tales plataformas. En este artículo se presenta el desarrollo e implementación de una plataforma de robótica de servicios que soporta robots Kuka y robots Nao. Esta plataforma incluye componentes de software para visión por computadora, simulación del robot, planificación de movimiento, generación de trayectorias de movimiento y detección de colisiones. También se incluye una lógica de intercambio de información entre los robots y las computadoras de procesamiento remotas. El contenido de este artículo se organiza como sigue: en la sección 2 se describe la infraestructura utilizada, se presenta el diagrama a bloques de la plataforma y su implementación. Posteriormente, los resultados y una demostración de seguimiento visual de objetos de color es presentado en la sección 3. Finalmente, las conclusiones finales se presentan en la sección 4.

2. Materiales y plataforma robótica

En esta sección se presentan las características del hardware y software utilizado para la implementación del la plataforma robótica. Se describen las características de los robots y la infraestructura para comunicación utilizada.

2.1. Equipo y material utilizado

(5)

Figura 1. En esta imagen se presenta el Robot Kuka y sus componentes.

(6)

Figura 2. El Robot Nao se programa utilizando sistemas Linux, Windows y OS X.

El computo remoto tanto para el robot KUKA y Nao se realiza con estaciones de trabajo con sistema operativo Linux u OSX. Sin embargo, la versión Linux Ubuntu 14.0 LTS para el robot Nao o cualquier versión de Windows para las estaciones remotas. La estación de trabajo para el robot Kuka debe estar equipada con comunicación Ethernet y con Wifi para el caso del robot Nao. Un switch y un access point son necesarios para establecer comunicación e integrar la lógica intercambio de información entre los robots y la estación de trabajo remoto.

2.2. Descripción de la plataforma

(7)

desarrollo un simulador con motor grafico basado en OpenGL 2.0. El resto de los componentes son muy parecidos para ambos robots, excepto por su configuración, geometría y modelado matemático. La comunicación entre el controlador del robot y el nivel aplicación se realiza a través de una lógica de intercambio de información, para ambos casos se utiliza el protocolo TCP/IP vía alámbrica para el robot Kuka y vía inalámbrica para el robot Nao. El nivel de aplicación del robot se encuentra en una estación remota.

(a) (b) (c)

Figura 3. (a) Partes de la integración de la plataforma. (b) Componentes para plataforma robot Kuka. (c) Componentes para plataforma robot Nao

2.3. Lógica de intercambio de información

La lógica de intercambio de información entre el robot Kuka y el nivel de aplicación en la plataforma se lleva acabo utilizando JOpenShowVar, (16). Para los robots Kuka se requiere de contar con un servidor en el lado del robot y un cliente en el lado de la aplicación. En el lado del controlador, sistema Windows 7 embarcado, se utiliza un servidor KUKAVARPROXY y se configura el archivo $CONFIG.DAT para definir las variables del sistema del robot que se pueden compartir. Del lado del cliente, se utiliza JOpenShowVar que es un cliente en java que permite la comunicación vía TCP/IP. Por ejemplo, un mensaje que se puede enviar es POS={X,Y,Z,A,B,C} donde definen la posición y orientación del herramental o E6AXIS={A1,A2,A3,A4,A5,A6} que permite enviar las posiciones angulares de cada uno de los seis ejes del robot. La tarea final se desarrolla en C++ utilizando los módulos a nivel de aplicación, se genera la información a enviar al robot y vía TCP/IP localmente se envía el mensaje a JOpenShowVar que se comunica con el robot. Para otras marcas de robots o modelos este componente comunicación es la que se debe cambiar para soportarlos. En el caso del robot

Lógica de intercambio de información

Lógica de intercambio de información

(8)

Nao la lógica de intercambio de información que utiliza es naoqi-sdk que es parte de las herramientas con las que cuenta el robot.

2.4. Componentes de software

Para proveer de mayores capacidades a los robots, a estos se deben integrar componentes de software adicionales. El componente para el modelado matemático del robot es robot-sdk. Cada robot se modela por una cadena de segmentos conectados por juntas rotacionales, (17). El modelo del robot considera lo siguiente: parámetros Denavit-Hartenberg, los límites de cada junta, masa de cada segmento, centro de masa y parámetros inerciales. El bloque de generación de movimientos utiliza el modelo geométrico del robot y la cinemática inversa generalizada, esto es el modelo diferencial del robot que considera restricciones geométricas. El modelo diferencial resuelve una variación diferencial de los ejes del robot respecto a una variación en la posición y orientación del herramental. La solución se encuentra mediante el calculo numérico de la pseudo inversa, (18). Otro bloque consiste en la planificación de movimientos que consiste en generar una secuencia {q1,…, qn} que realiza algún movimiento en particular (19), donde qi es el vector que representa las posiciones angulares de las juntas del robot. Además, se consideran los limites angulares de las juntas y las colisiones con sus segmentos u otros objetos. El bloque de toma de decisiones consiste en modelar el problema creando una base de conocimiento al robot, que se toma en cuenta para la ejecución de la tarea. Este bloque implementa algoritmos de reconocimiento de patrones y modelos ocultos de Makov, (20). La interacción del robot con en ambiente y la planificación de movimientos ocupan el bloque de detección de colisiones. Este bloque se realiza con un modelado geométrido del robot y de los objetos basado en cajas orientadas OBB, (21). El bloque de percepción de la plataforma hace uso de las librerías OpenCV, (22). Para del robo Nao se utiliza la versión 2.3 por compatibilidad. Para la simulación del robot Kuka se utiliza el modelo geométrico del robot y OpenGL como motor grafico, (23). La simulación incluye colisiones y se utiliza el formato .obj, para cargar la geometría del robot se asume que sus segmentos se representan por una malla de triángulos. En el caso del robot Nao, este se distribuye con el simulador Webots (14).

3. Resultados y demostraciones

(9)

reglas difusas, (24). Utilizando la localización de la región de color se determina el movimiento que el robot realizará con:

qk = qk-1+f(xk - xk-1) (1)

donde qk, xk,  y f representan los valores de las posiciones angulares de las juntas, el centroide del objeto de color, parámetro de suavizado de seguimiento y una función que nos permite convertir posiciones en la imagen a posiciones angulares de las juntas del robot, respectivamente.

Figura 4. Diagrama de seguimiento visual de objeto.

Los bloques de envío de mensaje y ejecución de movimiento, incluyen la lógica de intercambio de información entre el cliente a nivel aplicación, finalmente el movimiento generado es ejecutado por el robot. La implementación del sistema de seguimiento se llevó a cabo tanto en el robot Nao como en el robot Kuka, la diferencia en la implementación radica en la lógica de intercambio de información y sus interfaces de comunicación, como se menciono anteriormente. En el bloque de detección de objetos se considera la actualización de las características de color y una predicción de la localización del objeto utilizando un filtro de Kalman, (24).

3.1. Demostración de seguimiento de color

(10)

Figura 5. Secuencias de seguimiento de objetos para el robot Kuka y Nao.

3.2. Evaluación de la plataforma

(11)

Tabla 1. En esta tabla se muestran los tiempos requeridos para ejecución de algunos procesamientos en la plataforma para los robots Nao y Kuka.

Nao Kuka

Lógica de intercambio de información,

20 ms

(sin transmisión de video)

5 ms

Detección de objetos,

computadora remota

1 ms 1 ms

Retraso de la red, < 0.2 ms

(sin transmisión de video)

< 0.2 ms

Generación de movimientos,

computadora remota

1 ms 1 ms

Detección de colisiones, usando OBB

5 ms 3 ms

Tiempo del ciclo de control ~27.2 ms 10.2 ms

4. Discusión y conclusiones

Los componentes de la plataforma para el robot Kuka se pueden replicar prácticamente para cualquier tipo de robot manipulador. La lógica de intercambio de información es el elemento más importante a considerar para incluir otros robots. Respecto al rendimiento de la plataforma, la detección de colisiones y el procesamiento de imágenes son componentes que dependiendo de la aplicación pueden ser computacionalmente costosas. Por lo que en aplicaciones específicas son factores que se deben atender o en su caso considerar estaciones de trabajo con capacidades superiores. Con la integración de los componentes presentados se puede realizar robótica de servicio o interacción humano máquina ya que los tiempos de control son de 25ms y 10 ms para los robots Nao y Kuka, respectivamente. Este parámetro es muy importante para salvaguardar la integridad de los humanos y del robot, así como para el ciclo de percepción-acción. Ya que se puede tener un tiempo suficiente para realizar un paro de emergencia en caso de detectar algún problema y se puede tener una capacidad reactiva elevada. La velocidad de movimientos del robot debe ser estudiada ya que dependiendo de la tarea esta debe ajustarse automáticamente. Por ejemplo, cuando no hay objetos cercanos al robot, este puede desplazarse a mayor velocidad que cuando está en un ambiente con varios objetos en movimiento.

(12)

5. Referencias

(1) International Federation Robotics, “The Impact of Robots on Productivity, Employment and Jobs”, IFR Press Releases, April 2017.

(2) Decker M., Fischer M. and Ott I., “Service Robotics and Human Labor: A first technology assessment of substitution and cooperation”, Robotics and Autonomous Systems, Vol. 87, 2017, pp.348–354.

(3) Robot operating system (ros), 2017, http://www.ros.org

(4) Rockel S., Klimentjew D., Zhang and L., Zhang, J. “An Hyperreality Imagination based Reasoning and Evaluation System (HIRES)”, International IEEE Conference on Robotics and Automation, ICRA 2014.

(5) Metta G., Fitzpatrick P. and Natale L., “YARP: Yet Another Robot Platform”, International Journal of Advanced Robotic Systems, Vol. 3(1), 2006, pp.43-48.

(6) Bruyninckx H., Fleury S., and Mallet A, “A specification of generic robotics software components: future evolutions of GenoM in the Orocos context”, International IEEE/RSJ Conference on Intelligent Robots and Systems, IROS 2002.

(7) Kanehiro F., Hirukawa H. and Kajita, S., “OpenHRP: Open Architecture Humanoid Robotics Platform”, International Journal on Robotic Research, Vol. 23, 2004, pp.155-165.

(8) Cousins S., “ROS on the PR2”, IEEE Robotics & Automation Magazine, 2010, Vol. 17(3), pp. 23-25.

(9) Tikhanoff V., Cangelosi A. and Metta G., “Integration of Speech and Action in Humanoid Robots: iCub Simulation Experiments”, IEEE Transactions on Autonomous Mental Development, Vol. 3(1), 2011, pp. 17-29.

(10) Sisbot E.A., Clodic A., Alami R. and Ransan Maxime, “Supervision and Motion Planning for a Mobile Manipulator Interacting with Humans”, 3rd ACM/IEEE International Conference on Human-Robot Interaction, HRI-2008.

(11) http://asimo.honda.com/

(12) Park I.-W., Kim J.-Y., Lee J., Kim M.-S., Cho B.-K. and Oh J.-H., “Development of Biped Humanoid Robots at the Humanoid Robot Research Center, Korea Advanced Institute of Science and Technology (KAIST)”. Humanoid Robots: Human-like Machines.2007.

(13) KUKA Roboter GmbH, “KUKA System Software: Operating and Programming Instructions for System Integrators”, 2012.

(13)

(15) https://www.cyberbotics.com/

(16) Sanfilippo F., Hatledal L. I., Zhang H., Fago M., Pettersen K. Y., “Controlling Kuka Industrial Robots: Flexible Communication Interface JOpenShowVar”, Robotics & Automation Magazine IEEE, Vol. 22, 2015, pp. 96-109.

(17) Craig J. J., “Robótica”, Pearson Educación, 2006.

(18) Yoshida E., Kanoun O., Esteves C and Laumond J.-P., “Task-driven support polygon reshaping for humanoids”, 6th IEEE-RAS International Conference on Humanoid Robots, 2006, pp. 208-213.

(19) LaValle S., “Planning Algorithms”, Cambridge: Cambridge University Pres, 2006. (20) Theodoridis S. and Koutroumbas K., “Pattern Recognition”, Academic Press, 2008. (21) Ericson C., “Real-Time Collision Detection”. CRC Press, 2004.

(22) www.opencv.org (23) www.opengl.org

(24) Montecillo-Puente F.J. and Ayala-Ramirez V., “Tracking Based On Fuzzy Color Blobs”, Acta Universitaria, Vol. 22, 2012, pp. 27-34.

Correspondencia

Dr. Francisco Javier Montecillo Puente. Email: [email protected] M.C. Obed Noé Samano Abonce. Email: [email protected]

M.C. Alejandro Medina Reza. Email: [email protected]

M.C. Marcos Jesus Villaseñor Aguilar. Email: [email protected]

ITESS - Instituto Tecnológico Superior de Salvatierra

Departamento de Tecnologias de la Información y Comunicaciones Calle Manuel Gómez Morin No. 300, C.P. 38933

Comunidad de Janicho, Salvatierra, Guanajuato, México. Tel: (+52) 466 66 398 00

Referencias

Documento similar

A continuous map in robotics is a representation of the environment around the robot as it is, without any use of discretization, based only on the sensors readings. Since

Hacer una arquitectura de control para las tareas de Alcance y Agarre representa una oportunidad para centrarse en los problemas de control para manipular objetos;

Como vemos, los requisitos para el uso de Leap Motion como dispositivo de realidad virtual son mucho más superiores que para su uso como dispositivo de

Ofrece una amplia variedad de productos basados en la nube, incluidos recursos de para procesamiento de datos, almacenamiento, bases de datos, análisis, redes,

&#34;No porque las dos, que vinieron de Valencia, no merecieran ese favor, pues eran entrambas de tan grande espíritu […] La razón porque no vió Coronas para ellas, sería

Esto viene a corroborar el hecho de que perviva aún hoy en el leonés occidental este diptongo, apesardel gran empuje sufrido porparte de /ue/ que empezó a desplazar a /uo/ a

The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,

El documento se estructura en tres partes; en primer lugar, se desarrolla la parte sobre fundamentación epistemológica relacionada con la materia de Computación y Robótica y