Uma introdução ao sistema operacional do robô: a estrutura final do aplicativo de robô

O Robot Operating System (ROS) não é um sistema operacional real, mas uma estrutura e um conjunto de ferramentas que fornecem a funcionalidade de um sistema operacional em um cluster de computadores heterogêneo. Sua utilidade não se limita a robôs, mas a maioria das ferramentas fornecidas está focada em trabalhar com hardware periférico.

O ROS é dividido em mais de 2.000 pacotes, cada pacote fornecendo funcionalidade especializada. O número de ferramentas conectadas ao framework é provavelmente seu maior poder.

Por que devo usar o Robot OS?

O ROS fornece funcionalidade para abstração de hardware, drivers de dispositivo, comunicação entre processos em várias máquinas, ferramentas para teste e visualização e muito mais.

O principal recurso do ROS é a maneira como o software é executado e a maneira como ele se comunica, permitindo que você projete softwares complexos sem saber como funciona determinado hardware. O ROS fornece uma maneira de conectar uma rede de processos (nós) com um hub central. Os nós podem ser executados em vários dispositivos e se conectam a esse hub de várias maneiras.

As principais maneiras de criar a rede são fornecer serviços solicitados ou definir conexões de editor/assinante com outros nós. Ambos os métodos se comunicam por meio de tipos de mensagem especificados. Alguns tipos são fornecidos pelos pacotes principais, mas os tipos de mensagens podem ser definidos por pacotes individuais.

Os desenvolvedores podem montar um sistema complexo conectando soluções existentes para pequenos problemas. A forma como o sistema é implementado, permite-nos:

• Substitua componentes por interfaces semelhantes em tempo real, eliminando a necessidade de parar o sistema para várias alterações

• Multiplexação de saídas de vários componentes em uma entrada para outro componente, permitindo a resolução paralela de vários problemas

• Conecte componentes feitos em várias linguagens de programação apenas implementando os conectores adequados ao sistema de mensagens, facilitando o desenvolvimento de software conectando módulos existentes de vários desenvolvedores

• Crie nós em uma rede de dispositivos, sem se preocupar com onde o código é executado e implementando sistemas de comunicação entre processos (IPC) e Remote Procedure Call (RPC)

• Conecte-se diretamente a feeds sob demanda de hardware remoto sem escrever nenhum código extra, empregando os dois marcadores anteriores

Planejamos demonstrar como isso é útil desenvolvendo iterativamente uma solução simples. Existem várias vantagens importantes em comparação com outras abordagens. O ROS tem suporte a várias plataformas e permite conexões entre processos em vários dispositivos por meio de conexões ponto a ponto que são tratadas nos bastidores. O design permite suporte para qualquer linguagem envolvendo as classes de comunicação C++ ou desenvolvendo manualmente classes para a interface da linguagem.

O ROS é feito por sua própria comunidade, destinado à sua comunidade. Após vários anos, isso resultou em uma grande quantidade de pacotes reutilizáveis ​​que são simples de integrar, graças à arquitetura do sistema.

Abordagens alternativas como MRPT, CARMEN, LCM, Player, Microsoft RDS e outras fornecem alguns desses recursos, mas não todos. Na maioria das vezes, as falhas do design são limitações de suporte a idiomas, comunicação não otimizada entre processos ou falta de suporte para vários dispositivos, que é sem dúvida o problema mais difícil de corrigir.

O que vamos construir?

Como nosso foco é o framework e não os algoritmos reais para problemas específicos, o problema dado será bastante simples. Nosso objetivo é construir um software para um computador de bordo que nos permita controlar e monitorar remotamente um robô, conectado a nós via Wi-Fi, usando um gamepad em nosso computador e um feed da câmera montada no robô.

Em primeiro lugar, faremos um programa simples se conectar a uma simulação simples, apenas para demonstrar os princípios básicos do ROS. Vamos anexar um gamepad a um computador e tentar projetar um bom esquema de controle para transformar a entrada do gamepad em sinais de controle para um robô.

As principais linguagens para escrever código ROS são C++ e Python, sendo C++ preferido devido ao melhor desempenho. Explicaremos nossos exemplos em Python devido a menos clichê no código e sem necessidade de construção explícita.

Instalação e configuração

As versões do ROS são referidas pelo nome. A partir desta data, a versão mais recente é Jade Turtle e a versão LTS mais recente Indigo Igloo . Ir para a versão LTS é preferível, e a compatibilidade com versões anteriores não é garantida no ROS, então todos os exemplos serão escritos para Indigo .

