Yuriy Alejandro Moreno Salomón

Estudiante del grado de Ingeniería en Sistemas Audiovisuales y Multimedia en la Universidad Rey Juan Carlos

3 minute read

Motivación del cambio de .PLY a .PCD

Tras hablar con el compañero sobre los problemas que le daban las nubes de puntos del dataset, específicamente sobre las intensidades ya que se guardaban en el campo normals, se decidió investigar más sobre los dos tipos de archivos que se suelen usar para guardar nubes de puntos, además de que sugirió usar el .pcd. Investigando se vio que aunque .ply soporta campos personalizados, su estructura no está estandarizada para ello, lo que dificulta el soporte en herramientas de terceros.

Por el contrario, .pcd es el formato nativo de la biblioteca PCL y permite describir de forma clara y explícita todos los atributos por punto. Esto lo hace más apropiado para datasets LiDAR semánticos.

Implementación en el proyecto

Se modificó la función lidar_callback para usar “open3d.t.geometry.PointCloud”, lo que permitió definir los campos personalizados intensity y labels directamente como tensores. Luego, se utilizó “open3d.t.io.write_point_cloud()” para guardar los archivos en formato .pcd binario cada 20 frames.

Diferencias entre los formatos .pcd y .ply

PCD (Point Cloud Data)

  • Propósito: Fué diseñado específicamente para la biblioteca PCL (Point Cloud Library).

  • Estructura: Contiene un encabezado que define los campos presentes (como x, y, z, intensity, label, etc.) seguido de los datos.

  • Soporte de campos: Permite almacenar múltiples atributos por punto, incluyendo campos personalizados.

  • Formatos de almacenamiento: Puede ser almacenado en formato ASCII o binario.

Ventajas:

  • Optimizado para procesamiento de nubes de puntos.

  • Soporte nativo en PCL.

  • Fácil de extender con nuevos campos.

PLY (Polygon File Format)

  • Propósito: Fue originalmente diseñado para almacenar datos de polígonos, pero también se utiliza para nubes de puntos.

  • Estructura: Contiene un encabezado que define los elementos y propiedades (como x, y, z, red, green, blue, etc.) seguido de los datos.

  • Soporte de campos: Es posible añadir campos personalizados en el encabezado para cada punto, aunque con menor flexibilidad y soporte menos estándar que en PCD..

  • Formatos de almacenamiento: Puede ser almacenado en formato ASCII o binario.

Ventajas:

  • Amplio soporte en diversas aplicaciones de gráficos 3D.

  • Fácil de visualizar en herramientas como MeshLab.

open3d.t

open3d.t es la versión tensorial de Open3D, pensada para procesamiento eficiente de datos estructurados como nubes de puntos. A diferencia de la API clásica, este módulo está diseñado desde cero para aprovechar tensores multidimensionales, GPU, y paralelismo, lo que permite trabajar con grandes volúmenes de datos con mayor rapidez y flexibilidad.

Comparación entre estructuras:

  • open3d.geometry.PointCloud: Estructura clásica de Open3D. Adecuada para operaciones estándar y visualización.

  • open3d.t.geometry.PointCloud: Estructura basada en tensores. Optimizada para procesamiento en GPU y operaciones paralelas. Permite manejar atributos adicionales como intensity y labels.

Almacenamiento de campos personalizados

Una de las grandes ventajas de usar .pcd junto con “open3d.t.geometry.PointCloud” es la facilidad para definir y guardar atributos personalizados por punto, en este caso se ha decidido usar:

FIELDS x y z  r g b  intensity label 
SIZE   4 4 4  4 4 4     4        4   
TYPE   F F F  F F F     F        I   
COUNT  1 1 1  1 1 1     1        1

Descripción de los campos .pcd

Campo Tipo Tamaño Descripción
xyz float 3 Coordenadas espaciales del punto: x, y, z.
rgb float 3 Color RGB del punto normalizado [0.0–1.0] por canal: r, g, b.
intensity float 1 Intensidad del retorno LiDAR (atenuación del haz).
label int 1 Etiqueta semántica del punto

Fuentes

Problemas técnicos al compilar CARLA

Durante estas semanas se pudo avanzar menos de lo que se hubiese deseado debido a varios problemas técnicos que surgieron al intentar compolar CARLA. Al principio, se intentó ejecutar make launch como de costumbre pero se observó que CARLA dejó de funcionar debido a varios problemas. Tras investigar y probar varios métodos que se encontraron sobre personas con problemas parecidos, nada funcionó y al ver que el entorno ya habían surgido muchos problemas, se optó por reinstalar CARLA. Durante la reinstalación, iba todo bien hasta que se llegó al make PythonAPI, donde se presento un problema con el Boost 1.80.0 y Python 3.10:

...skipped <...>libboost_numpy310.so.1.80.0 for lack of <...>numpy/dtype.o...

Al investigar, se descubrio que era un problema al construir la biblioteca “boost_numpy” para Python 3.10. Una sugerencia de GitHub recomendaba usar Python 3.8, donde surgieron algunos problemas distintos y se dejó de lado. También se intento con Python 3.7.9, que al no estar presente directamente en Ubuntu 22.04, se tuvo que descargar manualmente, lo que no era viable al final al haber varios archivos ausentes para make PythonAPI. Tras muchos intentos se volvió a intentar usar Python 3.8, que logró funcionar tras solo reinstalar algunas dependencias.

You May Also Enjoy

Semana 22: Mapa Ladera

2 minute read

Mapa Ladera Este tipo de entorno plantea riesgos reales para la conducción autónoma como pendientes pronunciadas, vegetación densa, y caminos estrechos Con e...