DETECCIÓN DE CAPAS DE DISEÑO VIAL EN DATOS DE NUBE DE PUNTOS

PARA LA MONITORIZACIÓN DEL PROGRESO DE LA CONSTRUCCIÓN

Mateo Timarán López

Profesor
Oscar Pedraza Franco

UNIVERSIDAD COOPERATIVA DE COLOMBIA

Medellín
18/10/2019
 Introducción
Un estudio reciente estimó que se necesitan 3,2 billones de dólares anuales en
inversión en infraestructura para mantener el ritmo del crecimiento del producto
interno bruto (PIB) mundial hasta 2030, con aproximadamente el 16% de esa
inversión (512.000 millones de dólares) necesarios para la construcción de
carreteras (Dobbs et al. 2013).

Se trata de un proceso cíclico que consiste en la supervisión de los progresos y la

aplicación de medidas correctoras. La automatización de la primera parte del ciclo
de control del proyecto, la supervisión de los progresos, puede permitir la adopción
de medidas correctivas más oportunas y eficaces para mantener un proyecto a
tiempo y dentro del presupuesto.

Antecedentes

El problema técnico específico que se aborda en este documento es la detección

de superficies de diseño de carreteras en los datos incorporados para apoyar la
supervisión automatizada del progreso. En el examen que figura a continuación se
evalúan los métodos conexos propuestos en estudios recientes sobre la base de
su grado de automatización y aplicabilidad a las superficies estratificadas para el
diseño de carreteras.

Enfoques de correspondencia puntual

Enfoques de correspondencia puntual (Bosché 2010; Kim et al. 2013; Turkan et al.
2014) generan nubes puntuales planificadas a partir de elementos de modelos 3D
y buscan las más cercanas se construyeron correspondencias dentro de una
distancia umbral para determinar si un punto como planeado está presente en la
escena como-construido. Los vértices de triangulación de superficie de diseño son
escasos, por lo que las nubes puntuales planeadas deben estar o bien en la
superficie de diseño para que coincidan estrechamente con la densidad de la nube
tal como está construida (por ejemplo, Kim et al. 2013), o los puntos tal como
están construidos deben proyectarse sobre las superficies cercanas antes de
seleccionar la proyección más cercana como la ubicación correcta como se planeó
(por ejemplo, Bosché 2010). Los investigadores utilizaron principalmente umbrales
sobre el número de correspondencias de puntos confirmados para determinar si
se detectó un elemento de modelo. Estos métodos resultaron prometedores para
la detección automática de elementos de construcción estructural planificados en
3D PCD, en particular al incorporar a priori información de conectividad y
secuenciación de construcción como Kim et al. (2013). Sin embargo, se centraron
en la detección total o total de los componentes individuales. Este enfoque
funciona bien para detectar componentes relativamente pequeños construidos
dentro de un ciclo de seguimiento del progreso (por ejemplo, una columna), pero
no capta el tipo de progreso incremental necesario para apoyar el control eficaz
del proyecto en las obras de construcción de carreteras con superficies de diseño
muy grandes

Enfoques de partición espacial

Otros investigadores dividieron escenas registradas como construidas y como

planeadas y puntos identificados que caen en las regiones divididas para facilitar
la detección de objetos. Algunos utilizaron los límites de cada modelo de elemento
estructural (por ejemplo, una columna cuadrada) para llevar a cabo este
particionado (por ejemplo, Zhang y Arditi 2013). Métodos más comúnmente
utilizados particionan el espacio 3D que contiene la escena como-construida y
como-planeada usando voxels. Algunos (Tuttas et al. 2014; Braun et al. 2015)
construyeron un octree sobre el PCD y buscaron puntos dentro de los umbrales de
distancia ortogonal de segmentos planos rasterizados (por ejemplo, rectángulos o
triángulos) extraído de las superficies constitutivas de cada elemento estructural.
Aunque este enfoque no es todo o nada, limita la decisión de detección a cada
segmento de superficie plana que constituye el objeto de diseño.

Investigación específica sobre el transporte

Sólo un estudio buscó comparar las capas superficiales del diseño de carreteras
con los datos de nubes de punto como-construido (Kivimaki y Heikkila 2015). Este
estudio, sin embargo, se detuvo a corto de la verdadera detección de superficie de
diseño porque la coincidencia de los puntos encuestados con la superficie de
diseño pertinente se logró mediante la asignación de un código específico que une
cada punto a una superficie.

Lagunas en el conocimiento, el objetivo y las cuestiones de investigación

