Relatório pedrocastro 2012_2013_v1

Centro de Tecnologia da Informação Renato Archer
Programa Institucional de Bolsas de Iniciação Científica – Pibic/CNPq
Divisão de Robótica e Visão Computacional – jun/2011
1
Centro de Tecnologia da Informação Renato Archer - CTI
Divisão de Robótica e Visão Computacional - DRVC
Relatório Final de Iniciação Científica
Familiarização e uso do Arcabouço ROS no projeto
VERO
Pedro Corrêa Bueno de Castro
Orientador: Helio Azevedo
Julho de 2013

2
Conteúdo
1 - Resumo............................................................................................................................................................3
2 - Introdução......................................................................................................................................................3
2.1 - Motivação....................................................................................................................................................3
2.1.1 - Objetivo - O projeto VERO................................................................................................................3
2.1.2 - O arcabouço ROS ..................................................................................................................................4
2.1.3 - Conceitos ROS........................................................................................................................................4
2.1.4 - Arquitetura do veículo .........................................................................................................................5
3 - Materiais e métodos .....................................................................................................................................6
3.1 - Materiais .....................................................................................................................................................6
3.2 - Desenvolvimento .......................................................................................................................................6
3.2.1 - Implementação do Algoritmo RANSAC .........................................................................................7
3.2.2 - Driver do Pan Tilt C46 - 17 para ROS ..........................................................................................10
3.2.3 - Organização do Startup do VERO .................................................................................................11
4 - Resultados ...................................................................................................................................................13
5 - Conclusão....................................................................................................................................................14
6 - Referências Bibliográficas .......................................................................................................................14

3
1 - Resumo
O projeto VERO visa desenvolver um veiculo robótico terrestre, autônomo, com
aplicações que se estendem desde a área militar até mapeamentos geográficos em
diferentes modalidades (ambientais, agrícolas, minerais, entre outras).
Para alcançar esse objetivo é necessário criar um sistema de software robusto e capaz
de processar informações de diversos sensores e de comandar o veículo com base
nesses dados. Uma forma eficiente de se fazer isso é utilizando um arcabouço que
permita a comunicação entre todos os programas de controle e a criação de um
sistema organizado e robusto. Inicialmente o arcabouço selecionado foi o ORCA [2],
mas em 2012, esse arcabouço foi descontinuado, direcionando a seleção para o
arcabouço ROS [3].
O presente trabalho visa a familiarização com o novo arcabouço robótico, denominado
ROS, para a criação de drivers para sensores e a implementação de algoritmos de
controle. Uma vez que a fase de familiarização com o arcabouço tenha sido concluída é
possível focar na organização do sistema de software do veiculo criando uma interface
de fácil utilização para que novos desenvolvedores possam se concentrar em suas
aplicações e não em como utilizar a plataforma de desenvolvimento.
2 - Introdução
2.1 - Motivação
O desenvolvimento de sistemas autônomos é de grande importância para a formação
de tecnologia necessária para impulsionar um país e sua presença é notória, nos mais
diversos aspectos da vida moderna, desde sensores e controladores em geladeiras até
em veículos automotores. Dentro dessa perspectiva é de especial interesse o domínio
de veículos autônomos com aplicações que se estendem desde a área militar até
mapeamentos geográficos em diferentes modalidades.
A DRVC/CTI busca em uma de suas linhas de pesquisa o desenvolvimento e a
implementação de soluções em robótica móvel para diversos ambientes (terrestre,
aquático e aéreo).
2.1.1 - Objetivo - O projeto VERO
O sistema Veículo Robótico[1] é uma das atividades da linha de pesquisa
“Desenvolvimento e Aplicação de Veículos Robóticos com Graus de Autonomia
Crescente” da Divisão de Robótica e Visão Computacional do CTI.
O projeto Veículo Robótico foca na construção de um robô móvel para ambientes
externos. Veículos robóticos terrestres de exterior locomovem-se comumente usando
rodas, em diferentes configurações de tração e direção. Se por um lado modelos
cinemáticos e leis de controle já estão relativamente bem estabelecidas, existem
ainda, nessa área, desafios científicos e tecnológicos quando se trata do uso desses
veículos em campo (i.e. sujeitos a inclinações, escorregamentos, efeitos dinâmicos da
interação veículo-terreno, etc.) e, mais ainda, no que concerne à percepção e
navegação autônoma e robusta em ambiente não estruturado de exterior.

