Flying Car Simulation Entry

Context

The TEKNOFEST Flying Car Simulation Competition is decided inside a simulation environment that every team is given. There is no airframe to build and no flight line to travel to. What is submitted is a design and its control logic, and what is scored is how that vehicle behaves when the simulator flies it through a defined mission.

This is a different kind of engineering work from building hardware, and in some ways a stricter one. Hardware hides mistakes behind tolerance and luck. A simulator does not. It runs the same mission the same way every time, so a design either meets the requirement or it does not, and the reason is recoverable from the run.

Approach

The work was organised around the fact that the environment is fixed and shared. Nobody can improve their result by having a better test rig, so the only variables that matter are the vehicle definition and the logic that flies it.

That leads to a straightforward loop: define the vehicle, fly the mission, look at what the mission cost in stability, control effort and time, change one thing, fly it again. Because the simulator is deterministic, a change can be attributed to its cause with far more confidence than in a physical test — which makes it worth running many more iterations than a hardware project could afford.

What I built

A competition entry consisting of the vehicle configuration and the control and mission logic that operates it inside the provided simulation, together with the analysis used to compare one iteration against another.

The most useful discipline was refusing to accept a good run as evidence. A single successful mission proves that the vehicle can complete it once. What the competition rewards is a vehicle that completes it under the conditions the simulator will actually impose, which means the comparison has to be made across runs rather than on a best case.

The entry reached the finals of the TEKNOFEST Flying Car Simulation Competition.

What I learned

Simulation taught me to be honest about the difference between a model and a vehicle. Everything I concluded is a conclusion about the model, and the model is only as good as the assumptions inside it. Keeping that boundary explicit — this is a result, this is an artefact of the environment — is a skill in itself.

It also taught me how much of flight control is about margins rather than peaks. The interesting question was rarely whether a manoeuvre was possible. It was how much room was left when it went wrong.

Note: this entry is a structural placeholder. The competition record is accurate; the technical write-up still needs the owner’s own detail.