Chapters

3 Capstone Projects: Selection and Fleet Tracking

capstone
projects

3.1 Start With the Decision

A student can buy every sensor and still have no project that can be reviewed. The smallest useful claim, evidence table, and integration test must come before assembly.

3.2 Route Overview

This is part 2 of 3. Review Capstone Projects: Planning and Evidence for the preceding evidence.

3.3 Learning Objectives

  • Select a capstone scope from skill, evidence, and integration risk.
  • Build a claim-to-evidence table and a fleet-tracking test plan.

3.4 Chapter Roadmap

  • For Beginners: Capstone Projects
  • Prerequisites
  • Knowledge Check: Project Planning Priorities
  • Choose Your Project
  • Project Submission Guidelines
  • Try It: Build a Claim-to-Evidence Table
  • Knowledge Check: Documentation Best Practices
  • Knowledge Check: Technical Trade-offs
  • Decision Framework: Capstone Project Selection by Experience Level
  • Common Mistake: Scope Creep Kills Capstone Projects
  • Concept Relationships
  • See Also
  • Interactive Quiz: Match Capstone Project Concepts
  • Interactive Quiz: Sequence the Steps
  • Common Pitfalls
  • 1. Starting hardware assembly before defining requirements
  • 2. Testing components in isolation instead of integrated
  • 3. Not planning for hardware failure and component replacement
  • Label the Diagram
  • Code Challenge
  • Capstone Project 3: Fleet Tracking System

3.5 For Beginners: Capstone Projects

Capstone projects bring together everything you have learned to build a complete, working IoT system. Start with a small reliable version, then add complexity only when the core sensor-to-dashboard path works end to end.

3.6 Prerequisites

Before starting a capstone project, you should have completed:

  • Sensor Fundamentals and at least one sensor lab
  • Networking Fundamentals including MQTT or similar protocol
  • Cloud Computing basics or edge computing concepts
  • Security Fundamentals including device authentication
  • Basic programming skills (Python, C/C++, or JavaScript)
Knowledge Check: Project Planning Priorities

3.7 Choose Your Project

Each brief below is a complete, independent project — pick the one that matches your experience level and interests, then open its page for the full requirements, hardware list, architecture, milestones, and rubric. All three share the reviewable-claim approach above.

↔ Scroll the project comparison horizontally to review every selection criterion.

ProjectDomainDifficultyDurationChoose this if…
Capstone Project 1: Smart Environment MonitorEnvironmental Monitoring / Smart BuildingIntermediate4-6 weeksThis is your first IoT capstone and you want a contained sensor-to-dashboard build (Wi-Fi, MQTT, cloud storage, alerts).
Capstone Project 2: Smart Agriculture SystemPrecision Agriculture / Smart FarmingAdvanced6-8 weeksYou have shipped 1-2 prior projects and want to add safe actuation (soil sensing, automated watering, solar power sizing).
Capstone Project 3: Fleet Tracking SystemLogistics / Asset TrackingAdvanced6-8 weeksYou want the most complex build: GPS, cellular connectivity, geofencing, and a spatial (PostGIS) backend.

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.

3.8 Project Submission Guidelines

3.8.1 Required Deliverables

Step 1 — Technical Report (10-15 pages) Problem statement and requirements Architecture design with diagrams Implementation details Testing results and analysis Lessons learned

Step 2 — Source Code Repository Well-organized, commented code README with setup instructions Dependencies documented

Step 3 — Video Demonstration (5-10 minutes) System overview Live functionality demo Key features walkthrough

Step 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 claimEvidence to showRisk 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.

3.8.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

ExperienceProject ComplexityRecommended CapstoneDuration
Beginner (first IoT project)SimpleEnvironment Monitor (sensors only, Wi-Fi, cloud dashboard)4-6 weeks
Intermediate (1-2 prior projects)ModerateSmart Agriculture (sensors + actuators + logic, Wi-Fi/LoRa)6-8 weeks
Advanced (3+ projects)ComplexFleet Tracking (GPS + cellular + backend + geofencing)8-12 weeks

Project selection criteria:

FactorSimpleModerateComplex
Hardware complexitySensors onlySensors + actuatorsMultiple subsystems
Firmware complexityBasic reading + transmitState machines + control logicReal-time processing + optimization
ConnectivityWi-Fi (familiar)Wi-Fi or LoRa (one protocol)Cellular (LTE-M/NB-IoT) + fallback
PowerUSB/wall poweredBattery with chargingBattery optimization critical
BackendUse existing platformBasic custom backendFull-stack with geospatial
Debugging difficultySerial debug sufficientOccasional field debuggingRemote 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:

Design Thinking - Planning methodology Prototyping Hardware - Building techniques End-to-End Test Strategy - Verification strategies