4
Neste contexto, o projeto VERO propõe uma plataforma robótica, caracterizada pelo
veículo em si e pela infraestrutura robótica associada, destinada a suportar a pesquisa
e desenvolvimento em robótica terrestre de exterior autônoma (Figura 1).
Figura 1: Veículo robótico VERO
2.1.2 - O arcabouço ROS
ROS [3] (Sistema Operacional Robótico) fornece bibliotecas e ferramentas que auxiliam
na criação de aplicações robóticas. Ele fornece abstração de hardware, drivers para
dispositivos, bibliotecas, ferramentas para vizualização e envio de informações,
gerenciamento de pacotes, e mais. ROS é licenciado sobre uma licença open source, a
BSD.
O arcabouço ROS foi escolhido como novo arcabouço do projeto devido a sua enorme
gama de bibliotecas e o grande número de grupos de pesquisa, usuários e até
empresas privadas que compartilham pacotes no site do arcabouço, aumentando e
melhorando a qualidade das bibliotecas e principalmente compartilhando o
conhecimento para que desenvolvedores ao redor do mundo avancem no âmbito do
software robótico mais rapidamente.
2.1.3 - Conceitos ROS
Todos os programas que utilizam o arcabouço ROS precisam de uma certa organização
para funcionarem corretamente, esta organização consiste na criação de alguns
arquivos e pastas e na definição de algumas formas de comunicação que juntos
organizarão os programas criados. Segue a definição de conceitos básicos de
organização:
Pacote: Pacotes são o nível mais baixo de organização de software ROS. Eles podem
conter qualquer coisa: bibliotecas, ferramentas, executáveis, etc. Um pacote é
organizado da seguinte forma:
 Manifest.xml: Arquivo contento todas as dependências ROS do pacote atual. É
através deste arquivo que o ROS saberá onde encontrar as bibliotecas e
headers que se encontram em outros pacotes.

5
 CMakeLists.txt: Arquivo utilizado pela ferramenta rosmake (ferramenta
utilizada para compilar pacotes ROS), nele é feita a definição dos executáveis,
das bibliotecas e das mensagens que serão compiladas do pacote, além da
inclusão de bibliotecas que não estão dentro de outros pacotes (como
bibliotecas do sistema).
 Pasta src/: Embora não seja obrigatório, é recomendado que todo código fonte
fique dentro desta pasta, com o intuito de padronizar e organizar os pacotes.
 Pasta include/: Embora não seja obrigatório, é recomendado que todos os
headers fiquem dentro desta pasta, principalmente quando o pacote contem a
implementação de uma biblioteca, porque desta forma é possível exportar
apenas o diretório dos headers para os pacotes que dependem deste pacote.
 Pasta msg/: Este é o diretório padrão para a definição de mensagens
customizadas. O ROS permite a implementação de mensagens de forma muito
simples, basta definir os nomes e tipos das variáveis em um arquivo de texto
que o rosmake se encarrega de gerar todo o código necessário para a criação
das mensagens.
Stack: Stacks são conjuntos de pacotes que juntos formam uma biblioteca. Uma stack
é organizada da seguinte forma:
 Stack.xml: Arquivo contento todas as dependências ROS da stack atual. É
através deste
 arquivo que o ROS saberá onde encontrar as bibliotecas e headers que se
encontram em outros pacotes.
 CMakeLists.txt: Arquivo utilizado pela ferramenta rosmake (ferramenta
utilizada para compilar pacotes ROS), nele é feita a definição dos executáveis,
das bibliotecas e das mensagens que serão compiladas do pacote, além da
inclusão de bibliotecas que não estão dentro de outros pacotes (como
bibliotecas do sistema).
 Pastas dos Pacotes: Cada pacote pertencente à stack fica dentro de uma pasta
