Sono tornato a un computer!
Come ho detto in questo commento , ROS non è generalmente obbligatorio. ROS è una delle tante piattaforme, famosa soprattutto per il fatto che Willow Garage offre robot gratuiti a un certo punto nel tempo a chiunque abbia scritto il maggior numero di moduli ROS. Detto questo, non è la migliore piattaforma possibile e non è certamente niente di particolarmente speciale. In particolare, il suddetto concorso ha portato a molti moduli di bassa qualità solo per aumentare i numeri.
Nel tempo, la qualità dei moduli ROS è migliorata e ce ne sono anche molti. Usando ROS quindi, hai il vantaggio di riutilizzare molto di ciò che è già stato fatto. Puoi leggere qui alcuni motivi per cui potresti voler usare ROS.
Con questo in mente, dovresti cercare anche gli effetti collaterali.
Controllo distribuito
Con ROS hai molti nodi che dialogano tra loro attraverso la rete. Questo a volte è buono e facile, ma generalmente provoca un ritardo molto variabile nella ricezione dei messaggi. Di conseguenza, dovresti avere un grande ritardo di controllo per assicurarti che tutti i messaggi arrivino, il che significa che non puoi reagire velocemente agli eventi, il che a sua volta significa che devi spostare il tuo robot a velocità più basse per non perdere quegli eventi.
Che ci crediate o no, le persone eseguono effettivamente il controllo del robot tramite ROS ( MoveIt! È il nome del relativo set di componenti). Lento. Unsafe. Ma facile!
Non in tempo reale
Anche se non distribuito, ROS non è una piattaforma in tempo reale. Ciò significa che sei a completa discrezione del kernel Linux per pianificare le tue attività in qualsiasi momento lo ritenga opportuno. Questo è ok per alcune applicazioni, ma non per altre. Quindi è necessario esaminare le proprie esigenze. Devi avere la garanzia che il tuo compito finisca entro un lasso di tempo noto? In tal caso, è necessario un sistema in tempo reale.
Hosted Runtime Environment
Un altro punto da considerare è che, sebbene ROS sia un protocollo generale di comunicazione, è essenzialmente supportato solo per ambienti ospitati. Hosted significa che il codice gira su un kernel, invece di un indipendente, il che significa che il codice controlla direttamente l'hardware (ad esempio, su un microcontrollore).
Se la tua applicazione di robotica viene eseguita vicino all'hardware, e quindi avresti bisogno di un programma che gira su un microcontrollore, ROS non ti è di aiuto.
Blocco piattaforma
Ultimo ma non meno importante, lo sviluppo di ROS comporta un blocco della piattaforma. Ciò significa che se in futuro, per una ragione o per l'altra, decidessi di basare il tuo lavoro su un'altra piattaforma robotica, come OROCOS, YARP, ecc., Ciò sarebbe atroce.
Saresti anche in qualche modo bloccato su Linux. Linux è il migliore, senza dubbio, ma un giorno potresti finire per dover supportare un altro sistema, come QNX, VxWorks ecc., E avresti problemi anche lì.
Se stai scrivendo per microcontrollori, dimentica ROS. Se stai scrivendo moduli di alto livello, consiglio vivamente di scrivere codice portatile. Ad esempio, supponiamo di aver sviluppato un nuovo sensore e di voler scrivere un modulo che acquisisca i dati da questo sensore, che è collegato al computer tramite il bus CAN.
Quello che potresti fare in questa situazione è scrivere una libreria indipendente, con funzioni in grado di lavorare con il tuo sensore e acquisire dati. Si potrebbe anche pensare di generare un thread nella libreria che acquisisce e accoda periodicamente i dati.
Una volta che hai questa libreria di helper, sei libero di scrivere una CLI, una GUI, un modulo ROS, un modulo OROCOS, un modulo YARP, collegarti a Matlab o qualsiasi altra cosa tu voglia usare per interagire con il tuo sensore.
Nota finale: quello che ho detto qui è generalmente applicabile a tutte le piattaforme di robotica e non solo ai ROS.