Directorio
Arquitectura de comunicación 4 ROS
4.1 Iniciar el maestro y el nodo
4.1.1 Iniciar el maestro: roscore
4.1.2 启动 nodo: rosrun, roslaunch
4.2 método de comunicación ROS
Arquitectura de comunicación 4 ROS
Nodo:
En el mundo ROS, la unidad de proceso más pequeña es un nodo. Puede haber varios archivos ejecutables en un paquete de software. Después de ejecutar el archivo ejecutable, se convierte en un proceso. Este proceso se denomina nodo en ROS. De Cheng
Desde un punto de vista de procedimiento, el nodo es un archivo ejecutable (generalmente un archivo ejecutable generado por la compilación de C ++, un script de Python)
Se ejecuta y se carga en la memoria; desde un punto de vista funcional, generalmente un solo individuo responsable de un robot de nodo
Función. Dado que el módulo de funciones del robot es muy complicado, a menudo no concentramos todas las funciones en un nodo, y
Utilizará un enfoque distribuido. Por ejemplo, hay un nodo para controlar el movimiento de las ruedas del chasis, un nodo para conducir la cámara para obtener imágenes, un nodo para manejar el LIDAR y un nodo para planificar la ruta en función de la información del sensor ...
Maestro:
El maestro es equivalente al centro de gestión en toda la arquitectura de comunicación de red, gestionando cada nodo. El nodo se registra primero en el maestro, y luego el maestro incluirá el nodo en todo el programa ROS. La comunicación entre nodos también se "tira" primero por el maestro, de modo que la comunicación punto a punto se puede llevar a cabo en pares. Cuando se inicia el programa ROS, el primer paso es iniciar primero el maestro, y el administrador de nodos procesa los nodos y los inicia a su vez.
4.1 Iniciar el maestro y el nodo
4.1.1 Iniciar el maestro: roscore
Al iniciar ROS, primero ingrese el comando roscore para iniciar el maestro:
$ roscore
En este momento, se inicia el maestro ROS, y también se inician rosout y el servidor de parámetros, del cual rosout es responsable de
Un nodo de la salida del registro, su función es informar al usuario del estado actual del sistema, incluido el error del sistema de salida, advertencia, etc.
Espere y grabe el registro en el archivo de registro; el servidor de parámetros es el servidor de parámetros, no es un nodo,
Es un servidor que almacena configuraciones de parámetros. Cada vez que ejecutamos el nodo ROS, necesitamos iniciar el maestro, para que el nodo pueda iniciarse y registrarse.
4.1.2 启动 nodo: rosrun, roslaunch
Puedes usar rosrun, roslaunch
El uso detallado del comando rosrun es el siguiente:
$ rosrun [--prefix cmd] [--debug] pkg_name nombre_nodo [ARGS]
rosrun buscará el programa ejecutable llamado EJECUTABLE en PACKAGE y pasará el parámetro opcional ARGS.
comando roslaunch :
roslaunch pkg_name file_name.launch
El maestro y varios nodos pueden iniciarse a la vez. El comando roslaunch detectará automáticamente si el roscore del sistema se está ejecutando, es decir, para confirmar si el administrador de nodos se está ejecutando, si el maestro no se inicia, roslaunch iniciará primero el maestro. Luego sigue las reglas de lanzamiento.
4.1.3 comando rosnode
- La lista rosnode enumera la información del nodo actualmente en ejecución
- rosnode info nombre_nodo muestra información detallada del nodo
- rosnode kill nombre_nodo finaliza un nodo
- nodo de conexión de prueba de ping rosnode
- La máquina rosnode enumera los nodos que se ejecutan en una máquina específica o lista de máquinas
- La limpieza de rosnode borra la información de registro de nodos inalcanzables
rosnode ayuda a ver el uso del comando rosnode.
4.2 método de comunicación ROS
El método de comunicación de ROS es el concepto central de ROS. Hay cuatro tipos de métodos de comunicación de ROS:
- Tema
- Servicio
- Servicio de parámetros
- Biblioteca de acciones Actionlib
4.2.1 Tema
Entre los métodos de comunicación en ROS, el tema es uno de uso común. Para mensajes periódicos en tiempo real, usar el tema para transmitir es la mejor opción. El tema es un tipo de método de comunicación unidireccional punto a punto, donde "punto" se refiere al nodo, lo que significa que la información se puede transferir entre nodos a través del tema. El tema debe pasar por el proceso de inicialización de los siguientes pasos: Primero, tanto el nodo del editor como el nodo del suscriptor deben registrarse con el administrador de nodos, luego el editor publicará el tema y el suscriptor se suscribirá al tema bajo el comando del maestro, estableciendo así Comunicación. Tenga en cuenta que todo el proceso es unidireccional. El suscriptor procesará el mensaje cuando lo reciba. Generalmente, este proceso se llama devolución de llamada. La llamada devolución de llamada es definir una función de procesamiento por adelantado (escrita en el código), cuando hay un mensaje activará la función de procesamiento, la función procesará el mensaje.
La comunicación temática es un método de comunicación asincrónico unidireccional.
El diagrama esquemático de su estructura se muestra a continuación;
4.2.1.1 comando rostopic:
- lista de rostopic enumera todos los temas actuales
- rostopic info topic_name muestra la información de atributos de un tema
- rostopic echo topic_name muestra el contenido de un tema
- pub rostopic topic_name ... Publicar contenido en un tema
- rostopic bw topic_name Ver el ancho de banda de un tema
- rostopic hz topic_name Ver la frecuencia de un tema
- rostopic find topic_type encuentra un tipo de tema
- rostopic type topic_name Ver el tipo de un tema (msg)
4.2.1.2 archivo msg
Mensaje es el tipo de datos del contenido del tema, también conocido como el formato estándar del tema. Definido en el archivo con el sufijo .msg.
Los tipos de datos de msg básicos incluyen bool, int8, int16, int32, int64 (y uint), float, float64, cadena, hora, duración, encabezado, matriz de matriz de longitud variable [] y matriz de matriz de longitud fija [C].
Utilizamos un mensaje específico para comprender, como msg sensor_msg / image, la ubicación se almacena en sensor_msgs / msg / image.msg, su estructura es la siguiente:
std_msg / Encabezado de encabezado
uint32 seq
sello de tiempo
string frame_id
uint32 altura
ancho de uint32
codificación de cadena
uint8 is_bigendian
uint32 paso
uint8 [] fecha
4.2.1.3 comando rosmsg:
- La lista rosmsg enumera todos los mensajes en el sistema
- rosmsg show msg_name muestra el contenido de un mensaje
4.2.2 Servicio
La comunicación del servicio es bidireccional, no solo puede enviar mensajes, sino también recibir comentarios. Por lo tanto, el servicio incluye dos partes, una es el solicitante (Clinet) y la otra es el proveedor de respuesta / servicio (Servidor). En este momento, el solicitante (Cliente) enviará una solicitud, esperará a que el servidor procese y devolverá una respuesta, de modo que toda la comunicación del servicio se complete a través de un mecanismo similar a "solicitud-respuesta".
El diagrama esquemático de este método de comunicación es el siguiente: El nodo B es un servidor (respondedor), que proporciona una interfaz de servicio llamada / Servicio. Generalmente usamos el tipo de cadena para especificar el nombre del servicio, similar al tema. El nodo A inició una solicitud al nodo B y recibió comentarios después del procesamiento.
El servicio es un método de comunicación síncrono. La llamada sincronización significa que el Nodo A esperará una respuesta después de emitir una solicitud hasta que llegue
Después de que el Nodo B procesa la solicitud y completa la respuesta, el Nodo A continuará ejecutándose. El nodo A está en proceso de espera
Comunicación bloqueada Este modelo de comunicación no tiene mensajes frecuentes, no hay conflictos y una alta ocupación de recursos del sistema, y solo realiza servicios cuando acepta solicitudes, lo cual es simple y eficiente.
4.2.2.1 tema VS servicio
4.2.2.2 comando rosservice
- rosservice list mostrar lista de servicios
- Información de servicio de impresión Imprimir información de servicio
- tipo de servicio
- rosservice servicio de impresión uri ROSRPC uri
- rosservice encontrar Buscar servicio por tipo de servicio
- rosservice call utiliza los argumentos proporcionados para llamar al servicio
- parámetros del servicio de impresión de rosservice args
4.2.2.3 archivo srv
El archivo srv se utiliza para describir el servicio (tipo de datos del servicio, el formato de datos de la comunicación del servicio se define en * .srv. Declara un servicio, incluidas la solicitud (solicitud) y la respuesta (respuesta) en dos partes.
La declaración de formato es la siguiente: Ejemplos:
msgs_demo / srv / DetectHuman.srv
bool start_detect
---
my_pkg / HumanPose [] pose_data
msgs_demo / msg / HumanPose.msg
std_msgs / Encabezado de encabezado
uuid de cuerda
int32 número_de_uniones
my_pkg / JointPose [] joint_data
msgs_demo / msg / JointPose.msg
string joint_name
geometry_msgs / Pose pose
floar32 confianza
El formato del archivo srv es muy fijo, la primera línea es el formato solicitado, separado por --- en el medio, y la tercera línea es el formato de la respuesta. En este ejemplo, la solicitud es si iniciar la detección, la respuesta es una matriz y cada elemento de la matriz es el gesto de una persona (HumanPose). En cuanto al gesto humano, en realidad es un mensaje, por lo que srv puede anidarse en msg, pero no puede anidarse en srv.
4.2.2.4 comando rossrv
- rossrv show show descripción del servicio
- lista rossrv Listar todos los servicios
- rossrv md5 servicio de visualización md5sum
- El paquete rossrv enumera los servicios en el paquete
- paquetes rossrv enumera paquetes que contienen servicios
4.2.3 Servidor de parámetros
También se puede decir que un servidor de parámetros es un "método de comunicación" especial. El punto especial es que el servidor de parámetros es donde los nodos almacenan parámetros, se usan para configurar parámetros y compartir parámetros globalmente. El servidor de parámetros utiliza la transmisión por Internet y se ejecuta en el administrador de nodos para realizar todo el proceso de comunicación.
El servidor de parámetros, como otro método de transmisión de datos en ROS, es diferente del tema y el servicio, es más estático. El servidor de parámetros mantiene un diccionario de datos, que almacena varios parámetros y configuraciones.
Hay tres formas de mantener el servidor de parámetros:
- Mantenimiento de línea de comando
- Leer y escribir en el archivo de inicio
- Código fuente del nodo
4.2.3.1 Mantenimiento de línea de comando: rosparam
- rosparam set param_key param_value Establecer parámetros
- rosparam obtener parámetros de visualización param_key
- rosparam cargar nombre_archivo cargar parámetros del archivo
- rosparam dump file_name guardar parámetros en el archivo
- rosparam eliminar eliminar parámetro
- lista de rosparam enumera nombres de parámetros
cargar y volcar 文件
Los archivos de carga y descarga deben cumplir con el formato YAML. Los ejemplos específicos del formato YAML son los siguientes:
nombre: 'Zhangsan'
edad: 20
genero M'
puntaje {Chino: 80, Matemáticas: 90}
score_history: [85,82,88,90]
4.2.3.2 Leer y escribir en el archivo de inicio
Hay muchas etiquetas en el archivo de inicio, y solo hay dos etiquetas relacionadas con el servidor de parámetros, una es <param> y la otra
Es <rosparam>.
4.2.3.3 código fuente del nodo
El código fuente de ROS, es decir, usa la API para operar el servidor de parámetros. Introduciremos el contenido específico después de estudiar los siguientes capítulos.
4.2.4 Acción
Actionlib es una biblioteca muy importante en ROS. Similar al mecanismo de comunicación de servicio, actionlib también es un mecanismo de solicitud de respuesta.
Método de comunicación, actionlib compensa principalmente una deficiencia de la comunicación de servicio, es decir, cuando el robot realiza una tarea a largo plazo
En ese momento, si se utiliza el método de comunicación del servicio, el editor no recibirá la respuesta durante mucho tiempo, lo que provocará que la comunicación reciba
Obstaculizar. Cuando la comunicación de servicio no puede completar bien la tarea, actionlib puede ser más adecuado para la comunicación a largo plazo.
Proceso, el proceso de comunicación actionlib se puede ver en cualquier momento, el progreso del proceso también se puede finalizar, tal característica lo hace
Tiene alta eficiencia en algunos mecanismos especiales.
4.2.4.1 El principio de funcionamiento de la acción.
El principio de funcionamiento de Action es el modo cliente-servidor, que también es un modo de comunicación bidireccional. Comunicando fiestas en ROS
Según el Protocolo de Acción, el intercambio de datos y la comunicación se llevan a cabo a través de mensajes. cliente y servidor proporcionan a los usuarios un simple
API para solicitar el objetivo (en el lado del cliente) o ejecutar el objetivo a través de llamadas de función y devoluciones de llamada (en el lado del servidor).
El diagrama esquemático del modo de trabajo es el siguiente:
El cliente enviará la instrucción de destino y la instrucción de acción de cancelación al servidor, y el servidor puede enviar información de estado en tiempo real, información de resultados, información de retroalimentación, etc. al cliente, completando así la parte que el servicio no puede hacer.
4.2.4.2 archivo de acción
Utilice la biblioteca de acciones para la respuesta a la solicitud. El formato de contenido de la acción debe incluir tres partes: objetivo, comentarios y resultados.
- Target
Cuando el robot realiza una acción, debe tener información clara del objetivo en movimiento, incluida la configuración de algunos parámetros, dirección, ángulo, velocidad, etc. Para que el robot pueda completar la tarea de movimiento.
- Retroalimentación
En el curso de la acción, debe haber retroalimentación de información de estado en tiempo real al implementador del servidor, diciéndole al implementador el estado de finalización de la acción, para que el implementador pueda hacer un juicio preciso para modificar el comando.
- El resultado
Cuando se completa el movimiento, el servidor de acciones envía los datos del resultado del ejercicio al cliente, para que el cliente pueda obtener toda la información de la acción, por ejemplo, puede incluir la duración del movimiento del robot, la postura final, etc.
El nombre del sufijo del archivo de especificación de acción es .action, y su formato de contenido es el siguiente:
# Definir el objetivo
uint32 dishwasher_id # Especifique qué lavavajillas queremos usar
---
# Definir el resultado
uint32 total_dishes_cleaned
---
# Definir un mensaje de retroalimentación
float32 percent_complete
