In the spring of 2026 I started to work on data-driven discovery of PDEs as part of my PhD project, with a focus on equivariant methods for PDE discovery on flat planes, spheres, and hyperplanes. Instead of deriving equations from physical principles the idea is to start from data and try to deduce the governing equations. This is fairly well studied, but the question of how to handle the same problem when symmetries are known (or suspected) or when the domain has non-zero curvature was still unexplored.

Erlend (my doctoral advisor) and I had already worked on the foundations of this problem from the theoretical side, by studying a complete classification of equivariant polynomial differential operators ¹, and we wanted to now apply our results to a practical problem. I started by designing a research plan which involved picking some famous PDEs to test, implementing a numerical integrator to simulate them, and applying our methods against known benchmarks. Doing a literature review, one of the PDEs I encountered was the Kuramoto–Sivashinsky (KS) equation ²,³, and I was immediately fascinated by it!

The KS equation is one of the simplest partial differential equations that exhibits several regimes among which some are spatiotemporal chaos. It is a canonical testbed for studying chaos in extended systems, and it appears in surprisingly many physical contexts.

What struck me most was the dramatic change in behaviour (the different patterns) as a single parameter (the domain size \(L\)) is varied. For small domains the equation is boring as everything decays to zero, but for slightly larger domains, steady cellular patterns emerge (hexagons, rolls, or oscillating cells). Push \(L\) further, and the cells break apart into fully developed spatiotemporal chaos. Three qualitatively different regimes from one parameter. I wanted to see them, and I wanted to play with them. I then needed to write my own simulator to do that, and I decided to build it as a browser-based interactive tool for everyone to enjoy.

This post walks through the equation, the three regimes, and briefly how the simulator works under the hood. You can play with it yourself here.

The equation in 1D

Before diving into two dimensions, it's worth looking at the one-dimensional version. In 1D the KS equation is usually written as

To understand what each term does, we switch to Fourier space (where \(\partial_x \to i k\), turning derivatives into multiplication). Expanding \(u(x,t) = \sum_k \hat{u}_k(t) e^{i k x}\) with \(k = 2\pi j / L\) for \(j \in \mathbb{Z}\), the equation becomes

where the linear part breaks down as follows:

The two linear terms compete: \(k^2\) wants to grow the mode, \(-k^4\) wants to kill it. Modes with \(\vert k\vert < 1\) grow (anti-diffusion wins), modes with \(\vert k\vert > 1\) decay (hyperdiffusion wins). The nonlinear term \(\hat{N}(u)_k = \mathcal{F}[-\tfrac{1}{2}(\partial_x u)^2]\) couples different \(k\) together, transferring energy between scales.

The classic way to visualize the 1D KS equation is through a spacetime plot: a horizontal slice of the solution stacked vertically over time.

The equation in 2D

In two spatial dimensions the KS equation takes the form

The parameter \(\nu\) controls the strength of the hyperdiffusion (in the 1D version above, \(\nu\) was implicitly set to 1).

To analyze the equation, we expand the solution in a 2D Fourier series. Because the domain is periodic, we can write

where the index of the Fourier coefficients \(\mathbf{k} = (k_x, k_y)\) is called wavevector, which label each Fourier mode. The magnitude \(k = \vert\mathbf{k}\vert = \sqrt{k_x^2 + k_y^2}\) is called the wavenumber. A mode with large \(k\) varies rapidly in space (small ripples), while a mode with small \(k\) varies slowly (broad swells). The coefficient \(\hat{u}_{\mathbf{k}}(t)\) is a complex number encoding the amplitude and phase of the mode with wavevector \(\mathbf{k}\) at time \(t\).

Working in Fourier space turns derivatives into multiplication, and just as \(\partial_x\) turns into \(i k_x\) in 1D, in 2D the gradient becomes \(i\mathbf{k} = (i k_x, i k_y)\), and the Laplacian becomes \(-\vert\mathbf{k}\vert^2 = -(k_x^2 + k_y^2)\). Applying this to the KS equation, we split it into a linear part \((-\Delta u - \nu\Delta^2 u)\) and a nonlinear part \((-\tfrac{1}{2}\vert\nabla u\vert^2)\), and transform each:

• The linear part becomes \(\bigl(\vert\mathbf{k}\vert^2 - \nu\vert\mathbf{k}\vert^4\bigr)\,\hat{u}_{\mathbf{k}}\). Crucially, this is diagonal: each Fourier mode \(\hat{u}_{\mathbf{k}}\) is multiplied only by a scalar that depends on \(\mathbf{k}\) alone. There is no mixing between different \(\mathbf{k}\) — mode \(\mathbf{k}\) doesn't talk to mode \(\mathbf{k}'\) through the linear terms.
• The nonlinear part, which we write as \(\hat{N}(u)_{\mathbf{k}} = \mathcal{F}\bigl[-\tfrac{1}{2}\vert\nabla u\vert^2\bigr]\), is not diagonal: it couples different Fourier modes through convolution. This coupling is what transfers energy between scales and ultimately generates chaos.

So in Fourier space the PDE becomes a system of ordinary differential equations, one for each \(\mathbf{k}\):

The linear coefficient depends only on \(k = \vert\mathbf{k}\vert\), so the linear part is diagonal — each mode evolves independently. Because it is diagonal, the linear part can be solved exactly: over a time step \(h\), each mode simply multiplies by

