Build B-01
A mine vehicle driving through fog cannot know how far its sensors can actually see, so nobody can say how fast it is safe to go.
| Condition | Radar 24 GHz | RGB camera | Thermal MLX90640 |
|---|---|---|---|
| Clear, MOR 200 m | 94.6 | 62.8 | 16.7 |
| Fog, MOR 20 m | 94.4 | 16.9 | 16.7 |
| Fog, MOR 8 m | 94.1 | 6.8 | 16.7 |
| Dust, MOR 8 m | 94.1 | 6.8 | 4.3 |
Detection range for a walking person, in metres, straight out of VISOR’s three sensor simulators. Simulator output, not field measurements.
| Layer | Responsibility |
|---|---|
| core | Time base, units, physical bounds, CRC-8, staleness budgets |
| contracts | Every message that crosses a layer boundary |
| perception | Camera, radar and thermal (stages 03-05) |
| visibility | MOR estimation (stage 06, not started) |
| health | Sensor-health engine (stage 07) |
| safety | Risk engine, envelope solver, state machine (stages 08-09) |
| fusion | Track-level fusion (stage 10) |
| v2v | ESP-NOW protocol simulator (stage 11) |
| logging | Append-only event log (stage 14) |
| hmi | Synthetic vision (stage 15) |
VISOR is a retrofit safety and efficiency system for open-cast mine vehicles, written for Smart India Hackathon 2026 (SIH26007, safe operation of mine vehicles in fog and low visibility). It is deliberately not a fog detector and not an object detector. It measures how far the vehicle can actually see, calculates how fast it can safely travel, and enforces that speed even when the perception stack fails.
The work is staged from 01 to 24, with a gate at the end of every stage. Stage 01 froze the architecture: every message that crosses a layer has a contract, and the safety microcontroller is the authority, not the Linux host. Where the engineering reference leaves a choice open, the choice is recorded as an architecture decision record instead of being assumed.
The simulators are the interesting part so far. Radar is flat across conditions because a 12.5 mm wavelength does not care about 1-20 µm fog droplets. The camera’s range collapses as visibility falls. Thermal holds through fog and then loses its advantage in dust, because dust particles are large enough to scatter long-wave infrared and fog droplets are not.
Two decisions are open and belong to the team: ADR-0006 (the Koschmieder constant, needed before stage 06) and ADR-0018 (how usable range combines across modalities, needed during stage 08).
Source: VISOR README, simulator output at the end of stage 05. These are model results, not measurements from a vehicle.
Architecture frozen with data contracts, an authority boundary and a 12-byte MCU frame.
Vehicle dynamics plus radar, camera and thermal simulators. The camera collapses in fog; thermal holds in fog and then fails in dust.
That inversion is why the design refuses a single “fog number”.
No sensors are readily available (one Raspberry Pi 4B and two NodeMCU boards on hand).
Working software-first against simulated sensors, with a physical miniature vehicle planned for the demonstration.
A tested, dependency-free simulation core that shows why visibility has to be measured per modality before speed can be limited.
BUILDING
Stages 01-05 of 24 complete. Stage 06 has not started.
Stage 06, the visibility (MOR) estimator. ADR-0006, the Koschmieder constant, has to be settled by the team first.