4  Capstone Project 3: Fleet Tracking System

capstone
projects

One of three capstone project briefs in this series – along with Capstone Project 1: Smart Environment Monitor and Capstone Project 2: Smart Agriculture System. The shared capstone approach is introduced in Part 1; this part works through the Fleet Tracking System brief, then closes the series with submission guidelines, a project-selection decision framework, and the shared capstone reference material.

The third brief trades pumps and soil probes for location, cellular connectivity, geospatial storage, and movement-aware power management.

4.1 Capstone Project 3: Fleet Tracking System

Project Overview

Domain: Logistics / Asset Tracking

Difficulty: Advanced

Duration: 6-8 weeks

Team Size: 2-3 people

4.1.1 Project Description

Design a GPS-based asset tracking system for vehicles or valuable equipment. The system should provide real-time location tracking, geofence alerts, movement history, and battery-efficient operation for long deployment without charging.

4.1.2 Project Context

Fleet tracking projects show how IoT systems combine location sensing, cellular connectivity, geospatial storage, and operational dashboards. Your system should focus on reliable location updates, safe geofence logic, and power-aware reporting rather than constant high-rate tracking.

4.1.3 Requirements Specification

4.1.3.1 Functional Requirements

ID Requirement Priority
F1 GPS location tracking (< 10m accuracy) Must Have
F2 Cellular connectivity (4G LTE-M/NB-IoT) Must Have
F3 Real-time location on map Must Have
F4 Historical route playback Must Have
F5 Geofence entry/exit alerts Must Have
F6 Speed monitoring and alerts Should Have
F7 Movement/tamper detection Should Have
F8 Battery level monitoring Must Have
F9 Multi-device fleet view Should Have
F10 Trip reports and analytics Could Have

4.1.3.2 Non-Functional Requirements

ID Requirement Target
NF1 Battery life (1 update/hour) > 30 days
NF2 Location accuracy < 5m (clear sky)
NF3 Update latency < 30 seconds
NF4 Device cost < $100
NF5 Monthly connectivity < $5/device

4.1.5 System Architecture

Layer Responsibilities Typical Components
Tracking device Acquire location, detect movement, measure battery state, and transmit compact updates. GPS module, accelerometer, battery monitor, MCU, LTE-M or NB-IoT modem
Cellular network Carry low-rate telemetry from devices to backend services. SIM profile, carrier network, MQTT or HTTPS endpoint
Backend Accept device updates, store spatial history, evaluate geofences, and send alerts. API server, PostGIS database, cache, geofence engine, notification service
Dashboard Show current locations, historical routes, geofence status, and device health. Map interface, fleet list, alert view, trip reports

Data and command flow:

  1. Device wakes based on movement state or scheduled reporting interval.
  2. Firmware obtains a GPS fix, packages location and battery status, and transmits over LTE-M or NB-IoT.
  3. Backend stores the point, checks geofence transitions, and updates the dashboard.
  4. Operators review alerts, routes, and device health from the web interface.

4.1.6 Power Optimization Strategy

// Power states for maximum battery life
enum PowerState {
    DEEP_SLEEP,      // GPS off, cellular off, ~10uA
    LIGHT_SLEEP,     // GPS acquiring, cellular off, ~1mA
    ACTIVE_GPS,      // GPS tracking, cellular off, ~30mA
    ACTIVE_TRANSMIT  // GPS + cellular active, ~150mA
};

// Adaptive reporting based on movement
void adaptiveTracking() {
    if (isMoving()) {
        // Vehicle in motion: frequent updates
        reportIntervalSeconds = 60;
        gpsMode = CONTINUOUS;
    } else if (hasMovedRecently(30)) {
        // Recently stopped: medium updates
        reportIntervalSeconds = 300;
        gpsMode = PERIODIC;
    } else {
        // Parked: infrequent updates
        reportIntervalSeconds = 3600;
        gpsMode = ON_DEMAND;
    }
}

// Estimated battery life calculation
// 3000mAh battery
// Moving 4 hours/day: ~35 days
// Parked most of time: ~90+ days
Knowledge Check: Power Optimization Strategy

4.1.7 Implementation Milestones

4.1.7.1 Week 1-2: GPS & Basic Firmware

4.1.7.2 Week 3-4: Cellular Connectivity

4.1.7.3 Week 5-6: Backend & Storage

4.1.7.4 Week 7-8: Dashboard & Optimization

4.1.8 Geofence Implementation

from shapely.geometry import Point, Polygon

