LAKESHORELABS
← All work

Large Philippine Delivery Company · FOUNDER TRACK RECORD

IoT fleet management for delivery trucks

In-truck telemetry and predictive analytics for a large Philippine delivery fleet: Raspberry Pi devices reading GPS and engine data over OBD-II, streaming into route and driver-behavior models that reduced fuel consumption and theft incidents.

2019 – 2021 completed
IoT fleet management architecture: in-truck Raspberry Pi telemetry over OBD-II streaming to cloud XGBoost models and a fleet operations dashboardFIG. 01 / TRUCK TO DASHBOARD: FLEET TELEMETRY PIPELINEPHILIPPINE DELIVERY NETWORK / RASPBERRY PI + OBD-II + GPS / XGBOOST ANALYTICSIN-TRUCK HARDWAREx N TRUCKSCLOUD PLATFORMOBD-II PORTCAN BUS PIDSRPM SPEED FUEL DTCGPS MODULE1 HZ FIXRASPBERRY PIEDGE READER + RING BUFFER4G LTE MODEMSTORE AND FORWARDBUFFERS ON SIGNAL LOSS,REPLAYS WHEN COVERAGE RETURNSPOLL @ 1 HZJSON FRAMESMQTT / TLS@ 5 STELEMETRY INGESTMQTT BROKERTRIP STOREDECODED FRAMESROUTE OPTIMIZERXGBOOST / PYTHONDRIVER BEHAVIORXGBOOST / PYTHONFEATURES PER TRIPFLEET OPS DASHBOARDFUEL ALERTSTHEFT ALERTSROUTE PLANSRISK SCORESDEPLOYED 2019-2021 / METAPRISEOUTCOME: REDUCED FUEL CONSUMPTION AND THEFT INCIDENTS

Delivered by our founder at Metaprise Systems (2019 to 2021), before Lakeshore Labs was formed. It is part of the track record we build on, not a Lakeshore engagement.

The challenge

A large Philippine delivery company ran a substantial fleet of trucks across the archipelago with almost no visibility into what happened between depot gates. Once a truck left the yard, operations knew nothing about where it was, how it was being driven, or how much fuel it was actually burning. Fuel costs drifted upward with no way to tell aggressive driving from bad routes from outright siphoning, and theft, of both fuel and cargo, was a persistent and largely unprovable loss.

The environment made the obvious answers hard. Off-the-shelf fleet telematics priced per vehicle was uneconomical at this scale, and cellular coverage along provincial routes drops constantly. Any system that assumed an always-on connection would silently lose exactly the trips that mattered most.

What we built

The system has two halves, matching the diagram above: cheap rugged hardware in every truck, and a cloud platform that turns the resulting telemetry into decisions.

In-truck hardware: Raspberry Pi on the OBD-II port

Every truck built since the mid-1990s exposes an OBD-II port, a standard diagnostic connector onto the vehicle’s CAN bus. Polling it gives you the engine’s own ground truth: RPM, vehicle speed, fuel level, and diagnostic trouble codes, with no aftermarket sensors to install or calibrate. We paired that with a GPS module producing a position fix at 1 Hz.

The edge unit reading both was a Raspberry Pi: cheap enough to put in every truck, easy to source and replace in-country, and powerful enough to do real work locally. It polled the OBD-II port and GPS at 1 Hz, decoded the CAN bus PIDs, and assembled timestamped JSON frames into a ring buffer so a unit could run unattended for long stretches without filling its storage.

Store-and-forward over 4G

Connectivity was treated as unreliable by design. A 4G LTE modem uplinked frames to the cloud over MQTT with TLS, batched roughly every five seconds. When the signal dropped, in tunnels, mountain passes, or rural dead zones, the Pi simply kept buffering. When coverage returned, it replayed the backlog in order. The cloud saw a complete trip either way; the only difference was latency. This store-and-forward discipline is what made the data trustworthy enough to act on.

Cloud platform: from frames to fleet decisions

On the cloud side, an MQTT broker ingested telemetry from every truck and wrote decoded frames into a trip store. From there, per-trip features fed two XGBoost models built in Python. A route optimizer learned which routes actually cost what, in time and fuel, under real traffic and load conditions, and produced route plans. A driver-behavior model scored trips for patterns like harsh acceleration, excessive idling, and unexplained fuel-level drops, producing per-driver risk scores.

Both models surfaced in a fleet operations dashboard: live truck positions, route plans, fuel alerts when consumption diverged from what the model expected, and theft alerts when fuel level fell in ways driving could not explain.

How it was delivered

Delivery started with a small pilot fleet to prove the hardware could survive daily duty cycles, heat, vibration, and patchy power, and that the store-and-forward pipeline produced complete trips. Once the data was trustworthy, the models were trained on accumulated trip history and the dashboard was put in front of operations staff, whose feedback shaped the alerting. Installation then scaled across the fleet truck by truck, with the per-unit hardware cost low enough that rollout never needed a procurement fight.

What shipped

The operator went from no visibility into its trucks to a per-trip, per-driver record of the entire fleet, and the result was reduced fuel consumption and fewer theft incidents.

Raspberry PiOBD-IIGPS telemetryPythonXGBoost

Want something like this running against your data?

Start a prototype sprint