MUTEC · Papierflug — Stand 10.10.2026

Inbetriebnahme

Frontend: https://www.tinetronics.de/mutec/flight/controller.html, nur über Ticket-Menü auswählen. Electron: https://www.tinetronics.de/mutec/flight/display.html#displayKey=BESTEHENDER_DISPLAY_KEY Der vorhandene Anzeigeschlüssel wird wiederverwendet. Nicht öffentlich weitergeben.

Eine laufende MUTEC-Anwendung mit „Zur Auswahl“ verlassen.
Auf dem VPS als root ausführen:

  bash /home/clawtronics/mutec-flight-update/apply-flight-update.sh

Die abschließende Statusmeldung muss flight:true und returnToTrailer:true enthalten.
Electron neu starten, damit der ergänzte Reiter flight aus views.json geladen wird.
MUTEC-Menü auf dem Smartphone neu laden. Mit einem gültigen Ticket „Papierflug“ auswählen.
Bildschirm nach oben halten; Fußende/Ladebuchse nach vorn. „Sensoren aktivieren“ drücken und ggf. die Browser-Freigabe bestätigen. Die Haltung kalibrieren, dann den Flug starten.

Der Menüpunkt wird erst sichtbar, wenn GET /mutec-control-api/capabilities die Unterstützung bestätigt. Der bisherige Relay bleibt bis zur Installation nutzbar.

Bedienung

Links/rechts kippen lenkt; das Fußende heben lässt den Flieger steigen. Ein Kontrollkästchen kann die Höhenachse umkehren. Kalibrierung während des Flugs ist möglich. Zwei Grad Totzone, voller Ausschlag ab ungefähr 25 Grad, geglättete Eingaben. Geräteachsen bleiben an die Hardware gebunden; eine Browser-Drehung ändert nicht die Bedeutung des Ladebuchsen-Endes.

Falls Sensorfreigabe verweigert wird oder keine Messwerte eintreffen, „Mit Touch steuern“ öffnen. Den Punkt bewegen und loslassen zum Zentrieren. iOS fordert die Bewegungsfreigabe direkt beim Tastendruck an; HTTPS ist erforderlich. Die tatsächliche Richtung und Empfindlichkeit auf iPhone/Android bitte mit den vorgesehenen Geräten prüfen.

Jeder Flug dauert 60 aktive Sekunden. Ringtreffer: 100 Punkte; fortlaufende Treffer geben bis zu 100 Bonuspunkte pro Ring. Fehlschüsse setzen die Serie zurück. „Neu starten“ beginnt einen neuen Flug. Zeit und Punkte werden in Electron berechnet und zum Smartphone zurückgemeldet. Keine dauerhafte Bestenliste und keine Speicherung der Sensormessungen.

Bei Verbindungstrennung, fehlenden Eingaben länger als eine Sekunde, verborgenem Smartphone-Tab oder fehlenden Sensorwerten pausiert das Spiel. Station-IDLE oder ein abgelaufenes Ticket beendet die Steuerberechtigung. Nach einer vollständig neu geladenen Steuerseite beginnt ein neuer Lauf. „Zur Auswahl“ sendet wie bisher 50-Trailer und meldet die Station ab.

Infrastruktur und Modularität

Keine Änderungen an megbes-external/megbes-internal. Unser separater Relay erhält vier aktualisierte Dateien: access.js, protocol.js, server.js, test/relay.test.js. Die Installation sichert diese vier Dateien und stellt sie bei Fehlern wieder her. Umgebungsdatei, DISPLAY_KEY, systemd-Konfiguration und npm-Abhängigkeiten bleiben bestehen. Es sind keine neuen nginx-Routen und keine weiteren Schlüssel erforderlich.

Feature-ID und Electron-UDP: flight, Auswahl sendet 166-flight und 50-maps. 50-maps ist der bereits vorhandene HDMI-Umschaltbefehl. Station 50 bleibt für genau eine Person exklusiv reserviert. Electron views.json erhält den Reiter, vorhandene Reiter und Standardansicht bleiben bestehen.

WebSocket-Join v1: zusätzlich feature:"flight"; bestehende Karten-Clients ohne feature verwenden weiter maps. Controller-Ticket muss zum Feature passen. Displays verwenden den bestehenden DISPLAY_KEY. Events werden nach Feature getrennt:

flight.control: {x:-1..1, y:-1..1, playing:boolean, runId:string}; ca. 25 Nachrichten/s, nur vom Controller.
flight.status: {score:int, hits:int, remaining:0..60, phase:waiting|running|paused|finished, runId:string}; ca. 6 Nachrichten/s, nur von angemeldeten Flug-Displays zum aktiven Flug-Controller.
Alte Flugimpulse werden nicht gespeichert oder bei Wiederverbindung abgespielt. Der Controller sendet seinen aktuellen Zustand fortlaufend. Das vorhandene Karten-Snapshot-Verhalten bleibt erhalten.

Module: sensors.js (Sensorfreigabe/Kalibrierung), controller.js (Bedienoberfläche/Transport), simulation.js (Zeit/Ringe/Punkte), display.js (three.js-Ansicht), gemeinsamer ControlClient (WebSocket) und protocol.js (Relay-Validatoren). three.js 0.180.0 und MIT-Lizenz liegen lokal unter flight/vendor; keine CDN-Abhängigkeit zur Laufzeit. Electron muss WebGL2/Hardwarebeschleunigung unterstützen.

Prüfung

27 automatisierte Prüfungen: 13 Relay-Prüfungen, 10 bestehende Ticket-/Rückkehrprüfungen, vier Prüfungen zu Sensorachsen, Ringtreffern, Serien, Zeit, Bewegungsgrenzen und Bildraten. Zusätzlich zwei Browser-Ansichten über einen privaten Test-Relay verbunden: 3D-Darstellung, Start, Ringtreffer (100 Punkte), Punkte-Rückkanal und Pause beim Schließen des Controllers geprüft. Dabei keine Befehle an die reale Station gesendet.

Noch zu prüfen: Installation des neuen Relay auf dem VPS und echter Geräteflug mit iOS/Android/Electron an Station 50. Reiner Probeflug ohne Ticket, WebSocket oder Stationsreservierung: https://www.tinetronics.de/mutec/flight/display.html?preview=1 (Pfeiltasten/WASD, Leertaste pausiert). Dieser Modus steuert keine Hardware.

Technische Quellen: https://threejs.org/manual/pages/installation.html und https://developer.mozilla.org/en-US/docs/Web/API/DeviceOrientationEvent/requestPermission_static

Siehe auch MUTEC – WebSocket-Steuerung.