3. Data acquisition sources

Vehicle intrusion and deformation measurement begins long before any Python script runs. The quality, density, and coordinate consistency of the raw geometry you capture determines what your automation can realistically compute. This section examines the four principal acquisition sources used in crash and static testing — structured-light/laser 3D scanners, photogrammetry, LiDAR, and coordinate measuring machines (CMM) — and how each one's data characteristics shape the downstream pipeline.

What Each Source Actually Produces

It is tempting to treat all four as "point clouds," but they differ in sampling principle, accuracy, and the coordinate frame they naturally inhabit. Understanding these differences prevents the most common automation failure: feeding data into a measurement routine that assumes a precision the source never had.

The accuracy figures are representative ranges, not guarantees — they depend on standoff distance, surface finish, ambient light, and calibration state. Always confirm the actual specification for your instrument and setup before setting tolerance thresholds in code.

3D Scanners: Dense Geometry for Local Intrusion

Structured-light and laser-line scanners are the workhorse for measuring localized deformation — a door panel pushed inward, a B-pillar buckle, or a floor pan crease. They deliver the density needed to resolve small features, but they require line-of-sight and often multiple scans stitched together.

A practical acquisition workflow for a crash-tested door assembly might look like this:

1. Mount the specimen on a rigid fixture and apply photogrammetric targets or coded markers at known reference positions.
2. Scan from at least three overlapping viewpoints to cover occluded regions behind the intrusion.
3. Register scans using the coded markers, then merge into a single cloud.
4. Export as PLY with a documented unit (millimetres) and coordinate frame.

In Python, the first sanity check after loading is always the bounding box and point count:

import open3d as o3d
import numpy as np

pcd = o3d.io.read_point_cloud("door_scan.ply")
pts = np.asarray(pcd.points)
print("points:", len(pts))
print("bbox min:", pts.min(axis=0))
print("bbox max:", pts.max(axis=0))
print("extent (mm):", pts.max(axis=0) - pts.min(axis=0))

If the extent is off by a factor of 1000, the file is in metres, not millimetres — a frequent and silent error that corrupts every downstream measurement. If the point count is unexpectedly low (say, a few thousand instead of millions), the export may have decimated the cloud or saved only the sparse registration markers.

Photogrammetry: Full-Body Coverage and Scale

Photogrammetry reconstructs geometry from overlapping photographs. Its strength is capturing an entire vehicle or large structural region in one consistent coordinate frame, which makes it ideal for global deformation mapping rather than fine local detail. The critical dependency is scale: without a known-length reference (a scale bar or calibrated target), the reconstruction is dimensionally arbitrary.

Typical practice is to place coded targets around the vehicle, include at least one scale bar of certified length, and capture 60–80% image overlap. After processing in software such as Metashape or COLMAP, you export a dense cloud and a camera-parameter file. The scale bar lets you verify that the reconstructed distance matches the certified length within, for example, 0.2 mm; if it does not, the bundle adjustment has not converged and the cloud should not be used for measurement.

LiDAR: Large-Scale and Dynamic Capture

LiDAR excels where the scanner cannot reach or where the scene is too large for close-range triangulation — full-vehicle exterior scans, crash-test tracks, or dynamic deformation captured at speed. Its lower point density and larger uncertainty mean it is better suited to gross intrusion envelopes than to sub-millimetre feature measurement.

LiDAR clouds are unorganized and often carry per-point intensity and timestamp. For crash analysis, the timestamp matters: it lets you separate pre-impact and post-impact geometry if the scene was scanned repeatedly. A common preprocessing step is to crop the region of interest and remove ground returns before registration:

# Crop to a bounding box around the front structure (mm)
bbox = o3d.geometry.AxisAlignedBoundingBox(
    min_bound=np.array([-1200, -900, 0]),
    max_bound=np.array([ 1200,  900, 1600]))
roi = pcd.crop(bbox)
print("ROI points:", len(roi.points))

If the ROI returns zero points, check the coordinate frame convention — some LiDAR exports use a vehicle-centric frame with the origin at the rear axle, others use a sensor-centric frame. Documenting the frame in the file metadata or a sidecar JSON is essential for automation.

CMM: Sparse but Authoritative Reference Points

The CMM provides the highest accuracy but the lowest density. It is used to establish datum features, measure specific reference points, and validate the other sources. In a crash-test context, CMM data typically appears as a table of nominal and actual coordinates for designated measurement points defined by the test protocol.

Because CMM points are discrete and individually identified, they are the natural anchor for aligning dense clouds. A robust approach is to register the scanner or photogrammetry cloud to the CMM points using a rigid transform, then report residuals:

# cmm_pts: Nx3 array of measured reference points (mm)
# cloud_pts: corresponding points picked from the dense cloud
# Compute rigid transform and inspect residuals
T = o3d.pipelines.registration.
    TransformationEstimationPointToPoint()
result = o3d.pipelines.registration.evaluate_registration(
    cloud_pcd, cmm_pcd, 5.0, np.identity(4))
print("fitness:", result.fitness)
print("inlier RMSE (mm):", result.inlier_rmse)

An inlier RMSE well above the CMM's own uncertainty (for example, 3 mm when the CMM is ±0.02 mm) indicates a registration or frame problem, not a measurement problem. Investigate before proceeding.

Choosing and Combining Sources

The decision is driven by the measurement question. Local intrusion depth on a specific panel favours a 3D scanner. Global body deformation favours photogrammetry. Large or dynamic scenes favour LiDAR. Datum establishment and validation favour the CMM. In practice, a single test campaign often uses two or three sources, registered to a common frame through shared targets or CMM reference points.

Practical Failure Modes and How to Catch Them

Three problems account for most acquisition-related automation failures. First, unit mismatch: a cloud in metres fed into a routine expecting millimetres produces intrusion values off by 1000×. Catch it with the bounding-box check shown earlier. Second, frame mismatch: two clouds registered to different origins produce a rigid offset that looks like deformation. Catch it by verifying that shared reference points coincide within tolerance. Third, scale drift in photogrammetry: a reconstruction without a certified scale bar is dimensionally meaningless. Catch it by comparing a reconstructed known distance against its certified value before any measurement.

With acquisition sources understood and validated, the next stage is turning these heterogeneous clouds into consistent, comparable geometry — the subject of the following section on preprocessing and registration.