com o nome do pacote.
Node: Um node é uma aplicação que utiliza o ROS para se comunicar com outros
nodes.
Mensagem: Mensagens são utilizadas por nodes para comunicação, uma mensagem é
basicamente uma estrutura de dados com alguns campos de informação pré-definidos.
Tópicos: Um tópico é um canal de comunicação, através de um tópico um node pode
receber e enviar mensagens.
O sistema de organização do ROS possiblita desenvolvedores a criar sistemas robóticos
robustos, bem organizados e independentes. Mais informações sobre as formas de
organização podem ser encontradas no site do arcabouço [3].
2.1.4 - Arquitetura do veículo
O veículo de testes possui diversos sensores e três CPUs para controle e
processamento dos dados. Cada sensor gera dados que são processados pelos nodes
ROS. Os dados obtidos pelos sensores permitem um controle preciso da posição e da
rota do veículo, além de antecipar e prever colisões com o meio. A organização e as
formas de comunicação física dos sensores são representadas na Figura 2.

6
Figura 2: Arquitetura Computacional do VERO
3 - Materiais e métodos
3.1 - Materiais
Na realização dos testes apresentados neste trabalho foram utilizados:
 Plataforma robótica Pioneer 3DX
 Pan Tilt modelo C46 - 17
Figura 3: Plataforma Robótica Pioneer 3DX
3.2 - Desenvolvimento
O objetivo do trabalho consiste no projeto, implementação e teste de módulos para o
arcabouço ROS considerando a instanciação realizada no veiculo robótico da DRVC.

7
Neste cenário foram implementados três módulos:
 Implementação do sistema RANSAC
 Geração de driver para ROS para controle para pantilt modelo C46 - 17
 Organização do startup do VERO
Os próximos itens detalham cada uma dessas implentações.
3.2.1 - Implementação do Sistema RANSAC
Motivação
O projeto RANSAC foi primeiramente idealizado para uma aplicação no âmbito agrícola
ao permitir que o veículo se locomova entre pés de café. Tal sistema de software
utiliza apenas os dados recebidos pelo sensor Hokuyo que são as distancias entre ele e
os objetos ao seu redor. A partir dos dados brutos, são criadas retas que melhor
representam os lados esquerdo e direito com relação ao próprio sensor e uma reta
bissetriz é criada. Utilizando algoritmos de controle o veículo se locomove seguindo
esta reta conforme novas retas são geradas ao longo de sua trajetória. Vale ser
ressaltado que os testes feitos foram primeiramente efetuadas em uma plataforma
Pioneer entre os corredores da própria instituição por motivos de praticidade e
segurança. A descrição deste módulo são baseados nos testes efetuadas neste cenário.
A ferramenta de visualização, rxgraph, disponiblizada pelas bibliotecas do ROS
apresenta em forma de um grafo orientado os nós se comunicando por meio de um
tópico específico conforme o tipo de mensagem envolvida nesta comunicação. A
seguir, a Figura 4 mostra os nós do sistema RANSAC.
Figura 4: grafo do sistema RANSAC criado por meio da ferramenta rxgraph
Node Hokuyo_node
No projeto, primeiramente, foi utilzado o package Hokuyo_node, driver responsável
pelo controle do sensor Hokuyo Laser range-finder, modelo utilizado: UTM-30LX. Este
node publica em três tópicos onde o /scan representa os dados coletados pelo sensor
cujas mensagens consistem basicamente em um vetor de pontos. Cada ponto é
apresentado como uma distancia e um ângulo num formato aderente a representação
de ponto por coordenadas polares. Informações adicionais como lista de tópicos
publicados e descrição completa das mensagens enviadas podem ser encontradas no
link: http://www.ros.org/wiki/hokuyo_node