Just as in 1D, the growth rate \(k^2 - \nu k^4\) pits anti-diffusion (\(k^2\), wants to grow) against hyperdiffusion (\(-\nu k^4\), wants to decay). The two balance at the critical wavenumber

Modes with \(k < k_{\text{crit}}\) grow; modes with \(k > k_{\text{crit}}\) decay.

What does this have to do with the domain size? On a periodic domain of length \(L\), the smallest nonzero wavenumber is \(k_{\min} = 2\pi/L\) and you can't fit a wave longer than the box in the box itself. If even this longest wave decays (\(k_{\min} > k_{\text{crit}}\)), the solution dies out. The threshold \(k_{\min} = k_{\text{crit}}\) gives the critical domain size

Three regimes, one equation

The ratio \(L / L^\ast\) is the single parameter that determines the qualitative behaviour of the system. Here's what happens as you increase it.

Stable (\(L < L^\ast\))

When the domain is smaller than the critical length, no Fourier mode fits within the unstable band. Every mode decays exponentially, and any initial condition eventually flattens to \(u \equiv 0\). Not terribly exciting, but a good sanity check for the simulator.

Cellular (\(L^\ast < L \lesssim 3L^\ast\))

A small set of modes — those whose wavevectors fit inside the unstable annulus \(0 < \vert\mathbf{k}\vert < 1/\sqrt{\nu}\) — begin to grow. Nonlinear saturation locks them into steady or periodically oscillating patterns: rolls, hexagons, or mixed states depending on the initial condition and the precise value of \(L\).

Chaotic (\(L \gg L^\ast\))

When the domain supports many unstable modes, the nonlinear term transfers energy between them continuously and the patterns never settle. They twist, merge, split, and reform in an endless dance which is spatiotemporal chaos. The field at any given point fluctuates unpredictably and produces a result that is visually mesmerising.

How the simulator works

The simulator runs entirely in the browser with the use of a JavaScript snippet. The numerical engine is implemented from scratch following standard methods from the literature, with some tweaks to balance accuracy and performance.

Halfway through the project I came across Ricky Reusser's beautiful WebGL notebook which implements a similar simulator, which I recommend checking out. Especially his WebGPU implementation which is incredibly fast.

Here's a high-level overview of the key components of the simulator I built. I am not an expert in numerical PDEs, so a lot of the design choices were made through trial and error and relying on papers I scavenged from the internet. If you have suggestions for improvements, please let me know!

Spectral discretization

The domain \([0, L]^2\) is discretised into an \(M \times M\) grid. Since the boundary conditions are periodic, the natural basis is the Fourier basis. The solution is represented by its Fourier coefficients \(\hat{u}_{\mathbf{k}}\) on a grid of wavenumbers

Spatial derivatives are computed in Fourier space (multiplication by \(i k_x\) or \(i k_y\)), then transformed back to physical space when needed. The 2D FFT is the workhorse — specifically a hand-written radix-2 Cooley–Tukey implementation. It's not as fast as FFTW, but it runs in a Web Worker so the UI stays responsive.

The nonlinear term

The nonlinear term \(\hat{N}(u) = \mathcal{F}[-\frac{1}{2}\vert\nabla u\vert^2]\) is computed pseudo-spectrally:

1. Compute the physical-space gradient \(\nabla u = \mathcal{F}^{-1}[i\mathbf{k}\,\hat{u}]\)
2. Form \(-\frac{1}{2}\vert\nabla u\vert^2\) pointwise in physical space
3. Transform back: \(\hat{N} = \mathcal{F}[-\frac{1}{2}\vert\nabla u\vert^2]\)

Apparently, there can be an issue of aliasing, which can be addressed by the 2/3 de-aliasing rule: after each step, zero out all Fourier modes with \(\vert j_x\vert > M/3\) or \(\vert j_y\vert > M/3\). This removes the aliasing error at the cost of effectively running on a coarser grid (and about a 2× slowdown). In practice, I don't really see much difference.

Exponential Time Differencing (ETD)

The hyperdiffusion term \(-\nu\nabla^4 u\) is extremely stiff. A stiff term is one that involves drastically different time scales within the same problem and here, the high-wavenumber modes decay orders of magnitude faster than the low-wavenumber ones. Any explicit time-stepping method must take steps small enough to resolve the fastest scale, even if we only care about the slow ones.

Concretely, let's see what happens if we try to use forward Euler. For the highest resolved wavenumber \(\vert\mathbf{k}\vert_{\max} \approx \pi M/L\) the hyperdiffusion term \(-\nu\vert\mathbf{k}\vert^4 \hat{u}\) contributes \(-\nu(\pi M/L)^4\). An explicit method would require \(\Delta t \sim 1/\vert\mathbf{k}\vert_{\max}^4 \sim L^4/(\nu M^4)\) for stability. On a modest \(64 \times 64\) grid, that's around \(10^{-6}\). We would need a million steps to simulate one time unit. A bit pricey.

The solution: treat the linear part exactly. Write the PDE in Fourier space as

where \(\hat{L} = \text{diag}(\vert\mathbf{k}\vert^2 - \nu\vert\mathbf{k}\vert^4)\). The exact solution over a time step \(h\) satisfies

The first term handles the linear part exactly with no stability restriction from the \(\vert\mathbf{k}\vert^4\) term. The integral involving the nonlinearity is approximated by a Runge–Kutta scheme, giving a family of Exponential Time Differencing methods. The specific one used here is ETDRK4 ⁴, a fourth-order scheme. Its coefficients involve the \(\varphi\)-functions, which arise naturally from the integral in the exact solution formula:

