Underground mine corridors have no cellular coverage, no GPS, and variable power infrastructure. A robot that inspects them cannot transmit data in real time and cannot count on consistent connectivity at any point during the run. This post describes how we structure the data pipeline for underground inspection: what processing happens onboard the robot, how data is managed during the disconnected interval, and what gets delivered to the operator's dashboard after the robot surfaces.
The Core Constraint: No Real-Time Uplink
Above-ground inspection in open environments can, in principle, relay data back to a cloud processing endpoint during the run. Tethered above-ground robots can pipe data over the tether link. For underground mine corridors, neither of these options is reliable. RF propagation in rock-bounded tunnels is range-limited and geometry-dependent. LTE has no coverage below ground. Wi-Fi mesh systems exist in some modern mines but are not universal, are not available in older or inactive workings, and cannot be assumed as a design dependency for a system intended to operate across varied infrastructure.
The design choice is therefore edge-first. All data processing that needs to happen in real time or near-real time happens on the robot's onboard compute hardware. Everything else is buffered to local storage and uploaded when the robot returns to a connectivity-available location, which is typically at the mine portal or a designated surface relay station.
This is not a novel approach in industrial robotics. Autonomous underwater vehicles have operated on the same buffered-and-surface-upload model for decades. The engineering problem is managing the onboard compute budget, the storage capacity, and the data prioritization logic to ensure the right information is available in the right form when the robot surfaces.
Onboard Processing: What Has to Happen Underground
Three categories of processing must happen onboard during the run rather than being deferred to post-surface upload.
Navigation state is the most critical. The robot needs its position estimate continuously updated throughout the run to maintain its planned path, avoid obstacles, and correctly associate any detected anomaly with its physical location in the mine structure. This requires continuous IMU integration, visual odometry frame matching, and map update operations running at the navigation loop frequency. If this computation were deferred, the robot would not have a usable position estimate, which means it could not navigate. Onboard compute for navigation is non-negotiable.
Defect detection inference runs onboard as a second continuous process. The alternative would be buffering all raw imagery for post-surface processing. A high-resolution camera at inspection resolution generates data volumes that would require either expensive solid-state storage for extended runs or aggressive compression that degrades the image quality needed for defect classification. Running inference onboard and storing the defect classification outputs plus the associated imagery crops for flagged events, rather than full-resolution video, dramatically reduces storage requirements while preserving the data that matters.
Safety monitoring is the third onboard real-time requirement. The robot monitors its own system state for mechanical issues, power levels, and tether status throughout the run. Decisions about whether to continue, pause, or initiate a return-to-origin sequence based on these signals have to happen onboard without waiting for human review of data that has not yet been uploaded.
What Gets Buffered and How
The buffer storage system holds several categories of data during the run. The position log records the robot's estimated position and orientation at regular time intervals throughout the run. This is the geographic reference that allows every defect finding to be localized within the mine structure after the fact. Position log entries are compact compared to imagery, so they are stored at high density throughout the entire run.
Event imagery is the core inspection record. When the defect detection model flags a potential anomaly, a burst of images around that event is saved in full resolution. The burst window captures the pre-event, the event frame, and post-event frames to allow review of whether the classification was based on a genuine surface condition or a sensor artifact. Each event record includes the position log entry for the corresponding time, sensor readings from the ultrasonic array and IMU at the time of the event, and the model's classification result and confidence score.
Run continuity imagery is a separate stream at lower resolution covering the complete path traversal. This is not used for defect detection but serves as a record that the robot actually visited each segment of the inspection path, which is operationally relevant if there is a dispute about coverage or if a later manual inspection finds something the robot missed.
System telemetry is logged throughout: motor temperatures, battery state, tether tension if tethered, and any error or warning events from the subsystem monitors. This data feeds post-run analysis of robot performance and is essential for diagnosing anomalous behavior that does not produce an immediate mission failure.
The Surface Upload and Processing Step
When the robot returns to the mine portal or surface relay point, the onboard buffer is synchronized to the cloud processing backend. The transfer is structured as a prioritized upload queue. Event records with high-confidence defect classifications and critical severity flags transfer first. Run continuity imagery and system telemetry transfer in the background after the high-priority inspection data is confirmed uploaded.
The cloud processing step combines the onboard classification results with the position log to assemble the structured inspection report. Each defect finding is geolocated on the mine structure map using the position log. Findings are grouped by corridor segment, sorted by severity, and assigned identifiers that link to the imagery record for each event.
The output delivered to the operator dashboard is a structured inspection report with a segment-by-segment coverage map, defect location markers referenced to the mine structure geometry, severity-tiered findings, and direct access to the imagery crops for any flagged event. The intent is that an engineer reviewing the report can navigate directly to the imagery evidence for any finding that warrants closer review, without having to search through unstructured video footage.
Latency From Run End to Report Available
The upload and report generation step is not instantaneous. For a robot returning from an extended underground run, the upload volume depends on the number of event records generated and the quality of the uplink at the surface transfer point. A run with a modest number of defect events on a corridor with good surface connectivity can produce a report within a few minutes of the robot surfacing. A run with high event density or over a slower uplink will take longer.
We have designed the report generation pipeline to produce a preliminary report from the high-priority event records as soon as those are uploaded, before the run continuity imagery and telemetry transfer completes. This means the operator can begin reviewing the most critical findings while the balance of the run data is still uploading, rather than waiting for a complete transfer before anything is visible.
There is a tradeoff here that is worth naming. Prioritizing speed of preliminary report delivery means the operator sees findings before all the corroborating context data (run continuity imagery, full telemetry record) is available. A finding that looks ambiguous in the preliminary view might be clarified once the surrounding run imagery is available. We provide a clear indication in the dashboard when a report is preliminary versus complete, so the operator knows the current state of the data and is not making decisions based on a report they believe is final when it is not.
What the Edge-First Architecture Does Not Solve
Edge-first processing puts real constraints on the compute hardware that fits within the robot's mass and power budget. The onboard model inference must run within the power and thermal envelope of a system that is also running navigation, sensor acquisition, and safety monitoring simultaneously. Pushing inference model size beyond what the onboard hardware handles within that envelope means either reducing run duration (more power draw) or reducing navigation and safety monitoring quality (unacceptable), or deferring more of the inference to post-surface (which brings back the full-resolution storage problem).
The current design uses a model configuration sized for the available edge compute hardware, which is a meaningfully smaller model than the largest version we have trained. Defect detection accuracy on the edge model is lower than on the full model running on server-class hardware. We know the gap and it is an active area of work. Model optimization for edge deployment, specifically distillation and quantization approaches that preserve detection quality while reducing the compute requirement, is a different problem from dataset construction and model training, and it has its own set of constraints.
It is also worth being clear that the pipeline described here is designed and tested on collected data, not yet on operational underground runs. The data volumes, upload latency, and report generation timing we describe are estimates based on our test environment, not measured operational figures. The actual performance on real underground infrastructure will depend on variables, including actual mine connectivity quality and real-world event density, that we have not yet characterized in a live deployment.
