Progreso marzo 2025 - RoboticsURJC/tfg-dcampoamor GitHub Wiki

Progreso marzo 2025

SEMANA 79 (24/02/2025-02/03/2025)

SEMANA 80 (03/03/2025-09/03/2025)

SEMANA 81 (10/03/2025-16/03/2025)

SEMANA 82 (17/03/2025-23/03/2025)

SEMANA 83 (24/03/2025-30/03/2025)

SEMANA 84 (31/03/2025-06/04/2025)

SEMANA 79 (24/02/2025-02/03/2025)

  • Solución del porcentaje de confianza de las detecciones mostradas por pantalla

    Dado que la confianza (cls_conf) seguía apareciendo como 1.00 en todas las detecciones, lo cual indicaba que el valor que se estaba obteniendo no es el correcto o que estaba siendo modificado en alguna parte del código, se modificó la sección donde se muestra la confianza en la imagen para asegurar que se está usando el valor correcto:

    for i, det in enumerate(detection):
  if len(det) == 7:  # Asegurar que la detección tiene los valores esperados
      x1, y1, x2, y2, conf, cls_conf, cls_pred = det  # Obtener correctamente la confianza

      # Verificar qué valores tiene cls_conf
      print(f"[DEBUG] Confianza detectada en P{i+1}: {cls_conf}")

      # Dibujar el recuadro de detección en el frame
      color = (255, 0, 0)  # Azul para la caja delimitadora
      cv2.rectangle(frame, (int(x1), int(y1)), (int(x2), int(y2)), color, 2)

      # Etiqueta con "Fresa" y número de detección (P1, P2, ...)
      label = f"Fresa - P{i+1}"
      cv2.putText(frame, label, (int(x1), int(y1) - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.5, color, 2)

      # Mostrar confianza de la detección correctamente
      confidence_text = f"{float(cls_conf):.2f}"  # Asegurar que se muestra correctamente
      cv2.putText(frame, confidence_text, (int(x2) + 10, int(y1)), cv2.FONT_HERSHEY_SIMPLEX, 0.5, color, 2)

    Sin embargo, el mensaje de [DEBUG] seguía mostrando que la confianza era 1.0. Esto ocurría ya que, al introducir la numeración de las detecciones (P1, P2, ...), probablemente cambió la forma en que se extraía el valor de confianza (cls_conf), algo en la forma en que se itera sobre las detecciones podría estar causando que la confianza siempre sea 1.0.

    Por este motivo se intentó volver a modificar el mismo fragmento de código, pero se seguía obteniendo el mismo resultado:

    El hecho de que cls_conf siempre fuera 1.0 sugería que en alguna parte del código, el valor de confianza se estaba asignando incorrectamente o que la función non_max_suppression() estaba devolviendo un valor máximo en lugar del real. La función non_max_suppression() está normalizando la confianza de detección, lo que puede estar haciendo que se devuelva 1.0 en todas las detecciones porque el modelo fuera cargados con valores procesados de forma errónea. Otra de las posibilidades de que esto estuviera ocurriendo era que, en algunas versiones de YOLO, el valor correcto de confianza es conf y no cls_conf, siendo la diferencia entre ambas que conf representa la confianza de detección antes de aplicar la clasificación de la clase.

    Por todo esto, se procedió a modificar la línea siguiente:

    x1, y1, x2, y2, conf, cls_conf, cls_pred = det

    Por esta:

    x1, y1, x2, y2, cls_conf, conf, cls_pred = det

    Con lo que se consiguió obtener finalmente valores razonables y lógicos sobre la confianza de la detección. Esto puede observarse en el vídeo Pruebas confianza deteccion y threshold.mp4.

  • Corrección de la tolerancia en las detecciones

    Actualmente, la distancia configurada en el código xmlrpc_deteccionfresas.py para la distancia threshold era de 0.1 mm, distancia usada para comparar detecciones entre frames y evitar que el sistema registre la misma detección repetidamente, ya que si una nueva detección está a menos de este umbral de distancia de una anterior, se considera la misma detección y no se vuelve a registrar. Se modificó este umbral hasta dejarlo en 0.5 mm, ya que 0.1 mm era un valor muy pequeño como para prevenir y/o evitar esta duplicación de las detecciones.

    En este código inicializa una lista previous_positions para almacenar las posiciones de detecciones anteriores mientras que se establece el umbral o margen threshold_distance = 5, que define qué tan cerca pueden estar dos detecciones antes de considerarlas la misma. Se recorren todas las detecciones en positions, y para cada posición pos se comparan con las posiciones anteriores prev_pos usando la función calcular_distancia_3d(), y si la distancia es menor que threshold_distance se considera la misma fresa y no se agrega como nueva, pero si es mayor que este valor, se guarda como nueva en filtered_positions y en previous_positions para futuras comparaciones.

    De igual manera, en el vídeo Pruebas confianza deteccion y threshold.mp4 puede observarse como aún moviendo en este caso el móvil con las imágenes de las fresas, a no ser que deje de detectar la fresa, si la imagen sufre movimientos leves no detecta como si fuera otra detección imprimiéndolo por pantalla. Lo que sí se ha detectado es que, si se deja de detectar momentaneamente una fresa y se detecta a la vez otra, esta nueva fresa pasa a tomar la referencia de la anterior, es decir, si se está detectando Fresa - P1, y se deja de detectar por cualquier factor, pero se detecta la fresa que estaba al lado, esta nueva fresa puede pasar a denominarse Fresa - P1, lo que si únicamente se mira la terminal podría llevar a confusión, pero que, con la ventana destinada a mostrar lo que ve la cámara y a marcar las detecciones se ve claramente.

  • Elaboración del Resumen de la memoria

    De manera paralela a la consecución de pruebas, se elaboró la primera versión del Resumen de la memoria, a la espera de las posibles modificaciones a posteriori.

  • Pruebas de la distancia de las detecciones a la cámara

    Para comprobar que definitivamente el problema con las distancias a las detecciones estaba solucionado, y antes de volver a pasar a realizar pruebas conjuntas con robot real, se llevaron a cabo pruebas de detección conociendo las coordenadas y distancias reales respecto a la cámara. En primer lugar, utilizando una fresa real, y conociendo la altura a la que se situó la cámara en el soporte y habiendo medido su inclinación, se ejecutó por primera vez el programa para comprobar estas distancias y detecciones.

    Para estas pruebas se utilizó una altura de 151 mm desde la mesa a la cámara y una inclinación de 62º, obteniendo los siguientes resultados:

    Con estos resultados, se observó primeramente que la distancia obtenida por pantalla en comparación de la distancia teórica no coincidía, es decir, que la distancia que se mostraba por pantalla y el cálculo de la distancia que se obtenía con las coordenadas de la detección no eran iguales, por lo que se revisó el código para ver por qué motivo sucedía esto, solucionándose al tomar la posición de la cámara como origen de coordenadas, es decir, como punto [0,0,0].

    Para verificar que estos cambios que se habían realizado se volvió a ejecutar el programa, obteniendo los siguientes resultados con solamente 5 posiciones para verificar que las distancias que se mostraban por pantalla coincidían con el cálculo, pero se volvió a medir la altura de la cámara, observando que en lugar de 151 mm se encontraba a 145 mm.

    De las tablas de resultados anteriores (los obtenidos con la altura de cámara de 151 mm), tomando la distancia calculada de las coordenadas mostradas por terminal, es decir, la distancia teoríca ya que la distancia obtenida por terminal era errónea, se obtuvieron las siguientes gráficas para poder comparar las coordenadas de los ejes X e Y y las distancias obtenidas por pantalla de las detecciones y las reales que habían sido medidas previa ejecución del programa.

    A partir del análisis de estos resultados obtenidos se observa que las coordenadas proyectadas de las fresas situadas en los extremos del campo de visión (FoV) de la cámara presentan valores anómalos o significativamente desviados respecto a los reales, es decir, aquellas fresas detectadas en cualquiera de los extremos del campo de visión de la cámara, ya sea el límite superior, inferior o cualquiera de los dos límites laterales, reportan grandes desviaciones respecto a las coordenadas y distancias reales, siendo la zona central del campo de visión la que más exacta llega a ser tanto en las coordenadas del eje X e Y como en distancias, llegando a tener para P5 una desviación de 1,92 mm en las coordenadas del Eje x, 32,93 mm para el Eje Y y 3,65 mm de desviación en la distancia, siendo este el punto obtenido con mayor precisión de la serie. Esta desviación se debe principalmente a efectos geométricos del modelo de proyección pinhole, que es el utilizado para este proyecto, donde pequeñas variaciones en la posición de los píxeles en los bordes del sensor implican grandes errores en las coordenadas proyectadas, especialmente si se trabaja con una proyección a un plano con profundidad o altura fija. Además, al acercarse al límite angular del FoV, los rayos proyectados se vuelven casi tangenciales al plano de referencia, lo que genera coordenadas extremadamente grandes o incluso tiende a valores infinitos.

SEMANA 80 (03/03/2025-09/03/2025)

  • Pruebas de la distancia de las detecciones a la cámara

    Una vez solucionado el problema con el cálculo de las distancias y verificado, se volvió a medir el ángulo de inclinación de la cámara y se ejcutó de nuevo el programa para evaluar una muestra mayor que la que se hizo con solucionar el error de las distancias, y ver si al haber afinado más la medición tanto de la altura de la cámara como del grado de inclinación de esta, se obtenían resultados más cercanos a los reales. Para esta serie de puntos, la altura era de 145 mm desde la mesa a la cámara y una inclinación de 59º.

    En esta serie, al igual que en la anterior, y las cuales están recogidas en el documento Pruebas distancia detecciones.xlsx, pese a algún valor obtenido atípico, se puede observar que la región del campo de visión de la cámara con mayor exactitud es la región central, en la que, el P7 presenta una desviación de 4,25 mm en las coordenadas del Eje X, 12,19 mm para el Eje Y y 3,43 mm de desviación en la distancia, siendo este el punto obtenido con mayor precisión.

    Además, ya que anteriormente las pruebas se habían realizado o bien con imágenes de fresas o al inicio con post-it pintados de color verde sobre la mesa blanca para que se identificasen mejor, se probó a medir el alto de la fresa para restárselo a la distancia que presentaba la cámara sobre la mesa, por si estos 2 cm (que fue el alto que se midió desde la mesa hasta la mitad de la fresa) afectasen algo en el cálculo matemático para determinar la posición y distancia de la detección, utilizándose para ello los mismos puntos que en el caso anterior.

    Como resultado se puede observar que, los datos obtenidos son similares a los que se obtuvieron con la distancia total de la cámara a la mesa, es decir, despreciando la posible altura que pudiera tener la fresa para restarla a esta distancia para su detección. Donde más cambios se aprecian es en las coordenadas del Eje Y, donde se puede apreciar que en numerosos puntos se reduce la diferencia entre las coordenadas reales y las obtenidas, sin embargo, se amplían estas diferencias en estos puntos para las coordenadas del Eje X y en las distancias totales. Por este motivo, al observar que los resultados son similares y que no existe una mejora notoria respecto a despreciar la altura de la fresa, se optó por seguir despreciándolo para medidas y experimentos posteriores.

SEMANA 81 (10/03/2025-16/03/2025)

  • Pruebas de la distancia de las detecciones a la cámara con diferentes ángulos y altura

    Para verificar que los cálculos y la matemática detrás del programa eran válidos, se modificó la altura y ángulo de giro de la cámara y se volvieron a llevar a cabo medidas. Para esta serie de puntos, la altura era de 252 mm desde la mesa a la cámara y una inclinación de 69º.

    Tal y como pasaba en pruebas anteriores, para valores de la región inferior o superior de la cámara, los valores obtenidos no se asemejan a los reales. Sin embargo, a pesar de haber obtenido algún valor atípico, los resultados entorno a una distancia de 600 mm en el Eje X empiezan a asimilarse y acercarse a los reales, siendo el P18 (600,-30,252) mm uno de los puntos que menor desviación presenta con 12,19 mm en el Eje X, 47,21 mm en el Eje Y y 10,79 mm de desviación en cuanto a la distancia junto con el P22 (700,0,252) mm con una desviación de 13,76 mm en el Eje X, 17,91 mm para el Eje Y y 12,71 mm en distancia.

    El proceso de medición y configuración para estos experimentos puede verse en los vídeos Proceso de medición de altura de la cámara.mp4, Proceso medición pruebas distancias fresas reales.mp4, Proceso de medición fresas.mp4 o Medición distancias fresas para Z 252 mm region central.mp4 entre otros.

SEMANA 82 (17/03/2025-23/03/2025)

  • Pruebas de detección múltiple con fresas reales

    De la misma manera que se testeó con una fresa real, se probó a poner varias fresas al mismo tiempo para comprobar como respondía el programa al respecto y que se obtenía.

    De esta primera prueba con varias fresas reales de manera simultánea, cuyo proceso se puede ver en el vídeo Primera prueba deteccion multiple con fresas reales.mp4, se consiguió observar que para el caso que se probó, es decir, para el caso de tres fresas, a pesar de mostrar los tres puntos diferenciados en la ventana de "Detección de fresas", por terminal no se diferencian bien ni se llega a mostrar las coordenadas y distancia a la tercera detección.

  • Proyección con OpenGL de las detecciones y el campo visual de la cámara para resolver los problemas en las mediciones con el Eje Y

    Dado que después de llevar a cabo varias mediciones con distintos valores de altura de la cámara y ángulo de inclinación de la misma se llegó a la conclusión de que los resultados obtenidos para el Eje Y (eje correspondiente con el eje transversal de la mesa sobre la que se encontraba la cámara) no se acercaban a la realidad en ninguna región que no fuera sobre el Eje X, es decir, para un valor de Y cercano a 0 como distancia real, se propuso utilizar OpenGL para intentar identificar de manera visual de dónde podía venir este problema o si realmente estas desviaciones no se podían considerar tan significativas como se creía en un inicio.

    Para ello se proyectó de manera paralela a la ejecución del programa en una ventana a parte, el plano de la cámara sobre el que se dibujó a su vez el recuadro de la detección y posteriormente el centroide de este recuadro.

    Lo primero que se programó y ejecutó fue lo que puede observarse en la imagen anterior, y que está recogido en el vídeo Primer intento xmlrpc_deteccionfresas_OpenGL.mp, donde se ve que sobre el plano de la cámara se proyecta el recuadro de la detección en la zona en la que se ubica esta proyección, coincidiendo con el campo de visión de la cámara.

    Después de esto, se incluyó que, en esta ventana de OpenGL se pudiera navegar cambiando la rotación y el zoom dentro de esta ventana que representaba con OpenGL el plano cámara y la detección dentro de ese plano, tal y como se puede ver en el vídeo Proyeccion deteccion centroide OpenGL con ejes cambiados.mp4.

    Por último, se cambiaron los ejes de dirección para que coincidieran con la orientación que se había supuesto para los experimentos y se calculó el centroide del recuadro de detección para que únicamente se mostrase esto en el plano. Estos cambios pueden verse en el vídeo Proyeccion deteccion centroide OpenGL.mp4.

  • Elaboración del Abstract de la memoria

    Se elaboró el abstract de la memoria como traducción del resumen de la misma.

SEMANA 82 (24/03/2025-30/03/2025)

  • Proyección con OpenGL de las detecciones y el campo visual de la cámara para resolver los problemas en las mediciones con el Eje Y

    Dado que únicamente se había proyectado con OpenGL el plano cámara y no el plano mesa, se añadió este plano para comprobar si la deformación del recuadro de la detección suponía un polígono que entrase dentro de lo que se podía considerar normal o en cambio se apreciaba que el problema estaba en esta proyección del plano cámara al plano de trabajo o plano mesa en este caso.

    Para este primer intento se volvió a utilizar el vértice de la pirámide como si fuera la cámara, y en la ventana Detección y Proyección 3D en la que se representaba con OpenGL todo esto se podía observar que tanto el plano mesa como esta detección podría coincidir con la proyección que se estaba buscando, ya que para esto se habían utilizado en el código las funciones backproject_pixel_to_3d y get_3d_polygon.

    La primera función utiliza un píxel (px, py) y lo convierte a coordenadas ópticas usando la función pixel2optical para posteriormente utilizar la inversa de la matriz intrínseca (K) y la inversa de la parte de rotación de la matriz de transformación (RT) de la cámara, obteniendo el vector direccional del rayo que sale del centro óptico a través de ese píxel. Finalmente, se calcula el factor de escala para que la intersección de ese rayo con el plano de la mesa (definido en z = 0) se obtenga mediante la fórmula, donde cam_pos[2] es la posición en z de la cámara (–252 mm en este caso):

    factor = -cam_pos[2] / ray_dir[2]

    La función get_3d_polygon llama a backproject_pixel_to_3d para cada una de las 4 esquinas del bounding box (definido en píxeles) y así obtiene 4 puntos 3D en el plano de la mesa. Esa lista de 4 puntos forma el polígono irregular que representa la proyección real del recuadro de detección sobre la mesa.

    Posteriormente, se le volvieron a añadir a la cámara, representada como el vértice de la cámara los ejes de coordenadas que se habían considerado para los experimentos.

    En el vídeo Proyeccion plano mesa OpenGL con ejes coordenadas.mp4 se puede ver este proceso y resultado del uso del programa xmlrpc_deteccionfresas_OpenGL.py actualizado para que pudiera llevar a cabo lo anteriormente mencionado.

  • Solución del problema de impresión por pantalla de los datos de la detección múltiple con fresas reales

    Ya que se había observado en Pruebas de detección múltiple con fresas reales que existían ciertos problemas con lo que se mostraba por terminal, ya que no se diferencian bien ni se llegaban a mostrar las coordenadas y distancias de todas las detecciones, se intentó solucionar esto.

    En primer lugar se modificó la forma de imprimir cada detección en la terminal para que cada punto tuviera su propio índice mediante enumerate, de esta forma, en caso de que cada fresa supere el umbral de tolerancia establecido en threshold respecto a las demás, aparecerá su propio índice y se listará correctamente en la terminal. Sin embargo, al realizar la prueba tras cambiar el código con 3 fresas reales, en la terminal únicamente se mostraban las coordenadas y distancias relativas a dos de ellas pese a detectarse las tres.

    El problema de esto era que se estaba usando una lista global (previous_positions) que acumulaba las detecciones de fotogramas anteriores para filtrar las detecciones actuales. De esta forma, aunque en un fotograma se detectasen varias fresas y sus coordenadas fueran distintas, al compararlas con las detecciones acumuladas de fotogramas previos se descartaban como duplicados, incluso cuando en realidad eran fresas diferentes. Para solucionarlo, se filtró las detecciones solo dentro del mismo fotograma, es decir, en lugar de comparar cada detección con todas las anteriores (de todos los fotogramas), se compararían únicamente con las detecciones ya aceptadas en el fotograma actual. De esta forma, si en el mismo fotograma hubiera 3 o 4 fresas (y sus coordenadas fueran suficientemente distintas según el umbral de 5 mm), se mostrarían todas.

    A pesar de mostrarse después de estas últimas modificaciones en el código todos los puntos detectados, se mostraban continuamente nuevos datos de coordenadas y distancias en la terminal, tal y como se puede ver en la imagen anterior y en el vídeo Pruebas deteccion multiple_Deteccion de todos los puntos continuamente.mp4. Esto ocurre porque, aunque las fresas estaban en la misma posición, para cada fotograma la detección variaba ligeramente debido al ruido inherente (pequeñas fluctuaciones en las coordenadas). Para poder solucionar esto, se aplicó un umbral de “estabilidad” o margen de error al comparar las posiciones actuales con las ya impresas, de modo que se “suavicen” estas fluctuaciones, es decir, aunque las detecciones variasen se considerarán iguales si se encontrasen dentro de este margen y no se imprimirá de nuevo. Para conseguir esto, se introdujo la variable stability_threshold para determinar cuándo se consideran las posiciones iguales, superando así las pequeñas fluctuaciones de cada fotograma, además de la función positions_are_similar, que se utilizó para comparar la lista de detecciones actuales (filtered_positions) con la última lista impresa (last_printed_positions), y si la diferencia era menor que stability_threshold, se consideraba que las fresas no habían cambiado de posición, y no se volvía a imprimir nada.

    En el vídeo Pruebas deteccion multiple solucionado.mp4 se puede observar como después de aplicar estos cambios al código se consiguió obtener el resultado deseado exceptuando el caso cuando las fresas están totalmente pegadas, ya que los centros de las detecciones en 3D resultan tan próximos que la diferencia entre ellas cae por debajo del umbral utilizado para filtrar detecciones similares dentro del mismo fotograma, es decir, el sistema entiende que, al estar tan cerca, en realidad se trata del mismo objeto, por lo que agrupa esas detecciones en una sola y/o omite una de ellas hasta que se separan atendiendo al parámetro del umbral y se vuelven a detectar todas.

    Este comportamiento es el esperado del filtro por proximidad ya que su función es evitar que se impriman múltiples entradas para lo que podría ser la misma fresa en caso de pequeñas variaciones, sin embargo, cuando los objetos están muy próximos entre sí, el filtro acaba combinándolos y solo se muestra una detección.

SEMANA 84 (31/03/2025-06/04/2025)

  • Pruebas de la distancia de las detecciones a la cámara con diferentes ángulos y altura

    Después de realizar la proyección con OpenGL de las detecciones y el campo visual de la cámara para resolver los problemas en las mediciones con el Eje Y, y observar que aparentaba estar bien hecha esta proyección, al no poder realizar muchas más pruebas más allá de estas pruebas visuales, ya que no se puede más que obtener trazas, se volvieron e ejecutar pruebas con una altura y grado de rotación de la cámara distintos a las anteriores pruebas realizadas cuyos resultados se encuentran en el documento Pruebas distancia detecciones.xlsx.

    Para esta serie de puntos, la altura era de 180 mm desde la mesa a la cámara y una inclinación de 58º.

    De las tablas de resultados anteriores se obtuvieron las siguientes gráficas para poder comparar las coordenadas de los ejes X e Y y las distancias obtenidas por pantalla de las detecciones y las reales que habían sido medidas previa ejecución del programa.

    Tal y como pasaba en pruebas anteriores, para valores de la región inferior o superior de la cámara, los valores obtenidos no se asemejan a los reales. Sin embargo, a pesar de haber obtenido algún valor atípico, los resultados entorno a una distancia de 250-300 mm en el Eje X empiezan a asimilarse y acercarse a los reales, siendo el P7 (250,0,180) mm uno de los puntos que menor desviación presenta con 0,7 mm en el Eje X, 21,85 mm en el Eje Y y 1,34 mm de desviación en cuanto a la distancia junto con el P10 (280,0,180) mm con una desviación de 26,11 mm en el Eje X, 5,38 mm para el Eje Y y 21,60 mm en distancia y el P14 (300,10,180) mm con una desviación de 22,72 mm en el Eje X, 22,42 mm para el Eje Y y 19,73 mm en distancia.

    Sin embargo, de igual manera que en los experimentos anteriores, se observó que a partir de cierto valor en el que se había supuesto como Eje X (eje longitudinal de la mesa), los valores obtenidos para el supuesto Eje Y disminuían, siendo cada vez vez más negativos, sin asemejarse para nada con los supuestos valores reales. Para este caso, por ejemplo, se puede ver que a partir del P13, los valores del Eje Y disminuyen desde -3,52 mm hasta -55,65 para el P25 (450,0,180) mm.

    La discrepancia se debe a la forma en que se define y se aplica la transformación geométrica (rotación y traslación) de la cámara en el modelo pinhole, ya que la función que convierte los píxeles a coordenadas ópticas (pixel2optical) y la transformación que realiza la proyección inversa (getIntersectionZ) intercambian y modifican los ejes. Esto implica que el eje que se obtiene en la proyección 3D no coincida necesariamente con el sistema de coordenadas que se ha supuesto para la mesa. El hecho de que se use un ángulo de, para este caso, 58° en la rotación (thetaY) significa que la cámara está inclinada respecto a la mesa, y como resultado, lo que se interpreta como el eje longitudinal (Eje X real) se mapea en una combinación de los ejes de la cámara, y puede ocurrir que la componente que se asocia a Y se invierta o se desvíe a medida que se aleje del origen, por lo que podría ser que la proyección estuviera generando una inversión en el eje Y debido a la combinación de la rotación de la cámara y la forma en que se intercambian los ejes en la conversión.

    Para comprobar si el problema estaba en que el que se suponía como Eje Y se encontraba invertido, se creó un nuevo input para la función getIntersectionZ que, al activarlo, invertía el signo de la componente Y. De ese modo, se podía comparar los resultados obtenidos con y sin invertir y ver cuál se acercaba más a los puntos de referencia reales.

    En este fragmento se puede ver cómo después de hacer la inversión de la matriz intrínseca (inv_K) y de la matriz de rotación/traslación (inv_RT), p3d_h contiene las coordenadas 3D (en el espacio de la cámara) correspondientes al píxel de la imagen (𝑝2𝑑[0],𝑝2𝑑[1]). Se denomina _h (homogéneo) porque inicialmente se trata de un vector con la componente Z todavía no “normalizada”, y a menudo se incluye una cuarta componente si fuese estrictamente homogéneo. Con p3d_h *= escala, se ajusta la escala para que la proyección coincida con la altura de la cámara, para este caso Z=180mm, siendo al final del proceso, p3d_h el punto 3D en el sistema de la cámara. Para invertir el Eje Y, cuando invert_y=True, se ejecuta p3d_h[1] *= -1, que multiplica la componente Y por -1, esto significa que, en términos geométricos si antes el punto tenía coordenadas (𝑋,𝑌,𝑍), ahora tendrá (𝑋,−𝑌,𝑍).

    Después de activar la opción invert_y = True, se volvió a ejecutar el programa xmlrpc_deteccionfresas.py y se repitieron las mediciones para los puntos P7 a P24 de los últimos experimentos, es decir, para la altura de 180 mm desde la mesa a la cámara y una inclinación de 58º, obteniendo los siguientes resultados:

    Tal y como se puede observar, en algunos puntos mejora la aproximación al valor real al invertir el eje Y tanto para los valores de ese eje como para los del Eje X, pero en otros empeora. Es decir, no existe un patrón único en el que todos los puntos se ajusten mejor con el eje Y invertido o no invertido. La inversión del eje Y solo corrige un posible error de signo (cambia 𝑌 a −𝑌), pero no corrige cualquier inclinación o rotación adicional de la cámara por mínima que sea, la distorsión de la lente en las zonas periféricas, un offset mal medido o pequeñas inexactitudes en la altura, en la ubicación real de la cámara, etc.

    Aún con el ajuste de signo, se observan errores notables en varias posiciones alejadas, lo que puede indicar que no se trata de un simple cambio de signo, sino de una combinación de factores (rotaciones en más de un eje, desalineación, distorsiones de lente, etc.), además, a medida que te alejas del origen o del centro de la imagen, la geometría de proyección hace que los errores se magnifiquen (especialmente si la cámara tiene distorsión residual o si la altura/ángulo real no coinciden perfectamente con los valores introducidos).