Studying mechatronics and control
with an open mind.

MSc student in Cybernetics & Robotics at NTNU. Control team at Vortex NTNU. Formerly ML at Cogito NTNU.

Patrick Sheehan

About.

I'm pursuing a Master's in Cybernetics and Robotics at NTNU in Trondheim, working across machine learning, control systems, and autonomous robotics.

I'm currently on the control team at Vortex NTNU, where I previously served as Project Manager. Before that I spent a semester with Cogito NTNU, the student organization for applied machine learning and AI.

AI tools are part of how I work every day: Perplexity for reading papers, Claude for coding, and all of them for the countless small questions that used to cost me hours. I've built a solid foundation with them, across both learning and project work.

Prior to university I served with the Norwegian Armed Forces in HMKG Band & Drill Team, His Majesty the King's Guard.

5 Systems & tooling
ROS 2 · Docker · CI/CD · Linux · Cloud
16 mo As Project Manager
Vortex NTNU · 2024–25

Skills.

Robotics & control

ROS 2 · Guidance & control · Embedded systems · Simulation

I build theory-driven control software for a subsea autonomous drone, turning commands into safe, precise movement underwater. Most of this has been on Vortex NTNU's robotic gripper arm.

Statistics & data

Estimation & detection · SQL & BigQuery · Machine learning · Dashboards

I turn large, real-world datasets into tools people actually use, end to end. At Neat, that means building on top of our fleet and crash data, from the database to the dashboard the team checks every day. I did the same thing independently with Norwegian housing data, the Housing analytics project further down this page.

Experience.

Jun 2026 to Present

Neat AS

Software Developer Intern · Cloud & Tools

Building and maintaining the internal tooling that keeps a fleet of hardware and CI infrastructure observable, diagnosable, and clean:

  • A crash-to-Jira lookup tool: exact matching against years of tickets, with a fuzzy, similarity-ranked match as a fallback, cutting down manual incident triage.
  • Auditing and cleaning up CI build and runner infrastructure: distinguishing official from unofficial builds and identifying stale configuration to retire.
  • Several standalone tools inside the team's internal toolbox that other teams now use to speed up their own workflows, plus dashboards built from fleet network metadata.
Aug 2025 to Jan 2026

Cogito NTNU

Machine Learning · Member

NTNU's student-driven organization for applied machine learning and AI. Collaborated on hands-on projects across computer vision, NLP, and reinforcement learning, building practical ML systems alongside a team of driven students.

Ongoing

NTNU

MSc · Cybernetics & Robotics

Coursework across real-time systems, estimation & classification, modelling & simulation, and embedded systems. Norwegian University of Science and Technology, Trondheim.

Prior

Norwegian Armed Forces

HMKG · Band & Drill Team

Completed service with His Majesty the King's Guard (Hans Majestet Kongens Garde) prior to beginning studies at NTNU.

Selected projects.

01 ROS 2 · C++ · Python · Stonefish

AUV Gripper Software Stack

Manipulator guidance, control, and hardware/sim interfaces for Vortex NTNU's competition AUV, with end-to-end goal sends executing in simulation.

The problem

Vortex NTNU's AUV needed a manipulator arm that could be commanded precisely and safely to complement the vehicle's valve-manipulation capabilities. The subsystem also had to be built, reviewed, and handed off across a rotating student team.

My contribution

On the control team, I designed the ROS 2 message and action interfaces in vortex-msgs, then built the reference-filter guidance module, controller skeleton, CAN interface, and Stonefish simulation interface in vortex-gripper.

Engineering choices

The action server lets the wider autonomy stack drive the gripper through each command and phase of an autonomous mission, tracking or cancelling a goal mid-execution, with a threshold on state error triggering the final snap to setpoint. Stonefish verifies this logic end to end in simulation, while the CAN interface carries it through to the physical hardware.

Evidence
Logic testing, via Stonefish

Gripper logic exercised against the Stonefish interface

Control and interface logic tested against Stonefish, ahead of the reference-tracking run below.
Reference tracking, in simulation

