Project AURORA V1 Prototype Completed

[Madacool01]

I’ve hit a major milestone for Project AURORA! Instead of testing on flaky real-world hardware early on, I’ve built a working, desktop-bound prototype using a Simulation-First Philosophy. This allowed me to fully verify the video pipeline, navigation state machine, and OpenCV overlay engine before moving to real hardware.

System Architecture

To keep the codebase clean, I split the project into specific dedicated components:

• navigation/engine.py: Tracks route progress and runs the Haversine calculations (see The Haversine Formula for AURORA #11 for more details).

• navigation/telemetry.py: Streams pre-recorded timestamped GPS logs.

• video/player.py: Handles video frames, runs the core app clock, and updates the UI.

• overlay/renderer.py: Draws the AR HUD and navigation arrows.

• main.py: The centralised orchestrator and loop ticker that integrates all the components above into the working prototype.

Solving the Simulation Desync Problem

During integration, I ran into an interesting challenge: a massive time scale conflict.

Our Kivy graphics engine ticks at 30 Frames Per Second to keep video playback smooth, but the telemetry log represents real-world driving recorded at 1 Hz (one coordinate per second). Initially, the loop popped a new GPS row on every single frame, burning through a 14-second trip in just 200 milliseconds!

To fix this, I implemented a Time Accumulator Pattern to decouple the layers:

self.time_accumulator += dt

# Only step the telemetry timeline forward when 2.0 full seconds passes
if self.time_accumulator >= 2.0:
    next_tick = self.telemetry_player.pop_telemetry()
    if next_tick:
        self.current_gps_tick = next_tick
    self.time_accumulator -= 2.0

Now, the video streams perfectly at 30 FPS while the telemetry, HUD metrics, and AR arrows update naturally every 1.0 second.