Ausgangslage
Ein Flugkarussell unterscheidet sich von einer Achterbahn in fast jeder Hinsicht: Die Gondeln bewegen sich relativ frei, jede Fahrt hat einen anderen Verlauf, und das Erlebnis lebt von der Perspektive der einzelnen Fahrgäste. Klassische On-Ride-Kameras (eine Kamera am Ein-/Ausfahrtsbereich) bilden das nicht ab.
Der Wunsch von Plutos: pro Gondel ein eigenes Videoerlebnis aus mehreren Kameras gleichzeitig. Das stellt drei harte technische Anforderungen: zuverlässige Auslösung exakt bei Fahrtbeginn, lokale Aufnahme vieler Kameras pro Gondel in Echtzeit, und ein robuster Transfer der Aufnahmen an einen Server am Boden – unter realen Park-Bedingungen mit Vibration, Witterung und Personal, das keine SSH-Sessions debuggen kann.
Lösung
Wir haben das System Schicht für Schicht aufgebaut.
- Eigene Mainboards für Raspberry Pi Compute Modules. Auf den Compute Modules sitzt das Rechenzentrum jeder Gondel; das eigens entwickelte Mainboard verbindet Kameras, Sensorik und Stromversorgung in einem Formfaktor, der in die Gondel passt und Schock-/Vibrationsanforderungen standhält.
- Acht Kameras pro Gondel über ein Mini-Netzwerk. Pro Gondel landet die Bild-/Videoerfassung an einem zentralen Pi, der die Aufnahmen synchronisiert lokal puffert. Beschleunigungssensoren liefern zusätzlich Bewegungsdaten für spätere Auswertungen.
- Auslösung über Arduino an der SPS. Der Arduino liest das Startsignal direkt aus der SPS des Fahrgeschäfts, interpretiert es und gibt es an die Raspberry-Pi-Module weiter. Damit ist die Aufnahme nicht „ungefähr richtig", sondern auf das Steuerungs-Event des Fahrgeschäfts gekoppelt.
- Transfer und Betrieb. Sobald die Gondel zum Stillstand kommt, beginnt der strukturierte Transfer zum Server am Boden. Dashboards zeigen pro Gondel den Aufnahme- und Transferstatus, damit Betreiber:innen ohne Linux-Kenntnisse sehen, dass das System läuft.
Ergebnis
Aus „eine coole Idee fürs Fahrgeschäft" wurde ein verteiltes Echtzeit-Video-System, das innerhalb einer Minute vom Auslösen bis zum fertigen Video pro Gondel kommt. Komplexe Hardware-Integration, ein Park-Umfeld voller realer Störquellen, und am Ende ein System, das den Betrieb der Attraktion nicht stört, sondern um eine ganze Erlebnis-Ebene erweitert.
Warum diese Aufgabe zu uns passt
Hier hilft kein Cloud-First-Stack, kein Standard-SaaS und keine Power-Point-Architektur. Hier braucht es Leute, die zwischen SPS-Programmierung, Compute-Module-Pinouts, Python-Echtzeit-Code und Park-Betriebsalltag pendeln können – und die ein System bauen, das auch nach drei Saisons noch läuft, ohne dass das Park-Personal IT studieren muss.