merzbuilds

Selected work / 02

Agila Fleet Manager

Fleet management and facial-recognition attendance, built as one academic engineering project.

StatusAcademic research prototype · not deployed

Repository
Official Agila Smart Fleet Attendance logo
Official project identity

01 / Context

The problem and the people

Agila connects an Android driver app, a Fleet Manager dashboard and a FastAPI service. The same project includes my facial-recognition/GPS attendance thesis and MerLens V2 model development.

Driver attendance needs operational context: who is checking in, which delivery they are assigned to, and whether they are within the configured location. Agila explores that workflow when connectivity is intermittent.

Intended users
Fleet managers assigning deliveries and drivers recording attendance through the Android application.

02 / Contribution

My role in the work

Main developer · facial-recognition model training

  • I was responsible for the majority of Agila’s development work, including facial-recognition model training. The fleet system and attendance thesis are one unified project.
  • Agila is a team academic project. My leading development role does not imply sole authorship of every contribution.

Built and documented

What the system does

  1. Driver & fleet workflow

    The dashboard manages drivers, deliveries, attendance and audit events. Drivers activate an account, retrieve assigned deliveries and record attendance through the Android app.

  2. Attendance on the device

    YuNet detects and aligns faces; MerLens V2 generates 128-dimensional embeddings for local cosine comparison. A separate MediaPipe-assisted workflow checks head turns and a randomized color response for attendance.

  3. Offline capture, accountable synchronization

    Face, liveness and GPS checks precede an encrypted local attendance queue. When connectivity returns, records sync with attempt identifiers. The server checks identity, assignment, time and distance against the configured attendance radius.

System map / 03

How the pieces connect

  1. Android driver app

    Flutter / Kotlin · capture, local inference, GPS and encrypted queue

  2. API & dashboard

    FastAPI / HTML, CSS, JavaScript · fleet workflow and validation

  3. Persistence

    SQLAlchemy / PostgreSQL · attendance, assignments and audit records

Implementation

Technology used

  • Flutter
  • Dart
  • Kotlin
  • Python
  • FastAPI
  • SQLAlchemy
  • PostgreSQL
  • Supabase PostgreSQL
  • PyTorch
  • ONNX Runtime
  • OpenCV YuNet
  • MediaPipe
  • JavaScript
  • Leaflet
  • Docker

Engineering judgment

Decisions and trade-offs

  1. Separate device inference from server validation

    Native Android code runs ONNX inference and the Flutter app owns capture and queuing. FastAPI independently validates operational fields before persistence, but it records the device’s biometric decision rather than rerunning facial inference.

  2. A compact embedding CNN

    MerLens V2 uses a project-authored topology built from dual depthwise-convolution branches, channel gating, residual paths and normalization. It takes aligned 224 × 224 RGB input and produces a normalized 128-dimensional embedding.

  3. Train, evaluate, export as separate stages

    The deterministic identity curriculum expands from 256 to 2,048, 8,192, 32,768 and 92,329 DigiFace identities, preserving earlier class centers. ArcFace is a training-only head; inference-only ONNX export is checked for parity separately from recognition evaluation.

Documented results

Results

  • Implemented source covers the fleet dashboard, Android attendance workflow, backend validation, model training, verification and ONNX export. The public repository includes the final inference model; Agila is not currently deployed.
  • Repository-recorded internal synthetic validation reports 98.42% accuracy; external LFW evaluation at the unchanged threshold reports 73.10% accuracy, 35.20% false acceptance and 18.60% false rejection. These are research results, not production reliability claims. All 6,000 pairs are included, with preprocessing failures treated as rejection.

Project boundaries

Limitations

  • MerLens V2 was trained on DigiFace-1M under Microsoft’s Research Use of Data Agreement. Use of the data or resulting model in a commercial offering is prohibited; this is a non-commercial research prototype.
  • The synthetic-to-real evaluation gap is material. The Android-only prototype is not a certified biometric or anti-spoofing product; broader device/lighting calibration, participant usability studies and formal attack testing remain incomplete.
  • GPS is affected by device conditions and spoofing. The server does not independently repeat biometric inference. YuNet, MediaPipe and diagnostic runtime assets require separate acquisition; further field validation, privacy/legal review and operational safeguards are needed before production use.

Evidence trail

Project references