O ROS está disponível em várias plataformas *NIX. A versão oficialmente suportada está no Ubuntu. As versões OS X, Arch Linux, Debian, Raspbian e Android são suportadas pela comunidade.

Passaremos pelo processo de instalação do Ubuntu 14.04 no desktop. Os processos para todas as versões e plataformas suportadas estão disponíveis no site oficial. Máquinas virtuais com ROS instalado também estão disponíveis.

A instalação depende da plataforma (e a maioria das plataformas tem pacotes fornecidos), mas a configuração do espaço de trabalho é a mesma para todas as plataformas.

Instalação no Ubuntu

O ROS fornece seus próprios repositórios. O primeiro passo é adicioná-los.

 sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list' sudo apt-key adv --keyserver hkp://pool.sks-keyservers.net --recv-key 0xB01FA116 sudo apt-get update

Depois disso, você terá todos os pacotes hospedados para todas as versões do ROS disponíveis para sua versão do Ubuntu. Por exemplo, o Ubuntu 14.04 suporta indigo e jade .

A instalação dos pacotes básicos no desktop tem uma das três opções:

• sudo apt-get install ros-indigo-ros-base para uma instalação mínima

• sudo apt-get install ros-indigo-desktop para ter as ferramentas GUI adicionais básicas

• sudo apt-get install ros-indigo-desktop-full por ter todos os recursos oficiais, incluindo vários simuladores e bibliotecas para navegação e percepção

Para a melhor experiência de trabalho, a opção completa é recomendada. Para instalação em dispositivos que serão usados ​​apenas para executar nós, a versão base é suficiente. Independentemente da opção escolhida, você pode instalar qualquer pacote necessário chamado package_name executando:

 sudo apt-get install ros-indigo-<package-name>

Os sublinhados são substituídos por hífens no nome final, então stage_ros estará no pacote ros-indigo-stage-ros .

O próximo passo é inicializar o rosdep . Os pacotes no ROS podem declarar de quais componentes eles dependem. rosdep permite que você compile esses pacotes sem muita manipulação manual de dependências. Para inicializá-lo, chame:

 sudo rosdep init rosdep update

O ROS possui diversas variáveis ​​de ambiente utilizadas por suas ferramentas. Com a instalação padrão, o script bash para inicializá-los está localizado em /opt/ros/indigo/setup.bash . As variáveis ​​precisam ser inicializadas em cada sessão do bash, então a melhor solução é adicioná-las a ~/.bashrc .

 echo "source /opt/ros/indigo/setup.bash" >> ~/.bashrc source ~/.bashrc

Alguns pacotes instalam dependências externas via rosinstall , que está disponível como um pacote e instalado via sudo apt-get install python-rosinstall .

Este é o fim da instalação no Ubuntu. O que se segue é uma breve introdução à instalação de espaços de trabalho.

Configuração

Desde Groovy Galapagos , os espaços de trabalho ROS são gerenciados via catkin . Precisamos definir um diretório para todos os pacotes que hospedamos. Dentro do diretório, criamos uma pasta src e chamamos o formulário catkin_init_workspace dentro dela. Isso criará vários links simbólicos para a versão do ROS atualmente fornecida. A próxima etapa é adicionar esse espaço de trabalho também às variáveis ​​de ambiente.

Para realizar toda essa configuração do workspace, escolha um diretório vazio e execute os seguintes comandos:

 mkdir src cd src catkin_init_workspace cd .. catkin_make echo "source $(pwd)/devel/setup.bash" >> ~/.bashrc source ~/.bashrc

Agora você criou um espaço de trabalho no qual pode criar seus próprios pacotes ROS.

Familiarizando-se com as ferramentas

Criar qualquer código é um grande salto. Vamos primeiro nos familiarizar com alguns dos sistemas em execução nos bastidores. Nosso primeiro passo será executar a GUI básica e ver quais mensagens ela gera.

Para executar qualquer coisa no ROS, um processo central precisa ser iniciado. É tão fácil quanto abrir uma nova janela de terminal e digitar:

 roscore

Em toda a sua rede de dispositivos conectados, o roscore precisa ser iniciado apenas uma vez, no dispositivo que hospedará o hub central para despacho de comunicação.

