Skip to content

Cornell-GreenClub/pathOS

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

189 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

pathOS: Smarter Routes for a Greener Future

pathOS is a web application designed to quantify and optimize transportation emissions. While standard tools like Google Maps optimize point-to-point routing, pathOS specifically optimizes the order of stops (the Traveling Salesperson Problem) and weight accumulation to minimize fuel consumption and $CO_{2}$ output.

Developed to address the 1.6 million tons of institutional food waste generated by K-12 schools annually, pathOS supports initiatives like Ithaca's Green New Deal by providing reliable data on waste transport emissions.


1. System Overview

The platform is built on a modern, three-tier architecture:

  • Frontend: A responsive Next.js 15 application featuring interactive mapping via Leaflet.
  • Backend: A Flask (Python) REST API housing the Fuel Consumption Model and Simulated Annealing logic.
  • Routing Engine: An OSRM (Open Source Routing Machine) instance hosted on AWS EC2.

2. Technical Infrastructure & Data Flow

The system utilizes a "Wake on Demand" architecture to balance high-performance routing with cost-efficiency.

Route Optimization Pipeline

Route order optimization is a "wicked problem" where the true optimum is often computationally unattainable. pathOS uses a two-step approach to find the most efficient paths:

  • Core Optimization (TSP): The system first solves the Traveling Salesperson Problem using Google OR-Tools to establish a baseline optimal route based on distance.
  • Secondary Optimization (Simulated Annealing): Simulated Annealing is then applied to account for weight accumulation (load changes at each stop). This step refines the core TSP route to minimize the specific impact of vehicle weight on fuel consumption.
  • SA Method: The algorithm accepts random, non-optimal solutions at a "high temperature" and becomes more selective as it "cools." It employs 50% 2-opt (reversing sub-routes) and 50% stop-pair swap methods.

Fuel Consumption Model

The backend predicts fuel usage based on the fundamental physics of motor vehicles:

  • Assumptions: Factors in Drag, Grade, and Friction. Assumes constant speed and only factors uphill climbing into elevation costs.
  • The Prediction Equation: $$Fuel (L) = 0.038 + 0.053(Distance) + 9.56 \times 10^{-5}(Distance \times Weight) + 9.56 \times 10^{-7}(Elevation \times Weight) + 3.45 \times 10^{-9}(Distance \times Speed^{2})$$
  • Validation: Trained on the eVED Dataset (9,500 real-world routes) with an average error of $\pm 150$ mL per trip ($R^{2} = 0.907$).
pathos-graphic

3. Hosting & Infrastructure

Component Provider Strategy
Frontend Vercel Next.js deployment.
Backend Render Flask REST API.
Routing (OSRM) AWS EC2 Wake on Demand: Uses EC2 hibernation to save RAM state to the EBS root volume.

"Wake on Demand" Lifecycle

  1. Wake Phase: A Lambda gateway receives a request and triggers ec2:StartInstances.
  2. Execution: The OSRM engine resumes without re-indexing map data, eliminating idle compute charges.
  3. Sleep Phase: After 10 minutes of inactivity, EventBridge triggers a "Hibernate" Lambda.
  • Result: Slashed monthly AWS costs from ~$60.00 to ~$6.00 (90% reduction).
  • Limitation: Increased cold start latency to ~90 seconds.

4. Impact & Results

  • Route Optimization: Achieved the optimal route for $CO_{2}$ emissions 100% of the time on 10 generated mock routes.
  • Case Study (TST BOCES): Achieved a 3.7% optimization on their original route, projected to save 569 kg of $CO_{2}$ emissions yearly.
  • Overarching Goal: Reduce stakeholder emissions by 10%, saving thousands of tonnes of $CO_{2}$ annually.

5. Next Steps

  • Stakeholder Outreach: Execute the engagement plan to transition from project development to active integration.
  • User-Centric Design: Consult with stakeholders to fine-tune the platform for specific use-cases.
  • Model Refinement: Tailor the optimization model to specific data collected by stakeholders.

6. Extensive Documentation

For deeper dives into the specific systems and models powering pathOS, please refer to the comprehensive guides in the documentation/ folder:

  • Fuel Consumption Model Guide: Details the physics-informed hybrid model, datasets used (eVED & commercial), and instructions for retraining the model for new clients.
  • Simulated Annealing Guide: Explains the algorithmic data flow, matrix construction, and the specific optimization methods used to account for load accumulation.
  • OSRM AWS Deployment Guide: A step-by-step walkthrough of the cost-saving "Wake on Demand" server architecture using AWS EC2, Lambda, and EventBridge.
  • Backend Deployment Guide: Covers the setup and deployment of the Flask Python API and its integration with the frontend and OSRM engine.

7. OSRM Setup

To set up your local OSRM server, follow the official OSRM Backend Guide.

Crucial Configuration for pathOS: When running the final osrm-routed command, you must expose port 5000 to allow the Flask backend to connect.

# Ensure -p 5000:5000 is included
docker run -d -t -i -p 5000:5000 -v "${PWD}:/data" ghcr.io/project-osrm/osrm-backend osrm-routed --algorithm mld /data/your-map-data.osrm

About

pathOS - Cornell Greenclub.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors