Autore Topic: PPT raddiomobile traffic capture API server per applicazione cobot ?  (Letto 70 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline solyarisoftware

  • Newbie
  • *
  • Post: 4
  • Karma: 0

Buongiorno,

lo so, il titolo del post è criptico e può sembrare delirante.

BTW, questo è il mio primo post in questo forum. Di radio ne capisco poco.
Mi occupo, come ricercatiore, di chatbot/voicebot/assistenti vocali, ovvero di applicazioni "robot" che parlano con un utente umano dialogando, a voce. Per chi fosse interessato interessa, il mio blog è: www.convcomp.it e sono attivo su questi temi su twitter: www.twitter.com/solyarisoftware

Cosa c'entra il radio mobile, direte!?
Ci arrivo tra poco, esponendovi il problema/richiesta di suggerimenti.

Voglio, in ambito di ricerca/attività lavorativa, far parlare un operatore umano in ambito industriale (cantieri navali/fabbrica/ambienti pericolosi) con una applicazione software ("un robot parlante"), in modo che l'operatore possa essere assistito nelle attività lavorative, in tempo reale. Immaginiamo che l'interfaccia sia audio: letteralmente l'operatore parla con un assistente vocale, che gli risponde e fa "cose".

Il punto aperto è il mezzo trasmissivo ed il dispositivo in dotazione all'operatore.
Non ci sarebbero problemi a fare una "app" che gira su un telefono/tablet. Ma visto il contesto, dove l'operatore guida un mezzo meccanico o comunque deve stare attento a cosa gli succede intorno, in umabiente industriale come quello in immagine qui:



ho pensato che la user experience più efficiente (opinabile) sia quella di una conversazione radio mobile con walkie-talkie, push to talk, half duplex, 1-a-1: ogni operatore ha un "canale" dedicato e parla con il cobot (che è un server multiutente che sta su un computer).   
 
Il problema è quale tecnologia radio mobile usare. E come passare sul digitale (IP).
L'ambiente in cui gli operatori si muovono è coperto da rete WIFI e quindi sarebbe ottimo usare radio WIFI-enabled. Ed esistono, direi, ma il problema è avere un "gateway" server (lasciatemi usare questo termine probabilmente scorretto) per tracciare i messaggi audio di ogni canale. Alla fine avrei bisogno di gestire

- ogni messaggio vocale in input (dall'operatore N)
- poter spedire un messaggio vocale in output (all'operatore N)

Qualche idea?
A disposizione per chiarimenti
Grazie
giorgio

Offline SimplexFM

  • Sr. Member
  • ****
  • Post: 300
  • Karma: 10
Buona serata solyarisoftware.

Rispondo brevemente, perché non usi un sistema radio/voip come ad esempio Zello, esistono anche appositi smartphome con il tasto ptt e il problema è risolto, almeno da quanto ho capito a riguardo delle tue intenzioni. In pratica alla fine tutti userebbero uno smartphone con il tasto ptt sul lato come per le ricetrasmittenti e la relativa applicazione. Rimane solo da capire come faccia il robot a premere il tasto ma se non erro su Zello dovrebbe esservi implementata la funzione vox.

Offline solyarisoftware

  • Newbie
  • *
  • Post: 4
  • Karma: 0
Grazie per la risposta, ma Zello non è una soluzione, per vari motivi:

1 handset:
Come dicevo, viste le condizioni dell'operatore, che è un tecnico/operaio che ha guanti, guida un mezzo meccanico o comunque deve guardare quello che fa con macchinari etc. l'utilizzo di un telefono/tablet è (secondo me) è una soluzione troppo "fragile", anche per l'interfaccia touch, che per quanto appaia "semplice", in cantiere, in  condizioni visive disagevoli (troppa luce/notte/pioggia) è secondo me un problema. Pertanto sto studiando una soluzione che mi sembra più "robusta", ovvero l'utilizzo di walkie-talkie dedicato alla comunicazione operatore-cobot. In quest'ultimo caso l'operatore deve solo schiacciare un bottone e parlare e Rilasciare il bottone ed ascoltare la risposta del cobot (pull mode). oppure (advanced) il cobot può contattare l'operatore per notifiche, azioni richieste, etc.
La radiomobile può cadere per terra e andare dentro una pozzanghera. E' un aggeggio che chiunque sa usare, etc. etc.

2. Zello:
Bhe non è un sistema "radio/voip". E' semmai solo un sistema web/voip come ce ne sono tanti, che mima la tradizionale esperienza di PTT analogico radioamatoriale.
Non mi piace anzitutto perché, a parte i costi (dell'opzione on-premise), si tratta di una soluzione proprietaria "black-box".
Questo non va bene anzitutto per motivi di privacy; i dati (conversazioni) tra cobot ed operatori devono essere privati all'azienda; non devono "andare su internet" (forse non l'ho detto nel post iniziale, dandolo per scontato: no-cloud / on-premise / networking su LAN !) e possibilmente sarebbe meglio che non andassero su un sw proprietario, anche se on-premise.
D'altro canto il problema di notificare le comunicazioni al cobot (il server applicativo) dovrebbe essere risolto dal fatto che Zello fornisce API websocket e quindi si fa senza problemi, direi.

Quindi, fare un sistema "come Zello" in cui i client fa PTT con un server, si fa "facilmente" con una architettura web client/server standard: il client web HTML5 manda e riceve audio messaggi ad un web server, via websocket o anche (semplicisticamente) su HTTP request. Per farla raffinata, considerando anche il video, si potrebbe usare WebRTC. Ma quello che mi sembra preferibile, per i requisiti elencati, è un sistema in cui gli operatori hanno in mano (o su cruscotto di un mezzo/poco cambia) un sistema radiomobile "robusto".

Sulla tecnologia trasmissiva (analogico->digitale/tutto già in digitale/ connessione a server) accetto suggerimenti :)

Offline SimplexFM

  • Sr. Member
  • ****
  • Post: 300
  • Karma: 10
Citazione
Bhe non è un sistema "radio/voip". E' semmai solo un sistema web/voip come ce ne sono tanti
Su questo punto però ti sbagli, Zello è conosciuto e usato sia tra i radioamatori come anche cb e in ambito pmr proprio perché avendo la funzione ptt è possibile collegare una ricetrasmittente, magari nel tuo caso meglio se usando la versione per pc, basta dotarsi di una semplice interfaccia tra la radio e il computer, in pratica hai un computer che fa da serve collegato ad una ricetrasmittente e di conseguenza tutti gli operai possono comunicare con il robot e tra loro via radio, quindi nessuno di loro userà internet e nessuno userà smartphone.

Se il problema però è anche di privacy allora lo puoi escludere ma anche sopratutto  perché sono sistemi vietati sia in banda cb che pmr/lpd.

Considerando dunque che ogni sistema radio-voip non ti sarà consentito se non sulle frequenze ad uso professionale (forse) non esistono altre soluzioni se non quella di usare direttamente delle ricetrasmittenti attivando su quella del robot la funzione vox in modo così che la radio trasmetta automaticamente in presenza della voce, a me sembra la soluzione migliore oltre che la più semplice ed efficace, poi per la privacy meglio usare delle radio dmr magari dotati cifratura.

Offline Domini

  • Full Member
  • ***
  • Post: 142
  • Karma: 2
Buona serata a tutti, io non vedo però cosa centri la questione voip e comunque legata alla rete! Se devi inviare e ricevere segnali audio, ovvero le voci degli operatori e del robot ti servono solo delle comuni ricetrasmittenti, ognuno ne avrà una e la cosa finisce li ma sempre che tu non abbia qualche altra esigenza particolare.

In tutti i casi devi considerare che nelle frequenze di libero uso la privacy non esiste e che i sistemi di criptazione non sarebbero consentiti, l’alternativa sarebbe quella di prendere una frequenze in concessione con relativi costi non proprio alla portata di tutti e che aumentano anche in base al numero delle radio utilizzate, non so poi quale range di copertura ti serve e anche qui ci sarebbe da discutere.

Ripeto, la cosa è perfino banale ma ci sono delle problematiche importanti da valutare.

Un'alternativa invece sarebbe quella di usare delle ricetrasmittenti wi-fi tipo le icom-ip100 o simili.

Offline solyarisoftware

  • Newbie
  • *
  • Post: 4
  • Karma: 0
ciao a tutti,

Citazione
Su questo punto però ti sbagli, Zello è conosciuto e usato sia tra i radioamatori come anche cb e in ambito pmr proprio perché avendo la funzione ptt è possibile collegare una ricetrasmittente,

Sì. https://zello.com/accessories/network-radios/ per esempio la Inrico T199
Nella demo vedo che questa radio si connette ad internet (via SIM/operatore telefonico) raggiungendo il server Zello evidentemente. No riesco a trovare da nessuna parte la documentazione di configurazione nè sul sito Zello nè sul sito Inrico.
Se questo tipo di radio potesse essere configurata per accedere ad un qualsivoglia sito web con un qualche protocollo standard (HTTP/websocket/boh) avrei risolto il mio problema :)


Citazione
in pratica hai un computer che fa da serve collegato ad una ricetrasmittente e di conseguenza tutti gli operai possono comunicare con il robot e tra loro via radio, quindi nessuno di loro userà internet e nessuno userà smartphone.

Preciso: il server è una applicazione su computer che comunica 1-a-1 con ogni operatore (configurazione stella) che ha un dispositivo "in mano":

operatore 1 <-> server
operatore 2 <-> server
...
operatore N <-> server

N va da 1 a ... 8/16/max qualche decina

Non prevedo al momento comunicazione radio tra gli operatori. Ogni operatore solo parla con il cobot 1-a-1, half duplex, push to talk.


Citazione
Se il problema però è anche di privacy allora lo puoi escludere ma anche sopratutto  perché sono sistemi vietati sia in banda cb che pmr/lpd.
Considerando dunque che ogni sistema radio-voip non ti sarà consentito se non sulle frequenze ad uso professionale (forse) non esistono altre soluzioni se non quella di usare direttamente delle ricetrasmittenti attivando su quella del robot la funzione vox in modo così che la radio trasmetta automaticamente in presenza della voce, a me sembra la soluzione migliore oltre che la più semplice ed efficace, poi per la privacy meglio usare delle radio dmr magari dotati cifratura.

Sulla privacy ci sono vari punti:
Internet: Sicuramente non voglio che i dati di comunicazione aziendali vadano su internet.
In locale/radio: non c'è un requisito di cifratura/criptazione o qaunt'altro per segretezza delle informazioni.  Ma avere comunicazione in chiaro su canali pubblici non è una buona idea direi :)

