Conceptos Teóricos ROS 1 y 2
Introducción y conceptos básicos
ROS es un meta-sistema operativo de código abierto para su robot. Proporciona servicios de sistema
operativo estándar, como abstracción de hardware, controladores de dispositivos, implementación de
funciones de uso común que incluyen detección, reconocimiento, mapeo, planificación de movimiento,
paso de mensajes entre procesos, administración de paquetes, visualizadores y bibliotecas para
desarrollo, así como herramientas de depuración. La reutilización de código en la investigación y el
desarrollo de robótica es cada vez más común, que es el objetivo final de ROS.
Meta-Sistema Operativo: describe un sistema que realiza procesos tales como programación, carga,
monitoreo y manejo de errores utilizando la capa de virtualización entre las aplicaciones y los recursos
informáticos distribuidos. ROS no es un sistema operativo convencional como Windows, Linux y
Android, sino un metasistema operativo que se ejecuta en el sistema operativo existente. Para operar
ROS, un sistema operativo como Ubuntu, que es una de las distribuciones de Linux, debe instalarse
primero.
Bibliotecas de cliente: son las API que permiten a los usuarios implementar su código ROS. Mediante
el uso de bibliotecas cliente, los usuarios obtienen acceso a conceptos de ROS como nodos, tópicos,
servicios, etc. Las bibliotecas cliente vienen en una variedad de lenguajes de programación para que
los usuarios puedan escribir código ROS en el lenguaje que mejor se adapte a su aplicación.
Al utilizar la biblioteca de cliente ROS de núcleo común, las bibliotecas de cliente escritas en una
variedad de lenguajes de programación son más fáciles de escribir y tienen un comportamiento más
consistente.
El equipo de ROS 2 mantiene las siguientes bibliotecas de clientes:
● rclcpp = biblioteca cliente C++
● rclpy = biblioteca cliente de Python
API: una API, o interfaz de programación de aplicaciones, es una interfaz proporcionada por una
"aplicación", que en este caso suele ser una biblioteca compartida u otro recurso compartido apropiado
para el lenguaje. Las API se componen de archivos que definen un contrato entre el software que utiliza
la interfaz y el software que proporciona la interfaz. Estos archivos normalmente se manifiestan como
archivos de encabezado en C y C++ y como archivos de Python en Python. En cualquier caso, es
importante que las API se agrupen y describan en la documentación y que se declaren como públicas o
privadas. Las interfaces públicas están sujetas a reglas de cambio y los cambios en las interfaces
públicas solicitan un nuevo número de versión del software que las proporciona.
(Video explicativo: [Link] )
ID Domain (Identificador de dominio)
El middleware predeterminado que usa ROS 2 para la comunicación es DDS. En DDS, el mecanismo
principal para que diferentes redes lógicas compartan una red física se conoce como ID de dominio. Los
nodos ROS 2 en el mismo dominio pueden descubrir y enviarse mensajes libremente, mientras que los
nodos ROS 2 en diferentes dominios no pueden. Todos los nodos ROS 2 utilizan el ID de dominio 0 de
forma predeterminada. Para evitar interferencias entre diferentes grupos de computadoras que ejecutan
ROS 2 en la misma red, se debe configurar una ID de dominio diferente para cada grupo.
El rango seguro de IDs que se pueden utilizar en ROS 2 está entre 0 y 101, inclusive.
Middleware: es el software que brinda servicios y funciones comunes a las aplicaciones, además de lo
que ofrece el sistema operativo. Generalmente, se encarga de la gestión de los datos, los servicios de
aplicaciones, la mensajería, la autenticación y la gestión de las API. Ayuda a los desarrolladores a
diseñar aplicaciones con mayor eficiencia. Además, actúa como hilo conductor entre las aplicaciones,
los datos y los usuarios.
Espacios de trabajo (Workspaces): ROS 2 se basa en la noción de combinar espacios de trabajo
(workspaces) utilizando el entorno de shell. “Área de trabajo” es un término de ROS para la ubicación
en su sistema donde está desarrollando con ROS 2. El área de trabajo principal de ROS 2 se llama
subyacente (underlay). Los espacios de trabajo locales subsiguientes se denominan superposiciones
(overlays). Al desarrollar con ROS 2, normalmente tendrá varios espacios de trabajo activos al mismo
tiempo.
La combinación de espacios de trabajo facilita el desarrollo con diferentes versiones de ROS 2 o con
diferentes conjuntos de paquetes. También permite la instalación de varias distribuciones de ROS 2 (o
"distros", por ejemplo, Dashing y Eloquent) en la misma computadora y cambiar entre ellas.
Esto se logra obteniendo archivos de configuración cada vez que abre un nuevo shell, o agregando el
comando fuente a su secuencia de comandos de inicio de shell una vez. Sin obtener los archivos de
configuración, no podrá acceder a los comandos de ROS 2 ni encontrar o usar paquetes de ROS 2. En
otras palabras, no podrá usar ROS 2.
Turtlesim: es un simulador ligero para aprender ROS 2.
rqt: es una herramienta GUI (interfaz de usuario gráfica) para ROS 2. Todo lo que se hace en rqt se
puede hacer en la línea de comandos, pero proporciona una forma más fácil y amigable de manipular
los elementos de ROS 2.
“ROS graph” es una red de elementos de ROS 2 que procesan datos juntos al mismo tiempo. Abarca
todos los ejecutables y las conexiones entre ellos si tuviera que mapearlos y visualizarlos.
Nodos: Cada nodo en ROS debe ser responsable de un solo propósito de módulo (por ejemplo, un
nodo para controlar los motores de las ruedas, un nodo para controlar un telémetro láser, etc.). Cada
nodo puede enviar y recibir datos a otros nodos a través de temas, servicios, acciones o parámetros.
Un sistema robótico completo se compone de muchos nodos que trabajan en conjunto. En ROS 2, un
único ejecutable (programa C++, programa Python, etc.) puede contener uno o más nodos.
El nodo registrado puede actuar como publicador, suscriptor, servidor de servicios o cliente de servicios
en función de la información registrada, y los nodos pueden intercambiar mensajes utilizando temas y
servicios.
Las conexiones entre nodos se establecen a través de un proceso de "descubrimiento" distribuido. Los
nodos pueden estar ubicados en el mismo proceso, en diferentes procesos o en diferentes máquinas.
Parámetros: un parámetro es un valor de configuración de un nodo. Puede pensar en los parámetros
como configuraciones de nodo. Un nodo puede almacenar parámetros como enteros, flotantes,
booleanos, cadenas (strings) y listas. En ROS 2, cada nodo mantiene sus propios parámetros.
Los parámetros en ROS están asociados con nodos individuales. Los parámetros se utilizan para
configurar nodos al inicio (y durante el tiempo de ejecución), sin cambiar el código. La vida útil de un
parámetro está ligada a la vida útil del nodo (aunque el nodo podría implementar algún tipo de
persistencia para recargar valores después del reinicio).
Los parámetros se direccionan por nombre de nodo, espacio de nombres de nodo, nombre de
parámetro y espacio de nombres de parámetro. Proporcionar un espacio de nombres de parámetros es
opcional.
Cada parámetro consta de una clave (key), un valor y un descriptor. La clave es una cadena (string) y el
valor es uno de los siguientes tipos: bool, int64, float64, string, byte[], bool[], int64[], float64[] o string[].
De forma predeterminada, todos los descriptores están vacíos, pero pueden contener descripciones de
parámetros, rangos de valores, información de tipo y restricciones adicionales.
Declaración de parámetros: De forma predeterminada, un nodo debe declarar todos los parámetros
que aceptará durante su vida útil. Esto es para que el tipo y el nombre del parámetro estén bien
definidos en el momento del inicio del nodo, lo que reduce las posibilidades de una configuración
incorrecta más adelante.
Para algunos tipos de nodos, no todos los parámetros se conocerán de antemano. En estos casos, se
puede crear una instancia del nodo con “allow_undeclared_parameters” establecido en verdadero, lo
que permitirá obtener y establecer parámetros en el nodo incluso si no se han declarado.
Cada parámetro en un nodo ROS 2 tiene uno de los tipos de parámetros predefinidos
Tipos de parámetros: cada parámetro en un nodo ROS 2 tiene uno de los tipos de parámetros
predefinidos que se mencionan en la descripción. De forma predeterminada, los intentos de cambiar el
tipo de un parámetro declarado en tiempo de ejecución fallarán. Esto evita errores comunes, como
poner un valor booleano en un parámetro entero.
Si un parámetro debe ser de varios tipos diferentes y el código que usa el parámetro puede controlarlo,
se puede cambiar este comportamiento predeterminado. Cuando se declara el parámetro, debe
declararse utilizando un “ParameterDescriptor” con la variable de miembro “dynamic_typing” establecida
en verdadero.
Devoluciones de llamada de parámetros (Parameter callbacks): un nodo ROS 2 puede registrar dos
tipos diferentes de devoluciones de llamada para recibir información cuando se produzcan cambios en
los parámetros. La razón por la que hay dos tipos de devoluciones de llamada es para tener la
oportunidad de intervenir antes de que ocurra el cambio de parámetro y para tener la oportunidad de
reaccionar después de que ocurra el cambio de parámetro. Un nodo puede registrarse para ambos
tipos de devolución de llamada, cualquiera de ellos o ninguno. Ambos tipos se describen a
continuación.
El primer tipo se conoce como devolución de llamada de "establecimiento de parámetros" y se puede
instalar llamando a add_on_set_parameters_callback. La devolución de llamada debe aceptar una lista
de objetos de parámetro y devolver un rcl_interfaces/msg/SetParametersResult. Esta “call-back” se
llamará antes de que se declare o cambie un parámetro en un nodo. El objetivo principal de call-back es
brindar al usuario la capacidad de inspeccionar el próximo cambio en el parámetro y rechazar
explícitamente el cambio.
El segundo tipo de call-back se conoce como "en evento de parámetro" y se puede instalar llamando a
on_parameter_event. La devolución de llamada debe aceptar un objeto
rcl_interfaces/msg/ParameterEvent y no devolver nada. Esta devolución de llamada se llamará después
de que se hayan declarado, cambiado o eliminado todos los parámetros. El objetivo principal de esta
devolución de llamada es dar al usuario la capacidad de reaccionar a los cambios de los parámetros
que se han aceptado con éxito.
Interacción con parámetros: los nodos de ROS 2 pueden realizar operaciones de parámetros a través
de las API de nodos. Los procesos externos pueden realizar operaciones de parámetros a través de
servicios de parámetros que se crean de forma predeterminada cuando se crea una instancia de un
nodo. Los servicios que se crean por defecto son:
/node_name/describe_parameters: utiliza un tipo de servicio de rcl_interfaces/srv/DescribeParameters.
Dada una lista de nombres de parámetros, devuelve una lista de descriptores asociados con los
parámetros.
/node_name/get_parameter_types: utiliza un tipo de servicio de rcl_interfaces/srv/GetParameterTypes.
Dada una lista de nombres de parámetros, devuelve una lista de tipos de parámetros asociados con los
parámetros.
/node_name/get_parameters: utiliza un tipo de servicio de rcl_interfaces/srv/GetParameters. Dada una
lista de nombres de parámetros, devuelve una lista de valores de parámetros asociados con los
parámetros.
/node_name/list_parameters: utiliza un tipo de servicio de rcl_interfaces/srv/ListParameters. Dada una
lista opcional de prefijos de parámetros, devuelve una lista de los parámetros disponibles con ese
prefijo. Si los prefijos están vacíos, devuelve todos los parámetros.
/node_name/set_parameters: utiliza un tipo de servicio de rcl_interfaces/srv/SetParameters. Dada una
lista de nombres y valores de parámetros, intenta establecer los parámetros en el nodo. Devuelve una
lista de resultados al intentar establecer cada parámetro; algunos de ellos pueden haber tenido éxito y
algunos pueden haber fracasado.
/node_name/set_parameters_atomically: utiliza un tipo de servicio de
rcl_interfaces/srv/SetParametersAtomically. Dada una lista de nombres y valores de parámetros, intenta
establecer los parámetros en el nodo. Devuelve un solo resultado al intentar establecer todos los
parámetros, por lo que si uno falla, todos fallan.
Establecer valores de parámetros iniciales al ejecutar un nodo: los valores iniciales de los
parámetros se pueden establecer cuando se ejecuta el nodo a través de argumentos de línea de
comandos individuales o mediante archivos YAML.
Establecer valores de parámetros iniciales al “lanzar” nodos: los valores de los parámetros
iniciales también se pueden establecer cuando se ejecuta el nodo a través de la compilación de
lanzamiento de ROS 2.
Manipulación de valores de parámetros en tiempo de ejecución: el comando ros2 param es la
forma general de interactuar con los parámetros de los nodos que ya se están ejecutando.
En resumen (sobre los parámetros): se utilizan para configurar nodos al inicio (y durante el tiempo de
ejecución), sin cambiar el código. Un nodo puede almacenar parámetros como enteros, flotantes,
booleanos, cadenas y listas. En ROS 2, cada nodo mantiene sus propios parámetros. Podemos obtener
y establecer los valores de los parámetros desde la línea de comandos y guardar la configuración de los
parámetros en un archivo para volver a cargarlos en una sesión futura. Piense en ello como archivos de
configuración *.ini en un programa de Windows. Los valores predeterminados se establecen en el
parámetro y se pueden leer o escribir si es necesario. En un contexto más amplio, también pueden
considerarse como un mensaje de comunicación.
Cada parámetro consta de una clave, un valor y un descriptor.
Los valores configurados se pueden modificar en tiempo real desde el exterior mediante la función de
escritura.
Los procesos externos pueden realizar operaciones de parámetros a través de servicios de parámetros
que se crean de forma predeterminada cuando se crea una instancia de un nodo.
Interfaces: las aplicaciones ROS normalmente se comunican a través de interfaces de uno de tres
tipos: mensajes, servicios y acciones. ROS 2 utiliza un lenguaje de descripción simplificado, el lenguaje
de definición de interfaz (IDL), para describir estas interfaces. Son variables como enteros, punto
flotante y booleanos. La estructura de interfaces anidadas que contiene otras interfaces o un arreglo de
interfaces se puede utilizar en la interfaz.
El encabezado (std_msgs/Header), que se usa comúnmente en ROS, también se puede usar como
mensaje. El archivo [Link] en std_msgs31 contiene el ID de secuencia, la marca de tiempo y el ID
de marco, y utilícelos para sondear el mensaje o medir el tiempo.
.msg FILE: los archivos 'msg' son archivos de texto simples que describen los campos de un mensaje
ROS, utilizados por tópicos. Están ubicados en el directorio msg/ de un paquete ROS. Los archivos msg
se componen de dos partes:
1) Campos: cada campo consta de un tipo y un nombre, separados por un espacio.
fieldtype1 fieldname1 fielddefaultvalue
fieldtype2 fieldname2 fielddefaultvalue
fieldtype3 fieldname3 fielddefaultvalue
Por ejemplo: int32 my_int 5
El valor por defecto no es obligatorio.
Campos admitidos:
2) Constantes: cada definición de constante es como una descripción de campo con un valor
predeterminado, excepto que este valor nunca se puede cambiar mediante programación. Los
nombres de las constantes deben estar en MAYÚSCULAS. Esta asignación de valor se indica
mediante el uso de un signo igual '=':
constanttype CONSTANTNAME=constantvalue
.srv FILE: los archivos 'srv' describen un servicio. Se componen de dos partes: una solicitud y una
respuesta. La solicitud y la respuesta son declaraciones de mensajes. Los archivos ‘srv’ se encuentran
en el directorio srv/ de un paquete ROS. Un archivo de descripción de servicio consiste en un tipo de
mensaje de solicitud y respuesta, separados por '---'. Cualquier dos archivos .msg concatenados con
un '---' son una descripción de servicio legal. Siendo el mensaje superior el mensaje de solicitud y el
inferior el de respuesta, del respectivo servicio.
fieldtype1 fieldname1 fielddefaultvalue1
fieldtype2 fieldname2 fielddefaultvalue2
…
---
fieldtype11 fieldname11 fielddefaultvalue11
fieldtype22 fieldname22 fielddefaultvalue22
…
.action FILE: los archivos .action describen acciones. La principal diferencia con los archivos msg y srv
es que la serie de tres guiones (---) se utilizan en dos lugares como delimitadores, siendo el primero el
mensaje de objetivo, el segundo el mensaje de resultado y el tercero el mensaje de retroalimentación.
La mayor diferencia del archivo de acción es la función de mensaje de retroalimentación. Cada parte es
una declaración de mensaje en sí misma.
fieldtype1 fieldname1 fielddefaultvalue1
fieldtype2 fieldname2 fielddefaultvalue2
….
---
fieldtype11 fieldname11 fielddefaultvalue11
fieldtype22 fieldname22 fielddefaultvalue22
…
---
fieldtype111 fieldname111 fielddefaultvalue111
fieldtype222 fieldname222 fielddefaultvalue222
…
Tópicos: los tópicos son un elemento vital del gráfico ROS que actúa como un bus para que los nodos
intercambien mensajes. Un nodo puede publicar datos en cualquier número de tópicos y
simultáneamente estar suscrito a cualquier número de tópicos. Los tópicos son una de las principales
formas en que los datos se mueven entre nodos y, por lo tanto, entre diferentes partes del sistema. Los
tópicos no tienen que ser solo comunicación punto a punto; puede ser de uno a muchos, de muchos a
uno o de muchos a muchos. (Así que tienen algunos publicadores y suscriptores). Los publicadores y
suscriptores deben enviar y recibir el mismo tipo de mensaje para comunicarse.
Publicar y Publicador (PUBLISH AND PUBLISHER): El término 'publicar' se refiere a la acción de
transmitir mensajes relativos al correspondiente tópico. El nodo publicador envía un mensaje a los
nodos suscriptores conectados que están interesados en el mismo tópico. El editor se declara en el
nodo y se puede declarar varias veces en el mismo.
Suscribirse y Suscriptor (SUBSCRIBE AND SUBSCRIBER): el término 'suscribirse' se refiere a la
acción de recibir mensajes relativos correspondientes al tópico. El nodo suscriptor recibe información
del publicador que publica un tópico relativo. En función de la información del publicador recibida, el
nodo del suscriptor solicita directamente la conexión al nodo del publicador y recibe mensajes del nodo
del publicador conectado. Un suscriptor se declara en el nodo y se puede declarar varias veces en el
mismo.
La comunicación de los tópicos es asíncrona y se basa en el publicador y suscriptor. Es útil para
transferir ciertos datos. Dado que el tema transmite y recibe continuamente un flujo de mensajes una
vez conectado, a menudo se usa para sensores que deben transmitir datos periódicamente.
Servicios: los servicios son otro método de comunicación para los nodos en ROS graph. Los servicios
se basan en un modelo de llamada y respuesta, frente al modelo de publicador-suscriptor de los
tópicos. Si bien los tópicos permiten que los nodos se suscriban a flujos de datos y obtengan
actualizaciones continuas, los servicios solo brindan datos cuando un cliente los llama específicamente.
Los servicios tienen tipos que describen cómo se estructuran los datos de solicitud y respuesta de un
servicio. Los tipos de servicio se definen de manera similar a los tipos de tópicos, excepto que los tipos
de servicio tienen dos partes: un mensaje para la solicitud y otro para la respuesta.
El servicio es una comunicación bidireccional sincrónica entre el cliente del servicio (service client) que
solicita un servicio (service) con respecto a una tarea en particular y el servidor del servicio (service
server) que es responsable de responder a las solicitudes. Los servicios se basan en un modelo de
llamada y respuesta (sólo proporcionan datos cuando son específicamente llamados por un cliente).
Puede haber muchos clientes de servicio que utilicen el mismo servicio, pero solo puede haber un
servidor de servicio para un dispositivo. Generalmente no queremos usar un servicio para llamadas
continuas; los tópicos o incluso las acciones serían más adecuados.
Servidor de Servicio (Service Server): Es un servidor en la comunicación de mensajes de servicio
que recibe una solicitud como entrada y transmite una respuesta como salida. Tanto la solicitud como la
respuesta están en forma de mensajes. Tras la solicitud de servicio, el servidor realiza el servicio
designado y entrega el resultado al cliente del servicio como respuesta. El servidor de servicios se
implementa en el nodo que recibe y ejecuta una determinada solicitud.
Cliente de Servicio (Service Client): es un cliente en la comunicación de mensajes de servicio que
solicita servicio al servidor y recibe una respuesta como entrada. Tanto la solicitud como la respuesta
tienen forma de mensaje. El cliente envía una solicitud al servidor de servicio y recibe la respuesta. El
cliente del servicio se implementa en el nodo que solicita el comando especificado y recibe los
resultados.
Un servicio a menudo se usa para ordenar a un robot que realice una acción específica o nodos para
realizar ciertos eventos con una condición específica.
Acciones: las acciones son uno de los tipos de comunicación en ROS 2 y están destinadas a tareas de
larga ejecución. Se utilizan acciones donde se tarda más tiempo en responder después de recibir una
solicitud y se requieren respuestas intermedias hasta que se devuelve el resultado (comunicación
bidireccional asíncrona). Constan de tres partes: un objetivo o ‘goal’ (solicitud), retroalimentación o
‘feedback’ y un resultado (respuesta).
Las acciones se basan en tópicos y servicios. Su funcionalidad es similar a los servicios, excepto que
las acciones se pueden cancelar, pero en la práctica se parece más a un tópicos. De hecho, si usa el
comando para enumerar tópicos, hay cinco tópicos, como objetivo (goal), estado (status), cancelación
(cancel), resultado (result) y comentarios (feedback) que se usan en la acción.
También brindan retroalimentación constante, a diferencia de los servicios que devuelven una sola
respuesta.
Las acciones utilizan un modelo cliente-servidor. Un nodo de "cliente de acción" (action client) envía un
objetivo a un nodo de "servidor de acción" (action server) que reconoce el objetivo y devuelve un flujo
de comentarios (feedback) y un resultado.
Servidor de acción (Action server): está a cargo de recibir el objetivo del cliente y responder con
comentarios y resultados. Una vez que el servidor recibe el objetivo del cliente, realiza un proceso
predefinido.
Cliente de acción (Action client): está a cargo de transmitir el objetivo al servidor y recibe datos de
resultados o comentarios como entradas del servidor de acción. El cliente entrega el objetivo al servidor
de acción, luego recibe el resultado o retroalimentación correspondiente y transmite instrucciones de
seguimiento o cancelación de instrucciones.
No solo el lado del cliente puede detener un objetivo, el lado del servidor también puede hacerlo.
Cuando el lado del servidor elige dejar de procesar un objetivo, se dice que "aborta" el objetivo. Todos
los objetivos tienen una identificación única (unique ID), que se muestra en el mensaje de respuesta.
Descubrimiento (Discovery) en ROS: el descubrimiento de nodos ocurre automáticamente a través
del middleware subyacente de ROS 2. Se puede resumir de la siguiente manera:
1) Cuando se inicia un nodo, anuncia su presencia a otros nodos en la red con el mismo dominio
ROS (establecido con la variable de entorno ROS_DOMAIN_ID). Los nodos responden a este
anuncio con información sobre ellos mismos para que se puedan realizar las conexiones
apropiadas y los nodos puedan comunicarse.
2) Los nodos anuncian periódicamente su presencia para que se puedan establecer conexiones
con entidades recién encontradas, incluso después del período de descubrimiento inicial.
3) Los nodos anuncian a otros nodos cuando se desconectan.
Los nodos sólo establecerán conexiones con otros nodos si tienen una configuración de calidad de
servicio compatible.
Nombres en ROS 2: el nombre de un tópico está dividido en:
Método relativo ("nombredeltema" o “topicname”): si se utilizan símbolos para declarar, el tópico tendrá
el nombre relativo '/topicname'.
Método global ("/topicname"): si se usa el carácter de barra inclinada (/) para declarar en global, el
nombre del tema seguirá siendo '/topicname'.
Método privado ("~nombredeltema" o “~topicname”): si declara el nombre como privado usando el
carácter de tilde (~), el nombre del tema se convierte en ‘/nodename/topicname’.
Los nodos con el mismo nombre se pueden ejecutar de la siguiente manera. A continuación, la opción
de nombre va seguida de guiones bajos consecutivos (__). Las opciones como '__ns', '__name', '__log',
'__ip', '__hostname' y '__master' son opciones especiales que se utilizan cuando se ejecuta el nodo.
Además, se coloca un guión bajo único (_) delante del nombre del tema si se usa como privado.
RQT GRAPH: es una herramienta que muestra la correlación entre los nodos activos y los mensajes
que se transmiten en la red ROS como un diagrama. Esto es muy útil para comprender la estructura
actual de la red ROS. Un círculo representa un nodo y un cuadrado representa un tópico.
RQT CONSOLE: es una herramienta GUI que se utiliza para realizar una introspección de los mensajes
de registro (o logueo) en ROS 2. Por lo general, los mensajes de registro aparecen en su terminal. Con
rqt_console, puede recopilar esos mensajes a lo largo del tiempo, verlos de cerca y de una manera más
organizada, filtrarlos, guardarlos e incluso volver a cargar los archivos guardados para realizar una
introspección en un momento diferente. Tiene 3 secciones:
● La primera sección es donde se mostrarán los mensajes de registro de su sistema.
● En el medio, tiene la opción de filtrar los mensajes excluyendo los niveles de gravedad.
● La sección inferior es para resaltar mensajes que incluyen una cadena (string) que ingresaste.
Los niveles de registro de ROS 2 están ordenados por gravedad:
Los mensajes fatales (fatal) indican que el sistema se cerrará para tratar de protegerse contra daños.
Los mensajes de error indican problemas significativos que no necesariamente dañan el sistema, pero
que impiden que funcione correctamente.
Los mensajes de advertencia (warn) indican actividad inesperada o resultados no ideales que pueden
representar un problema más profundo, pero que no dañan la funcionalidad por completo.
Los mensajes de información (info) indican actualizaciones de eventos y estados que sirven como
una verificación visual de que el sistema está funcionando como se esperaba.
Los mensajes de depuración (debug) detallan todo el proceso paso a paso de la ejecución del
sistema.
El nivel predeterminado es Información. Solo veremos mensajes del nivel de gravedad predeterminado
y niveles más graves.
RVIZ2: es la herramienta de visualización 3D de ROS. El objetivo principal es mostrar mensajes ROS
en 3D, lo que nos permite verificar visualmente los datos. Por ejemplo, puede visualizar la distancia
desde el sensor de un sensor de distancia láser (LDS) hasta un obstáculo, los datos de nube de puntos
(PCD) del sensor de distancia 3D como RealSense, Kinect o Xtion, el valor de la imagen obtenido de un
cámara y muchos más sin tener que desarrollar el software por separado.
También admite varias visualizaciones utilizando polígonos especificados por el usuario, y los
marcadores interactivos permiten a los usuarios realizar movimientos interactivos con comandos y
datos recibidos del nodo de usuario. Además, ROS describe robots en formato de descripción de robot
unificado (URDF), que se expresa como un modelo 3D para el cual cada modelo se puede mover u
operar de acuerdo con su grado de libertad correspondiente, por lo que se pueden usar para simulación
o control.
ROS2 Bag: ros2 bag es una herramienta de línea de comandos para registrar datos publicados sobre
tópicos en su sistema. Acumula los datos transmitidos sobre cualquier número de tópicos y los guarda
en una base de datos.
ROS2 tf2: es la biblioteca de transformación, que permite al usuario realizar un seguimiento de
múltiples marcos de coordenadas a lo largo del tiempo. tf2 mantiene la relación entre los marcos de
coordenadas en una estructura de árbol amortiguada en el tiempo y permite al usuario transformar
puntos, vectores, etc. entre dos marcos de coordenadas cualesquiera en cualquier momento deseado.
Si desea usar tf2 para transformar entre marcos de coordenadas, sus nodos deberán escuchar las
transformaciones. Lo que hará es recibir y almacenar en búfer todos los marcos de coordenadas que se
transmiten en el sistema y consultar transformaciones específicas entre marcos.
Espacio de trabajo (Workspace): es un directorio que contiene paquetes de ROS 2. También tiene la
opción de obtener una "superposición" (“overlay”), un espacio de trabajo secundario donde puede
agregar nuevos paquetes sin interferir con el espacio de trabajo existente de ROS 2 que está
ampliando, o "subyacente" (“underlay”). Su espacio subyacente debe contener las dependencias de
todos los paquetes en su superposición. Los paquetes en su espacio de superposición anularán los
paquetes en el subyacente. También es posible tener varias capas de capas subyacentes y
superposiciones, y cada superposición sucesiva utiliza los paquetes de sus capas subyacentes
principales (o parents).
El espacio de trabajo es un espacio que almacena y construye paquetes creados por usuarios y
paquetes publicados por otros desarrolladores. Los usuarios realizan la mayoría de las operaciones
relacionadas con ROS en esta carpeta. Los detalles son los siguientes:
■ /build: Hay archivos relacionados a la compilación.
■ /devel: msg, archivos de encabezado srv y biblioteca de paquetes del usuario, archivos de ejecución
■ /src: en esta carpeta, puede guardar y crear sus propios paquetes ROS o paquetes desarrollados por
otros desarrolladores.
Paquetes [PACKAGE (Cmake)]: Un paquete es la unidad básica de ROS. Puede considerarse un
contenedor para su código ROS 2. Ayuda cuando tenemos que instalar un código o compartirlo con
otros para usarlo fácilmente. La creación de paquetes en ROS 2 utiliza "ament" como sistema de
compilación y "colcon" como herramienta de construcción (no se si ament los construye y colcon los
compila o al revés). Puede crear un paquete usando CMake o Python (nosotros usamos Cmake). La
mejor práctica es crear sus paquetes en la carpeta /src en su espacio de trabajo. Esto mantiene el nivel
superior del espacio de trabajo "limpio". Obs: Un metapaquete es un conjunto de paquetes que tienen
un propósito común.
En el directorio de un paquete encontraremos:
/src (directorio): aquí es donde irán todos nuestros nodos C++ personalizados en el futuro.
/include (directorio): Archivos de encabezado (Header Files)
/launch Archivos de lanzamiento (Launch Files) utilizados con roslaunch
/node Scripts para rospy
/msg Archivos de mensajes
/srv Archivos de servicio
[Link] (file): contiene metainformación sobre el paquete, como nombre, versión, descripción,
licencia, mantenedor y algunas etiquetas que terminan en "_depend" (esta última es donde su
[Link] enumeraría sus dependencias de otros paquetes).
A continuación se encuentran las descripciones de cada declaración:
<?xml>: esta etiqueta indica que el contenido del documento cumple con la versión 1.0 de XML.
<package>: esta etiqueta se combina con la etiqueta </package> para indicar la parte de
configuración del paquete ROS.
<name>: esta etiqueta indica el nombre del paquete. Se utiliza el nombre del paquete ingresado
al crear el paquete. El desarrollador puede cambiar el nombre del paquete.
<version>: esta etiqueta indica la versión del paquete. El desarrollador puede asignar la versión
del paquete.
<description>: una breve descripción del paquete. Usualmente 2-3 oraciones.
<maintainer>: el nombre y la dirección de correo electrónico del administrador del paquete.
<license>: esta etiqueta indica la licencia, como BSD, MIT, Apache, GPLv3, LGPLv3. (Nosotros
usaremos la Licencia Apache 2.0)
<url>: esta etiqueta indica la dirección de la página web que describe el paquete, o la gestión de
errores, el repositorio, etc. Según el tipo, puede asignarla como sitio web, rastreador de errores o
repositorio.
<autor>: el nombre y la dirección de correo electrónico del desarrollador que participó en el
desarrollo del paquete.
<buildtool_depend>: describe las dependencias del sistema de compilación. (Nosotros
utilizaremos ament_cmake)
<build_depend>: nombre del paquete dependiente al compilar el paquete.
<depend>: biblioteca de cliente dependiente y dependencias correspondientes a las
declaraciones de inclusión de su nodo (en el archivo cpp). Por ejemplo:
<run_depend>: nombre del paquete dependiente cuando se ejecuta el paquete.
<test_depend>: nombre del paquete dependiente al probar el paquete. (Usamos
ament_lint_auto y ament_lint_common)
<export>: se usa cuando se usa un nombre de etiqueta que no está especificado en ROS. El
caso más utilizado es el de los metapaquetes. En este caso, use
<export><metapackage/></export> para notificar que el paquete es un metapaquete. (Usamos
<export> <build_type>ament_cmake</build_type> <export>)
<metapackage>: la etiqueta oficial utilizada dentro de la etiqueta de exportación que declara el
paquete actual como un metapaquete.
[Link] (archivo): describe cómo construir el código dentro del paquete. Configura la creación
de archivos ejecutables, la compilación de prioridad de paquetes de dependencia, la creación de
enlaces, etc. Las opciones en el archivo de configuración de compilación ([Link]) son las
siguientes:
● cmake_minimum_required: describe la versión mínima requerida de 'cmake' instalada en el
sistema operativo.
● project: describe el nombre del paquete. Use el nombre del paquete ingresado en 'package. xml'
● find_package: es el paquete de componentes necesario para realizar una compilación sobre
ament. Si el paquete ingresado aquí no se encuentra en el sistema, ocurrirá un error al compilar
el paquete. En otras palabras, esta es una opción para requerir la instalación de paquetes
dependientes para el paquete personalizado: find_package(<dependency> REQUIRED)
(always)
If: then:
● add_executable, ament_target_dependencies & install: Primero, especifica el ejecutable que
se creará después de la compilación. En el ejemplo siguiente, las líneas especifican que el
sistema se refiera al archivo 'src/publisher_member_function.cpp' para generar el archivo
ejecutable 'talker' (nombre). Si hay que crear dos o más archivos ejecutables, agregue una
entrada adicional 'add_executable'.
Luego, tenemos que declarar sus dependencias:
Finalmente, agregue la sección install(TARGETS…) para que ros2 run pueda encontrar su
ejecutable:
● include_directories: es una opción para especificar carpetas a incluir. En el ejemplo, se
configura ‘${catkin_ INCLUDE_DIRS}’, que hace referencia al archivo de encabezado, la carpeta
‘include’ en el paquete. Para especificar una carpeta de inclusión adicional, agréguela a la
siguiente línea de '${catkin_INCLUDE_DIRS}'.
● add_library: declara la biblioteca que se creará después de la compilación. La siguiente opción
creará la biblioteca 'polygon_plugins' a partir del archivo 'polygon_plugins.cpp' en la carpeta 'src'.
● add_dependencies: es un comando para realizar determinadas tareas antes del proceso de
compilación, como la creación de mensajes dependientes o reconfiguraciones dinámicas. Las
siguientes opciones describen la creación de mensajes dependientes y la reconfiguración
dinámica, que son las dependencias de la biblioteca 'my_first_ros_pkg'
A continuación se describe la dependencia del archivo ejecutable llamado 'my_first_ros_pkg_node', no
la biblioteca mencionada anteriormente:
● target_link_libraries: es una opción que vincula bibliotecas y ejecutables que deben vincularse
antes de crear un archivo ejecutable
● rosidl_generate_interfaces: es una opción para generar un archivo .msg o .srv.