DEV Community

Cover image for NASA Explores Potential Commercial Servicing for Hubble Telescope
Ashish
Ashish

Posted on

NASA Explores Potential Commercial Servicing for Hubble Telescope

Vom Hubble-RFI zum dichoptischen Shader: Wie ich mein Amblyopie-Training in VR selbst engineered habe ## Der Auslöser: 29. Oktober, NASA RFI Ich scrollte durch Hacker News, Kaffee kalt neben der Tastatur. „NASA Seeks Industry Capabilities for Hubble On-Orbit Servicing.“ 34 Jahre im Orbit, keine Wartung seit STS-125. Millimeter-Arbeit, zwei Augen – menschliche oder robotische – die perfekt fusionieren müssen. Ein einziges Fehlalignment und das 1,5-Milliarden-Dollar-Objekt wird Debris. Ich grinste bitter. Mein eigenes „Hubble“ sitzt links in meiner Augenhöhle: Amblyopie, seit ich sechs bin. Das dominante rechte Auge hat das Kommando übernommen, das linke wurde vom Kortex ignoriert – klassische Suppression. Pflastertherapie als Kind? Zwei Wochen, dann Rebellion. Rot-Blau-Brille? Farbverfälschung, Kopfschmerzen, Compliance gegen null. Ich habe das Thema verdrängt, wie man Technical Debt verdrängt: „Läuft ja irgendwie.“ Bis zu diesem NASA-Post. ## Warum mich die Parallele nicht losließ Hubble braucht binokulare Präzision. Mein Alltag auch: Code-Reviews, Architecture-Diagramme, 3D-Druck-CAD, nächtliches Debugging auf zwei Monitoren. Tiefenwahrnehmung fehlt mir beim Parken, beim Ballfang, beim Einschätzen von Abständen in AR-Prototypen. Ich kompensiere mit Monokular-Cues – Motion Parallax, Occlusion, Size-Depth. Aber echte Stereopsis? Fehlanzeige. Ich begann zu recherchieren. Dichoptisches Training: zwei Bilder, leichter Unterschied, Gehirn muss fusionieren. Klassisch mit Anaglyphen oder Spiegel-Stereoskop. Aber VR? Zwei Displays, physisch getrennt, pro Auge adressierbar. Das ist Hardware, die für dichoptische Stimulation gebaut ist – nur nutzt sie kaum jemand dafür. ## Amblyotube: Was unter der Haube steckt Seven Sportz (nicht zu verwechseln mit großen MedTech-Konzernen) hat Amblyotube für Meta Quest 2/3/Pro/3S gebaut. Kein Unity-Asset-Store-Prototyp, sondern eine native App, die die Rendering-Pipeline des Headsets direkt ansteuert. ### Dual-Render-Pipeline Jedes Frame wird zweimal gerendert: - Linkes Auge (bei mir das schwache): Original-Video + MFBF-Sharpening + Flicker-Stimulus + Magenta-Cue (hochvisibel) + Highlight/Outline/Pulse-Accents. - Rechtes Auge (dominantes): Original-Video + Dominant-Eye-Shader (Blur, Contrast, Brightness, Gamma, Opacity 0–100 %). Die Shader-Parameter sind zur Laufzeit über ein Floating-Panel einstellbar – Controller oder Hand-Tracking. Kein Neustart, keine Rekompilierung. Das ist saubere Separation of Concerns: Rendering-Engine kennt die Therapie-Logik nicht, sie bekommt nur Parameter. ### MFBF (Mono-Fixation-in-Binocular-Field) via On-Device-KI Das ist der Teil, der mich als ML-Engineer interessiert: Ein leichtes Person-Detection-Modell (vermutlich MediaPipe Pose oder BlazePose, quantisiert für Snapdragon XR2) läuft auf dem Headset. Es identifiziert Gesichter/Körper im YouTube-Stream und generiert eine Maske. Nur innerhalb dieser Maske wird das Bild für das schwache Auge geschärft (Unsharp-Masking mit konfigurierbarem Radius/Amount). Außerhalb: unverändert. Warum Personen? Evolutionär relevanter Reiz, Social-Attention-Netzwerk im Kortex. Der Flicker-Stimulus (einstellbar Hz, „Jerk“) moduliert die Maske – ein Mikro-Saccaden-Trigger für den visuellen Kortex. ### Binokulare Fusion: Magenta-Cue & Wedge-Occlusion Ein bewegter Kreis: Magenta (R+G, ~#FF00FF) im schwachen Auge, subtiles Grau im dominanten. Magenta steht gegen Hauttöne, Grün, Blau – maximal salience. Das Gehirn muss die Signale fusionieren, um den Kreis kohärent zu sehen. Wedge-Occlusion (schwarzer Keil, pro Auge versetzt) unterdrückt Rivalität, indem jedem Auge exklusive Bildanteile zugewiesen werden. ### Klinisches Screening, keine Spielerei LogMAR-Test mit Landolt-C, virtuelle 3 m Distanz, Staircase-Algorithmus (4-down/1-up oder ähnlich), bis zu 30 Trials pro Auge + binokular. Output: logMAR-Werte, Auto-Mapping auf Presets (Mild/Moderate/Severe). Das ist keine Gamification – das ist ein klinisches Assessment-Tool, eingebettet in die App. ## Meine ersten 30 Tage: Ein Dev-Log Tag 1–3: Kalibrierung & Frustration Falsches Auge gewählt (rechts statt links) – erste Session trainierte das dominante Auge. Wichtig: „Lazy Eye Selection“ ist kritisch. Korrigiert, Preset „Moderate“ (ich lese die letzten 3–4 Zeilen nicht). Shader auf 40 % Opacity, Blur 2.5 px, MFBF-Sharpening Medium, Flicker 2 Hz. Kopfschmerzen nach 25 Min. VR-Eye-Strain ist real. Hard Limit: 60 Min, Empfehlung 30–40 Min. Ich blieb bei 30. Tag 7: Erste Fusion-Momente Magenta-Cue: Plötzlich sah ich den Kreis nicht als zwei überlagerte Bilder, sondern als einen Kreis mit Tiefe. Ein kurzer Flash – wie beim ersten Mal git rebase -i verstehen. Das Gehirn hatte die Signale fusioniert. Dauer: vielleicht 2 Sekunden. Aber: Beweis, dass Plastizität da ist. Tag 14: Alltags-Transfer Parkhaus-Rampe: Ich schätzte die Distanz zur Säule besser. Nicht perfekt, aber der „Schreck-Moment“ fehlte. Code-Review auf zwei 27″-Monitoren: Weniger Kopfbewegungen, Blickwechsel flüssiger. Tag 30: LogMAR-Re-Test Linkes Auge: 0.32 → 0.24 logMAR (ca. 2 Linien Gewinn). Binokular: 0.18 → 0.12. Nicht geheilt – aber messbar besser. Und das Wichtigste: Ich mach's täglich, weil ich YouTube schaue (Lex Fridman, 3Blue1Brown, Veritasium), nicht weil ich „Therapie“ mache. Engagement durch Content, nicht durch Compliance. ## Was Builder daraus mitnehmen können 1. Hardware-Software-Co-Design: Quest-Displays sind physisch zwei Render-Targets. Die meisten Apps rendern identisch. Amblyotube nutzt die Asymmetrie gezielt. Such dir in deinem Stack die ungenutzte Asymmetrie. 2. Parametrisierung > Hardcoding: Shader-Config, Flicker-Hz, Pulse-Depth, MFBF-Strength – alles exposed. Kliniker (oder Power-User) können titrieren. Kein „One-Size-Fits-All“-Build. 3. On-Device-ML für Latenz-kritische Loops: Person-Detection muss lokal laufen. Cloud-Roundtrip = Frame-Drop = Brechreiz. Quantisierung, NPU-Nutzung, Model-Distillation – das sind die echten Engineering-Herausforderungen. 4. Clinical-Grade Metrics in Consumer-UX: LogMAR-Staircase in der App, nicht als separates Tool. Datenfluss: Screening → Preset-Auto-Update → Training. Closed Loop. 5. Content als Retention-Hook: YouTube-API + Offline-Katalog. Nutzer bleiben, weil der Content interessant ist, nicht weil sie müssen. Das ist der Heilige Gral bei Adhärenz. 6. Safety by Design: Hard Session-Limit (60 Min), Altersgrenze (13+), Medical Disclaimer prominent. Kein „Move fast and break things“ bei Sehen. ## Was Amblyotube nicht ist - Kein Medizinprodukt (keine MDR-Zulassung, kein CE-Klasse-IIa). - Kein Ersatz für Augenarzt/Orthoptistin. - Keine Garantie auf „Heilung“ – Neuroplastizität nimmt mit Alter ab, aber 13+ ist die untere Grenze, oben offen. - Keine Telemetrie an Dritte (lt. Datenschutz), alles lokal. ## Fazit: Dein persönliches Hubble wartet Die NASA sucht Partner für ein Teleskop im Orbit. Ich habe einen Partner für mein linkes Auge gefunden: ein Headset, eine App, 30 Minuten am Tag. Die Shader-Parameter sind meine Flight-Software-Updates. Der LogMAR-Score ist mein Telemetry-Downlink. Wenn du Builder bist und Amblyopie hast – oder jemand kennst, der: Probier's. Die Technologie ist ehrlich, die Architektur sauber, der Nutzen messbar. Und wer weiß – vielleicht baut die nächste Generation Hubble-Servicing-Roboter weil ihre Entwickler als Kinder dichoptisch in VR trainiert haben. https://www.meta.com/en-gb/experiences/amblyotube/25906906972338493/

Top comments (0)