Sulla Legalità:
sicuramente il sistema, che adotterebbero delle aziende, deve rispettare le leggi vigenti.

Vox/PTT:
La funzionalità di ascolto continuo (e full-duplex) sono perfette in teoria, ma non vanno bene, immo, in ambiente rumoroso dove vorrei che la comunicazione fosse "pull" con richieste veloci dell'operatore. Quindo il PTT e half duplex vanno benissimo.

Connessione ricetrasmittente operatore-ricetrasmittente attaccata al computer (via audio?)
Questa cosa può andare bene solo per una demo lato UX dell'operatore. Ma non scala. Nel caso di 10 operatori dovrei avere 10 radio attaccate ad un computer :)

---

Citazione
Buona serata a tutti, io non vedo però cosa centri la questione voip e comunque legata alla rete! Se devi inviare e ricevere segnali audio, ovvero le voci degli operatori e del robot ti servono solo delle comuni ricetrasmittenti, ognuno ne avrà una e la cosa finisce li ma sempre che tu non abbia qualche altra esigenza particolare.

La rete (IP) c'entra :) L'esigenza particolare è l'architettura descritta sopra: tanti operatori parlano con una unica applicazione software server attraverso messaggi vocali. Alla fine della fiera il server maneggia file audio in ingresso ed in uscita.


