Rover Arduino/Xbee ritardo

Salve a tutti, sto realizzando un rover con arduino mega 2560. Sto usando due schede, una sulla console di controllo che leggendo gli input dell'utente invia tramite xbee al secondo arduino (sul rover) i movimenti da compiere. La mia domanda è: c'è qualche possibilità che i movimenti risultino poco fluidi scrivendo il codice "normalmente"? Il secondo arduino dovrebbe leggere la seriale e in base al dato ricevuto leggere e inviare i dati dei sensori o muovere i motori/braccio meccanico. Per risolvere questo eventuale problema ho letto di uno scheduler sviluppato da un moderatore (se non erro), leOS, ma non ho trovato nessuna guida o spiegazione su come utilizzarlo, a quanto ho capito si usa come un thread giusto?
grazie in anticipo per l'aiuto e se non mi sono spiegato correttamente scusatemi.

Borgonovo

Se il codice contiene dei delay o cicli while i movimenti potrebbero non risultare fluidi poichè il micro aspetta in pausa o all'interno di un ciclo.
Riguardo al LeOS c'è l'articolo sul sito di Leonardo (l'autore della libreria) --> http://www.leonardomiliani.com/2012/leos-un-semplice-so-per-arduino/#wpfb-file-38

ciao PaoloP, grazie per la risposta, l'artico sul sito di Leonardo lo avevo già letto, per quanto riguarda la fluidità molto probabilmente il codice dovrà contenere cicli o delay. A parer tuo con LeOS dovrei riuscire a risolvere il problema?

il punto non è evitare cicli e delay, ma usare sistemi come il leos per "scedulare" cose da fare nel futuro, e non "metterni in attesa" per esempio con un loop infinito. Certo, poi questi compiti devono durare poco, altrimenti saranno loro a generare questa lag.

Quindi; lato arduino, ogni compito che impiega più di un certo tot (direi 10ms), o necessita dei delay, va spezzato in task più piccoli; il loop() semplicemente controlloerà la presenza di input (schedulando o mdofificando la scedulazione in base all'input), aggiornetà lo stato della schedulazione in attesa di segnali/timeut, ed infine eseguirà quei task segnati come pronti, ma facendo attenzione a non eseguirni troppi alla volta, insomma questo ciclo non deve superare i 20/50ms, altrimenti si inizia a notare una certa rettività "in ritardo", cosa che già è presente a causa della comunicazione pc->xbee -> xbee -> arduino

Grazie per la risposta lesto! il "problema" è quindi cercare le istruzioni piu "veloci" da eseguire. Appena sistemo il codice definitivo faccio delle prove, grazie a tutti dell'aiuto!

no, arduino esegue istruzioni a livello CPU alla velocità di centinaia di NANOsecondi, direci esegue circa metà istruzioni al secondo rispetto al suo clock, che normalmente è di 16MHz,ovvero 16.000.000 impulsi al secondo.

però spesso bisogna fermarsi ed ATTENDERE qualcosa; magari che una lettura completi, che un sensore risponda, che l'untente inserisca l'input, etc.. e sono proprio questi i tempi da eliminare, o meglio, da spezzare in piccoli task.