Progreso octubre 2024 - RoboticsURJC/tfg-dcampoamor GitHub Wiki
SEMANA 64 (30/09/2024-06/10/2024)
- Pruebas de comunicación y uso de pinhole.py con robot real
- Elaboración del Capítulo 3: Objetivos de la memoria
SEMANA 65 (07/10/2024-13/10/2024)
- Depuración de la programación y pruebas con robot real
- Elaboración del Capítulo 3: Objetivos de la memoria
SEMANA 66 (14/10/2024-20/10/2024)
- Pruebas con robot real y cambios en la programación
- Elaboración del Capítulo 3: Objetivos de la memoria y añadidos al Capítulo 2: Estado del arte
SEMANA 67 (21/10/2024-27/10/2024)
SEMANA 64 (30/09/2024-06/10/2024)
-
Pruebas de comunicación y uso de pinhole.py con robot real
Para intentar solucionar el problema del Índice fuera de intervalo, el tamaño de la lista es inferior a 2 se llevaron a cabo algunas modificaciones en el programa de python, sin embargo, al volver a ejecutar el programa de python en la terminal y el mismo programa de robot en el robot, se obtuvo un nuevo mensaje de error.
Este error que mostraba la interfaz del robot indicaba que el programa está esperando una lista de 6 elementos, probablemente representando una posición completa en 3D (coordenadas X, Y, Z) y una orientación (Rx, Ry, Rz), que es el formato típico para definir una pose completa en el espacio tridimensional del robot, sin embargo, el servidor XML-RPC parece estaba enviando solo dos valores (X, Y) (que en principio son los unicos valores que se obtienen de la detección de puntos verdes), estando esperando el robot una pose completa de 6 elementos (X, Y, Z, Rx, Ry, Rz) para mover el brazo, por lo que se incluyeron estas variables en xmlr_server_primeraspruebas_robotreal.py.
Después de añadir las variables al programa en python y volver a ejecutar la aplicación, se obtuvieron los siguientes resultados:
El programa enviaba a las coordenadas del punto detectado al robot, y al cambiar el punto de posición, tras haber alcanzado el punto previo, el robot se movía a otro punto nuevo distinto.
Esto ocurría de manera contínua, ya que el programa de robot estaba configurado para ejecutarse en bucle, por lo que, cuando no se detectaba ningún punto, tal y como programado, se mostraba por terminal, y el robot se movía a la posición determinada como Home o Casa.
Todo esto puede observarse en el vídeo Pruebas funcionales pinhole y robot real un punto.mp4.
-
Elaboración del Capítulo 3: Objetivos de la memoria
De manera paralela a la consecución de pruebas, se continuó escribiendo el Capítulo 3: Objetivos de la memoria reuniendo la información de las guías docentes del grado para definir las competencias empleadas durante la consecución del trabajo.
SEMANA 65 (07/10/2024-13/10/2024)
-
Depuración de la programación y pruebas con robot real
Con el fin de poder alcanzar el punto real de detección con el robot, se siguió modificando y probando el programa de robot, esta vez introduciendo el uso de la función pose_trans , que utiliza la transformada de la posición obtenida por el sistema de visión, trasladando y rotando esta posición a los parámetros y sistema de coordenadas del robot, tal y como se hizo con el programa de prueba visionsimple.urp, pero cubriendo esta vez el método de recuperación de los datos de la cámara, ya que suministra los datos X, Y y rotación desde la posición de referencia.
Al modificar el programa e intentar volver a ejecutarlo se obtuvieron errores como Error de tipo: tipos de operando no compatibles con ==: [0,0,0,0,0,0] y [], tal y como se puede ver en el vídeo Error del tipo: tipos de operando no compatibles.mp4 en el que se prueba a ejecutar por primera vez el programa tras los cambios, y que indicaba que existía un problema de compatibilidad de tipos en la comparación que se estaba haciendo en esa línea del programa urp, ya que se estaba intentando comparar un array o pose (como [0, 0, 0, 0, 0, 0]) con otro tipo de dato vacío ([]), lo cual no es válido, por lo que se volvieron a condicionar todas las posiciones de la coordenada recibida por parte del sistema de visión.
Una vez solucionado esto y modificado alguna línea más de código, el siguiente error que se obtuvo fue _Error de tipo: Debe ser una pose, no "List" _, error que significaba que en alguna parte del código se está proporcionando una lista de valores en lugar de un objeto de tipo pose, que es lo que el programa del UR espera.
Este problema probablemente se encuentrase en la variable target, la cual se define mediante la función pose_trans().Para solventarlo, y asegurar que la función pose_trans() devuelve una pose válida (un tipo de dato específico que incluya posición y orientación en formato de pose), y no una lista, se utilizó lo que hasta ese momento había sido la variable fija de posición reference_point como una variable de tipo pose.
Sin embargo, el Error de tipo: el lado izquierdo de la expresión esperaba el tipo "List" pero encontró "Pose", por lo que se cambió finalmente por un waypoint que se enseñó directamente con el robot y se guardó en el programa.
-
Elaboración del Capítulo 3: Objetivos de la memoria
De manera paralela a la consecución de pruebas, se continuó escribiendo el Capítulo 3: Objetivos de la memoria detallando la metodología empleada.
SEMANA 66 (14/10/2024-20/10/2024)
-
Pruebas con robot real y cambios en la programación
Al modificar el punto de referencia y grabarlo con un waypoint, se volvió a ejecutar el programa, esta vez obteniendo el Error: La funcion de script movej no puede encontrar una solucion de la cinetica inversa.
Por este motivo se optó por cambiar el tipo de movimiento de **MoveJ **(movimiento articular), donde cada articulación del robot se mueve al mismo tiempo hasta alcanzar la posición objetivo, siendo un movimiento rápido y eficiente, sin ser la trayectoria de la herramienta (end-effector) lineal, lo que puede no ser adecuado para ciertas aplicaciones, por un movimiento de tipo MoveP (Pose Blending), que permite una transición suave entre múltiples posiciones sin detenerse, siendo muy útil en trayectorias complejas donde se requiere que el robot mantenga una velocidad constante.
Al volver a ejecutar el programa habiendo realizado estos cambios, se obtuvo el error movep: No se puede mover a la velocidad especificada debido a límites de seguridad tal y como se puede observar en el vídeo Programa posetrans movep velocidad.mp4, por lo que se modificaron los valores de velocidades y aceleraciones del movimiento.
-
Elaboración del Capítulo 3: Objetivos de la memoria y añadidos al Capítulo 1: Introducción
De manera paralela a la consecución de pruebas, se terminó de escribir el Capítulo 3: Objetivos de la memoria detallando la metodología empleada, y se añadió la mención al artículo sobre agricultura vertical y fresas de nombre La primera granja vertical de interior del mundo producirá 1,8 millones de kg de fresas al año, en el Capítulo 1: Introducción.
SEMANA 67 (21/10/2024-27/10/2024)
-
Pruebas con robot real
Al disminuir los valores de los parámetros del MoveP, se ejecutó el programa, tal y como se puede observar en el vídeo Programa posetrans UR3e.mp4, sin embargo, al tratarse de un robot cuyo alcance máximo es de 500mm, se aprecia que el robot está a punto de llegar al máximo rango posible.
Por este motivo, se utilizó un UR10e, como se puede apreciar en el vídeo Programa robot posetrans UR10e.mp4, el cual, con los parámetros del movimiento también disminuidos, no presentó ningún mensaje de error.