El cuerpo de investigación existente está fuertemente sesgado hacia los

componentes estructurales de construcción en PCD como-construido. Las
superficies para tales componentes se caracterizan típicamente por secciones
planas de intersección ortogonal relativamente pequeñas (por ejemplo, las caras
de una pared de cimentación de hormigón). Las superficies de construcción de
carreteras son más grandes y más complejas, por lo general con cambios de
pendiente a lo largo de los ejes longitudinal y transversal del corredor vial. La
construcción en capas estrechas, especialmente en las capas delgadas de asfalto
superior, también diferencia las superficies de diseño de carreteras de los
componentes estructurales de construcción. El objetivo de este estudio es abordar
las lagunas 2 a 4 mediante el desarrollo y ensayo de una nueva estructura de
datos para la detección automática y gradual de las superficies de diseño de
carreteras en capas en PCD sin etiqueta. Los autores examinan las siguientes
preguntas de investigación para lograr este objetivo:

1. ¿Cómo se puede dividir el espacio 3D según lo previsto para permitir una

detección constante y gradual de la capa de carreteras?

2. ¿Cómo puede clasificarse con precisión el PCD tal como está construido dentro
de las regiones divididas, teniendo en cuenta el ruido y la incertidumbre en la
escena tal como está construido?

3. ¿Qué combinación de parámetros de diseño y/o de entrada será necesaria para

obtener los resultados más deseables?
 SOLUCION PROPUESTA

Los autores proponen una solución novedosa para detectar superficies de diseño
de carreteras en capas en regiones discretas de datos de nubes de puntos a
medida. Esta solución implementa una nueva estructura de datos de partición de
espacio jerárquica guiada por modelos y escasa llamada Bricktree, una
combinación de los nombres de los autores y un guiño a la forma cuboide
rectangular de la hoja voxels en esta estructura. La Fig. 2 ilustra los procesos
clave en la implementación de este enfoque. Las entradas a esta solución son (1)
una nube de puntos tal como está construida, escalada en unidades del mundo
real y registrado en el sistema de coordenadas del modelo CIM; y (2) superficies
de capas de carreteras trianguladas extraídas del modelo CIM. El resto de esta
sección describe con más detalle los cuatro procesos de la solución propuesta.

Estructura de datos de Bricktree

El primer paso para generar el Bricktree aplica una transformación de cuerpo

rígido a las superficies de diseño en capas, colocándolas justo por encima del
origen global con la dirección longitudinal del corredor de carretera alineado con la
y-y la dirección transversal alineada con el eje X. Se crea una cuadrícula 2D,
llamada projectGrid, en el plano x-y debajo de las capas de superficie de diseño
registradas y alineadas. El proyectoGrid sirve como base para la partición
adicional, ya que cada celda de cuadrícula cuadrada define los límites x-y de un
rasterBranch en la estructura jerárquica del árbol (Fig. 3). Como tal, cada
rasterBranch es una proyección vertical de un proyectoGrid celda, y se define
dentro de la jerarquía como una colección de leafVoxels, que se definen como 3D
elementos de partición de espacio rectangular que subdividen cada región
rasterBranch.
 Poblando el Bricktree con Puntos Como Construidos

Hay dos estrategias generales para asignar los puntos tal como están construidos
a un árbol de partición de espacio jerárquico: (1) atraviese la nube de puntos para
determinar en qué parte de la estructura del árbol se encuentra cada punto, o (2)
atravesar la estructura del árbol para identificar y asignar puntos en las
proximidades de cada voxel. La estructura leafVoxels alineada a ejes permite
indexar rápidamente los puntos y asignarlos a regiones 3D discretas. Por esta
razón, los autores optaron por atravesar la nube tal como fue construida,
asignando directamente puntos a leafVoxels. Debido a que los voxels no están
espaciados uniformemente en la dirección z, la indexación rápida sólo ocurre a
nivel de rama. Para un determinado punto como-construido, pb, el proceso calcula
el índice de ramas comparándolo con el origen (punto inferior izquierdo) del
proyectoGrid, po, usando las ecuaciones siguientes, donde ni celdas es el número
de células proyectGrid en la dirección x. .

Clasificación de Sucursales

El ruido y otros errores podría dar lugar a múltiples leafVoxels se detectan en el

