Progreso diciembre 2024 - RoboticsURJC/tfg-dcampoamor GitHub Wiki

Progreso diciembre 2024

SEMANA 70 (25/11/2024-01/12/2024)

SEMANA 71 (02/12/2024-08/12/2024)

SEMANA 72 (09/12/2024-15/12/2024)

SEMANA 73 (23/12/2024-29/12/2024)

SEMANA 70 (25/11/2024-01/12/2024)

  • Modificaciones en el código para detección de fresas y movimiento de robot

    Para poder solucionar que, pese a ejecutarse, no se detectasen las fresas, se modificó el código en Python, creando el código xmlrpc_deteccionfresasv1.py y posteriormente el xmlrpc_deteccionfresas.py.

SEMANA 71 (02/12/2024-08/12/2024)

  • Pruebas con el nuevo código para detección de fresas y comunicación con el robot

    Durante las modificaciones de código, a la hora de testear su funcionamiento, se obtuvieron diferentes errores, principalmente del tipo AttributeError, TypeError y RuntimeError, al igual que, debido a que se intentó incluir durante estas pruebas también la parte de conexión con el robot para la comunicación con el programa en Python, también se produjeron ciertos problemas derivados de los cambios necesarios para que esto se pudiera producir.

    Se obtuvo el error TypeError: pic should be PIL Image or ndarray. Got <class 'torch.Tensor'> , debido a que el código intentaba convertir un tensor de PyTorch en una imagen, pero el tipo de dato no era el esperado, tratando un tensor de PyTorch como si fuera una imagen en formato PIL o ndarray. Para solucionarlo se convirtió explícitamente el tensor de PyTorch a un formato de imagen adecuado antes de pasarlo a cualquier operación que espere una imagen (numpy.ndarray).

    Al igual que el anterior error, el AttributeError: 'Image' object has no attribute 'shape' indicaba que el objeto Image que se estaba utilizando no tenía el atributo shape, ya que probablemente era un objeto de tipo PIL.Image y no un numpy.ndarray. La solución fue convertir la imagen a un formato adecuado (como un numpy.ndarray) antes de acceder a sus atributos como shape.

    AttributeError: numpy.ndarray object has no attribute 'dim' es un error que se dió debido a que el código intentaba acceder al atributo dim de un objeto numpy.ndarray, siendo ndarray.ndim el atributo correcto para obtener las dimensiones de un array en NumPy, no ndarray.dim, por lo que se solucionó modificandolo en el código, para obtener las dimensiones del array.

    El TypeError: 'tuple' object has no attribute 'unsqueeze' indicaba que se intentó llamar al método unsqueeze en un objeto de tipo tuple, pero este método solo estaba disponible para tensores de PyTorch, no para tuplas, por lo que se configuró para que el objeto que fuera un tensor de PyTorch antes de llamar a este método.

    Tras estos cambios, se obtuvo un código de error RuntimeError: CUDA error: out of memory, causado por la falta de memoria en la GPU para realizar las operaciones necesarias. Esto sucedía ya que, el modelo de YOLO y/o el vídeo que se estaba procesando en tiempo real consumían demasiados recursos para la memoria disponible en la GPU.

    Por lo que se consultó el uso de la GPU mediante la herramienta nvidia-smi para poder ajustar el código en consecuencia, observando que los procesos de Python estaban consumiendo la mayor parte de la memoria de la GPU, ocupando aproximadamente 3126 MiB, lo que representa un uso significativo del total disponible.

    Con todo esto, se consideró procesar el video en CPU en lugar de GPU, aunque esto podría influenciar en la velocidad del procesamiento del vídeo y la detección, siendo más lento. Después de realizar este cambio, se volvió a intentar ejecutar el programa, sin embargo, se obtuvieron esta vez problemas con la identación en ciertos bloques del código relacionados con la configuración del servidor, cuya solución fue revisar el código en la línea mencionada (línea 157 en este caso) y confirmar que la indentación fuera correcta, modificando los espacios o tabulaciones que causaban que Python no interpretase correctamente el bloque de código,y aunque no se reflejaban problemas con la conexión al servidor, no se habría la cámara ni se podía comprobar si se realizaban correctamente las detecciones.

  • Modificaciones en el formato de las detecciones

    Una vez solucionado estos problemas, se ejecutó de nuevo el código, obteniendo detecciones a través de la cámara. Viendo el formato del texto y el recuadro de las detecciones, se decidió ir modificando esto junto con el formato de los print que mostraban por la terminal el estado del programa y las detecciones, por lo que se tuvieron diferentes versiones, en las que se fueron variando tanto el color como el grosor de los recuadros y el texto de la clase detectada, el umbral de confianza del modelo para esa detección y los datos y la forma de estos datos que se mostraban por pantalla una vez se estaba ejecutando el programa.

    En primer lugar, se quiraron las coordenadas de las detecciones de la ventana en la que se mostraban estas y se fue cambiando el color del texto y el recuadro junto con el grosor del mismo.

    En los vídeos xmlrpc_deteccionfresasv1.mp4 y xmlrpc_deteccionfresas recuadro sin editar.mp4 se muestra como tras realizar algunos cambios, el color azul se diferencia sin problema, pudiendo ver la detección, sin embargo, el grosor del umbral de la detección es demasiado grande, y en las detecciones en las que el recuadro es pequeño, se solapa el texto de la clase con el del umbral, impidiendo poder verlo de una manera clara.

    Tras cambiar los parámetros para poder arreglar esto, se fijó el color azul y el grosor del texto en 2, y se obtuvieron los resultados que se pueden ver en el vídeo xmlrpc_deteccionfresas con texto en recuadro arreglado.mp4 o en Pruebas xmlrpc_deteccionfresas.mp4.

  • Añadidos del Capítulo 3: Objetivos y elaboración del Capítulo 4:Plataforma de desarrollo

    Se terminó de escribir el Capítulo 3: Objetivos de la memoria y se inició la escritura del Capítulo 4: Plataforma de desarrollo sobre las distintas plataformas de desarrollo, tanto hardware como software, que han facilitado el logro de los objetivos del Capítulo 3: Objetivos.

