Dates

• Official time zone: All official times are in London time (Europe/London).

• Start: Monday, 2 February 2026, 09:00 (London time).

• End / submission deadline: Monday, 23 February 2026, 17:00 (London time). Submissions must be uploaded to Devpost by this time to be eligible for judging.

• Judging window: Judging will take place after submissions close. Any announcements will be posted via Devpost Updates.

• Work window / pre-work: You may use existing public libraries, frameworks, and tools. However, the core work submitted for AeroHack (mission logic, planning approach, integration, validation, and results) must be completed within the official hackathon window listed above.

Eligibility

• Age requirement: Participants must be 17 years or older at the time of entry.

• Language requirement: All communication and submission materials must be in English (Devpost page, README, report, comments). Participants must be able to collaborate in English at a strong professional level (recommended: C1 or equivalent).

• Location: AeroHack is open to participants worldwide, subject to local laws and these rules.

• Teams: Solo and team entries are allowed. A participant may only be part of one team submission.

• Organizer rights: The organizer reserves the right to remove or disqualify participants or submissions for rule violations, academic dishonesty, plagiarism, harassment, or disruptive behavior, or for attempts to manipulate scoring/judging.

Project and Submission Requirements

• Challenge scope: Each team must build a single, unified mission planning + simulation framework that demonstrates both:

  1. Aircraft mission planning + simulation (UAV/fixed-wing): constrained mission planning under wind, endurance/energy limits, maneuver limits (turn/bank/climb or equivalent), and geofencing/no-fly zones.

  2. Spacecraft mission planning (CubeSat-style LEO ops): a 7-day observation + downlink schedule under orbit/visibility constraints and simplified pointing/power (or equivalent proxy) constraints.

• Unified approach requirement: The aircraft and spacecraft components must share a common planning concept (constraints + objective + planning method). Submissions that are effectively two unrelated projects may be scored lower.

• Original work: Submissions must substantially represent work completed during the AeroHack window, except for standard third-party libraries/frameworks.

• Required submission items (no video required):

  1. Runnable code (repo or downloadable package) with clear setup instructions and a single end-to-end run path that generates outputs for both aircraft and spacecraft modules.

  2. Reproducible run steps (exact install/run commands, expected outputs, file locations).

  3. Results bundle containing plots/metrics/outputs demonstrating both aircraft and spacecraft results (e.g., route/schedule outputs, constraint checks, performance metrics).

  4. Technical report PDF (4–8 pages) describing models/assumptions, constraints/objectives, planning method, validation, results, limitations.

  5. Validation evidence for both modules (e.g., Monte-Carlo runs, stress tests, baseline comparisons, unit/sanity checks).

  6. Devpost project page summary including links to code/report and key metrics.

• Reproducibility standard: Judges must be able to reproduce key outputs from your instructions. Submissions that cannot be reproduced may receive lower scores or may not be judged.

• One submission per team: Each team may submit one project on Devpost. Duplicate, spam, or plagiarized submissions may be disqualified.

Prizes

AeroHack offers no cash prizes and no guaranteed material rewards.

Instead, the event is designed as a high-signal technical selection challenge. Outstanding submissions may receive:

• Public recognition on the AeroHack Devpost page (Featured / Finalist / Winner listings)

• An invitation to a follow-on build after the hackathon (optional, by mutual agreement) to continue developing an advanced aerospace project with real commercial potential

• Optional references (e.g., a written performance summary or LinkedIn recommendation) for exceptional contributors, based strictly on demonstrated work and conduct

Participation in any post-hackathon collaboration is not guaranteed and is offered at the organizer’s discretion based on submission quality, teamwork, and reliability.

Judging Criteria and Winner Selection

Submissions will be evaluated by the organizer (and any additional judges listed on the hackathon page) using a technical rubric focused on correctness, depth, and reproducibility.

To be considered for judging, a submission must:

• Run end-to-end using the provided instructions

• Include outputs for both the aircraft and spacecraft modules

• Include the required report, results bundle, and reproducibility steps

1. Correctness & Feasibility (40 pts)

   • Constraints are respected (no-fly zones, endurance/energy, scheduling feasibility, etc.)

   • Outputs are internally consistent and technically credible

   • Clear constraint-check summaries are provided

2. Robustness & Validation (20 pts)

   • Evidence of robustness (e.g., Monte-Carlo runs, varied scenarios)

   • Meaningful validation, sanity checks, or baseline comparisons

   • Transparent reporting of failure cases and limitations

3. Technical Depth (20 pts)

   • Sound modelling assumptions and methods

   • Strong planning/optimisation approach (solver/search/heuristics with justification)

   • Systems-level thinking across aircraft + spacecraft

4. Reproducibility & Engineering Quality (20 pts)

   • Clear run instructions and dependency management

   • Clean repo structure, readable code, and documented design choices

   • Results can be reproduced by judges

• Projects with missing requirements or non-reproducible results may be scored lower or excluded from finalist selection.

• The organizer will select Winners/Finalists based on the highest overall scores and may also recognize special categories (e.g., “Best Validation”, “Best Systems Design”) at their discretion.

• In case of ties, priority will be given to: (1) feasibility/correctness, (2) robustness/validation, then (3) technical depth.