Six Teams, Four Difficulty Levels and Nobody Dropping Out: How the AI SkyRun Hackathon Ended

First place — team “Povitria”

This team won not on speed, but on point of view.

First, they implemented an unusual form of BFS navigation, overlaying a map rotated by 45 degrees. Breadth-first search is an algorithm everybody knows and nobody finds interesting; it is a workhorse, not a thoroughbred. But a grid rotated at an angle changes the very notion of which cells are neighbours, and with it the geometry of the route you find. It is the kind of solution that looks obvious exactly one moment after somebody else says it out loud.

Second — and this is what earned them the most in the presentation round — they dropped the rule that “the destination is fixed”. In other words, they rewrote the problem statement. Instead of a craft going from point A to point B, they built a cartographer: a system whose main goal is to work out how the surrounding space is arranged as fast as possible. Not to arrive, but to find out. That is an entirely different problem, with a different reward function and a different criterion of success, and it is much closer to what research autonomous systems actually do: surveying terrain, building maps, monitoring areas that are hard for a human to reach.

Third, they were the only team to train the Tier B map up to level L8. That is pure engineering stamina: taking training to the eighth level of manoeuvring difficulty means watching everything break many times over and going back to the reward function each time instead of lowering the bar.

Three separate claims — on algorithmic inventiveness, on reframing the problem, and on seeing it through to a result. The ranking here caused no arguments.

Second place — “NSK”

Young men who put real geometry into practice. That phrasing deserves unpacking. Most solutions at hackathons like this live at the level of “let us tune the coefficients until it flies” — and that is a normal, workable path. “NSK” went another way: they built the motion out of geometric reasoning rather than out of tuning. When you understand the space you are working in, you need far fewer lucky accidents.

A side effect of that approach: they collected more achievements than anyone else over the whole hackathon. Not because they were chasing ticks, but because a careful geometric foundation produces a solution that survives a change of conditions well: what works through understanding rather than through fitting usually works on the neighbouring task too.

Third place — “Kraken AI” and “KKD”

We split third place between two teams, and that was an honest split rather than diplomacy. Both reached the finals with working agents, both went beyond the original problem statement, both defended their work confidently. Separating them artificially into third and fourth would have meant inventing a difference that was not there in the results.

A separate story I am genuinely grateful for

One of the teams found a bug in our own environment: when the craft switched to powered-flight mode, its collision disappeared for a few seconds. During that window the world stopped being solid, and the craft could calmly pass straight through an obstacle.

From a participant’s point of view that is a gift: here is a window in which physics does not object. From an organiser’s point of view it is exactly the situation where the simulation you assembled so carefully turns out to be slightly less airtight than you had believed for two weeks straight.

But something else matters more: to find a hole like that, you first have to stop trusting the environment. That is a grown-up engineering habit — checking not only your own solution, but the conditions it is being tested under. Most people walk past anomalies like this and put them down to a mistake of their own. The hackathon participants did not walk past. We have logged the bug, of course. Next time the collision will hold.

The jury consisted of two organisers: Illia Nakonechnyi and Danyil Bohynskyi. They judged on the whole package: whether the solution worked, the depth of the technical approach, going beyond the problem as set, and the quality of the final presentation.

That last criterion turned out to matter more than the participants themselves expected. Being able to explain in 5 minutes why your reward function is built the way it is — that is half of engineering work. The other half is making it fly at the same time.

We publish task breakdowns, technical details of the solutions and announcements of the next intakes in the “Vstupnyk FMF” Telegram channel.

📩 Questions, partnerships, participation: drlaispace@gmail.com