Voy a construir un pequeño sistema de robot , y parece que ROS sirve un buen marco para controlar y programar el sistema.

Sin embargo, me pregunto cuál es la mejor práctica para administrar los componentes de mi robot.

• ¿Tiene sentido poner todos los sensores en un nodo?

• ¿Debo colocar los sensores del mismo tipo en un nodo o es mejor tener un nodo para un sensor?

• ¿Es una buena práctica tener algún tipo de nodo manejador, que reciba información de los sensores y dirija los actuadores correspondientes o los nodos actuadores y los nodos sensores deberían comunicarse directamente?

1. Nodos sensores fusionados y nodos actuadores con manejador

2. Sensor único y nodos de actuador con manejador

3. Comunicación directa

Para mí, supongo que lo mejor es tener algún tipo de controlador, que maneje la comunicación entre sensores y actuadores y tenga un nodo para cada elemento del robot (como en la figura 2), porque el sistema está de esta manera acoplado libremente y puede extenderse fácilmente, pero quiero saber cuál es su opinión.

Respuesta muy corta: 2

Sensores

En cuanto a si leer de los sensores en un solo nodo o cada uno por separado, debe hacerse esta pregunta:

¿Los sensores no tienen sentido sin el otro?

Esta pregunta pregunta si los sensores están estrechamente acoplados o no. Por ejemplo, supongamos que tiene un sensor sensible a la temperatura (y necesita compensarlo). Agrega un sensor de temperatura principalmente para fijar el valor del otro sensor. En este escenario, tiene sentido leer ambos valores al mismo tiempo, ya que están estrechamente acoplados. De hecho, sin las lecturas del sensor de temperatura, las lecturas del sensor original son inútiles.

Por otro lado, si los sensores son útiles individualmente, manténgalos en nodos separados. Esto tiene muchos beneficios:

• Los nodos se pueden ejecutar en procesadores separados
• Los nodos pueden reutilizarse en futuros robots
• La falla en la comunicación con un nodo no hace caer todo el sistema
• El reinicio de la adquisición desde una placa de sensor defectuosa se puede hacer por separado de los demás.

De hecho, si necesita alguno de los beneficios anteriores, tendría que ir con nodos separados, incluso si los sensores están estrechamente acoplados, pero eso generalmente no sucede.

Actuadores

Esto es análogo.

¿Los actuadores no tienen sentido sin el otro?

Por ejemplo, si está diseñando una muñeca con tendones robóticos donde para cada tendón (por cualquier razón) dos motores son responsables de trabajar simultáneamente para mover una articulación en una u otra dirección, entonces tenerlos en el mismo nodo hace mucho más sentido que separado.

Por otro lado, donde los actuadores son independientes (caso común), tiene sentido tener un nodo para cada actuador. En ese caso, cada uno podría colocarse en un nodo diferente. Además de los mismos beneficios exactos que con los sensores, existe este beneficio adicional:

• Si un actuador está parado (por cualquier razón), los otros actuadores aún funcionan. Si hay grados de libertad redundantes, incluso podrían compensarlo por completo.

Esto tiene una implicación. Si necesita que los actuadores funcionen en armonía, colóquelos en el mismo nodo. Esto no se debe solo a una falla en la comunicación, sino a que diferentes nodos significan diferentes demoras; en un sistema distribuido, cada nodo está en una parte diferente de la red y, por lo tanto, la diferencia en los retrasos, en un sistema centralizado, se producen diferentes retrasos en altas cargas de CPU debido a la suerte de cada proceso en la programación.

¿Debería haber un controlador?

Aunque la respuesta es "depende", existe un enfoque común con muchas ventajas. Cambiemos el nombre y llamémoslo "controlador". El enfoque es "sí, debería haber un controlador".

Las ventajas de tener un controlador son (entre muchas):

• Procesamiento desacoplado: cada nodo es responsable de una cosa que significa:
  • Simplicidad: lo que implica
    • Desarrollo más fácil
    • Depuración más fácil
    • Menos errores
    • Menos posibilidades de fracaso
  • Reutilización: porque el mismo controlador se puede usar con diferentes nodos de sensor si tienen la misma funcionalidad (es decir, formatos de mensaje y servicio).
