Civil engineering @ Western · Oakville, ON

Nishant Shah

I'm a civil engineering student at Western. I've worked on the construction side and the finance side of infrastructure, and I teach myself to code when a problem won't leave me alone. Lately that's been a model that predicts city traffic — and now robots: a lidar rover that maps rooms, and a two-wheeler that balances itself.

See my projects Email me
About

I'm less interested in big visions than in how things actually get built, paid for, and kept standing.

I'm a couple of years into civil engineering at Western. So far I've spent time on the construction side, doing project controls at The Byng Group, and on the money side, through infrastructure finance and financial services.

The coding is self-taught. I got into machine learning because of smart cities and it stuck — a traffic-forecasting model, a live aquaponics dashboard, a hard-hat detector. Lately it's spilled into hardware: I'm building robots, starting with a lidar rover that maps rooms and a self-balancing two-wheeler. Alongside that I'm figuring out where infrastructure advisory fits into all of it.

NowProject controls at The Byng Group
StudyingB.Eng Civil, Western University
BuildingA SLAM rover and a balance bot
Curious aboutInfra finance, advisory, ML
Experience & education
Projects
Diagram of the A3T-GCN model: message passing between sensors, then a GCN → GRU → attention → linear pipeline.
How the model works — a diagram I drew to force myself to actually understand each layer.

I used METR-LA — 207 loop sensors across Los Angeles highways — and built an A3T-GCN, a graph neural network that reads space and time at once. A graph convolution lets every sensor borrow its road-neighbours' readings, a GRU reads the last hour, and an attention layer decides which moments matter. It forecasts speed 60 minutes ahead. The point of the graph is simple: a jam upstream reaches you a few minutes later, and a plain per-sensor model can't see that coming.

The model on its own isn't the interesting part. I fed its forecasts into a SUMO simulation and let them drive the traffic lights on a 3×3 grid through TraCI. Against fixed-time signals, the adaptive version cut average waiting time by 79%.

  • PyTorch Geometric
  • A3T-GCN
  • SUMO / TraCI
  • METR-LA
Code & notebook ↗
Line chart: predicted vs actual speed over time at one sensor.
60-min-ahead forecast vs. real speed at one sensor. Where the line drops to zero the sensor cut out — the model leans on its neighbours instead of following it off a cliff.
Animated SUMO grid simulation with vehicles and signals.
The forecasts driving adaptive signals in SUMO.
Bar chart comparing adaptive vs fixed-time signal control.
Adaptive vs. fixed-time: −79% waiting, −55% time loss, −27% trip duration.
CAD render of the rover's printable body shell with cooling vents and a lidar opening.
The printable body shell, written in OpenSCAD — sources are in the repo.

I'm building an autonomous rover that maps rooms with lidar: a Raspberry Pi 5 runs ROS2 and slam_toolbox for the thinking, a Pico handles real-time motor control, and every structural part is 3D-printed from my own CAD. Before spending a dollar I did the engineering on paper — a decision log, a risk register, and a staged ~$400 bill of materials — because on a student budget, ordering the wrong motor driver twice is the real failure mode.

The firmware already works: PWM motor control, quadrature encoders counted in PIO, and a WiFi command protocol with a fail-safe watchdog, validated 9/9 in a simulation harness I wrote so it could be tested with no robot attached. Structural parts are printed and dry-fitted on a Bambu P1S; hardware bring-up is the next phase, and every problem along the way goes in a debugging log.

  • ROS2 Jazzy
  • slam_toolbox
  • MicroPython + PIO
  • Onshape / OpenSCAD
Design package & code ↗
CAD render of the rover chassis plate with a grid of mounting holes.
The chassis plate — a 34-hole grid, so mounts can move around without reprinting the whole plate.
CAD render of an N20 motor clamp.
N20 motor clamp — a press-fit tunnel, no fasteners needed.
CAD render of a drive wheel with grooves for rubber-band tires.
Drive wheel with a D-bore and grooves for rubber-band tires.
Screenshot of the AquaControl dashboard showing pH, temperature, water level and ammonia readings with trend charts.
The real dashboard, running in simulation mode here. The alert buttons actually do something — go try them on the live version.

My team designed an aquaponics system — fish and plants sharing one water loop — and I built the software that watches it. An ESP32 reads pH, water temperature, level and ammonia and streams them to this dashboard over WebSocket; a Node + SQLite backend keeps history so you can see trends and catch a problem early. With no hardware connected it runs a physics simulation, so the whole thing is still pokeable. It placed 2nd runner-up for People's Choice out of about 80 teams.

  • ESP32 / Arduino
  • Node.js
  • WebSocket
  • SQLite
Live dashboard ↗ Code ↗

A few smaller things

Contact

Say hi.

I'm looking for co-op and internship roles, and I'm always happy to talk infrastructure or kick around a project idea. Email is the best way to reach me.

LinkedIn ↗ GitHub ↗