Research

GNSS and indoor positioning

As an undergraduate at PolyU I built an AI-aided GNSS software-defined receiver in MATLAB, working on raw satellite signal rather than on computed position fixes. The model classified which measurements had been corrupted by multipath — signal arriving at the antenna after bouncing off a building instead of directly from the satellite — and predicted that error before it reached the position solution. Most of the work was signal processing.

The harder problem sits upstream of the modelling. Every receiver, phone, and sensor writes its output in a different dialect: RINEX, NMEA, UBX, and a long tail of undocumented proprietary formats. Fusing two sensors means writing a parser first, and that work gets redone constantly.

With Prof. Li-Ta Hsu’s IPN Lab at Hong Kong PolyU I worked on whether a language model could do it instead. Asking a model to transcribe the data directly does not scale. Instead the model writes a parser, the backend runs it against the real file, validates the output, and returns structured errors until it converges.

That became a paper at IPIN 2024 and an open toolkit, FusionFly. A follow-on manuscript is under review. A parallel line with the same group used a spherical panorama and a building information model to localise a phone camera indoors without dedicated infrastructure, published in IEEE Sensors Journal.

Thermo-fluid experiments at Ghent

In the summer of 2024 I worked in the Sustainable Thermo-Fluid Energy Systems group at Ghent University, with Wito Plas and Prof. Michel De Paepe, on conditioning horticultural growing spaces efficiently. The project ran across both sides of that problem: the two-phase injection compressor that supplies the heat, and the wind tunnel that measures how air actually moves through a crop canopy once it gets there. A CFD model of a growing space is only worth as much as the measurements it has been checked against, and those have to come off a physical rig.

The work was experimental rather than computational. I extended the group’s LabVIEW acquisition program to record the runs, tuned the PID loops until the setup would hold conditions steady long enough for a reading to mean anything, and then ran the tests and reduced the data into a form the CFD model could be validated against. Most of the time went into getting the rig to behave; the measurement itself is the short part.

Carbon accounting at Imperial

Since November 2025 I have worked with Prof. Anna Korre in Imperial’s Department of Earth Science and Engineering on estimating emissions from institutional travel. People describe journeys in prose rather than in structured fields, so the system parses those descriptions, resolves them against live routing data from TfL and OSRM, and produces estimates that college sustainability officers use for policy.

Reading indicators out of sustainability reports

A second thread at Imperial is with the Leonardo Centre on Business for Society, which has mapped some 2.6 million corporate sustainability actions. What that map lacks is outcomes. An action is on record, but the numbers that would say whether it changed anything — Scope 1–3 emissions, water intensity, return on equity, R&D intensity — sit unstructured in the companies’ own reports.

Those reports resist extraction. One indicator might live in a dense financial table on one page and in a sentence of prose on another, under a different name and a different unit depending on whether the company reports against GRI, SASB, or TCFD. So the pipeline is hybrid: table parsing for the grids, a language model for the values buried in text, both resolving down to entity–attribute–value triplets.

The interesting constraint is that an extraction which is right most of the time is not usable as research data. Every value is therefore grounded against a page and a coordinate box in the source PDF, put through unit standardisation, and then read back by a second model whose job is to reject it.

Cost shapes the rest of the architecture. The data lake holds around half a million PDFs, and sending all of them page by page to a frontier model is not affordable, so the system cascades: small models decide which sections are worth reading, and only those reach the model that does the reasoning.

Clusy

Clusy is a notebook where an agent does the setup: finding the data, writing the cells, attaching GPUs, and running branches in parallel.

The open problems sit in the runtime, and that is where most of the work goes: kernel management, state persistence, and dependency-aware re-execution.

A notebook is a dataflow graph rather than a linear script. Each cell reads some variables and writes others, so the dependencies between cells can be derived from the code itself. Once that graph exists, editing one cell only invalidates the cells that transitively depend on it, and the rest of the notebook does not need to run again — which matters when a single cell is a forty-minute training run.

Doing that reliably means tracking state at the kernel level rather than the document level, and checkpointing it, so that a session survives disconnection, a notebook can be forked at any cell without recomputing everything above it, and two branches of the same experiment can run against the same materialised state on different machines.