A2-Prüfung

SDK und Autonomie: Regeln schlagen Code

SDKs ermöglichen Waypoints, automatische Aufnahmen und Datenerfassung — DJI Mobile SDK, Parrot, PX4, ArduPilot. EASA verbietet Programmierung nicht — der Betreiber bleibt verantwortlich. Autonomie ersetzt weder A1/A3 noch A2/STS; Software muss Geozonen und Höhenlimits respektieren.

A2STS editorial12 min read

Contents

1. Grundlagen

Typische Stacks: Hersteller-Mobile-SDKs und Open Source. Automatisierung ändert nicht die EASA-Kategorie allein — Missionsprofil entscheidet.

Geofence und nationale Geodaten (dipul) in Planungstools einbinden, wo APIs verfügbar.

2. Einsatzszenarien

Landwirtschaft: automatische Feldscans. Inspektion: wiederholbare Orbits. Schule: Python/JS am Simulator vor Live-Flug.

Gewerblich oft Specific, wenn BVLOS oder Automation Open-Grenzen überschreitet — SORA und LBA-Genehmigung.

3. Failsafe und Human Factors

Code braucht RTH, Geofence, Low-Battery-Aktionen. Test in Simulation und kleinem Areal. Firmware/SDK-Version im Wartungslog.

Pilot muss jederzeit übernehmen können — EASA Human-Factors-Grundsatz.

4. Lernpfad

Hersteller-Doku und Simulator zuerst. A1/A3-Theorie auf A2STS vor Produktions-Autonomie.

Kommerzielle Produkte: CE (C-Klasse) und Versicherung mitdenken.

Frequently asked questions

Anderes Zeugnis für SDK-Flug?
Nein automatisch — Kategorie und Grenzen zählen. VLOS Open vs. BVLOS Specific.
Einstieg für Anfänger?
Hersteller-Simulator + offizielles Mobile SDK. PX4 für Studierende mit ROS/Python.
Darf SDK dipul umgehen?
Nein — Software muss behördliche Geozonen respektieren; Umgehung ist kein legaler Betrieb.

Authority & sources

A2STS Redaktion · Reviewed by: EASA UAS-Lehrplan angepasst

Drohnen SDK Programmierung: LBA Regeln | A2STS