Other modules:

Sensors & Measurement - Sensor selection for projects MQTT Protocol - Messaging for capstones Power Management - Battery optimization

External resources:

Hackster.io - IoT project showcase and tutorials GitHub IoT Topics - Open-source IoT projects Arduino Project Hub - Hardware projects

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

3.9 Capstone Project 3: Fleet Tracking System

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 on the Capstone Projects hub, which also has the submission guidelines and the project-selection decision framework; this part works through the Fleet Tracking System brief.

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

3.9.1 Capstone Project 3: Fleet Tracking System

Prove One Asset Story From Fix to Decision

Picture a tracker that appears to leave a depot while it is actually indoors with a stale position. A moving dot alone cannot support an investigation.

Telemetry means measurements and status sent from a device for review elsewhere. Bind each location to device identity, source time, arrival time, accuracy, power state, and confidence.

Test stationary, moving, blocked, delayed, duplicate, and missing cases. Keep the route, raw fix, telemetry, map state, alert, operator choice, and outcome so another team can replay the trip.

This test covers one fleet route and set of conditions, not every location error. The deeper project adds architecture, power, storage, alerts, privacy, and release evidence.

Project Overview

Domain: Logistics / Asset Tracking

Difficulty: Advanced

Duration: 6-8 weeks

Team Size: 2-3 people

3.9.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.

3.9.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.

3.9.1.3 Requirements Specification

3.9.1.3.1 Functional Requirements
IDRequirementPriority
F1GPS location tracking (< 10m accuracy)Must Have
F2Cellular connectivity (4G LTE-M/NB-IoT)Must Have
F3Real-time location on mapMust Have
F4Historical route playbackMust Have
F5Geofence entry/exit alertsMust Have
F6Speed monitoring and alertsShould Have
F7Movement/tamper detectionShould Have
F8Battery level monitoringMust Have
F9Multi-device fleet viewShould Have
F10Trip reports and analyticsCould Have
3.9.1.3.2 Non-Functional Requirements
IDRequirementTarget
NF1Battery life (1 update/hour)> 30 days
NF2Location accuracy< 5m (clear sky)
NF3Update latency< 30 seconds
NF4Device cost< $100
NF5Monthly connectivity< $5/device

Knowledge Check: Cellular Technology Selection

3.9.1.5 System Architecture

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

Data and command flow:

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

3.9.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

3.9.1.7 Implementation Milestones

3.9.1.7.1 Week 1-2: GPS & Basic Firmware
  • GPS module integration and testing
  • NMEA parsing and position extraction
  • Accelerometer for movement detection
  • Serial debugging and validation
3.9.1.7.2 Week 3-4: Cellular Connectivity
  • LTE-M/NB-IoT module configuration
  • MQTT or HTTP data transmission
  • Connection reliability handling
  • SIM card provisioning
3.9.1.7.3 Week 5-6: Backend & Storage
  • API server for receiving data
  • PostGIS database for location history
  • Geofence calculations
  • Alert notification system
3.9.1.7.4 Week 7-8: Dashboard & Optimization
  • Map-based web dashboard
  • Route playback feature
  • Power optimization
  • Enclosure and field testing

3.9.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

3.9.1.9 Evaluation Rubric

Read the rubric as one end-to-end tracking claim. GPS accuracy and cellular delivery establish trustworthy observations, battery life determines how long that evidence can be collected, geofencing and dashboards turn it into operational decisions, and documentation makes every result reproducible. A strong score therefore depends on the connections between criteria, not isolated demonstrations.

CriteriaPointsDescription
GPS Accuracy15Consistent < 10m accuracy
Cellular Reliability15> 99% data delivery
Battery Life20Meets 30-day target
Geofencing15Accurate entry/exit detection
Dashboard15Real-time, historical, usable
Documentation20Complete, reproducible
Total100

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. Each stage must preserve the same vehicle identity and timestamp contract.

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. A measured trace must validate that 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. The query evidence completes the tracking claim.

Knowledge Check: Database Selection for Location Data

3.9.2 Within This Series

DirectionChapterTopic
PreviousCapstone Project 2: Smart Agriculture SystemSoil sensing and automated watering
CurrentCapstone Project 3: Fleet Tracking SystemGPS, cellular, and geofencing

This closes the three-part capstone series. For submission guidelines, the project-selection decision framework, and shared reference material, return to the Capstone Projects hub — or revisit Capstone Project 1: Smart Environment Monitor and Capstone Project 2: Smart Agriculture System.

3.10 Continue to the Next Part

Carry this evidence into Capstone Projects: Agriculture and Environment, which begins with Capstone Project 2: Smart Agriculture System.