When someone says a microcontroller cannot do something, the conversation usually ends before the engineering work begins. That is exactly the tension this project embraced: a Need for Speed Underground 2 style minimap running on an ESP32 P4 with a 3.4-inch 800 by 800 Waveshare display, using real-world GPS and local data tiled into a navigable grid.
The real significance here is not that the display can show an image. It is that a full geographic tiling pipeline, with live GPS, waypoint layers, and subsecond map updates, can be made to behave acceptably on hardware whose ecosystem was not designed for that scale. What actually determines whether this matters is how you manage two bottlenecks: storage of millions of tiles and the I/O latency of loading them from removable media.
This article walks through the design choices, data sources, and optimizations that turned an idea most people assumed impossible into a working in-car mini map. It also shows where the system’s usefulness is defined by tradeoffs in storage, memory, and rendering strategy, and why the creator chose to rotate the vehicle icon rather than the map tiles themselves.
What most people misunderstand is that visual complexity is often cheap, but movement and latency are not. With clever tiling, selective conversion, and a different approach to rotation, the ESP32 Minimap becomes less about raw horsepower and more about smart limits.
Why A Mini Map On An ESP32
Mini maps are familiar UI on consoles and PC games because they compress spatial awareness into a glanceable visual. Translating that into a car dashboard requires the same affordances: immediate orientation, nearby waypoints, and a smooth sense of motion. The creative brief here was to capture the aesthetic of Need for Speed Underground 2 while remaining functionally useful for local navigation and waypoint awareness.
The creator selected an ESP32 P4 module paired to a 3.4-inch 800 by 800 Waveshare display. Choosing that board was strategic: among ESP32 variants, the P4 is one of the most capable for graphics and peripheral handling, so it raises the ceiling for what can be attempted on a microcontroller platform.
What An ESP32 Minimap Is
The ESP32 minimap is a locally rendered map experience that combines preprocessed tile images, a GPS feed, and a small runtime cache to deliver subsecond updates on constrained hardware. It prioritizes waypoint visibility and motion smoothing over continuous high-resolution streaming, placing preprocessing and storage at the center of the pipeline.
From Raw Maps To Tiles
Data Sources And Why They Matter
Real maps require reliable inputs. For this project, the base geography came from Ordnance Survey for roads, buildings, woodlands, and waterways. Railway stations were included in that dataset. Additional waypoint layers like airports, seaports, and car parks were taken from UK Department of Transportation downloads. Petrol stations were not available as a clean single download, so the OpenStreetMap extract for the UK was used instead.
OpenStreetMap tags make it possible to extract features by key. Every petrol station has amenity=fuel either as a node or as a polygon. The developer wrote a Python script to parse the roughly 2-gigabyte UK OSM dump, convert nodes to latitude/longitude, find centroids of polygons, and emit a point layer of fuel locations. The same script can be repurposed to extract any tagged feature from an OSM dataset.
QGIS And Tile Generation
QGIS provided the styling canvas. After compositing the base layers and waypoints, the Quick Map Services plugin was used to export the working view into XYZ tiles. That sounds simple until the scale becomes real. The initial run generated approximately 2,533,800 tiles for the chosen zoom level across the mapped area of the UK. Tiling was not instantaneous; the export took many hours, and the pipeline reported dramatically different interim counts before finishing.
What becomes obvious when you look closer is that the majority of generated tiles can be pruned. Coastal and ocean tiles were uniformly blue; large swathes of blank land used identical empty tiles. Those uniform tiles were detected by file size profiling, and a threshold rule was introduced to skip tiles smaller than 881 bytes. That simple filter cut the storage burden by eliminating redundant images.
Process: Converting And Moving Tiles For The Device
Tiles exported as PNGs do not match the display driver format on the ESP32. A conversion pipeline turns PNGs into BIN image blobs that the device can stream and blit efficiently. The conversion step took roughly eight hours after pruning, and copying the converted files to an SD card required another 22 hours for this dataset.
Conversion, Storage, And The Cost Of Scale
Tiles on disk as PNGs are not directly usable for the ESP32 display driver. A conversion pipeline turned PNG tiles into BIN image blobs formatted for the device. The conversion process alone required a further 8 hours for the full dataset after pruning. Transferring the converted images to an SD card consumed another 22 hours. The final on-device dataset occupied approximately 236 gigabytes of image blobs on the SD card.
Two explicit constraints surface here. First, storage requirement: a complete tiling of a large area at a given zoom level can easily reach hundreds of gigabytes unless the data set is aggressively pruned. In this case the developer kept the image set to roughly 236 gigabytes after filtering. Second, I/O latency: each tile loaded from the SD card took about 0.1 seconds, so naive on-demand loading would produce noticeable stalls during movement.
Quantified context makes the tradeoff visible. At 0.1 seconds per tile, loading ten new tiles equals one second of frozen animation. That is why the software design must minimize new tile reads per frame and prefer pointer or buffer shuffling over fresh disk reads.
Designing For Motion On Limited Hardware
Anticipatory Loading And Buffering
The core software trick was to avoid loading all visible tiles from scratch every frame. Instead the system keeps a sliding window of tiles in memory and only loads new tiles that enter the viewport based on direction of travel. If the vehicle is moving north, only tiles coming from the top edge need to be fetched and swapped in. Side and rear tiles can be recycled by shifting pointer references.
The result is a reduction in fresh disk reads per second from dozens to a handful. That change alone transformed the user experience from juddery to passably smooth.
Rotation Tradeoffs And The Oracle Decision
Early attempts tried to rotate the entire map image to align the world with the vehicle heading. That required rotating a large grid of tiles in software at update time, which tanked performance. The moment this breaks down is when rotation becomes an O(n) pixel operation on each update, and the ESP32 does not have the bandwidth for that at useful frame rates.
The practical solution was a design tradeoff: keep map tiles north-facing and rotate only the vehicle icon. From a user experience perspective, that preserves orientation and dramatically improves rendering performance. It is a fidelity versus responsiveness decision. The interface no longer matches the exact dynamic rotation in the original game, but it preserves the essential navigation cues while increasing frame rates and smoothing animation.
Map Rotation Vs Icon Rotation
Choosing between rotating the map or rotating the icon is a real engineering pivot: one approach needs heavy per-frame pixel work, the other needs only a small sprite transform. On the ESP32, the sprite transform is far cheaper. This comparison frames the decision around performance cost, implementation complexity, and perceptual impact rather than theoretical fidelity.
Performance Differences
Rotating the map forces large memory reads and per-pixel math for every visible tile on each update. Rotating the icon replaces that with a single lightweight draw operation. That difference explains why the single-icon rotation was the pragmatic choice for smooth motion on limited hardware.
User Experience Differences
From the driver’s perspective, map rotation offers a feeling of the world turning under the vehicle, while icon rotation keeps the world fixed and the vehicle moving within it. The minimap prioritized consistent waypoint visibility and low latency over game-accurate rotation effects.
Field Testing And Real World Behavior
Testing in a car revealed the important interaction patterns. Boot time needs a visible loading state while GPS fixes are acquired. Sharp turns and roundabouts expose the limit case for tile fetching because many new tiles can be required in short order. In practice the system handled roundabouts, tight corners, and waypoint displays with no perceptible frame drops once the buffering scheme and single-icon rotation were applied.
This field test also surfaced a UX insight: waypoint visibility is more valuable than continuous high resolution. The developer prioritized petrol stations, airports, and other points of interest so that when a tile comes into view the icon appears immediately, delivering information even if the surrounding map detail is still streaming in.
One quotable observation: The technical problem was never making the map look good, it was making it move without asking for more hardware.
Two Concrete Constraints That Define This Project
Constraint One, storage scale: Tiling a large geographic area at a useful zoom level will often fall into the hundreds of gigabytes before pruning. For this project the pruned BIN image set consumed about 236 gigabytes. That scale defines deployment choices such as SD card speed, filesystem robustness, and the need for automated pruning pipelines.
Constraint Two, I O latency: When each tile takes about 0.1 seconds to load from external storage, the developer must design the runtime to limit new tile loads to a few per second. This latency threshold informed the anticipatory loading algorithm and the decision to rotate only the car icon to avoid per-frame heavy pixel work.
ESP32 Vs Single Board Computers
The project deliberately frames microcontrollers as a constrained alternative to single-board computers rather than a drop-in replacement. Single-board computers generally offer more CPU and GPU-style operations, but they also change power, boot, and integration tradeoffs. The minimap shows that with heavy preprocessing and careful runtime design, an ESP32 can host a usable, polished visual map experience.
When To Consider A Different Platform
If continuous high-resolution rotation, live map rendering, or dense urban tiling without aggressive pruning are required, a platform with more runtime memory and faster storage may be a better fit. The ESP32 excels when preprocessing and storage are acceptable tradeoffs for runtime responsiveness.
What This Means For Makers And Car Modders
From an editorial standpoint, the project reframes microcontrollers as platforms for constrained creativity rather than brute force substitutes for single-board computers. The ESP32 ecosystem is viable for polished visual projects if you accept and design around three realities: storage scale, I O latency, and the limited GPU-style operations available on the module.
For others who want to attempt this, the recipe is clear in practice. Use robust data sources like Ordnance Survey and OpenStreetMap, generate and prune tiles in QGIS, convert into device-friendly blobs, and design a tile cache that anticipates motion. Be prepared for multi-day processing steps and hundreds of gigabytes of intermediate data.
Two practical recommendations that emerged from the build: prioritize point of interest layers over raw photographic detail, and plan for automated dead tile pruning based on file size or color signatures to avoid wasting storage on identical sea or blank tiles.
Where The Project Goes Next
The creator plans to integrate this minimap into a larger Need for Speed-inspired digital dashboard for a 350Z. That next stage is about aesthetics, mounting, and the physical work of making the assembly look OEM. Expect 3D printing, custom PCBs, and interface polishing in the coming weeks.
Beyond this specific car project, the bigger implication is that microcontrollers can host locally rendered, styled map experiences when the data pipeline is shifted off the live device. This shifts the engineering burden to the preprocessing stage and rewards careful tradeoffs at runtime.
The code used to extract OSM features, generate tiles, convert images, and render the minimap is published by the creator in a public repository for anyone who wants to experiment or extend the idea. That repository contains the Python extraction script, QGIS export notes, and the ESP32 rendering code so others can iterate without repeating the entire data preparation slog.
What determined success here was not a single hack but the cumulative effect of many small choices that reduced real time workload: prune tiles, cache aggressively, avoid per-frame heavy image transforms, and prioritize informational clarity over visual parity with the original game.
As the landscape of in-car displays evolves, projects like this show that creative reuse of game design patterns can make driving interfaces both useful and emotionally resonant. The next interesting question is how far this can scale in city environments where tile density and waypoint churn are much higher, and what hybrid strategies will be required to keep storage and latency within practical bounds.
That is the engineering thread to follow next.
Hope something good happens to you today and see you in the next build.
Who This Is For And Who This Is Not For
Who This Is For: makers, hobbyist car modders, and developers who can accept long preprocessing times, large SD card storage, and a design that favors low runtime latency over live rendering. The project rewards careful planning and familiarity with GIS tooling.
Who This Is Not For: anyone who needs live high-resolution rotation, continuous streaming maps without pruning, or a drop-in solution that avoids days of data preparation. In those cases, a more powerful single-board computer or cloud-assisted rendering will be a better match.
FAQ
What Is The ESP32 Minimap?
The ESP32 minimap is a locally rendered, glanceable navigation display that uses preprocessed map tiles, GPS input, and a runtime tile cache to deliver subsecond updates on an ESP32 P4 and a Waveshare 800×800 display.
How Much Storage Does The Project Require?
For the UK area and zoom level used in this build, the pruned BIN image set occupied about 236 gigabytes on the SD card after conversion and pruning.
How Long Does Tile Conversion And Transfer Take?
Conversion of the pruned tile set took roughly 8 hours, and transferring the converted images to the SD card took about 22 hours for this dataset.
Can I Use OpenStreetMap Instead Of Ordnance Survey?
Yes. The project used both: Ordnance Survey for base geography and OpenStreetMap extracts to fill gaps like petrol station locations. The Python extraction script was used to parse the OSM dump and create point layers.
Does The Minimap Rotate The Map Like A Game?
No. To avoid heavy per-frame pixel work and reduce I/O pressure, the project keeps tiles north-facing and rotates only the vehicle icon. That preserves orientation and vastly improves frame rates.
What Are The Main Constraints To Plan For?
Two constraints dominate: storage scale, which can reach hundreds of gigabytes without pruning, and I/O latency, measured here at about 0.1 seconds per tile read from external storage. Both dictated cache and loading strategies.
Is The Code And Pipeline Available?
Yes. The creator published the Python extraction script, QGIS export notes, and ESP32 rendering code in a public repository for others to use and extend.
Can This Scale To Dense City Environments?
It may, but the article notes uncertainty: city-scale tiling increases tile counts and waypoint churn, which will require hybrid strategies, more aggressive pruning, or different storage choices. The exact approach for large urban areas remains an open engineering question.
COMMENTS