Pubblicata seconda Bozza regolamento ENAC

[lambdafly]

Originalmente inviato da ElNonino

Vediamo di dare un valore a "tempo reale", leggetevi questo e poi ne riparliamo: Il tempo di reazione

Bello, bello tutto ma non c'entra assolutamente nulla con la definizione di tempo reale.

Ed anche l'ultima scaglia di sapone è finita.

[il_Zott]

Originalmente inviato da sloper_marco

Se permettete riscrivo la definizione secondo quello che, a mio parere, l'estensore aveva in testa:



Sistema autonomo

: SAPR per il quale il pilota non ha possibilità di controllare il volo del mezzo intervenendo in qualsiasi momento.



meglio?



L'aeromodellista può riprendere il controllo del mezzo in qualsiasi momento?

- NO -> volo autonomo (non consentito)

- SI -> volo non autonomo (consentito)

Beh
Effettivamente quest'interpretazione non fa una piega, a prescindere dal real time o meno...



Inviato dal mio iPhone utilizzando Tapatalk

[sloper_marco]

Originalmente inviato da sub53

Ovviamente non mi sembra che ci possano essere interpretazioni diverse.... almeno in italiano.

Beh, sai, di assoluto a 'sto mondo esiste ben poco; quasi tutto è relativo, in particolar modo nel campo del diritto la cui famosa "certezza" è sempre stata solo una chimera. Se poi il diritto è scritto ad cazzum, come nel caso di specie, anche quella flebile certezza ne esce massacrata.

Però, partendo dall'assunto che è impossibile "quantificare" il "tempo reale" (il tempo zero non esiste e quello massimo non è definito) e volendo dare un senso ad una norma che altrimenti risulterebbe inapplicabile, direi che l'interpretazione "tempo reale"="in qualsiasi momento" mi pare sensata, quanto meno perchè chiude, non dico il cerchio, ma almeno un abbozzo di figura.

my 2 cents

[rebrule]

Originalmente inviato da sub53

Il termine real time ha diversi significati a secondo del campo di utilizzo, solo in alcuni rarissimi settori dell' informatica il significato è quello che gli attribuisci e visto che il settore di applicazione della normativa ENAC è ben diverso credo che sia tu a non conoscere il significato di quel termine nel caso specifico.


P.S.
Prima di darmi dell' ignorante informati ... e guarda come viene usato il termine "real time " in generale, anche in informatica, e non solo nel tuo particolarissimo esempio !

non diciamo eresie.
https://it.wikipedia.org/wiki/Real-time

Il real time indica per definizione un tempo massimo entro cui il comando deve essere eseguito.
Il termine Real time viene battezzato nell'ambito dell'automazione industriale in cui è fondamentale sapere entro quanto tempo un comando viene eseguito o un sensore viene letto, senza questo tutte le regolazioni possibili e immaginabili sono inutili.

