Progreso junio 2024 - RoboticsURJC/tfg-dcampoamor GitHub Wiki

SEMANA 51 (27/05/2024-02/06/2024)

• Pruebas con OpenGL y generación de figuras geométricas mediante puntos

SEMANA 52 (03/06/2024-09/06/2024)

• Pruebas con OpenGL y generación de figuras geométricas mediante líneas

• Visión general de las interfaces de cliente del robot

• Pruebas de comunicación con robot mediante el método de llamada de procedimiento remoto XML-RPC

SEMANA 53 (10/06/2024-16/06/2024)

• Pruebas de comunicación con robot mediante el método de llamada de procedimiento remoto XML-RPC

• Implementación de Zoom y Movimiento con Teclado con OpenGL en 2D

SEMANA 54 (17/06/2024-23/06/2024)

• Pruebas de comunicación con robot mediante el método de llamada de procedimiento remoto XML-RPC

• Implementación de Zoom y Movimiento con Teclado con OpenGL en 3D

SEMANA 55 (24/06/2024-30/06/2024)

• Pruebas de comunicación de listas dinámicas al robot mediante el método de llamada de procedimiento remoto XML-RPC

• Uso de filtro de color para su utilización posterior con OpenGL

SEMANA 51 (27/05/2024-02/06/2024)

• Pruebas con OpenGL y generación de figuras geométricas mediante puntos

  Dado el problema que se daba a la hora de intentar modificar el programa pinhole.py para que en el mismo script también se reprodujeran las formas detectadas de un color definido en OpenGL, se optó por probar a elaborar en primer lugar un script en python que se denominó OpenGL_Unificado.py, que utilizaba OpenGL y en el que se muestran las figuras geométricas que se formaban a partir de una serie de puntos recibidos (simulando los detectados).

  

  Pruebas OpenGL_Unificado.mp4 es el vídeo en el que se muestra el funcionamiento de este script, y en el cual se puede apreciar como en función de los puntos aleatorios que se generen, se genera de igual forma una figura geométrica distinta.

SEMANA 52 (03/06/2024-09/06/2024)

• Pruebas con OpenGL y generación de figuras geométricas mediante líneas

  Tras comprobar como poder generar figuras geométricas a partir de puntos generados de manera aleatoria, simulando los puntos detectados, se pasó a volver a intentar representar lineas, combinando el uso de OpenCV para la detección de líneas en frames de video en tiempo real y OpenGL para la representación de esas líneas en una ventana separada en el script OpenGL_DeteccionLineas.py.

  

  Este código, que pese a verse en la imagen que este script se llama pinhole_modificado_prueba.py , finalmente se renombró como OpenGL_DeteccionLineas.py. Este programa combina OpenCV y OpenGL para capturar vídeo en tiempo real, detectar líneas y visualizarlas gráficamente. OpenCV captura frames de video de la cámara, detecta líneas y muestra el feed de la cámara en una ventana separada. Las líneas detectadas se almacenan en una variable global para su posterior uso en la visualización con OpenGL.

  OpenGL se encarga de renderizar las líneas detectadas en una ventana gráfica. Se inicializa y configura una ventana de OpenGL con GLUT, definiendo una función de renderizado (draw_lines) que limpia los buffers, configura la cámara virtual y dibuja las líneas en amarillo. Un temporizador actualiza y redibuja la ventana cada 16 milisegundos, asegurando una visualización continua y en tiempo real de las líneas detectadas. Este temporizador llama a la función de actualización de la cámara para obtener nuevas líneas y redibujar la ventana, manteniendo la representación sincronizada con el feed de video en tiempo real.

  En el vídeo OpenGL_DeteccionLineas.mp4 se puede ver como funciona este código.

• Visión general de las interfaces de cliente del robot

  Dado que el robot UR puede interactuar con dispositivos externos mediante distintos tipos de interfaces de comunicación, se estudió de manera general a través de cual de todas estas era más viable y sencillo establecer la comunicación con el ordenador, y por tanto, con el programa que corriera la detección de fresas en el futuro.

  En el apartado de interfaces de comunicación con un software de terceros, encontramos que esta comunicación puede tener lugar mediante:

  • Sockets: El robot UR puede comunicarse con equipos externos a través del protocolo TCP/IP. Los datos pueden transferirse a través de la comunicación socket entre el robot y otro dispositivo. En la comunicación socket, el robot actúa como cliente y el otro dispositivo como servidor. URScript proporciona comandos que abren y cierran sockets, y envían y reciben diferentes formatos de datos. Este tipo de comunicación es el que se estuvo probando en Progreso octubre 2023, en los apartados de Pruebas de código y programa para enviar a un robot UR a una posición determinada por un sistema de visión externo, Pruebas de código para enviar una cadena a un servidor y recibir por socket una lista de enteros y Pruebas de código y programa para enviar a un robot UR a una posición determinada por un sistema de visión externo.

  • XML-RPC: XML-RPC es un método de llamada a procedimiento remoto que utiliza XML para transferir datos entre programas a través de sockets. Con él, el controlador UR puede llamar a métodos/funciones (con parámetros) en un programa/servidor remoto y obtener de vuelta datos estructurados. Mediante su uso, se puede realizar un cálculo complejo que no está disponible en URScript. Además, se pueden combinar otros paquetes de software con URScript.

  • RTDE (Real-Time Data Exchange): La interfaz de intercambio de datos en tiempo real (RTDE) proporciona una forma de sincronizar aplicaciones externas con el controlador UR a través de una conexión TCP/IP estándar, sin romper ninguna propiedad en tiempo real del controlador UR. Esta funcionalidad es útil, entre otras cosas, para interactuar con controladores de bus de campo (por ejemplo, Ethernet/IP), manipular E/S del robot y trazar el estado del robot (por ejemplo, sus trayectorias). La sincronización es configurable y puede incluir, por ejemplo, los siguientes datos:

    • Salida: estado del robot, la articulación, la herramienta y la seguridad, E/S analógicas y digitales y registros de salida de propósito general.
    • Entrada: salidas digitales y analógicas y registros de entrada de propósito general.

    La funcionalidad RTDE se divide en dos etapas: un procedimiento de configuración y un bucle de sincronización.