The guidance filter, tracking a pinch & roll reference live

PlotJuggler capture, Stonefish simulation. Reference (red) versus actual state (orange) for the gripper's pinch and roll channels, tracking a commanded waypoint end to end. Both channels show a threshold snap to setpoint near the end of the run, once the state closes to within tolerance.
In the water

The drone in a pool test

Thrusters running, tethered for power and data, during an in-water test of the physical vehicle.
Operational reality

Validated end to end in Stonefish simulation, with integration tests in vortex-auv covering full goal sends through the pipeline.

vortex-gripper ↗ · Vortex NTNU

02 Go · Distributed systems · TTK4145

Distributed Elevator Control

A peer-to-peer elevator network in Go: no master node, and no hall call lost or duplicated across a crash or a network partition.

The problem

NTNU's TTK4145 Real-Time Systems project: a peer-to-peer network of elevator nodes has to keep serving hall and cab calls correctly through motor faults, door obstructions, and dropped network connections, without ever needing a manual restart. Each node broadcasts a state snapshot over UDP every 10ms and merges its peers' snapshots into a shared consensus view, so no central coordinator can become a single point of failure.

My contribution

Built with a three-person team for the semester project. The system runs as five concurrent Go modules communicating over channels: a driver polling buttons, floor sensors, and door obstruction; a finite-state machine turning assigned orders into movement; a network node handling consensus; a manager assigning hall and cab requests; and the door and lights output.

Engineering choices

Each hall and cab request carries its own cyclic counter (Unknown, Inactive, Requested, Active) rather than one counter for the whole state snapshot, so conflicting reports of the same order resolve locally without blocking on every other request. An earlier version counted the whole snapshot instead and was scrapped: it could only resolve one worldview at a time, which broke handling of concurrent requests.

Heislab-TTK4145 ↗ · NTNU · Real-Time Systems

03 Python · NumPy · SciPy

Modelling & Simulation

A cube-shaped satellite's torque-free attitude dynamics, modelled with the Newton-Euler equations: a steady spin for a uniform cube, precession once the mass distribution shifts.

The problem

TTK4130 Modelling and Simulation, assignment 5: derive the Newton-Euler equations of motion for a cube-shaped satellite and predict its torque-free attitude dynamics over one orbit. A uniform cube spins about a fixed axis indefinitely, but bolting a small mass onto one corner makes the same satellite's spin axis precess instead, the textbook difference between a spherical and an axisymmetric top.

My contribution & approach

Solo coursework: modelled the satellite as a 13-state system (position, velocity, attitude quaternion, body angular velocity) and derived the corner-mass case's shifted inertia tensor by hand via the parallel axis theorem. The orbit and torque-free rotation were then integrated numerically over a full 139-minute orbit.

Engineering choices

Attitude is represented with a unit quaternion, avoiding the gimbal lock that Euler angles introduce, and the torque-free Euler equation is integrated directly in the body frame. Angular momentum and rotational energy stay conserved to around 1e-15 relative drift across the run, a hard numerical check on whether the integration is actually correct.

Evidence
Two torque-free cases, side by side

The satellite's attitude over one full orbit

Left: a uniform cube spins steadily about a fixed axis. Right: adding a small corner mass turns the same cube into a precessing top.
Body-frame angular velocity and the inertial track of the body z-axis, for both satellite cases
Quantitative check. Body-frame angular velocity (top) and the inertial track of the body z-axis (bottom): constant ω and a fixed point for the uniform cube, oscillating ω and a conical track once the corner mass is added.
Operational reality

Angular momentum and rotational energy hold to machine precision, about 1e-15 relative drift, across the whole simulated orbit for both cases.

NTNU · Modelling & Simulation

04 Python · NumPy · scikit-learn

MNIST & Iris Classifiers

Nearest-neighbour and k-means classifiers written from scratch: 96.91% accuracy raw, 93.49% after compressing the reference set to k-means templates.

What it is