mismo rasterBranch. Se debe tomar una decisión de clasificación para corregir
este conflicto, ya que sólo es posible detectar una superficie de diseño por rama
en una escena como construida. Los límites de decisión sofisticados se pueden
aprender usando enfoques supervisados o no supervisados de aprendizaje
automático, pero estos requieren un gran número de conjuntos de datos de
entrenamiento de una variedad de sitios de construcción

Corrección de Valores Atípicos

El paso final en el proceso de detección de superficies, la corrección de valores

atípicos, tiene como objetivo mejorar la precisión del resultado final utilizando un
conocimiento a priori de las operaciones de construcción de carreteras.
Concretamente, el método supone que las superficies de los caminos no suelen
estar construidas con huecos o zonas faltantes en el medio..
 Calidad de los datos de construcción y de construcción

La solución propuesta asume un nivel aceptable de construcción (εc) y un error de

medición de datos (εm). Los autores dividen estos errores en direcciones
horizontal (εc; h, εm; h) y vertical (εc; v, εm; v) para describir su impacto en el
método propuesto. Los errores de medición también incluyen el ruido, dividido
además en ruido aleatorio, valores atípicos y oclusiones. La estructura de
Bricktree limita implícitamente la influencia de los valores atípicos y las oclusiones
al considerar solamente puntos dentro de las regiones de leafVoxel. Los puntos de
oclusiones de bajo nivel (por ejemplo, el equipo sentado en la superficie de la
carretera) todavía podrían desencadenar errores de detección, pero este tipo de
ruido es difícil de controlar en un sitio activo. Además, el paso de corrección de
valores atípicos está diseñado para corregir estos errores siempre y cuando la
región ocluida no sea mucho mayor que el vecindario de comparación. Por
consiguiente, el siguiente análisis de la calidad de los datos de entrada requeridos
solo tiene en cuenta el ruido aleatorio (εn), que se supone que es gaussiano y
afecta principalmente a las mediciones verticales.

Los errores horizontales (εc; h y εm; h) podrían dar lugar a errores de detección,
principalmente a lo largo de los límites del corredor vial.

En la práctica, las especificaciones del contrato dictan el nivel aceptable de error

de construcción.

Los errores verticales (εc; v, εm; v, y εn) podrían resultar en errores de detección
dentro de cualquier rama del Bricktree. El parámetro buscar distancia maneja la
sensibilidad de error vertical de la solución propuesta y se limita a una distancia
máxima igual al grosor de la capa de diseño de carretera más delgada para evitar
el solapamiento de leafVoxels. Ec. (5) describe la relación entre este parámetro y
el error de entrada de datos requerido para permitir la detección

De nuevo, las especificaciones del contrato impulsan los niveles εc;v aceptables,
con la Agencia de Carreteras del Reino Unido definiendo los límites a 6 mm para
el pavimento, 15 mm para la base y 10 mm para los niveles de la base. Utilizando
el máximo permitido εc; v de 15 mm y una búsqueda teórica de 4 cm de diámetro,
la mayoría de los puntos tendrían que estar dentro de un error de medición vertical
(εm; v þ εn) de 2,5 cm para facilitar la detección.

Metodología, experimentos y resultados

Los autores generaron datos de nubes de puntos simulados para probar la

viabilidad de la solución propuesta antes de realizar más experimentos de
verificación de datos del mundo real. Los datos simulados permitieron aislar y
probar el rendimiento de la solución propuesta en presencia de errores típicos de
construcción y medición, mientras se controlaban las oclusiones y el desorden en
la escena observada.

DATOS DEL MUNDO REAL

Los autores recopilaron los datos planificados en dos días separados durante la
construcción de una carretera residencial para un nuevo desarrollo en Cambridge,
Reino Unido. El diseño del camino asfaltado incluyó cinco superficies distintas: (1)
la formación (fondo de excavación), (2) una capa de base de 520 mm de espesor,
(3) un curso de base de 125 mm de espesor, (4) un curso de 65 mm de espesor
aglutinante asfáltico, y (5) un curso de desgaste del asfalto de 40 mm de espesor.
La aplicación AutoCAD Civil 3D se utilizó para generar un modelo de corredor 3D
a partir de la información de diseño 2D proporcionada por el contratista.

Comparación de los conjuntos de datos simulados y del mundo real