class GeofenceEngine:
    def __init__(self):
        self.geofences = {}
        self.device_states = {}  # Track inside/outside state

    def add_geofence(self, name, coordinates, alert_on):
        """
        coordinates: List of (lat, lon) tuples
        alert_on: 'entry', 'exit', or 'both'
        """
        self.geofences[name] = {
            'polygon': Polygon(coordinates),
            'alert_on': alert_on
        }

    def check_position(self, device_id, lat, lon):
        """Check if device triggers any geofence alerts."""
        point = Point(lon, lat)  # Note: Shapely uses (x, y) = (lon, lat)
        alerts = []

        for name, geofence in self.geofences.items():
            was_inside = self.device_states.get((device_id, name), None)
            is_inside = geofence['polygon'].contains(point)

            if was_inside is not None:
                if not was_inside and is_inside and geofence['alert_on'] in ('entry', 'both'):
                    alerts.append({'type': 'entry', 'geofence': name})
                elif was_inside and not is_inside and geofence['alert_on'] in ('exit', 'both'):
                    alerts.append({'type': 'exit', 'geofence': name})

            self.device_states[(device_id, name)] = is_inside

        return alerts
Knowledge Check: Geofence Implementation

4.1.9 Evaluation Rubric

Criteria Points Description
GPS Accuracy 15 Consistent < 10m accuracy
Cellular Reliability 15 > 99% data delivery
Battery Life 20 Meets 30-day target
Geofencing 15 Accurate entry/exit detection
Dashboard 15 Real-time, historical, usable
Documentation 20 Complete, reproducible
Total 100

SammyCheckpoint: Fleet Tracking

You now know:

  • The must-have path combines GPS location, LTE-M or NB-IoT connectivity, live map state, route history, geofence alerts, battery level, and documentation.
  • The power argument depends on movement state: 1-minute updates while moving, 1-hour updates while parked, and a 3000mAh battery target that exceeds 30 days in the worked estimate.
  • The data argument belongs in PostGIS when the project must run spatial indexes and point-in-area geofence queries instead of only storing timestamped telemetry.

Knowledge Check: Database Selection for Location Data

Once a brief has enough evidence to demo, the remaining work is packaging: make the reviewer able to rerun, repair, and question the system without guessing what the team meant.

4.2 Project Submission Guidelines

4.2.1 Required Deliverables

  1. Technical Report (10-15 pages)
    • Problem statement and requirements
    • Architecture design with diagrams
    • Implementation details
    • Testing results and analysis
    • Lessons learned
  2. Source Code Repository
    • Well-organized, commented code
    • README with setup instructions
    • Dependencies documented
  3. Video Demonstration (5-10 minutes)
    • System overview
    • Live functionality demo
    • Key features walkthrough
  4. Hardware Documentation
    • Bill of materials with costs
    • Wiring diagrams
    • Assembly photos

Before final presentation rehearsal, choose three claims your demo will make and attach one piece of evidence to each claim. Use this minimum table:

Demo claim Evidence to show Risk if evidence is missing
The node meets the sensor requirement. Calibration note, datasheet tolerance, or test log. The audience cannot tell whether readings are accurate or merely displayed.
Data travels end to end. Timestamped sensor-to-dashboard trace. A dashboard screenshot could hide gateway, broker, or storage failures.
The design is maintainable after handoff. Wiring diagram, setup steps, and known-limitations note. The next maintainer may need to reverse-engineer the prototype before fixing it.

If a claim has no evidence, either gather the evidence before the demo or remove the claim from the presentation.

4.2.2 Presentation Format

  • 15-minute presentation + 5 minutes Q&A
  • Cover: problem, solution, demo, results, lessons
  • Be prepared to discuss technical trade-offs
Knowledge Check: Documentation Best Practices
Knowledge Check: Technical Trade-offs
Experience Project Complexity Recommended Capstone Duration
Beginner (first IoT project) Simple Environment Monitor (sensors only, Wi-Fi, cloud dashboard) 4-6 weeks
Intermediate (1-2 prior projects) Moderate Smart Agriculture (sensors + actuators + logic, Wi-Fi/LoRa) 6-8 weeks
Advanced (3+ projects) Complex Fleet Tracking (GPS + cellular + backend + geofencing) 8-12 weeks

Project selection criteria:

Factor Simple Moderate Complex
Hardware complexity Sensors only Sensors + actuators Multiple subsystems
Firmware complexity Basic reading + transmit State machines + control logic Real-time processing + optimization
Connectivity Wi-Fi (familiar) Wi-Fi or LoRa (one protocol) Cellular (LTE-M/NB-IoT) + fallback
Power USB/wall powered Battery with charging Battery optimization critical
Backend Use existing platform Basic custom backend Full-stack with geospatial
Debugging difficulty Serial debug sufficient Occasional field debugging Remote debugging required

Red flags that project is too ambitious:

  • Project requires three or more technologies the team has never used.
  • Budget is more than $200 per team member.
  • Timeline is compressed below four weeks for a moderate-complexity system.
  • Core hardware has no reliable examples, documentation, or backup option.
  • No fallback plan exists if the primary approach fails.

Key insight: Choose a project that challenges you without overwhelming the team. One new major technology per project is enough; if LoRa is new, avoid also learning cellular, GPS, and solar in the same build.

Common Mistake: Scope Creep Kills Capstone Projects

The Mistake: Team starts with “Environment Monitor” (4-week project). Week 2: “Let’s add actuators!” Week 4: “What about solar power?” Week 6: “Should we use LoRa instead of Wi-Fi?” Week 8: Project incomplete, demo is half-working prototype.

