Citazione:
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.
Citazione:
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.