Gli astronauti selezionati dalla NASA erano tutti piloti esperti di jet militari altamente qualificati e abituati a gestire le situazioni critiche. Affidare una missione composta da 3 uomini in un viaggio di andata e ritorno sulla Luna esclusivamente alle capacità dei piloti poteva essere molto rischioso. In molte situazioni di volo in cui si verificano centinaia di eventi in sequenza in un ristretto intervallo di tempo: se qualcosa fosse andato per il verso sbagliato nessun astronauta benchè molto preparato sarebbe stato in grado di gestire una situazione di emergenza simile.
L’utilizzo di un computer era fondamentale: pertanto si decise che i progetti Mercury, Gemini ed Apollo venissero subito influenzati dal controllo elettronico con complessità crescente.
La conferenza affronta la tematica uomo-macchina all’interno del progetto Apollo fornendo le risposte alle domande: come integrare il computer con le abilità degli astronauti? Quale peso avrebbero avuto gli astronauti nella missioni Apollo e quali ruoli avrebbe avuto il calcolatore?
A causa delle restrizioni imposte dai decreti ministeriali del Governo italiano per limitare la diffusione del CoVid-19, la conferenza si terrà on line18 Marzo con inizio alle ore 21:00. Verranno inviati successivamente via email ai soci e ai frequentatori del GAVil link per accedere allo streaming.
Gli astronauti selezionati dalla NASA erano tutti piloti esperti di jet militari altamente qualificati che erano abituati a gestire le situazioni critiche in volo in prima persona, tuttavia con la corsa allo spazio, affidare ogni operazione solo ai piloti poteva essere molto rischioso e mettere a repentaglio la vita stessa degli astronauti. Per questo motivo la presenza di un rudimentale computer a bordo era già stata prevista ed implementata per il programma X-15, in modo da aiutare il pilota nell’eseguire i calcoli o gestire le situazioni di emergenza. Con l’aumentare del carico e della complessità del lavoro da svolgere in vista dell’obiettivo Luna, la discussione si fece molto accesa e vide nascere due scuole di pensiero distinte divise fra il controllo manuale ed il controllo automatizzato della capsula.
X15
Erano i primi aerorazzi sganciati in volo da un bombardiere B52 in grado di raggiungere una quota fino a 350.000 piedi (circa 105 Km) per poi atterrare nel deserto lungo una traiettoria balistica
La prima opzione era quella preferita dalla maggior parte degli astronauti, in quanto venivano dal mondo dell’areonautica dove erano abituati a “tenere-in-mano” l’aereo, ovvero a governare il veivolo agendo direttamente con le proprie forze sugli attuatori. La seconda opzione invece vedeva tra i suoi maggiori sostenitori i progettisti ed ingegneri. Essi erano ben consapevoli che pilotare una navicella spaziale è tutto un’altra cosa: ci sono tante operazioni che devono essere eseguite alla precisione, in sequenza ed in un intervallo di tempo brevissimo e qualsiasi cosa può non funzionare tanto che nemmeno l’astronauta più preparato con ottimi riflessi sarebbe stato in grado di agire per tempo. Quest’ultima opzione non piaceva agli astronauti perché rischiava di relegare il loro ruolo a spettatori passivi.
Dicotomia Uomo-Macchina raffigurata in una vignetta dell’epoca. Gli astronauti sono spettatori passivi durante il viaggio verso la Luna o possiedono un ruolo decisionale attivo?
Come includere quindi gli astronauti in questa nuova gestione?
Spettatori passivi o persone con un ruolo decisionale?
Allo scopo di garantire la maggior sicurezza possibile per i piloti si decise che essi avrebbero dovuto acquisire un insieme di competenze non legate esclusivamente al volo, ma anche al funzionamento della strumentazione e imparare come quest’ultima si interfacciava con gli attuatori del velivolo per agire di conseguenza in caso di emergenza.
Fonte immagini a sinistra:
Charles Stark Draper Laboratory Archives Photo 24861 Smithsonian Museum
Charles Stark Draper Laboratory Archives Photo 24860 Smithsonian Museum
Elaboratore e astronauti avrebbero dovuto quindi agire in concertazione in tutte le fasi di volo per integrarsi con i sistemi di avionica dell’Apollo
A tale scopo la suddivisione delle operazioni fra uomo e macchina venne rivista: gli astronauti avevano il compito di monitorare le operazioni di volo ed in orbita erano parte attivi del processo decisionale insieme al sistema di controllo: potevano in ogni caso interagire, integrare o correggere le direttive impartite dal computer, così come sostituirsi ai processi automatici dell’elaboratore e prendere il comando della navicella all’occorrenza in ogni parte del volo.
Questa scuola di pensiero venne soprannominata “man-in-the-loop”, e fu quella che venne effettivamente usata in tutte le missioni Apollo, ove tutti gli allunaggi avvennero con i sistemi di controllo attivi e gli astronauti supervisori finali in grado di inserirsi all’interno del sistema di controllo (come effettivamente fu).
L’introduzione del computer significava inoltre che per le missioni lunari non erano più sufficienti gli ingegneri meccanici, ma si affiancavano anche gli ingegneri elettronici: una volta identificato il ruolo degli astronauti era necessario passare alla fase di progettazione e costruzione dei computer di bordo. Come procedere? Quando nel 1958 la NASA creò lo Space Task Group sotto la direzione di Robert Gilruth venne nominato Max Faget come ingegnere responsabile del progetto della Mercury, Gemini ed Apollo, i quali vennero subito influenzati dal controllo elettronico con complessità crescente.
Timeline dei progetti X15, Mercury, Gemini ed Apollo: i progetti sono stati sviluppati in parallelo. Ogni volta che venivano consolidate le conoscenze del progetto in corso queste ultime venivano utilizzate nel progetto seguente. Diagramma dell’autore
La Mercuryera una capsula costruita dalla McDonnel-Douglas, con un sistema di controllo progettato dalla Honeywell Regulator Company. Durante le normali operazioni la capsula lavorava in modalità automatica e solo in caso di problemi del sistema primario il pilota avrebbe assunto il controllo della situazione con due sistemi di controllo separati. L’astronauta non aveva alcun controllo sull’orbita, poteva solo cambiarne l’assetto tranne durante l’operazione di rientro ove la capsula si orientava automaticamente nella posizione corretta con lo scudo termico verso il basso.
Per il progetto Gemini invece, che includeva operazioni più complesse (rendezvous, docking ed EVA), vennero utilizzati computer sviluppati dalla IBM (che già collaborava con la marina negli anni ‘50) dal peso di 27 Kg avente 7 programmi precaricati: i minimi necessari e previsti per lo scopo della missione.
Per il progetto Apollo, trattandosi di un sistema molto più complesso dei precedenti, la capacità di calcolo degli elaboratori venne sfruttata al massimo al fine di migliorare la stabilità della capsula, intesa come secondo requisito di base fondamentale per una missione lunare. In particolare l’elaboratore doveva gestire:
partenza (come sistema di back up del terzo stadio del Saturn V)
il viaggio verso la Luna
l’allunaggio
il rendezvous
inserimento in orbita terrestre
l’ammaraggio.
La stabilità viene ottenuta tramite un sistema di controllo basato su un sistemi ad anello chiuso come quello in figura a sinistra. Il sistema confronta l’ingresso di riferimento (velocità, smorzatore d’imbardata, …) con quello reale letto dai sensori (uscita controllata). La differenza, ovvero il segnale di attuazione (o errore) viene applicato ai segnali di controllo del sistema.
Queste funzionalità dovevano essere racchiuse in una serie di computer (AGC Apollo Guidance Computer) che occupasse uno spazio modesto, consumasse poca energia e funzionasse per circa due settimane di viaggio: il progetto iniziò nel 1962 a partire da un prototipo basato su logica a transistor che avrebbe dovuto essere usato per una futura missione su Marte.
AGC
Con il termine AGC si intende genericamente il computer della capsula Apollo; in realtà vennero progettati due versioni: uno per il modulo di comando (CGC) e uno per il LM (LGC). Entrambi condividevano parecchie funzionalità di libreria, oltre ovviamente a funzionalità specifiche del sistema. Il LM inoltre includeva anche un computer di backup AGS usato in caso di abort della missione e come backup del LGC. Un altro computer era presente nell’anello di raccordo del primo stadio del Saturn V per gestire la piattaforma inerziale e le fasi di volo del primo stadio.
Il computer aveva le seguenti caratteristiche:
Dimensioni di un piede cubico (circa 28 dm3). Una dimensione molto ridotta, tenendo presente che negli anni ’60 i computer erano molto ingombranti, consumavano molta corrente e occupavano interi edifici universitari.
Programmabile (con una modesta capacità di calcolo)
Un microprocessore in grado di gestire interrupt esterni a priorità per gestione di eventi real time per la piattaforma inerziale, i propulsori SPS e RCS.
Un watchdog (NIGHT WATCHMAN) per consentire al microprocessore di uscire dalle condizioni di stallo
DAC/ADC per comunicare con le interfacce analogiche esterne
Sebbene fosse chiamato computer, in realtà era un sistema embedded basato su microprocessore, una memoria RAM/ROM e un sistema di interfacciamento con i sensori ed attuatori di bordo. Oggi un sistema siffatto si chiama microcontrollore.
La prima versione del AGC nota come Block I venne rilasciata nel 1963: si basava su un solo tipo di circuito integrato (una porta NOR a tre ingressi) esteso anche ai sensori di interfacciamento in modo da rendere il sistema più modulare, mentre il sistema di navigazione rilasciò la sua parte nel settembre dello stesso anno. Garantire l’affidabilità di un sistema che si basava su una tecnologia ancora in stadio embrionale (come quello dei circuiti integrati) era un problema che assillava gli ingegneri progettisti e la NASA stessa, pertanto si decise di produrre componenti in serie tutti uguali per enormi volumi in modo da poter semplificare i test di qualità del prodotto.
La Fairchild (l’azienda appaltatrice) decise di lavorare in lotti: ogni circuito integrato veniva esaminato, sottoposto a stress meccanici e immerso in una soluzione di freon per verificare eventuali perdite. Piccole variazioni di peso superiori a 5 mg indicava che parte del liquido era entrato all’interno dell’integrato, e di conseguenza tutto il lotto veniva scartato. Altri test di produzione includevano: test sulle vibrazioni, di escursioni termiche, shock, umidità, rumore elettronico e variazioni di salinità.
Schema circuitale della porta NOR a due ingressi. Qualsiasi funzione logica può essere implementata con porte NOR perché é una porta universale.
La NASA affidò ai laboratori IL del MIT il sistema principale di navigazione (IMU), il quale era già stato coinvolto nel passato nel sistema di guida di missili Polaris. Il gruppo di lavoro, sotto la guida di Charles Draper, progettò un sistema di navigazione (IMU) usato per mantenere l’assetto, posizione e velocità (previa una procedura di allineamento).
tre accelerometri per identificare tutte le forze agenti sulla capsula in movimento.
tre giroscopi di precisione per il controllo dell’assetto. L’uso dei giroscopi consentiva di tenere gli accelerometri in una direzione costante nel loro frame di riferimento indipendentemente dall’orientazione della capsula: in modo da dare al CSM la capacità di navigare senza un sistema di riferimento esterno.
L’Apollo montava tre giunti cardanici per mantenere in sospensione i giroscopi, comunque insufficienti per evitare il “gimbal lock”, ovvero una situazione per cui la piattaforma perdeva una dimensione di riferimento e quindi non poteva fornire una misura corretta dell’assetto della capsula. Il quarto giunto non venne installato sia per motivi di spazio e poi perché tutte le manovre erano progettate per essere effettuate in due dimensioni. Il computer aveva una procedura che periodicamente controllava il suo stato e avvisava in tempo gli astronauti in caso fosse vicino alla situazione critica, ma nonostante questo sia nella missione Apollo 11 che Apollo 13 si verificarono situazioni di rischio. A queste caratteristiche IL aggiunse:
un telescopio e un sestante spaziale a 28 ingrandimenti: per il controllo manuale ed eventuale correzione di rotta. Il sestante aveva due linee di vista: una fissa o LLOS (la linea dell’orizzonte) e una mobile o SLOS (linea stellare). Per garantire maggior precisione, il sistema era solidale con la capsula Apollo e IMU stessa, come un banco ottico. L’astronauta puntava la linea dell’orizzonte verso il punto di riferimento e la linea della stella in direzione di un altro oggetto e muoveva il sestante finché le due immagini non si sovrapponevano: alla fine l’astronauta premeva un pulsante ed il computer registrava l’angolo di vista. La differenza fra la posizione reale e quella stimata dal computer serviva allo stesso per modificare il suo allineamento.
una console per interagire con il computer ed elettronica di supporto
Il banco di prova del AGC Block I avvenne con i primi test LEO sotto la guida di Robert Shea: questa versione non poteva navigare verso la Luna, pertanto tutte le nuove caratteristiche vennero incorporate nella versione successiva: AGC Block II.
I problemi di interfacciamento con le apparecchiature elettroniche non mancarono comunque: nel Maggio 1963, durante l’ultimo volo della Mercury Gordon Cooper ebbe un problema con il sistema di controllo: dell’urina fuoriuscita dal sistema di raccolta aveva corroso la circuiteria elettronica; questo portò la NASA a sigillare ermeticamente tutta l’elettronica.
La capsula per motivi di sicurezza veniva guidata da Terra grazie all’aiuto di tre stazioni: Spagna, Australia e California che dialogavano con il trasponder di bordo dell’Apollo: negli anni ‘60 la precisione degli orologi atomici consentiva alla NASA un ottimo livello di approssimazione. A partire dal ritardo di trasmissione e dall’effetto Doppler la NASA poteva calcolare la posizione dell’Apollo con un errore di 10 metri e la velocità con un errore di 0,5 m/s (il radar consente di ricostruire l’orbita di un corpo celeste ma non il suo assetto). In ogni caso il computer era essenziale quando transitava lungo la faccia nascosta della Luna, causa l’assenza di segnale da Terra.
Il computer di bordo era un sistema fly-by-wire: faceva da interfaccia e mediava tutte le operazioni di volo. Il software doveva imparare ad interagire con i sottosistemi della capsula, reagire ai cambiamenti esterni e formare un processo decisionale adatto, in ogni livello. Il MIT produsse un prototipo a novembre 1965 per essere poi consegnato alla NASA nel luglio 1966.
A lato le caratteristiche dell’AGC Block II.
2KWord son diversi da 4Kbytes
Dal punto di vista implementativo 2 bytes sono diversi da 1 Word. Infatti un computer che deve processare un byte ma e’ stato progettato per lavorare in Word significa che la CPU deve effettuare operazioni di post processing (mascheramento e shift-register) quindi impiegare ulteriori tempi aggiuntivi di elaborazione (cicli di fetch).
Bibliografia
Digital Apollo: Human and Machine in Spaceflight, David A. Mindell
Left Brains for the Right Stuff: Computers, Space, and History Hugh Blair-Smith
Durante le missioni Apollo la stima ed il controllo delle traiettorie ottimali Terra – Luna erano condizione critiche in molte fasi di volo, per esempio:
Il CSM doveva entrare in orbita lunare (LOI, Lunar Orbit Insertion) con molta precisione ad un’altezza di soli 60 miglia nautiche, intorno ad un corpo celeste che si muove a circa 1 Km/s.
Durante l’allunaggio: i dati provenienti dal radar di Terra dovevano trovare un’analogia con i valori dei radar di allunaggio (LR, Landing Radar) montato sul LM per capire se proseguire o abortire la missione.
In fase di ritorno in atmosfera: il CM doveva imboccare un corridoio di rientro con un angolo di volo di 6,5°± 1° rispetto all’orizzonte.
La conoscenza a priori e la possibilità di stimare il consumo di beni e materiali, oltre ad aspetti pratici, serviva anche per ragioni di riduzione costi (consumo di carburante) e per adempiere ai criteri di sicurezza dell’equipaggio. In ogni caso il problema più sentito per l’equipaggio a bordo (e al MOCR a Houston) era l’esigenza di poter controllare che l’Apollo si muovesse lungo il percorso stabilito dalla traiettoria in uno spazio di riferimento, così come in qualsiasi altra situazione di volo.
La capsula CM dell’Apollo era equipaggiata con sensori (giroscopi e accelerometri) e strumentazione (telescopio, sestante spaziale) per poter prendere delle misure angolari rispetto alle stelle fisse, al Sole, a punti particolari sull’orizzonte terrestre ed altro le quali venivano inviate al computer per i calcoli di posizione. I sensori sono soggetti a diversi tipi di errore: casuali, di deriva o di imperfezioni di costruzione.
Analogalmente le equazioni del moto (modello dinamico) usato per descrivere la traiettoria è soggetta ad errori nel modello non deterministici ove non è possibile valutarne a priori la quantita’ in maniera precisa: per esempio è difficile considerare le perturbazioni del moto lunare, l’esatta spinta ottenuta dall’accensione dei RCS, l’influenza della distribuzione della massa terrestre/lunare sul CSM …
Il problema che la NASA doveva affrontare era: quante e quali misure bisognava effettuare al fine di garantire una navigazione corretta nello spazio cislunare?
La risposta a questa domanda significava identificare il numero minimo ed ottimale di misure da effettuare, quali correzioni erano necessarie e quando effettuarle. La procedura ideale poteva essere descritta come segue:
Utilizzando i sensori del CM, identificare posizione e velocità attuali, cioè i vettori di stato e
informare il computer di bordo (AGC) dello stato corrente
in base ad alcune regole “statistiche” decidere se:
intraprendere una correzione orbitale sulla traiettoria
non effettuare alcuna correzione
aggiornare i vettori di stato
tornare al punto 1
Dato che ogni misura è affetta da incertezza (ambiente rumoroso) era necessario valutare in senso statistico le azioni da intraprendere ad ogni ripetizione. Maximilian Schuler nei primi anni del Novecento fu tra i primi matematici a studiare il problema; in particolare gli errori oscillatori generati dai sensori IMU indotti dal campo gravitazionale in cui i giroscopi lavorano. In seguito altri matematici quali Richard Battin (1925 – 2014) del MIT e Norbert Wiener cercarono di affrontare il problema ma fu con Rudolf Kalman (1930 – 2016) che la NASA ebbe la possibilità di implementare l’algoritmo che ancora oggi porta il suo nome: il filtro di Kalman.
Egli riuscì a trovare una soluzione ottima per la stima dell’errore lavorando nel dominio del tempo, anziché in frequenza (come fece Wiener) in modo da renderlo gestibile in tempo reale da un computer ed implementarlo nel software di volo.
Il filtro di Kalman è un metodo statistico per l’ottimizazione del controllo, in particolare è un filtro ricorsivo per la stima di uno stato interno del sistema dinamico a partire da una serie di misure rumorose.
L’ipotesi di base di funzionamento del filtro prevede sorgenti di errori indipendenti provenienti da distribuzione statistica Normale N (μ, σ) a media nulla.
Dato che al fine di individuare la traiettoria ottima è necessario stimare l’errore (predizione in senso statistico) e gestirlo nelle equazioni dinamiche del sistema (parte deterministica del sistema), quindi il fattore principale del processo di filtraggio è la misura dell’errore. L’algoritmo si compone in due fasi:
una predizione basata sul modello ideale del modello ideale di volo per una prima stima di $latex $V_{k|k-1}$ nell’istante successivo del sistema.
una misura dai sensori del LM/CSM (SXT/TEL)
Il confronto/correzione con la predizione iniziale per ottenere la stima ottima finale
Lo stato interno del sistema si trova più vicino al valore nominale.
La parte di osservazione consiste nella lettura dei sensori anch’essi affetti da errore, l’aggiornamento consiste nella minimizzazione della differenza fra la previsione e l’osservazione, quindi l’errore viene corretto da un fattore K il quale viene usato per aggiornare le equazioni del sistema dinamico.
L’algoritmo consiste in cinque fasi applicate in maniera iterativa:
Predizione: si prevede lo stato corrente in base al modello dinamico affetto da rumore N (0, σ)
Osservazione dello stato: si effettua la misura dei sensori affetti anch’essi da rumore N (0, ξ)
Minimizzazione dell’errore $latex e_{k}$ fra la previsione del modello dinamico e la sua osservazione. L’errore si chiama innovazione del sistema
Aggiornamento calcolo della covarianza dell’errore e del guadagno K per la previsione dello stato successivo del sistema dinamico.
Integrazione: del parametro K nel modello dinamico e stima ottima
Ritorna al punto 1
Ci sono molti modi per calcolare K: se il sistema dinamico e lineare con rumori gaussiani a media nulla (descritti nei punti 1 e 2) allora esiste un algoritmo ottimale per il calcolo di K.
Principio di funzionamento del filtro di Kalman implementato nel CGC Fonte: Apollo On board navigation technique, NASA
Il filtro venne inizialmente implementato nei mainframe IBM704 che usavano un’aritmetica a virgola mobile a 36 bit, quindi grazie al lavoro di J.E. Potter, riuscì a trovare un’implementazione con un’aritmetica a virgola fissa a 15 bit per poterlo farlo funzionare sul computer dell’Apollo. Un’operazione di filter tuning condotta a terra con altre simulazioni numeriche ha fornito alla NASA le condizioni iniziali di funzionamento del filtro: a questo punto mancava solo un test in campo.
Ideato inizialmente per funzionare con problemi di stima lineari, la NASA fu in grado di estendere il campo di lavoro del filtro anche per problemi non lineari, come quello di mandare un’equipaggio sulla Luna.
Questa seconda versione implementata per il progetto Apollo si chiama filtro di Kalman esteso (EKF).
Esso fornisce un’approssimazione della stima ottima, poichè viene effettuata una linearizzazione del sistema nell’intorno dell’ultima stima dello stato. Il processo di trasformazione dello spazio non lineare in uno spazio lineare avviene tramite una trasformazione Jacobiana basata sull’approssimazione in serie di Taylor del primo ordine.
Patch Apollo 7
La prima prova del funzionamento del filtro avenne nell’ottobre 1968, con la missione Apollo 7 ove il filtro di Kalman venne implementato nel software del AGC Block II, al suo primo test di volo. Si trattò di un volo particolare: durante la missione l’equipaggio si impratichì a recuperare il LM ma ci furono tensioni fra gli astronauti e il personale di Terra, in quanto gli astronauti si dimostrarono poco collaborativi ma il filtro fece il suo dovere.
Il filtro di Kalman ha rappresentato un’evoluzione tecnologica fondamentale nel campo dell’avionica, ed oggi viene implementato in moltissimi campi, come nei sistemi di navigazione, nella guida autonoma e tanti altri settori ove si tratta di effettuare una stima ottimale con sorgenti affetti da rumore.
Disegno che mostra la differenza fra traiettoria reale affetta da errore (puntini rossi) e la traiettoria ottimale filtrata da Kalman
Per il suo contributo al progetto Apollo, l’ingegner Rudolf Kalman ha ricevuto la “National Medal of Science” nel 2009.
Orologio solare - Ortisei, frazione San Giacomo (BZ)
Orologio solare - Ortisei (BZ)
Orologio solare - Andalo, località Laghett (TN)
Orologio Solare - Brinzio (VA)
Orologio solare, Palazzo del Vescovo - Losanna
Fai della Paganella (TN)
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
![\vec{\textbf{r}} = [r_{x}, r_{y}, r_{z}]](https://s0.wp.com/latex.php?latex=%5Cvec%7B%5Ctextbf%7Br%7D%7D+%3D+%5Br_%7Bx%7D%2C+r_%7By%7D%2C+r_%7Bz%7D%5D&bg=88c3d7&fg=feeca5&s=0&c=20201002)
e ![\vec{\textbf{v}} = [v_{x}, v_{y}, v_{z}]](https://s0.wp.com/latex.php?latex=%5Cvec%7B%5Ctextbf%7Bv%7D%7D+%3D+%5Bv_%7Bx%7D%2C+v_%7By%7D%2C+v_%7Bz%7D%5D&bg=88c3d7&fg=feeca5&s=0&c=20201002)
in base al modello dinamico affetto da rumore N (0, σ)
dei sensori affetti anch’essi da rumore N (0, ξ)
