Delucidazioni sul protocollo per impartire ed eseguire ordini a bordo di un sottomarino

[gepard *]

Quesito per @Totiano e gli altri sommergibilisti della base.

 

Innanzitutto perdonate la mia ignoranza riguardo questa questione basilare.

 

Sabato scorso durante il pranzo del raduno "Provana" all'ANMI di Torino mentre chiacchieravo con @Ocean's One, @Totiano ha accennato a quello che io da profano informatico battezzo con il termine di "protocollo" per impartire ed eseguire gli ordini all'interno di un battello:

 

A) Il comandante pronuncia l'ordine: "Rotta 170"

 

B) L'operatore addetto all'esecuzione dell'ordine impartito, prima di attuarlo, lo ripete lari pari: "Rotta 170"

 

C) L'operatore quindi attua l'ordine e all'ottenimento del risultato richiesto (il battello è sulla rotta 170), l'operatore pronuncia l'ordine "invertito", qualcosa tipo: "Nuova rotta 170" ?

 

Cosa si intende per ordine "invertito" ?

Cosa succede se l'operatore non ha inteso correttamente l'ordine rip e quello che pronuncia in B non corrisponde a ciò che ha detto il comandante ?

Ordini, ripetizioni e annunci "invertiti" hanno un frasario predefinito ?

 

Queste domande sono leggermente tendenziose... dopo aver visto e smanettato un po' sul simulatore della timoneria del Toti 1:1 di @Ocean's One e ascoltato ciò che ha detto @Totiano mi è venuto in mente: perché non aggiungere al TOTI 1:1 anche un livello di interazione vocale: il simulatore fa le veci del comandante e pronuncia il comando (TTS: text to speech) , il giocatore lo ripete prima di attuarlo e ne annuncia l'attuazione (STT: speech to text)

 

Per lavoro ho avuto a che fare con librerie TTS e STT e ritengo che con le versioni offline si possa mettere su qualcosa di "funzionicchiante", comunque potrebbe valere la pena analizzarne la complessità implementativa in funzione di quanto sia "rigido" (frasario predefinito) o "flessibile" (linguaggio naturale) il "protocollo"

 

 

P.S. in linguaggio informatico A) potrebbe essere definito con il termine COMMAND, B) con ACKNOWLEDGE e C) con  FEEDBACK 

Edited November 26 by gepard

[Totiano*]

Col PS hai centrato il problema: su unità pericolose come i somergibili è necessario ridurre al minimo gli errori e, comunque, fin dall'Accademia, si viene addestrati a impartire gli ordini, che devono essere comprensibili, eseguibili, verificabili. Ovvero, se do ordine in lingua sconosciuta sto sbagliando, se ordino di accostare a una persona senza braccia sto sbagliando, se non verifico che l'ordine sia stato eseguito correttamente sto sbagliando. Quindi:

Do ordine, ad esempio rotta (o via) 170. 

Chi riceve l'ordine lo ripete pari pari "rotta 170" dando evidenza di avere sentito, avere capito e stare eseguendo 

Quando l'ordine è stato eseguito dirà "170 rotta" dando evidenza che l'unità è in rotta quindi l'ordine è stato eseguito correttamente

 

Questa semplice procedura è indispensabile, ad esempio, alle 4 del mattino col sonno che incombe e il locale quasi al buio....  

