Published using Google Docs
Federated Learning for Adaptive Road Efficiency Project Log
Updated automatically every 5 minutes

March 3rd Shenanigans

To Do list:

(1)

Some thoughts on network architectures for traffic intersections

Given the fact that traffic lights are in a fixed position, we can probably leverage the spatial locality of CANs to manage updates and state information efficiently.

Some research on CAN locality property: Each node is only aware of its neighbours

Pivot to a more layered architecture?

(2)

Now that I have OMNeT++ setup and running on my computer, need a new TO DO

TO DO:

Objectives/Requirements

March 4th Shenanigans

What I would like to do today:

What we need:

Traffic simulators: Simulation of Urban Mobility (SUMO) through Traffic Control Interface (TraCI)

Trying to get SUMO, TraCI and Veins into the project. Veins builds with the project so that works for now (using this doc)

While waiting for SUMO to build, I renamed my project:

Federated Learning for Adaptive Road Efficiency (FLARE)

March 5-8th Shenanigans

No huge updates. Having troubles integrating SUMO into the project.

Reading paper for RS4: Federated Learning through model gossiping in wireless sensor networks

March 11th Shenanigans

Thinking about the mathematics behind determining optimisation through matrices of intersections

1. Can We Find a Standard Matrix for Traffic Flow?

Yes! If we model the inflow and outflow of vehicles at an intersection (or multiple intersections) as a linear system, then we can absolutely find its standard matrix.

2. Why Would This Work?

Traffic flow (in its simplest form) is based on conservation of vehicles—cars don’t just vanish or appear out of nowhere. This is very similar to conservation of mass in physics, which is often modeled linearly.

Each intersection can be treated as a node, and the streets connected to it define the edges (like a directed graph). The number of cars entering and leaving must balance according to:

Total Inflow=Total Outflow

If the relationship between in-flow and out-flow is linear, we can describe the entire system as:

Ax=b where:

3. What Would the Standard Matrix Represent?

The columns of the standard matrix would represent how each individual inflow affects the system.

For a single intersection, we could construct a standard matrix that transforms incoming traffic flows into outgoing traffic flows.

For multiple intersections, we'd get a larger system of equations, and the matrix would describe how traffic from one intersection influences others—kind of like a networked transformation!

March 18th Shenanigans

What we’re working on today:

Issues with the data found for the traffic of city of victoria

What I currently have:

  1. Traffic Volume (Label field) – I have 24-hour vehicle counts, e.g., "450(92)" means 450 vehicles were counted in 1992.
  2. Direction field – It tells you if the traffic was counted in both directions (bi-directional).
  3. SHAPE_Length – Likely the length of the line segment where the count was taken (could be street segments).
  4. Year – The year of the data point.
  5. No explicit intersection information – The data appears linear (road segments), not node-based (no junction/intersection node IDs or coordinates provided).

Why inflow-outflow models are tricky here:

For inflow-outflow systems (aka traffic balance at intersections), you need:

Problems with the data:

  1. No explicit intersection/node data: Without knowing which lines meet at which intersections, you can’t fully close the system.
  2. No split of direction-specific volumes: the "Direction" = "both" means total two-way counts, but you don’t know how much is inbound vs outbound on each segment.
  3. 24-hour aggregate: These are daily totals, not time-of-day (morning peak, afternoon peak, etc.), so inflows/outflows may vary heavily depending on time.

What I could potentially do:

What’s missing to fully model:

HOLD ON TEAM, THEY HAVE A GEOjson.

Now that we have this we can:

1. Map it all in QGIS:

2. Create symbology based on counts or year:

3. Create an interactive map (e.g., Leaflet or Mapbox):

4. Create inflow-outflow system of equations

For each node (intersection), apply:

Inflow−Outflow=Δ