The ETDRK4 step reads:

where all \(\varphi_{\ell}\) are evaluated at \(h\hat{L}\) in the final line.

Evaluating \(\varphi_1, \varphi_2, \varphi_3\) near \(z = 0\) requires care — the formulas above suffer from catastrophic cancellation. The simulator uses a numerically stable evaluation ⁵, falling back to the explicit formula for \(\vert z\vert > 5\) where it is safe.

The simulator also offers a simpler IMEX BDF2 integrator (implicit-explicit Backward Differentiation Formula, second order). It treats the stiff linear terms implicitly and the nonlinearity explicitly, trading some accuracy for better stability on coarse grids. This is what Reusser's notebook uses.

Why does it still blow up sometimes?

If you push the domain size too large or the hyperviscosity too low, the simulation will eventually blow up and the solver will stop. This is frustrating, especially if you've seen other KS simulators (notably Ricky Reusser's beautiful WebGL notebook) that seem to run forever without a hiccup. What gives?

Half-precision arithmetic as accidental hyperviscosity. Reusser's simulation runs on the GPU using WebGL textures, which default to 16-bit floating point (float16). Every multiplication discards information at high wavenumbers. This acts as an unintentional low-pass filter that continuously damps the very modes most prone to instability. Our solver uses Float64Array (double precision) in a Web Worker, preserving energy across all resolved scales, including the ones that can run away.

A different form of the equation. Reusser follows Kalogirou et al. ⁶, who shift the solution by a constant drift: \(V = u - ct\). This introduces a term proportional to \(c\,dt\) into the BDF2 update formula that provides additional damping of previous timesteps. Our implementation solves the KS equation directly without this shift.

Energy-leaking post-processing. After every timestep, Reusser's code runs an extra cycle to remove imaginary leakage from the complex FFT of real data. Each such pass removes a tiny amount of energy. Our code preserves Hermitian symmetry analytically (if \(\hat{u}_{-\mathbf{k}} = \overline{\hat{u}_{\mathbf{k}}}\), the IFFT is real), so no stripping is needed (but we also don't get the free dissipation).

The IMEX BDF2 integrator mentioned above follows the same approach as Reusser's notebook but without the half-float damping or the \(c\)-shift.

Try it yourself

The simulator is live at francesco.ballerin.it/ks_equation. Here are some parameter combinations to get you started:

References

At some point during one of my productive doomscrolling evenings, on YouTube specifically, I came across a video produced in November 2024 by Marcello Ascani featuring a pizzaiolo who moved to San Francisco, and was at the time working for a company producing Napolitan frozen pizzas in the Bay area. The original video can be found here.

The business model showcased in the video was baking fresh Napolitan pizzas just outside of the city, freeze them, and then ship them to around 100 Whole Foods locations in the area, where they were sold at around $10 a piece.

Living in Norway, where frozen pizza is one of the most consumed foods (but alas not because of exceptional quality) this video sparked curiosity in the form of "what if I could do it myself, and have a stack of delicious and cheap homemade frozen pizzas at any given time rather than buying the crap at the store?".

Not that I would buy frozen pizzas anyway. I am a true patriot 🇮🇹🤌.

Background

Baking is not a trivial process, and it shares a lot more similarities to chemistry than cooking does. And, believe it or not, chemistry was one of my least favorite subjects in highschool. Probably one of the contributing factors pushing me towards mathematics and informatics rather than physics and engineering.

While preparing for this project I did a deep dive into the theory of flour types and baking — which we are soon going to cover — and contacted a couple of industries dealing in flour milling and frozen pizzas production. The summary of this explorative search follows.

Types of flours and yeast

Not all flour is the same, and this is obvious when facing the flour shelf of a well-stocked grocery store. Some flours are sold for breadmaking, others for focaccia, some for cakes and shortbreads. The difference lies not only in the grain type and origin, but also in the milling procedure, and they can be quantified and accurately measured. The characteristics of flours can be inferred by metrics such as protein content, W-value, P/L ratio, water absorption, and ash content just to name a few.

Several countries introduced naming conventions with associated requirements, and have strict regulations on how to name them. In Italy, just to name a country, these types can be defined as tipo 00, tipo 0, tipo 1, tipo 2, and integrale. Other countries may follow different naming conventions.

Protein content

This is the value that is easiest to find as a retail consumer. By law it needs to be reported on every package of flour which is sold. It typical ranges between 9g and 14g per 100g of product. This is usually referred to as the strength of the flour, as the protein contained in the flour is usually gluten-forming proteins.

The rule of thumb is to pick an 11-12.5% for Napolitan pizza and 12.5-14% for long fermentations.

W-value

The W-value measures the required energy to deform the dough — either resisting to manipulation or resisting to the dough raising — thus making it a good proxy for gluten strength. The alveograph test consists of inflating a disk of dough, making it into a bubble, until it bursts, while measuring the pressure for the first deformation and the total volume of air that is needed to rupture the glutinic mesh.

Typical ranges and common uses are:

• < 170 : weak (cookies and shortbreads)
• 180 - 270 : medium (direct doughs, short-medium fermentations)
• 280 - 350 : strong (long fermentations)
• > 350 : very strong (panettone, biga for multistep doughs, very high hydration doughs)

The W-value is measured in a lab test using the Chopin's alveograph test, and it is not a metric that is legally required to be reported. Approximate ranges can be inferred if the flour is sold as a specific type, but specific values are often found only on more premium flours.

