← Back to project catalogue
GP-MA-16W9NUCMathematicsOpen for request

Multi-objective last-mile routing laboratory

An optimisation laboratory for comparing last-mile delivery routes across distance, time, cost, emissions, service quality, and workload-balance objectives.

  • Nuxt
  • Vue
  • FastAPI
  • PostgreSQL
  • PostGIS
  • Python
  • OR-Tools
  • NetworkX
  • Docker

Project definition

Problem statement

A route that minimises total distance may create late deliveries, overloaded vehicles, uneven driver workloads, or additional emissions under congestion and vehicle differences.

The mathematical problem is to formulate competing objectives and operational constraints, generate valid solutions, and show the Pareto tradeoffs rather than hiding them inside one unexplained score.

Project objectives

  • Model a selected road graph, depots, orders, vehicles, capacities, service times, time windows, and working limits.
  • Formulate distance, travel time, operating cost, emissions proxy, lateness, and workload-balance objectives.
  • Implement baseline, exact or bounded, constructive, local-search, and selected metaheuristic methods.
  • Generate and compare Pareto-efficient solutions under fixed computational budgets.
  • Test sensitivity to demand, traffic, failed delivery, vehicle, and objective-weight scenarios.

System design

System modules

01

Problem builder

Defines graph, depots, customers, demand, vehicles, constraints, service rules, and objective functions.

02

Distance and time engine

Creates valid route matrices from prepared networks and time-dependent travel assumptions.

03

Solver workbench

Runs baseline, OR-Tools, exact small-instance, and selected heuristic methods with recorded seeds and budgets.

04

Pareto analyser

Identifies non-dominated solutions and measures objective spread, dominance, and tradeoff changes.

05

Routing dashboard

Shows routes, loads, schedules, violations, convergence, Pareto fronts, and scenario comparisons.

Methodology

System workflow

  1. 01
    Load instance

    The student selects a prepared city network, orders, fleet, service constraints, and objective definitions.

  2. 02
    Verify data

    Reachability, units, capacities, time windows, and basic feasibility bounds are checked.

  3. 03
    Run methods

    Solvers process the same instance under fixed time, iteration, and seed budgets.

  4. 04
    Compare tradeoffs

    Valid solutions are evaluated against every objective and displayed on the Pareto front.

  5. 05
    Stress test

    Traffic, demand, vehicle loss, failed delivery, or objective preferences are varied and rerun.

Demonstration scenario

A prepared Bengaluru delivery instance uses two vehicle types, capacities, time windows, and shift limits. One solution minimises distance but creates late stops, while another reduces lateness and balances workload at additional cost. The Pareto view makes the tradeoff explicit and reruns it under peak traffic.

Engineering

Technical architecture

Web application
Nuxt and Vue for problem setup, route maps, schedules, convergence, Pareto plots, and export.
Optimisation API
FastAPI for instances, matrix jobs, solver runs, constraint checks, scenarios, and results.
Spatial data layer
PostgreSQL and PostGIS for prepared graphs, locations, instances, routes, schedules, and metrics.
Algorithm engine
Python, OR-Tools, and NetworkX for routing baselines, constraints, search, and graph operations.
Experiment design
Versioned instances, solver budgets, random seeds, feasibility checks, lower bounds, and repeated runs.

Testing

Evaluation

Evaluation measures

  • Constraint satisfaction and independent route-feasibility checks
  • Objective values against manually calculated and exact small instances
  • Optimality gap or lower-bound gap where available
  • Pareto-front quality, diversity, and dominance across methods
  • Runtime, convergence, success rate, and result variability
  • Sensitivity to traffic, order demand, fleet, time windows, and objective preferences

System boundaries

  • The project uses prepared or permitted map and delivery data and does not expose customer information.
  • Travel time, cost, emissions, and service behaviour use documented planning assumptions.
  • The optimiser supports research and does not dispatch real vehicles or drivers.
  • Operational deployment requires live-data validation, labour and safety rules, local restrictions, and human oversight.

Included

  1. 01Depot, vehicle, order, network, and objective interface
  2. 02Routing, constraint, Pareto, and scenario modules
  3. 03Route maps, objective tradeoffs, convergence, and comparison views
  4. 04Prepared Indian urban delivery instances, baselines, and results
  5. 05Complete source code in a private GitHub repository
  6. 06Complete project documentation with synopsis, abstract, methodology, mathematical formulation, algorithm results, screenshots, and conclusion
  7. 07Setup and usage guide

Project record

No buyer information is collected on this page.

Permanent project ID
GP-MA-16W9NUC
Catalogued
21 Aug 2026
Completed
Pending
Verified
Pending
Demonstration
Added when ready

Handover

After purchase

  1. 01
    Payment is confirmed

    The project is marked unavailable and cannot be purchased again.

  2. 02
    Repository access is granted

    The buyer's submitted GitHub account receives access to the private repository.

  3. 03
    The purchase record is delivered

    The certification sheet is prepared from the reviewed buyer details and sent privately by email.