• Pruebas de comunicación con robot mediante el método de llamada de procedimiento remoto XML-RPC

  Para muchos lenguajes de programación existen servidores XML-RPC gratuitos, entre otros para: Python, Java, C++ y C. Debido al uso de python en el proyecto, se ejecutó un ejemplo sencillo siguiendo los pasos recogidos en el documento XMLRPC.pdf en el que queremos hacer que el robot se mueva utilizando una pose recuperada de una cámara remota falsa. El programa de la "cámara" remota, que proporciona la siguiente pose objetivo, se ejemplifica en Python en xmlrpc_server.py, mientras que el programa utilizado en el robot es xmlrpc_example.urp.

  

  Después de corroborar que todo estaba correctamente configurado, se llevó a cabo la prueba, que se grabó y se puede ver en xmlrpc_example.mp4.

SEMANA 53 (10/06/2024-16/06/2024)

• Pruebas de comunicación con robot mediante el método de llamada de procedimiento remoto XML-RPC

  El siguiente paso a probar después de ejecutar el ejemplo recogido en el punto anterior, fue que, en lugar de pasarle una única pose al robot, se le pasaran varias poses en un array, para de este modo, comprobar si el robot seguiría este orden y pudiera alcanzar el número de posiciones facilitadas en el orden establecido.

  

  Dado que se te tomó como base el ejemplo recogido en el documento XMLRPC.pdf, en un principio, en la parte del programa del robot, se siguió utilizando la posición de la herramienta del robot argumento como parámetro en la función get_next_pose(p). Al seguir utilizando este argumento para este caso en el script guardado en este repositorio como xmlrpc_server_severalpos.py e intentar ejecutar el programa, se reprodujo el siguiente error:

  

  Para intentar solventar este fallo, se modificó la función get_next_pose(), que se pasó a utilizar sin argumento, lo que permitió ejecutar el programa sin ningún mensaje de fallo o error. Sin embargo, a pesar de que sí que existía comunicación entre el PC y el robot, consultando en el Símbolo del sistema de Windows (sistema operativo en el que se realizaron las pruebas), se podía observar como aparecía únicamente el mensaje "Listening on port 50000...", pero no se producía ningún movimiento en el modo simulación del robot.

• Implementación de Zoom y Movimiento con Teclado con OpenGL en 2D

  Debido a la imposibilidad de que en los programas en los que se ha modificado en el script pinhole para mostrar la reconstrucción de la figura geométrica detectada a partir de varios puntos se mostrase dicha reconstrucción, se planteó la posibilidad de que esto fuera debido a que se estuviera representando en otra ubicación dentro de la ventana o que estuviera escalado de tal manera que no se pudiera apreciar esta reconstrucción geométrica.

  Por esto, se decidió llevar a cabo pruebas basadas en la página Learn OPenGL y el repositorio de github pyZPR, en las cuales se llevaba a cabo un script llamado zpr.py que proporciona una introducción básica a cómo configurar una escena 2D utilizando OpenGL en Python con GLFW. Permite interactuar con la cámara para explorar la escena y ajustar el zoom para cambiar la perspectiva visual.

  

  La ejecución y demostración de este programa se puede ver en los videos Zoom OpenGL.mp4 y Zoom OpenGL PantallaCompleta.mp4.

SEMANA 54 (17/06/2024-23/06/2024)

