LiDAR point cloud processing at the military edge: 3D terrain and obstacle detection on embedded hardware

A 32-channel spinning LiDAR sensor produces roughly 700,000 points per second. Each point encodes a precise range measurement, an azimuth and elevation angle, and a reflectance intensity value. From that raw data stream, a military autonomous platform must derive -- in real time and without connectivity -- a navigable terrain map, a set of obstacle detections, and a compressed representation suitable for transmission over a constrained tactical radio link. That is the engineering problem of LiDAR point cloud processing at the military edge: extracting operationally useful 3D situational awareness from a high-throughput sensor on hardware that may be limited to a 15 W power budget, without a cloud offload path, and under the latency demands of real-time autonomous navigation.

Why LiDAR point cloud processing at the edge matters for military autonomy

Autonomous ground vehicles, unmanned aerial systems operating below the GPS shadow of urban canyons, and dismounted robotic platforms all share the same fundamental dependency: they need a real-time understanding of the 3D geometry around them to navigate safely and accomplish their tasks. LiDAR is the preferred primary sensor for this because it produces metric-accurate range measurements (typically 1--3 cm accuracy at ranges up to 100 m) that are independent of lighting conditions, do not require scene texture to function, and degrade gracefully in light rain and dust. Camera-based depth estimation can supplement LiDAR but cannot replace it in the degraded visual conditions that are common in military operational environments.

The edge constraint is not a choice -- it is a physical and operational requirement. Raw point cloud data from a 32-channel spinning sensor at 10 Hz generates approximately 20--40 MB/s, which vastly exceeds the throughput of any practical tactical radio link (typically 512 kbit/s to 5 Mbit/s in a MANET configuration under load). Even if the link were available, the round-trip latency to a cloud processor and back would consume tens to hundreds of milliseconds -- far too long for collision avoidance decisions on a vehicle moving at speed. For an autonomous ground vehicle traveling at 20 km/h, 100 ms of additional latency corresponds to 55 cm of additional travel distance before the system can react, a margin that is unacceptable near obstacles. Processing on the platform is not a nice-to-have feature; it is a hard latency and bandwidth requirement.

Military edge LiDAR deployments therefore demand algorithms that are both computationally efficient and robust to the degraded conditions of field operation: vibration, sensor tilt, partial occlusion by vegetation, and the absence of the clean structural features (walls, ceilings, floors) that indoor LiDAR SLAM systems depend on. The algorithms discussed in this article are specifically selected for their demonstrated performance in outdoor unstructured environments.

SLAM for terrain mapping: building real-time 3D maps from mobile platforms

Simultaneous Localization and Mapping (SLAM) is the algorithmic backbone of LiDAR-based terrain mapping in GPS-denied or GPS-degraded environments. A LiDAR SLAM system maintains two interacting estimates: the platform's current pose (position and orientation in 3D space) and a map of the environment accumulated from all past scans. Each new scan from the LiDAR is matched against the previous scan or a local submap to compute the incremental motion of the platform, which updates the pose estimate. The pose-stamped scan is then integrated into the growing map, building up a 3D point cloud representation of the terrain the platform has traversed.

The most widely deployed LiDAR SLAM algorithms for military outdoor platforms are LOAM (LiDAR Odometry and Mapping), LIO-SAM (LiDAR-Inertial Odometry via Smoothing and Mapping), and KISS-ICP (Keep it Small and Simple ICP). LOAM extracts edge and planar features from each scan and matches them across frames, achieving low drift on structured terrain but requiring relatively powerful processors to sustain 10 Hz throughput. LIO-SAM tightly couples LiDAR scan matching with inertial measurement unit (IMU) data using a factor graph optimization backend, providing robust odometry on platforms subject to vibration and rapid attitude changes -- conditions that defeat pure LiDAR odometry. KISS-ICP strips the algorithm down to its essential ICP core with a dynamic point-to-point threshold, achieving real-time performance on an ARM Cortex-A55 at the cost of slightly higher drift on featureless terrain.

Loop closure detection is the mechanism that prevents SLAM drift from accumulating unboundedly. When the platform returns to a previously visited location, the back-end optimizer detects the overlap between the current scan and the stored submap, adds a loop closure constraint to the pose graph, and re-optimizes the entire trajectory. For military reconnaissance missions where a UGV or robot traverses a route and returns, loop closure reduces the final map drift from potentially several meters (open-loop ICP accumulation over a 500 m traverse) to centimeters. The trade-off is computational cost: full loop closure detection using scan context or intensity-histogram descriptors requires 50--200 ms per detection attempt, and the graph optimization step scales super-linearly with the number of poses in the graph for large environments.

Obstacle detection and classification on embedded LiDAR hardware

