Point Cloud Subsampling Parallelization for Unified Memory Platforms
PParalelizaci ´on del submuestreo de nube de puntospara plataformas con memoria unificada
Martin Nievas ∗ , Claudio J. Paz ‡ and Gast´on R. Aragu´as § CIII - Centro de Investigaci´on en Inform´atica para la Ingenier´ıaUniversidad Tecnol´ogica Nacional Facultad Regional C´ordoba, Argentina ∗ [email protected], ‡ [email protected], § [email protected] Resumen —La exploraci´on de ambientes desconocidos me-diante robots es una tarea que integra distintas ´areas comolocalizaci´on por un lado y mapeo y planificaci´on por otro. En loque respecta al mapeo, existen diversos m´etodos para representarlos ambientes por los que puede transitar un robot, en dosy tres dimensiones. Se pueden mencionar grilla de ocupaci´onprobabil´ıstica , Octomap y STVL entre los m´as importantes los´ultimos a˜nos. En la actualidad, las c´amaras RGB-D son amplia-mente utilizadas para generar una representaci´on detallada delambiente. La misma presenta un gran volumen, el cual debeser reducido para poder utilizarse en plataformas de recursoslimitados de c´omputo.En este trabajo se presenta una implementaci´on del m´etodode diezmado de la nube de puntos capaz de ser ejecutado en unaplaca con memoria unificada. El mismo consiste en reducir lanube de puntos de manera iterativa utilizando una subdivisi´onordenada del espacio. Se obtuvieron resultados para distintostama˜nos de grillas, plataformas y escenarios tanto reales comosimulados. Los resultados indican que en sistemas embebidos esconveniente contar con arquitecturas que compartan memoriaentre CPU y GPU para optimizar los procesos de paso debloques de datos.
Index Terms —Exploraci´on, Rob´otica, Mapeo, Nube de Puntos,Sistemas Embebidos, GPU, Memoria Unificada
I. I
NTRODUCCI ´ ON En rob´otica, se conoce como exploraci´on al proceso me-diante el cual se busca aumentar la informaci´on respecto delentorno del robot para construir un modelo del ambiente quelo rodea. Se aplican los algoritmos de exploraci´on cuandose necesita conocer el estado de una locaci´on a la que nopueden acceder personas o hay un riesgo latente o manifiestoen su ingreso. Por ejemplo en estructuras colapsadas o conposibilidad de colapso en busca de sobrevivientes. En estascircunstancias los robots m´as utilizados son de dimensionesreducidas por su capacidad de atravesar aberturas peque˜nas.Debido a estos limitantes geom´etricos, la capacidad de c´ompu-to de estos robots tambi´en se ve limitada.Lo modelos generados por estos robots son ´utiles para podernavegar en estos ambientes, entendi´endose por navegar a latarea que permite llevarlo de un punto a otro de manera se-gura evadiendo obst´aculos. Los modelos pueden ser m´etricos,donde se trata de representar o reproducir la geometr´ıa delentorno; o topol´ogicos, donde se describe la relaci´on espacialentre distintos ambientes.Respecto de los m´etricos, durante a˜nos una de las formasm´as populares de representar el entorno fue mediante grilla de
Figura 1. Montaje utilizado para las pruebas en un escenario real ocupaci´on [1]. Este m´etodo consiste en representar el ambientebidimensional con un plano dividido en celdas formandouna grilla. Las celdas de la grilla son de tama˜no regular ycada una contiene un valor que representa la probabilidadde estar ocupada basada en modelos probabil´ısticos de lossensores involucrados. Derivaciones de este trabajo usandotres dimensiones con cubos llamados voxels se presentaronen trabajos como [2] y [3] mostraron ser ineficientes respectodel uso de memoria para almacenar el mapa debido al grantama˜no de los mismos.De forma m´as eficiente, el framework
Octomap [4] usa unaestructura en forma de ´arbol con ocho nodos, donde cada nodocomienza con un voxel que es dividido sucesivamente en otrosocho hasta alcanzar la resoluci´on deseada. Esta estructura esllamada octrees y fue propuesta por primera vez en [5]. Elvalor contenido en el voxel puede ser binario, un valor deprobabilidad que puede estar basado en distintos criterios o unavariante con una cota aplicada a una densidad de probabilidad.Si bien el Octomap hace mejor uso de la memoria, el acceso acada elemento tiene mayor costo computacional que la grillade ocupaci´on.Para mejorar el acceso a cada elemento, en [6] se proponeuna variante de ´arboles B+, usados generalmente en sistemasde archivos, llamada VDB por las siglas de
Volume DynamicB+tree . Con esta topolog´ıa se puede modelar un espaciode ´ındices tridimensional, virtualmente infinito que permiteel acceso r´apido a informaci´on dispersa. Adicionalmente, la a r X i v : . [ c s . R O ] F e b mplementaci´on de VDB no impone restricciones de topolog´ıasobre los datos de entrada y admite patrones de acceso,inserci´on y eliminado aleatorio r´apidos, en promedio O (1) .La implementaci´on de esta estructura de datos es conocidacomo OpenVDB (OVDB) y se presenta en [7].Explotando las caracter´ısticas de OVDB, en [8] se pre-senta una biblioteca llamada STVL por las siglas de Spatio-Temporal Voxel Layer donde se implementan una serie de buf-fers que almacenan nubes de puntos provenientes de c´amarasde profundidad u otras fuentes capaces de generar este tipo dedatos. Estas nubes de puntos se codifican usando OpenVDBlogrando formar mapas tridimensionales de manera eficiente.Debido a la resoluci´on y cantidad de sensores, las nube suelenestar compuestas de millones de puntos por lo que es necesariorealizar una compresi´on diezm´andola con alg´un criterio. En [8]esto es realizado mediante un filtro de voxelizado , disponibleen la biblioteca
Point Could Library [9] el cual corre en CPU.En este trabajo se presenta una implementaci´on de STVLcapaz de ser ejecutada en la GPU de la plataforma de desarro-llo Jetson Nano de Nvidia, utilizando el arreglo de la Fig. 1.Esta plataforma fue elegida debido a su reducido tama˜no ygran eficiencia energ´etica, lo que posibilita su uso en peque˜nosrobots ya sean voladores o terrestres. Adicionalmente, estaplataforma tiene la CPU y la GPU en el mismo chip, porlos que comparten f´ısicamente la memoria. Esto evita que sehagan copias redundantes de bloques de memoria, por ejemplouna imagen, entre el CPU y la GPU. Este enfoque es conocidopor NVIDIA como
Zero-Copy . Espec´ıficamente se presentauna variante de [10] implementada en CUDA para realizarla compresi´on de los puntos. Esta compresi´on o filtrado serealiza aprovechando el acceso
Zero-Copy disponible en laplataforma Jetson Nano. No hay, seg´un el conocimiento delos autores, otra implementaci´on que pueda ser ejecutada enesta plataforma.El trabajo se organiza de la siguiente manera: En la Sec-ci´on II se describen las herramientas de software y las platafor-mas de hardware utilizadas en el trabajo, as´ı como la propuestade modificaci´on al algoritmo para poder ser utilizado en laplataforma Jetson Nano. Tambi´en se describen los escenariodonde fue probada la implementaci´on. En la Secci´on III semuestran los resultados obtenidos en las distintas plataformasy escenarios, con tres tama˜nos de voxel. Las conclusiones deltrabajo y futuras l´ıneas de investigaci´on son enumeradas en laSecci´on IV. II. M
ATERIALES Y M ´ ETODOS
Para evaluar el algoritmo propuesto se hicieron pruebas enun ambiente simulado y en un escenario real. Ambos esce-narios de similares caracter´ısticas, est´aticos y estructurados.Adem´as se compar´o el tiempo de c´omputo de la bibliotecaoriginal y la propuesta usando distintas plataformas.
II-A. Herramientas de software utilizadas
La implementaci´on se realiz´o sobre el framework
ROS(siglas en ingl´es de Sistema Operativo para Robots) [11],usando la versi´on de nombre clave Melodic Morenia. Esto permite una r´apida integraci´on del m´etodo a evaluar con algo-ritmos existentes y ampliamente usados en rob´otica. La mejorapropuesta es una variante de m´etodo de filtrado de puntos dePCL [12] utilizado por la biblioteca STVL disponible en [13].Para la etapa de simulaci´on, la misma se realiz´o con el entornoGazebo [14] versi´on 9 la cual puede descargarse de [15] eintegrarse a ROS.
II-B. Plataformas de hardware utilizadas
La plataforma elegida para realizar las pruebas fue la JetsonNano de NVIDIA. La misma es una placa de peque˜nasdimensiones, tan solo 70mm de largo y 45mm de ancho, loque posibilita su utilizaci´on en robots de tama˜no reducido.Cuenta con una GPU de arquitectura Maxwell de 128 CUDAcores con los cuales puede correr hasta 2048 hilos y comoprocesador principal tiene un ARM Quad-core Cortex-A57.Esta placa cuenta con una memoria de 4GB 64-bit LPDDR4con un ancho de banda m´aximo te´orico 25.6GB/s. Con todoeste hardware puede alcanzar 472GFLOPS de rendimiento dec´omputo en FP16, con 5-10W de consumo de energ´ıa. Comose mencion´o antes la CPU y la GPU se encuentran en el mismoencapsulado y comparten f´ısicamente la misma memoria delsistema, admitiendo una forma limitada de memoria unificada .Dicha arquitectura permite comunicaciones CPU-GPU, que noson posibles en GPU discretas. De esta forma, se evita la copiade cada punto y solamente es necesario pasar la direcci´onde memoria del mismo a las funciones de CUDA lo que setraduce en una reducci´on de tiempo y espacio utilizado. Esimportante destacar que esta implementaci´on es en si mismauna mejora sobre el algoritmo original presentado por [10], yaque originalmente estaba pensado para arquitecturas de GPUNVIDIA Fermi y Kepler las cuales son generaciones anterioresy no disponen de memoria unificada.El algoritmo tambi´en fue evaluado en una PC de escritoriocon procesador Ryzen 7 1700 y una GPU NVIDIA GTX 1660Super. La misma cuenta con 6GB de memoria GDDR6 devideo, con un ancho de banda te´orico m´aximo indicado por elfabricante de hasta 336GB/s. Esta placa pertenece a la familiade micro arquitectura Turing la cual dispone de la tecnolog´ıade memoria unificada. Como contrapartida, la memoria est´aseparada del procesador de la CPU por lo cual la informaci´ontiene que ser copiada a trav´es del bus PCI Express.Para generar la nube de puntos en el escenario real se utiliz´ola c´amara RGB-D Intel RealSense Depth Camera D435. Estac´amara est´a formada por un par est´ereo capaz de determinarla distancia al sensor de los puntos dentro de su campode visi´on. Tambi´en dispone de un proyector infrarrojo, paramejorar la imagen 3D en paredes que no tengan caracter´ısticassobresalientes.
II-C. Algoritmo propuesto
En el algoritmo presentado en [8], las nubes de puntosprovenientes de las c´amaras RGB-D, son ingresadas en buffers de observaciones, los cuales almacenan la posici´on relativade la medici´on con respecto a un sistema de coordenadasglobales. Luego, estas mediciones pueden ser utilizadas conos finalidades: operaciones de marcado en la cual se designala celda como ocupada, u operaciones de liberaci´on donde semarca la celda como vac´ıa.Debido a la implementaci´on paralela del programa, existen buffers extra destinado a cada una de las operaciones. Lasnubes de puntos recibidas, al estar en el sistema de referenciade la c´amara, tienen que ser transformadas al sistema decoordenadas de globales. Esta transformaci´on de un sistemade referencias a otro es realizado mediante la biblioteca tf2 [16], la cual permite realizar las transformaciones entre losm´ultiples sistemas de referencia presentes en el robot, a lolargo del tiempo.Mediante el an´alisis de tiempo empleado en cada una delas operaciones del programa mencionadas anteriormente, sedeterminaron las partes del algoritmo que presentaban mayoresdemoras. Como se puede ver en la Fig.2, las operacionesm´as costosas desde el punto de vista computacional son lade filtrado de la nube de puntos, llamada filter y laoperaci´on de marcado/liberaci´on, llamada
ClearFrustums .Esta ´ultima comprende el acceso a las celdas del mapa global,utilizando los m´etodos provistos por la biblioteca OpenVDB.Estas nubes de puntos pueden llegar a ser muy densas,del orden de millones de puntos, y al ser utilizadas en elmarcado de celdas para el mapa global, es necesario realizaruna compresi´on de las mismas. En [8] esto es realizadomediante un filtro de voxelizado , disponible en la biblioteca dePCL. Este filtro recibe como entrada nube de puntos, la cualtiene que estar en el sistema de referencia global, para poderlimitar la altura de la nube de puntos. Este l´ımite en el eje z , permite al navigation_stack de ROS [17] proyectarla nube de puntos sobre el plano horizontal y generar unmapa de ocupaci´on, utilizado en la navegaci´on del robot.El filtro disponible en la biblioteca PCL es calculado en laCPU, y seg´un el conocimiento de los autores, no hay otraimplementaci´on que pueda ser ejecutada en esta plataforma.Por otro lado, los algoritmos implementados en CUDA parael filtrado de nubes de puntos normalmente se implementanen GPUs de escritorio con gran capacidad de memoria. Estolos convierten en poco atractivos para utilizar en plataformasembebidas debido a su limitada capacidad de memoria, gene-ralmente compartida con la CPU.Se implement´o una versi´on modificada de Cubic Subspa-ces - Neighboring Buckets [10], implementada en CUDA yutilizando el proceso
Zero-Copy disponible en plataformascomo la Jetson Nano. La idea principal es usar la GPU paradescomponer el espacio 3D en una cuadr´ıcula regular de n × n × n cubos ( n = 4 , , , , , . Por lo tanto, paracada punto, se consideran solo 27 cubos (3 ) para encontrarlos vecinos m´as cercanos. Para calcular la distancia entre dospuntos p x , y , z y p x , y , z se utiliza la distanciaeucl´ıdea definida como: d ( p , p
2) = (cid:104) ( x − x ) + ( y − y ) + ( z − z ) (cid:105) (1)con x , y , z y d ( p , p pertenecientes al espacio R . Cada Figura 2. Tiempos de procesamiento de las partes de mayor carga compu-tacional del algoritmo. punto del espacio tridimensional
XY Z es normalizado, detal forma que { x, y, z ∈ R : − ≤ x, y, z ≤ } . Luego, sonclasificados mediante un ´arbol de decisi´on para determinar aque subdivisi´on del espacio n × n × n pertenecen.La cantidad de puntos que pertenecen a cada subdivisi´on, esdeterminada mediante una tabla ( tabla_subdiv ) ordenadade pares “clave-valor” utilizando el conocido algoritmo “RadixSort”. Es importante notar que esta tabla es almacenada enla memoria global de la GPU, por lo tanto, todos los hilosde CUDA pueden acceder a los datos. El par “clave-valor”,junto con la informaci´on de la cantidad de puntos en cadasubdivisi´on, son accesibles mediante la memoria de la GPU, yse utilizar´a para buscar el vecino m´as cercano en el algoritmo.El objetivo del filtrado es eliminar puntos, para reducirla densidad de la nube de puntos y al mismo tiempo eli-minar el ruido de la medici´on proveniente de la c´amara deprofundidad. Una vez calculados los vecinos m´as cercanospor el m´etodo anteriormente descripto, las subdivisiones delespacio son iterativamente reducidas hasta obtener la densidadde puntos deseada. Este proceso puede ser descripto medianteel Algoritmo 1.La nube de puntos obtenida del filtro, es una versi´oncomprimida de la nube de entrada, y la densidad de la mismadepende del tama˜no de bloque elegido para el filtro. Estadimensi´on puede ser configurada al inicio del algoritmo, ytambi´en es utilizada por la estructura de OpenVDB paraalmacenar los puntos en el mapa global.Debido a las restricciones impuestas por la evasi´on deobst´aculos, es una prioridad garantizar c´alculos completos dela nube de puntos en el menor tiempo posible.Para asegurar la utilizaci´on completa de la GPU, el pro-grama determina la cantidad m´axima de procesadores CUDAdisponibles, para distribuir cada subdiv del espacio. Esto sepuede ver en el punto n´umero 11 del Algoritmo 1. igura 3. Secuencia de im´agenes del ambiente utilizado para las pruebas. Izquierda: Nube de puntos generada por la c´amara RGB-D, Centro: Grilla deocupaci´on 3D generada por el algoritmo STVL, Derecha: Nube de puntos y mapa superpuestos. Algorithm 1
Filtrado de puntos 3D
Entrada:
Puntero a la nube de puntos de la c´amara
Salida:
Puntero a la de puntos filtrada copiar el puntero del host al device llamado a la funci´on de CUDA para todos los puntos m ixyz en paralelo hacer buscar subdiv m i actualizar tabla_subdiv fin para en paralelo ordenar tabla_subdiv { radix sort } mientras la cantidad de puntos marcados > { unkernel CUDA por cada punto m xyz } hacer para todos los puntos m ixyz en paralelo hacer buscar subdiv para todas las subdiv vecinas hacer contar la cantidad de vecinos de { teniendo encuenta los puntos marcados para borrar } fin para { un kernel de CUDA por un punto } marcar m ixyz para borrar si cont > umbral fin para { un kernel de CUDA para todos los puntos } si cantidad de puntos marcada > entonces aleatoriamente elegir 1000 puntos marcados paraeliminarlos definitivamente fin si fin mientras sincronizar el llamado a los kernels eliminar los puntos marcados copiar el puntero del device al hostSe realizaron experimentos en ambientes simulados y realespara validar el m´etodo de filtrado. A continuaci´on se presentauna breve descripci´on del sistema utilizado. II-D. Escenario simulado
Para evaluar el algoritmo propuesto, en una primera ins-tancia se utiliz´o el simulador Gazebo [14], en su versi´on 9.Se opt´o por por este simulador ya que es compatible conel protocolo de mensajes de ROS Melodic utilizada en estetrabajo, y cuenta con soporte para los sensores requeridos porel algoritmo. El robot es del estilo tracci´on diferencial, con una c´amaraRGB-D montada en su parte superior. El mismo cuenta conodometr´ıa, con lo cual el mapa generado puede ser extendidom´as all´a del alcance de la c´amara de profundidad. En laFig.4, se puede observar el mapa generado por el algoritmo.El mismo intenta recrear un ambiente de oficinas, en elcual se encuentran dispuestos mobiliario, en ambos lados. Esimportante destacar que al ser un sensor simulado, no presentalos artefactos normalmente encontrados en c´amaras RGB-D.
II-E. Escenario real
Para un an´alisis cualitativo se realizaron pruebas en unescenario real en donde se tomaron im´agenes de un pasillocon distintos obst´aculos y puertas. Se utiliz´o la configuraci´onmostrada en la Fig. 1. La misma est´a compuesta por la c´amaraRGB-D con el eje ´optico alineado con el sentido de circulaci´ondel pasillo. La c´amara fue montada sobre un perfil de aluminio.Debajo de la misma, se coloc´o la plataforma de desarrolloJetson Nano. III. R
ESULTADOS
Como se explic´o anteriormente, el mayor c´omputo delalgoritmo est´a concentrado en dos partes principales, el fil-trado y el acceso a la nube de puntos global mediante lasfunciones provistas por OVDB. Luego de la implementaci´ondel algoritmo, en la Fig. 5 se muestra el an´alisis de cadafunci´on comparando la versi´on original con la versi´on en GPUejecut´andose en la Jetson Nano.
Figura 4. Robot en el entorno de simulaci´on. Izquierda: Mapa 3D obtenidopor el algoritmo. Derecha: Pasillo de oficina con obst´aculos en sus laterales n la Fig. 6, se pueden observar los tiempos empleadospor el filtrado de la nube de puntos. Como se puede ver, laversi´on utilizando CUDA es m´as r´apida que la versi´on originalutilizando el filtrado con la biblioteca PCL. Esto era de esperar,ya que el filtrado puede ser descompuesto de forma tal, que seexpone el paralelismo del algoritmo. Estas tareas masivamenteparalelas, hacen que las placas GPU saquen grandes ventajasfrente a su versi´on serializada.Por otro lado, llevar el procesamiento de la nube de puntosa la GPU, implica que la CPU ahora dispone de m´as recursos,dejando lugar para ejecutar otros algoritmos en forma simul-tanea. Esto se puede ver en la Fig. 7 como una reducci´on enel tiempo de procesamiento de la nube de puntos por partedel algoritmo de OVDB, el cual se ejecuta en la CPU. Parael mismo tama˜no de grilla elegido, al algoritmo se procesaen menor tiempo en la versi´on con el filtro paralelizado enCUDA.Esto tambi´en se puede ver en la Fig. 5, en la cual lasfunciones clear_frustum y mark que est´an implemen-tadas en CPU, ahora se ejecutan en un menor tiempo, pese aque no se realizaron mejoras en esas funciones. Es importantedestacar que la mejora se realiz´o sobre el filtrado de la nube depuntos; y el algoritmo de inserci´on y eliminaci´on de puntos,mediantes las funciones de OVDB en el mapa global nopresenta modificaciones.En la Fig. 3 podemos observar el mapa de ocupaci´on3D generado por el algoritmo. Tambi´en se puede apreciaren la parte inferior, la ausencia de voxels (puntos en elmapa 3D), debido a que es una condici´on requerida por el navigation_stack para realizar la proyecci´on sobre elplano y generar el mapa de ocupaci´on. Este mapa generado,puede ser utilizado por algoritmos de planificaci´on, para des- Figura 5. Comparaci´on de las funciones de mayor carga computacional, enel algoritmo con el filtrado en CUDA y en PCL. Se puede apreciar como lasfunciones las funciones clear_frustum y mark que est´an implementadasen CPU, ahora se ejecutan en un menor tiempo, ya que la CPU dispone dem´as recursos. Figura 6. Comparaci´on entre la versi´on original del algoritmo de filtradomediante PCL y la versi´on propuesta en CUDA, para diferentes resolucionesdel mapa global plazarse en el ambiente evitando obst´aculos, y de forma parale-la para generar un mapa con la informaci´on de odometr´ıa. Esteescenario ser´ıa el caso de un robot navegando por un pasillo,en el cual se encuentran presentes obst´aculos que obstruyen sucamino. En este caso la resoluci´on elegida fue de 5cm, la cualno solo permiti´o representar con efectividad los obst´aculos(Cajas de cart´on en la imagen), si no que tambi´en permiti´ocapturar detalles del ambiente. Por ejemplo, en la esquina Figura 7. Comparaci´on del tiempo para las operaciones en la CPU por partede la biblioteca OpenVDB en el mapa global, para diferentes tama˜nos degrilla.igura 8. Comparaci´on de tiempo de filtrado para tres configuraciones conuna resoluci´on de 0.02m: a la izquierda, el algoritmo de filtrado originalcorriendo en la CPU de la Jetson; al centro, el algoritmo propuesto corriendoen la GPU de la Jetson; a la derecha, el algoritmo propuesto corriendo en laGPU de escritorio superior derecha, podemos observar como el matafuegos escapturado por el mapa 3D. En el caso de la puerta a laizquierda de la escena, la discontinuidad se puede distinguirpor un cambio en el color de la grilla 3D. Es importanteremarcar que, debido a la presencia de ruido en la c´amarade profundidad, en la tercera imagen de la Fig. 3, algunosvoxels del mapa 3D son ocluidos por la nube de puntos.El algoritmo de filtrado implementado en CUDA no tieneuna gran carga aritm´etica, debido a que la mayor´ıa de ope-raciones corresponden a movimientos de memoria. Como semencion´o anteriormente, la plataforma utilizada dispone deuna memoria LPDDR4 con cuatro canales de 16 bits, capazde alcanzar un ancho de banda m´aximo te´orico de 25.6GB/s,sin embargo en las pruebas realizadas la velocidad no superalos 16GB/s para copias entre la misma GPU y de 10GB/spara copias CPU-GPU. Las pruebas fueron realizadas conlos ejemplos sugeridos por el fabricante [18], para evaluarel ancho de banda. Es importante destacar que las trans-ferencias CPU-GPU se deben a no utilizar memoria fijada( pinned_memory) ), la cual evita que el sistema operativola mueva o la cambie al disco. La memoria fija proporcionauna mayor velocidad de transferencia para la GPU y permitela copia asincr´onicaComo puede observarse en la Fig. 8, se obtiene una mejoranotable en el tiempo de filtrado de la nube de puntos. Lavelocidad del filtrado se reduce en un orden de magnitudcuando el algoritmo es ejecutado en la computadora de es-critorio como se indica en la Tabla I. Esto tambi´en se debeal cambio de micro arquitectura, ya que en Turing los proce-sadores se redise˜naron para unificar la memoria compartida,el almacenamiento en cach´e de texturas y el almacenamiento en cach´e de carga de memoria, en una sola unidad. Esto setraduce en 2 veces m´as ancho de banda y m´as de 2 veces m´ascapacidad disponible para la cach´e L1 [19], en comparaci´ona la arquitectura anterior a Turing. Por otra parte, la placa devideo cuenta con 22 SM (Streaming Multiprocessors) con con64 CUDA cores cada uno, lo que mejora el desempe˜no delalgoritmo, puesto que cada subdivisi´on del espacio ( subdiv )es procesada en forma independiente del resto.Cabe aclarar que el algoritmo para este ´ultimo caso, est´autilizando memoria unificada, pero no puede utilizarse elconcepto de
Zero-copy disponible en la plataforma Jetson.
Tabla ID
ATOS ESTAD ´ ISTICOS OBTENIDOS PARA LA FUNCI ´ ON DE FILTRADO EN LAPLATAFORMA J ETSON N ANO Y EN UNA
GPU
DISCRETA , PARA UNTAMA ˜ NO DE M Plataforma Media [ms] Desviaci´on est´andarpcl-jetson .
88 1 . · − cuda-jetson . . · − cuda-desktop . . · − IV. C
ONCLUSIONES
En este trabajo se present´o una mejora sobre sobre el filtradode una nube de puntos, en el programa STVL. Se realizaronpruebas simuladas como en la vida real, y se analizaron lasventajas de procesar la nube de puntos en la GPU embebidaen plataformas como las NVIDIA Jetson. Tambi´en se realiz´ouna comparaci´on de velocidad con una placa de video discretaen una PC de escritorio, en la cual se pudo comprobar queel aumento en la velocidad de memoria disminuye el tiempode procesamiento del algoritmo. Durante el desarrollo delalgoritmo, se pudo constatar que es muy importante tener lamisma arquitectura de GPU que la de la plataforma sobrela cual se est´a desarrollando. Una discordancia en la misma,podr´ıa provocar errores conceptuales y algor´ıtmicos, debido aque algunas funciones pueden no estar disponibles. Para elcaso de la Jetson Nano, la misma cuenta con una versi´onlimitada de las funciones de memoria unificada. Es trabajofuturo implementar mejoras sobre el algoritmo presentado enla plataforma Jetson TX2, la cual cuenta con micro arquitec-tura Pascal y mejor soporte de memoria unificada, con lo cualse espera mejorar a´un m´as el rendimiento.Tambi´en se est´a trabajando en reemplazar el uso de lasfunciones de OpenVDB (realizadas en CPU), por las de labiblioteca GVDB provistas por NVIDIA [20]. Debido al usode funciones implementadas a partir de la micro arquitecturaPascal, se planea utilizar la plataforma Jetson TX2.R
EFERENCIAS[1] H. Moravec and A. Elfes, “High resolution maps from wide angle sonar,”in
Proceedings of the IEEE international conference on robotics andautomation (ICRA’85) , 1985.[2] H. P. Moravec, “Robot spatial perception by stereoscopic vision and 3devidence grids,” Robotics Institute, Tech. Rep., 1996.[3] I. Dryanovski, W. Morris, and J. Xiao, “Multi-volume occupancy grids:An efficient probabilistic 3d mapping model for micro aerial vehicles,”in , 2010, pp. 1553–1559.4] A. Hornung, K. M. Wurm, M. Bennewitz, C. Stachniss, and W. Burgard,“OctoMap: An efficient probabilistic 3D mapping framework basedon octrees,”
Autonomous Robots , 2013, software available at http://octomap.github.com. [Online]. Available: http://octomap.github.com[5] L. Doctor and J. Torborg, “Display techniques for octree-encodedobjects,”
IEEE Computer Graphics and Applications , vol. 1, no. 3, pp.29–38, 1981.[6] K. Museth, “Vdb: High-resolution sparse volumes with dynamic topo-logy,”
ACM transactions on graphics (TOG) , vol. 32, no. 3, pp. 1–22,2013.[7] K. Museth, N. Avramoussis, and D. Bailey, “OpenVDB,” in
ACMSIGGRAPH 2019 Courses , ser. SIGGRAPH ’19. New York, NY,USA: Association for Computing Machinery, 2019. [Online]. Available:https://doi.org/10.1145/3305366.3328070[8] S. Macenski, D. Tsai, and M. Feinberg, “Spatio-temporal voxel layer:A view on robot perception for the dynamic world,”
InternationalJournal of Advanced Robotic Systems , vol. 17, no. 2, 2020. [Online].Available: https://doi.org/10.1177/1729881420910530[9] R. B. Rusu and S. Cousins, “3D is here: Point Cloud Library (PCL),”in
IEEE International Conference on Robotics and Automation (ICRA) ,Shanghai, China, May 9-13 2011.[10] J. Bedkowski, K. Majek, and A. Nuchter, “General purpose computingon graphics processing units for robotic applications,”
Journal of Soft-ware Engineering for Robotics , 2013. [11] M. Quigley, “ROS: an open-source robot operating system,” in
ICRA2009 , 2009.[12] “Point cloud library,” https://pointclouds.org/, accessed: 2020-09-20.[13] “Spatio-temporal voxel layer,” https://github.com/SteveMacenski/spatiotemporal voxel layer, accessed: 2020-09-20.[14] N. Koenig and A. Howard, “Design and use paradigms for gazebo,an open-source multi-robot simulator,” in , vol. 3. IEEE, 2004, pp. 2149–2154.[15] “Gazebo,” https://github.com/osrf/gazebo, accessed: 2020-09-20.[16] T. Foote, “tf: The transform library,” in
Technologies for Practical RobotApplications (TePRA), 2013 IEEE International Conference on , ser.Open-Source Software workshop, April 2013, pp. 1–6.[17] E. Marder-Eppstein, E. Berger, T. Foote, B. Gerkey, and K. Konolige,“The office marathon: Robust navigation in an indoor office environ-ment,” in