O principal papel do roscore é informar aos nós a quais outros nós eles devem se conectar e de que maneira (seja por meio de uma porta de rede ou memória compartilhada). O objetivo é permitir que os nós se preocupem apenas com os dados que desejam saber, em vez de com qual nó eles desejam se conectar, minimizando o tempo e a largura de banda necessários para realizar toda a comunicação.

rqt

Depois de executar roscore , podemos iniciar a ferramenta GUI principal para ROS: rqt . O que vemos é muito decepcionante - uma janela vazia. rqt hospeda uma ampla variedade de plugins que podem ser configurados em qualquer configuração visual e em qualquer número de visualizações predefinidas.

Para começar, vamos executar o plugin Robot Steering , escolhendo-o em Plugins > Robot Tools > Robot Steering . O que obtemos são dois controles deslizantes, representando o movimento linear e rotacional que queremos que nosso robô tenha. Na parte superior do plugin, vemos uma caixa de texto com /cmd_vel . Podemos renomeá-lo para o que quisermos. Ele representa o nome do tópico no qual o direcionamento está publicando. As ferramentas do terminal são o melhor lugar para ver o que está acontecendo em segundo plano.

Ferramentas de terminal

O ROS possui várias ferramentas poderosas para inspecionar o que está acontecendo no sistema. A primeira ferramenta que apresentaremos é rostopic . Ele nos permite inspecionar tópicos nos quais os nós podem se inscrever e publicar. A execução rostopic list produzirá:

 /cmd_vel /rosout /rosout_agg

Os 2 últimos tópicos estão sempre em execução e estão relacionados aos sistemas ROS centrais. O tópico /cmd_vel está sendo publicado pela nossa direção. Renomear o tópico na direção também o renomeará aqui. Agora, estamos interessados ​​no que está acontecendo dentro do tópico. A execução rostopic echo /cmd_vel não nos mostrará nada (a menos que você tenha mexido nos controles deslizantes). O processo é executado até que o cancelemos. Vamos agora mover o controle deslizante vertical para 20 m/s. Olhando para o eco, podemos ver o seguinte repetido várias vezes:

 linear: x: 0.2 y: 0.0 z: 0.0 angular: x: 0.0 y: 0.0 z: 0.0

Com que frequência ele envia spam para esta mensagem? rostopic hz /cmd_vel diz a uma taxa média de 10 Hz. Bem, quantos tópicos como este posso executar através da minha conexão Wi-Fi lenta? rostopic bw /cmd_vel detecta uma média de 480 B/s.

Agora está tudo bem, mas falamos sobre os tipos de mensagem. Esses dados são bons para um ser humano, mas um aplicativo precisará dos dados brutos e precisará conhecer o tipo de mensagem para poder interpretar os dados. O tipo pode ser determinado com rostopic type /cmd_vel , nos dizendo que é um geometry_msgs/Twist . Todas as ferramentas de terminal ROS chamadas sem nenhum argumento retornam uma mensagem de ajuda padrão.

O ROS Wiki é bom o suficiente para fazer uma pesquisa na web por essa string resultar em uma explicação do Wiki sobre o que ela contém e como está estruturada. Mas não precisamos depender disso. rosmsg é a ferramenta geral para tipos de mensagens. A execução rosmsg show geometry_msgs/Twist retornará:

 geometry_msgs/Vector3 linear float64 x float64 y float64 z geometry_msgs/Vector3 angular float64 x float64 y float64 z

A mensagem consiste em dois vetores 3D, representando a velocidade linear e angular no espaço 3D.

Se quisermos a quais tópicos um nó está conectado, rosnode info <node-name> nos dará dados detalhados sobre o nó. As ferramentas rostopic , rosmsg e rosnode são as principais ferramentas para inspecionar a funcionalidade bruta do ROS. O ROS tem muito mais ferramentas GUI e terminal, mas essas estão fora do nosso escopo para esta introdução.

As principais ferramentas para executar nós ROS são rusrun e roslaunch . rosrun pode executar nós via rosrun <package_name> <node_name> , e roslaunch executa nós com base em arquivos de inicialização, com os quais nos familiarizaremos um pouco, pois são o elemento mais complexo da automação do ROS.

Podemos desligar tudo o que corremos para começar a trabalhar em nosso primeiro código. Para referência futura, não é preciso dizer que executar qualquer coisa relacionada ao ROS requer uma instância ativa do roscore . Muitos problemas que você encontra podem ser resolvidos fechando a janela do terminal em que o roscore é executado e abrindo uma nova para reiniciá-la. Isso atualiza todas as dependências que precisavam ser recarregadas, tanto no bash quanto no roscore .