[Ocean's One*]

Oppure in situazioni come questa: 

 

"... Alle 21:44:37, avendo notato che la poppa sarebbe entrata in collisione con gli scogli se l'accostata a dritta fosse continuata, ordinò barra al centro per interrompere la manovra; ordinò poi alle 21:44:44 di dare timone per 10° a sinistra ed alle 21:44:46 per 20° a sinistra, tuttavia il timoniere Rusli Bin non comprese correttamente questi ultimi ordini e accostò invece a dritta. Alle 21:45:05 Schettino, probabilmente rendendosi conto dell'errore, ordinò "hard to port" (tutta la barra a sinistra), ma due secondi più tardi, in posizione 042°21'.4100 N e 010°55'.8510 E, a 14,2 nodi e con prora per 007°, la nave si scontrò con il più piccolo degli scogli delle Scole, nei pressi dell'Isola del Giglio, a 96 metri dalla riva e a 8 metri di profondità."

da Wiki: https://it.wikipedia.org/wiki/Naufragio_della_Costa_Concordia

che riporta dalla Relazione tecnica dei periti del GIP (PDF), su dadosav.files.wordpress.com.

 

Oltre a tutto il resto, sono stati fatali quei 19 secondi in cui l'ordine non è stato capito, né confermato, ma anzi è stato eseguito al contrario.

(scusate l'OT ma mi è venuto spontaneo! Se volete cancello...)

 

______________

 

@gepard

Ottima idea quella degli ordini vocali.

Ne vedo già un possibile utilizzo nel gioco guidato a punti.

Come hai visto, il gioco guidato ti impone proprio degli ordini da eseguire, per cui almeno la fase A) COMMAND si potrebbe implementare con voce registrata oppure addirittura generata dal SW.

Invece, mi risulta più difficile immaginare l'interazione dei punti B) ACKNOWLWDGE e C) FEEDBACK: il SW deve "ascoltare" il timoniere? E se questi non conferma, il SW deve ripetere l'ordine? E se infine il timoniere fa giusto ma in silenzio, gli darà lo stesso i punti oppure no?

 

Qualche questione da chiarire, ma l'idea è molto buona...

 

 

 

 

[Iscandar]

La risposta del timoniere è in due parti, come enunciato dal Dir..

Credo che il sw debba avere questi due check per considerare l'ordine eseguito nei canoni

Edited November 27 by Iscandar

[gepard *]

@Ocean's One

 

5 ore fa, Ocean's One ha scritto:

Ne vedo già un possibile utilizzo nel gioco guidato a punti.

Pensavo esattamente a questo

 

5 ore fa, Ocean's One ha scritto:

la fase A) COMMAND si potrebbe implementare con voce registrata oppure addirittura generata dal SW.

Sì, più che registrata pensavo proprio all'uso di una libreria di text to speech, quindi sintetizzata dal SW (magari basata su un modello di IA che imita la voce del Dir..., da una breve ricerca esistono delle librerie open source per implementare un TTS che imita la voce)

 

5 ore fa, Ocean's One ha scritto:

i punti B) ACKNOWLWDGE e C) FEEDBACK: il SW deve "ascoltare" il timoniere?