For more refined flours, with a minimal content of bran, the W-value correlates well with the protein content. But for other types of flours, for example wholegrain or if durum wheat or other grains are mixed in, the protein content does not correlate as directly with the W-value as measured by the alveograph test. Moreover, the W-value as a proxy for gluten strength loses significance in these cases and should be disregarded.

P/L ratio

The P/L ratio measures the ratio between tenacity (P) and extensibility (L) and it is also measured through the alveograph test. The P value is the pressure to first deformation, while the L value is the total volume of air that the dough can handle before bursting — which corresponds to how much it can extend before rupturing.

Ash content

The ash content is not a measure of how much ash there is in flour, but rather a measure of the mineral content. It has gotten this name due to the procedure with whom it is measured: a sample is burned and minerals are then measured in the ash residue that is left behind after combustion has taken place.

As the minerals are mostly contained in the bran of the wheat, the ash content is a good indicator of how much of the bran has made it into the flour — menaing how little refined the flour is.

In Italy the ash content is regulated by law by the name of the type of the flour, which can be tipo 00, tipo 0, tipo 1, tipo 2, and integrale. In other countries other classifications can be in place, or it can happen that no classification at all is used. In these cases it can be harder to determine the ash content of the flour you are buying.

I have attempted to put together a table of some of the flours for sale at retail grocery stores in Norway, as well as online at the specialty store "Oluf Lorentzen". Most of the technical specification of the flour is available online on the websites of the respective producers. I have also contacted Regal flour, which is one of the main brands for retail shoppers in Norway, for information regarding their lines of flour. The price was reported as the minimum "bulk price" for orders of a maximum of 5kg, taking advantage of "quantity discounts" such as 3x2 offers but not seasonal or temporary discounts.

Choice of toppings