Citazione
In tutti i casi devi considerare che nelle frequenze di libero uso la privacy non esiste e che i sistemi di criptazione non sarebbero consentiti, l’alternativa sarebbe quella di prendere una frequenze in concessione con relativi costi non proprio alla portata di tutti e che aumentano anche in base al numero delle radio utilizzate, non so poi quale range di copertura ti serve e anche qui ci sarebbe da discutere.

L'opzione di usare frequenze in concessione in teoria potrebbe non essere un osatcaolo (economico). Va bene "qualsiasi" sistema radio (analogico/digitale) ma ho bisogno alla fine di andare su un server (IP, direi HTTP) con messaggi vocali.

Range di copertura:
come dicevo in post e foto iniziale si tratta di operations in ambienti industriali, all'aperto tipicamante, in aree ristrette a qualche (~1/3) km quadrato max. Immagina una area di movimentazione portuale o simile.


Citazione
Un'alternativa invece sarebbe quella di usare delle ricetrasmittenti wi-fi tipo le icom-ip100 o simili.

Sì. Alle icom-ip100 ero arrivato. Come per le Inrico T199 il problema di queste radio "wifi" è che non riesco a trovare le specifiche di protocollo di connettività in rete :/


Offline SimplexFM

  • Sr. Member
  • ****
  • Post: 300
  • Karma: 10
Non sono un genio con l’inglese ma quelli del video sono radioamatori, poi considera che il più delle volte si tratta di adattamenti sperimentali di sistemi nati magai per altri scopi. Non conosco personalmente questa tipologia di telefoni camuffati da radio ma ad esempio per le citate Icom so che serve un apposito abbonamento per poter accedere ai server Icom e poter usare così il sistema. Insomma le varianti del caso sono tante.

