Eirik Simón
Ortega Guttelvik

Traditional networks treat every packet the same. The moment a link gets congested, the video call degrades along with the file download nobody is watching. This project asked whether a network could work out for itself what kind of traffic it was carrying, and then act on that.

Three hosts share one 10 Mbps bottleneck: a video stream, an interactive stream and a bulk transfer that will happily eat the whole link. The controller reads flow statistics from the switch, a Random Forest labels each flow, and OpenFlow rules drop it into one of two priority queues, all while traffic is flowing.

Results

• Video jitter fell from 6.97 ms to 0.003 ms at the worst congestion point, and stayed under 0.004 ms in every scenario
• Video kept its full rate under QoS where the baseline collapsed and fluctuated
• Classification was clean on held-out flows, which is unsurprising for synthetic traffic and something I'd expect to degrade on real captures

Built at the University of Cape Town.

Autonomous driving research is dominated by places where the road is visible. In a Norwegian winter it often isn't. The markings are under snow, and the only thing telling you where the road ends is a line of poles.

They are an awkward target: thin, low-contrast against white, often half-buried and small in the frame. I trained an edge-friendly detection model on NTNU's NAPLab dataset and put the tuning effort into the failure cases of poor light, falling snow and partial occlusion, while keeping it inside a compute budget that could realistically run in a car. It scored best in the class.

Rolling out fibre to a neighbourhood is mostly a placement problem. Where do the cabinets go, how many splitters, which streets does the cable follow? Get it wrong and you either overbuild or strand houses.

We pulled building footprints and the street graph from open GIS data, then modelled placement and routing as an integer linear program. Run on a real neighbourhood in Chile, with 1340 houses and 489 poles, the solver activated 30 of 48 candidate cabinets.

Built by a team of three at Universidad Técnica Federico Santa María, and delivered entirely in Spanish.

The interesting problem in scooter sharing isn't the app. It's that the scooter is a computer standing outside in the rain. It loses signal, gets unplugged mid-charge, and has to keep behaving correctly while the server has no idea where it is.

So the app talks to a Flask API over HTTP, but everything physical talks over MQTT: scooters and charging stations each run their own state machine and publish what they're doing instead of waiting to be asked.

One scooter is real. A Raspberry Pi with a Sense HAT stands in for it. The joystick drives it around the live map, the LED matrix shows battery draining and charging, and pressing the joystick in simulates plugging it in. Built with two others for TTM4115 at NTNU.

A rocket flight lasts a couple of minutes and you get one attempt. Telemetry is the only thing standing between "we launched something" and "we know what happened".

I developed the tracker the ground crew uses during flight, acquiring the downlink, decoding the packet stream and turning it into position and state the team can act on in real time. Alongside that I troubleshot across subsystems in the run-up to launch.

Two things stuck: radio links behave nothing like the diagram once there's terrain, weather and a moving transmitter, and it's worth testing the failure path harder than the happy path, because the happy path tests itself on launch day.

VIDEO

You can buy smart blinds. They cost a fortune and they don't fit the blinds you already own, so I built the mechanism instead. A stepper motor drives the existing blind, brackets and a gear coupling are 3D-printed to fit the window frame, and the whole thing is exposed to HomeKit so it responds to schedules and to Siri.

It was the first project where the mechanical, electrical and software sides all had to agree with each other. A strong enough motor with a bracket that flexes gets you nowhere. Several print iterations later it's still running.

The project that started the habit. I wanted a drone, and building one from parts was cheaper than buying one, which is true only if you don't count the time, and I've never regretted the time.

Choosing motors, ESCs, battery and frame so the thrust-to-weight actually worked out, soldering the power distribution, then configuring and tuning the flight controller taught me what has been true of every project since: the specification is the easy part, and everything interesting happens when the parts arrive and don't quite fit.