Estoy de vuelta en una computadora!
Como dije en este comentario , ROS generalmente no es obligatorio. ROS es una plataforma entre muchas, famosa principalmente debido a que Willow Garage regala robots gratuitos en algún momento a quien escribió la mayoría de los módulos ROS. Dicho esto, no es la mejor plataforma posible, y ciertamente no es nada demasiado especial. En particular, dicho concurso resultó en una gran cantidad de módulos de baja calidad solo para aumentar los números.
Con el tiempo, la calidad de los módulos ROS ha mejorado y también hay muchos de ellos. Usando ROS, por lo tanto, tiene la ventaja de reutilizar mucho de lo que ya está hecho. Puede leer aquí algunas razones por las que puede querer usar ROS.
Con eso en mente, también debes estar atento a los efectos secundarios.
Control distribuido
Con ROS, tiene muchos nodos que se comunican entre sí a través de la red. Esto a veces es bueno y fácil, pero generalmente resulta en un retraso muy variable en la recepción de mensajes. Como resultado, tendría que tener un gran retraso de control para asegurarse de que todos los mensajes lleguen, lo que significa que no puede reaccionar rápidamente a los eventos, lo que a su vez significa que debe mover su robot a velocidades más lentas para no perderse esos eventos.
Lo creas o no, la gente realmente controla el robot a través de ROS ( MoveIt! Es el nombre del conjunto de componentes relevante). Lento. Inseguro. ¡Pero fácil!
No en tiempo real
Incluso cuando no se distribuye, ROS no es una plataforma en tiempo real. Eso significa que tiene total discreción del kernel de Linux para programar sus tareas en cualquier momento que lo considere conveniente. Esto está bien para algunas aplicaciones, pero no está bien para otras. Por lo tanto, debe analizar sus propios requisitos. ¿Necesita tener una garantía de que su tarea finalizará dentro de un marco de tiempo conocido? Si es así, necesita un sistema en tiempo real.
Entorno de tiempo de ejecución alojado
Otro punto a considerar es que, si bien ROS es un protocolo general de comunicación, esencialmente solo es compatible con entornos alojados. Hospedado significa que el código se ejecuta en la parte superior de un kernel, en lugar de ser independiente, lo que significa que el código controla directamente el hardware (por ejemplo, en un microcontrolador).
Si su aplicación de robótica se ejecuta cerca del hardware y, por lo tanto, necesitaría un programa que se ejecute en un microcontrolador, ROS no lo ayudará.
Bloqueo de plataforma
Por último, pero no menos importante, desarrollar para ROS da como resultado un bloqueo de plataforma. Esto significa que si en el futuro, por una razón u otra, decide basar su trabajo en otra plataforma robótica, como OROCOS, YARP, etc., sería insoportable.
También estaría algo bloqueado para Linux. Linux es el mejor, sin duda, pero un día puede terminar teniendo que soportar otro sistema, como QNX, VxWorks, etc., y también tendrá problemas allí.
Si estás escribiendo para microcontroladores, entonces olvídate de ROS. Si está escribiendo módulos de alto nivel, le recomiendo escribir código portátil. Por ejemplo, supongamos que ha desarrollado un nuevo sensor y desea escribir un módulo que adquiera datos de este sensor, que está conectado a su computadora a través del bus CAN.
Lo que podría hacer en esta situación es escribir una biblioteca independiente, con funciones que puedan trabajar con su sensor y adquirir datos. Incluso podría pensar en generar un hilo en la biblioteca que adquiere y pone en cola datos periódicamente.
Una vez que tenga esta biblioteca auxiliar, puede escribir una CLI, GUI, módulo ROS, módulo OROCOS, módulo YARP, conectarse a Matlab o cualquier otra cosa que quiera usar para interactuar con su sensor.
Nota final: lo que he dicho aquí es generalmente aplicable a todas las plataformas de robótica y no solo a ROS.