Citazione
Se questo tipo di radio potesse essere configurata per accedere ad un qualsivoglia sito web con un qualche protocollo standard (HTTP/websocket/boh) avrei risolto il mio problema
Non puoi farlo, sono progettate per degli scopi ben precisi e null’altro, al massimo esistono gli adattamenti del caso.


Citazione
Non prevedo al momento comunicazione radio tra gli operatori. Ogni operatore solo parla con il cobot 1-a-1, half duplex, push to talk.
In questo caso le cose si complicano, servirebbero ad esempio delle radio digitali magari dmr programmate per le chiamate selettive, il problema però è che il robot non può prendere in mano la radio e decidere chi chiamare premendo gli appositi tasti.

Citazione
In locale/radio: non c'è un requisito di cifratura/criptazione o quant'altro per segretezza delle informazioni
Non so se ti ho capito bene ma faccio presente che in digitale si possono usare gli sistemi di cifratura usati ad esempio anche da whatsapp.

Citazione
La funzionalità di ascolto continuo (e full-duplex) sono perfette in teoria, ma non vanno bene, immo, in ambiente rumoroso dove vorrei che la comunicazione fosse "pull" con richieste veloci dell'operatore. Quindo il PTT e half duplex vanno benissimo
No aspetta, la funzione vox sarà usata solo dal server proprio perché non ha le mani :) le persone invece schiacceranno il pulsante ptt.

Citazione
Connessione ricetrasmittente operatore-ricetrasmittente attaccata al computer (via audio?) Questa cosa può andare bene solo per una demo lato UX dell'operatore. Ma non scala. Nel caso di 10 operatori dovrei avere 10 radio attaccate ad un computer
Di radio collegata al server ne basta una, l’unico problema rimane l’impossibilità di non far comunicare tra loro gli operatori. Di fatto la parte web non esiste più, esiste solo la parte radio, poi cosa fa il serve dal lato web non ha alcuna importanza essendo due cose totalmente indipendenti tra loro.

Citazione
La rete (IP) c'entra  L'esigenza particolare è l'architettura descritta sopra: tanti operatori parlano con una unica applicazione software server attraverso messaggi vocali. Alla fine della fiera il server maneggia file audio in ingresso ed in uscita.
Se il sistema funziona in modo selettivo per ogni operatore gestendo log, orari, posizione e non so cosa allora sappi che via radio non disporrai più di tali funzionalità essendo semplicemente un gestione del flusso audio ...appunto.

Alla fine però stiamo parlando di un sistema su misura che deve disporre di determinate peculiarità, di per se il collegamento tra radio e server è un gioco da ragazzi, basta una scheda audio e una piccola interfaccia per la commutazione tx/rx, il vero problema è la necessità di gestione in base alle tue esigenze.

Offline charles_forever

  • Full Member
  • ***
  • Post: 201
  • Karma: 10
  • Sesso: Maschio
Scusami, buongiorno, ti do del tu perché io sono un dipendente CEDACRI, quindi l'informatica dà da mangiare pure a me!...
Vorrei chiederti perché parli di "messaggi vocali". Se tu usassi delle radio digitali, ogni messaggio potrebbe essere memorizzato, anche solo per poco tempo, mentre messaggi vocali in analogico dovrebbero essere "registrati" fisicamente, qualunque sia il substrato, nastro magnetico, stato solido. Un'alternativa potrebbe essere quella di far partire messaggi in analogico dall'operatore, poi digitalizzati ed eventualmente salvati. Sempre usando radio in digitale, il VOX potrebbe essere pienamente operativo anche in ambienti molto rumorosi, poiché si possono effettuare filtrature in digitale che tagliano le frequenze audio indesiderate come lame di coltello. Poi ogni messaggio in partenza dal cobot conterrebbe già tutte le info necessarie per essere ricevuto solo dall'operatore chiamato. Inoltre un sistema multiplex digitale può inviare e ricevere contemporaneamente da e per più utenti con una banda base molto più stretta che non nel caso analogico, anche senza criptature, ma senza possibilità che A ascolti i messaggi da e per B, ecc.
Scusa se mi sono espresso un tanto al chilo, diciamo con unità di misura naso-spannica, in realtà il mio settore è il software bancario e para-bancario.

Saluti,

Charles

Offline solyarisoftware

  • Newbie
  • *
  • Post: 4
  • Karma: 0
Ciao Charles,

Citazione
Vorrei chiederti perché parli di "messaggi vocali".