Why It Happens:

  • “Wouldn’t it be cool if…” feature additions
  • Underestimating integration time
  • No explicit scope definition and freeze date
  • Fear of “simple” project seeming unimpressive

Real example timeline:

Week 0: Scope Defined
+-- Environment Monitor: Temp, humidity, CO2 -> Cloud dashboard

Week 2: Feature Creep Begins
+-- "Let's add PM2.5 sensor!" (+1 week integration time)

Week 4: More Features
+-- "What about automated alerts?" (+1 week backend work)

Week 6: Major Change
+-- "LoRa would be cooler than Wi-Fi!" (+2 weeks learning + debugging)

Week 8: Crisis
+-- Original features: 80% complete
+-- Added features: 30% complete
+-- Integration: buggy
+-- Demo: disappointing half-working system

The Fix: Scope Freeze Contract:

SCOPE FREEZE (signed Week 0):

MUST-HAVE (required for completion):
+-- [ ] Temperature sensor (BME280)
+-- [ ] Humidity sensor (BME280)
+-- [ ] CO2 sensor (MH-Z19B)
+-- [ ] Wi-Fi connectivity
+-- [ ] MQTT to cloud
+-- [ ] Grafana dashboard

NICE-TO-HAVE (only if ahead of schedule):
+-- [ ] PM2.5 sensor
+-- [ ] Alert system
+-- [ ] Mobile app

OUT-OF-SCOPE (explicitly excluded):
+-- Solar power
+-- LoRa connectivity
+-- Machine learning
+-- Multi-room support

FREEZE DATE: End of Week 2
After this date, NO changes to MUST-HAVE list.

Enforcement strategy:

  1. Week 0: Define MUST-HAVE features and timeline
  2. Week 2: FREEZE scope (no changes to MUST-HAVE)
  3. Week 4-6: Implement MUST-HAVE features ONLY
  4. Week 7: If ahead of schedule, add ONE NICE-TO-HAVE
  5. Week 8: Polish, documentation, demo prep (no new features)

Key insight: Impressive demos come from polished execution of focused scope, not sprawling half-finished features. A simple project executed excellently beats a complex project executed poorly. Define must-have and nice-to-have work in week 0, freeze scope in week 2, and resist feature additions after the freeze.

Capstones integrate the entire IoT stack: Each project combines sensors (Module 2), networking (Module 3), cloud (Module 5), and design methodology (Module 9).

Project complexity scales with experience:

  • Beginner: sensors to cloud over Wi-Fi with a simple dashboard
  • Intermediate: sensors to actuators to control logic for automation or multi-zone systems
  • Advanced: GPS or cellular data to backend geospatial services

Budget constraints force architecture decisions: A $120 budget might eliminate LoRa and solar in the first version, pushing the team toward Wi-Fi, USB charging, and a stricter must-have feature list.

Related concepts:

  • Power optimization from the Energy and Power module is essential for solar and battery projects.
  • Protocol selection from networking modules helps compare MQTT, LoRa, and cellular trade-offs.
  • Testing strategies from Testing and Validation define the verification evidence required by the rubric.

Within this module:

Other modules:

External resources:

Interactive Quiz: Match Capstone Project Concepts

Interactive Quiz: Sequence the Steps

Common Pitfalls

Ordering components and soldering connections before writing requirements leads to scope creep: features are added as interesting capabilities are discovered, timelines slip, and the project never reaches a coherent complete state. Define acceptance criteria, create a BOM, and get requirements approved before purchasing a single component.

A sensor that works correctly on a breadboard, a gateway that processes MQTT messages correctly in unit tests, and a cloud API that responds correctly in Postman can all fail when combined – due to timing, QoS settings, or JSON schema mismatches. Schedule 30-40% of the project timeline for integration testing.

IoT projects in the field experience sensor failures, damaged cables, and MCU resets. Design your system to continue operating (degraded mode) when individual sensors fail. Document which failures are recoverable (restart, swap sensor) versus which require full system restart. Capstone projects that depend on every component working perfectly fail during live demonstrations.

Label the Diagram

Code Challenge

4.3 What’s Next

If you want to… Read this
Look up technical terms encountered during project work IoT Glossary A-F
Review mathematical foundations for sensor calculations Mathematical Foundations
Apply visual style standards to project diagrams and documentation Reference Appendix
Access reference templates and supplementary materials Appendix
Revisit data storage architectures for your project’s backend Data Storage and Databases

4.5 Summary

Capstone projects bring the course together by asking students to define a real IoT problem, select sensors and actuators, design connectivity, handle data, secure the system, and evaluate whether the result meets user and operational requirements.

4.6 Key Takeaway

A strong capstone is judged by the complete system argument: problem, stakeholders, architecture, data flow, security, validation, and trade-offs. The prototype matters, but the engineering justification matters just as much.

This closes the three-part capstone series. Return to Capstone Project 1: Smart Environment Monitor or Capstone Project 2: Smart Agriculture System for the other two briefs.