• Pruebas de comunicación con robot mediante el método de llamada de procedimiento remoto XML-RPC

  Para poder solventar que no se produjese ningún tipo de movimiento en el robot pese a tener establecida comunicación mediante el protocolo XMLR, se llevaron a cabo varios cambios en el programa xmlrpc_server_severalpos.py, que tras estos cambios se pasó a guardar en este repositorio como xmlrpc_server_3positions.py.

  Se mantuvo el hecho de no recibir parámetros en la función get_next_pose() y se estructuró el programa de tal manera que simplemente se devolviera una lista predefinida de poses, en lugar de listas que utilizasen funciones que no están definidas en el script y que se utilizaban para el ejemplo con una única pose en xmlrpc_server.py, como las funciones poseToList y listToPose.

  Con todo esto, se consiguió que funcionase el programa, incluyendo la llamada al servidor XML-RPC para obtener la siguiente pose del robot y el comando que mueve el robot a la posición especificada en next_pose en un bucle para garantizar que el robot se mueva continuamente a nuevas posiciones proporcionadas por el servidor XML-RPC.

  

  En el vídeo xmlrpc_example_3positions.mp4 se puede observar como el robot va a las 3 posiciones proporcionadas por la lista de poses en el programa de python. El problema es que, las coordenadas de las poses que están configuradas para el robot se refieren al sistema de referencia de la base del robot.

  Cuando las poses se definen en función de la base del robot y no del TCP, la diferencia entre dos modelos distintos de UR, en este caso se llevó a cabo el ejemplo básico con una sola pose con un UR5e y estas últimas pruebas con un UR3e, puede afectar principalmente en términos de alcance y la configuración de las juntas. Dado que el UR3e tiene un radio de alcance más pequeño (500 mm) comparado con el UR5e (850 mm), las posiciones absolutas en el espacio que son accesibles para el UR5e pueden no estar dentro del alcance del UR3e, y tal y como se puede observar en el vídeo, a pesar de poder ejecutarse el programa, al tratarse de un modo simulación dentro del propio robot, se intentan alcanzar unas posiciones, en las que, seguramente de ejecutarlo y llevarlo a cabo sin este modo, obtendríamos algún tipo de mensaje de error en cuanto a límite de juntas, singularidad de las mismas, errores de colisión y/o errores debidos a la aceleración y velocidad del robot (como por ejemplo Protective Stop: Velocity limit exceeded) entre otros.

• Implementación de Zoom y Movimiento con Teclado con OpenGL en 3D

  Dado que se probó con el script zpr.py la Implementación de Zoom y Movimiento con Teclado con OpenGL en 2D, se llevó a cabo un nuevo script llamado scene_navegation.py que crea una escena en 3D utilizando OpenGL en Python donde se dibuja un cubo y que permite al usuario interactuar con la escena de dos formas: moviendo la cámara con las teclas de flecha y rotar la figura que se muestra (en este caso un cubo) con el ratón; y controlar el zoom con la rueda del ratón mientras que la posición de la cámara es ajustada según las teclas de flecha presionadas.

  

  El vídeo Interaccion con cubo 3D movimiento con raton.mp4 muestra las primeras pruebas en las que se consiguió utilizar unicamente el ratón para hacer zoom y moverse por la escena, mientras que el vídeo Interaccion con cubo 3D rotacion y traslacion.mp4 es en el que se puede observar el funcionamiento final de scene_navegation.py explicado anteriormente.

SEMANA 55 (24/06/2024-30/06/2024)

• Pruebas de comunicación de listas dinámicas al robot mediante el método de llamada de procedimiento remoto XML-RPC

  Después de lograr que el robot fuera a 3 posiciones distintas provenientes de una lista con estas 3 posiciones, tal y como se puede puede ver en el vídeo xmlrpc_example_3positions.mp4, se intenta que en vez de repetir estas posiciones de manera continua, se vaya una única vez, como si se tratase de una lista dinámica, de tal manera que, aunque de manera consecutiva según su ubicación en esta lista, no se vuelvan a repetir, modificando el programa de robot también para ello. Al ejecutar el programa xmlrpc_server_listadinamica.py se obtiene lo siguiente en el robot al haberse movido a 2 de estas 3 posiciones:

  

  Donde, si pulsamos en la opción "Continuar" el robot alcanza la posición restante, emitiendo, acto seguido el siguiente mensaje de fallo en la interfaz de robot:

  

  Sin embargo, tras pulsar la opción "Continuar" en el popup en la interfaz robot y que este fuera a la posición restante de la lista, si consultamos el Símbolo del sistema de Windows (cmd), se puede observar que, en teoría, el proceso se ha realizado sin ningún tipo de incidencia, finalizando el programa, lo cual no corresponde con lo que realmente ocurre, ya que se debería de alcanzar el último punto previa emisión del popup en el TeachPendant del robot.

  

  Este proceso se recoge en el vídeo xmlrpc_server lista dinamica fallo.mp4.

• Uso del filtro de color para su utilización posterior con OpenGL

  Aprovechando la Implementación de Zoom y Movimiento con Teclado con OpenGL en 3D, se llevó a cabo el programa DetectionOpenGL_CameraControl.py que utiliza OpenCV para la parte de procesamiento de imágenes y detección de color, capturando video y detectando los puntos de color amarillo en tiempo real mediante un filtro de color basado en el espacio de color HSV, y OpenGL para renderizar estos puntos en una ventana.

  

  El funcionamiento del programa se recoge en el vídeo DeteccionOpenGL_CameraControl.mp4