Sì, con una libreria di speech to text offline (per lavoro ho avuto modo di usarne una che è abbastanza precisa con un frasario prestabilito: https://alphacephei.com/vosk/)

 

Ad esempio vosk può restituire sia la trascrizione della frase pronunciata che un intent associato a delle frasi di un frasario per il quale è stato precedentemente addestrato a riconoscere.

 

5 ore fa, Ocean's One ha scritto:

E se questi non conferma, il SW deve ripetere l'ordine?

A questo può rispondere @Totiano, cosa succederebbe nella realtà ? Il comandante chiede al secondo di puntare una pistola alla nuca del timoniere finchè non esegue l'ordine ? (il problema poi è come implementare questa coercizione sul simuatore...) 

 

In ogni caso ad ogni violazione del protocollo sicuramente il SW del simulatore dovrà eseguire delle azioni opportune.

 

Che potrebbero essere sia "punitive", come la sottrazione di punti, che "istruttive", come dei messaggi didattici che aiutino il giocatore ad acquisire dimesichezza con il protocollo (magari seguiti o preceduti da qualche gentile messaggio vocale del sergente maggiore Hartman di Full metal jacket...).

 

5 ore fa, Ocean's One ha scritto:

E se infine il timoniere fa giusto ma in silenzio, gli darà lo stesso i punti oppure no?

Sarebbe comunque una violazione del protocollo.

 

Nel caso di un'azione che agisca sul punteggio del gioco in aggiunta dell'attuale metodo di assegnazione dei punti, si potrebbe:

 

Sottrarre punti:

- ad ogni COMANDO ripetuto perchè non eseguito entro un certo tempo (sempre che il timoniere sopravviva all'azione del secondo...)

- ad ogni ACKNOWLEDGE non conforme al COMANDO impartito

- ad ogni ACKNOWLEDGE conforme al COMANDO ma dato dopo l'inizio dell'esecuzione dell'ordine

- ad ogni FEEDBACK non conforme al COMANDO impartito

- ad ogni FEEDBACK conforme al COMANDO ma annunciato oltre un certo tempo limite dopo l'esecuzione corretta dell'ordine (maggiore è il ritardo e maggiori sono i punti sottratti)

 

Aggiungere punti:

- ad ogni ACKNOWLEDGE conforme al COMANDO, dato entro un tempo limite (più si è responsivi maggiori sono i punti assegnati) e solo se dato prima di eseguire l'ordine

- ad ogni FEEDBACK conforme al COMANDO annunciato entro un certo tempo limite (più si è responsivi maggiori sono i punti assegnati)

 

Lasciare il punteggio invariato:

- ad ogni ACKNOWLEDGE conforme al COMANDO dato in prossimità del tempo limite e solo se dato prima di eseguire l'ordine

- ad ogni FEEDBACK conforme al COMANDO annunciato in prossimità del tempo limite

 

[gepard *]

Tra l'altro, l'utilizzo di una libreria di riconoscimento vocale (speech to text) non troppo intelligente impone che l'operatore debba necessariamente scandire in modo chiaro e intelligibile le parole e le cifre dell'ACKNOWLEDGE e del FEEDBACK e questo ritengo che sia un plus notevole dal punto di vista didattico.

 

Inoltre, un modo per rendere più didattico il simulatore con riconoscimento vocale potrebbe essere quello di ignorare ogni azione sui comandi dal momento in cui viene pronunciato il COMANDO fino a quando l'STT non riceve il corretto ACKNOWLEDGE e tutti i leveraggi e interruttori sono in posizione neutra.

[Ocean's One*]

Ciao, carissimo.

Certamente, i comandi vocali sarebbero un bel miglioramento per il simulatore arcade in modalità “missione”.

Se dici che si può trovare una buona libreria per un realistico text-to-speech, bene, ti credo!

 

In generale mi trovo d’accordo sulle modalità che hai ipotizzato, magari con qualche distinguo.

Certamente le azioni punitive e di premio con taglio o attribuzione di punti hanno senso (già adesso perdi punti se causi cavitazione, per esempio).

Per i gentili messaggi vocali del sergente invece lascerei perdere, come pure per la simulazione degli scappellotti del Direttore sul coppino del malcapitato timoniere... ( non sapevi?  )

 

Per il punteggio, cambia poco che sia punitivo o di mancato premio, l’effetto è lo stesso.

La verifica dell’ACKNOWLEDGEMENT vocale si può sicuramente fare. 

Il problema sarebbe invece nel caso in cui il gioco imponga contemporaneamente due comandi, come per esempio rotta e quota. In questo caso servirebbero due comandi vocali e due conferme, opportunamente spaziate nel tempo. Per questo forse ci sarebbe qualche difficoltà pratica.

 

Per le conferme all’ordine date dopo che si è iniziato il comando non farei penalità: pensa per esempio all’ordine “disimpegno!” per il quale bisogna reagire con tempestività, dando timoni a scendere magari ancora prima di aver confermato l’ordine verbalmente (ma qui chiedo al Dir)

 

Son d’accordo anche di premiare il FEEDBACK verbale alla corretta esecuzione dell’ordine, ma senza essere troppo fiscale.

Infatti, usando per un po’ il simulatore ti accorgerai che alcuni comandi richiedono un mantenimento nel tempo, come per esempio mantenere quota periscopica, scendere con una bolla costante, oppure mantenere una quota assegnata, quando magari il battello non è perfettamente neutro o sei sotto il termoclino invernale e diventi pesante.

Quindi, non prevedo punti fissi al raggiungimento delle condizioni ordinate, ma punti progressivi per tutto il tempo in cui le mantieni. 

Poi, mi va bene un premio per la conferma vocale, me senza essere troppo fiscale: tu puoi chiamare la quota quando la raggiungi, ma i punti li fai se la mantieni nel tempo, con bolla a zero.

 

Infine, lasciami dissentire sul possibile blocco virtuale dei comandi prima che l’ordine sia confermato.

Infatti, i comandi raramente sono in posizione neutra, o perché si fanno piccole correzioni per mantenere quota o rotta, o perché il battello non è perfettamente bilanciato e permane una minima correzione con i timoni. 

Tu manovri sempre, ma non necessariamente per imporre una nuova condizione di quota/rotta al battello.

Quindi lasciami dire no alla tua ultima opzione. Sorry.

Nell’insieme ci sono però un bel po’ di buone idee che varrebbe la pena implementare.

[S513]

Diventa una "no ending story"!!!!!

[Ocean's One*]

non lo sapevi? 

 

(qui però parliamo della versione virtuale, appena data a Carmagnola...)