Terrain mapping and obstacle detection are algorithmically distinct tasks that run concurrently on the same point cloud stream. Terrain mapping accumulates scans to build a persistent 3D model; obstacle detection processes each scan independently to identify objects that the platform must avoid or that have tactical significance. The standard pipeline begins with ground plane segmentation: separating the points that belong to the traversable surface from the points that represent above-ground objects. RANSAC (Random Sample Consensus) plane fitting is the classical approach, selecting a random subset of points, fitting a plane model, and iterating until the largest inlier set is found. For outdoor terrain with non-flat surfaces, progressive morphological filters or range-image based ground estimation methods perform better, adapting to slope and undulation.

Above-ground points are then clustered into candidate obstacle regions using Euclidean clustering or density-based spatial clustering (DBSCAN). Euclidean clustering groups points within a configurable distance threshold into connected components, each representing a distinct object. For typical outdoor military scenarios, clustering at 0.5--1.0 m distance threshold groups a person's body into a single cluster and a vehicle into one or a few clusters, while separating individual tree trunks and bushes. Each cluster is then described by its bounding box (dimensions and orientation) and its normalized point distribution, which is fed to a classification network. PointNet and its successor PointNet++ are the standard architectures for this task: they operate directly on the raw (x, y, z) coordinates of the cluster's points, apply a shared MLP to each point to extract per-point features, and aggregate with a global max-pool to produce a fixed-size embedding that is invariant to point ordering. A final MLP classifier maps the embedding to object class probabilities.

Deploying PointNet-style classifiers on embedded hardware requires the same quantization and optimization workflow that applies to image-based TensorFlow Lite model deployment on embedded military hardware. INT8 quantization of a PointNet model reduces the parameter storage from approximately 3.5 MB (FP32) to under 1 MB, and inference latency on a Jetson Orin NX drops from 18 ms to under 5 ms per cluster. Because clusters are processed independently, the total obstacle detection latency for a scan with 20--30 above-ground clusters is typically 50--100 ms on a Jetson Orin NX -- well within the 200 ms end-to-end budget for obstacle detection at 10 Hz scan rate.

Downsampling algorithms: voxel grids, farthest point sampling, and military trade-offs

Raw point clouds from a 32-channel spinning LiDAR contain 50,000--150,000 points per scan. Processing every point through a SLAM algorithm or obstacle detection pipeline is computationally unnecessary and often counterproductive: the point density at short range is far higher than is needed for either task, while the density at long range is too low to add meaningful information beyond what a coarser representation would capture. Downsampling reduces the point count to a level matched to the processing requirement, trading spatial resolution for computational efficiency.

Voxel grid downsampling is the most common approach in military edge deployments. The 3D space is divided into a regular grid of cubic voxels, and all points within each voxel are replaced by their centroid. The voxel size parameter directly controls the resolution--compute trade-off: a 0.1 m voxel size reduces a 120,000-point scan to approximately 5,000--10,000 points for typical outdoor scenes, a 10--20x reduction, while preserving the metric geometry needed for SLAM. A 0.2 m voxel size reduces to 2,000--4,000 points with a corresponding reduction in map resolution. Voxel downsampling is computationally trivial (a hash-map lookup per point) and runs in under 2 ms on an ARM processor, making it suitable for the real-time pre-processing stage that feeds all downstream algorithms.

Farthest point sampling (FPS) is the standard downsampling method used as input preparation for PointNet-style classifiers. Given a cluster of N points, FPS iteratively selects the point that is farthest from the current selected set until K points are selected. This produces a spatially uniform sample that preserves the geometric spread of the cluster -- critical for PointNet, which relies on the global shape structure. The computational cost is O(N * K), which is acceptable for the small clusters (50--500 points) fed to the obstacle classifier, but would be prohibitive for downsampling full raw scans. In practice, voxel downsampling handles the full-scan pre-processing stage, and FPS handles per-cluster normalization immediately before classifier inference.

Point cloud compression for bandwidth-constrained tactical transmission

Even after voxel downsampling, transmitting full processed point clouds over a tactical radio link is rarely viable. A downsampled outdoor scan at 0.1 m voxel resolution with 5,000 points, each encoded as three FP32 coordinates and one reflectance value, occupies approximately 64 KB. At 10 Hz scan rate, the raw stream is 640 KB/s -- exceeding the available throughput of most MANET configurations operating under interference. The practical solution is to transmit derived data products rather than raw or downsampled point clouds: occupancy grids, Digital Elevation Model (DEM) tiles, and structured obstacle detection messages.

A 2.5D occupancy grid encodes the terrain as a grid of cells, each storing the height of the highest LiDAR return and a traversability flag. For a 100 m x 100 m area at 0.25 m resolution, the grid contains 160,000 cells. Storing each cell as a 16-bit signed integer for height plus one bit for traversability, and applying LZ4 compression, reduces the 100 m tile to approximately 15--30 KB depending on terrain complexity. At a 1 Hz update rate per tile, the map streaming load is 15--30 KB/s -- manageable even on a heavily loaded MANET link. The receiving platform can reconstruct a route-planning quality terrain model from these tiles without ever receiving a single raw point cloud packet.

