Municipal waste collection in the case study city ran on fixed routes with no real time visibility. Administrators could not tell whether a van was on schedule or had skipped a zone, route planning was done on assumption rather than data, and a citizen who filed a complaint had no way of knowing whether anyone had acted on it. The failure was not any one of those things on its own — it was that the vans, the complaints and the routes were three separate systems that never spoke to each other.

An end to end IoT system that closes that loop. A NodeMCU ESP8266 paired with a NEO-6M GPS module rides in each collection van and streams its position over a WebSocket to a Node/Express server, which broadcasts it out to every connected client. A MERN stack web application then gives each of the three groups the view it actually needs: a live fleet map for the municipal corporation, an assigned route and complaint queue for the driver, and a “where is my complaint” status page for the citizen who filed it.

• WebSockets over HTTP polling. A van reports every few seconds. Polling that from a dozen browsers would have meant thousands of near-empty requests an hour; one persistent socket per van, broadcast out through socket.io, keeps the map live without the traffic. On the device side that meant WebSocketClient.h on the ESP8266 and TinyGPS++ to parse the NEO-6M’s NMEA sentences.
• OpenStreetMap and Leaflet over a paid maps API. This had to be viable on a municipal budget, not just as a thesis demo. Per-request billing would have made the live map the single most expensive part of running the system.
• Coordinates as the primary key of a complaint. A complaint is filed against a point on the map, not a free text address. That is what makes it possible to assign complaints to routes automatically, and to measure whether a route actually passed the places it was meant to.
• Built to run convincingly on simulated GPS during development, since the hardware was not always available and a thesis demo cannot depend on a van being out on a round. The dashboard below uses the same approach, for the same reason.

• A GPS fix is not a position. The NEO-6M drops out under cover, and raw fixes jitter by tens of metres while a van sits still. Points had to be filtered before they were trusted, or the map showed a parked van wandering around the depot.
• Rendering a moving fleet without melting the browser. Every van pushing updates into a Leaflet map with per-marker redraws does not scale, so updates were batched and markers grouped by zoom level rather than redrawn one at a time.
• Defining “route efficiency” at all. Turning raw position pings into a number meant first deciding what an efficient route through a collection zone looks like, then measuring deviation from it: distance covered against bins actually served, and time spent inside the zone against time spent getting to it.
• Keeping the citizen view simple while the admin view stayed dense. The same underlying data has to read as a one line status to one user and as a planning dashboard to another.

Each unit is a self contained box: a NodeMCU ESP8266 with onboard WiFi, a NEO-6M GPS module and its antenna, a lithium polymer battery with a micro-USB charging port, and a toggle switch so a driver can power it without opening anything. Nothing about it needs attention during a round — a deliberate constraint, because a tracking device that needs attention is a tracking device that gets switched off.

Passwords are hashed with bcrypt rather than stored, CORS is configured explicitly rather than left open, and each of the three roles only reaches the endpoints belonging to it. This is a system holding citizens’ phone numbers alongside their home coordinates; treating that casually was not an option.