NTNU coursework, solo: nearest-neighbour and k-means classifiers built from scratch, to see the algorithms at the level of the underlying maths. 1NN on raw MNIST digits reaches 96.91% accuracy; compressing the reference set to k-means templates and running k=7 against them trades about 3.4 accuracy points for a far smaller reference set (93.49%), with errors concentrated in a few genuinely ambiguous pairs, like 4s read as 9s.

Evidence
Confusion matrix for a 1-nearest-neighbour classifier on MNIST, 96.91% accuracy
1NN on raw MNIST, 96.91% accuracy. Confusion matrix across all ten digit classes on the full test set.

classification_project ↗ · NTNU · Estimation & Classification

05 Python · GeoPandas · openavmkit

Housing Valuation & GIS Analytics

An end-to-end mass-appraisal pipeline on real Norwegian property data: the deepest, most heavily evidenced project on this site. Full breakdown below.

Why this one's different

Self-directed, outside any coursework or team assignment: I found the public ArcGIS services behind Norwegian housing-price maps, scraped and modelled the data myself, and ran an IAAO-standard valuation pipeline end to end. The write-up reports the model's honest accuracy numbers alongside the wins.

housing-valuation-gis ↗ · Self-directed

Housing analytics.

A self-directed dive into geospatial data engineering and mass appraisal. I traced public ArcGIS map layers back to their REST APIs, scraped real Norwegian housing data, engineered spatial features, and ran an IAAO-standard automated valuation model from end to end. The metric throughout is price per m².

Three Norwegian cities OsloMet · 100 m grid · ≈ 2016

All three come from one OsloMet dataset (≈ 2016), so they compare like-for-like; a different source from the Asker data below. Bar = median price/m², right = level versus Oslo.

MEDIAN PRICE / m²

Three cities, compared

Asker, in depth Geodata · per-transaction · 1988–2023

Individual open-market sales, per transaction, not a grid: ordinary deals between an unrelated buyer and seller, not gifts, inheritance or family transfers.

Property workspace

The Asker sales data, three views

Subject property · Asker · gnr 9/bnr 159

Key info
Area score
Location & comparables
The white ringed marker is the subject home being valued. The other markers are the comparable sales it is priced against, shaded by price per m².
Subject lower → higher NOK/m² Hover to zoom; click a marker for its NOK/m².
Comparable sales

Motion as explanation

The valuation pipeline, animated end to end

Some pipelines are easier to watch than to read. A 3-minute Manim walkthrough of the whole mass-appraisal workflow: the raw matrikkel table, the cleaning rules, every sale placed on the map, a cluster of comparable homes, and the one outlier flagged for scrutiny. Built with Manim · data: Geodata “Matrikkelbygg_Salg” (public ArcGIS).
MEDIAN, BY YEAR

Asker price/m², over time

Spatial gradient. Asker dwelling sales, price/m² by location (interactive, GeoPandas + Leaflet). Source: Geodata “Matrikkelbygg_Salg” (public ArcGIS).
Asker sale price versus living area, zoomed to the trend
Hedonic relationship. Sale price against living area (BRA), zoomed to the trend. Technique after Qiusheng Wu, Introduction to GIS Programming.
Median price per square metre by dwelling type in Asker, with interquartile range
Price by type. Median price/m² for each dwelling type (recent sales), with the middle-50% range. Robust to the handful of impossible records in the raw data.

Running my own AI.

I self-host a local large language model on my own hardware, reachable from anywhere through a secured Cloudflare tunnel. The whole system runs as a set of containerized services coordinated by Docker Compose, with GPU passthrough so inference stays fast on consumer-grade hardware.

Beyond the model itself, this project has given me real hands-on experience with Linux, container networking, reverse tunnels, and the day-to-day work of keeping self-hosted infrastructure running.

STACK
OLLAMA Local LLM runtime, GPU passthrough enabled
OPEN WEBUI Chat interface, multi-user accounts
CLOUDFLARED Secure public tunnel, no open ports
COMPOSE Orchestration across services
LINUX + GPU Host OS and container runtime

Get in touch.