Die Steuerung einer selbstgebauten Drohne mit einem Raspberry Pi verbindet Elektronik, Programmierung und Luftfahrttechnik. Der Beitrag erläutert benötigte Komponenten, Aufbau und Verkabelung, Einrichtung von betriebssystem, Libraries und Flugsoftware, Grundlagen der Regelung, Sicherheit und Recht, sowie Tests, Telemetrie und erste autonome Manöver.
Inhalte
- Navio2 oder Pixhawk wählen
- Stromversorgung und ESCs
- ArduPilot auf Raspberry Pi
- PID-Tuning und Flugstabilität
- Telemetrie, Latenz und Funk
Navio2 oder Pixhawk wählen
Navio2 bündelt Flugsteuerung und Companion-Computer auf dem Raspberry Pi: ArduPilot läuft unter linux (häufig mit PREEMPT_RT), Sensorik sitzt direkt auf dem HAT, Telemetrie und Missionslogik teilen sich eine Plattform. Das reduziert Bauteile, gewicht und Latenzen zwischen Bildverarbeitung und Regler, verlangt jedoch sauberes Power-Design, gutes SD‑Karten‑Management und sorgfältige Prozesspriorisierung, damit Echtzeit-Anteile nicht unter Last schwanken. Stärken liegen bei Integration, einfacher Erweiterbarkeit per GPIO/SPI/I2C und schnellen Iterationen in projekten mit Onboard‑KI oder Computer Vision.
| Aspekt | Navio2 | Pixhawk |
|---|---|---|
| Architektur | Linux-basierte FC auf Pi | Dedizierter MCU-FC + companion |
| Echtzeit | Gut, aber lastabhängig | Deterministisch (RTOS) |
| Redundanz | Einzelsensorik | oft duale IMUs, fail-safes |
| Verkabelung | Minimal (HAT) | Mehr kabel, saubere Trennung |
| I/O & Bus | GPIO/SPI/I2C auf Pi | CAN (UAVCAN), PWM, DShot |
| Latenz KI→Regler | Sehr niedrig | Niedrig über MAVLink/CAN |
| Setup-Komplexität | Niedrig-Mittel | Mittel-Hoch |
| Einsatzprofil | Prototyp, Leichtbau, CV | Langzeit, Industrie, BVLOS |
Pixhawk trennt Zuständigkeiten: Ein STM32‑Controller führt den Flugregelkreis mit hoher Deterministik, während der Raspberry Pi als Companion über MAVLink Aufgaben wie Mapping, Objektverfolgung oder Edge‑KI übernimmt. Das erhöht Robustheit durch Redundanz, klare Strompfade, galvanische Trennung und umfangreiche Peripherie (z. B. CAN‑Geräte, externe Magnetometer, Dual‑GPS). Der Preis sind mehr Komponenten, größeres Volumen und zusätzliche Konfiguration. Geeignet, wenn Verfügbarkeit, skalierbarkeit und regulatorische Anforderungen Vorrang vor maximaler Integration haben.
- Priorität Echtzeit/Fail-safes: Vorteil Pixhawk.
- Platz- und Gewichtsbudget: Vorteil Navio2.
- Onboard-KI/Computer Vision: Vorteil Navio2 (direkte Pipeline), Pixhawk solide mit Companion-Link.
- Erweiterungen per CAN und professionelle Peripherie: Vorteil Pixhawk.
- Budget und Teileanzahl: Vorteil Navio2.
- Wartbarkeit/Field-Service: Vorteil Pixhawk durch modulare Trennung.
Stromversorgung und ESCs
Die Energiearchitektur bestimmt Flugzeit, Stabilität und sicherheit. Ein LiPo-Akku (3S/4S) speist die ESCs direkt; der Raspberry Pi benötigt dagegen eine saubere 5‑V‑Schiene. Empfehlenswert ist ein hocheffizienter Step‑Down (BEC) mit ausreichender Reserve (≥3 A) sowie ein LC‑Filter, um Schalt- und Motorrauschen von der Logik zu entkoppeln. Eine Power Distribution Board (PDB) verteilt die Spannung, misst Ströme und vereinfacht die Verkabelung. gemeinsame Masse aller Komponenten bleibt Pflicht, galvanische Trennung nur für Sensorpfade. Kurze, ausreichend dimensionierte Leitungen, robuste Steckverbinder und Überspannungsschutz erhöhen die Zuverlässigkeit.
- Akkuauswahl: 3S/4S je nach Motor-KV; sinnvolles Verhältnis aus Kapazität, C‑Rating und Gewicht.
- BEC/Step‑Down: 5 V / 3-5 A, geringe Restwelligkeit (<50 mV), thermische Reserve.
- Filter & Schutz: LC‑Filter, TVS‑Diode, Sicherung oder polyfuse für die Logikversorgung.
- Verteiler & Stecker: PDB oder AIO; XT60/XT30; passender Leitungsquerschnitt (AWG14-18).
- Masseführung: sternförmig oder niederimpedant; Masseschleifen vermeiden.
- Messung: Strom- und Spannungssensor für Telemetrie/Logging zur verbrauchsprognose.
| Komponente | Empfehlung | Hinweis |
|---|---|---|
| Akku | 4S 1500-2200 mAh | 75-100C für Peaks |
| BEC | 5 V / 3-5 A | <50 mV Ripple |
| PDB | 40-60 A | Stromsensor integriert |
| Filter | LC (100 µH/470 µF) | gegen Motorrauschen |
| Stecker | XT60 | verriegelbar |
| Leitungen | AWG14-18 | kurz halten |
Bei den elektronischen Drehzahlreglern entscheidet die kombination aus Stromrating, Firmware und Signalprotokoll über die Reaktionsfreudigkeit. Moderne Regler mit BLHeli_S/32 unterstützen OneShot, Multishot und DShot. Für Linux-basierte Systeme bietet sich ein PWM‑Treiber (PCA9685) oder ein separater Mikrocontroller als Signalgenerator an,der vom Raspberry Pi über I²C/SPI/UART angesteuert wird; so bleiben Timings deterministisch. Passende Update‑Raten (z.B. 400-600 Hz PWM oder DShot300/600), korrektes Timing und saubere Masseführung verhindern Desyncs. Telemetriefähige ESCs liefern Strom‑, Temperatur‑ und Drehzahldaten, die für Leistungsregelung und Logging genutzt werden können.
- ESC‑Dimensionierung: 20-30 % Stromreserve über der Motor‑Maximalaufnahme einplanen.
- Protokollwahl: DShot bevorzugt (kein Kalibrierbedarf, CRC); ansonsten 400-600 Hz PWM.
- Signalquelle: Hardware‑PWM via PCA9685 oder MCU; Software‑PWM unter Linux vermeiden.
- Kalibrierung & Timing: Endpunkte, Motor‑Timing und Demag‑Einstellungen für sanften Anlauf.
- Spitzenschutz: Regenerative Bremse kann Spannungsspitzen erzeugen; TVS/Anti‑spark vorsehen.
- Thermik: Luftstrom über ESCs sicherstellen; ggf. Wärmeleitpads auf Carbonarme.
ArduPilot auf Raspberry Pi
ArduPilot lässt sich entweder nativ auf einem raspberry Pi betreiben oder als Companion-Computer an einem separaten Autopiloten einsetzen.Der native Ansatz über Sensor-hats wie Navio2 bringt IMU, Barometer und PWM-Ausgänge direkt auf das Board; für deterministisches Timing empfiehlt sich ein PREEMPT_RT-Kernel. Im Companion-Modus wird per MAVLink mit Pixhawk-Hardware kommuniziert, während Planung und Tuning über QGroundControl oder Mission Planner erfolgen.
- Rechner: Raspberry Pi 4/5, 64‑Bit OS (Lite bevorzugt)
- Sensorik: IMU/Baro (HAT) oder externer Autopilot
- Navigation: GPS + Kompass, korrekt entstört
- Energie: Power-Modul mit Spannungs-/Strommessung
- Antrieb: ESCs/Motoren passend zur Zelle
- Verbindung: Telemetrie (Wi‑Fi/UDP, 433/915 MHz) und RC-Empfänger
| Setup | Modus | Erforderlich | Stärken |
|---|---|---|---|
| Navio2 auf Pi | Native | RT-Kernel, GPS/Baro | Kompakt, flexibel |
| Pixhawk + Pi | companion | MAVLink (UART/UDP) | Robuste Sensorik |
| SITL auf Pi | Simulation | Keine Flughardware | Schnelle Tests |
Die Einrichtung umfasst das Aktivieren von I2C/SPI/UART, einen systemd-Dienst für ArduCopter/ArduPlane sowie die Telemetrie-Anbindung. Typische Startparameter definieren serielle Ports, Baudraten und einen UDP-Endpunkt für Bodenstationen; für zuverlässigen Betrieb bewähren sich CPU-Governor performance, isolierte Kerne und logfreundliche Schreibparameter. Kalibrierung (ACCEL/COMPASS/RC),Failsafes und akkurate Frame-/ESC-einstellungen sind Pflicht; Logfiles unterstützen PID-Feinschliff,Vibrationsanalyse und Energie-Monitoring.
- Kernel & Leistung: PREEMPT_RT, Governor „performance”, moderates Log-Rate-Limit
- Schnittstellen: /dev/serial0 für Telemetrie; I2C/SPI in raspi-config aktiv
- Startdienst: arducopter -A udp:192.168.1.50:14550 -C /dev/serial0:57600
- Telemetrie: UDP/TCP zu QGroundControl/Mission Planner; 57600/115200 Baud gängig
- Kalibrierung: ACCEL, COMPASS, RC, Battery Monitor mit korrekten Werten
- Sicherheit: BAT_FS, GCS_FAILSAFE, RTL/LAUNCH-Optionen je nach Mission
PID-Tuning und Flugstabilität
Stabilität entsteht aus präziser Rückkopplung: Die Fluglage wird über IMU‑Sensordaten (Gyro/Accel) erfasst, per Sensorfusion (z. B. Komplementär‑ oder Kalman‑filter) geglättet und in einem PID‑Regelkreis mit dem Sollwert verglichen. Der Proportionalanteil (P) dämpft Abweichungen unmittelbar, der Integralanteil (I) kompensiert dauerhafte Bias (Schwerpunkt‑/Trimmfehler), der Differentialanteil (D) bremst schnelle Änderungen und unterdrückt Oszillation. Auf einem Raspberry Pi zählt eine konsistente Loop‑Rate (ca. 500-1000 Hz) mit geringer Latenz: IMU über SPI, hohe Prozesspriorität, monotone Zeitbasis, Motoransteuerung mit 2-4 kHz Update. Vibrationen werden durch Notch‑ und Lowpass‑Filter entschärft; der D‑Term erhält die stärkste Filterung. Setpoint‑Dämpfung und Anti‑Windup stabilisieren aggressive Manöver und verhindern I‑Sättigung.
| Regleranteil | Wirkung | Zuviel / Zuwenig |
|---|---|---|
| P | direkte Korrektur | Zittern / schwammig |
| I | Fehleraufsummierung | Pumpen / Drift |
| D | Änderungsbremse | Rauschen/Hitze / Überschwingen |
| FF | Setpoint‑Durchgriff | ruckelig / verzögert |
- Saubere Sensorik: Propeller auswuchten,Flight‑Controller weich lagern,IMU per SPI mit hoher Abtastrate; Gyro‑Noise durch Notch-/Lowpass‑Filter und starren Rahmen minimieren.
- Deterministischer Regelkreis: RT‑Priorität, isolierter CPU‑Kern, monotone taktquelle; PID‑Loop 500-1000 Hz, Motor‑Update 2-4 kHz.
- Konservative Startwerte: P moderat, D niedrig, I ausreichend für Schwebeflug; Anpassungen in 5-10%‑Schritten mit Temperatur‑ und Sättigungsprüfung.
- Validierung: Loggen von Gyro, Motorsignal, Setpoint; Bewertung von Überschwingen (<10%), Einschwingzeit und Motorsättigung; Anti‑Windup bei anhaltender Sättigung aktiv.
- Sicherheit: Prop‑Guards, Tether, niedrige Spannung/kleine Props für frühe Tests; Notabschaltung verifizieren.
Ein robuster Workflow beginnt mit Filter‑ und Loop‑Konfiguration, gefolgt von P‑Anhebung bis kurz vor sichtbarem Zittern, anschließender D‑Erhöhung zur Reduktion von Überschwingen und I‑Feinabstimmung gegen langsame Drift. Bei Manövern mit steilen Setpoints sorgt Feedforward für knackige Reaktion ohne überhöhten P‑bedarf; harte Rucke werden mit Setpoint‑Dämpfung geglättet.Stabilität zeigt sich in ruhigen Motorgeräuschen, moderaten Temperaturen, reproduzierbaren log‑Kurven und geringer latenz in der Kommandokette vom Raspberry Pi zur Motorregelung. Treten Oszillationen in bestimmten Drehzahlbändern auf, hilft ein schmaler Notch auf der entsprechenden Frequenz, während die D‑Filterung so leicht wie möglich gehalten wird, um Phasenverzug gering zu halten.
Telemetrie, Latenz und funk
Telemetrie bildet das Nervensystem zwischen Flugsteuerung und Bodenstation: Ein Raspberry Pi kann als MAVLink-Bridge die FCU über UART anbinden und die Daten via UDP über Wi‑Fi oder LTE weiterreichen, parallel lokal protokollieren und Zustände verdichten. Aussagekräftige Timestamps, konstante Heartbeat-Signale und wohldefinierte Nachrichtenraten senken Jitter und verhindern Pufferüberläufe. Sicherheitsrelevant sind MAVLink2-Signing, Link-Monitoring sowie eventbasierte Meldungen bei Zustandswechseln, während bandintensive Rohdaten (z. B. HIGHRES_IMU) lokal gehalten oder stark komprimiert werden.
- HEARTBEAT: 1 Hz
- ATTITUDE: 20-50 Hz
- GPS_RAW_INT: 5-10 Hz
- BATTERY_STATUS: 1-2 Hz
- RC_CHANNELS/OVERRIDE: 10-20 Hz
- HIGHRES_IMU: 50-100 Hz (lokal/Log)
- STATUSTEXT/EVENT: bei Änderung
| Linktyp | Band | Netto-Rate | Einweg-Latenz | Reichweite | Besonderheit |
|---|---|---|---|---|---|
| wi‑Fi 802.11ac | 5 GHz | 50-200 Mbit/s | 5-20 ms | 50-300 m LoS | hohe Bandbreite, störanfällig |
| Wi‑Fi 802.11n | 2,4 GHz | 10-50 Mbit/s | 10-30 ms | 100-500 m los | Bessere Durchdringung |
| SiK-Telemetrie | 868/915 MHz | 32-250 kbit/s | 40-120 ms | 1-5 km | Robuste FEC, geringe Rate |
| LoRa | 868/915 MHz | 0,3-37 kbit/s | 150-500 ms | 2-15 km | Extrem robust, sehr hohe Latenz |
| LTE/4G | Mobilfunk | 5-50 mbit/s | 30-100 ms | Weiträumig | NAT/VPN erforderlich |
Latenz bestimmt die Steuerpräzision: Entscheidend ist das Ende-zu-Ende-Budget vom FCU-Zeitstempel bis zur Bestätigung am Boden und zurück.Kommandopfad und Telemetrie/Video profitieren von getrennten Queues und priorisierten Klassen, um jitter zu minimieren. Eine robuste Funkplanung (Bandwahl, Kanalbreite, Antennendiversität) senkt Paketverluste; konsistente Zeitsynchronisation (PTP/NTP) ermöglicht saubere Log-Korrelation und schnelle Diagnosen.Fallback-Strategien zwischen Wi‑Fi und LTE halten die Verbindung stabil, während dynamische Ratenbegrenzung Überlast verhindert.
- Transport: UDP für telemetrie, TCP nur für zuverlässige Bulk-Daten
- QoS: WMM/EDCA, DSCP-Markierung, Priorisierung von RC/MAVLink
- Funk: 20 MHz Kanalbreite, feste MCS, Power-Save off, getrennte Bänder zu RC
- fehlertoleranz: Moderate FEC/ARQ, kleine Pakete, kurze Timeouts
- System: CPU-Affinität, IRQ-Balancing, Ringpuffer-tuning auf dem Raspberry Pi
- Redundanz: Automatisches Handover Wi‑Fi ↔ LTE, Health-Checks, Heartbeat-Watchdog
Welche Komponenten werden benötigt?
Benötigt werden Raspberry Pi, Brushless-Motoren mit ESCs, Propeller und Rahmen, eine IMU, optional GPS/Barometer, ein LiPo mit BEC oder PDB, Funkanbindung per WLAN, RC oder Telemetrie sowie Schrauben, Dämpfer, Kabel und bei Bedarf eine Kamera.
Wie übernimmt der Raspberry Pi die Flugsteuerung?
Der Raspberry Pi verarbeitet IMU- und ggf. GPS-Daten,berechnet Stellgrößen und gibt sie an Antriebe oder Flugcontroller. Über PWM/DSHOT oder MAVLink werden Befehle übertragen. Eingaben kommen via RC, Gamepad oder Netzwerk; telemetrie berichtet Zustände.
Welche Software eignet sich für Entwicklung und Kontrolle?
Bewährte Software umfasst Raspberry Pi OS, ArduPilot oder PX4 (etwa mit Navio2-HAT), dazu MAVLink, mavproxy oder QGroundControl. Für eigene Logik eignen sich Python, ROS 2 und MAVSDK/DroneKit. logging, Kalibrier-Tools und OTA-Updates erleichtern den Betrieb.
Wie lässt sich eine sichere Stromversorgung und Verkabelung erreichen?
Eine PDB oder ein BEC versorgt den Pi stabil mit 5 V, während der LiPo Motoren speist. Ausreichende Kabelquerschnitte, Sicherungen, EMV-Filter und feste Steckverbindungen erhöhen Zuverlässigkeit. Propellerschutz, Kill‑Switch und Tests ohne Props minimieren Risiken.
Welche rechtlichen Vorgaben und Tests sind relevant?
Zu beachten sind EU-Drohnenregeln (Offene Kategorie, Gewichtsklassen), registrierung, eID/Kennung, Versicherung und Flugverbotszonen. Vor Erstflug: Kalibrierung, Reichweiten- und failsafe-Tests, Logprüfung und mehrere kontrollierte Schwebeflugproben.