Criando a Teleoperação do Gamepad

Nosso primeiro objetivo é imitar a funcionalidade do Robot Steering criando um nó que publica dados geometry_msgs/Twist em /cmd_vel com base na entrada do gamepad. Nossa primeira parada é o pacote de joy .

O pacote da joy

O pacote joy fornece drivers ROS genéricos para joysticks e gamepads. Ele não está incluído na instalação padrão, portanto, precisa ser instalado via:

 sudo apt-get install ros-indigo-joy

Após a instalação, podemos executar rosrun joy joy_node . Isso nos conectará ao joystick ou gamepad padrão. A execução rostopic list nos mostra que temos um tópico chamado /joy . Ouvir via rostopic echo nos mostra mensagens no seguinte formato (observe que você precisa interagir com o gamepad ou joystick para que as mensagens sejam publicadas).

 header: seq: 4156 stamp: secs: 1450707466 nsecs: 204517084 frame_id: '' axes: [0.0, 0.0, 0.0, -0.0, 0.0, 0.0, 0.0, 0.0] buttons: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

Você pode ignorar os cabeçalhos por enquanto. Fora isso, temos axes e buttons , explicando bem o que eles representam. Mover eixos e apertar botões no controlador resultará na alteração desses números. Usando nossas ferramentas, podemos determinar que o tipo de mensagem é sensor_msgs/Joy e o formato é:

 std_msgs/Header header uint32 seq time stamp string frame_id float32[] axes int32[] buttons

Criando nossa teleoperação

O primeiro passo para escrever código é fazer um pacote. Dentro da pasta src da área de trabalho, execute:

 catkin_create_pkg toptal_tutorial rospy joy geometry_msgs sensor_msgs

Aqui indicamos o nome do pacote que estamos criando, seguido pelos pacotes dos quais planejamos depender. Não se preocupe, as dependências podem ser atualizadas manualmente mais tarde.

Agora temos uma pasta toptal_tutorial . Dentro da pasta, crie uma pasta de scripts que abrigará todos os nossos scripts Python.

Vamos criar um arquivo chamado teleop.py e dentro dele vamos definir:

 #!/usr/bin/env python import rospy from sensor_msgs.msg import Joy def joy_callback(data): print data def main(): rospy.init_node('teleop') rospy.Subscriber('joy', Joy, joy_callback) while not rospy.is_shutdown(): pass if __name__ == '__main__': main()

Também precisaremos definir chmod +x teleop.py para que o script se torne executável. A execução rosrun joy joy_node em um terminal e rosrun toptal_tutorial teleop.py em outro resultará na saída do terminal de teleop.py sendo preenchida com mensagens Joy.

Vamos examinar o que o código faz.

Primeiro, importamos o rospy, que hospeda a biblioteca para interagir com o framework ROS. Cada pacote que define mensagens possui um subpacote msg com definições de mensagens nele. Estamos importando Joy para lidar com a entrada. Não há necessidade de importar tipos de mensagens incorporados (como Header from std_msgs.msg que está na mensagem Joy ), a menos que queiramos mencioná-los explicitamente.

Nosso primeiro passo é inicializar um nó com um nome específico (neste caso, chamamos de “teleop”). Depois disso criamos um assinante que se inscreve no tópico “joy” do tipo sensor_msgs.msg.Joy , e que trata cada mensagem chamando a função joy_callback . Os retornos de chamada recebem um parâmetro, os dados da mensagem. O acesso aos membros dos dados é simples. Se quisermos imprimir o estado do primeiro eixo, se lembrarmos do tipo de mensagem, chamaríamos print data.axes[0] e será um float. O loop no final faz um loop até que o ROS seja desligado.

Nosso próximo passo seria lidar com nossos dados de alguma forma. Devemos criar uma mensagem Twist que muda dependendo da entrada, e então a publicaremos no tópico cmd_vel .

 #!/usr/bin/env python import rospy from sensor_msgs.msg import Joy from geometry_msgs.msg import Twist # new from functools import partial # new def joy_callback(pub, data): # modified cmd_vel = Twist() # new cmd_vel.linear.x = data.axes[1] # new cmd_vel.angular.z = data.axes[0] # new pub.publish(cmd_vel) # new def main(): rospy.init_node('teleop') pub = rospy.Publisher('cmd_vel', Twist, queue_size=1000) # new rospy.Subscriber('joy', Joy, partial(joy_callback, pub)) # modified while not rospy.is_shutdown(): pass if __name__ == '__main__': main()

