% ------------------------------------------------------------- % | Template de tese da UA, em língua portuguesa | % | Lista completa de opções e comandos em uaThesis.sty | % ------------------------------------------------------------- % | Fevereiro, 2011 | % | Universidade de Aveiro | % | Criado por T. Oliveira e Silva | % | Modificado/adaptado por F. Teixeira-Dias & M. Paulino | % ------------------------------------------------------------- \documentclass[11pt,twoside,a4paper,openright]{report} % Estilo relatório % openright: página inicial de cada capítulo sempre ímpar % ------------------------------------------------------------- % Preâmbulo do documento - pacotes % ------------------------------------------------------------- % Package para teses UA %\usepackage[usecolor,newLogo,DEM]{uaThesis} % provisório \usepackage[usecolor,newLogo,DEM,final]{uaThesis} % final % \usepackage{amssymb} % Símbolos da American Mathematical Society %\usepackage[citebordercolor={1 1 1},linkbordercolor={1 1 1}]{hyperref} % Links activos no pdf % Opção citebordercolor={0.9 0.9 0.9} para cor do border % Opção linkbordercolor={0.9 0.9 0.9} para cor do border \usepackage{textcomp} % Símbolos e caracteres especiais %\usepackage{indentfirst} % Indentação do primeiro parágrafo de cada secção \usepackage{fancyhdr} % Utilização de fancy headings %\usepackage[square,sort&compress]{natbib} % Ordenação e gestão de referências bibliográficas \usepackage{epsfig} % Permite utilização de figuras em formato EPS %\usepackage{subfig} % Ambiente para gestão de subfiguras \usepackage{multirow} % Agrupamento de linhas em tabelas \usepackage{layout} %\usepackage{citesort} \usepackage{graphicx} \graphicspath{ {Imagens/} } \usepackage{blindtext} \usepackage{subfig} \usepackage{booktabs} % To thicken table lines \renewcommand\PackageError[3]{[[[ERROR FOR PACKAGE #1]]]} \usepackage[backend=bibtex, sorting=none]{biblatex} \addbibresource{bib/myBib} %diagranas: \usepackage{tikz} \usepackage{graphicx} \usepackage{dirtree} \usepackage{rotating} \usetikzlibrary{trees} \usepackage{scrextend} \usepackage{svg} \usepackage{algorithmic}% http://ctan.org/pkg/algorithms \usepackage{amsmath} \usepackage[linesnumbered,ruled]{algorithm2e} \newenvironment{megaalgorithm}[1][htb] {\renewcommand{\algorithmcfname}{Algoritmo}% Update algorithm name \begin{algorithm}[#1]% }{\end{algorithm}} \usepackage{listings} \usepackage{color} \definecolor{gray}{rgb}{0.4,0.4,0.4} \definecolor{darkblue}{rgb}{0.0,0.0,0.6} \definecolor{cyan}{rgb}{0.0,0.6,0.6} \usepackage{calc} \lstset{ basicstyle=\ttfamily, columns=fullflexible, showstringspaces=false, commentstyle=\color{gray}\upshape } \lstdefinelanguage{XML} { morestring=[b]", morestring=[s]{>}{<}, morecomment=[s]{}, stringstyle=\color{black}, identifierstyle=\color{darkblue}, keywordstyle=\color{cyan}, morekeywords={xmlns,version,type}% list your attributes here } \renewcommand{\lstlistingname}{Listagem} \usetikzlibrary{shapes,arrows,positioning} \usepackage{varwidth} % Define block styles \tikzstyle{decision} = [diamond, draw, fill=blue!20, text width=4.5em, text badly centered, node distance=3cm, inner sep=0pt] \tikzstyle{block} = [rectangle, draw, fill=blue!20, text badly centered, rounded corners, minimum height=4em] \tikzstyle{line} = [draw, -latex'] \tikzstyle{cloud} = [draw, ellipse,fill=red!20, node distance=3cm, minimum height=2em] \usepackage{grafcet} \usepackage{fancyref} % ------------------------------------------------------------- % Preâmbulo do documento - Escrita em língua portuguesa % ------------------------------------------------------------- \usepackage[latin1]{inputenc} % Caracteres acentuados do Português \usepackage[english,portuguese]{babel} % Hifenização e títulos \usepackage[T1]{fontenc} % Codificação das fontes \usepackage{forest} \usepackage{float} \usepackage[acronym]{glossaries} \makeglossaries \newacronym{AGV}{AGV}{\textit{Automated Guided Vehicle}} \newacronym{ROS}{ROS}{\textit{Robot Operating System}} \newacronym{URDF}{URDF}{\textit{Unified Robot Description Format}} \newacronym{IP}{IP}{\textit{Internet Protocol}} \newacronym{PWM}{PWM}{\textit{Pulse-width modulation}} \newacronym{NFS}{NFS}{\textit{Network File System}} \newacronym{IDE}{IDE}{\textit{Integrated Development Environment}} \newacronym{LAN}{LAN}{\textit{Local Area Network}} \newacronym{STL}{STL}{\textit{ Standard Triangle Language}} % ------------------------------------------------------------- % Preâmbulo do documento - Definições da tese % ------------------------------------------------------------- \newcommand{\authorname}{Filipe Aguiar da Silva} % Nome do autor da tese \newcommand{\thesistitle}{Sistema baseado em ROS distribuído para controlo de uma plataforma skid-steering} % Título da tese \newcommand{\thesisyear}{2017} % Ano da tese \newcommand{\thesisdegree}{Mestrado} % Grau \newcommand{\sciarea}{Engenharia Mecânica} % Área científica da tese % ------------------------------------------------------------- % Preâmbulo do documento - Equipa de orientação % ------------------------------------------------------------- \newcommand{\profdoc}{Prof. Doutor} % Grau geral \newcommand{\supervisor}{Vítor Manuel Ferreira dos Santos} % Orientador \newcommand{\supdegree}{Professor Associado} % Grau académico do orientador \newcommand{\supfili}{Departamento de Engenharia Mecânica} % Filiação do orientador \newcommand{\cosupervisor}{Miguel Armando Riem de Oliveira} % Co-orientador \newcommand{\cosupdegree}{Professor Auxiliar Convidado} % Grau académico do co-orientador \newcommand{\cosupfili}{Departamento de Engenharia Mecânica} % Filiação do co-orientador \newcommand{\cosupuni}{Universidade de Aveiro} % Instituição do co-orientador % ------------------------------------------------------------- % Preâmbulo do documento - Membros do júri % ------------------------------------------------------------- \newcommand{\tribpresident}{José Paulo Oliveira Santos} % Presidente do júri \newcommand{\tribpresidentcat}{Professor Auxiliar} % Categoria do presidente do júri \newcommand{\tribi}{Manuel Bernardo Salvador Cunha} % Elemento do júri 1 \newcommand{\tribicat}{Professor Auxiliar} % Categoria do elemento do júri 1 \newcommand{\tribifili}{Universidade de Aveiro (arguente)} % Filiação do elemento do júri 1 % ------------------------------------------------------------- % Preâmbulo do documento - Outros comandos % ------------------------------------------------------------- \newcommand{\dd}{\textrm{d}} % Operador diferencial \newcommand{\ngs}{\sigma} % Sigma minúsculo \newcommand{\nga}{\alpha} % Alfa minúsculo \newcommand{\ngb}{\beta} % Beta minúsculo % ------------------------------------------------------------- % Preâmbulo do documento - Margens e mancha gráfica % ------------------------------------------------------------- \setlength{\textwidth}{147mm} % Largura da mancha gráfica \setlength{\textheight}{225mm} % Altura da mancha gráfica \setlength{\topmargin}{0mm} % Margem de topo (default=1in) \setlength\oddsidemargin{5mm} % Margem direita páginas direitas \setlength\evensidemargin{5mm} % Margem esquerda páginas esquerdas % ------------------------------------------------------------- % Início do documento % ------------------------------------------------------------- \begin{document} % ------------------------------------------------------------- % Definição da capa (com e sem figuras) % ------------------------------------------------------------- \iffalse % \iffalse: capa sem imagem, \iftrue: capa com imagem \TitlePage % Capa da tese com uma imagem % \DRAFT % Escreve "Documento Provisório" na página inicial % \GRID % Desenha grelha rectangular de 3mm \HEADER{\BAR\FIG{\includegraphics{./Imagens/nice.pdf}}} % Imagem para a capa {\thesisyear} \TITLE{\authorname} {\thesistitle} \EndTitlePage \else \TitlePage % Capa da tese sem imagens, com citação % \DRAFT % Escreve "Documento Provisório" na página inicial % \GRID % Desenha grelha rectangular de 3mm \HEADER{\BAR\FIG{\begin{minipage}{100mm} % Largura da caixa da citação (<120mm) {} % Citação 1. Colocar {} para retirar citação \begin{flushright} {} % Citação 2. Colocar {} para retirar citação \end{flushright} \end{minipage}}} {\thesisyear} \TITLE{\authorname} {\thesistitle} \EndTitlePage \fi \titlepage\ \endtitlepage % Página de verso em branco % ------------------------------------------------------------- % Definição da capa interior % ------------------------------------------------------------- \TitlePage % \PGRID % Desenha grelha rectangular de 3mm \HEADER{}{\thesisyear} \TITLE{\authorname} {\thesistitle} \vspace*{15mm} \TEXT{} {Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em \sciarea, realizada sob orientação científica de \supervisor, \supdegree{} do \supfili{} da Universidade de Aveiro e de \cosupervisor, \cosupdegree{} do \cosupfili{} da \cosupuni.} \vspace*{15mm} \vspace*{100mm} \TEXTI{} {Apoio financeiro dos projetos UID/EMS/00481/2013-FCT e CENTRO-01-0145-FEDER-022083} \EndTitlePage \titlepage\ \endtitlepage % Página de verso em branco % ------------------------------------------------------------- % Definição da página do júri da dissertação (PT/EN) % ------------------------------------------------------------- \TitlePage \vspace*{55mm} \TEXT{\textbf{O júri~/~The jury\newline}} {} \TEXT{Presidente~/~President} {\textbf{\profdoc{} \tribpresident}\newline {\small \tribpresidentcat{} da Universidade de Aveiro}} \vspace*{5mm} \TEXT{Vogais~/~Committee} {\textbf{\profdoc{} \tribi}\newline {\small \tribicat{} da \tribifili}} \vspace*{5mm} % \TEXT{} % {\textbf{\profdoc{} \cosupervisor}\newline {\small % \cosupdegree{} da \cosupfili{} (co-orientador)}} % \vspace*{5mm} \TEXT{} {\textbf{\profdoc{} \supervisor}\newline {\small \supdegree{} da Universidade de Aveiro (orientador)}} \EndTitlePage \titlepage\ \endtitlepage % Página de verso em branco % ------------------------------------------------------------- % Definição da página dos agradecimentos % ------------------------------------------------------------- \TitlePage \vspace*{55mm} \TEXT{\textbf{Agradecimentos~/\newline Acknowledgements}} {Gostaria de começar por agradecer a todos os meus colegas de laboratório que me acompanharam durante todo este processo. Ao professor Vítor Santos por toda a ajuda, sugestões e conhecimento transmitido. \\Não podia também deixar de fora a grande família do BEST Aveiro por me terem acolhido, sem eles não era aquilo que sou hoje. \\Aos meus país e irmãos por me terem apoiado durante todo este percurso e nunca terem desistido. \\Por último, a todos os colegas que tive o prazer de conhecer durante estes cinco anos de pura aprendizagem. \\A todos, muitíssimo obrigado. } \EndTitlePage \titlepage\ \endtitlepage % Página de verso em branco % ------------------------------------------------------------- % Definição da página do resumo (PT) % ------------------------------------------------------------- \TitlePage \vspace*{55mm} \TEXT{\textbf{Palavras-chave}} {ROS; Skid-Steering; Gazebo; Sistema distruibuído; Plataforma robótica móvel; Raspberry Pi} \vspace*{5mm} \TEXT{\textbf{Resumo}} {Esta dissertação tem como objetivo a implementação de um sistema de ROS distribuído para o controlo de uma plataforma robótica móvel com uma configuração \textit{skid-steering}. Para o seu desenvolvimento são usados múltiplos microcontroladores de baixo custo, o Raspberry Pi, que interligados em rede permitem a partilha de mensagens ROS e o respetivo controlo da plataforma. A par disto, foram desenvolvidas algumas funcionalidades que permitem melhor facilidade de utilização de todo o sistema, como o controlo remoto. \\É ainda criado um ambiente de simulação para uma plataforma skid-steering que interage com todos os processos desenvolvidos de ROS. \\Por fim, de forma a testar a solução, foi realizada uma aplicação em ambiente virtual que visa a utilização de todas as funcionalidades desenvolvidas. Esta aplicação consiste no seguimento de uma linha usando uma câmara, sendo também possível a intervenção humana no seu controlo, recorrendo ao uso de um comando \textit{joystick}. } \EndTitlePage \titlepage\ \endtitlepage % Página de verso em branco % ------------------------------------------------------------- % Definição da página do resumo (EN) % ------------------------------------------------------------- \TitlePage \vspace*{55mm} \TEXT{\textbf{Keywords}} {ROS; Skid-steering; Gazebo; Distributed system; Mobile Robotic Platform, Raspberry Pi} \vspace*{5mm} \TEXT{\textbf{Abstract}} {This dissertation aims to implement a distributed ROS system to control a mobile robotic platform with a skid-steering configuration. For its development are used multiple low-cost microcontrollers, Raspberry Pi, which networked together allow the sharing of ROS messages and the platform control. Alongside this, some features have been developed that allow better usability of the entire system, such as remote control. It also created a simulation environment for a skid-steering platform that interacts with all the processes developed in ROS. Finally, in order to test the solution, an application in virtual environment is realized that aims at the use of all the functionalities developed. This application consists in a line following application using a camera, being also possible the human intervention in its control, resorting to the use of a joystick command. } \EndTitlePage \titlepage\ \endtitlepage % Página de verso em branco % ------------------------------------------------------------- % Listas e definições iniciais da dissertação % ------------------------------------------------------------- \pagenumbering{roman} % Numeração romana para as primeiras páginas \tableofcontents % Índice da dissertação \listoftables % Lista de tabelas \listoffigures % Lista de figuras %\printglossary[type=\acronymtype, title=Lista de Acrónimos] %\printglossaries \printacronyms[type=\acronymtype, title=Lista de Acrónimos] %\cleardoublepage \titlepage\ \endtitlepage % Página de verso em branco \pagenumbering{arabic} % Numeração árabe para as páginas restantes % ---------------------------------------------------------------- % Definicao de headers e footers % ---------------------------------------------------------------- \pagestyle{fancy} \renewcommand{\chaptermark}[1]{\markboth{\thechapter.#1}{}} % Capítulos em minúsculas \fancyhf{} % Reset aos headers e footers \fancyhead[LE,RO]{\thepage} % Header Left-Even (LE), Right-Odd (RO) \fancyhead[LO]{\leftmark} % Header Left-Odd (LO) \fancyhead[RE]{\leftmark} % Header Right-Even (RE) \fancyfoot[LE]{\authorname} % Footer Left-Even (LE) \fancyfoot[LO]{\authorname} % Footer Left-Odd (LO) \fancyfoot[RE]{\textit{Dissertação de \thesisdegree}} % Footer Right-Even (RE) \fancyfoot[RO]{\textit{Dissertação de \thesisdegree}} % Footer Right-Odd (RO) \renewcommand{\headrulewidth}{0.25pt} % Espessura da linha de header \renewcommand{\footrulewidth}{0.25pt} % Espessura da linha de footer \addtolength{\headheight}{0.5pt} % Espaçamento para a linha % ---------------------------------------------------------------- % Corpo da tese - Parte I - Introdução % ---------------------------------------------------------------- \chapter{Introdução} \label{chap:Introdução} \section{Enquadramento e motivação} O uso de robôs móveis para a execução de tarefas tem vindo a aumentar, sendo diversos os ambientes onde os podemos encontrar. Encontram-se em meio industrial, onde estão presentes os \gls{AGV} desempenhando tarefas como o transporte de mercadoria, ou até em ambiente agrícola onde, segundo o artigo escrito por Peter Feuilherade, a inclusão de tais veículos poderá aumentar a produtividade em cerca de 30\% \cite{farming}. Dada tal importância deste tipo de robôs, a empresa Tarento Robotics \cite{tarento} tem a ambição de desenvolver plataformas móveis para uso em diversas áreas tais como investigação, medicina e agricultura. Tendo como foco a agricultura, a empresa apresenta a plataforma robótica NARDO (figura \ref{fig:nardo}) onde é pretendido que se implemente o controlo da mesma usando uma arquitetura \gls{ROS}, deixando também a possibilidade de adaptar a plataforma a novas funcionalidades, com relativa facilidade. \begin{figure} \centering \includegraphics[width=0.5\textwidth]{nardo.jpg} \caption{Plataforma robótica NARDO \cite{nardo}} \label{fig:nardo} \end{figure} Plataformas com o propósito da apresentada não teriam o mesmo impacto caso não tivessem capacidades de navegação autónoma, sendo uma das características mais desafiantes que os robôs móveis têm. Esta característica requer capacidades de percepção, localização, planeamento de trajetória e controlo de movimento, sendo necessário a utilização de vários sensores e componentes \cite{c1}. No entanto, todas estas capacidades dão origem a uma grande quantidade de dados que necessitam de ser processados de modo a poder-se tomar decisões, surgindo então a procura por soluções de processamento com alto desempenho. %------feedback------% A facilidade com que um sistema se consegue adaptar a novas condições têm cada vez mais relevância. Por exemplo, no caso da plataforma apresentada, será importante a adaptabilidade da mesma na realização de diferentes tarefas sem que seja necessário uma reconfiguração total, tanto a nível de \textit{hardware} como a nível de \textit{software}, tal como a adição de diversas ferramentas para a realização de tarefas relacionadas com a agricultura. Posto isto, é importante encontrar soluções que satisfaçam ambos os critérios mencionados anteriormente. Genericamente, como arquitetura de software, propõe-se o uso de abordagens baseadas em \gls{ROS} que permitam criar um sistema distribuído entre várias máquinas que estejam ligadas em rede, com abstração do hardware utilizado. Por outro lado, será importante o uso de componentes padrão para as unidades computacionais, surgindo assim o uso de Raspberry Pi's como possibilidade. Combinando estas duas soluções, espera-se criar uma uma rede distribuída de unidades computacionais que permite fazer com que cada uma se dedique especificamente ao processamento de um tipo de dados, culminando na realização de uma tarefa final. No final, importa também fazer o teste da solução desenvolvida e para isto propõe-se o controlo da plataforma móvel em ambiente virtual. Para tal demonstração é importante que se proceda à realização de uma aplicação que demonstre várias unidades de processamento a desenvolverem tarefas diferentes. \section{Objetivos} Os objetivos pretendidos com a presente dissertação são os seguintes: \begin{itemize} \item Criação de uma rede de unidades computacionais para a execução de ROS numa abordagem distribuída; \item Instalação do \gls{ROS} e desenvolvimento do software necessário à interligação da plataforma com sistemas periféricos; \item Criação de um ambiente de simulação para uma plataforma skid-steering; \item Criação de uma aplicação de demonstração. \end{itemize} \section{Estado da arte} Seguidamente serão apresentados alguns projetos e plataformas da mesma configuração que aquela em estudo neste trabalho, assim como algumas questões de controlo deste tipo de plataformas. Também são abordados alguns exemplos onde o \gls{ROS} é usado para o controlo de sistemas distribuídos. \subsection{Plataformas \textit{Skid-steering}} Atualmente no mercado existem algumas plataformas com a configuração de \textit{skid-steering}, sendo maioritariamente usadas para operar em ambientes agrícolas, exploração de minas, militar, operações de salvamento, ou em ambientes com solo irregular. Alguns dos exemplos são as plataformas desenvolvidas pela Clearpath \cite{clearpath} sendo criadas essencialmente para ambientes terrestres, como é o caso da plataforma Husky (figura \ref{fig:husky}). Esta plataforma usa uma arquitetura \gls{ROS} podendo ser adquirida com diversos tipos de unidades computacionais como por exemplo minicomputadores como os Intel NUC ou então uma \textit{motherboard} mini ITX. \begin{figure}[H] \centering \includegraphics[width=0.5\textwidth]{husky.jpg} \caption{Plataforma Husky da Clearpath \cite{husky}} \label{fig:husky} \end{figure} \subsubsection{CARLoS} Um outro exemplo é o caso da plataforma móvel robótica Guardian da Robotnik, tendo também uma configuração \emph{skid-steering} é criada especialmente para a utilização em projetos relacionados com segurança, inspeção, e investigação \cite{guardian}.Para o controlo, a plataforma usa uma arquitetura ROS, enquanto que como unidade computacional é usado uma \textit{motherboard} com um processador Intel. Uma aplicação onde esta plataforma foi usada é o projeto CARLoS (Figura \ref{fig:carlos}) onde o objetivo é desenvolver um robô móvel capaz de executar alguns processos de soldadura durante a construção de navios. Para tal é acoplado um manipulador que contém na sua extremidade a ferramenta de soldadura. A plataforma tem então de ter algumas capacidades tais como a navegação autónoma dentro dos blocos do navio \cite{carlos}. \begin{figure}[H] \centering \includegraphics[width=0.6\textwidth]{carlos.jpg} \caption{Robô CARLoS \cite{carlos}} \label{fig:carlos} \end{figure} \subsubsection{VINBOT} Ainda usando uma plataforma da Robotnik, mas com a versão Summit XL na configuração \emph{skid-steering}, foi desenvolvido um robô todo-o-terreno autónomo, denominado por VINBOT (figura \ref{fig:vinbot}), tendo como objetivo realizar a análise do estado de vinhas e avaliar o seu rendimento. Para tal são aplicados um conjunto de sensores capazes de captar e analisar, imagens assim como dados 3D. A recolha dos dados é enviada para os viticultores ajudando assim num aumento significativo da produção de vinho. Todo este sistema opera sobre uma arquitetura \gls{ROS}. \begin{figure}[H] \centering \includegraphics[width=0.4\textwidth]{vinbot.jpg} \caption{Robô VINBOT\cite{vinbot}} \label{fig:vinbot} \end{figure} \subsection{Questões de controlo} O uso de plataformas do tipo \emph{skid-steering} tem tido uma utilização crescente principalmente para terrenos arenosos. No entanto, o tipo de cinemática usado traz alguns desafios devido à interação entre as rodas e o chão. O problema mais comum no controlo deste tipo de robôs é o facto de necessitarem que ocorra derrapagem para que possam alterar a sua trajetória, no entanto, tal procedimento é difícil de descrever pois depende de diversos fatores como a ficção entre o chão e as rodas\cite{c3}. O funcionamento deste tipo de plataforma, representada na figura \ref{fig:ssmr} é realizado pelo acionamento em simultâneo de ambas as rodas laterais. Para a plataforma realizar uma trajetória linear ambos os pares de rodas têm de rodar com a mesma velocidade, enquanto que no caso de uma trajetória curva as rodas têm de rodar com velocidades diferentes. Em \cite{c3} é apresentado uma solução para as equações da cinemática deste tipo de robô ( equação \ref{ssmr}), na quais $w_{L}$ e $w_{R}$ representam as velocidades angulares das rodas do lado esquerdo e direito respetivamente, $v_{x}$ e $w$ a velocidade linear e angular da plataforma respetivamente. O valor das constantes $r$ e $c$ têm que ser calculadas com base em ensaios experimentais pois dependem da interação com o meio. \begin{equation} \label{ssmr} \begin{bmatrix} v_{x}\\ w \end{bmatrix}= r\begin{bmatrix} \dfrac{w_{L}+w_{R}}{2}\\ \dfrac{-w_{L}+w_{R}}{2c} \end{bmatrix} \end{equation} \begin{figure} \centering \includegraphics[width=0.6\textwidth]{ssmr.png} \caption{Esquema de uma plataforma móvel \textit{skid-steering} \cite{c3}} \label{fig:ssmr} \end{figure} De forma aperfeiçoar as equações de cinemática, são diversas as abordagens utilizadas. Um estudo realizado na universidade de Beihang \cite{c2} propõe que para se conseguir chegar a um modelo cinemático se recorra a um laser (Sick LMS400) para traçar a trajetória percorrida, de forma a obter os valores para as constantes de forma a caracterizar da melhor forma o modelo cinemático. Para essa experiência é usada a plataforma móvel robótica Pioneer P3-AT (figura \ref{fig:p3at}) que é desenvolvida pela empresa Adept e muito usada para investigação utilizando um computador a bordo para comunicar com o \textit{hardware} usando uma biblioteca própria da marca. \begin{figure} \centering \includegraphics[width=0.3\textwidth]{p3at.jpg} \caption{Plataforma Pioneer P3-AT\cite{pioneer}} \label{fig:p3at} \end{figure} %fará mais sentido colocar a imagem do teste? \subsection{Sistemas distribuídos usando ROS} De uma forma breve, o \gls{ROS} consiste numa \emph{framework} usada no desenvolvimento de robô que permite ter vários processos a correr ao mesmo tempo denominados por nodos, podendo estes ser desenvolvidos em diversas linguagens e plataformas, permitindo uma abstração do \emph{hardware}. Para realizar a comunicação entre todos eles, existe o nodo \emph{roscore} que gerência toda a passagem de informação. Os nodos \gls{ROS} podem então ser distribuídos por diversas máquinas, o que permite ter sistemas distribuídos. Uma aplicação que pode ser realizada é o controlo de vários robôs tendo por base uma única unidade de controlo onde é executado o \emph{roscore} (figura \ref{signal_modelz}) que terá como tarefa contolar os diverssos robôs remotamente e fazer o gerenciamento da comunicação entre os diversos robôs, tendo estes apenas de executar nodos específicos \cite{c4}. No trabalho descrito em \cite{c6} foi utilizada esta abordagem de onde é feita a simulação de vários robôs para realizarem uma função de mapeamento e de exploração. Muito semelhante ao exemplo anterior, outra possibilidade é existir um robô que contenha uma unidade computacional que atue como Master onde seja executado o \emph{roscore}, e haver outros robôs que apenas executam os seus nodos específicos comunicando sempre com o Master. Porém, também existe a possibilidade de se ter uma rede distribuída de ROS onde cada unidade computacional corre o seu \emph{roscore} havendo uma passagem dos tópicos através da utilização de \emph{packages} especiais (figura \ref{amplitude_modz}), como por exemplo o \verb|wifi_comm| \cite{wifi_comm}. Uma aplicação desta abordagem pode ser consultada no trabalho de \cite{c5}, onde o objetivo é fazer o controlo de diversos robôs de modo a que todos executem uma tarefa de mapeamento. \begin{figure} \centering \subfloat[][]{\includegraphics[scale=0.55]{rosnet.png}\label{signal_modelz}} \subfloat[][]{\includegraphics[scale=0.55]{rosnet2.png}\label{amplitude_modz}} \caption{\protect\subref{signal_model} Controlo de vários robôs usando uma unidade centralizada executando o ROS Master \protect\subref{amplitude_mod} Controlo de vários robôs cada um correndo o ROS Master \cite{c4}} \end{figure} \section{Estrutura da dissertação} %ultima cena a fazer A presente dissertação é constituída pelo presente capítulo e mais seis: \begin{itemize} \item \textbf{Estrutura experimental e ferramentas} - Descrição do \textit{hardware} e \textit{software} utilizado ao longo do trabalho; \item \textbf{Controlo da plataforma} - São abordados os procedimentos executados para a realização do controlo da plataforma; \item \textbf{Unidade computacional} - É descrito todo o processo para a obtenção da solução proposta para a unidade computacional de todo o sistema; \item \textbf{Ambiente de simulação} - Descrição do processo e resultados obtidos para o desenvolvimento do ambiente de simulação; \item \textbf{Aplicação ilustrativa} - Descrição da aplicação desenvolvida e seus resultados; \item \textbf{Conclusão e trabalho futuro} - São apresentadas as conclusões do trabalho e as propostas de trabalho futuro. \end{itemize} % ---------------------------------------------------------------- % Corpo da tese - Parte II % ---------------------------------------------------------------- \chapter{Infraestrutura experimental e ferramentas} Neste capítulo são descritos todos os \textit{softwares}, equipamentos e bibliotecas usadas ano desenvolvimento do trabalho, nomeadamente a plataforma, o \gls{ROS}, o simulador Gazebo, e unidades de processamento e controlo. \section{Plataforma robótica móvel} Como referido no capítulo \ref{chap:Introdução}, o trabalho desenvolvido terá como objeto de estudo uma plataforma robótica móvel denominada por NARDO, representada na figura \ref{fig:nardo}. A plataforma possui um motor dedicado ao acionamento de cada par de rodas laterais da plataforma. Os motores utilizados são motores de escovas DC de 24V tendo já incorporada uma caixa redutora (figura \ref{fig:motor}). \begin{figure} \centering \includegraphics[width=0.3\textwidth, angle=270]{motor.jpg} \caption{Motor utilizado na plataforma} \label{fig:motor} \end{figure} Para fazer o acionamento dos motores são utilizados os \textit{drivers} de potência YC-MD1301-2.2 tendo uma corrente máxima de 10A DC. Estas unidades permitem a entrada de um sinal \gls{PWM} de 5V e de 35VDC para a alimentação dos motores. Permitem ainda fazer a troca de sentido de direção com recurso a uma ponte H. Como alimentação de todo o sistema, são usadas duas baterias de chumbo de 12V ligadas em série dando assim uma tensão de saída de 24V permitindo a alimentação dos motores. Existe ainda um conversor de tensão que converte os 24V das baterias em 20V com o objetivo de fazer a alimentação para os circuitos de controlo. O controlo remoto da plataforma é feito com um comando de \textit{PlayStation 3} ligado via bluetooth a um controlador Arduino UNO con recurso a um "shield" USB e um adaptador bluetooth. Como meio de transmissão entre os motores e as rodas é usado um sistema de correias transmitindo a mesma potência para ambas as rodas (figura \ref{fig:transmicao}). Na figura \ref{fig:geral} pode ser observada uma ilustração com todos os componentes mencionados anteriormente. A plataforma tem 800 mm de largura, 1200 mm de comprimento e 350 mm de altura. As suas rodas possuem um rasto com grande relevo, o que torna a plataforma apropriada para realizar tarefas em terrenos arenosos. \begin{figure} \centering \def\svgscale{0.75} \input{drawing2.pdf_tex} \caption{Sistema de transmição utilizado na plataforma} \label{fig:transmicao} \end{figure} \begin{figure} \centering \def\svgscale{0.75} \input{drawing.pdf_tex} \caption{Ilustração dos componentes da plataforma} \label{fig:geral} \end{figure} \section{ROS - Robot Operating System} Originalmente criado em 2007 o \gls{ROS} é um ambiente de desenvolvimento para a realização de software para robôs, oferecendo funcionalidades idênticas a um sistema operativo. O \gls{ROS} oferece diversas vantagens tais como: \begin{itemize} \item Grande variedade de ferramentas: juntamente com o \gls{ROS} temos ao nosso dispor diversas ferramentas que nos permitem fazer \textit{debugging}, visualização e simulação das aplicações criadas; \item Suporte para diversos sensores e atuadores: temos disponível um vasto número de controladores para os mais diversos tipos de sensores tais como lasers e câmaras; \item Modularidade: devido ao facto de em \gls{ROS} se usarem vários processos dedicados a uma operação, no caso de alguma parte do robô falhar esta não compromete a funcionalidade das restantes caso se use redundância. \end{itemize} No geral, pode-se dizer que o \gls{ROS} está subdividido em três grupos, o \textit{file system level}, o \textit{Computation Graph level} e o \textit{Community level} (figura \ref{fig:M1}). \begin{figure} \begin{center} \begin{tikzpicture} \tikzset{special characters mynode/.style={rectangle,rounded corners,draw=black, top color=white, bottom color=white!50,very thick, inner sep=1em, minimum size=3em, text centered}, myarrow/.style={->, >=latex', shorten >=1pt, thick}, mylabel/.style={text width=7em, text centered} } \node[block, minimum width=4cm] (manufacturer) { ROS }; \node[below=1cm of manufacturer] (dummy) {}; \node[block, below=of dummy] (retailer3) {\emph{Community level}}; \node[block, left=of retailer3] (retailer1) {\emph{Filesystem Level}}; \node[block, right=of retailer3] (retailer2) {\emph{Computation graph level}}; \draw[myarrow] (manufacturer.south) -- ++(-1.5,0) -- ++(0,-1) -| (retailer1.north); \draw[myarrow] (manufacturer.south) -- ++(1.5,0) -- ++(0,-1) -| (retailer2.north); \draw[myarrow] (manufacturer.south) -- ++(0,0) -- ++(0,0) -| (retailer3.north); \end{tikzpicture} \end{center} \caption{Estrutura geral do ROS} \label{fig:M1} \end{figure} \subsubsection{\textit{Filesystem level}} Algo que distingue o \gls{ROS} de outras soluções é o seu sistema de ficheiros. Tal como um sistema operativo, os ficheiros do \gls{ROS} também estão guardados em disco com uma configuração específica segundo o diagrama da figura \ref{fig:filesystem}. \begin{figure}[H] \centering \includegraphics[width=0.75\textwidth]{fs.pdf} \caption{Diagrama com a estrutura de ficheiros do ROS} \label{fig:filesystem} \end{figure} Segue uma explicação de cada uma das partes representadas: \begin{itemize} \item \textbf{Packages}: Os ROS \emph{packages} são a unidade mais básica da arquitetura ROS. Aqui estão contidos todos os processos, bibliotecas, ficheiros de configuração, entre outros. \item \textbf{Package manifest} - Trata-se de um ficheiro que contém a informação acerca do \textit{package} tal como o autor, licenças, dependências e regras de compilação. \item \textbf{Meta packages} - É usado para agrupar \textit{packages} para um determinado propósito. Um exemplo de um \textit{Meta package} é o Navigation Stack. \item \textbf{Meta packages manifest} - Semelhante ao \textit{package manifest}, inclui as dependências das \textit{packages} que lhe estão contidos. \item \textbf{Messages ( .msg )} - ROS messages são o tipo de informação que o ROS envia entre os vários processos. Pode-se definir um tipo de mensagem dentro de uma pasta denominada de \verb|msg| dentro de um \textit{package}. \item \textbf{Services ( .srv )} - ROS services é uma espécie de interação pedido/resposta entre processos. Os tipos de mensagem de pedido e resposta são definidos dentro de uma pasta denominada de \verb|srv| dentro de um \textit{package}. \end{itemize} \subsubsection{\textit{Computation graph level}} O \textit{computation graph level} é o grupo onde o \gls{ROS} processa todos os dados dentro da sua rede. As principais partes deste nível são os nodos, mensagens, tópicos, serviços, \textit{bags}, o \textit{Master} e \textit{Parameter Server}. A figura \ref{fig:graph_level} apresenta um esquema com esta informação. \begin{figure}[H] \centering \includegraphics[width=0.75\textwidth]{graph_level.png} \caption{Diagrama referente às diferentes partes do \textit{Computation graph level} \cite{mastering}} \label{fig:graph_level} \end{figure} \iffalse \begin{tikzpicture} \tikzset{special characters mynode/.style={rectangle,rounded corners,draw=black, top color=white, bottom color=white!50,very thick, inner sep=1em, minimum size=3em, text centered}, myarrow/.style={->, >=latex', shorten >=1pt, thick}, mylabel/.style={text width=7em, text centered} } \node[block, minimum width=4cm] (manufacturer) { ROS }; \node[above=2cm of manufacturer] (dummy) {}; \node[block, right=of dummy] (retailer3) {\emph{Community level}}; \node[block, left=of dummy] (retailer4) {\emph{Community level}}; \node[block, left=of retailer4] (retailer1) {\emph{Filesystem Level}}; \node[block, right=of retailer3] (retailer2) {\emph{Computation graph level}}; \draw[myarrow] (manufacturer.north) -- ++(-1.5,0) -- ++(0,1) -| (retailer1.south); \draw[myarrow] (manufacturer.north) -- ++(1.5,0) -- ++(0,1) -| (retailer2.south); \draw[myarrow] (manufacturer.north) -- ++(0,0) -- ++(0,1) -| (retailer3.south); \draw[myarrow] (manufacturer.north) -- ++(0,0) -- ++(0,1) -| (retailer4.south); \end{tikzpicture} \fi Nos seguintes pontos será explicado qual é a funcionalidade de cada parte: \begin{itemize} \item \textbf{Nodos} - Os nodos são os processos que realizam o processamento. Estes estão escritos usando bibliotecas específicas do ROS tais como \verb|roscpp| e \verb|rospy|. Um robô pode ter vários nodos onde cada um é responsável pelo processamento de uma determinada tarefa. Para comunicarem entre si, os nodos podem usar métodos de comunicação do ROS como a publicação e subscrição de tópicos, descrito seguidamente. \item \textbf{\textit{Master}} - O ROS Master é responsável pelo registo e administração dos nodos existentes. Assim os nodos podem trocar mensagens, reconhecerem-se entre si, ou invocarem algum serviço. Num sistema distribuído, o ROS Master deverá ser ativado inicialmente e posteriormente os restantes nodos podem comunicar. \item \textbf{\textit{Parameter Server}} - Permite que todos os dados estejam guardados num sistema central, possibilitando ao utilizador alterar e configurar os parâmetros dos nodos enquanto estes estão em execução. \item \textbf{Mensagens} - São o método de comunicação entre os nodos, estas possuem uma estrutura de dados bem definida e conhecida entre cada nodo ROS. Existem algumas estruturas padrão de mensagens, no entanto é possível desenvolver outras. \item \textbf{Tópicos} - É o nome que é dado ao canal por onde são enviadas as mensagens. Quando um nodo publica uma mensagem através de um tópico podemos dizer que o nodo publicou um tópico, o mesmo acontece no caso da receção de uma mensagem onde dizemos que o nodo subscreve o tópico. É possível subscrever tópicos que não estão a ser publicados assim como um tópico pode ser acedido por vários nodos. \item \textbf{Serviços} - Por vezes o uso de mensagens não é suficiente sendo necessário existir uma interação pedido/resposta entre processos. Para isto, os serviços permitem que um nodo cliente envie um serviço que posteriormente um nodo servidor irá processar enviando no fim uma resposta informando da conclusão da tarefa. \item \textbf{\textit{Bags}} - É um formato de ficheiro que armazena todas as mensagens de tópicos e de serviços, dando a possibilidade de play back de um período de tempo definido. \end{itemize} \subsubsection{Community level} O Community level consiste em todas as distribuições ROS, repositórios, a Wiki do ROS e o ROS Answers que permite a todos os investigadores, desenvolvedores e indústrias a partilharem os seus programas, ideias e conhecimento no sentido de melhorar as comunidades de robótica. Por si só, o ROS não faz a manutenção dos seus repositórios para os pacotes de ROS, no entanto os utilizadores e desenvolvedores são encorajados a hospedar os seus próprios repositórios para os pacotes que eles próprios criaram ou usaram. Os desenvolvedores têm a possibilidade de utilizarem a ROS Wiki para publicitar e criarem tutoriais que demonstram as usabilidade dos seus próprios pacotes. ROS answers é um fórum que ajuda a responder a questões relacionadas com ROS que os seus utilizadores possuam\cite{mastering}. \section{URDF}Uma das formas de definirmos um robô, os seus sensores e o seu ambiente de trabalho envolvente, é criar o seu \gls{URDF}. Aqui pode-se descrever robôs que tenham uma estrutura do estilo de árvore, ou seja, que é constituído por elos que terão de ser rígidos. Todos estes elos são então conectados através de juntas. O \gls{URDF} é composto usando \textit{tags} especiais de XML que posteriormente serão processadas. Exemplos destas \textit{tags} são a \verb|| e \verb||, onde na primeira é definido um elo incorporando características como a forma e massa, na segunda podemos definir as juntas indicando o seu tipo e os elos que lhe pertencem. De forma a simplificar a escrita deste tipo de ficheiro é possível usar xacros que são macros de XML. Ao utilizar xacros pode-se tornar o ficheiro \gls{URDF} mais curto, aumentar a sua facilidade de leitura, e pode ser usado para construir descrições de robôs complexas. Usando algumas ferramentas do ROS, é possível converter um xacro em \gls{URDF}. Na listagem \ref{lst:urdf} encontra-se um exemplo do código \gls{URDF} de um robô que contem dois elos e uma junta a interligados, estando ilustrado o seu resultado final na figura \ref{fig:urdf2} \begin{lstlisting}[language=XML, caption=Exemplo da definição de um robô com dois elos e uma junta no formato URDF, label={lst:urdf}] \end{lstlisting} \begin{figure}[H] \centering \includegraphics[width=0.4\textwidth]{urdf2.png} \caption{Visualização do robô resultante do código presente na listagem \ref{lst:urdf}} \label{fig:urdf2} \end{figure} \section{Gazebo} Neste trabalho será usado um simulador de robôs denominado por Gazebo onde se pode testar robôs complexos, sensores e uma variedade de objetos. Este simulador possui modelos de simulação para alguns robôs comuns que poderão ser usados sem a necessidade de serem criados desde raiz \cite{gazebo3}. O ROS já possui vários \textit{packages} que permitem uma fácil comunicação com o Gazebo, tal como o \verb|gazebo_msgs| que contem estruturas de mensagens e serviços que permitem interagir como Gazebo a partir do \gls{ROS}. Para além desta comunicação, o Gazebo permite também a adição de vários sensores aos robôs tais com sensor de visão. Devido à sua vasta lista de \emph{plugins} pode simular muitos dos sensores existentes no mercado atualmente. Na figura \ref{fig:gazebo} pode observar-se uma imagem ilustrativa da interface gráfica \cite{gazebo2}. \begin{figure}[H] \centering \includegraphics[width=0.5\textwidth]{gazebo.png} \caption{Interface gráfica do Gazebo \cite{gazebo}} \label{fig:gazebo} \end{figure} Uma ferramenta que o Gazebo possui é o \emph{Building Editor} que permite criar ambientes de simulação, onde é possível criar edifícios, por exemplo. \section{OpenCV} OpenCV (\textit{Open Source Computer Vision Library}) é uma biblioteca usada para processamento de imagem, podendo ser utilizada livremente tanto em meio académico ou comercial. Para a sua utilização podem ser usadas diversas linguagens de programação tais como C/C++, Python e Java. No caso do trabalho realizado, a biblioteca é utilizada na realização da aplicação para a demonstração do trabalho proposto, sendo usado o processamento de imagem para a deteção da linha. \section{Controladores Arduino} Uma das unidades de processamento usadas neste trabalho é o microcontrolador Arduino. O Arduino é uma plataforma \textit{open-source} e fácil de usar que permite a aquisição de sinais externos e também a ativação de saídas digitais. Devido a toda esta versatilidade, o sistema Arduino é largamente usado em muitos projetos tais como a construção de robôs. O tipo de programação utilizada é bastante simplificada comparando com a programação de microcontroladores PIC, pois o Arduino já possui bibliotecas internas que ajudam na configuração dos seus pinos. Para realizar a programação do microcontrolador existe um \gls{IDE} de fácil utilização onde já é incluído o compilador. Neste momento existem diversas plataformas com configurações diferentes, no entanto neste trabalho apenas foram usadas as versões UNO e Nano representados nas figuras \ref{fig:arduino_uno} e \ref{fig:arduino_nano} respetivamente. Na tabela \ref{tab:arduino} podem ser consultadas as especificações de cada uma destas plataformas\cite{arduino}. \begin{figure}[H] \centering \includegraphics[width=0.5\textwidth]{arduino_uno.jpg} \caption{Controlador Arduino Uno\cite{arduino2}} \label{fig:arduino_uno} \end{figure} \begin{figure} [H] \centering \includegraphics[width=0.5\textwidth]{arduino_nano.jpg} \caption{Controlador Arduino Nano\cite{arduino3}} \label{fig:arduino_nano} \end{figure} \begin{table}[H] \centering \begin{tabular}{l l l} \hline Versão & Arduino Uno & Arduino Nano \\ \hline Microcontrolador & ATmega328 & ATmega328 \\ Tensão de trabalho & 5V & 5V \\ Flash Memory & 32 KB & 32 KB \\ Clock Speed & 16 MHz & 16 MHz \\ Pinos saída & 14 & 14 \\ Pinos pwm & 4 & 4 \\ Pinos analógicos & 6 & 8 \\ Tamanho & 68.6 mm $\times$ 53.4 mm & 18 mm $\times$ 45 mm \\ Massa & 25 g & 7 g \\ \end{tabular} \caption{Especificações do arduino Uno e Nano \cite{arduino2, arduino3}} \label{tab:arduino} \end{table} \section{Raspberry Pi} Raspberry Pi é um computador com a dimensão de um cartão de crédito e de baixo custo. Foi originalmente criado para melhorar as competências de programação e \textit{hardware} para crianças e jovens. No entanto devido ao seu tamanho e baixo custo, começou a ser utilizado para outros fins tais como projetos eletrónicos e domótica. Com a sua capacidade de processamento este sistema consegue ter as capacidades de um computador, desempenhando todas as funcionalidades implicando um baixo consumo energético\cite{rpi2}. Atualmente existem no mercado diversas versões desta placa onde difere o seu formato assim como as suas especificações. Neste trabalho foram usadas a versão Raspberry 2 e o Raspberry Pi 3 (figura \ref{fig:rpi3}). Na tabela \ref{tab:rpi} são apresentadas algumas das suas características. \begin{figure}[H] \centering \includegraphics[width=0.5\textwidth]{rasp_pi.jpeg} \caption{Unidade computacional Raspberry Pi 3\cite{rpi}} \label{fig:rpi3} \end{figure} \begin{table}[H] \centering \begin{tabular}{l l l} \hline & \textbf{Raspberry Pi 2} & \textbf{Raspberry Pi 3} \\ \hline Processador & Cortex-A7 & Cortex-A53 64-bit \\ Número de núcleos & 4 & 4 \\ CPU Clock & 900MHz & 1.2GHz \\ RAM & 1 GB & 1 GB \\ GPIO pinos & 40 & 40 \\ Porta HDMI & Sim & Sim \\ Porta Ethernet & Sim & Sim \\ Portas USB & 4 & 4 \\ SPI & Sim & Sim \\ I2C & Sim & Sim \\ Wi-Fi & Não & Sim \\ Bluetooth & Não & Sim \\ \end{tabular} \caption{Lista de específicações dos Raspberry Pi 2 e 3\cite{rpi3}} \label{tab:rpi} \end{table} % ---------------------------------------------------------------- % Corpo da tese - Parte III - Solução % ---------------------------------------------------------------- \chapter{Controlo da plataforma} Neste capítulo abordam-se todos os procedimentos tomados para o controlo da plataforma, mais especificamente a elaboração do controlo em malha fechada dos motores e a comunicação entre a unidade computacional central e os microcontroladores. \section{Interveções na plataforma} Para se realizar o controlo da plataforma foi necessário fazer algumas alterações à mesma, mais especificamente a implementação de \emph{encoders} de forma a ser possível ter \textit{feedback} em relação ao estado das rodas, podendo assim ser feito um controlo em malha fechada. Os \emph{encoders} disponíveis, fornecidos pela empresa que propôs o trabalho, são do tipo incremental e possuem as características apresentadas na tabela \ref{tab:encoder}. \begin{table}[H] \centering \begin{tabular}{l l} \hline Tensão mínima de entrada & 5V \\ Tensão máxima de entrada & 24V \\ Número de canais & 2 \\ Rotação máxima & 5000 RPM \\ Pulsos por rotação & 100 \\ Diâmetro do veio & 6 mm \\ Diâmetro exterior & 40 mm \\ \hline \end{tabular} \caption{Características dos \emph{encoders} usados} \label{tab:encoder} \end{table} Para o acoplamento entre os motores e \emph{encoders} é usado um sistema com uma correia que faz a transmissão entre o veio do \emph{encoder} e o veio da roda, existindo uma polia em cada um (figura \ref{fig:encmount}). Nesta transmissão acontece uma desmultiplicação de 1:3, multiplicando em três vezes o número de rotações que o \emph{encoder} lê em relação às rotações da roda, aumentando assim a precisão de leitura. O suporte do encoder é realizado através de uma chapa que é fixada no suporte do veio do motor, tendo também a furação referente ao encaixe do \emph{encoder}. No total, foram instalados dois \emph{encoders} na plataforma ambos nas rodas dianteiras da plataforma. \begin{figure} \centering \def\svgscale{0.2} \input{enc2.pdf_tex} \caption{Montagem final dos \emph{encoders}} \label{fig:encmount} \end{figure} \section{Leitura de posição} Para a realização da leitura dos \emph{encoders} a solução encontrada baseia-se em colocar um controlador Arduino dedicado para cada \emph{encoder}, sendo cada um destes denominado por Slave. O valor lido por cada encoder é posteriormente comunicado para outro controlador Arduino, Master, utilizando uma comunicação I2C. O Arduino Master é então responsável por fazer o processamento dos dados recebidos. Na figura \ref{fig:enc_net} encontra-se um esquema da configuração final utilizada. A opção pelo uso de controladores Arduino para a leitura dos \emph{encoders} deveu-se principalmente ao facto de estes estarem disponíveis no laboratório evitando assim o gasto de recursos em outras soluções tais como circuitos contadores. Neste trabalho, devido à disponibilidade do \emph{hardware}, foram utilizados um controlador Arduino UNO como Slave Right e Master, enquanto que como Slave Right foi usado um Arduino Nano. Em relação à leitura dos sinais do \emph{encoder} tirou-se proveito do facto de estarem disponíveis dois pinos de \textit{interrupt} em cada Arduino, podendo-se assim utilizar as variações de ambos os canais para provocar interrupções no Arduino, aumentando a resolução de leitura em quatro vezes pois, conforme demonstrado na figura \ref{fig:enc_quadra}, existem quatro combinações diferentes aquando da leitura dos sinais do \emph{encoder}. \begin{figure} \centering \includegraphics[width=0.8\textwidth]{encnet.pdf} \caption{Diagrama com a rede de Arduinos utilizada para a leitura dos \emph{encoders}} \label{fig:enc_net} \end{figure} \begin{figure} \centering \includegraphics[width=0.75\textwidth]{enc_quadra.jpg} \caption{Diagrama temporal dos sinais recebidos do \emph{encoder}\cite{encoder}} \label{fig:enc_quadra} \end{figure} Assim, para realizar a leitura do encoder com o Arduino foram utilizados os pinos de \textit{interrupt} do Arduino, pinos 2 e 3. Utilizando a função do Arduino \verb|attachInterrupt()| com a opção \verb|CHANGE| pode-se definir uma função que será executada sempre que o sinal recebido num dos pinos altere. Esta função é responsável por decrementar ou incrementar o valor correspondente aos pulsos do encoder tendo em conta o seu estado e o do outro pino, conforme ilustrado na figura \ref{fig:interrupt}. \begin{figure} \centering \begin{tikzpicture}[node distance = 1.5cm, auto] % Place nodes \node [block] (init) { Início}; \node [decision, below of=init] (identify) {Pino 2 == 1?}; \node [decision, below of=identify] (evaluate) {Pino 3 == 1?}; \node [decision, right of=evaluate, node distance=4cm] (update) {Pino 3 == 0?}; \node [block, below of=update, node distance=3cm] (update3) {counter++}; \node [block, below of=evaluate, node distance=3cm] (evaluate2) {counter- -}; \node [block, below of=evaluate2, node distance=2cm] (stop) {Fim}; % Draw edges \path [line] (init) -- (identify); \path [line] (identify) -- node {Não} (evaluate); \path [line] (identify) -| node [near start] {Sim} (update); \path [line] (evaluate) -- node [near start] {Não} (update3); \path [line] (update) -- node {Não} (update3); \path [line] (evaluate) -- node {Sim} (evaluate2); \path [line] (update) -- node [near start] {Sim} (evaluate2); %\path [line] (decide) -| node [near start] {yes} (update); %\path [line] (update) |- (identify); \path [line] (update3) |- (stop); \path [line] (evaluate2) -- (stop); \end{tikzpicture} \caption{Diagrama referente à função executada sempre que é ativada a interrupção 1 num controlador Slave} \label{fig:interrupt} \end{figure} Ainda no Arduino Slave tem de se efetuar a comunicação I2C, para tal recorreu-se ao uso a biblioteca \verb|Wire.h| \cite{wire}. Aqui é necessário definir um endereço fixo para o Slave de modo a que o Master possa fazer pedidos. Tem de se definir uma função que será executada quando é feito um pedido, neste caso para o envio do número de pulsos. Para efetuar um melhor tratamento da informação, a mensagem enviada por I2C tem o formato \verb|/|, sendo do tipo \verb|String|. No Arduino Master, é então necessário também utilizar a biblioteca \verb|Wire.h| de forma a que seja possível fazer a comunicação I2C com os Arduinos Slave. Para a obtenção das mensagens por parte dos controladores Slave, o Arduino Master tem que fazer um pedido onde é indicado o endereço do Arduino de onde se quer obter a leitura do \emph{encoder}, assim como o tamanho da mensagem a ler. Após a receção da mensagem, o Master tem que fazer o seu tratamento, eliminando a "/" e a conversão do valor lido para inteiro. \section{Comunicação com microcontrolador} Para realizar a comunicação entre a unidade computacional e o Arduino foi utilizado um \textit{package} de ROS denominado por Rosserial. Este \emph{package} baseia-se numa série de protocolos de comunicação que permitem fazer a comunicação entre o \gls{ROS} e outros dispositivos através de porta série, \emph{socket} ou vise-versa (figura \ref{fig:rosserial}). O protocolo Rosserial pode converter entre mensagens e serviços ROS para tipos de mensagens para outros tipos que sejam entendidos pelos dispositivos a usar \cite{rosserial}. Para complementar, existe uma biblioteca para Arduino, \verb|rosserial_arduino|, que permite realizar a leitura das mensagens \gls{ROS}, podendo assim subscrever e publicar tópicos \gls{ROS}. No caso da aplicação em questão, na unidade computacional é publicado um tópico onde a sua mensagem contem a informação da velocidade desejada em cada roda da plataforma. Após o Arduino detetar a receção de uma mensagem é então ativada uma \textit{callback} no microcontrolador que atualizará o valor das velocidades desejadas nas respetivas variáveis. Por outro lado, de forma a existir um controlo contínuo e uma monitorização por parte da unidade computacional, o Arduino também realiza a publicação de um tópico que contem os dados referentes ao número de pulsos lidos em cada roda. \begin{figure} \centering \includegraphics[width=0.6\textwidth]{rosserial2.png} \caption{Comunicação comunicação entre diversos dispositivos usando rosserial \cite{rosserial}} \label{fig:rosserial} \end{figure} \section{Controlador PID} De modo a fazer um controlo em malha fechada desenvolveu-se um controlador PID utilizando um microcontrolador Arduino. Este tipo de controlador baseia-se no cálculo de um erro da posição, através do valor lido momentaneamente e o desejado. Após o erro ser processado o controlador calcula um valor de saída base com base nas constantes de ganho Proporcional (P), Integral (I) e Derivativo (D). No trabalho desenvolvido, este tipo de controlador foi implementado no Arduino Master e para isto foi desenvolvida uma \emph{class} que permite a sua implementação. Esta \textit{class} para além de ter o obrigatório construtor que aceita como parâmetros as constantes do PID, tem os seguinte métodos: \begin{itemize} \item \verb|setSetPoint(double value)| - tem como função fazer a definição do valor a atingir com o PID; \item \verb|addNewSample(double value)| - adiciona uma nova amostra que será usada para realizar o cálculo do novo erro; \item \verb|compute()| - este é o método principal da \emph{class}, que tem como objetivo calcular o valor de saída do controlador, sendo necessário aqui calcular o erro entre a última leitura e o valor pretendido; \iffalse \item \verb|setP(double value)| - tem como função permitir fazer uma atualização referente à constante kP do controlador; \item \verb|setI(double value)| - tem como função permitir fazer uma atualização referente à constante kI do controlador; \item \verb|setD(double value)| - tem como função permitir fazer uma atualização referente à constante kD do controlador; \fi \end{itemize} \lstset{language=C++, basicstyle=\ttfamily, keywordstyle=\color{blue}\ttfamily, stringstyle=\color{red}\ttfamily, commentstyle=\color{green}\ttfamily, morecomment=[l][\color{magenta}]{\#} } \begin{lstlisting}[ caption=\emph{Class} desenvolvida para a implementação do controlador PID, label={lst:rpi1}] class PID{ public: double error, sample, lastSample, kP, kI, kD, P, I, D, pid, setPoint; long lastProcess; PID(double _kP, double _kI, double _kD){ kP = _kP; kI = _kI; kD = _kD; } void addNewSample(double _sample){ sample = _sample; } void setSetPoint(double _setPoint){ setPoint = _setPoint; } double process(){ error = setPoint - sample; float deltaTime = (millis() - lastProcess) / 1000.0; lastProcess = millis(); P = error * kP; I = I + (error * kI) * deltaTime; D = (lastSample - sample) * kD / deltaTime; lastSample = sample; pid = P + I + D; return pid; } }; \end{lstlisting} Com a definição desta \textit{class}, pode-se fazer o desenvolvimento de todo o código necessário para o Arduino Master, que está de acordo com o diagrama da figura \ref{fig:pidarduino}. Neste programa é necessário realizar a ativação das saídas do Arduino que ativarão os motores, tanto em velocidade como em direção. A taxa de amostragem utilizada para o PID foi de 100 Hz. Para o cálculo da velocidade linear de cada roda é utilizada a equação \ref{eq_rpm}, onde $D$ representa o diâmetro da roda em metros, $P$ o número de pulsos lidos pelo encoder num determinado intervalo de tempo, $N$ o número de pulsos que o encoder dá por rotação e $T$ o intervalo de tempo da leitura em segundos. No caso do número de pulsos este será igual a 1200, pois existe a desmultiplicação de 1:3 no acopolamento do \emph{encoder}, e a multiplicação por quatro devido ao uso dos dois sinais do \emph{encoder}. \begin{equation} \label{eq_rpm} v = \frac{\pi \times D \times P}{4 \times N \times T} (m/s) \end{equation} Após a implementação do programa no Arduino, é necessário fazer o ajuste dos parâmetros do controlador PID. O método encontrado para a definição do controlador PID foi com base em tentativa e erro. De modo a facilitar todo este processo desenvolveu-se primeiramente um programa de Arduino que permite fazer o ajuste das constantes do PID através do computador, evitando que seja necessário o envio de um novo programa com as novos valores. Quando a resposta dos motores corresponder às expectativas, é então elaborado um programa de Arduino final que contém as constantes do controlador finais. \iffalse No gráfico da figura \ref{fig:pidgraph} é possível observar a resposta obtida pelo controlador quando é aplicado um impulso. \begin{figure} \centering \includegraphics[width=0.8\textwidth]{image.png} \caption{Gráfico resultante da leitura dos pulsos do PID} \label{fig:pidgraph} \end{figure} \fi \begin{figure} \centering \begin{tikzpicture}[node distance = 3cm, auto] % Place nodes \node [cloud] (init) { Início}; \node [block, below of=init, node distance=2cm] (first) {\begin{varwidth}{15em}Pedido do número de pulsos ao Arduino Slave Left\end{varwidth}}; \node [block, below of=first, node distance=2cm] (second) {\begin{varwidth}{15em}Pedido do número de pulsos ao Arduino Slave Right\end{varwidth}}; \node [block, below of=second, node distance=2cm] (third) {\begin{varwidth}{15em}Cálculo das velocidades de ambas as rodas\end{varwidth}}; \node [block, below of=third, node distance=2cm] (forth) {\begin{varwidth}{15em}Aplicação do PID\end{varwidth}}; \node [block, below of=forth, node distance=2cm] (fith) {\begin{varwidth}{15em}Aplicação das saídas de direção\end{varwidth}}; \node [block, below of=fith, node distance=2cm] (sixth) {\begin{varwidth}{15em}Ativação das saídas PWM dos motores\end{varwidth}}; % Draw edges \path [line] (init) -- (first); \path [line] (first) -- (second); \path [line] (second) -- (third); \path [line] (third) -- (forth); \path [line] (forth) -- (fith); \path [line] (fith) -- (sixth); \path [line] (sixth) -- ++(-4cm,0) |- (init); \end{tikzpicture} \caption{Diagrama da estrutura do código utilizado no controlador Master para a implementação do PID} \label{fig:pidarduino} \end{figure} \vspace{5px} Ao longo dos testes desenvolvidos na plataforma para a obtenção do PID um dos motores deixou de funcionar. Devido ao facto de novos motores demorarem algum tempo a chegarem optou-se por uma abordagem diferente para o resto do trabalho passando por uma via de simulação, mantendo no entanto toda a compatibilidade com a plataforma real caso ela voltasse a ser considerada. Pretende-se então simular a plataforma usando o simulador Gazebo e testando da mesma forma a solução proposta para o caso da unidade computacional. % ---------------------------------------------------------------- % Corpo da tese - Parte IV - Resultados % ---------------------------------------------------------------- \chapter{Sistema Computacional} Neste capítulo será abordado todo o desenvolvimento e referente ao projeto de uma rede distribuída de Raspberry Pi's operando sobre uma arquitetura ROS. É explicado qual a solução proposta que se pretende implementar, e são apresentadas as etapas para a implementação dessa solução. \section{Solução proposta} \label{proposed_solution} Como referido no capítulo \ref{chap:Introdução}, pretende-se criar uma rede de Raspberry Pi's onde cada um poderá ter várias tarefas a desempenhar. Deste modo pode-se aumentar o poder computacional conforme as necessidades, estando apenas limitados ao poder de processamento de um Raspberry Pi para um nodo ROS. A utilização dos Raspberry Pi's como unidade computacional foi a selecionada, pois para além de ser uma solução de baixo custo e que se encontravam disponíveis. Estes também são compactos o que permite uma melhor adaptabilidade em futuras aplicações. Para executar a comunicação entre todas as unidades computacionais é usado o protocolo de comunicação \emph{ethernet}. Como \emph{hardware} utilizado tem-se um \emph{switch} e os Raspberry Pi's e outras unidades computacionais necessárias para a aplicação a desempenhar. Apesar de neste trabalho ter sido utilizado uma rede \gls{LAN} para a comunicação entre as unidades computacionais, esta também poderia ser realizada usando uma rede\textit{ wireless}, permitindo assim ter várias unidades de processamento distantes e sem uma ligação física entre elas. Nesta solução, apenas uma das unidades computacionais irá necessitar de estar a correr o \emph{roscore} estando as restantes dedicadas a executar nodos específicos. Na figura \ref{fig:rpi_network} está representado um esquema da rede computacional proposta. \begin{figure}[H] \centering \includegraphics[width=0.9\textwidth]{rpinet.pdf} \caption{Esquema ilustrativo da rede de Raspberry Pi's a implementar} \label{fig:rpi_network} \end{figure} \section{Instalação do sistema operativo e ROS} \label{install} Na procura de um sistema operativo que garantisse estabilidade e que satisfaça as exigências que o ROS necessita foi encontrada a opção de instalação do Ubuntu Mate 16.04 LTS. Para se proceder à sua instalação foram feitos os seguintes passos: \begin{itemize} \item Descarregamento do website oficial a versão do sistema operativo optimizado para Raspberry Pi; \item Montagem de um cartão micro SD com uma capacidade mínima de oito \textit{gigabytes} com a imagem descarregada anteriormente; \item Instalação do sistema operativo no Raspberry Pi. \end{itemize} Fica-se assim em condições de proceder à instalação do ROS. Para tal foi instalado o versão ROS Kinetic seguindo os tutorial de instalação presente em \cite{kinetic}. \section{Comunicação entre unidades computacionais} \label{communication} De modo a definir a comunicação entre todas as unidades computacionais procedeu-se à definição de um IP fixo em cada máquina, desta forma a inicialização da rede é mais breve. Para colocarmos cada Raspberry Pi a conseguir comunicar com uma outra máquina onde esteja a correr o \textit{roscore} é necessário definir duas variáveis de ambiente: \begin{itemize} \item \textbf{ROS\_MASTER\_URI} - A definição desta variável indica aos nodos em que máquina é que o \textit{Master} está a ser executado; \item \textbf{ROS\_IP} - Tem como objetivo definir o endereço da rede local onde os nodos ROS estão a ser executados. \end{itemize} Para a definição do ROS\_MASTER\_URI é necessário executar no terminal o seguinte código: \verb|export ROS_MASTER_URI=http://:11311| onde \verb|| é referente ao IP da máquina onde o \textit{Master} irá estar em execução. Quanto à definição do parâmetro ROS\_IP é necessário executar o seguinte comando: \verb|export ROS_IP=| onde \verb|| é o IP da máquina onde serão executados os nodos. \\ \\ De forma a testar a comunicação entre todas as unidades foi feito um teste onde se verificava se um tópico que fosse publicado num Raspberry Pi era visualizado em outro Raspberry Pi usando o comando \verb|rostopic list|. O \textit{setup} utilizado consiste então no uso de um computador onde é executado o \emph{roscore}, e dois Raspberry Pi's onde são publicados tópicos. Na ilustração da figura \ref{fig:rpi_nn} é possível observar a publicação de um tópico num dos Raspberry Pi's, e respetiva visualização no computador e num Raspberry Pi. \begin{figure}[H] \centering \begin{tikzpicture} \node [anchor=west] (note) at (-0.5,4) { (a)}; \node [anchor=west] (note2) at (+13,4) { (b)}; \node [anchor=west] (note3) at (+13,1) {(d)}; \node [anchor=west] (water) at (-0.5,1) {(c)}; \begin{scope}[xshift=1.5cm] \node[anchor=south west,inner sep=0] (image) at (0,0) {\includegraphics[width=0.7\textwidth]{sistema.png}}; \begin{scope}[x={(image.south east)},y={(image.north west)}] \draw[red,ultra thick] (0.5,0.5) rectangle (0,0); \draw[blue,ultra thick] (0.5,1) rectangle (0,0.51); \draw[green,ultra thick] (1,0.5) rectangle (0.51,0); \draw[orange,ultra thick] (1,1) rectangle (0.51,0.51); %\draw [-latex, ultra thick, red] (note) to[out=0, in=-120] (0.48,0.80); \draw [-stealth, line width=3pt, red] (water) -- (0,0.15); \draw [-stealth, line width=3pt, blue] (note) -- (0,0.61); \draw [-stealth, line width=3pt, orange] (note2) -- (1,0.61); \draw [-stealth, line width=3pt, green] (note3) -- (1,0.15); \end{scope} \end{scope} \end{tikzpicture} \caption{Publicação de tópicos e respetiva visualização entre os Raspberry Pi's e o computador (a) Execução do \emph{roscore} no computador (b) Publicação de um tópico num Raspberry Pi (c) Visualização do tópico no computador (d) Visualização do tópico publicado num Raspberry Pi} \label{fig:rpi_nn} \end{figure} \section{Ambiente de Desenvolvimento} \label{dev} De forma a facilitar o trabalho de desenvolvimento envolvendo diferentes máquinas foram criadas determinadas funcionalidades para se obter uma melhor facilidade de uso, descritas a seguir. \subsection{Partilha de ficheiros} Como existe a possibilidade de haver um número elevado de máquinas a trabalhar simultaneamente em rede, uma das funcionalidades implementada foi a partilha de ficheiros entre todas. Isto é útil principalmente para se proceder à partilha de \textit{packages} que são desenvolvidos numa máquina principal. Assim, a solução proposta baseia-se na criação de uma pasta partilhada entre todas as unidades sendo uma delas o servidor. Para isto, recorreu-se ao uso do \textit{software} \gls{NFS} que permite criar pasta partilhada dentro de uma rede. Esta pasta encontra-se alojada numa das unidades computacionais que servirá como servidor, conforme ilustrado na figura \ref{fig:nfs}. Após feita a configuração do servidor as unidades clientes podem subscrever a pasta partilhada e podem usar o seu conteúdo. \iffalse No caso de os ficheiros a serem partilhados corresponderem a \textit{packages} é necessário então fazer uma cópia dos mesmos da pasta partilhada para o diretório correto dentro do ambiente de trabalho do ROS. \fi No caso de os ficheiros a serem partilhados corresponderem a \textit{packages} é criar um link simbólico no respectivo diretório do \emph{workspace} \gls{ROS} referente ao \emph{package} a ser usado. Para isto, pode-se usar o comando \verb|ln -s |, onde \verb|| corresponde ao diretório da pasta real (na pasta partilhada) e \verb|| o diretório onde se quer criar o atalho (ROS \emph{workspace}). \begin{figure}[H] \centering \includegraphics[width=0.75\textwidth]{nfs.png} \caption{Esquema da partilha de ficheiros usando NFS\cite{nfs}} \label{fig:nfs} \end{figure} %\subsection{Compilação Cruzada} \subsection{Controlo remoto} De modo a facilitar o acesso a todas as máquinas presentes, propõe-se o uso de \textit{Secure Shell} (SSH) que é um protocolo de rede criptográfica que permite o acesso remoto a várias máquinas de forma segura \cite{ssh}. Este controlo remoto tem muita utilidade pois permite fazer o lançamento de um nodo nodo de uma unidade específica sem haver necessidade de se ligar um monitor. No entanto, como o número de unidades computacionais pode ser elevado e de forma a agilizar o processo de \textit{login} desenvolveu-se um \textit{script} que abre um novo terminal referente a cada máquina que estiver definida (listagem \ref{lst:script1}). \begin{lstlisting}[language=bash, caption=\emph{Script} usado para fazer a inicialização das unidades remotas no computuador principal, label={lst:script1}] #!/bin/sh echo Inicializando Raspberry Pi 1 gnome-terminal -x sshpass -p password ssh -Y rpi1@192.168.1.10 echo Inicializando Raspberry Pi 2 gnome-terminal -x sshpass -p password ssh -Y rpi2@192.168.1.11 \end{lstlisting} Para facilitar a visualização de alguma interface gráfica referente a algum nodo, a inicialização da comunicação SSH é feita com o parâmetro \verb|-Y|, permitindo assim que as interfaces gráficas possam ser visualizadas num computador remoto. Ainda para facilitar o \textit{setup} das várias unidades computacionais, foi desenvolvido um \textit{script} específico que faz a inicialização de todos os processos necessários, incluindo a declaração das variáveis de ambiente para a comunicação (listagem \ref{lst:script2}). \begin{lstlisting}[language=bash, caption=Exemplo de \emph{script} usado para na inicialização das unidades remotas, label={lst:script2}] #!/bin/sh echo Definindo as variáveis de ambiente export ROS_MASTER_URI=http://192.168.1.1:11311 export ROS_IP=192.168.1.11 \end{lstlisting} \subsection{\textit{Launch file} geral} De forma a fazer a inicialização de todos os nodos distribuídos por vários Raspberry Pi's é possível criar um \textit{launch file} que realiza o lançamento de nodos em máquinas remotas. Para isto é necessário criar dois \textit{launch files} na unidade computacional principal: \begin{itemize} \item Um referente a que nodo tem de ser executado na unidade computacional remota. Esta tem de mencionar o nome do nodo e respetivo \textit{package} a executar. Na listagem \ref{lst:rpi12} encontra-se o ficheiro \verb|rpi1.launch|, que é uma \emph{launch file} referente a um nodo denominado por \verb|demo_node|. \item O outro ficheiro é também um \textit{launch file} onde é referido qual o \emph{launch file} que tem de ser executado na máquina remota. Na fistagem \ref{lst:rpi1} está um exemplo de um \textit{launch file} que pretende executar o \verb|rpi1.launch| na máquina com o utilizador "rpi1". \end{itemize} \vspace{20pt} \begin{lstlisting}[language=XML, caption=\emph{Launch file} para a execução do nodo \texttt{demo\_node}, label={lst:rpi12}] \end{lstlisting} \begin{lstlisting}[language=XML, caption=\emph{Launch file} que permite fazer o lançamento do ficheir \texttt{rpi1.launch} numa unidade remota, label={lst:rpi1}] \end{lstlisting} % ---------------------------------------------------------------- % Corpo da tese % ---------------------------------------------------------------- \chapter{Ambiente de simulação} Neste capítulo descrevem-se os passos executados para a obtenção do ambiente de simulação, desde a definição do \gls{URDF} do robô até à sua visualização no simulador. \section{Definição do robô} \label{description} Para a criação do ambiente de simulação a primeira etapa a ser executada é a realização de algo que consiga descrever todo o robô. Deste modo, foi criado o modelo em \gls{URDF} que permite definir o robô, e onde se encontra a sua forma geométrica bem como o tipo de juntas que o compõem. Para o robô em questão, pode ser encontrado na figura \ref{fig:urdfgraph} um esquema das diversas partes que o compõem assim como as ligações entre elas. \begin{figure} \centering \includegraphics[width=1\textwidth]{myrobot.pdf} \caption{Diagrama do URDF do robô gerado usando a ferramenta \texttt{urdf\_to\_graphiz}} \label{fig:urdfgraph} \end{figure} Os diversos componentes que compõem a plataforma tiveram de ser criados/adaptados recorrendo à modelação 3D, neste caso usando o \textit{software} SolidWorks (figura \ref{fig:solidworks}). Nesta definição do robô é possível definir quais as propriedades dos diversos componentes, tais como a massa e propriedades inerciais, permitindo assim ao simulador realizar uma simulação o mais realista possível. \begin{figure} \centering \subfloat[][]{\includegraphics[scale=0.35]{Capturar1.PNG}\label{signal_model2}} \subfloat[][]{\includegraphics[scale=0.35]{Capturar2.PNG}\label{amplitude_mod3}} \subfloat[][]{\includegraphics[scale=0.35]{Capturar3.PNG}\label{amplitude_mod2}} \caption{Componentes criados para em SoliWorks \protect\subref{signal_model} Chassis \protect\subref{amplitude_mod} Jante \protect\subref{amplitude_mod2} Pneu} \label{fig:solidworks} \end{figure} Ainda, para a definição do robô é necessário implementar o tipo de controlador que a plataforma terá de ter. Neste sentido, o Gazebo possui um \textit{plugin} que permite integrar o controlo de uma plataforma \textit{skid-steering}. Para a sua integração é necessário identificar quais os nomes das juntas correspondentes a cada roda, qual a distância entre rodas e o seu diâmetro, o torque máximo, nome dos tópicos onde o Gazebo irá publicar certas informações como odometria, e qual o nome do tópico que terá as informações para o robô ser comandado. Na listagem \ref{lst:label} pode ser encontrado um excerto de código referente à implementação do \emph{plugin}. No total, para a definição do robô foram elaborados quatro ficheiros descritos seguidamente: \begin{itemize} \item \verb|macros.xacro| - Neste ficheiro estão definidas as macros usadas ao longo da definição do robô; \item \verb|materials.xacro| - Aqui são definidas macros relacionadas com as propriedades dos materiais, como por exemplo a cor; \item \verb|mybot.gazebo| - Neste ficheiro são definidos os \textit{plugins} do Gazebo utilizados; \item \verb|mybot.xacro| - Aqui são definidas todas as partes do robô assim como o tipo de juntas que existe entre elas. \end{itemize} \begin{lstlisting}[language=XML, caption=Definição do \textit{plugin} referente a plataformas \textit{Skid-steering}, label={lst:label}] 100.0 front_left_rim_hinge front_right_rim_hinge back_left_rim_hinge back_right_rim_hinge 0.7 0.175 chassis 5.0 20 cmd_vel odom odom 1 \end{lstlisting} \section{Integração no Gazebo} Para se proceder à visualização do robô no Gazebo é necessário a criação de um ficheiro \verb|.launch| (listagem \ref{lst:gazebo}). Este ficheiro irá definir qual será a configuração do ambiente envolvente através da definição de um ficheiro apropriado, e inclui também a localização do ficheiro com o \gls{URDF} assim como algumas configurações iniciais para o Gazebo. \begin{lstlisting}[language=XML, caption=\textit{Launch file} para a execução do Gazebo com o modelo da plataforma, label={lst:gazebo}] \end{lstlisting} Para a definição de todo a ambiente envolvente, com o qual o robô pode interagir, tem de se criar primeiramente utilizando o Gazebo um ficheiro que terá todas as informações acerca do mesmo, desde os objetos existentes e fontes de luz. Posteriormente, pode ser gravado um ficheiro \verb|.world| que será chamado pelo \textit{launch file}. Após a execução do ficheiro \verb|.launch| o Gazebo é executado, obtendo-se o resultado visualizado na figura \ref{fig:nardogazebo}. \begin{figure}[H] \centering \includegraphics[width=0.8\textwidth]{gazebosim.png} \caption{Visualização do robô no Gazebo} \label{fig:nardogazebo} \end{figure} De forma a testar se o modelo do robô está operacional para a comunicação com o ROS realizou-se a publicação de uma mensagem de velocidade no tópico \verb|/cmd_vel|, correspondendo então ao movimento do robô virtual. \section{Integração de sensores} Para fins de teste, foram adicionados alguns sensores à plataforma de modo a observar os diversos resultados. Para tal, a sua adição passou por dois passos. Primeiramente a adição da parte geométrica do sensor no ficheiro \verb|mybot.xacro|, onde se indica as suas dimensões, forma, inércia e espaço de colisão, e qual a sua posição relativamente ao robô. Posteriormente é necessário indicar qual o tipo de sensor que se pretende simular, sendo então necessário integrar o respetivo \textit{plugin} no ficheiro \verb|mybot.gazebo|, onde se indica os tópicos onde os dados serão publicados assim como as suas características. \iffalse Na figura \ref{fig:nardosensor} encontra-se o resultado da adição de um sensor laser na plataforma NARDO. \begin{figure} \centering \includegraphics[width=0.6\textwidth]{nardosensor.png} \caption{Implementação de um senor laser na plataforma virtual NARDO} \label{fig:nardosensor} \end{figure} \fi \section{Interação com Rviz} \label{state} Para complementar todo o ambiente de simulação é importante existir um visualizador onde seja possível observar o resultado da simulação. No caso em questão recorreu-se ao Rviz. Assim, criou-se um\textit{ launch file} que permite a inicialização do visualizador para o caso do robô utilizado. Posteriormente, na interface do Rviz é necessário proceder à adição do robô e dos restantes dados que se quer visualizar, como por exemplo os dados de um laser. Ainda no \textit{launch file}, são executados dois nodos, o \verb|joint_state_publisher| e o \verb|robot_state_publisher|. Em relação ao \verb|joint_state_publisher| este irá ver todo o ficheiro \gls{URDF} encontrando todas as juntas existentes e para aquelas que não são fixas publicará valores de juntas. Por outro lado, o \verb|robot_state_publisher| é responsável por fazer uma leitura do estado das juntas do robô e fará a publicação do seu estado da forma de ROS \verb|tf|, que poderá posteriormente ser usada para ver o estado as juntas do robô no Rviz.\cite{mastering} Na listagem \ref{lst:label2} pode ser observada a \emph{launch file} utilizada. \begin{lstlisting}[language=XML, caption=Ficheiro \texttt{mybot\_rviz.launch} usado para a execução do Rviz,label={lst:label2}] \end{lstlisting} \vspace{15pt} Na figura \ref{fig:nardorviz} pode observar-se o resultado dos valores lidos por um laser simulado no Rviz. \begin{figure} \centering \subfloat[][]{\includegraphics[scale=0.16]{rviz1.png}\label{signal_model}} \subfloat[][]{\includegraphics[scale=0.172]{rviz2.png}\label{amplitude_mod}} \caption{\protect\subref{signal_model} Simulação em Gazebo da plataforma na presença de alguns objetos \protect\subref{amplitude_mod} Visualização em Rviz dos dados lidos pelo laser\cite{c4}} \label{fig:nardorviz} \end{figure} \section{Resultado final} Para a obtenção do ambiente de simulação foi necessário criar alguns \emph{packages} \gls{ROS}. Os packages criados são os seguintes: \begin{itemize} \item \verb|Description| - Neste \textit{package} estam presentes os ficheiros que descrevem o robô (\gls{URDF}), e ficheiros necessários para a definição da forma de partes do robô. A launch file que é usada para a visualização no Rviz também se encontra neste \textit{package}. \item \verb|Gazebo| - Aqui encontram-se os \textit{launch files} que permitem correr a simulação em Gazebo, assim como os ficheiros com a configuração do mundo. \end{itemize} No esquema \ref{fig:dirtree} pode ser visualizado todo o esquema de ficheiros utilizado para a simulação. \begin{center} \begin{figure} \centering \begin{forest} for tree={ font=\ttfamily, grow'=0, child anchor=west, parent anchor=south, anchor=west, calign=first, edge path={ \noexpand\path [draw, \forestoption{edge}] (!u.south west) +(2.5pt,0) |- node[fill,inner sep=1.25pt] {} (.child anchor)\forestoption{edge label}; }, before typesetting nodes={ if n=1 {insert before={[,phantom]}} {} }, fit=band, before computing xy={l=15pt}, } [src/ [Gazebo/ [launch/ [{\color{red}mybot.launch}] ] [worlds/ [{\color{red}mybot.world}] ] [{\color{blue}CMakeLists.txt}] [{\color{blue}package.xml}] ] [Description/ [launch/ [{\color{blue}mybot\_rviz.launch}] ] [meshes/ [chassis.stl] [wheel.stl] [rim.stl] ] [urdf/ [macros.xacro] [materials.xacro] [{\color{red}mybot.gazebo}] [mybot.xacro] ] [{\color{blue}CMakeLists.txt}] [{\color{blue}package.xml}] ] ] \end{forest} \caption{Esquema de ficheiros final para o ambiente de simulação virtual, estando a azul os ficheiros somente utilizados pelo ROS, a vermelhos os ficheiros somente usados pelo Gazebo, e os que são usados por ambos a preto} \label{fig:dirtree} \end{figure} \end{center} No final da implementação deste ambiente de simulação obtém-se um esquema dos nodos e tópicos final como o representado na figura \ref{fig:simgraph}. Aqui podem ser observados os tópicos publicados pelo laser (\verb|/mybot/laser/scan|), tópicos publicados pelo Gazebo (\verb|/tf|), assim como dos nodos do \verb|joint_state_publisher| e \verb|robot_state_publisher| descritos na secção \ref{state}. \begin{figure} \centering \includegraphics[width=1\textwidth]{simgraph.png} \caption{Diagrama dos nodos e tópicos para o caso do ambiente de simulação} \label{fig:simgraph} \end{figure} % ---------------------------------------------------------------- % Corpo da tese % ---------------------------------------------------------------- \chapter{Uma aplicação ilustrativa} Este capítulo descreve a aplicação realizada de forma a testar as soluções propostas. Essa aplicação assenta na simulação do seguimento de uma linha com uma câmara virtual em Gazebo. \section{Aplicação proposta} \label{ap} De forma a testar o sistema distribuído de ROS, propõe-se o desenvolvimento de uma aplicação usando os Raspberry Pi's e o simulador desenvolvido. A aplicação proposta é baseada no seguimento de uma linha que será detectada com o recurso a uma câmara. No entanto, é adicionado o fator humano à aplicação por intermédio de um comando \textit{joystick}, onde as ordens vindas deste terão prioridade perante as anteriores. Quando as mensagens oriundas do comando deixarem de existir o robô iniciará a procura da linha e posterior guiamento através da mesma. Deste modo é possível ter diversas unidades computacionais a funcionar ao mesmo tempo, estando uma dedicada a fazer o processamento da imagem da câmara, outro dedicado ao comando que é manipulado por uma pessoa, e por fim outra unidade onde será realizada a simulação. \section{Desenvolvimento} \subsection{Criação do ambiente com a pista} Para a realização da aplicação proposta teve-se de realizar a modelação da pista, tendo sido desenvolvido um ficheiro do tipo COLLADA utilizando o \emph{software} SketchUp (figura \ref{fig:sketchup}). Utilizando este tipo de ficheiro, propriedades como a cor mantém-se em comparação com um ficheiro \gls{STL}, permitindo que o ficheiro inclua o desenho da linha a seguir. \begin{figure} \centering \includegraphics[width=0.6\textwidth]{sketchup.png} \caption{Pisda criada no \emph{software} SketchUp} \label{fig:sketchup} \end{figure} Para a criação da trajetória a seguir pela plataforma optou-se por algo realizado de forma genérica, mas onde se incluem várias formas como retas e curvas com diferentes curvaturas. O resultado final pode ser observado na figura \ref{fig:traj}. Nos limites da pista é colocada uma parede de forma a evitar que a plataforma os passe. \begin{figure} \centering \includegraphics[width=0.6\textwidth]{pista.png} \caption{Visualização da pista visualizada no Gazebo} \label{fig:traj} \end{figure} De forma a visualizarmos a pista no simulador, procedeu-se à criação do ficheiro \verb|.world| e o \textit{launch file} respetivo. \subsection{Alterações efetuadas à plataforma} Para a realização da aplicação proposta foi necessário adicionar novos sensores à descrição da plataforma. Para tal adicionou-se uma câmara para fazer a detecção da linha, e um scanner laser para detetar os limites da pista criada. Para a adição da câmara fez-se a edição de alguns dos ficheiros mencionados na secção \ref{description}. Primeiramente, no ficheiro \verb|mybot.xacro| é necessário definir o seu aspeto visual, assim como propriedades inerciais e colisões. Posteriormente, no ficheiro \verb|mybot.gazebo| é feita a definição do \emph{plugin} do Gazebo que permite realizar a captura da imagem e respetiva publicação num tópico \gls{ROS}, neste caso o \verb|libgazebo_ros_camera.so|. Para aumentar o nível de semelhança entre o cenário virtual e a realidade foi adicionado um ruído à imagem extraída através da câmara. Para o caso do scanner laser, o procedimento efetuado foi semelhante ao da câmara, tendo-se usado o \textit{plugin} \verb|libgazebo_ros_gpu_laser.so| para fazer a simulação do laser, no qual se definem propriedades como os limites de alcance e resolução do laser. \subsection{Arquitetura da aplicação} Para o desenvolvimento da aplicação foram desenvolvidos quatro nodos distintos. \subsubsection{line\_node} A função principal deste nodo é realizar o tratamento da imagem proveniente da câmara e dar as respetivas ordens de movimento à plataforma. A primeira operação a realizar neste nodo é realizar o tratamento da imagem que é publicada num tópico. Para isto recorre-se ao package \verb|cv_bridge| que permite a conversão entre imagens ROS e imagens OpenCV. Ao fim de se ter a imagem no formato OpenCV realiza-se o seu tratamento de forma a que no final se obtenha uma imagem binarizada e onde apenas a linha a seguir seja reconhecida. Posteriormente ao tratamento de imagem admite-se que a plataforma pode estar entre dois estados, numa situação em que a linha é perfeitamente visualizada pela plataforma e outro onde o robô não reconhece/visualiza a linha. No primeiro caso a estratégia adotada para fazer o seguimento da linha baseia-se em encontrar um ponto central e superior da linha e verificar qual a sua distância para o centro da imagem. Com base nesta distância recorreu-se à aplicação de um controlador PID que faz o ajuste da velocidade angular a aplicar à plataforma consoante a distância em \emph{pixels} entre o centróide e o centro da imagem. No caso de a plataforma se encontrar perdida, esta começa a andar aleatoriamente e quando deteta na imagem uma parte correspondente à linha a plataforma começa a aproximar-se da mesma e quando está sobre a linha a plataforma começa a rodar sobre si própria de forma a alinhar-se com a linha. Quando se encontra totalmente alinhada a plataforma entra no estado descrito anteriormente. Por fim, os valores de velocidades calculados para os diferentes estados são publicados no tópico \verb|/nardo/line_vel|. Todos os procedimentos do código podem ser observados no algoritmo \ref{alg:the_alg}. \begin{megaalgorithm} [H] \caption{Algoritmo para o seguimento da linha com base na imagem recebida pela câmara} \label{alg:the_alg} \begin{algorithmic}[1] \STATE Tratamento de imagem com base em binarizações \label{op0} \STATE Análise da imagem binarizada \label{op1} \If{imagem vazia}{ $state = 1$} \eIf{$state = 1$ }{ \eIf{imagem vazia}{ Andar em frente\; }{ \eIf{Primeira e última coluna da imagem $\neq$ 0}{ \eIf{Centróide do objeto em y menor que metade da altura da imagem}{ Plataforma anda em frente}{ Plataforma roda sobre si\; \If{Primeira e última linha da imagem $\neq$ 0}{ $state = 0$} } }{ Plataforma anda em direção ao objeto detetado na imagem\; } } }{ Encontrar centróide na linha numa parte superior\; Cálculo da diferença em $x$ para o centro da imagem\; Aplicação do PID para cálculo da velocidade angular\; Publicação da velocidade final no respetivo tópico\; } \end{algorithmic} \end{megaalgorithm} \begin{figure} \centering \includegraphics[width=0.5\textwidth]{linefinal.png} \caption{Visualização da linha e deteção do centróide} \label{fig:line_img} \end{figure} No algoritmo ~\ref{alg:the_alg} está descrito o procedimento para a análise da imagem e respetivas ordens de controlo. \subsubsection{joy\_node} Como descrito na secção \ref{ap}, para realizar o controlo da plataforma manualmente é usando um \textit{gamepad}. Deste modo é necessário criar um nodo que seja responsável pela aquisição dos seus dados e posterior tratamento. Para proceder à aquisição dos dados é usado o \textit{package} \verb|joy| \cite{joy} que publica o estado de todas as componentes do comando no tópico \verb|/joy|. De modo a converter os dados recebidos em uma mensagem para o controlo da plataforma, é então criado o nodo \verb|joy_node| que fará a leitura dos dados publicados no tópico \verb|/joy|. Para a definição da velocidade linear é usado o \emph{joystick} esquerdo, enquanto que para a velocidade angular é usado o \emph{joystick} direito (figura \ref{fig:gamepad}). Para ambas as velocidades, o seu valor é proporcional ao deslocamento do joystick dado pelo utilizador, sendo as mensagens publicadas no tópico \verb|/nardo/joy_vel|. No diagrama da figura \ref{fig:joy} estão exemplificados as etapas executadas por este nodo sempre que é pressionado um botão no \emph{gamepad}. \iffalse De forma a alertar quando é que o comando está a ser utilizado, é necessário pressionar o botão \texttt{RB} publicando no tópico \verb|/nardo/joy_alert| uma mensagem booleana com esta informação. \fi \begin{figure} \centering \begin{tikzpicture} \node [anchor=west, align=right] (note) at (-2.5,5) { Controlo da \\ velocidade linear}; \node [anchor=west, align=left] (note2) at (+8,3.9) { Controlo da \\ velocidade angular}; \begin{scope}[xshift=1.5cm] \node[anchor=south west,inner sep=0] (image) at (0,0) {\includegraphics[width=0.4\textwidth]{xbox.jpg}}; \begin{scope}[x={(image.south east)},y={(image.north west)}] %\draw [-latex, ultra thick, red] (note) to[out=0, in=-120] (0.48,0.80); \draw [-stealth, line width=3pt, blue] (note) -- (0.25,0.68); \draw [-stealth, line width=3pt, blue] (note2) -- (0.62,0.52); \end{scope} \end{scope} \end{tikzpicture} \caption{Publicação de tópicos e respetiva visualização entre os Raspberry Pi's e o computador} \label{fig:gamepad} \end{figure} \begin{figure} \centering \begin{tikzpicture}[node distance = 3cm, auto] % Place nodes \node [cloud] (init) { Início}; \node [block, below of=init, node distance=2cm] (first) {\begin{varwidth}{15em}Velocidade linear = Valor lido no joystick esquerdo $\times$ Velocidade linear máxima\end{varwidth}}; \node [block, below of=first, node distance=2cm] (second) {\begin{varwidth}{15em}Velocidade angular = Valor lido no joystick direito $\times$ Velocidade angular máxima\end{varwidth}}; \node [block, below of=second, node distance=2cm] (third) {\begin{varwidth}{15em}Publicação da velocidade final no tópico \texttt{/nardo/joy\_vel}\end{varwidth}}; \node [cloud, below of=third, node distance=2cm] (forth) {Fim}; % Draw edges \path [line] (init) -- (first); \path [line] (first) -- (second); \path [line] (second) -- (third); \path [line] (third) -- (forth); \end{tikzpicture} \caption{Diagrama da estrutura da \emph{callback} usada quando são recebidos dados do \emph{gamepad}} \label{fig:joy} \end{figure} \subsubsection{laser\_node} De forma a precaver a existência de colisões foi então criado um nodo que faz a leitura dos dados obtidos pelo scanner laser dando um alerta quando a plataforma se encontra numa situação de emergência, ou seja quando a plataforma se está a aproximar dos limites da pista. Esta situação de emergência é atuada quando a distância mínima que o laser reconhece é menor que 40 centímetros, resultando na publicação de uma mensagem segundo o formato booleano no tópico \verb|/nardo/laser|, correspondendo o valor \verb|0| ao estado de emergência (algoritmo \ref{alg:the_alg2}). \begin{megaalgorithm} \caption{Algoritmo usado no tratamento dos dados lidos pelo laser} \label{alg:the_alg2} \begin{algorithmic}[1] \STATE Deteção do menor valor lido pelo laser \label{op0} \STATE Análise do menor valor \label{op1} \\ \eIf{Menor valordlido pelo laser $\leq$ 0.4 }{ Estado de emergência\;} { Estado normal\; } \end{algorithmic} \end{megaalgorithm} \subsubsection{decision\_node} Como descrito anteriormente, são publicadas várias mensagens que visam o controlo da plataforma, no entanto é necessário decidir quando é que cada uma o deve fazer. Para isto, é criado o nodo \verb|decision_node| que tem como objetivo interpretar as mensagens publicadas pelos três nodos descritos anteriormente, resultando numa mensagem final que controla a plataforma. Assim, este nodo pode estar em três estados. O estado padrão é quando a plataforma na rotina referente ao seguimento da linha, onde estão os dados recebidos no tópico \verb|/nardo/line_vel| são transpostos para a mensagem de controlo da plataforma, \verb|/nardo/cmd_vel|. O seguinte estado possível é quando a plataforma está a ser comandada pelo \textit{gamepad} e então as mensagens de controlo a enviar para a plataforma são iguais às enviadas pelo nodo \verb|joy_node|. Por último, o terceiro estado é ativado quando a plataforma encontra-se em estado de emergência, tendo este estado prioridade sobre qualquer outro. Quando este estado é ativado são dadas ordens à plataforma para rodar 180 graus sobre si própria e andar em frente. Para a realização destes movimentos são enviados comandos de movimento para a plataforma até percorrer o movimento desejado, usando os dados recebidos pelo tópico \verb|/odom| para verificar o estado do robô. Interligando todos os nodos mencionados anteriormente, obtêm-se os diagramas demonstrados na figura \ref{fig:app}, onde estão representadas as várias \emph{callbacks} e a estrutura do programa principal. \vspace{5pt} A estrutura final da aplicação pode ser consultada na figura \ref{fig:app2}, onde é possível observar todos os nodos e tópicos utlizados. \begin{figure} \centering \subfloat[][]{\begin{tikzpicture}[node distance = 3cm, auto] % Place nodes \node [cloud] (init) { joyCallback}; \node [block, below of=init, node distance=2cm] (first) {\begin{varwidth}{12em}Publicação das mensagens vindas do tópico \texttt{/nardo/joy\_vel}\end{varwidth}}; \node [decision, below of=first, node distance=3cm] (second) {\begin{varwidth}{12em}Velocidade \\ = 0?\end{varwidth}}; \node [block, below of=second, node distance=3cm] (third) {status = 1}; \node [block, below of=third, node distance=2cm] (forth) {Fim}; % Draw edges \path [line] (init) -- (first); \path [line] (first) -- (second); \path [line] (second) -- node {Sim} (third); \path [line] (third) -- (forth); \path [line] (second.east) -- node {Não} ++(1cm,0) |- (forth); \end{tikzpicture} \label{f1}} \qquad \qquad \subfloat[][]{\begin{tikzpicture}[node distance = 3cm, auto] % Place nodes \node [cloud] (init) { laserCallback}; \node [block, below of=init, node distance=2cm] (first) {\begin{varwidth}{13em}Plataforma roda sobre si própria\end{varwidth}}; \node [block, below of=first, node distance=3cm] (second) {\begin{varwidth}{13em}Plataforma move-se um metro linearmente\end{varwidth}}; \node [block, below of=second, node distance=3cm] (third) {status = 1}; \node [block, below of=third, node distance=2cm] (forth) {Fim}; % Draw edges \path [line] (init) -- (first); \path [line] (first) -- (second); \path [line] (second) -- (third); \path [line] (third) -- (forth); \end{tikzpicture}\label{f2}} \qquad \qquad \subfloat[][]{\begin{tikzpicture}[node distance = 3cm, auto] % Place nodes \node [cloud] (init) { lineCallback}; \node [decision, below of=init, node distance=2cm] (first) {\begin{varwidth}{13em}status \\ == 1?\end{varwidth}}; \node [block, below of=first, node distance=2.7cm] (second) {\begin{varwidth}{13em}Publicação das mensagens vindas do tópico \texttt{/nardo/line\_vel}\end{varwidth}}; \node [block, below of=second, node distance=2cm] (third) {Fim}; % Draw edges \path [line] (init) -- (first); \path [line] (first) -- node {Sim} (second); \path [line] (second) -- (third); \path [line] (first.east) -- node {Não} ++(1cm,0) |- (third); \end{tikzpicture}\label{f3}} \qquad \qquad \subfloat[][]{\begin{tikzpicture}[node distance = 3cm, auto] % Place nodes \node [cloud] (init) { Início}; \node [block, below of=init, node distance=2.5cm] (first) {\begin{varwidth}{13em}Definição das \emph{callbacks} \begin{itemize} \item joyCallback \item laserCallback \item lineCallback \end{itemize} \end{varwidth}}; \node [decision, below of=first, node distance=3.5cm] (second) {\begin{varwidth}{13em}Main Loop\end{varwidth}}; % Draw edges \path [line] (init) -- (first); \path [line] (first) -- node {Sim} (second); \path [line] (second.south) -- ++(0cm,-0.5cm) -- ++(1.5cm,0) |- (second); \end{tikzpicture}\label{f4}} \caption{(a) Callback acionada quando é recebido uma mensagem no tópico \texttt{/nardo/joy\_vel} (b) Callback acionada quando é recebido uma mensagem relativa a uma situação de emergência (c) Callback acionada quando a é recebido uma mensagem no tópico \texttt{/nardo/line\_vel} (d) Estrutura geral do programa } \label{fig:app} \end{figure} \begin{sidewaysfigure} \centering \includegraphics[width=0.8\textwidth]{rosgraph.png} \caption{Diagrama do nodos e tópicos da aplicação final} \label{fig:app2} \end{sidewaysfigure} \section{Resultados finais} Após o desenvolvimento da aplicação, é realizado o teste de todo o sistema. Para tal, distribuem-se os diferentes nodos pelos Raspberry Pi's a utilizar. Para os testes realizados recorre-se a um computador pessoal onde é executado o simulador, o \verb|decision_node| e o \verb|joy_node|. São usados dois Raspberry Pi's, um da versão 3 executa o \verb|laser_node|, e um da versão 2 que processa o \verb|line_node|. Esta disposição pode ser consultada na figura \ref{fig:netfinal} e \ref{fig:netfinal2}. \begin{figure} \centering \begin{tikzpicture} \node [anchor=west] (note) at (-1.5,1.5) { Raspberry Pi's}; \node [anchor=west] (note3) at (-1.5,2.5) { Switch}; \node [anchor=west] (note2) at (+10.5,4) { Computador}; \begin{scope}[xshift=1.5cm] \node[anchor=south west,inner sep=0] (image) at (0,0) {\includegraphics[width=0.6\textwidth]{final.jpg}}; \begin{scope}[x={(image.south east)},y={(image.north west)}] %\draw [-latex, ultra thick, red] (note) to[out=0, in=-120] (0.48,0.80); \draw [-stealth, line width=3pt, blue] (note) -- (0.12,0.2); \draw [-stealth, line width=3pt, blue] (note) -- (0.28,0.22); \draw [-stealth, line width=3pt, blue] (note3) -- (0.18,0.4); \draw [-stealth, line width=3pt, blue] (note2) -- (0.94,0.66); \end{scope} \end{scope} \end{tikzpicture} \caption{Ilustração com o sistema todo} \label{fig:netfinal} \end{figure} \begin{figure} \centering \begin{tikzpicture} \node [anchor=west] (note) at (-0.5,5) { (a)}; \node [anchor=west] (note2) at (+12.5,4) { (b)}; \node [anchor=west] (note3) at (+12.5,1) {(d)}; \node [anchor=west] (water) at (-0.5,1) {(c)}; \node [anchor=west] (note4) at (-0.5,3) {(e)}; \begin{scope}[xshift=1.5cm] \node[anchor=south west,inner sep=0] (image) at (0,0) {\includegraphics[width=0.68\textwidth]{demo.png}}; \begin{scope}[x={(image.south east)},y={(image.north west)}] \draw[red,ultra thick] (0.48,0.31) rectangle (0,0); \draw[blue,ultra thick] (0.48,0.66) rectangle (0,0.32); \draw[yellow,ultra thick] (0.48,1) rectangle (0,0.66); \draw[green,ultra thick] (1,0.48) rectangle (0.49,0); \draw[orange,ultra thick] (1,1) rectangle (0.49,0.49); %\draw [-latex, ultra thick, red] (note) to[out=0, in=-120] (0.48,0.80); \draw [-stealth, line width=3pt, yellow] (water) -- (0,0.15); \draw [-stealth, line width=3pt, blue] (note) -- (0,0.81); \draw [-stealth, line width=3pt, orange] (note2) -- (1,0.66); \draw [-stealth, line width=3pt, green] (note3) -- (1,0.15); \draw [-stealth, line width=3pt, blue] (note4) -- (0,0.49); \end{scope} \end{scope} \end{tikzpicture} \caption{Publicação de tópicos e respetiva visualização entre os Raspberry Pi's e o computador; (a)Execução do simulador no Gazebo; (b) Execução do \texttt{laser\_node} num Raspberry Pi; (c) Execução do \texttt{joy\_node} no computador; (d) Execução do \texttt{line\_node} num Raspberry Pi; (e) Execução do \texttt{decision\_node} no computador} \label{fig:netfinal2} \end{figure} De forma a poder-se visualizar se o controlo da plataforma é realizado convenientemente, fez-se a visualização da trajetória percorrida no \verb|Rviz|. Para o caso do percurso de toda a linha no mapa, obtem-se o resultado obtido na figura \ref{fig:line_rviz}, que comparando com a trajetória da pista demonstrada na figura \ref{fig:traj} pode-se aferir que se encontram bastante semelhantes, estando também presente na mesma imagem a trajetória que a plataforma executa quando encontra a linha. O gráfico da figura \ref{fig:path} demonstra qual o módulo da variação em \emph{pixles} entre um ponto no centro da linha e o centro da imagem da câmara segundo a direção horizontal, ao longo do percurso da plataforma pela linha. \begin{figure} \centering \begin{tikzpicture} \node [anchor=west] (note) at (-0.5,5) { (a)}; \node [anchor=west] (note2) at (+12.5,4) { (b)}; \begin{scope}[xshift=1.5cm] \node[anchor=south west,inner sep=0] (image) at (0,0) {\includegraphics[width=0.68\textwidth]{find.png}}; \begin{scope}[x={(image.south east)},y={(image.north west)}] \draw[blue,ultra thick] (0.48,0.12) rectangle (0.7,0.45); %\draw [-latex, ultra thick, red] (note) to[out=0, in=-120] (0.48,0.80); \draw [-stealth, line width=3pt, blue] (note) -- (0.48,0.3); \draw [-stealth, line width=3pt, orange] (note2) -- (0.94,0.66); \end{scope} \end{scope} \end{tikzpicture} \caption{(a) Trajetória de aproximação à linha (b) Trajetória percorrida pelo robô no seguimento da linha} \label{fig:line_rviz} \end{figure} \begin{figure} \centering \includegraphics[width=0.8\textwidth]{graph.png} \caption{Gráfico gerado usando a ferramenta \texttt{rqt\_plot} com a variação da distância em módulo entre o centro da imagem e o centróide da linha} \label{fig:path} \end{figure} % ---------------------------------------------------------------- % Corpo da tese - Parte V - Conclusoes % ---------------------------------------------------------------- \chapter{Conclusões e trabalho futuro} \section{Conclusões} No âmbito desta dissertação foram realizadas diversas tarefas. Começou-se inicialmente por fazer o controlo em malha fechada dos motores da plataforma NARDO, sendo para tal necessário a instalação de \textit{encoders} e a realização da sua leitura. Para a leitura dos \textit{encoders} foi desenvolvido um sistema com um microcontrolador dedicado a esta tarefa que posteriormente transmite os dados a outro microcontrolador principal para o seu processamento. Em relação ao controlo em malha fechada foi implementado um controlador PID que recebe as velocidade desejadas da plataforma. Importa referir que apesar de se ter chegado a umas constantes para o controlador estas foram testadas com a plataforma em suspensão, pelo que será necessário realizar novamente a afinação dos parâmetros quando a plataforma for colocada em contacto com o solo. O uso da solução apresentada verificou-se adequada. O sistema distribuído de ROS foi desenvolvido com sucesso verificando-se que é possível fazer a comunicação entre as várias unidades computacionais. A par deste sistema, foram ainda desenvolvidas algumas ferramentas que permitem uma melhor facilidade de desenvolvimento tais como a partilha de ficheiros entre as diversas unidades e também uma solução para o controlo remoto das diversas unidades. Posteriormente, devido à ocorrência de problemas num dos motores da plataforma que impediu o seu uso, optou-se por criar um ambiente de simulação para realizar testes. Este ambiente foi desenvolvido usando o simulador Gazebo que permite a interação com o ROS. Assim, criou-se o modelo completo da plataforma com a adição de sensores. Pode-se concluir que o simulador utilizado satisfez as necessidades requeridas permitindo a interação com o robô e meio envolvente. Por último, foi realizada uma aplicação que permite o teste de todas as componentes desenvolvidas. Nesta aplicação foram colocados vários nodos distribuídos por Raspberry Pi's, sendo então possível verificar que é possível ter um sistema de ROS distribuído a realizar o controlo de uma plataforma \emph{skid-steering}, embora apenas tenha sido realizado no ambiente virtual. Em suma, com a solução desenvolvida é possível prever que esta pode ser útil para diversas aplicações tais como o controlo de robôs. É de salientar a modularidade que este tipo de solução pode trazer pois permite com facilidade que seja adicionado um novo sensor ou funcionalidade a um robô. \section{Trabalho futuro} Após a realização deste trabalho ficam ainda abertas outras opções de trabalho a realizar no futuro: \begin{enumerate} \item \textbf{Compilação cruzada} Uma das funcionalidades que se sugere que seja adicionada a todo o sistema distribuído de ROS é a possibilidade de se fazer compilação cruzada do código desenvolvido num computador pessoal. Desta forma permitimos que não seja necessário fazer a compilação de código no Raspberry PI, reduzindo assim o tempo de compilação. \item \textbf{Teste do sistema distribuído num robô real} Após a validação do sistema distribuído de ROS usando o ambiente de simulação, sugere-se que este seja consequentemente testado numa plataforma real, permitindo assim provar que a comunicação com o hardware é realizada com sucesso. Isto permite ainda verificar se o simulador desenvolvido consegue corresponder ao que realmente acontece na realidade. \item \textbf{Implementação de novos motores e respetivo controlo da plataforma} Como um dos motores da plataforma se encontra inoperacional é necessário proceder à sua substituição. Posteriormente será necessário adaptar os valores dos controladores PID para ambos os motores. Posteriormente ao controlo dos motores será necessário realizar o controlo por parte da unidade computacional, ou seja, criar um nodo ROS que permita receber comandos de velocidade e converter para uma mensagem que seja compreendida pelo controlador dos motores, por exemplo de uma mensagem do tipo Twist para as velocidades que cada roda tem que ter. Para isto, será necessário aplicar as equações cinemáticas da plataforma. \iffalse \item \textbf{Criação de nodo ROS para o controlo da odometria} De forma a se poder realizar a um controlo do estado da plataforma para um posterior uso, sugere-se a criação de um nodo ROS que permite receber os dados vindos dos encoders e estes serem posteriormente analisados. Pode-se converter estes mesmos dados em \verb|tf's| para se poder ver os estados das juntas do robô no Rviz. \fi \end{enumerate} % ---------------------------------------------------------------- % Referências bibliográficas - Base de dadods % ---------------------------------------------------------------- \cleardoublepage \sloppy \nocite{*} \printbibliography % ---------------------------------------------------------------- % Fim do documento % ---------------------------------------------------------------- \end{document}