• Ejecución en hardware separado: cada nodo se puede mover en la red. Por ejemplo, los nodos de sensores y actuadores se pueden mover a un microcontrolador dedicado ( Arduino por ejemplo (no es lo que recomiendo)) y el controlador en una PC.
• Evite la fealdad extrema: si los sensores quisieran influir directamente en los actuadores, el resultado es simplemente un desastre. Suponiendo que no hay controlador, veamos cada caso:
  • Un nodo sensor: básicamente, esto significa que el nodo sensor y el controlador se unen en el mismo nodo. No está mal, pero es muy innecesario.
  • Muchos nodos sensores: este es el desastre. Esto significa que el controlador se distribuye entre los nodos del sensor. Por lo tanto, todos los nodos del sensor tienen que hablar entre ellos para saber cómo controlar sus actuadores asociados. Imagine una falla en la comunicación o varios tipos de demoras y verá lo difícil que se vuelve. Dado que esto es completamente innecesario, ¡no hay razón para hacerlo!

Dicho esto, también hay desventajas. Tener más nodos (cualquier nodo, no solo el controlador) significa:

• Comunicación más desperdiciada: los datos tienen que moverse en formatos estándar (de forma serializada y deserializada) a través de la red o la memoria compartida, el núcleo ROS tiene que mirarlos y decidir a quién entregarlos, etc. En resumen, se desperdician algunos recursos del sistema en comunicación. Si todos los nodos estuvieran en uno, ese costo podría haber sido cero.
• Mayor probabilidad de falla: si por alguna razón un enlace de red se cae, o un nodo muere, hay una falla en el sistema. Si no está preparado para ello, puede derribar todo el sistema. Ahora, esto es realmente bueno en general poder perder parte del sistema pero no todo ( degradación elegante ), pero también existen aplicaciones en las que esto debe evitarse tanto como sea posible. Cortar la comunicación y poner todo el código en un nodo realmente ayuda con la estabilidad del sistema. El lado negativo es, por supuesto, que el sistema funciona bien o de repente muere por completo.
• Tiempos caóticos: cada nodo se ejecuta por sí solo. El tiempo que tardan sus mensajes en llegar a otros no es determinista y varía de una ejecución a otra. A menos que sus nodos marquen cada mensaje (como una nota al margen: necesita tener relojes sincronizados en buena medida, lo cual ROS no) y a menos que cada nodo receptor pueda tener en cuenta el retraso y controlarlo en consecuencia (lo cual es una tarea muy difícil por sí solo), entonces tener múltiples nodos significa una alta incertidumbre sobre la antigüedad de los datos. Esta es en realidad una de las razones (entre muchas) por las que la mayoría de los robots se mueven tan lentamente; su ciclo de control debe ser lo suficientemente lento para asegurarse de que todos los datos correspondan al período actual. Cuanto mayores son los retrasos, más lento es el bucle de control.

En todas las desventajas anteriores, la solución es reducir el número de nodos, preferiblemente a un solo nodo. ¡Espera un minuto, eso ya no usa ROS! Exactamente.

Para resumir:

• Utilice ROS para sistemas que no sean en tiempo real, donde los retrasos podrían aumentar esporádicamente. En ese caso, siéntase libre de tener tantos nodos ROS como desee. De hecho, es una muy buena práctica hacer que cada nodo ROS haga una y solo una cosa. De esa manera, se vuelven muy simples y se vuelven altamente reutilizables.
• Por otro lado, para sistemas en tiempo real, evite por completo ROS. Para eso hay orocos y tecnologías como EtherCAT y, la mayoría de las veces, soluciones ad-hoc.

Como última palabra, en la práctica, ROS está bien. No es genial, pero está bien. Muy a menudo, el sistema no es crítico y la posibilidad de falla es tan pequeña que de vez en cuando reiniciar no es un gran problema. Este es el algoritmo de avestruz !