Primeiro, adicionamos a mensagem Twist e adicionamos suporte para argumentos de função de ligação via functools.partial . Criamos um publisher, pub , que publica em cmd_vel uma mensagem do tipo Twist . Vinculamos esse editor ao retorno de chamada e fazemos com que ele publique uma mensagem Twist em cada entrada com as velocidades representadas pelos dois primeiros eixos. Este código faz o que esperamos e podemos ver a saída resultante via rostopic echo /cmd_vel .

Ainda temos um problema. O tópico /joy pode ser publicado com ótimos preços. Se monitoramos o rostopic hz /cmd_vel e movemos o analógico em círculos, podemos ver um grande número de mensagens. Isso não apenas resulta em uma grande quantidade de comunicação, mas os processos que recebem essas mensagens precisam processar cada uma delas. Não há necessidade de publicar esses dados com tanta frequência, e é melhor apenas publicar a uma taxa estável de 10 Hz. Podemos fazer isso com o código a seguir.

 #!/usr/bin/env python import rospy from sensor_msgs.msg import Joy from geometry_msgs.msg import Twist from functools import partial def joy_callback(cmd_vel, data): # modified cmd_vel.linear.x = data.axes[1] cmd_vel.angular.z = data.axes[0] # moved pub.publish(cmd_vel) to main loop def main(): rospy.init_node('teleop') cmd_vel = Twist() # new pub = rospy.Publisher('cmd_vel', Twist, queue_size=1000) rospy.Subscriber('joy', Joy, partial(joy_callback, cmd_vel)) # modified rate = rospy.Rate(10) # new while not rospy.is_shutdown(): pub.publish(cmd_vel) # new rate.sleep() # new if __name__ == '__main__': main()

Modificamos o retorno de chamada para receber o objeto Twist mutável e modificá-lo dentro do loop. A função sleep do rospy.Rate mantém uma frequência de saída estável.

O código final resultará no tópico /cmd_vel obtendo comandos de velocidade em 10 Hz, imitando a saída do plug-in Robot Steering rqt .

Executando um sistema simulado

Simulando o mundo

Nosso primeiro objetivo é criar um ambiente no qual possamos simular um cenário que queremos alcançar. O nó stageros dentro do pacote stage_ros nos permite executar um robô dentro de um estágio 2D definido por meio de uma imagem. Existe toda uma sintaxe, descrita no pacote stage_ros para arquivos mundiais e como gerá-los. É bastante simples, mas fora do nosso escopo. Por sorte, o pacote vem com várias demos do mundo. Primeiro, vamos ao diretório dos arquivos executando:

 roscd stage_ros cd world

Dentro da pasta existem vários arquivos. Vamos executar um.

 rosrun stage_ros stageros willow-erratic.world

Isso criou vários tópicos. O significado de cada um deles também é documentado com o pacote. A parte importante é que tem cmd_vel .

Dentro do palco exibido, há um quadrado azul, representando o robô que você controla. Usando nosso código ou Robot Steering , podemos controlar esse robô. Experimente.

Configurando nosso sistema por meio de arquivos de inicialização

vamos criar uma pasta launch dentro do nosso pacote, e dentro dela criar um arquivo chamado teleop.launch . A estrutura final da pasta deve ficar assim:

 toptal_tutorial/ ├── CMakeLists.txt ├── launch │ └── teleop.launch ├── package.xml ├── scripts │ └── teleop.py └── src

Dentro do arquivo teleop.launch vamos definir um conjunto de nós e suas interconexões.

 <launch> <arg name="world_file" default="$(find stage_ros)/world/willow-four-erratics-multisensor.world" /> <node pkg="stage_ros" type="stageros" name="simulated_world" args="$(arg world_file)"></node> <group ns="robot_0"> <node pkg="joy" type="joy_node" name="joy_input"></node> <node pkg="toptal_tutorial" type="teleop.py" name="joy_convert"></node> </group> </launch>

O novo mundo consiste em quatro robôs, e cada um de seus tópicos tem um prefixo de robot_<n> . Portanto, o robô número 0 tem um tópico de comando de velocidade chamado robot_0/cmd_vel . É por isso que colocamos nosso controle dentro de um namespace chamado robot_0 , para ajustar seus nomes ao novo formulário. Nesse sentido, você pode pensar em nomes de tópicos como pastas em um sistema de arquivos.