Toppings need to be able to preserve their quality when frozen. Sauces, cheeses, roasted vegetables, and cooked meats (pepperoni, 'nduja, bacon …) are all excellent choices as toppings as quality is mostly preserved when undergoing the freezing process. Fresh ingredients and cold cuts, such as rucola, cherry tomatoes, and prosciutto crudo, completely lose their profile when undergoing the freezing and reheating process.

Freezing / cold blast process

From what I gathered from a quick literature review, it appeared that most of the available research covered (raw) doughs and parbaked (partially baked) products. Parbaking is probably the best way to prepare the pizza dough, but it would deprive the pizza of its classic Napolitan-style crust. I wanted a finished product that was possible to prepare in the oven straight from the freezer in approximately 10-12 minutes.

Research on frozen doughs and parbaked products shows that the type and strength of flour make a big difference in how well the pizza base survives freezing and reheating. Stronger flours with higher gluten content, which correspond to higher W-values, tend to retain more gas and structure after thawing, leading to better texture ¹. For home use, this means preferring a strong flour.

If the dough is fully baked — as in our case — freezing can still alter water distribution: ice crystals in the crumb can cause slight dryness, while moisture migration may soften the crust ². Cold blasting is often used in industrial production, as it drops the temperature of the food quickly, freezing it to the core within minutes. Because freezing happens so fast, the liquids form smaller crystals than they normally would in a regular freezer, locking in structure, texture, and aroma. Unfortunately, this is out of reach for most homecooks. Even without a blast chiller, minimizing the time it takes for the dough to freeze — for example by using thin metal trays — helps protecting the texture and flavor.

From my personal experience a regular freezer is good enough to obtain quite decent results. I have opted to wrap the pizzas in a layer of cling film to avoid freeze burns, which would dramatically reduce the quality of the final product. It is important to let the pizzas cool down before freezing, in order to minimize condensation and raising the internal temperature of the freezer. Optionally, after the pizzas have been frozen solid, it is possible to double wrap them in a second layer of cling film to further decrease the risk of freeze burns when stored for longer periods of time.

My first attempt

The recipe I have opted to use is the following, which has a yield of 4 pizzas:

Napolitan pizza dough does not usually contain oil, but oil is rather used as a topping which is added to the pizza just before going into the oven. However, a bit of extra virgin olive oil makes for a softer and richer dough, which I prefer. It also has the added benefit of makin the dough easier to handle.

After using a kitchen mixer, and giving a final folding by hand, I left the dough to rest and start the raising process at room temperature for approximately 4 hours before moving it in the fridge. This slows down the raising process allowing for better timing.

Approximately 4 hours before the pizza is to be baked, I take the dough out of the fridge and divide it into the 4 portions that will be then used to make the pizzas. After folding the dough a second time, and another 3.5h at room temperature, I like to move the portions again in the fridge to reduce the dough temperature, making the dough a bit stiffer and easier to work.

I then baked the pizza in a gas-powered pizza oven (cozze 13") until done, and left it to cool down on the bench before wrapping it in cling foil. As I do not have a chill blaster, I used my freezer to freeze and store the pizza.

After a few days in the freezer, it was the moment of the truth: I took a pizza out of the freezer, preheated the oven at 200°, and reheated for about 10 minutes.

All in all the pizza was delicious, but different than a fresh one by a mile. In particular the cheese on top was maybe a bit overcooked, and the crust was dry and crunchy in a slightly unpleasant way. So I would call it a success with a discrete margin of improvement.

My second attempt

For my second attempt I modified two steps in the procedure:

• Tried swapping "Caputo Pizzeria" for "Caputo Nuvola";
• The toppings are now added AFTER an initial baking;
• Oil is added to the crust before freezing to prevent a dry crust.

These slight adjustments made a big difference. The pizza came out of the oven with cheese that was now hot but not "lava-like" hot, and the crust was less dry and crunchy, although still quite different from the fresh version.

The change of flour was not really noticeable.

Conclusions

When it comes to quality of the final product there is no comparison: the homemade frozen pizza beats the commercial ones hands down. Not only do they taste and feel better, but can be highly customizable allowing for a larger range of possibilities.

Let us now analyze the cost. To estimate it I will use the prices available to the retail customer in the Norwegian market as of November 2025.

Estimating the propane usage is not trivial, as it depends on the pre-heating time, the number of pizzas made per batch, and the speed of the pizzaiolo. By a back-of-the-envelope calculation I approximate a 5kg canister to be good for around 75 pizzas. Such a canister can be refilled completely for 269 NOK. Cost estimates assuming we are using all the ingredients in the most efficient way possible.

Comparing it to the Norwegian national treasure Grandiosa pizza and the cheapest option First Price margherita — which sell at 59.90 NOK on oda.no and 29.90 NOK at the grocery chain Meny respectively — it seems like it pays off to bake homemade pizzas, also from a cost perspective.

References

Have you ever arrived at the airport, blissfully unaware, and suddenly found yourself submerged in chaos — a sea of people struggling with delays and cancellations? It is an absolute nightmare, and it happens to me regularly. To the extent that I have started looking up FlightRadar24 and Avinor's website to see what to expect prior to my arrival at the airport.

I stumbled upon FlightAware's Misery Map® and got inspired; I decided to create something similar for the Norwegian airports, so that I can always know what to expect when heading to catch my next flight.

Architecture

The architecture is fairly simple, and is based on D3.js for data visualization and W3.CSS for the stylesheet.

Avinor exposes a set of APIs that can be easily queried to obtain all the information we need to build the console. We just need a small middle layer to handle CORS requests, and possibly aggregate it so that we do not need to perform a request for every airport.

Avinor APIs

The official API documentation can be found here, but I report here a brief summary of the query parameters and the response attributes.

Request:

Notice that the request is airport-specific. Therefore, a request needs to be made for every single airport.

Response:

Cloudflare workers

Cloudflare Workers are a serverless platform executing JavaScript snippets. Exactly what we need.

On the free plan we can process up to 100,000 requests a day, with a limitation on CPU time of 10 milliseconds per request.

Avinor's API is not configured for CORS requests, and therefore cannot handle direct-browser requests from arbitrary origins. The Worker fetches data from Avinor server-side, so the browser can safely call the Worker endpoint without running into CORS restrictions. Additionally, by the way the API is built, we need to query every single airport in Norway. Instead, I delegated this operation to the worker, who calls the API asynchronously and returns an aggregated result.

To reduce request volume to Avinor and make the UI faster, the Worker implements short-lived caching. The Worker sets appropriate Cache-Control headers and leverages the Cloudflare cache API to store JSON responses for a short TTL (in my case 60 seconds). This reduces API calls to Avinor while keeping data near real-time.

LLM usage

Although I enjoy coding, especially if it is a data-driven project, I do not particularly enjoy UI-building and having to deal with HTML/CSS. JavaScript is also not my favorite programming language (clearly). So I took it as a good chance to see how far I could push agentic AI to help me build such a dashboard.

I knew already how I wanted to structure the project (W3.CSS + D3.js + Avinor's API + Cloudflare workers) so I described exactly how the API worked and what I wanted for a starting point and let the LLM do its magic.

The first result was usable but needing several BIG improvements. In particular:

• The agent tried to use the World Atlas TopoJSON in the form of countries-10m.json, which was nowhere near fine enough for good visualization. I changed it to countries-110m.json and filtered the file to keep only the features for Norway to make requests lighter.

• The UI was there, but it was frankly quite terrible. The LLM tried to custom-make CSS code instead of using W3.CSS as instructed. But this was easily fixed.

• Although it had been fed the documentation on the API, it still applied the wrong logic to some of the data processing. For example, it mixed up departure and destination airports, and incorrectly classified cancelled flights.

• The default value for caching was set at 12s. I updated it to 60s, which is better but potentially still quite low.

Overall, it compressed the required workload from several days of painful UI-building to a few hours of high-level thinking and some debugging. So I am quite happy with this experiment.

Still, horizontal centering through CSS seems to be godly work that is beyond the capabilities of an LLM. Let's not talk about vertical centering.

Future developments

I would have loved to include a weather overlay, such as precipitation data coming from meteorological radars or nowcasting computed by the Norwegian Meteorological Institute. Unfortunately, I could not find such data for Norway readily available except as tiles that need to be processed and stitched together. I decided to leave it for another time.

I also thought the interactive visualization of the traffic streams on FlightAware's map was pretty cool, but that was way above my UI knowledge to implement and I did not dare asking the LLM to assist me with that. Maybe I will try to implement it at a later time.

Final results with live demo

The live demo page can be found HERE. Take a look at it!

Below are some screenshots.

References

[1]: https://www.nrk.no/urix/cyberangrep-mot-europeiske-flyplassar-1.17578597

[2]: https://www.nrk.no/vestland/flere-hundre-passasjerer-havnet-i-bergen-etter-droneobservasjoner-1.17582173

In 2017 I participated, together with other three students from my high school — Daniele Gottardini, Alessandro Foradori, and Loris Gjini — to the international RoboCup JR competition which was held in Nagoya — Japan.

The motivation behind the competition was the simulation of an autonomous rescue effort in an unknown area which is considered too dangerous for human intervention. The rescue party (the robot) needs to be able to navigate the environment avoiding dangerous areas, navigating obstacles, searching for victims, and either rescuing the victims or dispensing rescue kits to them when found.

The Rescue competitions were divided into two categories, for which every team is tasked to build from scratch an autonomous robot able to perform a certain number of actions. In Rescue Line the robot needs to follow a line, navigating intersections and obstacles, and ultimately move the victims to a safe location. In Rescue Maze the robot needs to explore a maze, avoid forbidden areas, navigate obstacles, and dispense rescue kits to the victims.

Background

While in high school I joined several extracurricular activities, among which my favorite one was probably the school's robotics club — a bunch of nerds hanging out once a week for a few hours, playing around with electronic components, 3D printing, and programming. The whole activity was organized under the supervision of Andrea Cristofori, a passionate lab technician who organized the whole thing and taking care of the "adult stuff" while enabling us to grow in an inspiring and stimulating environment.

The activities revolved around several projects, depending on the individual interests and needs of the participants. Some wanted to build small devices to automate repetitive tasks, others wanted to build their own drone from scratch, and some just wanted to tear down everyday consumer electronics devices to deeply understand their inner mechanisms. The main focus of the club was however the RoboCup JR Italia competition: a national competition taking place in the month of April or May each year, where teams from all around Italy meet up to compete in who is most capable in building an autonomous robot under a specific set of rules and constraints. The main prize is admission to the international level of the competition, and the honour to represent the country on the international stage.

During the school year we then devoted most of our efforts to designing and building a robot for the competition, learning valuable skills in the fields of 3D design and 3D printing, electronics, coding, and teamwork.

In the school year 2016–2017 we probably bit off more than we could chew in terms of ambition and decided to redesign the robot from scratch, leveraging experience from previous years. We sat down to brainstorm the solutions and design choices we wanted in our new build and designed the first iteration of what we eventually competed with at the national level.

The final result had to be a fully autonomous robot able to explore and map a maze, and ultimately find and "rescue" the victims. In the 2017 edition the maze was made of 30 cm × 30 cm tiles with potential walls on the sides. The floor surface was not smooth and could contain obstacles, bumpers, ramps, and small steps that the robot needed to navigate, making solid mechanics essential. The victims were located on the walls and were represented by one of two different features: either a heated pad that the robot needed to sense using a heat sensor, or a letter printed on the wall that needed to be recognized using a camera or some other "vision sensor".

Our robot

During our initial brainstorming we came up with many needs and wants, among which:

• Linux-based project rather than microcontroller-based
• Efficient maze-exploring algorithms (Dijkstra's, BFS, A*, …)
• Custom diagnostic and monitoring tools with GUI
• Modular design with custom PCBs
• 3D printed chassis with mechanical suspensions

Let me go through these points one by one.

During the previous years we had experienced building robots based on Arduino, a simple open-source single-board microcontroller which can be programmed with its own programming language, which was close enough to C++ to make the learning curve not so steep, as C/C++ was part of the ordinary curriculum at our school. Arduino is an extremely cheap board, especially if using a Chinese knock-off version, which can take quite some beating without frying. It was perfect for learning the basics, but it had also many limitations. The biggest limitation, which we couldn't work past, was memory. It simply did not come with enough onboard memory to store the information of the maze and running our search algorithms. We discussed several solutions, among which using an SD card to store and retrieve bigger chunks of memory, but ultimately decided to just go for another board.

The popular Raspberry Pi board was very appealing, but it also came with its own set of limitations — notably the lack of real-time capabilities we needed to control some sensors and actuators. Looking back, we probably could have made it work by delegating the real-time tasks to an Arduino-based board, but at the time our eyes hovered over the BeagleBone Black boards: Linux-based boards with onboard Programmable Real-time Units (PRUs). Exactly what we needed.

Now that we had hardware capable enough to store all the information acquired about the maze in an appropriate data structure, we had to design our search-and-rescue algorithm. Ultimately, we opted for a simple algorithm that mixed a greedy approach with Dijkstra's algorithm. We represented the maze as a graph whose nodes are the Cartesian product of maze cells and the robot's possible states. Edges correspond to actions and are weighted by the time required to execute the movement and by the risk of getting stuck. Planning a path from one cell to another therefore meant running Dijkstra's algorithm to find the sequence of movements that minimized time and risk.

This was easier said than done. Actually, after ironing out the bugs, implementing the algorithm was straightforward. In practice, however, running the algorithm based on our sensor data proved challenging due to varying sensitivity ranges and faulty readings. That required tweaking the graph weights and implementing a diagnostic tool to understand the fundamental issues.

On the physical design of the robot, Alessandro pushed really hard for a base with suspensions. Inspired by the design patterns on older farming equipment, he designed a pivoting system which required minimal maintenance and extra components. This design choice worked surprisingly well, and contributed in large part to the ability of the robot to navigate bumpers and debris without complicated software routines.

To acquire the information coming from the sensors, logging, and diagnostics, we based our software on the Robot Operating System (ROS), which provided a plethora of tools specifically designed for robotics. We ended up using ROS only up to a small fraction of its full potential — the learning curve was steep and we were on a time crunch — but it proved extremely useful for handling sensor data and the communication between modules using the publisher/subscriber architecture. We implemented the debugging/diagnostic tool in Python, tapping into ROS's architecture, and built the GUI using the pygame library.

The computer-vision pipeline itself ran on the Raspberry Pi: the Pi handled camera capture and image processing (OpenCV) and sent recognition results to the BeagleBone Black over a simple serial link. We evaluated using a CNN approach, but ultimately opted for a lightweight preprocessing + k-nearest neighbors (KNN) classifier because it required far less training data and was easier to adapt to the real competition arenas for which we didn't have representative training examples.

To satisfy the requirement of modularity we decided to learn how to design and prototype PCBs using chemical etching. The process started with a blank copper-clad board and involved printing the PCB design with a laser printer onto regular paper and heat-transferring the toner lines onto the copper board. We then used an etching chemical such as ferric chloride to remove the excess copper not covered by the toner. The last step involved using acetone to remove the residual toner, leaving a clean finished board.

The specific components that were used for the robot were the following:

The main upgrade for which we were most excited was the use of Time-of-Flight (ToF) distance sensors. A ToF sensor measures how long it takes for an emitted infrared laser pulse to reflect back from a target, giving much more precise distance readings compared to an HC-SR04 ultrasonic distance sensor. It features two modes: a single-shot mode, which produces a measurement on demand, and a continuous mode, which measures the distance at regular intervals (commonly on the order of 100 ms).

As I mentioned, this turned out to be more than we could chew. Or more precisely — we managed to build the robot in time for the competition, but the amount of testing that we managed to perform before the competition was minimal. This in turn caused many bugs to be left in the final product.

The national competition in Foligno and the European competition in Montesilvano

The 2017 national competition was organized in the town of Foligno.

I will cut this short: we did not win this competition. The lack of testing showed itself clearly, and specifically in the form of sensors issues.

The VL53L0X Time-of-Flight distance sensors, in which we had high expectations, ended up failing us. It was not the sensors themselves but rather the high-level library we used to manage them. That library — the only high-level Python library available at the time — could only read the sensors in single-shot mode using a blocking procedure. The BeagleBone's I2C interface therefore could not handle multiple readings in parallel, and each reading was slow. Okay — each reading was only a few hundred milliseconds, but because we had 12 sensors in total the delay became critical.

Although this was not the only bug, it was certainly the main one. During the competition days we mitigated it by reducing the number of active sensors while the robot was moving and by prioritizing those directed toward the front. This, however, reduced precision and left the robot overall slow-moving.

Ultimately, we did not perform too badly at the competition. But the early rounds impacted the overall score, and ultimately we did not make it to the podium.

A new occasion presented itself in the form of the European competition in Montesilvano (Pescara). This was a European-level competition (SuperRegional competition) which served as a middle-ground between the regional/national competitions and the main international one.

With one extra month to mitigate the issues we faced, we greatly improved on the leaderboard, finishing in second place — just behind the Croatian team, which had already qualified for the international level from their national competition (and which — spoiler — went on to win the world title in Japan).

Unfortunately, the European competition did not grant automatic qualification to the international level, but only on the condition that any spot became available due to excess capacity of the international venue, or any of the other teams dropped out.

For the month following the Montesilvano competition we had intense correspondence with the international organization to see if a spot would become available, and eventually we received positive feedback.

It was now time to prepare for the next step: Japan.

The international competition in Nagoya, Japan

Excited at the prospect of competing in Japan and representing Italy on the international stage (together with the other Italian team from Schio, which had qualified in Foligno), we started working again on the robot.

Only two obstacles stood between us and the trip. 2017 was our graduation year, and finals took place in June and early July. As soon as the exams were over, the school would close for the summer.

There was no way around the first issue: we had to split our time between graduation and the robot until the end of the finals. After the school shut down we moved into my parents' house in Strigno and brought with us half of the lab.

In Strigno we spent a few very intense weeks: on the one hand upgrading the hardware and software, ironing out bugs and performing as many test rounds as possible; on the other hand seeking sponsors to cover the participation fees and travel costs. After all, a trip to Japan did not come cheap, especially in summer, and the school had very little disposable budget for this type of activity following many years of cuts in public funding.

Over the summer we managed to find several generous local companies whose contributions allowed us to go to Japan. In no particular order these were:

• Castelpietra S.r.l. — specializing in measurement tools in the automotive industry;
• Polo meccatronica — technology hub in Rovereto;
• Ecoopera — waste management solutions;
• TrentinoSviluppo — local agency for innovation, business, and territorial development for the Trentino province;
• Filippi — a family-run confectionery shop in Trento;
• Dr Schär — leader in production of gluten-free foods and snacks;
• Rotary Club Trento — the regional division of the Rotary Club International.

The competition rounds were split among two days for the main competition, with an extra day for the "SuperTeam": two teams from different countries were randomly matched in order to coordinate and compete against the other pairs in a new competition that was kept secret until the days of the event. With such short notice, the aim of this new competition was to test the ability to adapt and problem-solve in an extreme time crunch, as well as to work around language and cultural barriers.

During the competition days, technical interviews also took place to award the following additional prizes:

• Best Software Programming
• Best Rescue Engineering Strategy
• Best Innovation
• Best Presentation
• Best Team Spirit

Although our robot had many bugs resolved and the software had become more reliable, we ultimately didn't qualify for the podium and finished around the middle of the leaderboard. Considering this was the international level of the competition, which saw the best teams from all over the world competing for a spot on the podium, this was in no way a trivial achievement.

For the SuperTeam we were paired with a Chinese team and given very little time to coordinate. We started by showing each other the high-level parts of our systems — their sensors and control heuristics and our mapping and path-planning routines — and agreed on a minimal interface so the two stacks could interoperate for the collaboartive run. Thankfully, we had brought with us a couple of bluetooth serial chips that we could use to connect the two robots. Communication was challenging at first (language and cultural differences), so we relied heavily on sketches and Google Translate. The resulting cooperation was imperfect but effective — we managed to place ourselves again around the middle of the leaderboard.

Shortly before the award ceremony, the jury informed us that our team had won the Best Software Programming prize. The award felt especially meaningful to us: the judges explicitly cited our computer vision letter-recognition algorithm and the ROS integration as key reasons for the decision, and we were genuinely delighted and proud to receive it.

Takeaways and considerations

This project left us with lessons that reach far beyond the technical stack. Building a competition robot forced us to make choices every day about what to prioritize, how to split effort, and how to persist when things broke in unexpected ways. Time management proved as important as code: we learned to break large problems into small, testable goals, to schedule focused blocks of work around exams and other obligations, and to accept that shipping imperfect but well-tested features is often better than waiting for perfection.

Teamwork was the engine that made everything possible. Each member brought different strengths — mechanics, electronics, algorithms, or a calm head in a crisis — and trusting one another to own pieces of the project let us move faster than any of us could alone. We learned to communicate more clearly and to ask for help early when in need. When something failed on the field, we debugged together: someone watched logs and tried software patches, another inspected wiring and sensors. Those moments taught us resilience, how to divide responsibility, and how to turn mistakes into learning opportunities.

Finally, competing internationally was a gentle reminder that engineering is also a cultural exchange. In Nagoya we met teams from other countries, each with different approaches, tools, and ways of approaching problems. Conversations over coffee (or charging LiPo batteries) or in the pit area expanded our toolkit and our perspective. Teamwork with the Chinese team in preparation of the Superteam challenge, dealing with a tall language and cultural barrier, was an enriching experience and one of our first true international collaborations.

Many lessons were learned along the way, and although the engineering aspects are the most evident in a project like this, I am not sure they were more valuable or enriching than the lessons in time management, PR and sponsors acquisition, humility, and teamwork.

Acknowledgments

I would like to dedicate this blogpost to two key people in our journey: Andrea Cristofori and Fredrik Löfgren. Andrea was for us a great mentor, who selflessly dedicated a gargantuan amount of time and effort to the school and to us without ever asking for anything in return. Without him there would not have been a robotics club at all. Fredrik was a great judge and organizer, always available and friendly. He supported our participation in the international RoboCup JR competition and promptly helped us with the application process once a spot opened up after the European SuperRegional competition.

Unfortunately, Fredrik tragically passed away in 2024 in an accident involving a bus in Stockholm. He is fondly remembered by all of us.

I have always been drawn to new side projects and hobbies — ways to express ideas and creativity that otherwise are left to sit and seethe in a corner of my mind, desperately calling and begging to be let out.

Since I moved in 2019 from Trento (Italy) to Bergen (Norway), I have picked up many different new hobbies, and gave it a go to several side projects. Sometimes they were motivated by a need — learning to cook Italian dishes after moving abroad, starting to brew beer to have cheap, delicious beer, or studying nutrition and training to start a journey into a healthier life — and other times they were pure curiosity, like trying oil painting à la Bob Ross, photography, or woodworking.

In 2022 I started a PhD in Mathematics at the University of Bergen — which I am now three quarters of the way into completion — which has shifted my perception towards hobbies and free time. Suddenly, anything that I could not justify as having enough usefullness in my life was not as attractive as it once used to be. After all, that's all time I could be dedicating to working on research and writing my PhD thesis, or doing something otherwise useful or necessary. And that corner of my mind — where ideas for side projects live rent-free — started growing overcrowded.

This blog is an attempt to push back — at least partially — against that productivist view. To force myself to embrace projects that are not purpose-driven, and to satisfy the need to share what I care about with the people around me (and with kind strangers on the internet).

The way I work also changed during the PhD. After completing the educational module of my PhD project — which consists of a number of study points acquired through relevant courses — I found the introverted side of my personality taking over. Classes had been an excellent excuse to meet and interact with others — lecturers, students, or fellow PhDs — in a Scandinavian society that is otherwise somewhat tepid socially. The size of my research group — fairly small — and the fact that I most of the time work alone or with my PI did not help. So I intend to poke the comfort bubble around me and let something out.

Ultimately, I am so done with LLM-generated content. Don't get me wrong, I use LLMs regularely in many situations, and for many tasks they deliver and speed up my workflow. But as with everything, there is use and there is abuse, and the enshittification of the web that followed the rise of LLMs now seriously bothers me. Just the other day I was researching a travel destination and was met with dozens of AI-generated, ad-ridden sites and several hour-long "documentaries" that were basically glorified slideshows of images and clips scraped from the web with an AI-generated commentary. A million of these works may be published in the time it takes me to even think about writing a new blogpost, but the web used to be a place where unlimited information and knowledge was available, and now it is just a huge pile of information without any wisdom. I don’t want to pretend I have any great wisdom to offer, but I believe there’s value in sharing original work, however small it may be.

And yes, I have finally decided to learn how to use em dashes. That's not an LLM.

I intend to make a collection of either short or long posts on anything I am doing or working on that I find worth sharing. Probably skewed more towards non-academic topics, to stay true to the main goal of this project. So expecta a lot about cooking and baking, woodworking, beer brewing and similar things, although occasionally something about my actual work might make its way into the blog.

Happy browsing.