Tutto il resto sono definizioni mutuate e sbagliate.
Così come è una strunzata parlare di real time su macchine che "lavorano" ricevendo comandi da un tablet tramite protocolli wifi su cui "magari" si riceve un video in fullsupermegahd.
Principalmente perché queste standard di comunicazioni sono a pacchetto e prevedono per definizione perdita di dati, quindi possibile perdita di comandi.
Aggiungiamo che poi che la banda passante e il fatto che gli stessi tablet non hanno sempre come priorità quella di dare retta al programma in esecuzione come dovrebbe essere richiesto invece da un dispositivo in real time.
Quindi è chiaro che i vari dronetti da supermercato non possono essere per definizione macchine real time.
Sono oggetti che stazionano in modo autonomo e che "ogni tanto" (relativamente alla definizione in automazione industriale di real time= l'unica corretta) ricevono consigli su dove devono andare da un programmino che gira su di un tablet collegato tramite wifi.
Magari l'elettronica di bordo di questi dronetti da supermercato potrebbe essere definita in real time, ma di fatto questo li configura come oggetti non direttamente comandati dall'utente.

Differente il concetto di trasmissione di comandi radio indipendentemente dalla frequenza utilizzata.
In questo caso ogni tot millisencondi (intervallo fisso definito e non mutabile durante le operazioni) arriva un comando che indica cosa deve fare l'oggetto.

[Giulianoo]

Originalmente inviato da MAXZANI

Dato che il failsafe non deve salvare il modello ma limitare i danni che potrebbe provocare...........il motore va spento e i servi a fondo corsa...il modello non si allontana troppo e .una discesa in vite avviene a velocità verticale ridotta ........poi....per carità. ...il mondo è pieno di imbecilli che farebbero diversamente ma qui si entra in un discorso in cui un aeromodellista dovrebbe avere un minimo di cultura aeronautica........

ti quoto! forse Zott intendeva un failsafe con rth! un failsafe puro deve (o dovrebbe) far scendere il modello il più dolcemente possibile

[ElNonino]

Originalmente inviato da rebrule

non diciamo eresie.
https://it.wikipedia.org/wiki/Real-time

...
Quindi è chiaro che i vari dronetti da supermercato non possono essere per definizione macchine real time.
Sono oggetti che stazionano in modo autonomo e che "ogni tanto" (relativamente alla definizione in automazione industriale di real time= l'unica corretta) ricevono consigli su dove devono andare da un programmino che gira su di un tablet collegato tramite wifi.
Magari l'elettronica di bordo di questi dronetti da supermercato potrebbe essere definita in real time, ma di fatto questo li configura come oggetti non direttamente comandati dall'utente.

Su questo non sono del tutto d'accordo: per fare volo 3D con un eli R.C. i comandi inviati dal pilota hanno, con le radio tradizionali, un refresh-rate di 20ms (10ms le più moderne) per leggere una IMU a 10 DOF basta meno di 1ms utilizzando una SPI a 4MHz e poco più per fare quattro calcoli e controllare 4....8 ESC, quindi per il volo 'assistito' basta anche un micro da pochi euro ed un S.O. a semplice schedulatore per garantire che i comandi trasmessi vengano ricevuti e gestiti correttamente.

Se poi consideriamo che un multirotore è intrinsecamente stabile se anche i comandi venissero gestiti ogni 100ms poco cambierebbe, le cose si complicano se aggiungiamo GPS, telemetrie, cassi e massi vari e vogliamo fare tutto con un Arduino....

Anche nel settore industriale i comandi delle interfacce HMI sono letti intorno ai 100ms e nei simulatori di volo reali (anche quelli del F16) è considerato accettabilissimo un tempo di risposta comando -> attuatore idraulico di 12ms, i migliori lavorano ad 8ms; stesso discorso vale per gli airbag, abs, etc.

La scarsa affidabilità dei 'droni' hobbistici e pseudo-professionali risiede nella bassa qualità della componentistica usata (una IMU da 4$ non da garanzie come una da 40$ o da 1400$), nella non curata ingegnerizzazione (connettori della lippa ed altro) e nei firmware 'hobbistici' ed open source dove molti possono metterci mano senza sapere cosa vanno a modificare.

Per alcune caratteristiche non è che il CAN-BUS (per il solo fatto di essere multi-master) od anche l'Ethernet Industriale siano poi così real-time o, meglio deterministici.

[sub53]

Originalmente inviato da rebrule

non diciamo eresie.
https://it.wikipedia.org/wiki/Real-time

Il real time indica per definizione un tempo massimo entro cui il comando deve essere eseguito.
Il termine Real time viene battezzato nell'ambito dell'automazione industriale in cui è fondamentale sapere entro quanto tempo un comando viene eseguito o un sensore viene letto, senza questo tutte le regolazioni possibili e immaginabili sono inutili.

Tutto il resto sono definizioni mutuate e sbagliate.
Così come è una strunzata parlare di real time su macchine che "lavorano" ricevendo comandi da un tablet tramite protocolli wifi su cui "magari" si riceve un video in fullsupermegahd.
Principalmente perché queste standard di comunicazioni sono a pacchetto e prevedono per definizione perdita di dati, quindi possibile perdita di comandi.
Aggiungiamo che poi che la banda passante e il fatto che gli stessi tablet non hanno sempre come priorità quella di dare retta al programma in esecuzione come dovrebbe essere richiesto invece da un dispositivo in real time.
Quindi è chiaro che i vari dronetti da supermercato non possono essere per definizione macchine real time.
Sono oggetti che stazionano in modo autonomo e che "ogni tanto" (relativamente alla definizione in automazione industriale di real time= l'unica corretta) infatti stiamo parlando di ben altro ricevono consigli su dove devono andare da un programmino che gira su di un tablet collegato tramite wifi.
Magari l'elettronica di bordo di questi dronetti da supermercato potrebbe essere definita in real time, ma di fatto questo li configura come oggetti non direttamente comandati dall'utente.

Differente il concetto di trasmissione di comandi radio indipendentemente dalla frequenza utilizzata.
In questo caso ogni tot millisencondi (intervallo fisso definito e non mutabile durante le operazioni) arriva un comando che indica cosa deve fare l'oggetto.

Hai provato a vedere quanti eretici ci sono digitando real time e cosa definisce con questo termine la maggior parte dei siti , ovviamente tutti ignoranti ?

Poi, giusto per puntualizzare, quello che scrivi è errato in quanto la certezza dell' intervallo tra un frame di comando ed il successivo è solo in trasmissione e non in ricezione infatti i comandi delle nostre radio non hanno tempi certi di ricezione ed esecuzione del comando... durante la decodifica se il frame non viene riconosciuto non viene eseguito, quindi non puoi essere certo che arrivi un comando ogni tot ms.

[rebrule]

Originalmente inviato da ElNonino

Su questo non sono del tutto d'accordo: per fare volo 3D con un eli R.C. i comandi inviati dal pilota hanno, con le radio tradizionali, un refresh-rate di 20ms (10ms le più moderne) per leggere una IMU a 10 DOF basta meno di 1ms utilizzando una SPI a 4MHz e poco più per fare quattro calcoli e controllare 4....8 ESC, quindi per il volo 'assistito' basta anche un micro da pochi euro ed un S.O. a semplice schedulatore per garantire che i comandi trasmessi vengano ricevuti e gestiti correttamente.

Se poi consideriamo che un multirotore è intrinsecamente stabile se anche i comandi venissero gestiti ogni 100ms poco cambierebbe, le cose si complicano se aggiungiamo GPS, telemetrie, cassi e massi vari e vogliamo fare tutto con un Arduino....

Anche nel settore industriale i comandi delle interfacce HMI sono letti intorno ai 100ms e nei simulatori di volo reali (anche quelli del F16) è considerato accettabilissimo un tempo di risposta comando -> attuatore idraulico di 12ms, i migliori lavorano ad 8ms; stesso discorso vale per gli airbag, abs, etc.

La scarsa affidabilità dei 'droni' hobbistici e pseudo-professionali risiede nella bassa qualità della componentistica usata (una IMU da 4$ non da garanzie come una da 40$ o da 1400$), nella non curata ingegnerizzazione (connettori della lippa ed altro) e nei firmware 'hobbistici' ed open source dove molti possono metterci mano senza sapere cosa vanno a modificare.

Per alcune caratteristiche non è che il CAN-BUS (per il solo fatto di essere multi-master) od anche l'Ethernet Industriale siano poi così real-time o, meglio deterministici.

Semplicemente non è questione di velocità di invio del comando, ma di certezza che entro un tot tempo un comando venga inviato.
Inoltre stai confondendo quelli che sono dei comandi automatici di autoregolazione (stabilità mantenimento della quota ecc.ecc. ) con quelli che sono i comandi utente.
Per il 90% del tempo l'oggetto in volo farà quello che i sistemi di autocontrollo gli dicono di fare e tenterà di andare dove gli viene detto di andare.
questo perché non stiamo parlando di un sistema intrinsecamente stabile, non è in quiete continua , ma in continua regolazione : decisamente diversa la questione.
Non hai certezza del fatto che il comando che tu credi di inviare venga davvero inviato e soprattutto che sia inviato entro un tempo certo : queste è la grande differenza tra un sistema comandato in real time e questi oggetti.
Poi se vogliamo parlare di sistemi di regolazione industriali e tempi certi si apre un mondo.

Originalmente inviato da sub53

Hai provato a vedere quanti eretici ci sono digitando real time e cosa definisce con questo termine la maggior parte dei siti , ovviamente tutti ignoranti ?

Poi, giusto per puntualizzare, quello che scrivi è errato in quanto la certezza dell' intervallo tra un frame di comando ed il successivo è solo in trasmissione e non in ricezione infatti i comandi delle nostre radio non hanno tempi certi di ricezione ed esecuzione del comando... durante la decodifica se il frame non viene riconosciuto non viene eseguito, quindi non puoi essere certo che arrivi un comando ogni tot ms.

quanti siano ignoranti non è un mio problema.
La definizione real time, purtroppo, non la ho inventata io o me ne starei sopra ad una spiaggia e sotto ad un ombrellone.
Vedi sopra per il resto.
Nel caso dei multi rotori non solo non hai la certezza che il comando venga recepito in maniera corretta, eseguito in un tot di tempo ma nemmeno che venga inviato in real time.
Quindi a prescindere questi multi-rotori comandati da tablet non possono essere definite macchine real time.

Voglio dire non devo convincere nessuno, ma sta cosa di "comandare" un oggetto che vola con un sistema wifi onestamente qualche dubbio lo mette, considerando che il protocollo usato è nato per scopi decisamente diversi.

[ranox]

ma se volete continuare...



Robbè

[sub53]

Originalmente inviato da rebrule

Semplicemente non è questione di velocità di invio del comando, ma di certezza che entro un tot tempo un comando venga inviato.
Inoltre stai confondendo quelli che sono dei comandi automatici di autoregolazione (stabilità mantenimento della quota ecc.ecc. ) con quelli che sono i comandi utente.
Per il 90% del tempo l'oggetto in volo farà quello che i sistemi di autocontrollo gli dicono di fare e tenterà di andare dove gli viene detto di andare.
questo perché non stiamo parlando di un sistema intrinsecamente stabile, non è in quiete continua , ma in continua regolazione : decisamente diversa la questione.
Non hai certezza del fatto che il comando che tu credi di inviare venga davvero inviato e soprattutto che sia inviato entro un tempo certo : queste è la grande differenza tra un sistema comandato in real time e questi oggetti.
Poi se vogliamo parlare di sistemi di regolazione industriali e tempi certi si apre un mondo.



quanti siano ignoranti non è un mio problema.
Sarà/ è sbagliato dal tuo punto di vista ma la realtà è diversa...
La definizione real time, purtroppo, non la ho inventata io o me ne starei sopra ad una spiaggia e sotto ad un ombrellone.
Vedi sopra per il resto.
Nel caso dei multi rotori non solo non hai la certezza che il comando venga recepito in maniera corretta, eseguito in un tot di tempo ma nemmeno che venga inviato in real time.
Quindi a prescindere questi multi-rotori comandati da tablet non possono essere definite macchine real time.
Voglio dire non devo convincere nessuno, ma sta cosa di "comandare" un oggetto che vola con un sistema wifi onestamente qualche dubbio lo mette, considerando che il protocollo usato è nato per scopi decisamente diversi.

Non capisco cosa collega il wifi al modellismo, alla definizione di volo autonomo ed al mio post, probabilmente non hai letto bene cosa ho scritto nei post precedenti...