Diretório
4 arquitetura de comunicação ROS
4.1.1 Iniciar o mestre: roscore
4.1.2 启动 nó: rosrun, roslaunch
4 arquitetura de comunicação ROS
Nó:
No mundo do ROS, a menor unidade de processo é um nó. Pode haver vários arquivos executáveis em um pacote de software.Depois que o arquivo executável é executado, ele se torna um processo.Este processo é chamado de nó no ROS. De Cheng
Do ponto de vista processual, o nó é um arquivo executável (geralmente um arquivo executável gerado pela compilação C ++, um script Python)
É executado e carregado na memória; do ponto de vista funcional, geralmente um único indivíduo responsável por um robô de nó
Função Como o módulo de função do robô é muito complicado, geralmente não concentramos todas as funções em um nó e
Usará uma abordagem distribuída. Por exemplo, existe um nó para controlar o movimento das rodas do chassi, um nó para dirigir a câmera para obter imagens, um nó para dirigir o lidar e um nó para planejar o caminho com base nas informações do sensor ...
Mestre:
O mestre é equivalente ao centro de gerenciamento em toda a arquitetura de comunicação da rede, gerenciando cada nó. O nó é registrado primeiro no mestre e, em seguida, o mestre incluirá o nó no programa ROS inteiro. A comunicação entre os nós também é primeiro "puxada" pelo mestre, para que a comunicação ponto a ponto possa ser realizada em pares. Quando o programa ROS é iniciado, a primeira etapa é iniciar o mestre primeiro e o gerenciador de nós processa os nós e os inicia sucessivamente.
4.1 Iniciar o mestre e o nó
4.1.1 Iniciar o mestre: roscore
Ao iniciar o ROS, primeiro insira o comando roscore para iniciar o master:
$ roscore
No momento, o mestre do ROS é iniciado e o servidor de parâmetros e de rosca também é iniciado, do qual o rosout é responsável por
Um nó da saída do log, sua função é informar o usuário sobre o status atual do sistema, incluindo o erro do sistema de saída, aviso etc.
Aguarde e registre o log no arquivo de log; o servidor de parâmetros é o servidor de parâmetros, não é um nó,
É um servidor que armazena configurações de parâmetros. Toda vez que executamos o nó ROS, precisamos iniciar o mestre, para que o nó possa ser iniciado e registrado.
4.1.2 启动 nó: rosrun, roslaunch
Você pode usar rosrun, roslaunch
O uso detalhado do comando rosrun é o seguinte:
$ rosrun [--prefix cmd] [--debug] pkg_name node_name [ARGS]
O rosrun procurará o programa executável chamado EXECUTABLE em PACKAGE e passará o parâmetro opcional ARGS.
comando roslaunch :
roslaunch pkg_name file_name.launch
O nó principal e vários nós podem ser iniciados ao mesmo tempo.O comando roslaunch detectará automaticamente se o roscore do sistema está em execução, ou seja, para confirmar se o gerenciador de nós está em execução, se o mestre não estiver iniciado, o roslaunch iniciará o mestre primeiro Depois siga as regras de lançamento.
4.1.3 comando rosnode
- A lista rosnode lista as informações do nó atualmente em execução
- informações do rosnode node_name mostra informações detalhadas do nó
- rosnode kill node_name finaliza um nó
- nó de conexão de teste de ping do rosnode
- A máquina rosnode lista nós em execução em uma máquina ou lista específica
- A limpeza do rosnode limpa as informações de registro de nós inacessíveis
ajuda do rosnode para ver o uso do comando rosnode.
4.2 método de comunicação ROS
O método de comunicação do ROS é o conceito principal do ROS. Existem quatro tipos de métodos de comunicação do ROS:
- Tópico
- Serviço
- Serviço de Parâmetros
- Biblioteca de ações Actionlib
4.2.1 Tópico
Entre os métodos de comunicação no ROS, o tópico é comumente usado. Para mensagens periódicas em tempo real, usar o tópico para transmitir é a melhor opção. O tópico é um tipo de método de comunicação unidirecional ponto a ponto, em que "ponto" se refere ao nó, o que significa que as informações podem ser transferidas entre os nós por meio do tópico. O tópico precisa passar pelo processo de inicialização das seguintes etapas: Primeiro, o nó do publicador e o nó do assinante devem se registrar no gerenciador do nó, depois o publicador publicará o tópico e o assinante assinará o tópico sob o comando do mestre, estabelecendo, assim, Comunicação. Observe que todo o processo é unidirecional. O assinante processará a mensagem quando a receber, geralmente esse processo é chamado de retorno de chamada. O chamado retorno de chamada é definir uma função de processamento antecipadamente (escrita no código); quando houver uma mensagem, a função de processamento será acionada, a função processará a mensagem.
A comunicação de tópicos é um método de comunicação assíncrona unidirecional.
O diagrama esquemático de sua estrutura é mostrado abaixo;
4.2.1.1 comando rostópico:
- lista rostópica lista todos os tópicos atuais
- informações rostópicas topic_name exibe as informações de atributo de um tópico
- eco rostopic topic_name exibe o conteúdo de um tópico
- pub rostopic topic_name ... Publicar conteúdo em um tópico
- rostopic bw topic_name Exibir a largura de banda de um tópico
- rostopic hz topic_name Ver a frequência de um tópico
- rostopic find topic_type encontre um tipo de tópico
- tipo rostópico topic_name Exibir o tipo de um tópico (msg)
4.2.1.2 arquivo msg
Mensagem é o tipo de dado do conteúdo do tópico, também conhecido como padrão de formato do tópico. Definido no arquivo com o sufixo .msg.
Os tipos de dados básicos da mensagem incluem bool, int8, int16, int32, int64 (e uint), float, float64, string, tempo, duração, cabeçalho, array de comprimento variável [] e array de comprimento fixo [C].
Usamos uma mensagem específica para entender, como msg sensor_msg / image, o local é armazenado em sensor_msgs / msg / image.msg, sua estrutura é a seguinte:
std_msg / Cabeçalho do cabeçalho
uint32 seq
carimbo de data / hora
string frame_id
altura uint32
largura uint32
codificação de string
uint8 is_bigendian
etapa uint32
uint8 [] data
4.2.1.3 comando rosmsg:
- A lista rosmsg lista todas as mensagens no sistema
- rosmsg show msg_name exibe o conteúdo de uma mensagem
4.2.2 Serviço
A comunicação de serviço é bidirecional, não apenas pode enviar mensagens, mas também possui feedback. Portanto, o serviço inclui duas partes, uma é o solicitante (Clinet) e a outra é o atendedor / provedor de serviços (servidor). Nesse momento, o solicitante (Cliente) enviará uma solicitação, aguardará o processamento do servidor e retornará uma resposta, para que toda a comunicação do serviço seja concluída por meio de um mecanismo semelhante a "solicitação-resposta".
O diagrama esquemático desse método de comunicação é o seguinte: O nó B é um servidor (respondedor), que fornece uma interface de serviço chamada / Service.Nós geralmente usamos o tipo de string para especificar o nome do serviço, semelhante ao tópico. O nó A iniciou uma solicitação ao nó B e recebeu feedback após o processamento.
O serviço é um método de comunicação síncrona. A chamada sincronização significa que o Nó A aguardará a resposta no local após emitir a solicitação até
Depois que o Nó B processa a solicitação e conclui a resposta, o Nó A continuará sendo executado. O nó A está em processo de espera
Comunicação bloqueada. Esse modelo de comunicação não possui mensagens freqüentes, conflitos e alta ocupação de recursos do sistema, e apenas executa serviços ao aceitar solicitações, o que é simples e eficiente.
4.2.2.1 tópico serviço VS
4.2.2.2 Comando rosservice
- lista de serviços Ross exibir lista de serviços
- informações sobre o serviço de impressão
- tipo de serviço
- serviço de impressão uri rosservice uri ROSRPC
- rosservice find Encontre serviço por tipo de serviço
- A chamada rosservice usa os argumentos fornecidos para chamar o serviço
- parâmetros do serviço de impressão rosservice args
4.2.2.3 arquivo srv
O arquivo srv é usado para descrever o serviço (tipo de dados do serviço, o formato dos dados da comunicação do serviço é definido em * .srv. Ele declara um serviço, incluindo a solicitação (solicitação) e resposta (resposta) em duas partes.
A declaração de formato é a seguinte: Exemplos:
msgs_demo / srv / DetectHuman.srv
bool start_detect
---
my_pkg / HumanPose [] pose_data
msgs_demo / msg / HumanPose.msg
std_msgs / cabeçalho do cabeçalho
uuid string
int32 number_of_joints
my_pkg / JointPose [] joint_data
msgs_demo / msg / JointPose.msg
string joint_name
geometry_msgs / Pose pose
confiança floar32
O formato do arquivo srv é muito fixo, a primeira linha é o formato solicitado, separado por --- no meio e a terceira linha é o formato da resposta. Neste exemplo, a solicitação é se deve iniciar a detecção, a resposta é uma matriz e cada elemento da matriz é o gesto de uma pessoa (HumanPose). Quanto ao gesto humano, na verdade é uma msg, portanto, srv pode ser aninhado em msg, mas não pode ser aninhado em srv.
4.2.2.4 Comando rossrv
- rossrv show show descrição do serviço
- lista rossrv Listar todos os serviços
- serviço de exibição rossrv md5 md5sum
- O pacote rossrv lista os serviços no pacote
- pacotes rossrv lista pacotes contendo serviços
4.2.3 Servidor de parâmetros
Um servidor de parâmetros também pode ser considerado um "método de comunicação" especial. O ponto especial é que o servidor de parâmetros é onde os nós armazenam parâmetros, usados para configurar parâmetros e compartilhar parâmetros globalmente. O servidor de parâmetros usa a transmissão da Internet e é executado no gerenciador de nós para realizar todo o processo de comunicação.
O servidor de parâmetros, como outro método de transmissão de dados no ROS, é diferente do tópico e do serviço, é mais estático. O servidor de parâmetros mantém um dicionário de dados, que armazena vários parâmetros e configurações.
Existem três maneiras de manter o servidor de parâmetros:
- Manutenção de linha de comando
- Leia e escreva no arquivo de inicialização
- Código fonte do nó
4.2.3.1 Manutenção da linha de comandos: rosparam
- rosparam set param_key param_value Definir parâmetros
- rosparam obtém parâmetros de exibição param_key
- rosparam load file_name carrega parâmetros do arquivo
- rosparam dump file_name salva parâmetros no arquivo
- rosparam delete delete delete
- lista rosparam lista nomes de parâmetros
load && dump 文件
Os arquivos de carregamento e despejo precisam estar em conformidade com o formato YAML. Exemplos específicos do formato YAML são os seguintes:
nome: «Zhangsan»
idade: 20
sexo: 'M'
pontuação {chinês: 80, matemática: 90}
score_history: [85,82,88,90]
4.2.3.2 Ler e gravar no arquivo de inicialização
Existem muitas tags no arquivo de inicialização e existem apenas duas tags relacionadas ao servidor de parâmetros, uma é <param> e a outra
É <rosparam>.
4.2.3.3 código fonte do nó
O código-fonte do ROS, ou seja, use a API para operar o servidor de parâmetros. Introduziremos o conteúdo específico depois de estudar os capítulos seguintes.
4.2.4 Ação
O Actionlib é uma biblioteca muito importante no ROS. Semelhante ao mecanismo de comunicação de serviço, o actionlib também é um mecanismo de resposta a solicitações.
Método de comunicação, actionlib, compensa principalmente uma falta de comunicação de serviço, ou seja, quando o robô executa uma tarefa de longo prazo
No momento, se o método de comunicação de serviço for usado, o editor não receberá a resposta por um longo tempo, fazendo com que a comunicação receba
Dificultar. Quando a comunicação de serviço não pode concluir bem a tarefa, o actionlib pode ser mais adequado para comunicação de longo prazo.
Processo, o processo de comunicação actionlib pode ser visualizado a qualquer momento, o andamento do processo também pode ser encerrado, um recurso que o torna
Possui alta eficiência em alguns mecanismos especiais.
4.2.4.1 O princípio de funcionamento da ação
O princípio de funcionamento da Ação é o modo cliente-servidor, que também é um modo de comunicação bidirecional. Comunicando as partes em ROS
Sob o Protocolo de Ação, o intercâmbio e a comunicação de dados são realizados por meio de mensagens. cliente e servidor fornecem aos usuários uma simples
API para solicitar o destino (no lado do cliente) ou executar o destino por meio de chamadas de função e retornos de chamada (no lado do servidor).
O diagrama esquemático do modo de trabalho é o seguinte:
O cliente enviará a instrução de destino e a instrução de ação de cancelamento para o servidor, e poderá enviar informações de status em tempo real, informações de resultados, informações de feedback etc. para o cliente, concluindo assim a parte que o serviço não pode executar.
4.2.4.2 arquivo de ação
Use a biblioteca de ações para solicitar resposta.O formato de conteúdo da ação deve incluir três partes: objetivo, feedback e resultado.
- Target
Quando o robô executa uma ação, ele deve ter informações claras sobre o alvo em movimento, incluindo a configuração de alguns parâmetros, direção, ângulo, velocidade, etc. Para que o robô possa concluir a tarefa de movimento.
- Comentários
No decorrer da ação, deve haver feedback das informações de status em tempo real para o implementador do servidor, informando ao implementador o status de conclusão da ação, para que o implementador possa fazer um julgamento preciso para modificar o comando.
- O resultado
Quando a movimentação é concluída, o servidor de ação envia os dados do resultado do exercício para o cliente, para que o cliente possa obter todas as informações da ação, por exemplo, pode incluir a duração do movimento do robô, a postura final e assim por diante.
O nome do sufixo do arquivo de especificação de Ação é .action e seu formato de conteúdo é o seguinte:
# Defina a meta
uint32 dishwasher_id # Especifique qual máquina de lavar louça queremos usar
---
# Defina o resultado
uint32 total_dishes_cleaned
---
# Definir uma mensagem de feedback
float32 percent_complete
