Sterowanie i IO

PTT to zasada: mów, gdy trzeba. Pilot aktywuje tryb słuchania i nagrywania; dopiero po zwolnieniu sterowania aplikacja wykonuje kolejne kroki (Whisper → intencja → dane → Gemini → odpowiedź).

Dlaczego PTT jest obowiązkowy w tej architekturze

• Julia nie interpretuje intencji w trakcie przypadkowego hałasu lub ciągłego mówienia bez kontroli.
• Pilot ma świadomą kontrolę nad momentem, w którym system „przerabia” polecenie.
• Potok jest przewidywalny — kluczowe w zastosowaniach lotniczych.

Źródła PTT w aplikacji

• Joystick / kontroler — zdarzenia obsługiwane m.in. przez Pygame (stabilniejsza integracja kontrolera i płynność PTT).
• Skrót klawiaturowy — w dokumentacji technicznej: m.in. klawisz „R” (wraz z joystickiem).

Klasa PTTMappingContainer

Autorskie rozwiązanie przechwytywania sygnałów w tle systemu Windows.

• Multi-Input Handling: równoległy monitoring klawiatury oraz przycisków joysticka / wolantu przez bibliotekę win32api.
• Global Hooking: mechanizmy zapobiegające „wyciekaniu” klawisza do innych aplikacji — aktywacja Julii nie powinna powodować niechcianych akcji w symulatorze.

1. VAD (Voice Activity Detection) — automatyczne przycinanie ciszy w nagraniu (oszczędność tokenów / czasu).
2. Transkrypcja (Whisper) — analiza pliku audio (np. .wav); prompty techniczne poprawiają rozpoznawanie skrótów lotniczych (QNH, V1, FL320 itd.).
3. Context Injection — przed zapytaniem do Gemini system wstrzykuje aktualne dane z symulatora (wysokość, prędkość, paliwo) oraz plan lotu, aby model nie zadawał pytań o informacje już znane z telemetrii/OFP.

Po uzyskaniu tekstu system wybiera tor działania (architektura komisji):

• intencja pogoda / METAR → logika METAR i CheckWX,
• intencja nawigacja → kontekst trasy i pozycji,
• intencja wyliczenia → moduł kalkulacyjny,
• intencja procedury / nauka → tryb wspierający naukę (Teacher Mode w opisie architektury).

• CustomTkinter — główna nowoczesna warstwa GUI (przyciski, przełączniki, checkboxy, kafelki trasy, sekcje widoku).
• Tkinter — m.in. panel ZULU (METAR) oraz system tooltipów tam, gdzie potrzebna jest elastyczna kontrola wizualna.
• Pygame — joystick i zdarzenia sterujące w czasie rzeczywistym.

Tooltipy (podpowiedzi)

• Klasa Tooltip — dynamiczne wyświetlanie pomocy; zdarzenia <Enter> / <Leave> odseparowane od logiki przycisków (redukcja migotania).
• Tooltipy renderowane nad elementami, kolorystyka spójna z trybem ciemnym MSFS.
• W architekturze PL: „lekka, przezroczysta bańka” — nie zasłania kokpitu; użytkownik może ograniczyć tooltipy (Info tooltips).

Głosowa obsługa przycisków (audio feedback)

• Istotne przyciski mają funkcję głosową — wsparcie „ślepej obsługi” (VR, złe warunki widoczności).
• Synteza w osobnym wątku — threading.Thread dla funkcji mowy (mow), aby nie zamrażać okna podczas TTS.

Z dokumentacji architektury: Julia nie „przepycha” wypowiedzi, gdy pilot ponownie aktywuje PTT. Właściwa kolejność (najpierw odczyt i zrozumienie polecenia, potem odpowiedź) ogranicza sytuacje, w których system mówi, gdy pilot komunikuje się lub słucha. Przy PTT w trakcie wypowiedzi TTS działają mechanizmy wyciszania / priorytetu człowieka (np. stop_julia_mowy, flagi stanu opisane przy wielowątkowości).

• MUTE dotyczy krótkich potwierdzeń głosowych przy przyciskach — można wyłączyć dźwięk, zachowując ślad w logu tekstowym.
• Bilans: komfort w fazach intensywnego pilotażu + audyt tego, co system zrobił.

Warstwa HTTP (poza MQTT — patrz rozdział MQTT w dokumentacji technicznej) służy m.in. do:

• pobrania planu lotu z SimBrief,
• pobrania METAR z CheckWX,
• opcjonalnych integracji (webhook, zewnętrzny panel),
• komunikacji z backendem (Firebase, Stripe / webhooki przez Make.com).

• Opóźnienia zależą od CPU, łącza (dla chmury Gemini) i jakości audio; dokumentacja podkreśla lokalny STT (Whisper) jako bardziej przewidywalny w kabinie niż wyłączna zależność od sieci w momencie krytycznym.
• Bufor audio chunkowy (pyaudio) — wcześniejsze rozpoczęcie przetwarzania po zwolnieniu PTT (opis TTI / optymalizacji latencji).