Los autores verificaron la idoneidad de los datos simulados comparándolos con los
datos del mundo real, examinando específicamente la densidad de los puntos y
las estadísticas de la distancia a la superficie. Esto se hizo mediante la
construcción de histogramas de los datos para cada métrica; distribuciones
normales se ajustaron a los histogramas para describir y visualizar los resultados
(Fig. 8). Aislar el error de medición fotogramétrica en este caso requeriría modelar
con precisión el error de construcción en todo el corredor de carretera, lo que a su
vez requeriría técnicas de medición y modelado que introducen sus propios
errores. Para tener en cuenta esto, y hacer el siguiente análisis una comparación
de manzanas a manzanas, los autores calcularon las distancias punto a superficie
de los datos simulados en relación con las superficies de diseño sin errores.

Esta comparación confirma que los datos simulados se aproximan

razonablemente a los datos fotogramétricos aéreos del mundo real. Los errores
verticales del mundo real estaban dentro de σDay1 ¼ 1.5px y σDay2 ¼ 1.3px,
respectivamente, ambos dentro de los rangos esperados discutidos previamente.

Los autores desarrollaron la solución propuesta utilizando una plataforma de

codificación interna llamada Gygax que permite procesar y visualizar tanto
imágenes como PCD, e incorpora las bibliotecas de código abierto Emgu CV y
Point Cloud Library. La solución utiliza una combinación de código C++ y C#
escrito y compilado en Microsoft Visual Studio 2015. Todos los experimentos
utilizaron un ordenador con un procesador Intel i7 de 4.0-Ghz, 32 GB de RAM, una
unidad de procesamiento gráfico dedicada de 1.280 núcleos (GPU) con 2 GB de
memoria, y Windows 10 sistema operativo de 64 bits.

Experimentos con datos sintéticos

Los primeros experimentos realizados con los datos sintéticos tenían por objeto
determinar qué regla de desonflicción de detección de sucursales produce los
mejores resultados, y cómo las variaciones en la altura de voxel (searchDistance)
afectan a esos resultados. Los autores realizaron 20 ensayos para cada regla de
decisión probada (60 en total), variando la búsqueda entre 0,1 y 2,0 cm en
incrementos de 0,1 cm. Como se discutió anteriormente, el diseño de 40 mm de
espesor del curso de desgaste impulsó la selección de los valores de buscar
distancia probados. La Fig. 9 muestra la puntuación de F1 lograda en cada uno de
estos ensayos.

Experimentos con datos del mundo real

La superficie de recogida de datos del primer día estuvo sujeta a una serie de
oclusiones causadas por un vehículo estacionado, un compactador de rodillos y
múltiples barreras de seguridad asociadas con trabajos relacionados con otras
tareas programadas. Además, el contratista construyó intencionalmente tres
regiones del material de encuadernación a una elevación inferior a la proyectada.
Estas regiones correspondían a zonas en las que las carreteras de conexión
estaban a la espera de su instalación aglomerante asfáltico, tiempo durante el cual
el contratista corregiría las regiones intencionalmente bajas para proporcionar una
conexión sin problemas, Los primeros experimentos con datos del mundo real
eliminaron estas regiones y ocluyeron áreas de ambos conjuntos de datos del
análisis para aislar el desempeño del método en regiones donde las superficies de
verdad del suelo son observables en los datos. Las estrategias para hacer frente a
estas regiones problemáticas se examinan en los párrafos siguientes y son objeto
de una investigación continua.

Ajuste por regiones de error y oclusiones

Los autores experimentaron con el aumento del parámetro de distancia vecino del
método de corrección de valores atípicos para compensar el error y las regiones
ocluidas. Las combinaciones de parámetros de corrección de valores anómalos
producen una puntuación F1 superior al 95% en los datos sintéticos (como se
muestra en la Fig. 10) fueron implementados en el Día 1 y el Día 2 conjuntos de
datos para distancias de búsqueda superiores a 2. El mejor rendimiento general
resultó de una distancia de búsqueda de 7 con un umbral de consenso del 55%. El
cuadro 3 muestra los resultados de esta combinación, con y sin oclusiones
contabilizados en los cálculos de rendimiento. Fig. 13 ilustra los resultados.

Tiempo de procesamiento

La solución propuesta tardó aproximadamente 11 s en generar las decisiones de

detección de superficie incrementales para la sección de carretera de 200 m
analizada previamente utilizando una nube de entrada de 5,5 millones de puntos.
Esto no incluye el tiempo de construcción de Bricktree (40 s) porque este paso
sólo necesita ser completado en la inicialización del proyecto o cuando el diseño
es cambiado. El tiempo total del ciclo (incluyendo inicialización de Bricktree,
recolección de datos y pos procesamiento) fue de aproximadamente 3 h, 35 min el
Día 1 y 2 h, 29 min en el Día 2.