If we assume steady-state (traffic isn't "piling up" at intersections), set Δ=0 (in = out).

March 20th Shenanigans

Transferring project over to windows computer

$ split -d -a 3 -b 625m openstreetmap.zip openstreetmap.part

TODO:

Omg massive breakthrough here:

  1. With sumo installation, there’s a python script that you can run in the tools folder (..\Eclipse\Sumo\tools)

$ python osmWebWizard.py

  1. Find location you want to generate a simulation of
  1. here , I wanted Victoria so I found the coordinates of Victoria
  2. Generate
  3. It’ll open the simulation in SUMO for you
  1. You can edit the simulation: Edit > Open sumo config in netedit (or Ctrl + T)

Here are the videos of the traffic simulation of downtown Victoria that I’ve managed to get running.

Now that I have this up and running, I want to pick a specific set of intersections, and draw out a diagram of how the traffic control sensors communicate with others.

I’m also thinking with how much I’ve figured out with SUMO, it might be difficult to create an architecture of learners, but we’ll see. I need to figure out how to import into omnetpp and go from there.

March 21st Shenanigans:

As promised, I wanted to draw out a diagram of my thought process for the architecture. Which oddly turned out to represent more of a hierarchical but partially meshed network topology with local cliques and inter-clique connections.

Fig 1

Here's a breakdown of the diagram:

Inside each "circle" (A, B, C, D):

Between the "circles":

Visually:

TL;DR:

Aligning it to Gossip-Based FL:

In a gossip-based FL setting, we want:

  1. Decentralized model sharing: models don’t only travel "up" to a central aggregator but also horizontally and diagonally across peers.
  2. Multi-hop flexibility: if direct neighbors are busy or down, nodes can still communicate via alternative paths, which you’re engineering with this mesh.

Thoughts for further evolution:

This is what I’m gonna do: Build an FL network from scratch in OMNeT++ as a standalone proof of concept before integrating SUMO via TraCI. By first focusing on the FL network, I'll be able to concentrate on understanding the key components, algorithms, and communication dynamics of gossip-based federated learning in isolation. Once I have the core FL functionality working in OMNeT++, I can then integrate the mobility model from SUMO to enhance the simulation with realistic movement patterns and flow of traffic.

Example of what gossip protocol would look like:

// Simple example of gossip message handling
class GossipNode : public cSimpleModule {
protected:
   virtual void initialize() override;
   virtual void handleMessage(cMessage *msg) override;
private:
   void startGossipRound();
};

void GossipNode::initialize() {
   // Initialize node with model parameters
   scheduleAt(simTime() + 1.0, new cMessage("startGossip"));
}

void GossipNode::handleMessage(cMessage *msg) {
   if (strcmp(msg->getName(), "startGossip") == 0) {
       // Start a gossip round, send updates to neighbors
       startGossipRound();
   }
}

void GossipNode::startGossipRound() {
   // Create gossip messages and send them to neighbors
   for (int i = 0; i < numNeighbours(); i++) {
       send(createGossipMessage(), "out");
   }
}

March 25th Shenanigans

GeoJSON is a data format for representing geographic objects and their attributes. It is used to store and exchange geodata such as points, lines and polygons, as well as their associated attributes such as name, description, address, etc. If you want more technical and official explanations, visit the GeoJSON format page. [6]

Began building a linear regression ML model to train on the GeoJSON file. Had to convert to CSV such that I can build with pandas dataframe. Once converted to csv and turned into data frame, did the following:

print(df.isnull().sum())

This printed out the following info:
printed the following:

OBJECTID 0

Traffic_Volume 1

Direction 1

Segment_Length 0

Year 15

 Start_Coordinates 0

End_Coordinates 0

dtype: int64

Oddly, there were 15 years that weren’t included in the data, so I simply removed any line that didn’t contain a year. Not worth the trouble. For traffic_volume, I simply replaced the one missing value with the median of all traffic_volumes, that’s probably okay. And for direction, I just opted to add the most frequent value (which is ‘both’ - two way street).

I tested and trained the model. The results are the following:

Mean Squared Error: 4.233521005310553

R-squared: 0.0028718122151949466

0.7 or higher: Generally considered a good fit, meaning that the model explains a significant portion of the variability in the target variable. 0.5 to 0.7: Indicates moderate explanatory power.

Below 0.5: Poor fit. The model doesn’t explain much of the variance in the data. And we have 0.003. So we’re cooked chat.

The ideal MSE is 0, meaning no error at all. In practice, good MSE values depend on the scale of the target variable. We have a FOUR. my lord. We might as well have a monkey sitting in the intersection deciding on when to change the light.

If linear regression doesn't perform well, we can experiment with more complex models like Decision Trees or Random Forest.

Am attempting a decision tree model tomorrow.

March 26th Shenanigans

Attempted decision tree and got the following:
Decision Tree Mean Squared Error: 4.207823254050241

Decision Tree R-squared: 0.008924445971398631

This sucks. Though I had max_depth=5 so now I’m gonna try max_depth=None

Decision Tree Mean Squared Error: 4.466740230712524

Decision Tree R-squared: -0.05205869676065089

Lol dude.

Data might be overfitting with the none so I’m gonna fix some things. The features: Segment_Length, Distance, and Direction might actually have no real relationship with Traffic_Volume.

It would be optimal to have time of day, or even day part of this training set because I would have that data in a real-life scenario. It’s a difficult set to use. I’m gonna drop a couple features that aren’t really useful in predicting traffic volume. Like direction and distance between intersections aren’t huge game changers. As opposed to year, which is really helpful because obviously the amount of traffic scales each year. If there is a clear trend with the year feature, it  might be good to focus on predicting yearly trends instead of short-term fluctuations (even though preferably, it is these short term fluctuations I want to prioritise later in the simulation).

If you wanna see something interesting, this is the diagram of the traffic trends from 1980 to just over 2020. The average traffic volume has significantly DECREASED. Which is insanity.

Okay, this idea obviously isn’t working and this model is learning how to predict traffic volume on some year, which is not really in the scope of this project. I’m going to attempt to find more specific data sets for traffic here.

Since traffic has decreased over time in the data, what external factors could explain this? This is truly staggering information. It makes me wonder if I plotted this correctly. I’m gonna do the following to test this:
Line plot of traffic volume over time.

Rolling average plot to smooth fluctuations.

Box plots to analyze traffic volume distributions by decade.

Correlation heatmap to check relationships with other features

This distribution is truly disgusting. No wonder my models don’t know what to do.

I might have an idea here. Since I already have SUMO and TraCI set up, I could simply collect simulated traffic data from intersections using TraCI and then use that for modeling. Since I’ve already utilised the OSM Web Wizard to generate a detailed traffic simulation scenario based on OpenStreetMap data, I can install the TraCI Python library to establish a communication link between our simulation and external control scripts.​ I’m going to write a Python script employing TraCI to connect to the running SUMO simulation, collect vehicle count data at specified intersections, and manage simulation steps programmatically.

April 6th Shenanigans

(Also including some undocumented, sporadic shenanigans from after March 26th)

What happened today? I’ve finally managed to successfully build out the diagram from March 21st Shenanigans (Fig 1).

Here is simulation: https://youtu.be/tFbmnrT2hEk

What needs to happen now:

  1. Each node (GossipNode) will:

TODO:

Integrated nodes to host ‘modelWeights’

For analysing the data, I need to think about what attributes I specifically want to look at:

What I’m doing now:

Integrating Weight Gossiping

Added an array of weights to more appropriately simulate a learning model on the modes (different params represent diff attributes of a model)

Simulation runs well.

Now that the simulation is running smoothly and we’ve got model updates and weight sharing working, here are some directions on what I could explore next:

1. Aggregation Mechanism (Federated Averaging)

Time to add performance metrics to the project (the whole reason we’re here)
How well is the model performing and how efficiently is the federated learning network operating?

Implementing Convergence Rate (track this by comparing the change in the model's weights across time)

Okay perfect. Here’s a summary of what happened today:
1. Simulated Gossip-based Federated Learning (FL) Setup

2. Message Handling and Forwarding

3. Model Weight Evaluation

4. Error Handling and Debugging

5. Tracking Operations for Simulation Complexity

6. Makefile and Compilation Issues

Okay, what we gotta do now:

// Dummy accuracy evaluator function (replace with actual logic)

double GossipNode::evaluateModel(const std::vector<double>& modelWeights) {

   // Simulated accuracy value (can be replaced with actual evaluation logic)

   return 0.85;  // Dummy value for now

}

Is unfortunately just acting as a placeholder. Time to genuinely incorporate a model and its performance. Now’s the time to incorporate the information I obtained via xls from the City of Victoria.

Key Considerations:

can preprocess this traffic data to simulate how the nodes (intersections) will "learn" from the local traffic flow.

After this, can start Integrating with Federated Learning

Now that we have traffic data available, we can use it to evaluate the model at each node. For each time slice (e.g., 8:15 AM - 9:15 AM), we can take the traffic flow data and use it to adjust the model’s weights based on real-world patterns.

Map traffic data to model weights: For each intersection, we could take the sum of all vehicles (or specific movements) as a feature. This could be used as input to the model's weight calculation or evaluation function.

April 7th Shenanigans

Parsed and cleaned real-world traffic data into CSVs per intersection, per direction, per time period
- linear regression model predicting vehicle volume, delay, or congestion score based on:

we have actual locations, so what if we assign each unique location, like Douglas St & Pandora Ave, so one of the nodes! and then 4 of those make up a cluster. We can randomise which node gets what location I guess.

Extracting locations to randomly assign to nodes in the network. Then creating clusters. (randomly)

** finger guns **

In the makefile, I want to have the preprocessSheets.py script and locationAssignment.py script to run, and then our gossipnode.cc will take that info someway, somehow to assign the assigned nodes.

I have scripts outputting csv’s for .cc to use :)

Preprocessing Issues:

Fixing Makefile Path:

Errors and Debugging:

Linear Regression Script:

General Challenges:

References

[1] Maymounkov, P., & Mazieres, D. (2002). Kademlia: A Peer-to-peer Information System Based on the XOR Metric. New York University. https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf

[2] Jelasity, M., Voulgaris, S., Guerraoui, R., Kermarrec, A.-M., & Van Steen, M. (2004). Gossip-based peer sampling. distributed-systems.net. https://www.distributed-systems.net/my-data/papers/2007.tocs.pdf

[3] Kempe, D., Dobra, A., & Gehrke, J. (2003). Gossip-Based Computation of Aggregate Information. IEEE-Explore. https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1238221&tag=1

[4] Abhishek Jain, Feb 2, 2024. “All about loss functions like MSE, MAE, RMSE etc.” Medium https://medium.com/@abhishekjainindore24/all-about-loss-functions-like-mse-mae-rmse-etc-36596e3802f5

[5] J. S. Mertens, L. Galluccio and G. Morabito, "Federated learning through model gossiping in wireless sensor networks," 2021 IEEE International Black Sea Conference on Communications and Networking (BlackSeaCom), Bucharest, Romania, 2021, pp. 1-6, doi: 10.1109/BlackSeaCom52164.2021.9527886. https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9527886&isnumber=9527733

[6] D. Sobolevsky, March 15, 2023. “GeoJSON tutorial for beginners” Medium. https://medium.com/@dmitry.sobolevsky/geojson-tutorial-for-beginners-ce810d3ff169