Para executar arquivos de lançamento, não é necessário roscore . De certa forma, roscore é apenas um caso especial de um arquivo de inicialização que não faz nada. Se um roscore estiver faltando, apenas o primeiro arquivo de inicialização executado executará um núcleo, enquanto o restante se conectará a ele. Agora, executamos o lançamento com:

 roslaunch toptal_tutorial teleop.launch

Se tudo estiver correto, isso resultará em um simulador com 4 robôs, um dos quais é controlado com nosso gamepad ou joystick. Este mundo tem muito mais sob o capô do que o anterior. Cada um dos quatro robôs tem:

 /robot_<n>/base_pose_ground_truth /robot_<n>/base_scan_0 /robot_<n>/base_scan_1 /robot_<n>/camera_info_0 /robot_<n>/camera_info_1 /robot_<n>/cmd_vel /robot_<n>/depth_0 /robot_<n>/depth_1 /robot_<n>/image_0 /robot_<n>/image_1 /robot_<n>/odom

Substituímos <n> por 0, 1, 2 ou 3. Isso nos leva ao nosso último tópico.

Visualizando nossos dados com rqt

Não nos aprofundamos muito no rqt , mas é a ferramenta perfeita para visualizar dados mais complexos. Você pode experimentar todos os tópicos, mas vamos nos concentrar nos image_0 , image_1 , depth_0 e depth_1 .

Vamos iniciar o rqt e remover quaisquer plugins abertos. Agora vamos abrir 4 visualizadores de imagem ( Plugins > Visualization > Image View ), e colocá-los em uma formação de grade 2x2. Por fim, no canto superior esquerdo de cada uma das visualizações, vamos escolher um dos quatro tópicos indicados para robot_0 .

O que temos é visão estéreo com percepção de profundidade, com câmeras de baixa resolução. Tenha em mente que poderíamos até obter esse resultado sem nosso sistema de entrada. Se apenas executarmos isso (de dentro da pasta stage_ros/world ):

 rosrun stage_ros stageros willow-four-erratics-multisensor.world

e adicionar o plugin Robot Steering com um tópico chamado /robot_0/cmd_vel , teríamos os mesmos resultados com os controles sendo controles deslizantes na tela.

Aplicando os resultados a um sistema real

Muitos hardwares têm suporte total para ROS, muitas vezes fornecido por voluntários terceirizados. Muitas plataformas de robôs possuem drivers que geram esses tipos de mensagens, e o ROS possui nós que pegam uma webcam e publicam um feed de imagem.

Enquanto o último resultado foi uma simulação do que queremos alcançar, o mesmo pode ser alcançado com as seguintes modificações:

• Instale o ROS no computador de bordo do seu robô
• Crie um arquivo de lançamento para o computador de bordo que conecta o ROS à plataforma subjacente e todos os sensores de alto nível, como câmeras, telêmetros a laser e outros. Os nós necessários já podem existir ou podem ser implementados criando um editor/assinante para o ROS de um lado e um driver para comunicações seriais do outro
• Faça o launchfile ser executado na inicialização
• Em seu computador remoto, adicione export ROS_MASTER_URI=http://<robot_hostname>:11311/ para sua inicialização bash, fazendo com que o computador remoto procure roscore nesse nome de host e porta fornecidos
• Inicie rqt e/ou quaisquer scripts para monitorar e controlar o robô

O que isso realmente significa é apenas exportar a variável de ambiente adequada no dispositivo remoto, e o resto se trata sozinho. A execução do ROS em um cluster de computador precisa apenas que uma etapa seja executada para cada máquina.

Conclusão

Nós demonstramos como, com muito pouca codificação, você pode ter um sistema complexo de variáveis ​​que você pode manipular a seu bel-prazer. O sistema simples de editor/assinante permite desenvolver rapidamente um pipeline de software que processa dados em um cluster de computadores, sem se preocupar com a implementação subjacente de determinados elementos.

Enquanto usamos um simulador simples, simuladores mais complexos como o gazebo (também incluído na versão desktop completa) permitem que você crie mundos 3D com física e sensores complexos, e pode lhe dar uma experiência dos resultados finais e do produto muito antes de ser desenvolvido.

Esta introdução foi muito básica, mas a esperança é que você tenha se interessado mais em trabalhar com esse framework versátil.