perché, lato computer questo cobot è un server che deve:
1- elaborare dei file audio in input (contenente il parlato di un operatore)
2- rispondere con un file audio in output (risposta all'operatore come parlato con voce sintetica).

la catena è in verità questa:

file audio in input ->
ASR (speech recognition)
-> testo input ->

dialog manager (cobot) ->

-> messaggio testo in ouptut ->
TTS (text to voice)
-> file audio in output


Citazione
Se tu usassi delle radio digitali, ogni messaggio potrebbe essere memorizzato, anche solo per poco tempo, mentre messaggi vocali in analogico dovrebbero essere "registrati" fisicamente, qualunque sia il substrato, nastro magnetico, stato solido. Un'alternativa potrebbe essere quella di far partire messaggi in analogico dall'operatore, poi digitalizzati ed eventualmente salvati.


Sì, quale che sia il canale trasmissivo radio (analogico->digitale o solo digitale, ed è una cosa da definire), serve un "qualcosa (lo chiamerei "gateway") che interfacci il sistema di comunicazione con l'applicazione "conversazionale" su computer, che va interfacciata con qualche protocollo (IP/HTTP/da definire) dove i payloads sono messaggi audio (vocali).


Citazione
il VOX potrebbe essere pienamente operativo anche in ambienti molto rumorosi, poiché si possono effettuare filtrature in digitale che tagliano le frequenze audio indesiderate come lame di coltello.

Se per VOX intendi (intendete) questo: https://en.wikipedia.org/wiki/Voice-operated_switch
è per me un "di più". L'automatismo del riconoscimento del parlato non è un requisito necessario anzi, io preferisco il push to talk, perché è meglio che  non ci siano false detection ma quando l'operatore ha bisogno del cobot questo deve rispondere nel minimo tempo. Quindi premere il bottone per parlare mi sta bene.

 
Citazione
Poi ogni messaggio in partenza dal cobot conterrebbe già tutte le info necessarie per essere ricevuto solo dall'operatore chiamato. Inoltre un sistema multiplex digitale può inviare e ricevere contemporaneamente da e per più utenti

Vada per il sistema multiplex digitale. Mi puoi dare un esempio di un apparecchio/sistema che realizzo proprio questo?

Offline charles_forever

  • Full Member
  • ***
  • Post: 201
  • Karma: 10
  • Sesso: Maschio
 Per esempio i sistemi digitali usati proprio dai radioamatori, hanno la possibilità di creare dell "stanze", entro le quali sono uno o più operatori, il sistema è quindi in grado di operare da A a B, da uno a molti, ecc.
L'unico sistema open in campo amatoriale è il D-star di ICOM, che io sappia, oppure il sistema Motorola, DMR, che non è open, ma è talmente usato, anche in campo pro, da essere forse la prima scelta.

Charles

Offline SimplexFM

  • Sr. Member
  • ****
  • Post: 300
  • Karma: 10
Re:PPT raddiomobile traffic capture API server per applicazione cobot ?
« Risposta #10 il: Ven 22 Mag, 16:47 2020 »
Ciao charles_forever. Non so se ho capito male io ma D-STAR e C4FM sono sistemi proprietari, il DMR invece è open source.

Non sono certo di aver capito le reali intenzioni di solyarisoftware ma credo però che stiamo parlando di un sistema che non esiste e di conseguenza va creato in base alle proprie necessità e riguardando appunto anche la parte radio andiamo assolutamente oltre l’ambito puramente informatico, come minimo servirebbe un team di esperti almeno che non salti fuori l’uovo di colombo.

Offline charles_forever

  • Full Member
  • ***
  • Post: 201
  • Karma: 10
  • Sesso: Maschio
Re:PPT raddiomobile traffic capture API server per applicazione cobot ?
« Risposta #11 il: Ven 22 Mag, 17:13 2020 »
Forse ho capito male io, ad ogni modo il senso è lo stesso.
Ovvio che il sistema vada creato, con radio già esistenti non so se tutti i parametri possano essere rispettati.
Ad ogni modo, è sufficiente avere un telaio UHF in FM o altri sistemi di modulazione, sul quale collegare la parte logica.

Charles

Offline SimplexFM

  • Sr. Member
  • ****
  • Post: 300
  • Karma: 10
Re:PPT raddiomobile traffic capture API server per applicazione cobot ?
« Risposta #12 il: Ven 22 Mag, 18:38 2020 »
Nel complesso della situazione ci sono però troppi “non va bene”. Gli smartphone sono troppo delicati, software tipo Zello non garantiscono la privacy, la funzione vox non è adatta, gli operatori non devono sentirsi tra loro, le comunicazioni in chiaro via radio non devono esserci ecc.

A questo punto non vedo vie di sbocco, ciò che andrebbe tecnicamente bene non va bene comunque per un motivo o per l’altro e non so che cosa vi possa rimanere.

 

free countersfree countersfree counters