MineSentinel

MineSentinel: Edge-first mine safety combining offline alarms, deterministic safeguards, and ML-assisted risk detection.

Comment

Inspiration

MineSentinel was inspired by a machine-learning application that detects when an older adult falls and alerts the appropriate people. It showed me how sensors and intelligent software could translate a physical event into a timely intervention.

While thinking about other environments with serious safety gaps, I focused on underground mining. Workers can face dangerous gas accumulation, impacts, falls, post-impact immobility, and communication failures. This inspired me to develop a smart safety helmet prototype capable of detecting hazards locally while providing operators with actionable information.

What it does

MineSentinel is an edge-first AIoT safety platform for underground mine workers. An ESP32 connected to an MPU-6050 motion sensor and an MQ-2 gas sensor continuously monitors motion and environmental conditions.

The device can activate its LED and buzzer locally when it detects dangerous gas, an impact, free fall, or post-impact immobility. Because this decision is made on the ESP32, essential warnings remain available even when Wi-Fi or the backend is unavailable.

When connectivity is available, telemetry is sent to a FastAPI backend that combines:

  • An explainable, deterministic risk engine
  • Isolation Forest anomaly detection
  • Random Forest risk classification
  • Pessimistic safety gating
  • Asynchronous LLM-generated incident briefs

The results are presented through a real-time, SCADA-inspired Streamlit dashboard.

How I built it

The project was developed as an end-to-end prototype connecting embedded hardware, backend services, machine learning, and real-time visualization.

The ESP32 firmware was written in Arduino C/C++. It reads motion data from the MPU-6050 over I2C, samples the MQ-2 through the analog ADC, controls a warning LED and buzzer through GPIO, and transmits telemetry using HTTP and JSON.

The backend was built with Python, FastAPI, and Pydantic. It validates telemetry, calculates deterministic risk scores, runs machine-learning inference, and returns an immediate safety response.

Isolation Forest was used to identify unusual sensor combinations, while Random Forest was trained to classify telemetry into risk categories. The models were developed with Scikit-learn and serialized using Joblib.

Because deterministic rules and probabilistic models can disagree, we implemented pessimistic safety gating:

$$ R_{\text{final}} = \max\left( R_{\text{deterministic}}, R_{\text{predicted}} \right) $$

This ensures that a machine-learning prediction can increase the assessed risk but can never downgrade a critical condition identified by deterministic safety rules.

The monitoring interface was built with Streamlit and Plotly. Streamlit fragments allow live telemetry sections to refresh independently, reducing unnecessary full-page rerendering. Critical-event reports are generated asynchronously through the Groq API with cooldown protection, keeping generative AI outside the immediate safety-decision path.

Challenges I ran into

The greatest challenge was accounting for edge cases that emerge when software interacts with the physical world.

For example, a sudden impact does not always mean that a worker has fallen—the helmet itself could have been dropped. Likewise, a stationary reading could indicate post-impact immobility, but it could also occur when the helmet has been removed. These cases demonstrated that a single sensor reading was not sufficient to determine the complete situation.

To improve the decision process, the firmware uses stateful logic that evaluates an event sequence, including an impact followed by sustained near-(1g) immobility. This makes the Man-Down scenario more meaningful than relying on a single acceleration threshold.

Another challenge was maintaining safety during network interruptions. We initially relied too heavily on the backend response for alarm activation. We corrected this by moving essential hazard decisions onto the ESP32 and allowing the backend only to escalate—not suppress—the local alarm.

We also needed to prevent external LLM latency and rate limits from blocking telemetry ingestion. We addressed this by moving report generation into asynchronous background tasks and applying a cooldown between requests.

Accomplishments that I'm proud of

We are proud of building a complete working pipeline rather than a collection of disconnected demonstrations. MineSentinel connects physical sensors, autonomous edge alarms, validated API contracts, deterministic risk scoring, two machine-learning models, asynchronous incident reporting, and a live dashboard.

The project’s most important architectural accomplishment is its defense-in-depth approach:

  • Local alarms do not require network connectivity.
  • Machine learning cannot downgrade deterministic critical hazards.
  • LLM output remains advisory and cannot control immediate safety decisions.
  • Backend or external API failures do not disable the core edge warning mechanism.
  • Architecture decisions, limitations, and safety trade-offs are documented through ADRs.

What I learned

Building MineSentinel changed how we think about embedded systems, backend engineering, machine learning, and interface design.

We learned that creating a safety-oriented AI system is not primarily about selecting the most complex model. It requires careful state management, explicit data contracts, deterministic fallbacks, failure isolation, and honest treatment of uncertainty.

The most rewarding part was designing the complete system from scratch and making independently developed components communicate as one functioning prototype. The process also provided a clearer understanding of how firmware, APIs, machine-learning models, and dashboards influence one another in an end-to-end system.

Most importantly, we learned that AI should support physical safety protections—not replace or override them.

What's next for MineSentinel

MineSentinel is currently a prototype. Its sensor readings, thresholds, and machine-learning models would require industrial calibration, field validation, redundancy, and formal safety certification before real-world deployment.

The next development steps include:

  • Calibrating the gas sensor using controlled reference measurements
  • Adding helmet-wear detection to distinguish a removed helmet from worker immobility
  • Incorporating gyroscope data for more reliable motion analysis
  • Evaluating LoRa or mesh networking for underground communication
  • Adding persistent telemetry and incident storage
  • Testing the system with broader, real-world sensor datasets
  • Replacing process-local cooldown state with shared and durable infrastructure
  • Designing a more rugged and power-efficient helmet-mounted prototype

The long-term goal is to develop MineSentinel into a modular safety platform that helps operators detect compound hazards earlier while keeping immediate protection deterministic, local, and independent of generative AI.

Built With

Share this project:

Updates

Submission history