Back to case studies
Hardware & EmbeddedIoT & Embedded Systems

NAPL — autonomous groundwater oil-extraction rig with mobile + web ops

Client NAPL
Duration 2.5 months
Type Environmental remediation hardware + IoT web portal + mobile app
ESP32Arduino framework on PlatformIOWater-level detection probeReel motor + oil-extraction pumpCustom PCBWeatherproof field enclosureBattery + solar powerIoT web portal (fleet ops + history)Flutter mobile app (field operator)
water-filteration
water-filteration
water-filteration

Constraint

The box they were trapped in

NAPL needed a field-deployable rig that detects the water table inside an oil-contaminated borehole and pulls only the floating oil layer off the top — without disturbing the underlying water column. Operators in the field also needed remote monitoring and control: an IoT web portal for fleet ops and a mobile app for the field tech standing next to the borehole. Power has to come from battery or solar in places where shore power isn't an option.

Approach

How we attacked it

ESP32-based controller running a reel-mounted water-level sensor and a separate oil-extraction pump. The reel motor lowers the sensor into the borehole; the controller detects the moment the probe touches the water surface and freezes the descent. A second pump activates above that line and skims the floating NAPL layer off the top, taking advantage of the natural oil-water density gradient instead of trying to actively separate the streams. Custom PCB in a weatherproof enclosure; battery or solar power for field-only sites. The IoT web portal handles fleet visibility and historical logs; the Flutter mobile app gives the on-site tech direct command of the rig.

Decisions

What we picked, and what we rejected

01

Density-based oil skim, no active separation chemistry

Oil and water already separate by density in a borehole. Adding a chemical or membrane stage would have multiplied the BOM, added consumables that need replacement in the field, and given operators one more thing to maintain. Letting physics do the separation kept the rig serviceable in conditions a city utility crew can support.

02

Reel-and-detect probe over continuous level sensing

A continuous level sensor in a contaminated borehole has fouling and calibration problems we'd have to manage forever. Lowering a probe each cycle, detecting the water surface, and pulling the probe out trades a few seconds per extraction for a sensor we don't have to babysit between deployments.

03

Battery + solar flexibility instead of one fixed power architecture

Remediation sites range from peri-urban with shore power available to fully off-grid pads with no infrastructure. Designing the rig to accept either battery or solar input meant we could ship one SKU instead of two, and the field deployment team picks the right power input per site.

04

Both an IoT web portal and a mobile app on the same backend

The fleet operator wants history, alerts, and aggregate reporting at a desk; the field tech wants direct control standing next to the rig with their phone. Building both on the same backend means one source of truth — no syncing two parallel state stores, no question of which UI shows the latest reading.

Trade-off

What we didn't build

We left active separation chemistry off the rig — natural density separation does most of the work for free, and reaching for a chemical or membrane stage would have ballooned the BOM and the maintenance burden in field conditions. The reel-and-detect mechanism is mechanically simpler than continuous level sensing, but every extraction cycle costs a descent — fine for the duty cycle of remediation work, wrong for high-throughput water treatment. We picked solar/battery flexibility over a single fixed power architecture because the boreholes aren't all in the same kind of site.

Outcome

What changed after we shipped

A modular, low-power, field-deployable rig that pulls floating oil off contaminated groundwater without disturbing the water below. Operators run a fleet through the IoT web portal and the field tech runs the device in front of them through the Flutter app — both feed the same backend, no parallel data stores. Demos: web portal at https://www.loom.com/share/ab74f0c3a36344a785522d1a5c1efb42, mobile app at https://www.loom.com/share/dc50bbf6dd2142a1829a2c328b193892.

Talk to us

Have a similar project in mind?

Tell us what you're working on. We'll let you know whether it's a fit.