Obstacle detection events are even more compact. A structured message encoding position (3 FP32), class (1 byte), bounding box (3 FP32 dimensions plus 1 FP32 yaw), confidence score (1 FP32), track ID (4 bytes), and velocity estimate (3 FP32) occupies approximately 60 bytes per obstacle. Transmitting 30 obstacles per scan at 10 Hz generates a detection stream of 18 KB/s -- negligible on any practical link. For link budgets under 64 kbit/s, transmitting only the detection event stream (suppressing map tile updates entirely) provides the receiving operator with real-time obstacle awareness at less than 25% of the available link bandwidth.

Hardware platforms: GPU-constrained deployment on Jetson, FPGA, and military SBCs

The NVIDIA Jetson AGX Orin is the current performance reference for military edge LiDAR workloads. Its 2048-core Ampere GPU with 64 Tensor Core units delivers 275 TOPS of INT8 throughput in a configurable 15--60 W TDP envelope. Running a complete LiDAR processing pipeline -- voxel downsampling, LIO-SAM SLAM, ground segmentation, Euclidean clustering, and INT8 PointNet classification -- on a 32-channel sensor at 10 Hz consumes approximately 8--12 W on the Jetson AGX Orin, leaving headroom for communication drivers, mission software, and system overhead within a 20 W platform power budget. For platforms with less generous power allocations, the Jetson Orin NX (10--25 W) handles the same pipeline at 10 Hz if the SLAM back-end optimization is throttled to 5 Hz, and the Orin Nano (5--15 W) is sufficient for simpler workloads that skip full SLAM in favor of scan-to-scan odometry only.

FPGA platforms serve a different role in the LiDAR processing chain. The front-end operations -- point cloud ingestion from the sensor Ethernet port, voxel grid hashing, ground plane RANSAC, and range image generation -- have deterministic latency requirements and benefit from the pipelined parallelism that FPGAs offer. A Xilinx Zynq UltraScale+ MPSoC running voxel downsampling and ground segmentation in programmable logic can deliver sub-millisecond latency with guaranteed throughput, feeding the downsampled, ground-removed cloud to the ARM CPU subsystem for SLAM and to the GPU for classification. This heterogeneous architecture -- FPGA for front-end pre-processing, GPU for learning-based classification, CPU for SLAM back-end -- is increasingly standard in high-performance military UGV programs. Military single-board computers rated to MIL-STD-810G for shock and vibration and to TEMPEST standards for emanations control typically integrate a multicore ARM processor with a PCIe slot that accepts either a Jetson system-on-module or a Xilinx FPGA module depending on the program's latency and certification requirements.

Thermal management is a practical constraint that software teams frequently underestimate when integrating LiDAR processing into a military platform. The Jetson AGX Orin at 60 W TDP produces 60 W of heat that must be conducted away from the module in a sealed, MIL-spec enclosure. Passive cooling solutions using heat pipes and external fin stacks are feasible up to approximately 30 W continuous load; above that, a pumped liquid cooling loop is typically required. Setting the Jetson TDP to 15--20 W using the nvpmodel power mode configuration satisfies most passive cooling budgets while still delivering sufficient throughput for a 32-channel LiDAR pipeline. Thermal constraints affect all military edge inference deployments, not just LiDAR processing, and thermal budgeting should be part of platform design from the first hardware iteration rather than treated as a late-stage integration problem.

Integration with autonomous systems and blue-force tracking for situational awareness

A LiDAR processing pipeline that operates in isolation -- producing terrain maps and obstacle detections that are consumed only by the platform's own navigation stack -- delivers local autonomy but not shared situational awareness. The operational value multiplies when the derived data products from each autonomous platform are shared across the tactical network and fused into a common operating picture that every operator, commander, and connected system can access. The integration architecture for this requires three elements: a georeferenced data format for map products, a structured message format for detection events, and a publish-subscribe middleware that delivers both to consumers at the appropriate update rate and priority.

Terrain map tiles from each autonomous platform are georeferenced using the platform's current SLAM-estimated position and orientation fused with any available GPS fix. The tile is projected into a global coordinate frame (UTM or MGRS grid) and tagged with the generating platform's blue-force tracking ID and a timestamp. TAK Server's geospatial data layer accepts these tiles as Mission Package attachments or as vector geometry overlays, making them visible to every connected ATAK client as a live map layer that updates as the autonomous platform advances. Operators see the terrain structure of areas being scouted by autonomous systems as those systems traverse it, rather than waiting for a post-mission data dump.

Obstacle detections from the LiDAR classifier are published as CoT events to the TAK Server, following the same integration pattern as acoustic gunshot detection AI and other edge sensor systems. The CoT event carries the obstacle class (vehicle, person, structure), the bounding box dimensions and orientation, the confidence score, and the velocity estimate from the tracking filter. Autonomous platforms within communication range of each other can also share detection events peer-to-peer, enabling a shared obstacle map to be maintained across a fleet without requiring a central server. This peer-to-peer obstacle sharing is particularly valuable in urban operations where multiple autonomous systems are clearing a structure and need to maintain a shared picture of cleared rooms and detected threats without relying on a potentially degraded backhaul link to the command post.