Mobile Robotics simulation for ROS based robots using Visual
Components
Gustavo Emanuel Barbosa Teixeira
Dissertação de Mestrado
Orientador na FEUP: Prof. Germano Veiga
Mestrado Integrado em Engenharia Mecânica
Resumo
Atualmente existe uma crescente procura pela eficiência e flexibilidade na produção industrial. Para tal, o uso de tecnologias de simulação tem sido cada vez mais requisitado por ser uma solução de aplicabilidade rápida e de baixo custo.
Esta tecnologia permite desenvolver programas robóticos sem o robô físico, prever o seu comportamento, assim como perceber como é que qualquer alteração a uma linha de produção pode afetar a cadência de produção e sua eficiência.
Esta dissertação tem como objetivo o estudo do simulador de robótica Visual Components, analisar as suas competências e caraterísticas, principalmente no que diz respeito a robôs móveis (AGVs). Para além disso, pretende-se realizar uma ponte de comunicação entre a plataforma ROS e o Visual Components para que posteriormente se possam controlar robôs no ambiente virtual do Visual Components a partir desta plataforma.
Com este trabalho, concluiu-se que o Visual Components se trata de um programa bastante capaz no que diz respeito à programação industrial, devido a caraterísticas como a sua vasta biblioteca de componentes e a facilidade de criação de simulações. Trata-se também de um simulador com potencialidades no que diz respeito à simulação para desenvolvimento em robótica.
Nesta tese, ficou provado que é possível comunicar com o Visual Components apartir do ROS através de Websockets onde o Visual Components subscreve a um tópico ROS e este envia o seu conteúdo para o Components. Por se tratar de uma comunicação bidirecional, é possível realizar a comunicação com vários tópicos ao mesmo tempo, possibilitando testar vários programas em simultâneo, na mesma simulação.
Mobile Robotics simulation for ROS based robots using Visual
Components
Abstract
Nowadays there is a growing demand for production efficiency in term of task execution and the flexibility of the production line. In this regard, the use of simulation technologies has been increasingly demanded as it is a fast and low cost applicability solution. The use of robotic simulators allows the development of robotic programs without the physical robot and to predict their behaviour in a simulation environment. It is also possible to understand how any alteration to a production line could change the production rate as well as its efficiency.
This dissertation aims to study the robotics simulator Visual Components, to analyse its competences and characteristics mainly with respect to mobile robots (AGVs). In addition, it is intended to bridge the communication between the ROS platform and Visual Components so that robots can later be controlled in the Visual Components virtual environment with ROS.
With this work it was possible to realize that Visual Components is a very complete program at component level, with makes it possible to simulate the behavior of production lines and understand how the tested programs affect those lines. In addition, it has been proven that i tis possible to communicate with Visual Components from ROS through Websockets where Visual Components subscribes to a ROS topic and it posts its content to Visual Components. Since this is a bidirectional communication, it also allows Visual Components to communicate with multiple ROS topics at the same time, allowing the test of multiple programs simultaneously and in the same simulation.
Agradecimentos
A realização desta dissertação de mestrado contou com importantes apoios e incentivos sem os quais não se teria tornado uma realidade e aos quais estarei eternamente grato.
Ao Professor Germano Manuel Correia dos Santos Veiga, da Faculdade de Engenharia da Universidade do Porto, e ao Doutor Luís Freitas Rocha, do Centro de Robótica e Sistemas Inteligentes do INESC TEC, pela orientação, apoio e disponibilidade na solução dos problemas que foram surgindo ao longo da realização deste trabalho.
Aos meus amigos Alexandre Eusébio, Luís Castro, Raquel Reis, Luís Brás, Pedro Santos, Margarida Pinho, entre outros, que me suportaram durante os anos académicos e que sem eles este percurso não teria sido o mesmo.
Um agradecimento especial ao Mário José Gomes Lopes, que para além do seu apoio e preocupação incondicionais que mostrou desde que nos conhecemos, é uma grande referência para mim, como profissional e como pessoa.
Por último, um agradecimento especial aos meus pais. Eles que sempre me deram apoio incondicional, estiveram sempre presentes nos bons e maus momentos e fizeram de mim sempre a prioridade. A eles dedico este trabalho, pois sem eles não seria o homem que sou hoje.
Conteúdo
1 Introdução ... 1
1.1 Enquadramento do projeto e motivação ... 1
1.2 INESC TEC – Centro de Robótica e Sistemas Inteligentes ... 1
1.3 Objetivos do Projeto ... 2
1.4 Método seguido no projeto ... 3
1.5 Estrutura da dissertação ... 4
2 Estado da Arte ... 5
2.1 Simuladores robóticos para programação offline. ... 5
2.2 Simulação para desenvolvimento em robótica... 6
2.3 Principais Caraterísticas ... 7
2.4 Apresentação de Simuladores de Robótica ... 8
2.4.1 Gazebo ... 8
2.4.2 Unity ... 9
2.4.3 V-REP ... 10
2.4.4 RobotStudio – ABB ... 11
2.5 Introdução ao Visual Components ... 12
3 Visual Components ... 13
3.1 Biblioteca Works ... 15
3.2 Python API ... 20
3.2.1 vcSimVehicle ... 20
3.3 Robôs Móveis em Visual Components. ... 22
3.3.1 Simulação de Robôs Móveis com a biblioteca Works ... 22
3.3.2 Simulação de Robôs Móveis com o Python API ... 29
4 ROS ... 31
4.1 RosBridge ... 31
4.1.1 Protocolo ... 31
4.1.2 Subscribe ... 32
5 Comunicação ROS – Visual Components ... 33
5.1 Servidor RosBridge ... 33
5.1.1 Catkin_ws ... 33
5.1.2 Socket_pub_gus ... 34
5.2 Cliente Python ... 36
5.2.1 Comunicação em Python no Visual Components ... 37
5.3 Cliente C# ... 39
5.3.1 Plugin Exemplo – Hello World ... 40
5.3.2 Plugin Cliente C# ... 44
6 Conclusões e perspetivas de trabalho futuro ... 49
6.1 Conclusões ... 49
6.2 Trabalhos Futuros ... 50
Referências ... 51
Anexo A: Propriedades e Métodos da Biblioteca vcSimVehicle ... 53
Índice de Figuras
Figura 1-1 - Gráfico de Gantt com a distribuição das tarefas ao longo do tempo. ... 3
Figura 2-1 - Exemplos de simulações no Gazebo... 8
Figura 2-2 - Exemplos de simulações no Unity, utilizando ROS# ... 9
Figura 2-3 - Exemplos de simulações no V-REP ... 10
Figura 2-4 - Exemplos de simulações no RobotStudio ... 11
Figura 3-1 - Interface do Visual Components ... 13
Figura 3-2 - Separadores do Visual Components ... 13
Figura 3-3 - Painel apresentado do lado esquerdo da interface: a) Separador “Home”; b) Separador “Modeling”; c) Separador “Program” ... 14
Figura 3-4 - Layout da Simulação Exemplo ... 17
Figura 3-5 - Criação de componente Works TaskControl no ambiente de simulação ... 18
Figura 3-6 - a) Criação do componente “Works Process 1”; b) criação do “Conveyor 1”; c) Criação do componente “Works Process 2”; d) Criação do componente a transportar, o cilindro ... 18
Figura 3-7 - a) Primeira tarefa do componente “Works Process 1”; b) Segunda tarefa do componente “Works Process 1”; c) Primeira tarefa do componente “Works Process 2”... 19
Figura 3-8 - a) Terceira tarefa do componente “Works Process 2”; b) Registo da tarefa na “Tasklist” do componente “Works Robot Controller”; c) Atribuição da tarefa “Need” ao componente “Works Process 3”... 19
Figura 3-9 - Atribuição do Comportamento "Vehicle" a um componente ... 20
Figura 3-10 - Atribuição do comportamento "Python Script" a um componente ... 21
Figura 3-11 - Página do "Python Script" criado para o componente ... 21
Figura 3-12 - Confirmação do comportamento "Vehicle" pertencente à biblioteca “vcSimVehicle” do “Python API” ... 22
Figura 3-13 - Componente “Works Resource Pathfinder” ... 23
Figura 3-14 - Componente “Works Pathway Area” ... 24
Figura 3-15 - Exemplo da simulação de robôs móveis com a biblioteca “Works” ... 24
Figura 3-16 - Acoplamento de um braço robótico num robô móvel ... 25
Figura 3-17 - Simulação de braço robótico a retirar o componente a transportar ... 26
Figura 3-18 - Simulação de braço robótico a colocar componente transportado ... 26
Figura 3-19 - Escolha do layout do gráfico de monitorização ... 27
Figura 3-20 - Escolha do tipo de informação que se pretende obter... 27
Figura 3-21 - Gráfico gerado com os tipos de informação possíveis de obter durante a simulação ... 28
Figura 3-22 - Exemplo de monitorização de robôs móveis durante uma simulação ... 28
Figura 3-23 - Definição do componente, aplicação e comportamento do veículo no “Python Script” ... 29
Figura 3-24 - Definição de aceleração, desaceleração e velocidade máxima do veículo no “Python Script” ... 29
Figura 3-25 - Definição dos pontos utilizados na trajetória no “Python Script” ... 30
Figura 5-6 - Programa de comunicação por Websocket em Python ... 36
Figura 5-7 - Criação da porta de comunicação entre com a VirtualBox ... 37
Figura 5-8 - Resultado do programa de comunicação por Websocket em Python ... 37
Figura 5-9 - Programa de comunicação por Websocket em Python no “Python Script” do Visual Components .. 38
Figura 5-10 - Localização da bibliotec websocket na pasta site-packages do Visual Components ... 38
Figura 5-11 - Programa de comunicação por Websocket em Python quando compilado no Visual Components . 39 Figura 5-12 - Programa de comunicação por Websocket em C# ... 39
Figura 5-13 - Resultado do programa de comunicação por Websocket em C# ... 40
Figura 5-14 - Plugin "Hello World" ... 41
Figura 5-15 - Definições do Projeto Exemplo - Hello World, separador “Application” ... 41
Figura 5-16 - Definições do Projeto Exemplo - Hello World, separador “Build” ... 42
Figura 5-17 - Definições do Projeto Exemplo - Hello World, separador “Debug” ... 43
Figura 5-18 - Resultado do Plugin Exemplo – Hello World ... 43
Figura 5-19 – “Plugin Cliente C#” - Programa do Visual Studio ... 44
Figura 5-20 - Classe “WebsocketConnection” – “Plugin Cliente C#” ... 45
Figura 5-21 - Classe “Myplugin” – “Plugin Cliente C#” ... 45
Figura 5-22 – Classe MyContextAction – “Plugin Cliente C#” ... 46
Figura 5-23 - Criação de botão nas propriedades de um componente ... 46
Figura 5-24 – “Python Script” – “Plugin Cliente C#” ... 47
Figura 5-25 - Resultado do programa “Plugin Cliente C#” ... 47
Figura B-1 - Terminal de abertura do “catkin_ws” ... 59
Figura B-2 - Terminal de abertura do servidor RosBridge com o tópico “sub” ... 60
Siglas e Acrónimos
AGV Automated Guided Vehicle
API Application Programming Interface DOTS Data-oriented Tecnology Stack
ID Identity
IDLE Integrated Development and Learning Environment IoT Internet of Things
JSON JavaScript Object Notation
OGRE Object-oriented Graphics Rendering Engine Open GL ES Open Graphics Library for Embeded Systems PNG Portable Network Graphics
ROS Robot Operating System TCP Transmition Control Protocol URL Uniform Resource Locator
1 Introdução
Esta dissertação insere-se nas temáticas relativas a robôs móveis e simulação robótica, sendo que também foram abordados temas relativos à automação flexível e protocolos de comunicação informáticos.
O desafio proposto pelo Centro de Robótica e Sistemas Inteligentes do INESC TEC passa pelo estudo do simulador Visual Components relativamente à simulação de robôs móveis, em ambiente de simulação para desenvolvimento em robótica.
Sendo a plataforma ROS bastante utilizada no contexto de desenvolvimento em robótica, foi proposta também a exploração desta plataforma de forma a perceber como se poderia proceder à comunicação entre o ROS e o Visual Components e determinar as suas vantagens e inconvenientes.
Neste capítulo introdutório, pretende-se perceber o contexto deste projeto, quais os objetivos do mesmo, a metodologia seguida durante o período destinado ao trabalho e a estrutura da dissertação.
1.1 Enquadramento do projeto e motivação
A simulação assume um papel cada vez mais importante no desenho de soluções robóticas, quer em robôs para logística interna (AGVs e manipuladores móveis), quer no desenvolvimento de células robóticas. A sua utilização acelera o processo inicial de teste de programas robóticos tornando-o mais rápido e económico. Esta tecnologia pretende facilitar a criação e/ou alteração da logística de produção de forma a responder o mais eficientemente possível às necessidades de mercado.
Tendo em conta a metodologia da automação flexível, uma linha de produção deve ser capaz de satisfazer as necessidades dos seus clientes. Tal pode implicar alterações no layout da fábrica, na cadência de produção, etc. Desta forma, é importante prever como os robôs reagem a tais alterações e uma forma de o fazer é através da simulação.
1.2 INESC TEC – Centro de Robótica e Sistemas Inteligentes
Este trabalho foi realizado em parceria com o Centro de Robótica e Sistemas Inteligentes do INESC TEC. Este centro trabalha em estreita colaboração com empresas, outros Institutos e Universidades, seguindo o lema da Investigação e Desenvolvimento até à inovação,
design, prototipagem e implementação.
alguns deles:
• H2020 Fasten: Projeto europeu cujo objetivo é criar uma plataforma que permita a criação de produtos em fabrico aditivo de forma autónoma, rápida e de baixo custo(Office, 2017).
• H2020 Scalable: Projeto europeu cujo objetivo é a otimização e manutenção de linhas de produção em tempo real através de modelos virtuais da própria linha que, recebendo informação sobre o estado da produção em tempo real, consegue prever o comportamento da mesma e adaptá-la às necessidades de produção de forma ótima (INESC-TEC, 2017).
• P2020 Produtech – SIF: Projeto que constitui numa resposta integrada para o desenvolvimento e edificação de novos sistemas de produção, assentes em tecnologias de produção avançadas, que permitam preparar a indústria transformadora face aos desafios da 4ª revolução industrial (Produtech, 2017).
1.3 Objetivos do Projeto
Os projetos de investigação e desenvolvimento em robótica apresentam uma caraterística comum que é a necessidade de criação de um ambiente virtual. Neste âmbito, uma das ferramentas para simulação robótica utilizada pelo Centro de Robótica e Sistemas Inteligentes do INESC-TEC é o programa Visual Components. Nesta dissertação foi proposto explorar as capacidades deste programa no que diz respeito à simulação de robôs móveis, assim como às possibilidades de ligação com programas externos, neste caso o ROS.
Primeiramente, foi proposto o estudo do funcionamento do Visual Components em termos de simulação de linhas de produção com robôs antropomórficos e depois com robôs móveis. De seguida, foi proposto estudar as formas de comunicação do Visual Components com outros programas, incluindo o estudo do “.NET API” e do Visual Studio. Para este passo foi necessária a aprendizagem das linguagens de programação Python e C#.
Depois de perceber quais as melhores formas de comunicação com o Visual Components, procedeu-se ao estudo e criação de um tópico em ROS, o qual se encarrega de enviar uma mensagem “Hello World!”.
Finalmente na fase de criação da comunicação entre os dois programas, ROS e Visual Components, foi proposto encontrar uma solução do tipo servidor-cliente. Para tal procedeu-se à criação de um servidor ROS que envie a mensagem do tópico a um cliente que subscreva a esse mesmo tópico. Para a criação do cliente foram estudadas duas soluções:
• A criação de um cliente através do “Python API” do Visual Components, que requer a criação de um cliente em Python para receber a mensagem do servidor ROS;
• A criação de um cliente através da “.NET API” do Visual Components, que requer a criação de um cliente em C#, recorrendo ao Visual Studio, assim como, a criação de um plugin através da “.NET API” do Visual Components.
1.4 Método seguido no projeto
A metodologia utilizada para a realização do projeto assenta nas seguintes etapas: • Tecnologia de Simulação Robótica;
• Exploração do Visual Components:
o Capacidades e funcionamento do programa; o Biblioteca “Works”;
o “Python API” para robôs móveis; o “.NET API”.
• Exploração da plataforma ROS: o Potencialidades da plataforma; o Criação de tópicos e workspace; o Formas de comunicação com o ROS.
• Criação da comunicação entre o Visual Components e o ROS: o Através do “Python API”;
o Através do “.NET API”.
A Figura 1-1 mostra a distribuição das tarefas executadas ao longo do tempo, assim como uma tabela com a data de início e a duração da tarefa.
1.5 Estrutura da dissertação
Esta dissertação começa pela exploração das capacidades de um simulador de robótica e o impacto que a sua utilização pode ter no teste de programas robóticos, Capítulo 2. Seguidamente, foi explorado o simulador Visual Components com o objetivo de perceber as suas caraterísticas e modos de funcionamento. Nesta etapa foram realizadas várias simulações de forma a testar as várias caraterísticas deste simulador, entre elas a utilização da biblioteca “Works” e o separador “Modeling” que serão abordados no Capítulo 3. Estas simulações incluíram robôs antropomórficos, com a utilização da biblioteca “Works” e o separador “Modeling”, e robôs móveis, ou AGVs, onde se explorou também o comportamento “Vehicle” e a simulação recorrendo ao “Python API”.
O Capítulo 4 apresenta a plataforma ROS assim como estudo das suas caraterísticas e formas de funcionamento. Neste capítulo procedeu-se ao estudo de criação de um tópico ROS, cuja função é enviar a mensagem “Hello World!”, assim como à criação de um workspace ROS, o “catkin_ws”. Posteriormente, serão apresentadas as formas de comunicação com o ROS chegando-se ao “RosBridge” que permite o envio de tópicos ROS por Websockets. Aqui foi estudada a implementação do “RosBridge” assim como o seu protocolo de comunicação.
No Capítulo 5 procedeu-se ao desenvolvimento das soluções de comunicação ROS – Visual Components. Tal passa pela criação de um programa em Python que receba a mensagem do tópico ROS através de Websockets. Este programa requer a utilização de uma biblioteca que permita a comunicação por Websockets em Python, sendo a biblioteca escolhida a “websocket_client 0.56.0”.
Depois de confirmada a receção da mensagem do tópico ROS no programa Python, foi estudada a implementação deste programa no Visual Components, através do comportamento “Python Script” com o objetivo de receber a mensagem do tópico ROS no Visual Components. Como esta comunicação não teve sucesso pelas razões explicadas no Secção 5.2.1, o próximo passo foi encontrar outra solução para estabelecer a comunicação entre o ROS e o Visual Components.
A solução encontrada passou pela criação de uma aplicação cliente Websocket no Visual Studio na linguagem C# com o objetivo de receber a mensagem do tópico ROS. Após este programa receber a mensagem do tópico ROS com sucesso, procedeu-se à criação de um plugin no Visual Studio para o Visual Components através do “.NET API” deste programa. Este plugin possibilitou a comunicação entre o Visual Components e o ROS, como proposto.
O último capítulo apresenta as principais conclusões retiradas deste trabalho, assim como algumas propostas para trabalhos futuros neste tema.
2 Estado da Arte
Como a dissertação foi desenvolvida em torno do simulador de robótica Visual Components, torna-se necessário incluir e comparar outros simuladores com este. Começando pela sua definição, um simulador de robótica é um programa capaz de criar um ambiente virtual onde se podem desenvolver, visualizar e alterar programas robóticos. Neste ambiente virtual é possível simular o comportamento de um robô para que este possa ser visualizado pelo programador que pretende testar os seus programas.
A tecnologia de simulação torna-se cada vez mais corrente entre os fabricantes de robôs e produtores de software responsáveis pela criação destes simuladores, por se tratar de uma tecnologia que permite de forma rápida e acessível a realização de testes de programas para robôs.
O uso de um simulador de robótica é altamente recomendado independentemente do robô físico estar disponível ou não, pois permite que o programador teste e altere os seus programas até que estes sejam robustos o suficiente para poderem ser testados no robô físico. É também importante realçar que apenas em ambiente de simulação é possível repetir as condições iniciais de teste de forma exata, que o torna no ambiente mais justo para a comparação de algoritmos. Porém existem algumas desvantagens na utilização de simuladores, sendo uma das mais importantes a complexidade da construção do ambiente de simulação. O comportamento de um robô é maioritariamente afetado por três principais componentes: o próprio robô, a tarefa a realizar e o ambiente onde está inserido. Para que a simulação seja precisa é necessário simular com fiabilidade todas as combinações possíveis das interações, robô-tarefa-ambiente. Ora, é praticamente impossível que um simulador genérico consiga simular com fiabilidade todas as interações possíveis entre estes três componentes pelo simples facto que seria necessário um modelo de simulação para cada interação possível, afetando consequentemente algumas vantagens da utilização desta tecnologia como a velocidade de teste dos programas(Nehmzow, 2009).
O termo simulador pode se referir a diferentes aplicações de simulação de robótica, das quais se destacam o uso de simuladores para a programação offline de sistemas robóticos e o uso de simuladores para o desenvolvimento de novos robôs. Estes serão devidamente apresentados nas secções que se seguem.
2.1 Simuladores robóticos para programação offline.
A programação offline através de simulação é comum na área da robótica industrial, sendo que todos os fabricantes disponibilizam simuladores para o efeito. Existem ainda simuladores não associados a um fabricante concreto, dos quais se destacam o Visual Componentes e o Fast Suite. Este tipo de software de robótica simula um robô virtual que é capaz de imitar os movimentos de um robô físico, mas também incorpora uma virtualização do controlador industrial que permite que a programa gerado possua elevada compatibilidade com o sistema real. Este tipo de simulação é também utilizado para estudar a integração dos sistemas robóticos com os restantes sistemas que se encontrem em funcionamento numa determinada linha de produção. Também pode ser utilizado para alterar a composição das linhas quando se pretende alterar as cadências de produção e perceber como é que essas alterações afetam a produção, o que se torna bastante útil no ponto de vista da produção flexível.
Deste modo a simulação robótica pretende minimizar o risco associado à automação. A maioria da integração do sistema robótico é feito antes de qualquer alteração no chão de fábrica. A utilização desta tecnologia apresenta várias vantagens, destacando de seguida as principais (RIA, 2017):
• Planeamento: Geralmente os sistemas robóticos não são todos iguais, estes devem ser projetados para a tarefa que vão desempenhar e compatíveis com os restantes processos que se encontram em funcionamento. A simulação permite perceber se a integração dos sistemas robóticos é eficiente e se se compatibiliza com os restantes processos.
• Processo: A simulação robótica pode provar a eficiência dos processos de um sistema automatizado. Com uma simulação detalhada e precisa é possível garantir que o sistema robótico cumpre os tempos de produção e os ganhos de eficiência propostos.
• Maximização do investimento: Uma vez que a simulação está completa, o que resulta da mesma são programas para os robôs utilizados na solução. O software do simulador garante que os sistemas robóticos funcionam de acordo com a simulação. Desta forma, maximiza-se o investimento e garantem-se os ganhos de produtividade desejáveis.
Estes simuladores possuem duas características fundamentais: são orientados para utilizadores com poucas competências em programação genérica e não possuem motores de física, sendo deste modo a sua utilização limitada a ambientes pouco flexíveis.
2.2 Simulação para desenvolvimento em robótica
O segundo grande grupo de simuladores surgiu com o crescimento da robótica flexível e da robótica móvel, que apresentam necessidades específicas, nomeadamente no que diz respeito à simulação fidedigna de sensores e o comportamento de objetos livres no espaço. Por exemplo, no caso da robótica móvel, simuladores de robótica baseada em comportamento permitem que os utilizadores criem ambientes virtuais simples com apenas objetos rígidos e fontes de luz onde se pretende programar/desenvolver robôs para interagir com esses ambientes. O motor de física de um simulador permite a realização de simulações introduzindo elementos como gravidade, atrito e inércia. Porém, existem vários motores de física com caraterísticas distintas, visto serem projetados para diferentes finalidades. Alguns motores de física, concebidos para ser utilizados em ambientes de jogo de computador, focam-se no realismo do ambiente, a projeção de cores e no detalhe de cada elemento, enquanto que outros motores de física, projetados para simulação, estão mais focados na real representação do comportamento dinâmico de um determinado objeto, do atrito, das forças aplicadas, etc. Isto não significa que um motor de física projetado para um jogo de computador não possa ser adaptado para um simulador de robótica, sendo até prática bastante comum para que as simulações robóticas possam ser apelativas a nível de “renderização”. Um exemplo é o motor de física Nvidia PhysX, que embora tenha sido concebido para ambiente de jogo, as suas capacidades de representação física revelam-se bastante competentes em simuladores de robótica, como é o caso do Visual Components.
Idealmente, um programa deveria ser testado em vários simuladores de robótica com diferentes caraterísticas, de forma a não correr riscos na sua implementação no robô real. Mas como esta solução se torna bastante dispendiosa e morosa, a escolha de um simulador de robótica deve ter sobretudo em conta a atividade da organização que o pretenda utilizar (Tom Erez et al).
.
2.3 Principais Caraterísticas
Independentemente do tipo de simulador de robótica, este deve apresentar como principais caraterísticas:
• Linguagens suportadas: Cada simulador suporta determinadas linguagens de programação para o desenvolvimento de programas robóticos. As mais utilizadas são a C++ e Python. Quanto mais linguagens o simulador suportar, maior é a sua versatilidade para teste de programas robóticos.
• Motor de física: é a tecnologia que permite a simulação de sistemas físicos mais próximos da realidade. Parâmetros como velocidade, massa, atrito e deteção de colisões são simulados por motores de física. Estes funcionam em tempo real e pretendem representar sistemas físicos com alta precisão. Trata-se de uma função crucial de um simulador de robótica.
• Manipulação de Malha: A malha é dada por um conjunto de vértices, arestas e superfícies que definem a forma de um objeto. É desta forma que se representam os vários objetos, incluindo robôs, num simulador de robótica. Em alguns simuladores, a malha pode ser alterada e manipulada de diferentes formas, possibilitando a construção de novos objetos no ambiente de simulação.
• Outros formatos: Esta caraterística permite a extração de informação do simulador de robótica noutros vários formatos, sendo os mais comuns, ficheiros de vídeo, de texto, imagens, entre outros mais específicos. Desta forma é possível extrair da simulação o tipo de informação apropriada para várias finalidades. Esta caraterística permite também a importação de modelos para o ambiente de simulação.
• Bibliotecas: Existem muitos tipos de robôs, assim como fabricantes dos mesmos no mercado. Desta forma, os simuladores devem ter forma de criar e alterar, ou até possuir bibliotecas pré-definidas com vários tipos de robôs, assim como os diferentes modelos produzidos pelos respetivos fabricantes. Dentro destas bibliotecas é também possível encontrar seleções de outros tipos de componentes como conveyors, ferramentas e controladores, que permitem facilitar a construção e interação dos robôs com ambiente de simulação.
Estas caraterísticas variam consoante o simulador de robótica. Existem inúmeras soluções de simulação de robótica, de entre as principais encontram-se o Gazebo, o Unity e o V-REP. Também existem simuladores produzidos pelos fabricantes dos próprios robôs como é o caso RobotStudio, simulador robótico da ABB. Cada simulador tem as suas caraterísticas que se destinam a servir diferentes demografias.
2.4 Apresentação de Simuladores de Robótica
Nesta secção serão apresentados alguns simuladores de robótica no contexto da simulação para desenvolvimento em robótica, como o Gazebo e o Unity, assim como simuladores para programação offline, o V-REP e o RobotStudio – ABB.
2.4.1 Gazebo
O Gazebo, Figura 2-1, é um simulador maioritariamente utilizado em ambiente de investigação. Tem acesso a vários motores de física como, ODE, Bullet, Simbody e DART, apresenta gráficos 3D com capacidades de “renderização” provenientes do motor gráfico OGRE, integração de vários tipos de sensores indutivos e capacitivos e câmaras 2D e 3D (Howard, 2002, Coumans, 2013, Sherman, 2012, Smith, 2001, OGRE, 2005, DART, 2019).
O Gazebo possui ainda uma interface de programação de aplicações que permitem controlar robôs, sensores e ambiente de simulação utilizando outros programas, como o ROS.
2.4.2 Unity
O Unity é um motor de jogo que pode ser adaptado para simulação robótica. Este está equipado com os motores de física Nvidia Physics e Havok que podem ser utilizados em simultâneo graças à partilha do mesmo protocolo de informação pelos dois motores, o DOTS
framework. Devido à variedade de interfaces de programação de aplicações disponíveis,
Direct3D no Windows, OpenGL ES em Linux e MacOS, permite aos utilizadores testar os programas de várias plataformas (Unity, 2005).
Neste simulador é possível construir soluções mais específicas com alguma facilidade. O ROS#, Figura 2-2, é um exemplo de um conjunto de bibliotecas e ferramentas em linguagem C# que permite a comunicação com ROS através de aplicações .NET e utiliza o Unity para criação de simulações. Desta forma é possível criar classes em C# que possibilitem a comunicação com o Unity, a partir de qualquer tipo de tópico ROS (Bischoff, 2017).
O V-REP, Figura 2-3, é um simulador que permite o controlo de robôs através de seis tipos de programação, sendo todos mutuamente compatíveis na simulação. Esta possibilidade deve-se à interface de programação de aplicações que o V-REP possui e que permite a integração de tópicos ROS e BlueZero, criação de APIs para cliente remoto, Plugins, entre outras formas de programação. Uma vez que o V-REP permite testar programas criados em plataformas diferentes, torna-se assim numa solução bastante versátil. Para além disso, este simulador garante o acesso a vários motores de física como o Bullet, ODE, Vortex e Newton e possibilita a deteção de colisões, cálculo de distâncias, simulação com sensores de proximidade e sistemas e visão (Ferri, 2018, Jerez, 2011, V-REP, 2013, Vortex, 2018).
2.4.4 RobotStudio – ABB
O RobotStudio, Figura 2-4, trata-se de um simulador robótico desenvolvido pela ABB que permite a representação de linhas de produção em ambiente virtual para a programação
offline de robôs. Desta forma a programação dos robôs pode ser feita em computador sem a
necessidade de parar a linha de produção. Este simulador tem a particularidade de ter sido construído no VirtualController da ABB, sendo este uma cópia exata do controlador real dos robôs ABB. Esta caraterística permite simulações bastante realistas, a possibilidade de utilização dos programas realizados em simulação nos robôs reais sem qualquer alteração e a implementação de novos programas robóticos de forma mais eficiente e com menos paragens na produção.
O Visual Components destaca-se de entre os simuladores porque combina algumas características dos simuladores tradicionais, nomeadamente a facilidade de utilização por utilizadores com poucas competências de programação (graças à biblioteca “Works”, explicada na Secção 3.2, e à elevada compatibilidade com controladores reais, com as características dos simuladores de nova geração, nomeadamente devido a utilização do motor de física e às capacidades de expansão, devido à existência de bibliotecas de programação nas linguagens
Python e C#.
O Visual Components apresenta uma grande diversidade de componentes, como robôs, AGVs, controladores, conveyours, máquinas, ferramentas, etc. Para além da variedade de componentes, as bibliotecas do Visual Components são constituídas por vários fabricantes. Entre eles é possível encontrar a ABB, Epson, Fanuc, Grudel, Hyundai, KUKA, Omron, etc. Tal diversidade permite ao Visual Components simular diversos ambientes industriais e integrar máquinas de diferentes fabricantes no ambiente de simulação, aumentando o realismo da simulação.
Apresenta também aplicações como o “Python API” que permite a programação de componentes em Python. Este API dispõe de uma vasta biblioteca de tarefas compatíveis para todo o tipo de robôs presente no Visual Components. Como o objetivo da dissertação é modelar robôs móveis, as bibliotecas necessárias para a programação em Python são “vcSimVehicle”, que garante que o objeto tem um comportamento do tipo veículo, e “vcVector”, necessário para a criação das trajetórias a executar pelo robô. Outra aplicação que pode ser encontrada é a “.NET API” que permite a introdução de plugins .NET através do Visual Studio. Possibilitando a subscrição de mensagens, adicionar componentes, tratar de eventos e ações, o que será útil no âmbito desta dissertação. O Visual Components será apresentado com mais detalhe no Capítulo 3.
3 Visual Components
O Visual Components é um programa de simulação cujo principal objetivo é tornar o uso desta tecnologia acessível a todo o tipo de organizações industriais. A sua interface é fácil e familiar, apresentada na Figura 3-1. As funções do programa estão organizadas por separadores e apresenta também painéis cuja informação altera consoante o separador selecionado.
Figura 3-1 - Interface do Visual Components
A Figura 3-3 mostra o painel que se encontra do lado esquerdo da interface. A informação apresentada neste painel depende do separador selecionado. Este painel, encontra-se apenas nos encontra-separadores “Home”, “Modeling” e “Program”.
Figura 3-3 - Painel apresentado do lado esquerdo da interface: a) Separador “Home”; b) Separador “Modeling”; c) Separador “Program”
Este painel revela informação bastante importante para a criação de simulações no Visual Components. Começando pelo painel do separador “Home”, este designa-se “e-Catalog” e é aqui que se encontram as bibliotecas de componentes disponíveis para simulação. Estas bibliotecas estão separadas por tipo de componente, designadamente:
• Robots; • AGV; • Controllers; • Conveyors;
• Products and Components; • Machines;
E por fabricante, entre outros: • ABB; • Epson; • Fanuc; • Gudel; • Hyundai; • KUKA; • Omron; • Robotiq;
Também é possível encontrar a biblioteca “My Models” que apresenta componentes criados pelo utilizador no Visual Components, assim como componentes importados de outros programas cujo formato é compatível com simulador. Outras bibliotecas como “Currently Open”, “Recent Models”, “Most Used” e “Public Models” também podem ser encontradas neste painel.
O painel do separador “Modeling” designa-se por “Component Graph”. Neste painel encontram-se todas as informações sobre o componente como comportamentos (“Behaviours”), propriedades (“Properties”), etc. Através deste painel é possível caraterizar os comportamentos do elemento a modelar e alterar as suas propriedades geométricas e geográficas, relativamente ao referencial do ambiente de simulação (“World”), o que será útil para a simulação de robôs móveis como será mostrado na Secção 3.3. Através deste painel é ainda possível perceber o tipo de comportamento realizado por um componente na simulação, a relação que este tem com outros componentes e quais as suas propriedades e caraterísticas.
O painel do separador “Program” designa-se por “Program Editor”. Neste painel encontram-se os programas relativos ao componente. É neste painel que se programam robôs de forma tradicional, através da seleção dos pontos importantes da trajetória a ser executada pelo robô e da caraterização do tipo de movimento que se pretende que ele execute.
3.1 Biblioteca Works
A biblioteca “Works” pode ser encontrada no “eCatalog” e apresenta componentes que, quando utilizados, facilitam a criação de uma simulação. Estes componentes ajudam a simular processos simples e complexos sem recorrer a programação. Um processo contém tarefas que podem ser independentes ou requererem a utilização de recursos como máquinas, inputs e outputs. Os componentes desta biblioteca ajudam a interligar os componentes nas suas tarefas de forma a que estas sejam satisfeitas da forma pretendida.
Um dos componentes mais importantes desta biblioteca é o “Works Process” que é usado para a criação e execução de tarefas durante uma simulação. Para a execução de tais tarefas é
“Works Process”. Estas podem ser encontradas nas propriedades do componente, destacando-se as principais:
• Create: Permite a criação de uma lista de componentes, no componente “Works Process”, que se encontrem no ambiente de simulação.
• Create Pattern: Permite a criação de um padrão de componentes que se encontrem no ambiente de simulação.
• Transport In: Permite a transferência de componentes para o componente “Works Process”. Esta tarefa é bastante útil quando se pretende mover componentes através de um conveyor.
• Transport Out: Permite a transferência de componentes para fora do componente “Works Process”.
Feed: Permite identificar o componente “Works Process” responsável pelo início da
tarefa do robô ou humano responsável pelo transporte do componente em causa. Tal tarefa será destinada a uma fonte, robô ou humano, através de um nome que identifica a mesma (“TaskName”), este nome deve ser colocado nas propriedades da fonte que realizará a tarefa.
• Need: Permite identificar o componente “Works Process” ao qual se destinam os componentes a ser transportados pela tarefa “Feed”. Desta forma a fonte sabe qual destino do componente ou lista de componentes a transportar. A associação entre estas duas propriedades, “Feed” e “Need”, e o componente ao qual se destinam é feita pelo “Works Task Controller”.
• Need Pattern: Permite a colocação da lista de componentes conforme um padrão. Esta tarefa pode ser útil para a colocação de componentes numa palete, por exemplo.
3.1.1 Exemplo de Simulação
Nesta secção será apresentada uma simulação assim como a explicação dos passos importantes para o desenvolvimento da mesma de forma a ilustrar a simplicidade de simular com a biblioteca “Works” no Visual Components.
Figura 3-4 - Layout da Simulação Exemplo
Legenda da Figura 3-4:
1. Works TaskControl – Controlador responsável pela gestão de tarefas no ambiente de simulação;
2. Cylinder – Componente a transportar, neste caso um cilindro; 3. Works Process 1 – Componente ao qual se atribuem tarefas; 4. Conveyour 1 – Tapete transportador;
5. Works Process 2 – Componente ao qual se atribuem tarefas;
6. Works Robot Controller – Componente responsável pelo controlo do robô; 7. Generic Robot – Robô genérico antropomórfico do Visual Components; 8. Works Process 3 – Componente a qual se atribuem tarefas;
9. Conveyour 2 – Tapete transportador;
10. Works Process 4 – Componente ao qual se atribuem tarefas.
A simulação consiste no transporte de um cilindro, primeiramente por um tapete transportador ou conveyor e seguidamente por um robô antropomórfico.
O primeiro passo é a criação de um componente “Works TaskControl”, Figura 3-5, visto ser este o responsável pela atribuição das tarefas entre os componentes “Works Process”.
Figura 3-5 - Criação de componente Works TaskControl no ambiente de simulação
A primeira etapa da simulação consiste no transporte de um objeto, neste caso um cilindro, num tapete transportador ou conveyor. Para tal é necessário criar um conveyor , um cilindro e dois componentes “Works Process”, um para cada extremidade do conveyor, Figura 3-6.
O componente “Works Process 1” é responsável pela criação de cilindros dentro do mesmo (“Create”, e habilitar o seu transporte para fora deste (“Transport Out”). O componente “Works Process 2” é responsável por receber o cilindro no final do curso do “Conveyor 1” (“Transport In”), na Figura 3-7 estão representadas as tarefas relativas a esta etapa.
Figura 3-7 - a) Primeira tarefa do componente “Works Process 1”; b) Segunda tarefa do componente “Works Process 1”; c) Primeira tarefa do componente “Works Process 2”
De seguida, pretende-se criar um robô que faça o transporte de cilindros do componente “Works Process 2” para o “Works Process 3”. Para isso criar-se um componente “Works Robot Controller” e um robô, neste caso um robô antropomórfico genérico, no ambiente de simulação e atribui-se a tarefa “Feed” ao componente “Works Process 2”, assim como a tarefa “Need” ao componente “Works Process 3” para que a tarefa seja concluída neste componente, Figura 3-8.
Figura 3-8 - a) Terceira tarefa do componente “Works Process 2”; b) Registo da tarefa na “Tasklist” do componente “Works Robot Controller”; c) Atribuição da tarefa “Need” ao componente “Works Process 3”
Para concluir o processo, atribui-se a tarefa “Transport In” ao “Works Process 4” e a tarefa “Transport Out” ao “Works Process 3”. Assim quando o cilindro chega ao “Works Process 3” é transportado pelo “Conveyor 2” até ao “Works Process 4”.
Ao executar a simulação é possível ver que em primeira instância o cilindro é criado no componente “Works Process 1”, depois transportado pelo “Conveyor 1” até ao componente “Works Process 2”. Nesta fase o cilindro é recolhido pelo robô que o transporta até ao componente “Works Process 3”. Depois de colocado neste componente, o cilindro é
suficiente para casos mais complexos ou para tarefas mais exigentes. É possível alterar o tipo de movimento executado pelo robô nas propriedades do mesmo, mas as opções apresentadas são limitadas. Para trajetórias mais específicas torna-se necessário recorrer à programação do robô no separador “Program” ou através do “Python Script”, que será explicado de seguida.
3.2 Python API
O “Python API” é uma aplicação presente no Visual Components que permite a programação de componentes utilizando a linguagem de programação Python. Está equipada com várias bibliotecas de comandos que podem ser executados pelos componentes, dependendo do que se pretende simular. Como o objetivo desta dissertação é a simulação de robôs móveis, as bibliotecas necessárias para o comportamento a utilizar são a “vcSimVehicle” e a “vcVector”.
3.2.1 vcSimVehicle
Esta biblioteca apresenta os comandos que dizem respeito ao controlo de veículos no Visual Components na linguagem Python. Para se poder utilizar esta biblioteca é necessário que o componente robô móvel possua um comportamento “Vehicle”, Figura 3-9.
Figura 3-9 - Atribuição do Comportamento "Vehicle" a um componente
Para se utilizar o “Python API” é necessário atribuir outro comportamento ao componente, este denomina-se “Python Script” e permite programar a simulação em Python, Figura 3-10.
Figura 3-10 - Atribuição do comportamento "Python Script" a um componente
Depois da atribuição destes comportamentos ao componente que será o robô móvel, é possível abrir o “Python Script” criado no painel do separador “Modeling” onde se apresentam os comportamentos (“Behaviours”) atribuídos ao componente, Figura 3-11.
Figura 3-12 - Confirmação do comportamento "Vehicle" pertencente à biblioteca “vcSimVehicle” do “Python API”
Um objeto “vcSimVehicle” está localizado na raiz do componente. Para que o componente se consiga mover é necessário definir as caraterísticas de velocidade, aceleração e desaceleração do veículo. Depois de definir estes parâmetros, o objeto “vcSimVehicle” irá calcular automaticamente o movimento e a orientação do componente para que este chegue a um determinado destino. No Anexo A encontram-se as propriedades desta biblioteca bem como os métodos para a sua utilização.
3.3 Robôs Móveis em Visual Components.
Um robô móvel é projetado para se deslocar dentro de um determinado espaço de trabalho onde realiza variadas tarefas. Por exemplo, pode ser utilizado para deslocar componentes entre estações de trabalho, potenciando a concentração dos operários nas tarefas em casa estação e não no transporte de componentes entre as mesmas. Como se tratam de robôs móveis, não ocupam um espaço permanente no espaço de trabalho, o que os torna flexíveis na medida em que podem ser utilizados apenas quando e onde necessário.
3.3.1 Simulação de Robôs Móveis com a biblioteca Works
O Visual Components possibilita a simulação de robôs móveis recorrendo à utilização da biblioteca “Works”, sendo que é necessário obter a versão 4.1 do programa ou superior para o efeito. Como demostrado na Secção 3.1, a biblioteca “Works” possibilita a criação de simulações de forma fácil e intuitiva, sendo apenas necessário utilizar alguns componentes principais desta biblioteca.
No caso dos robôs móveis, este tipo de simulação torna-se extremamente útil no que diz respeito ao teste da eficiência de cada robô nas suas tarefas, perceber quantos robôs serão necessários, gerir os seus tempos de trabalho e de repouso, e prevenir possíveis colisões entre robôs móveis.
Nesta secção serão ainda referidas as principais vantagens da utilização deste tipo de simulação, sendo estas as seguintes:
• Definição de Rotas;
• Acoplamento de braço robótico a um robô móvel; • Monitorização da utilização de robôs móveis.
Definição de Rotas
A definição de rotas para robôs móveis através da utilização desta biblioteca é realizada com a criação da necessidade de transportar algo de um componente “Works Process” para outro, como se tratasse de um robô antropomórfico, com a utilização das tarefas “Need” e “Feed” como abordado na Secção 3.1.1. Para o robô móvel realizar uma trajetória é necessário colocar no ambiente de simulação um componente “Works Resource Pathfinder”, Figura 3-13. Este é responsável pela atribuição automática das trajetórias dos robôs móveis que estiverem presentes no ambiente de simulação.
Figura 3-13 - Componente “Works Resource Pathfinder”
O componente “Works Pathway Area” define a área de trabalho do robô móvel na qual são realizadas as suas trajetórias, Figura 3-14. Este componente apresenta uma grelha sobre a qual é criada a trajetória do robô móvel. A dimensão de cada espaço desta grelha pode ser alterado na propriedade “GridSize” que se encontra nas propriedades deste componente. Quanto menor for este valor, maior será a resolução da grelha e maior será o número de trajetórias possíveis para o robô móvel.
Figura 3-14 - Componente “Works Pathway Area”
Na Figura 3-15 encontra-se um exemplo da simulação de um robô móvel através da biblioteca Works do Visua Components. Nesta simulação é possível ver a trajetória atribuída pelo componente “Works Resource Pathfinder” ao robô móvel dentro do componente “Works Pathway Area”.
Figura 3-15 - Exemplo da simulação de robôs móveis com a biblioteca “Works”
Acoplamento de braço robótico a um robô móvel
No Visual Components é possível acoplar braços robóticos a um robô móvel. Desta forma, é possível movimentar braços robóticos no espaço de trabalho. Esta capacidade torna-se interessante quando torna-se pretende ter maior flexibilidade na alteração do número de robôs que
estão numa determinada linha de produção, a sua posição, assim como para melhorar a gestão de produção de forma a obter os melhores resultados possíveis com os robôs que a fábrica possui.
O acoplamento de um braço robótico a um robô móvel é muito simples, basta que este esteja no ambiente de simulação e utilizando o comando “Snap” arrastar o braço para a parte superior do robô, como mostra a Figura 3-16.
Figura 3-16 - Acoplamento de um braço robótico num robô móvel
Depois, para que o braço robótico se mova com o robô móvel, com o braço selecionado e utilizando o comando “Attach”, seleciona-se o robô móvel. Estes dois componentes estão agora ligados e funcionam como um só componente no ambiente de simulação. Desta forma, a tarefa que tinha sido anteriormente atribuída ao robô móvel é também agora atribuída ao braço robótico. Quando se inicia a simulação é possível ver que é o braço robótico que retira o componente a transportar do componente “Works Process” no início da trajetória, Figura 3-17, e que o coloca no componente “Works Process” no fim da mesma, Figura 3-18.
Figura 3-17 - Simulação de braço robótico a retirar o componente a transportar
Figura 3-18 - Simulação de braço robótico a colocar componente transportado
Monitorização da utilização de robôs móveis
Para ter maior controlo sobre o trabalho realizado por cada robô móvel, é possível monitorizar os respetivos tempos produtivos durante a simulação, assim como os tempos de repouso e eventuais colisões com outros robôs móveis. Esta capacidade permite encontrar possíveis erros na programação, ter maior sensibilidade sobre os tempos produtivos de cada robô móvel, perceber quais as diferenças produtivas ao adicionar ou retirar estes robôs e ainda perceber como é que a alteração das trajetórias dos robôs móveis podem afetar a produção. Para fazer esta análise utiliza-se o comando “Statistics” presente no separador “Home” que abrirá uma janela para escolher o layout do gráfico a ser utilizado, Figura 3-19.
Figura 3-19 - Escolha do layout do gráfico de monitorização
Depois de escolhido o layout, necessita-se escolher a informação que se pretende obter, neste caso o estado do componente, ou “Component State”, como apresentado na Figura 3-20.
Figura 3-20 - Escolha do tipo de informação que se pretende obter
Por fim aparecerá um gráfico que apresenta todos os tipos de informação possíveis de obter do componente, neste caso o robô móvel, durante a simulação, Figura 3-21.
Figura 3-21 - Gráfico gerado com os tipos de informação possíveis de obter durante a simulação
Um exemplo útil para a utilização desta informação está apresentado na Figura 3-22, onde se encontram dois robôs móveis numa simulação e dois gráficos, cada um correspondente à atividade de um dos robôs. É importante referir que a informação apresentada nos gráficos é atualizada a cada momento da simulação, podendo o valor temporal ser definido na janela “Interval” do separador “Home”, de acordo com o interesse do exercício.
3.3.2 Simulação de Robôs Móveis com o Python API
Neste exemplo pretende-se demonstrar como se programa um robô móvel com o “Python API” do Visual Components. O programa terá como objetivo a realização de uma trajetória por parte do robô móvel através do comportamento (“Behaviour”) “Vehicle”.
Primeiramente é necessário definir o componente e aplicação no “Python Script” assim como o comportamento (“Behaviour”) “Vehicle”. Para além disso é importante utilizar o comando “clearMove” para limpar quaisquer rotinas executadas anteriormente pelo robô móvel, Figura 3-23.
Figura 3-23 - Definição do componente, aplicação e comportamento do veículo no “Python Script”
De seguida, definem-se os comandos velocidade (“MaxSpeed”), aceleração (“Acceleration”) e desaceleração (“Deceleration”), Figura 3-24.
Figura 3-24 - Definição de aceleração, desaceleração e velocidade máxima do veículo no “Python Script”
Para a definição da trajetória a realizar é necessário utilizar a biblioteca “vcVector”, uma vez que os pontos devem ser definidos como vetores para serem reconhecidos pelo veículo. As
Figura 3-25 - Definição dos pontos utilizados na trajetória no “Python Script”
Para concluir a definição da rotina, é necessário definir a trajetória. Pretende-se que o robô móvel passe pelo ponto “v1”, “v2” e, por fim, “v3”. Para tal utiliza-se um ciclo for, mostrado na Figura 3-26.
Figura 3-26 - Definição da trajetória executada pelo veículo no “Python Script”
Depois de compilado, o código presente na Figura 3-26 comanda o robô realizar uma trajetória definida pelos pontos “v1”, “v2” e “v3” com aceleração, desaceleração e velocidade máxima definidas. Esta rotina pode ser observada quando se dá início ao exercício no ambiente de simulação.
4 ROS
O ROS é uma plataforma de programação robótica que consiste num conjunto de ferramentas e bibliotecas utilizadas na criação de comportamentos robóticos complexos e robustos (ROS, 2007).
O surgimento desta plataforma deve-se à difícil e morosa tarefa de programar comportamentos robóticos genéricos e robustos. Da perspetiva do robô, problemas que possam ser triviais para um humano têm imensas variantes, entre sub-tarefas, ações e ambientes que têm que ser executadas de uma determinada forma para cumprir a tarefa a realizar. Lidar com estas variantes é tão complexo que, muito dificilmente, uma pessoa, laboratório ou instituição pode esperar conseguir fazê-lo sozinho.
Desta forma, o ROS criou uma plataforma colaborativa de programas robóticos onde todos os seus utilizadores podem acrescentar os seus programas e utilizar os de outros utilizadores. Por exemplo, um laboratório pode ter desenvolvido programas de mapeamento de ambientes indoor, e outro grupo pode utilizar esse mapeamento para a orientação e navegação de um robô num determinado ambiente.
No âmbito desta dissertação, utilizar-se-á o ROS para a criação de mensagens que serão recebidas pelo Visual Components através de uma ligação cliente/servidor realizada por
Websockets pela plataforma de comunicação RosBridge. 4.1 RosBridge
O RosBridge é um package que permite a interação com o ROS através do “JSON API” que este proporciona. Está equipado com um servidor Websocket de forma a que programas externos possam interagir com tópicos ROS (Mace, 2014).
O package possui um protocolo de comunicação que necessita ser cumprido para a sua implementação e para que disponha de uma plataforma de comunicação por Websocket.
4.1.1 Protocolo
O protocolo define a especificação do envio de comandos JSON para ROS, estando relacionada com a linguagem de programação e o transporte. A ideia é que qualquer linguagem ou transporte que consegue enviar mensagens JSON pode interagir com o ROS através do protocolo RosBridge. Este protocolo está relacionado com a subscrição e publicação de tópicos, chamadas de serviço, procura e configuração de parâmetros, envio de mensagens, etc (Crockford, 2002).
O protocolo RosBridge define um número de operações diferentes: • Compressão/ Transformação de mensagens:
o fragment – parte de mensagem fragmentada;
o png – parte de mensagem PNG compressa e fragmentada; • Estado de mensagens RosBridge;
o set_status_level – pedido para reportar o estado de uma mensagem RosBridge;
o status – estado de uma mensagem; • Autenticação:
o auth – uma série de credenciais utilizadas para autenticar a conexão com o cliente;
• Operações ROS:
o advertise – comunicar que um tópico está a ser publicado; o unadvertise – encerrar a publicação de um tópico;
o publish – publicar uma mensagem ROS;
o subscribe – pedido para subscrever a um tópico;
o unsubscribe – pedido para deixar de subscrever a um tópico; o cal_service – chamada de serviço;
o service_response – resposta a um serviço;
No âmbito desta dissertação, é pretendido que o cliente subscreva a um tópico ROS. Portanto utilizar-se-á a operação “subscribe” que será apresentada com mais detalhe na secção seguinte.
4.1.2 Subscribe
Este comando permite que um cliente subscreva a um determinado tópico ROS. Para a subscrição ser concluída com sucesso, é necessário que o cliente caraterize alguns fatores:
• type – o tipo de tópico a que se pretende subscrever; • topic – o nome do tópico a que se pretende subscrever;
• throttle_rate – o tempo de espera mínimo (em ms) entre envio de mensagens. O valor padrão é 0.
• queue_lenght – o tamanho da fila de espera no buffer de mensagens criado caso haja throttle_rate. O valor padrão é 1.
• id – se especificado, esta subscrição específica pode encerrar apenas com a referência do ID.
• fragment_size – o tamanho máximo que uma mensagem pode ter antes desta ser fragmentada.
• compression – especifica o tipo de compressão de mensagens. Os valores válidos são “none” e “png”.
5 Comunicação ROS – Visual Components
A solução do problema proposto passa por criar a comunicação entre o ROS e o Visual Components. Para tal recorreu-se a uma comunicação cliente-servidor por Websocket onde o servidor é o ROS, mais especificamente o RosBridge. Para o cliente, foram estudadas duas situações:
• Python: Como o Visual Components possui uma “Python API”, criou-se um cliente através do “Python Script” existente no Visual Components, Figura 5-1.
Figura 5-1 - Diagrama de Comunicação entre ROS e Visual Components recorrendo ao “Python API”
• Visual Studio (C#): Como o Visual Components possui uma “.NET API”, criou-se um cliente em C# no Visual Studio, este cliente trata-se de um Plugin para o Visual Components que pode ser acedido diretamente no programa, Figura 5-2.
Figura 5-2 - Diagrama de Comunicação entre ROS e Visual Components recorrendo ao “.NET API”
5.1 Servidor RosBridge
O servidor foi criado numa Virtual Machine com o sistema operativo Ubuntu onde foi instalada a plataforma ROS assim como o RosBridge. Depois procedeu-se à criação de um
package com um tópico ROS que envie mensagens através do RosBridge, as instruções para a
ligação de um servidor RosBridge estão apresentadas no Anexo B.
5.1.1 Catkin_ws
Figura 5-3 - Localização do “catkin_ws”
Dentro desta pasta encontram-se outras três pastas com os nomes “build”, “devel” e “src”. O package criado, ao qual se deu o nome de “socket_pub_gus”, deve ser colocado na pasta “src”. Neste package encontra-se o tópico ROS responsável pelo envio de mensagens por Rosbridge e está apresentado na Secção 5.1.2.
5.1.2 Socket_pub_gus
O package “socket_pub_gus” é composto por duas pastas com os nomes “launch” e “src”. Na pasta “src” encontra-se o programa responsável pelo envio da mensagem que está escrito na linguagem C++, Figura 5-4. Como se pode ver, trata-se de um tópico que envia a mensagem “Hello World!” repetidamente até que o programa seja interrompido.
Figura 5-4 - Programa “sub” do package “socket_pub_gus”
Na pasta “launch” encontra-se o programa responsável pela ligação do servidor RosBridge à porta 1236 do “localhost”, isto é, do computador que está a ser utilizado. Quando ligado, este programa estabelece a ligação do servidor RosBridge.
Figura 5-5 - Programa “launch” do package “socket_pub_gus”
5.2 Cliente Python
A primeira solução para realizar a comunicação foi feita com o Python. Este necessita de uma biblioteca própria para comunicar através de Websockets que, neste caso, foi a “websocket_client” (Websocket - Client, 2019).
Primeiramente, procedeu-se à criação de um programa em Python que se encontra na Figura 5-6. Neste programa encontram-se declaradas as bibliotecas que são necessárias para realizar a comunicação. Chama-se a atenção para a variável “concat” que se trata da mensagem de subscrição ao tópico “sub” sob o protocolo de comunicação do RosBridge abordado na Secção 4.1.2.
A criação do cliente é feita através do comando “create_connection (url)”, cujo URL é “ws://127.0.0.1:1236”. Esta porta foi criada na VirtualBox como porta de comunicação sob o protocolo TCP, Figura 5-7.
Figura 5-7 - Criação da porta de comunicação entre com a VirtualBox
Quando compilado, o programa subscreve o tópico “sub” do ROS e devolve a sua mensagem. O painel de resultado deste programa utilizando o Python IDLE está representado na Figura 5-8. A mensagem recebida pode ser dividida em três campos, o primeiro é a confirmação da subscrição ao tópico (sub: “topic” “/sub”), o segundo é a mensagem enviada para o cliente: (“msg”: “data”: “Hello World!”) e o terceiro campo descreve a operação feita pelo tópico que foi publicado: (“op”: “publish”).
Figura 5-8 - Resultado do programa de comunicação por Websocket em Python
5.2.1 Comunicação em Python no Visual Components
A última etapa passa por testar este programa no Visual Components. Para isso é necessário criar um objeto no ambiente de simulação com um comportamento (“Behaviour”) do tipo “Python Script”. E por fim, colocar o programa de comunicação por Websocket em
Python, dentro desse comportamento, como apresentado na Figura 5-6. O resultado pode ser
Figura 5-9 - Programa de comunicação por Websocket em Python no “Python Script” do Visual Components
Antes de compilar o programa, é necessário importar a biblioteca “websocket” para a pasta Visual Components 4.0 > Python > lib > site-packages, como representado na Figura 5-10.
O resultado da compilação do programa no Visual Components está representado na Figura 5-11.
Figura 5-11 - Programa de comunicação por Websocket em Python quando compilado no Visual Components
Como se pode observar, a mensagem não foi recebida no Visual Components. Tal não implica a impossibilidade da comunicação através do “Python API”, apenas não foi possível realizar esta comunicação no tempo proposto para a realização deste trabalho.
5.3 Cliente C#
Para estabelecer a comunicação utilizando uma aplicação .NET criou-se uma “Console Application” no Visual Studio. O programa realizado para a comunicação com o tópico “sub” em C#, está representado na Figura 5-12. Como a comunicação por Websockets se carateriza por ser bidirecional, para realizar a comunicação em C# é necessário criar uma tarefa assíncrona onde se começa por criar um cliente Websocket, linha 13. A conexão ao servidor Rosbridge, através do comando “ConnectAsync” pertencente à biblioteca “System.Net.Websockets”, com o URL “ws://127.0.0.1:1236”, linhas 15 e 16. Depois de conectar ao servidor, o programa subscreve ao tópico “sub” do ROS. Para tal começa-se por transformar a string correspondente à subscrição ao tópico segundo o protocolo RosBridge, linha 18, num array de bytes, linha 19. Procedendo-se por fim ao envio ao da mensagem para o ROS, linha 20. Depois de subscrever ao tópico, pretende-se receber a mensagem do mesmo, para isso cria-se um array de 1024 bytes, linha 22, e recolhe-se a mensagem para dentro deste array através do comando “ReceiveAsync”, linha 23. Por fim, converte-se a mensagem numa string, linha 25, e escreve-se o resultado na consola, linha 26.