8
Node P2os_driver
O stack p2os provê driver compatível com qualquer robô que utilize o firmware P2OS
ou ARCOS. O package p2os_driver é o driver para o Pioneer usado como um ROS node.
Ele subscreve a tópicos relacionados ao controle como o /cmd_vel que recebe
mensagens contendo velocidades linear e angular. Os tópicos em que este publica
estão relacionados ao estado dos componentes que o compõem. O tópico /pose
recebe mensagens de odometria utilizadas por outros nós para saber a velocidade
tanto linear quanto angular em que o robô esta executando. Informação sobre os
pacotes que compõem o stack assim como lista de informações sobre as mensagens e
tópicos envolvidos são encontrados no link: http://ros.org/wiki/p2os?distro=electric
Node TF
Por último, há o node tf_broadcaster, do package TF, que executa uma transformação
estática de coordenadas e publica no tópico /tf, já que os pontos coletados pelo sensor
Hokuyo tem que estar em relação ao sistema de coordenadas do robô. Descrição do
pacote, sua utilização assim como tutoriais podem ser encontrados no link:
http://www.ros.org/wiki/tf
O algoritmo RANSAC
No pacote ransac_project construído, há os nodes ransac e ransac_control que
compõem o sistema de controle de trajetória e o dataplot, utilizado apenas para
visualização dos dados.
Node ransac
Primeiro, o ransac subscreve ao tópico /scan. Quando mensagens chegam ao tópico
um callback
(http://www.ros.org/wiki/roscpp/Overview/Callbacks%20and%20Spinning) é ativado e
recebe os dados brutos coletados do sensor Hokuyo e os transforma em coordenadas
cartesianas considerando a mudança do sistema de coordenadas entre o sensor e o
robô provida do tf_bradcaster, sendo que o frame do robo é denominado por vero e o
laser por hokuyo. Depois estes pontos são refinados, coletando-se apenas aqueles que
estão dentro da janela de valores permitidos para (x,y) . Em seguida, são separados
entre pontos da esquerda e da direita. Lembrando que o sistema de coordenadas
padrão do ROS segue a regra da mão direita e que o eixo x segue a direção e sentido
do robô, logo, valores com ângulos positivos estão à esquerda e negativos à direita.
Uma função do pacote MRPT [4] (Mobile Robot Programming Toolkit), chamada
ransac_detect_2D_lines, aproxima uma nuvem de pontos 2D para um conjunto de
retas possíveis retornado uma delas, assim foram construídas as retas da esquerda e
da direita. O nó, portanto, publica as duas linhas encontradas e os vetores de pontos
(x,y) no tópico /ransac_lines.
Há três parâmetros fundamentais ao ransac, sem os quais este fica impossibilitado de
executar.

9
 Threshold: utilizado pela função ransac_detect_2D_lines, é a distancia mínima
entre um ponto e um possível reta tal que este ponto é considerado um inlier.
 P_inliers: também utilizado pela função ransac_detect_2D_lines, é o numero
mínimo de inliers para que um reta possa ser considerada.
 DataWidth: define a que distancia pontos lidos pelo Hokuyo serão utilizados
sendo que esta sendo considerado uma largura de um vez o dataWidht para
esquerda e uma vez para a direita e de três vezes para frente.
Além destes, há o parâmetro windowPlot, opcional, que cria uma tela de visualização
dos pontos refinados e das linhas esquerda e direita formadas.
Node ransac_control
Em seguida, as linhas esquerda e direita serão coletadas pelo ransac_control que
subscreve aos tópicos /ransac_lines e /pose, este último referente à odometria do
Pioneer. Quando o spinning é realizado, à medida que mensagens vão chegando, cada
callback será ativado e irá tratar os dados correspondentes. O callback referente ao
tópico /pose simplesmente atualiza a variável que guarda a velocidade angular em que
o robô está executando.
O callback responsável pelas mensagens vindas do node ransac irá construir uma reta
bissetriz a estas duas retas e aplicar um controle PID que forneça uma velocidade
angular para que o robô se mantenha sobre a bissetriz. Este processo pode publicar
tanto mensagens ao tópico de controle do robô Pioneer, /cmd_vel, quanto do VERO,
/car_command, fazendo ajustes necessários. A velocidade linear se mantém constante
em ambos os casos e para o VERO, a velocidade angular é convertida em um ângulo
para que a mensagem possa ser enviada. Além do tópico referente ao comando, o
node publica a reta bissetriz construída em /bisec_data.
Por último, tem-se o node dataplot, que subscreve aos tópicos /ransac_lines e
/bisec_data. Assim, utilizando funções de visualização da biblioteca MRPT, é possível
observar os pontos (x,y) escolhidos, as retas esquerda e direita formadas e a bissetriz
atualizados conforme os dados são atualizados.
Há sete parâmetros fundamentais ao ransac, sem os quais este fica impossibilitado de
rodar.
 which_car: seleciona para qual plataforma será utilizada o sistema visto que as
mensagens publicadas para o comando do VERO e do Pioneer são diferentes.
 V_linear: é a velocidade linear que será constante tanto para o VERO quanto
para o Pioneer.
 Lenght: é a distancia entre eixos do VERO
 DataWidth: define a que distancia pontos lidos pelo Hokuyo serão utilizados
sendo que esta sendo considerado uma largura de um vez o dataWidht para
esquerda e uma vez para a direita e de três vezes para frente.
 Os outros quatro parâmetros são referentes ao controle PID, são eles: KPT, KIT,
KVT e KRT. O detalhamento destes parâmetros foge ao escopo deste texto.
Assim como o ransac, há o parâmetro windowPlot, opcional, que cria uma tela de
visualização dos pontos refinados e das linhas esquerda e direita formadas além da
bissetriz produzida.

10
3.2.2 - Driver do Pan Tilt C46 - 17 para ROS
Motivação
O projeto foi realizado visando a implementação e testes de algoritmos na área de
Visão Computacional utilizando primeiramente a plataforma Pioneer e uma câmera.
Para tanto era preciso um dispositivo que realizasse os movimentos necessários para
que a câmera se movimentasse. O Pan Tilt foi então escolhido e era necessária a
integração deste hardware com o sistema ROS.
O pacote PTU46_driver cria, basicamente, um wrapper do driver disponibilizado pela
biblioteca MRPT.
Primeiramente, com o objetivo de compreender melhor a implementação do módulo
é preciso ter o conhecimento do sistema de coordenadas do ROS. O eixo X é orientado
para frente, o Y para a esquerda e Z para cima. Por exemplo, seja um robô se
orientando no espaço sua representação espacial tem direção e sentido sempre sobre
o eixo X. Tal representação é comumente chamada de "Regra da Mão Direita".
A partir deste conceito, há dois eixos de rotação do Pan Tilt. O eixo Z denominado Pan
e o eixo Y, denominado Tilt.
Node PTU46_driver
O driver tem como entrada velocidades angulares a partir do tópico /PTU46_cmd que
recebe mensagens do tipo Twist. Como foi explicado anteriormente, a componente Z
se refere à velocidade angular do Pan e a do eixo Y à velocidade angular do Tilt.
A saída consta da orientação atual do dispositivo. As mensagens do tipo Pose, por
meio do tópico /PTU46_orientation, mostra a orientação por um quaternion e a
velocidade angular corrente. Além disso, é enviado mensagens do tipo Twist para o
tópico /PTU46_velocity especificando as velocidades angulares referentes aos dois
eixos.
Há ainda um terceiro tópico que o driver publica mensagens. As transformações entre
os eixos e a representação espacial do hardware é publicado no tópico /tf. Este tópico
é fundamental para a visualização dos dados.
O software fica em um loop infinito esperando as mensagens vindas do tópico
/PTU46_cmd e recebidas na função de callback suas velocidades atualizadas. Por meio
de funçôes da biblioteca MRPT, estes comandos são enviados ao dispositivo após o
devido tratamento das mensagens recebidas. No próprio callback, são enviadas as
mensagens para os tópicos publicados. As velocidades atualizadas são publicadas via
mensagens Twist e após a transformação da orientação para a representação em
quaternion são publicas as mensagens Pose.
Em relação ao /tf, há o frame PanTilt_base sendo a base fixa do dispositivo servindo
como referência para as posteriores transformações. A primeira transformação ocorre
do PanTilt_base para o base_PanTilt_arm onde é realizada uma translação fixa
decorrente da forma física do aparelho e uma translação dinâmica circular ao redor do
eixo Z dado o movimento Pan. Em seguida, uma rotação ao redor do eixo Z também é
realizada fazendo com que a componente X do frame base_PanTilt_arm esteja sempre

11
tangenciando a trajetoria circular. Quando há uma comando para de velocidade para o
Tilt, ocorre uma rotação ao redor do eixo Y do base_PanTilt_arm para o PanTilt_arm.
O frame base_PanTilt_arm foi criado apenas por questôes operacionais e não é
efetivamente utilizado, assim os frames que representam os movimentos do
dispositivo são o PanTilt_base e o PanTilt_arm.
O sistema ROS disponibiliza uma ferramenta de visualização extremamente útil
chamada Rviz(ROS vizualization), com ela é possivel observar o posicionamento
corrente dos eixos de rotação em relação à base do Pan Tilt.
Figura 5: visualização dos frames do Pan Tilt por meio da ferramenta Rviz
3.2.3 - Organização do Startup do VERO
Motivação
O VERO possui vários sensores já modelados no sistema ROS e muitos deles com
parâmetros a serem definidos pelo usuário quando são inicializados. A tarefa de iniciar
cada sensor na sua devida máquina embarcada ou remota configurando
separadamente seus atributos é uma tarefa passível de automatização.
A ferramenta roslaunch é utilizada pelo sistema ROS para inicializar múltiplos nós
localmente ou remotamente via SSH assim como configurar parâmetros no Servidor de
Parâmetros.
Portanto, foi criado um pacote denominado sensors que agrupa todos os arquivos tipo
launch dos sensores envolvidos, o arquivo mestre e outros tipos de arquivo que
auxiliam na inicialização e serão detalhados em seguida.
A imagem a seguir mostra de forma simplificada os nós envolvidos dos sensores do
veículo. Grande parte dos tópicos foram omitidas já que seu grande número dificulta a
visualização e compreensão do grafo.

12
Figura 6: Grafo dos sensores do VERO criado por meio da ferramenta rxgraph
Arquivos launch
O arquivo mestre, ou seja, responsável por iniciar todo o sistema de sensores é
mostrado na figura a seguir.
Figura 7: arquivo sensors.launch
Este launch carrega os arquivos roslaunch dos sensores envolvidos por meio da tag
include. São importados todas as configurações dos arquivos XML de cada sensor. As
modificações dos parâmetros podem ser feitas no launch mestre visto que este se
encontra em um escopo de mais alto nível. Por exemplo, o veículo contém dois
sensores de distância Hokuyo e ambos, por padrão, publicam no tópico /scan. Por isso,
na importação dos arquivos destes sensores os tópicos são mapeados por meio da tag
remap para outros nomes como /scan_hokuyo_inferior e /scan_hokuyo_superior.
Os pacotes dos sensores Sick, da câmera e dos dois Hokuyos são disponibilizados pela
comunidade do ROS assim foi apenas necessário criar o arquivo XML para cada sensor.
Os outros pacotes foram implementados por bolsistas e pesquisadores da DRVC e
alguns já continham arquivos launch básicos e poucas modificações tiveram que ser
feitas para integrá-los ao sistema.
Na figura 7, pode-se observar que um arquivo com extensão machine é carregado
antes de todos os sensores. Este arquivo declara todas as máquinas utilizadas pela
aplicação onde os nós rodam. Assim por meio de uma tag machine, cada XML
especifica qual máquina aquele sensor será inicializado.

13
Figura 8: arquivo camera.launch
A figura 8 exemplifica o uso da tag machine. O arquivo é responsável por inicializar a
câmera sendo que há três nodes envolvidos. Os dois primeiros são o driver e o
processamento das imagens brutas, portanto estes nós devem rodar na máquina
conectada fisicamente com a câmera, que como pode ser observado, ela tem o nome
EMBSYS0. O terceiro nó é a visualização das imagens geradas que é obviamente
especificado para ser inicializado no computador offboard onde se encontra o usuário,
denominado no caso de verot.
Este arquivo também exemplifica bem como são definidos os atributos nos arquivos de
extensão launch. Os nomes dos parâmetros estão especificados nas documentações
de cada node criado e a partir deles é possível dar-lhes valores.
É importante notar que os nomes dos frames de todos os sensores devem sempre ser
explicitamente configurados por meio de parâmetros para que seja criado uma árvore
de transformações e os dados coletados por cada sensor seja passível de visualização
por meio de ferramentas como o Rviz.
Os arquivos XML têm muitas especificidades e uma gama extensa de aplicações. A
sintaxe completa se encontra no link: http://www.ros.org/wiki/roslaunch/XML
O pacote sensors criado contendo os arquivos launch dos sensores utilizados é
detalhado no repositório:
http://paranhos.cti.gov.br/svn/VERO/trunk/implementacao/fontes/ros_workspace/
4 - Resultados
O primeiro sistema, o RANSAC, teve como resultado a implentação e teste do pacote
sobre a plataforma Pionner pelos corredores da DRVC. A visualização dos dados foi
coerente e o algoritmo mostrou-se muito eficiente visto que o robô movimentou-se
pelo corredor sem trepidações mantendo-se constantemente sobre a bissetriz criada a
partir dos pontos coletados. A imagem a seguir mostra a coleta de dados mostrando as
os pontos observados, as retas esquerda e direita e a sua bissetriz formada.
Lembrando que devido ao sistema de coordenadas do ROS, o robô se direciona pelo
eixo X. Os pontos em verde no plano superior são os pontos coletados pelo sensor
Hokuyo e definidos pelo software como pontos à esquerda do Pioneer e os pontos em
magenta à direita. A partir deles é possível ver as retas criadas e a bissetriz formada.

14
Figura 9: Dados coletados do sistema RANSAC
O segundo sistema, o driver do Pan Tilt foi testado com o auxílio de um joystick por
meio dos botões analógicos e os comandos foram interpretados como se esperava
pelo dispositivo. Os frames são observados em tempo real por meio da ferramenta de
visualização Rviz como é apresentado na Figura 5.
Finalmente, o projeto do startup do VERO organiza os pacotes de forma concisa e
mesmo desenvolvedores sem experiência em ROS conseguem iniciar o sistema de
sensores do veículo de forma prática e novos módulos são facilmente incluídos e
atualizados.
5 - Conclusão
Os sistemas aqui apresentados criam muitas oportunidades de novos testes e para o
desenvolvimento de aplicações baseados nos trabalhos realizados. O projeto RANSAC
ainda não foi testado no cafezal como foi idealizado ou em regiões com maior
dificuldade de orientação para observar sua eficácia e ou possíveis melhoramentos.
Em relação ao startup do VERO, o veículo ainda não operou com o Applanix ou com o
GPS ligados devido a problemas técnicos. Portanto, é interessante fazer uma coleta
com todos os sensores ativos e gravar estes dados para posteriormente observá-los
com o Rviz.
O driver do Pan Tilt pode ser integrado com a câmera sobre o Pioneer com o objetivo
de implementar aplicações de planejamento de trajetórias baseadas em Visão
Computacional assim como inúmeras outras aplicações.
6 - Referências Bibliográficas
[1] Bueno, S.S.; Azevedo, H; Mirisola, L.G.B.; de Paiva, E.C.; Ramos, J.J.G.; Victorino,
A.C.; Azinheira, J.R. (2009). Uma Plataforma para Pesquisa e Desenvolvimento em
Robótica Terrestre de Exterior, IX Simp. Bras. de Automação Inteligente, (SBAI),
Brasilia, DF.
[2] Orca (2013). http://orca-robotics.sourceforge.net/
[3] Ros (2013): http://www.ros.org/wiki/
[4] MRPT: http://www.mrpt.org/

Relatório pedrocastro 2012_2013_v1

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Relatório pedrocastro 2012_2013_v1

Semelhante a Relatório pedrocastro 2012_2013_v1 (20)

Relatório pedrocastro 2012_2013_v1