SEMANA 72 (09/12/2024-15/12/2024)

  • Elaboración del Capítulo 4: Plataforma de desarrollo

    De manera paralela a la consecución de pruebas, se continuó escribiendo el Capítulo 4: Plataforma de desarrollo de la memoria reuniendo la información y los detalles del hardware y software utilizado en la consecución del trabajo.

  • Pruebas de comunicación y envío de posiciones al robot

    Se empezaron a realizar pruebas del envío de las posiciones de las detecciones de las fresas con el robot real, a partir del código xmlrpc_deteccionfresas.py, aunque en las primeras pruebas se le volvió a cambiar el nombre a xmlrpc_server.py ya que se creía que algunos problemas pudieran venir del nombre del archivo, aunque luego se verificó que no era así, volviendo a retomarse el de xmlrpc_deteccionfresas.py, para corroborar si el robot era capaz de ir al punto correcto.

    En los primeros intentos, se obtuvieron errores relacionados con la función get_next_pose como NameError: name 'get_next_pose' is not defined, que ocurría porque el programa intentaba registrar la función en el servidor XML-RPC, pero no se encuentraba esa función definida en el código en el momento en que se intentaba registrar, por lo que se modificó el código para poder tener bien definida la función get_next_pose.

    De igual manera, se obtuvo el [ERROR] No se pudo enviar la posición al robot: name 'result' is not defined, ya que se habían introducido mensajes de depuración o mensajes de debug para verificar el correcto funcionamiento del código, donde la variable result no estaba definida y se intentaba hacer uso de la variable result para enviar las coordenadas del punto detectado al robot a través del servidor XML-RPC, pero nunca se asigna o inicializa esa variable. Para poder solucionarlo, en lugar de result, se enviaron las coordenadas de la posición directamente.

    En cuanto a problemas obtenidos en la interfaz del robot, se produjeron varios errores como: XMLRPC: Fallo con l código de error 1: <class 'TypeError'>: "cannot marshal None unless allow_none is enabled", debido a que el sistema intentaba enviar un valor None (un valor nulo) mediante el método XML-RPC, y este tipo de valores no son permitidos a menos que la opción allow_none esté habilitada. Para solventar esto, se revisó que todas las variables que se enviaban tuvieran valores válidos antes de enviarlas, evitando que se enviasen valores nulos.

    XMLRPC: Fallo con el código de error 1: <class 'NameError'>:name 'done_pose' is not defined, que significaba que la variable o función done_pose reflejada en el código en Python no había sido definida o no estaba en el alcance del programa del robot en el momento en que se intentaba utilizar, por lo que se revisó el código y se modificó para solucionarlo.

    Error de tipo: La variable de tipo "Matrix" no puede indexarse, que surgía ya que se estaba intentando indexar una variable de tipo Matrix, lo cual no era posible porque las matrices no pueden ser indexadas como listas o arrays. Por este motivo,se cambió la manera de facilitar los datos al programa de robot, para poder acceder a sus elementos de manera correcta.

    Error de tipo: La variable de tipo "Bool" no puede indexarse, ya que se intentó indexar una variable de tipo booleano (True o False), lo cual no es posible porque los valores booleanos no tienen elementos que puedan ser indexados. Como los errores anteriores, se solucionó revisando las variables utilizadas y cambiando el tipo de varible, ya que, al necesitar acceder a elementos dentro de una lista o matriz, la variable debía ser de tipo lista, no booleana.

    Por último, también se obtuvo un error relacionado con la función get_next_pose() en la interfaz del propio robot, más concretamente el error XMLRPC: Fallo con el código de error 1: <class 'TypeError'>: get_next_pose() missing 1 required positional argument: 'positions', puesto que requería un argumento llamado positions que no se estaba proporcionando. Para poder solucionar esto, se estructuró el código de otra manera, puesto que la función get_next_pose() no debería tener argumentos de entrada.

    Tras solucionar estos problemas, se consiguió realizar pruebas de detección de fresas y envío de las coordenadas al robot y comprobar si el robot recibía estas coordenadas correctamente y se movía tras la recepción de las coordenadas.

    En estas pruebas, hubo problemas al principio, a la hora de recibir las coordenadas a través de la variable next_pose.

    Este problema sucedía ya que no se recibía ninguna coordenada, tal y como se puede ver en el vídeo Problemas en envio de posiciones de detecciones de fresa a UR.mp4, pero finalmente, este problema se consiguió solucionar, como se muestra en el vídeo Pruebas deteccion de fresas y envio posiciones a UR.mp4.

SEMANA 73 (23/12/2024-29/12/2024)

  • Desarrollo e impresión de topes para pruebas con la cámara integrada del ordenador

    Ya que estas pruebas, por comodidad, se realizaban con la cámara integrada del ordenador, para poder comprobar si las detecciones se realizaban correctamente, y poder cargar los parámetros intrínsecos y extrínsecos de la cámara correctamente, conociendo la altura y el ángulo con el que se encuentra, apuntando al objetivo, se diseñaron e imprimieron varios topes con el programa Autodesk Fusion 360, para poder inclinar la tapa superior del ordenador con un ángulo conocido, y poder introducir posteriormente este valor en el código.

    Los archivos para su impresión en PLA con una impresora 3D son CCR10S_Tope30.gcode y CCR10S_Tope55.gcode, ya que se hicieron estos dos topes con distintos valores de inclinación.

  • Elaboración del Capítulo 4: Plataforma de desarrollo

    Se continuó escribiendo el Capítulo 4: Plataforma de desarrollo de la memoria reuniendo la información y los detalles del hardware y software utilizado en la consecución del trabajo.