do arquivo - Programa de Pós

Transcrição

UNIVERSIDADE FEDERAL DA BAHIA
ESCOLA POLITÉCNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
Anderson Amorim do Nascimento
ANÁLISE DE SISTEMAS DE AQUISIÇÃO DE IMAGENS
OMNIDIRECIONAIS PARA NAVEGAÇÃO EM ROBÓTICA
MÓVEL
DISSERTAÇÃO DE MESTRADO
Salvador
Outubro de 2015
Página em branco
ANÁLISE DE SISTEMAS DE AQUISIÇÃO DE IMAGENS
OMNIDIRECIONAIS PARA NAVEGAÇÃO EM ROBÓTICA
MÓVEL
Dissertação de Mestrado apresentada ao
Programa de Pós-graduação em Engenharia
Elétrica, PPGEE, da Universidade Federal
da
Bahia,
como
parte
dos
requisitos
necessários à obtenção do tı́tulo de Mestre
em Engenharia Elétrica.
Orientador: Paulo César Machado de Abreu
Farias
Salvador
Outubro de 2015
Agradecimentos
Este trabalho foi o resultado sofrido de perı́odos de otimismo e esperança intercalados por longos vales de desânimo e incerteza. Como deve acontecer em qualquer
outra pesquisa, houveram altos e baixos de produtividade que determinaram o ritmo
do trabalho. Os altos foram importantes para a coleta de resultados, a elaboração
de experimentos, a implementação de protótipos e para a revisão literária, mas foi
o apoio que eu recebi durante os perı́odos de inércia que garantiram a finalização.
É justamente este apoio que eu, correndo o risco imperdoável de deixar alguém de
fora, quero agradecer neste espaço.
Agradeço inicialmente aos meus pais, meu porto seguro, que sustentaram o sonho e esperaram com tanta paciência para que eu acordasse para a vida e tivesse
um pouco mais fé no futuro. Agradeço ao meu irmão por perguntar quase que diariamente quando seria a data da minha defesa. Agradeço ao meu orientador, Paulo
César, por não me deixar desistir algumas vezes e por me lembrar “que a vida às vezes nos prega peças, mas com paciência a gente resolve tudo”. Agradeço aos colegas
de trabalho não só pelas conversas longas e improdutivas sobre assuntos aleatórios,
mas também pela companhia solidária tanto nas horas produtividade quanto nas
de procrastinação. Finalmente, com carinho especial e uma gratidão que não cabe
em “trocentas” dissertações de mil páginas, agradeço à minha noiva, Ludmila, à
quem eu também dedico esta dissertação. Agradeço por ela estar ao meu lado todo
este tempo, desde o primeiro pixel capturado, vibrando mais do que eu em cada
resultado, torcendo mais do que eu à cada novo “robozinho” e sonhando, também
mais do que eu, com o desfecho disso tudo. Este trabalho é tão seu quanto meu,
meu bem. Obrigado.
iii
Resumo da Dissertação apresentada à PPGEE/UFBA como parte dos requisitos
necessários para a obtenção do grau de Mestre em Engenharia Elétrica (M.Sc.)
ANÁLISE DE SISTEMAS DE AQUISIÇÃO DE IMAGENS OMNIDIRECIONAIS
PARA NAVEGAÇÃO EM ROBÓTICA MÓVEL
Outubro/2015
Orientador: Paulo César Machado de Abreu Farias
Programa: Engenharia Elétrica
Sistemas de visão omnidirecional são ferramentas extremamente úteis para
aplicações de navegação em Robótica. Tarefas de localização, rastreamento de objetos e detecção de obstáculos podem ser beneficiadas por um campo de visão omnidirecional. O campo de visão estendido reduz o número necessário de observações
do espaço ao redor do robô e permite que obstáculos e objetos de interesse fiquem
visı́veis por mais tempo. Uma desvantagem destes sistemas, porém, é o custo computacional dos algoritmos envolvidos na manipulação de imagens, o que pode limitar
a sua aplicação em dispositivos embarcados de pequeno porte. Para contornar esta
limitação, uma alternativa comum é incorporar elementos de alto nı́vel ao sistema,
como servidores e computadores pessoais. Esta abordagem, no entanto, pode elevar consideravelmente os custos do projeto, além de aumentar a sua complexidade.
Outra estratégia é adaptar os algoritmos utilizados para dispositivos especializados
de baixo custo, como o Raspberry Pi e a CMUCam, distribuindo o processamento
entre eles. Neste modelo, as formas de interligação e distribuição de carga entre
os diferentes componentes são os principais problemas de projeto e também os que
mais limitam do seu desempenho. Este trabalho concentra esforços na análise de
iv
arquiteturas embarcadas de pequeno porte para aquisição e manipulação de imagens omnidirecionais. O objetivo é estabelecer modelos de arquitetura que sejam
capazes de capturar imagens omnidirecionais e realizar tarefas básicas de navegação
autônoma sobre elas. Cada modelo é um sistema fechado de navegação por visão
computacional, podendo ser integrado á um robô móvel por meio de um protocolo
simples de comunicação. O sistema captura, analisa e entrega ao robô um conjunto
de coordenadas de movimentação, posicionamento e localização. São apresentados
e comparados três modelos de arquitetura, cada um representando uma das formas
tradicionais de aquisição de imagens omnidirecionais: câmera giratória (monocular), várias câmeras disposta em cı́rculo (multicâmeras) e arranjo câmera/espelho
(catadióptrico). Os protótipos para avaliação foram construı́dos utilizando câmeras
CMUCam3 para captura e pré-processamento das imagens e um Raspberry Pi B,
para processamento e execução dos algoritmos de detecção de obstáculos, localização
e rastreamento de objetos de interesse. Os tempos de aquisição e processamento de
um panorama omnidirecional são os principais parâmetros de desempenho avaliados
em cada arquitetura.
v
Abstract of Dissertation presented to PPGEE/UFBA as a partial fulfillment of the
requirements for the degree of Master of Science (M.Sc.)
ANALYSIS OF OMNIDIRECTIONAL IMAGES ACQUISITION SYSTEMS FOR
MOBILE ROBOT NAVIGATION
October/2015
Advisor: Paulo César Machado de Abreu Farias
Department: Electrical Engineering
Omnidirectional vision systems are extremely useful tools for autonomous robot
navigation. The wide field of view can help the robot to move more efficiently
between obstacles, demanding fewer observations of the scene. Additionally, visual marks and other interesting objects stay longer inside the field of view, which
are important features for some navigation tasks, such as Localization and Object
Tracking. However, these systems require some high cost algorithms for image processing, which are difficult to run in small embedded applications. Some approaches
try to solve this problem by incorporating high level components into their systems,
such as personal computers and servers. This strategy may, however, increase the
financial costs of the project and limit their applications. Another approach focuses
on distributing task pieces over different small and specialized hardware, such as
CMUCam and Raspberry Pi. Nevertheless, on this strategy the many ways of interconnection and load distribution among its components may be a limiting point
for the system, if not analyzed carefully.
This work focus on the analysis of embedded architecture models for acquiring
and manipulating omnidirectional images for robot navigation problems. Our goal
is to define interconnection models between the embedded components for acquiring
vi
omnidirectional panoramas and performing basic navigation tasks with them. Each
model is a closed computer vision navigation system, which can be further integrated
to mobile robots with a simple communication protocol. The systems process omnidirectional panoramas and deliver moving coordinates or localization status to the
robot. Three architecture models are presented, one for each traditional way of acquiring omnidirectional images: a single rotating camera covering a field of view of
360 degrees, multiple cameras placed on a circle, each one covering a fraction of the
omnidirectional field of view, and a catadioptric model with camera and an spherical
mirror. The prototypes were built using CMUCam3 cameras for image capturing
and a Raspberry Pi B for image processing. The acquisition and processing times
are the main parameter used for evaluating each model’s performance.
vii
Sumário
Lista de Figuras
x
Lista de Tabelas
xiii
1 Introdução
1.1
1
Sistemas de Navegação Autônoma em Robótica Móvel
. . . . . . . .
2
1.1.1
Visão Computacional para Navegação . . . . . . . . . . . . . .
6
1.1.2
Sistemas de Visão Omnidirecional . . . . . . . . . . . . . . . .
8
1.1.3
Desafios de Implementação . . . . . . . . . . . . . . . . . . . .
9
1.2
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3
Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . 12
2 Navegação por Visão Computacional
2.1
2.2
14
Algoritmos de Navegação por Visão Computacional . . . . . . . . . . 16
2.1.1
Identificação de Obstáculos . . . . . . . . . . . . . . . . . . . 16
2.1.2
Rastreamento de Objetos
2.1.3
Localização e Mapeamento . . . . . . . . . . . . . . . . . . . . 23
. . . . . . . . . . . . . . . . . . . . 18
Sistema de Navegação . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1
Arquitetura do Sistema de Navegação . . . . . . . . . . . . . . 27
2.2.2
Modelo de Navegação . . . . . . . . . . . . . . . . . . . . . . . 29
3 Aquisição de Imagens Omnidirecionais
33
3.1
Concatenação de Segmentos (Image Stitching) . . . . . . . . . . . . . 34
3.2
Remapeamento (Dewarping) . . . . . . . . . . . . . . . . . . . . . . 38
4 Análise de Modelos de Aquisição
4.1
42
Caracterização dos Componentes de Aquisição e Processamento . . . 43
viii
4.2
4.1.1
CMUCam3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.2
Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.3
Análise dos Resultados da Caracterização
. . . . . . . . . . . 51
Aquisição de Panoramas Omnidirecionais . . . . . . . . . . . . . . . . 52
4.2.1
Arquitetura Monocular . . . . . . . . . . . . . . . . . . . . . . 53
4.2.2
Arquitetura Multicâmeras . . . . . . . . . . . . . . . . . . . . 55
4.2.3
Arquitetura Catadióptrica . . . . . . . . . . . . . . . . . . . . 61
4.2.4
Comparação dos Modelos de Aquisição . . . . . . . . . . . . . 62
5 Experimentos de Navegação
66
5.1
Cenário e Protótipo de Navegação . . . . . . . . . . . . . . . . . . . . 68
5.2
Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3
Caracterização para Odometria . . . . . . . . . . . . . . . . . . . . . 71
5.4
Rastreamento de Objetos . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5
Mapeamento Incremental . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.6
5.5.1
Detecção de Obstáculos . . . . . . . . . . . . . . . . . . . . . 81
5.5.2
Planejamento de Rota . . . . . . . . . . . . . . . . . . . . . . 83
5.5.3
Resultados de Mapeamento . . . . . . . . . . . . . . . . . . . 83
5.5.4
Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Localização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.6.1
Treinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.6.2
Reconhecendo o Nó Inicial . . . . . . . . . . . . . . . . . . . . 90
5.6.3
Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6 Conclusões
94
6.1
Resumo de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.2
Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.3
Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.4
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Referências Bibliográficas
102
A Trabalhos Publicados
112
ix
Lista de Figuras
2.1
Procedimento de detecção de obstáculos por diferenciação da cor do
solo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2
Procedimento de detecção de objetos por threshold de uma cor especı́fica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3
Algoritmo de Limiarização de imagens para detectar um objeto de
cor especı́fica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4
Algoritmo de detecção de objetos utilizando detecção de features. . . 22
2.5
Detecção de objetos por comparação de features. . . . . . . . . . . . . 23
2.6
Estratégias de mapeamento de um ambiente interno. . . . . . . . . . 24
2.7
Divisão geral de arquitetura.
2.8
Sequência de comunicação entre o Raspberry Pi e o tijolo Lego NXT
2.9
Representação do veı́culo em um plano de navegação . . . . . . . . . 30
. . . . . . . . . . . . . . . . . . . . . . 27
29
2.10 Representação do Centro Instantâneo de Curvatura (C.I.C.) . . . . . 30
3.1
Panorama retangular montado a partir de segmentos consecutivos . . 35
3.2
Dispositivo multicâmeras para aquisição de panoramas omnidirecionais por image stitching (Ladybug2 [63]) . . . . . . . . . . . . . . . . 35
3.3
Cálculo de homografias em cadeia . . . . . . . . . . . . . . . . . . . . 36
3.4
Exemplos de imagens omnidirecionais obtidas por uma câmera catadióptrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5
Modelos de implementação de uma câmera catadióptrica . . . . . . . 39
3.6
Lente de 360◦ Kogeto Dot [68]. . . . . . . . . . . . . . . . . . . . . . 39
3.7
Ilustração do procedimento de transformação de uma imagem polar
em um panorama retangular (dewarping). . . . . . . . . . . . . . . . 41
x
4.1
Arquitetura genérica de um sistema de navegação por visão computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2
Tempos de aquisição de um único quadro em uma CMUCam3 para diferentes resoluções e formatos de imagem: a) 352x288 pixels; b)176x143
pixels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3
Tempos de transmissão de um único quadro JPEG após filtro passabaixa (imagem suavizada). . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4
Tempo gasto pela CMUCam3 para calcular a distância até um obstáculo
posicionado à frente da câmera . . . . . . . . . . . . . . . . . . . . . 49
4.5
Resultado do procedimento de identificação de um obstáculo à 60 cm
para a CMUCam3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6
Tempo gasto pela Raspberry Pi para calcular a distância até um
obstáculo posicionado à 60 cm da CMUCam. . . . . . . . . . . . . . . 51
4.7
Modelo monocular para aquisição de imagens omnidirecionais. . . . . 53
4.8
Tempos de aquisição e montagem de um panorama no protótipo monocular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.9
Exemplo de panorama omnidirecional montado pelo protótipo monocular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.10 Modelos de interligações multicâmeras . . . . . . . . . . . . . . . . . 56
4.11 Modelo de barramento multiplexado com 3 CMUCam3 e um 74LS151 57
4.12 Tempos de transferência e montagem de um panorama de 180◦ . Segmentos JPEG com resolução de 176x143. . . . . . . . . . . . . . . . . 59
4.13 Solicitação de quadro no modelo daisy chain . . . . . . . . . . . . . . 59
4.14 Tempos de transmissão e montagem do panorama de 180 graus (3
câmeras) em daisy chain . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.15 Panorama de 180◦ montando a partir de um arranjo de 3 CMUCam3
em daisy chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.16 Imagem esférica capturada pelo protótipo catadióptrico (a) e panorama omnidirecional (b). . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.17 Tempo de geração de um panorama retangular a partir de uma imagem esférica de 480x480 pixels . . . . . . . . . . . . . . . . . . . . . . 63
5.1
Protótipo de veı́culo de tração diferencial para navegação . . . . . . . 69
xi
5.2
Panorama omnidirecional capturado pelo protótipo de navegação . . . 69
5.3
Piso padronizado para os experimentos de navegação . . . . . . . . . 70
5.4
Arquitetura geral do software para controle de navegação. . . . . . . 71
5.5
Diagrama de classes do sistema de controle de navegação. . . . . . . . 71
5.6
Medidas de distância percorrida para cada ângulo de rotação em
função do deslocamento angular . . . . . . . . . . . . . . . . . . . . . 73
5.7
Escala de rotação a partir do centro do panorama retangular . . . . . 76
5.8
Calibração do algoritmo para determinar a distância até o objeto
detectado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.9
Localização dos objetos para rastreamento . . . . . . . . . . . . . . . 77
5.10 Algoritmo para controle de movimentação do rastreamento . . . . . . 78
5.11 Trajetórias de rastreamento . . . . . . . . . . . . . . . . . . . . . . . 80
5.12 Grade de ocupação do cenário e grafo de representação do ambiente
para mapeamento dinâmico . . . . . . . . . . . . . . . . . . . . . . . 81
5.13 Resultado do procedimento de detecção de obstáculos . . . . . . . . . 83
5.14 Obstáculos para o experimento de mapeamento dinâmico . . . . . . . 84
5.15 Exemplo de rotas calculadas até o nó de destinoS5,1 . . . . . . . . . . 85
5.16 Visão do robô durante o mapeamento . . . . . . . . . . . . . . . . . . 85
5.17 Grafo atualizado após o percurso . . . . . . . . . . . . . . . . . . . . 86
5.18 Mapa topológico e pontos selecionados para localização . . . . . . . . 88
5.19 Imagens de pontos conhecidos do ambiente de navegação . . . . . . . 89
5.20 Resultado de comparações com o robô posicionado sobre o nó S1,5 . . 92
xii
Lista de Tabelas
2.1
Comandos de movimentação para controle do veı́culo Lego. . . . . . . 28
4.1
Resumo dos tempo de aquisição e montagem de panoramas em cada
modelo arquitetural . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1
Relação entre a distância real do objeto e a distância em pixels da
imagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2
Relação entre a distância real e a distância estimada pelo algoritmo
de detecção de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3
Cálculo e atualização de rotas no grafo de navegação . . . . . . . . . 86
5.4
Número de matches com o robô posicionado sobre pontos conhecidos
do mapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5
Número de matches com o robô posicionado sobre pontos desconhecidos do mapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
xiii
à Bilinha, com todo o meu amor.
xiv
Capı́tulo 1
Introdução
Na última década, pesquisas e aplicações envolvendo sistemas autônomos de navegação terrestre deixaram o âmbito exclusivo dos laboratórios e centros de estudos
e chegaram às ruas. Em 2010 o Google Inc. anunciou em seu blog oficial e no
jornal The New York Times [1] o protótipo de um veı́culo autodirigido que deveria, dentro de poucos anos, substituir os automóveis tradicionais. Acompanhando a
tendência, algumas grandes empresas do mercado automobilı́stico como a Audi[2],
a Mercedes-Benz [3] e a Jaguar[4] também anunciaram seus projetos de veı́culos de
navegação parcial ou totalmente autônoma. Ao mesmo tempo, alguns estados dos
EUA (e.g. California, Nevada, Michigan e Florida) aprovaram leis que autorizam e
regulamentam o trânsito para veı́culos auto-digiridos em seus territórios. Em 2012,
a Sociedade de Engenheiros Automotivos (Society of Automotive Engineers, SAE)
estabeleceu um comitê para a definição de padrões para projeto e desenvolvimento
de veı́culos de navegação não assistida [5]. Diversos outros setores também apresentaram avanços em dispositivos de navegação autônoma, incluindo drones [6], sondas
espaciais [7] e dispositivos domésticos de baixo custo, como o robô aspirador de pó
Roomba [8].
Em robótica móvel, a capacidade de navegar de forma autônoma por um determinado ambiente (conhecido ou não) requer duas habilidades essenciais no robô: a
capacidade de “observar” o ambiente ao seu redor e a “inteligência” necessária para
interpretar informações sobre ele. Um sistema de navegação genérico pode ser compreendido como uma combinação eficiente entre um aparato sensorial de observação
(e.g. radares, sonares, câmeras, etc.) e a computação necessária para tomar decisões
1
sobre o que foi observado. Esta combinação permite ao robô elaborar um modelo
descritivo do ambiente (e.g. mapas de ocupação, posicionamento de obstáculos, modelos 3D, etc.), para a realização de tarefas centrais de navegação. Alguns exemplos
destas tarefas centrais são: encontrar um objeto especı́fico, desviar de obstáculos,
otimizar a trajetória até um determinado ponto, mapear um ambiente desconhecido,
etc.
O tipo de sensor e o aparato computacional utilizado são especı́ficos de cada
aplicação e sua escolha deve considerar uma grande variedade de fatores, por exemplo: a topologia e a dinâmica do ambiente navegado, a disponibilidade de recursos
computacionais, a velocidade e a mobilidade do veı́culo, o tipo especı́fico de tarefa
a ser realizada e o custo financeiro do projeto. Veı́culos seguidores de linha, por
exemplo, normalmente não precisam de radares de alta precisão, da mesma forma
que projetos de automóveis auto-dirigidos certamente não podem se basear em computadores de baixo desempenho. O dimensionamento correto dos diferentes tipos
de sensores, hardware e algoritmos é um desafio para qualquer projeto de navegação
autônoma e compreende um dos principais temas desta pesquisa.
1.1
Sistemas de Navegação Autônoma em Robótica
Móvel
A Navegação autônoma pode ser definida como uma combinação de três competências fundamentais: auto-localização, planejamento de rotas e mapeamento [9].
No contexto da robótica móvel, um sistema de navegação autônoma é o conjunto de
ferramentas e algoritmos responsável pela escolha e pelo controle dos movimentos
executados pelo robô. De um ponto de vista funcional, é o sistema de navegação
que determina onde o robô está e para onde ele deve se mover. A habilidade de
navegar de maneira autônoma é a soma de um conjunto de serviços fundamentais
oferecidas pelo sistema de navegação, dentre eles: localização; mapeamento; odometria; planejamento de rotas; e a detecção de obstáculos, marcações e objetos de
interesse (targets). De um ponto de vista da arquitetural, um sistema de navegação
é a interligação entre os sensores, os algoritmos e os bancos de dados utilizados para
oferecer estes serviços.
2
Um sistema de navegação pode ser caracterizado pelo conjunto de sensores que
possui, pelo tipo e o grau de organização do ambiente no qual deve navegar e, finalmente, pela estratégia de mapeamento que utiliza [10]. O ambiente de navegação
pode ser classificado como interno ou externo, estruturado ou desestruturado, humano ou natural. O tipo de ambiente tem impacto decisivo sobre a escolha dos algoritmos necessários para os serviços de navegação. Quanto ao tipo de mapeamento
utilizado, é possı́vel escolher entre abordagens com mapeamento prévio, dinâmico
ou sem mapeamento algum.
Sistemas baseados em mapeamento são normalmente aplicados em ambientes
estruturados e previamente conhecidos. Nestas abordagens, juntamente com o mapa
do ambiente, é comum a utilização de marcações no terreno ou o reconhecimento
de pontos de referência para auxiliar a localização do robô. Em [11], por exemplo,
é apresentado um sistema de navegação de um robô móvel dentro de um escritório
comercial. A estratégia de navegação é dividida em duas etapas: global e local. A
primeira etapa envolve localizar o robô em um mapa global do ambiente a partir
de um conjunto de marcações no terreno. O mapa é representado por um grafo
onde os nós são pontos conhecidos do escritório e as arestas são os caminhos entre
eles. Cada nó é associado a uma marcação passiva de RFID (Radio Frequency
IDentification), que o robô é capaz de identificar a um metro de distância. Ele
percorre os corredores do escritório e atualiza sua posição global toda vez que alcança
uma destas marcações. A etapa local de navegação, por sua vez, consiste em manter
o robô sempre paralelo às paredes dos corredores navegados. O alinhamento com
as paredes é feito com base em informações fornecidas por um radar (laser range
scanner ) e assegura a localização do robô entre duas marcações consecutivas.
Em ambientes desconhecidos a navegação pode ser realizada com ou sem mapeamento dinâmico. Nas abordagens sem mapeamento (reativa), o robô se movimenta sem o auxı́lio de uma descrição prévia do ambiente, simplesmente reagindo
aos estı́mulos encontrados (i.e. obstáculos, marcações, alvos). O Roomba [8], por
exemplo, é um robô aspirador, bastante popular no mercado de robôs para utilidades domésticas, que utiliza uma abordagem reativa de movimentação. Seu sistema
de navegação não depende de um mapeamento prévio do ambiente, ele é capaz de
identificar obstáculos como móveis e paredes, de estimar a área do cômodo a ser
3
aspirado e ainda calcular o tempo que ele levará para aspirá-lo. O Roomba também
é capaz de localizar e regressar a uma estação base quando os nı́veis de bateria estão
baixos.
Nos sistemas de mapeamento dinâmico, por sua vez, a representação do ambiente
é construı́da a partir das informações de sensores adquiridas durante a navegação.
O conjunto de técnicas de mapeamento dinâmico é denominado SLAM (Simultaneous localization and mapping), da sigla em inglês para Mapeamento e Localização
Simultâneos [12]. Em [13] é apresentado um sistema de mapeamento dinâmico de
ambientes externos e desestruturados baseado em informações coletadas de um sonar. As leituras do sonar são feitas sob múltiplos pontos de vista toda vez que o
robô móvel entra em uma região desconhecida. A partir delas o robô é capaz de
determinar áreas ocupadas ou vazias ao seu redor e montar um mapa topológico
bidimensional do novo ambiente. O mapa serve de base para o planejamento de trajetórias e localização do veı́culo durante a navegação. Uma abordagem semelhante
também é apresentada em [14], onde o sistema de mapeamento combina técnicas de
visão panorâmica e reconstrução 3D para mapear o ambiente ao redor do robô. Entre robôs móveis de pequeno porte, um dos concorrentes do Roomba, o Neato Botvac
80 [15], utiliza uma estratégia de mapeamento dinâmico para mapear o cômodo a
ser aspirado durante a navegação.
A escolha da melhor combinação de sensores para um sistema de navegação é
quase sempre estabelecida com uma solução para o seguinte problema: como extrair
um volume de informações do ambiente suficiente para tomar decisões e assegurar
uma movimentação segura entre dois pontos? O problema parte do pressuposto
de que quanto maior é o número de informações coletadas sobre o ambiente, mais
precisa pode ser a navegação. O principal desafio associado ao projeto de sistemas
de navegação autônoma, portanto, é o de como obter o maior volume de informações
utilizando estratégias de menor custo e complexidade.
Há um número significativo de combinações de sensores para aquisição de informações sobre o ambiente a ser navegado. Além disso, para cada tarefa especı́fica
de navegação (i.e. localização, desvio de obstáculos, planejamento de rota) também
existe uma grande variedade de algoritmos disponı́veis na literatura. Considerando,
por exemplo, o problema de identificação de obstáculos ao redor do robô, é possı́vel
4
escolher entre alternativas baseadas em mapeamento por sonar, como em [16] e [13],
ou por visão computacional, como em [17]. Os dois primeiros apresentam soluções
poderosas de identificação e mapeamento de obstáculos, mas o custo dos sensores e a
complexidade dos algoritmos necessários para implementá-los podem ser proibitivos
para projetos menores. O terceiro, por sua vez, apresenta uma solução mais simples
baseada em segmentação de imagens obtidas com uma só câmera. O robô é capaz
de identificar pela cor os obstáculos em uma imagem, e estimar a distância até eles.
Em contrapartida, a aplicação deste modelo em ambientes altamente desestruturados pode ser inviável devido à fatores como: a necessidade de que os obstáculos
tenham cores bem diferentes do solo; e o fato de que os obstáculos precisam ser
visualizados diretamente pelo robô para serem mapeados.
As diferentes combinações de sensores e algoritmos para interpretar o ambiente
navegado podem ser separadas em duas abordagens distintas:
Fusão de sensores: combinar sensores que sozinhos não oferecem informações suficientes, mas juntos podem gerar uma descrição detalhada sobre um ambiente
desconhecido. Técnicas de fusão e filtragem das distribuições de probabilidade
dos sensores (e.g. Kalman Filters, Particle Filters, etc.) podem ser utilizadas
para combinar as diferentes leituras e aumentar a precisão das tomadas de
decisão.
Sensor Único: utilizar um único sensor que forneça sozinho um grande volume de
informações que possam ser “mineradas” pelo sistema de navegação.
A primeira abordagem apresenta resultados positivos com as mais variadas combinações de sensores ([18, 19, 20, 21]). O modelo de fusão de sensores pode oferecer
um conjunto diversificado de informações sobre o ambiente. Em conjunto, estas
informações podem ser utilizadas para compensar erros de estimativa de sensores
individuais. Uma dificuldade particular desta abordagem, além da interligação e
gerenciamento dos sensores, é a compatibilização da natureza das informações coletadas. Por exemplo, considerando um sistema de navegação de ambientes internos
dotado de um sonar e de sensores infravermelhos de distância, e supondo que o
ambiente a ser navegado contenha uma parede de vidro e outra de gesso, os sensores apresentariam informações conflitantes sobre os estes obstáculos [22]; o modelo
5
de navegação, neste caso, precisa considerar as peculiaridades de cada sensor para
eliminar conflitos e redundâncias.
A segunda abordagem normalmente requer a manipulação de sensores complexos
através de algoritmos de alto custo computacional. Embora soe atraente a possibilidade de utilizar um sensor capaz de fornecer um grande volume de informações
para navegação, os custos financeiros e computacionais associados à utilização destes
dispositivos podem restringir a sua aplicação em projetos de pequeno porte. Projetos de grande porte, por outro lado, podem utilizar uma combinação das duas
estratégias para ampliar o grau de independência do dispositivo. O veı́culo autodirigido do Google [23], por exemplo, combina diferentes sensores da seguinte forma:
a princı́pio a navegação só é possı́vel em ruas, estradas e avenidas previamente mapeadas pelo Google Maps e Google Street View. O sistema combina informações de
GPS com o mapa mundial da empresa para estimar a localização do veı́culo e determinar o melhor caminho até um destino especı́fico. É através destas informações
que o veı́culo “sabe” em qual rua ele está e para qual rua ele deve ir no próximo
cruzamento. No entanto, somente estas informações não são suficientes para uma
localização mais precisa com relação a construções e referências locais. Enquanto
o veı́culo trafega, o sistema de navegação compara imagens obtidas por câmeras
no topo do carro com as imagens do Google Street View previamente adquiridas e
elabora um mapa local para realimentar o sistema de localização. Finalmente, um
sistema LIDAR (sigla em inglês para Light Detection And Ranging) de varredura
por laser, combinado com sensores infravermelhos, varre todo o entorno do veı́culo
e constrói um modelo 3D do ambiente a uma taxa de vinte vezes por segundo, identificando obstáculos dinâmicos do caminho. O resultado é um sistema robusto para
navegação em ambientes altamente dinâmicos.
1.1.1
Visão Computacional para Navegação
Uma alternativa comum para os projetos que optam pela abordagem de “sensor
único” são os sistemas de visão computacional. A partir de uma única imagem do
espaço ao redor do veı́culo é possı́vel extrair informações decisivas, como a presença
ou não de obstáculos, a localização de objetos de interesse, a textura e a geometria
do terreno e, finalmente, um conjunto de caracterı́sticas invariantes no campo de
6
visão do robô (i.e. cantos e bordas). Por conta do volume de informações oferecido
pelos sensores visuais, bem como o avanço das técnicas e ferramentas de hardware
e software para manipulação de imagens, os sistemas de visão computacional têm
sido amplamente utilizados em diferentes projetos de navegação em robótica [14,
24, 25, 26, 27], tanto como sensor principal de navegação quanto como auxiliar em
estruturas mais complexas de fusão de sensores.
Sistemas de visão computacional podem auxiliar a execução de diferentes tarefas
de navegação autônoma, dentre elas: identificação de obstáculos, auto-localização,
mapeamento 3D, reconhecimento de marcações, etc. A versatilidade oferecida pelos sistemas de visão possibilita a sua aplicação em diferentes abordagens de navegação. Em [25], por exemplo, os autores apresentam a análise de um mecanismo
para navegação em ambientes internos previamente mapeados. O mapa é construı́do inicialmente com o auxı́lio humano, levando o robô a pontos distintos do
ambiente e capturando imagens de cada um deles. Em seguida, o robô é posicionado em um ponto qualquer do ambiente e inicia a navegação comparando imagens
recém-adquiridas com aquelas capturadas na fase de treinamento; quando a correspondência entre duas imagens atinge um certo nı́vel, o robô identifica que chegou
a um ponto conhecido do mapa. Os principais algoritmos utilizados neste sistema
envolvem o reconhecimento de padrões e a extração e comparação de caracterı́sticas
invariantes (features) presentes nas imagens. Em [28], por outro lado, é apresentado um sistema de navegação reativa para um veı́culo de colheita em um campo de
grãos infestado por ervas daninhas. O sistema não utiliza um mapeamento prévio
do campo de colheita e o robô orienta a sua trajetória simplesmente com base nas
imagens adquiridas durante o percurso. Os autores argumentam que a principal
dificuldade para utilizar sistemas de visão em campos deste tipo é o fato de que as
ervas possuem a mesma coloração que os grãos, adicionando uma série de ruı́dos que
interferem nos cálculos de trajetória. O artigo apresenta um modelo de eliminação
do ruı́do causado pelas ervas através da remoção de pequenos componentes conexos
nas imagens. Os principais algoritmos utilizados neste caso envolvem identificação
de cores, segmentação e reconhecimento de formas (blob detection).
As vantagens dos sistemas de visão computacional aplicados à navegação podem ser ainda maiores quando o campo de visão do robô é estendido. Tarefas que
7
envolvem extração de features e identificação de marcações, por exemplo, são beneficiadas quando as marcas e os objetos avaliados permanecem visı́veis por mais
tempo. Além disso, quanto maior o campo de visão menos capturas o robô precisa
fazer para identificar caracterı́sticas no ambiente ao seu redor. Manobras que precisam ser executadas com várias pausas em sistemas de visão frontal, por exemplo,
podem ser simplificadas quando o robô “enxerga” todos os obstáculos a sua volta de
uma só vez. Esta relação justifica o interesse em pesquisas de visão omnidirecional
para navegação em robótica móvel.
1.1.2
Sistemas de Visão Omnidirecional
Sistemas de visão omnidirecional para navegação de robôs são o interesse central
deste trabalho. O principal objetivo de um sistema visão omnidirecional é fornecer
um panorama de 360◦ do espaço ao redor do robô. As vantagem destes sistemas
com relação aos modelos de visão direcionada é justamente o maior campo de visão
disponı́vel para a análise em uma só captura. Quanto maior a amplitude angular
mais tempo os objetos de interesse permanecem no campo de visão, facilitando a sua
identificação e rastreamento. Imagens omnidirecionais também oferecem uma maior
invariabilidade às rotações e deslocamentos horizontais, caracterı́sticas essenciais
para tarefas de auto-localização [29].
Tradicionalmente, um panorama omnidirecional pode ser obtido de duas formas:
1. Combinando uma câmera e um espelho convexo devidamente alinhados pelo
centro focal da câmera;
2. Concatenando segmentos parciais do panorama capturados ao redor de um
centro de projeção.
Na primeira abordagem, são capturadas imagens polares do entorno da câmera.
Para obter um panorama retangular elas precisam passar por procedimentos de
conversão entre coordenadas polares e cartesianas. A técnica de conversão de uma
imagem polar para um panorama retangular é denominada dewarping (“desenrolar”,
em tradução livre). No segundo modelo, os segmentos são inicialmente alinhados sobre um mesmo plano através de uma transformação perspectiva. Em seguida, todos
8
eles são concatenados em uma única imagem retangular. O processo de alinhamento
e concatenação dos segmentos é conhecido como image stitching.
Os dois modelos de aquisição serão melhor detalhados no terceiro capı́tulo desta
dissertação. A principal diferença entre eles, além do método de criação do panorama retangular, é a resolução da imagem final. Se um sensor com resolução de
200x200 pixels for utilizado para capturar quatro segmentos, o panorama final obtido por concatenação terá uma resolução de até 800x200 pixels. Se o mesmo sensor
for utilizado em conjunto com um espelho esférico para obtenção de uma imagem
polar, o panorama final após o dewarping terá uma resolução em torno de 700x100
pixels. Estas particularidades têm um impacto decisivo na determinação do tipo de
aplicação para qual cada modelo é mais adequado.
1.1.3
Desafios de Implementação
A utilização de modelos de visão computacional em robótica embarcada pode ser
limitada pelo alto custo computacional que eles demandam. Algoritmos de manipulação de imagens, em sua maioria, possuem alta complexidade e exigem grandes
quantidades de memória e poder de processamento para serem executados em tempo
real. Na maioria das aplicações de navegação as imagens precisam ser capturadas e
analisadas em uma velocidade compatı́vel com a movimentação do robô. Por exemplo, para evitar colisões com obstáculos dinâmicos eles precisam ser identificados
assim que aparecerem no campo de visão do dispositivo, assegurando um tempo
hábil para reação. Restrições deste tipo impõem um desafio significativo em sistemas de pequeno porte, normalmente baseados em microcontroladores e FPGA, onde
recursos computacionais são mais limitados. Para sistemas de visão omnidirecional
esta dificuldade é ainda mais sensı́vel devido ao maior volume de dados em cada
imagem, além do custo adicional dos algoritmos de montagem de um panorama
retangular (dewarping ou image stitching).
Em geral, a dificuldade de embarcar algoritmos de visão computacional é contornada através da incorporação de elementos de alto nı́vel ao sistema de navegação.
Servidores e computadores pessoais normalmente são utilizados para realização das
operações mais complexas do sistema. A adição de elementos de alto nı́vel trás
consigo necessidade de incorporar todo um aparato necessário para o seu funciona9
mento, como redes de alta velocidade, sistemas operacionais e bibliotecas de software
especializadas. Um efeito imediato desta alternativa é o encarecimento dos custos do
projeto. Encontrar formas de interligação que comportem a utilização de algoritmos
complexos de manipulação de imagens em dispositivos de pequeno porte ainda é um
desafio aberto para pesquisa [30].
O conhecimento das etapas que compõem o fluxo de navegação visual pode ajudar
a estabelecer uma divisão de tarefas eficiente entre os componentes de cada arquitetura. O fluxo de imagens em um sistema de navegação por visão omnidirecional
pode ser dividido em cinco etapas:
Aquisição: captura das imagens para processamento. Em sistemas panorâmicos
de múltiplas câmeras é importante que as imagens sejam capturadas simultaneamente, evitando, por exemplo, que um mesmo objeto móvel seja visto
em vários pontos da imagem. Também é necessário conhecer as distorções de
imagem associadas aos sensores e lentes utilizados.
Pré-processamento: ajuste e acomodação das imagens de acordo com as necessidades de cada projeto. Nesta etapa podem ser aplicados filtros para suavização
de ruı́dos, para extração de bordas, ou até procedimentos de equalização de
histogramas e compressão das imagens.
Panorama: aplicação dos algoritmos de montagem do panorama retangular (dewarping e image stitching).
Análise: algoritmos para interpretação das informações observadas em cada imagem. Exemplos comuns são os algoritmos de extração de caracterı́sticas invariantes, ou as técnicas de segmentação e limiarização de imagens. O conjunto
de algoritmos utilizados depende do objetivo associado à navegação.
Controle: a partir das informações obtidas na etapa de análise, o sistema de visão
toma decisões de controle e movimentação do robô.
Do ponto de vista de sistema, é possı́vel concentrar todas as etapas do fluxo de
visão em uma única central de processamento, ou distribuı́-las entre os diferentes
componentes. As etapas de análise das imagens e controle do dispositivo são as
mais complexas e consomem a maior parte do tempo de execução. Por conta disso,
10
é essencial que as etapas de captura, pré-processamento e montagem dos panoramas
tenham o máximo de eficiência possı́vel.
1.2
Objetivos
O objetivo central deste trabalho é a implementação de um sistema de navegação
por visão computacional para robôs móveis de pequeno porte. A ideia é adaptar o
fluxo de imagens descrito na seção anterior para as restrições inerentes a este nicho
de aplicações. O sistema final deve possuir um campo de visão omnidirecional e
implementar tarefas comuns de navegação. A abordagem escolhida para a pesquisa
pode ser dividida em duas etapas principais: a primeira delas é uma análise de
diferentes arquiteturas de aquisição de imagens omnidirecionais e o impacto de cada
uma sobre o desempenho do fluxo visual; já a segunda etapa é a integração de um
dos modelos de aquisição a um robô móvel para navegação.
Os modelos de aquisição de imagens omnidirecionais são responsáveis pelas três
primeiras etapas do fluxo visual de navegação. Cada modelo é composto por uma ou
mais câmeras, todas com um microcontrolador de pequeno porte embarcado (smartcam), e uma unidade de central de processamento com maior poder computacional.
Na primeira fase, o trabalho procura responder questões do tipo: como deve ser a
troca de informações entre os diferentes componentes do sistema? Quais etapas podem ser executadas diretamente na câmera e quais precisam ser encaminhadas para
um módulo central de processamento? Quais as vantagens e desvantagens de montar
um panorama a partir de vários segmentos ou de uma única imagem polar? Qual a
forma mais eficiente de interligar várias câmeras para obter um panorama omnidirecional por concatenação? Para qual tipo de aplicação cada modelo é mais adequado?
Ao todo são comparadas três arquiteturas básicas de aquisição nesta etapa do trabalho, duas por image stitching e uma por dewarping. O tempo de aquisição em
cada modelo é o principal parâmetro de avaliação. O objetivo é determinar quais
arquiteturas são capazes de entregar um panorama omnidirecional em um intervalo
compatı́vel com a velocidade de movimentação do robô. Outro parâmetro importante avaliado é a resolução dos panoramas obtidos em cada modelo. Tarefas de
navegação baseadas em extração de features, por exemplo, são bastante sensı́veis
11
à resolução das imagens utilizadas, bem como a presença de ruı́dos e distorções,
justificando este tipo de análise.
Uma vez definidas as vantagens e limitações de cada modelo de aquisição, o
segundo objetivo da pesquisa é utilizar a melhor arquitetura como um sistema visual
de navegação em um robô móvel. Esta fase compreende as duas últimas etapas
do fluxo de imagens para navegação. A separação entre o sistema de aquisição
e os sistemas de interpretação de imagens é proposta com o objetivo de facilitar a
substituição do primeiro pelos modelos mais eficientes em cada aplicação. O sistema
de navegação e o robô móvel se comunicam através de um protocolo pré-definido
de troca de mensagens via Bluetooth. Como plataforma de navegação foi utilizado
um robô móvel de tração diferencial, montado a partir de um kit Lego Mindstorms
NXT [31]. Uma série de experimentos de navegação autônoma foram realizados para
avaliar as potencialidades e as restrições da integração proposta em um contexto real
de aplicação.
1.3
Organização da Dissertação
Esta dissertação é um estudo das formas de aquisição de imagens omnidirecionais
para sistemas de navegação visual em robôs móveis de pequeno porte. Aqui, entendese por “sistema de navegação” o conjunto de elementos que realizam tarefas de
localização, mapeamento e cálculo de trajetórias. São analisados os sistemas de
navegação baseados em visão computacional, destinados à ambientes internos e estruturados, sem mapeamento ou com mapeamento parcial.
A linha geral para orientação da pesquisa é o fluxo de imagens necessário para navegação visual, composto pelas etapas de captura, pré-processamento, montagem de
um panorama omnidirecional, análise e controle de movimentação. Inicialmente, o
trabalho concentra esforços na análise e implementação de arquiteturas de aquisição
de panoramas omnidirecionais. São avaliados quatro protótipos de aquisição, três
por image stitching (monocular, multicâmeras em barramento e multicâmeras em
cadeia) e um deles por dewarping (catadióptrico). A análise de arquiteturas de
aquisição compreende as três primeiras etapas do fluxo de imagens. Em seguida,
a atenção do trabalho é direcionada para a aplicação de um modelo de aquisição
12
em um contexto real de navegação. Um protótipo catadióptrico de aquisição é integrado à um robô móvel para a realização de experimentos de rastreamento de
objetos, mapeamento dinâmico de obstáculos e localização.
A fundamentação teórica necessária para a realização deste trabalho é apresentada nos Capı́tulos 2 e 3. O Capı́tulo 2 descreve os princı́pios de navegação por visão
computacional e apresenta os algoritmos utilizados para implementar os serviços de
identificação de obstáculos, rastreamento de objetos, localização e mapeamento. Os
serviços de navegação descritos no Capı́tulo 2 servem de fundamentação para os
experimentos descritos no Capı́tulo 5 desta dissertação. Após a descrição dos algoritmos de navegação por visão computacional, o Capı́tulo 2 ainda apresenta a
arquitetura do sistema de navegação por visão proposto e o modelo cinemático para
um robô móvel de tração diferencial. A interface e o protocolo de comunicação entre
o sistema de navegação e o robô também é descrita no Capı́tulo 2.
No Capı́tulo 3 são apresentados os fundamentos matemáticos para as duas formas
tradicionais de aquisição de um panorama omnidirecional, stitching e dewarping. O
capı́tulo serve de fundamentação para a implementação dos protótipos de aquisição,
descritos no Capı́tulo 4.
No Capı́tulo 4 também são apresentadas as análises de desempenho dos modelos
de aquisição. As análises são baseadas no tempo de aquisição e na resolução dos
panoramas. O objetivo do Capı́tulo 4 é avaliar as possı́veis formas de interligação
entre as câmeras e os elementos de processamento para obter o melhor desempenho
para navegação.
O Capı́tulo 5 apresenta o robô móvel construı́do e uma série de experimentos
de navegação com o modelo catadióptrico de visão omnidirecional. Os experimentos realizados compreendem os serviços de rastreamento de objetos, mapeamento
dinâmico e localização. A metodologia e os resultados de cada experimento também
são apresentados neste capı́tulo.
Finalmente, o Capı́tulo 6 discute os resultados obtidos nos Capı́tulos 4 e 5 e
apresenta as conclusões gerais do trabalho.
13
Capı́tulo 2
Navegação por Visão
Computacional
Navegação autônoma pode ser definida como um problema de como movimentar um
robô entre dois pontos de forma segura e eficiente, sem intervenção humana direta.
Segurança, neste contexto, significa ser capaz de detectar possı́veis obstáculos, evitando colisões e, consequentemente, danos ao robô e ao ambiente. A eficiência da
movimentação, por sua vez, sugere que sejam considerados fatores como o consumo
de energia, a quantidade de manobras, a velocidade de deslocamento, a escolha do
melhor caminho, etc. [32]. Um veı́culo de navegação autônoma, portanto, deve
ser capaz de se movimentar entre um ponto A e um ponto B, escolhendo o melhor
caminho possı́vel, realizando o menor número de manobras, evitando obstáculos, reconhecendo marcações e determinando sua posição no ambiente navegado, tudo isso
sem auxı́lio humano. O que se define por navegação é, de um ponto de vista computacional, a soma de algumas tarefas fundamentais para atender a esses requisitos
de segurança e eficiência.
Em qualquer ambiente de navegação a autonomia do robô depende diretamente
da capacidade de receber informações sobre o espaço ao seu redor e tomar decisões
de movimentação de acordo com elas. Quanto mais informações o robô obtiver,
mais precisas podem ser suas manobras. Outro fator decisivo para a qualidade da
navegação é o conjunto de suposições que o robô faz sobre o mundo navegado. É
razoável supor, por exemplo, que ambientes humanos são normalmente planos e
regulares, com linhas que podem ser seguidas e pontos de referência que podem
14
ser detectados; ao mesmo tempo é possı́vel admitir que ambientes naturais são
mais acidentados e sujeitos a variações de iluminação e textura [27]. Os tipos de
sensores utilizados para “observar” o ambiente e o conjunto de suposições sobre
ele determinam a estratégia de navegação, assim como quais das tarefas são mais
decisivas.
Técnicas de visão computacional são especialmente atraentes para sistemas de
navegação autônoma, porque fornecem, ao mesmo tempo, um grande volume de
dados sobre o ambiente, juntamente com um conjunto de mecanismos eficientes
para interpretação destes dados. Informações como cor, textura e linhas de fuga
podem ajudar o robô a construir um modelo de mundo bastante detalhado, com
a vantagem adicional do uso de um sensor apenas. A popularização de câmeras e
sensores visuais (e.g. webcams, smartcams, Kinect, etc.) nos últimos anos também
contribuiu para uma maior utilização das técnicas de visão em sistemas robóticos.
Todos estes fatores atraı́ram um enorme interesse da academia e da indústria nas
últimas décadas, como pode ser observado em [10] e [33].
Existem diversas formas de classificar os sistemas de navegação por visão computacional. Diferentes abordagens podem ser classificadas quanto ao tipo de ambiente
navegado (interno ou externo), o grau de organização do ambiente (estruturados
ou desestruturados) e o tipo de mapeamento utilizado (com ou sem mapeamento,
mapeamento dinâmico, etc.). Para cada problema de navegação abordado existe
também uma imensa variedade de algoritmos e técnicas de otimização disponı́veis
na literatura. Problemas de detecção de obstáculos, por exemplo, podem ser abordados de diferentes formas de acordo com o ambiente de aplicação [17, 34, 35, 36].
A mesma variedade de soluções pode ser encontrada para cada um dos problemas
fundamentais de navegação.
Este trabalho restringe o escopo de navegação à realização de três tarefas fundamentais: rastreamento de objetos, detecção de obstáculos e auto-localização. O
objetivo principal é submeter as imagens omnidirecionais, obtidas pelas arquiteturas
descritas no Capı́tulo 4, a algoritmos que realizem estas tarefas. Para cada problema
foi escolhido um algoritmo especı́fico e todos eles foram incorporados como funções
básicas do sistema de navegação. Embora os algoritmos implementados não sejam
os mais precisos em cada categoria, a escolha foi pautada principalmente pela neces-
15
sidade de incorporá-los em um ambiente embarcado de pequeno poder computacional. As arquiteturas propostas neste trabalho assumem que todo o processamento
de navegação deve ser feito pelo próprio sistema de visão embarcado, evitando a
necessidade de encaminhar imagens para elementos de alto nı́vel como servidores ou
computadores pessoais. Os algoritmos escolhidos são descritos na Seção 2.1.
O modelo geral para a arquitetura do sistema de navegação é apresentado na
Seção 2.2. A arquitetura é baseada em um Raspberry Pi [37], para controle visual, e
um mini-veı́culo montado a partir de um kit Lego Mindstorms [31], para navegação.
As interligações entre os componentes de hardware e software do sistema também
serão descritas nesta seção.
2.1
Algoritmos de Navegação por Visão Computacional
Os algoritmos apresentados nesta seção foram escolhidos para avaliar as arquiteturas de aquisição omnidirecional para a realização de tarefas básicas de navegação
autônoma. Eles foram incorporados ao firmware do sistema navegação sob a restrição de serem executados em um tempo compatı́vel com a velocidade de navegação.
O hardware utilizado para processamento é um Raspberry Pi modelo B [38].
2.1.1
Identificação de Obstáculos
O algoritmo de identificação de obstáculos implementado é uma variação dos procedimentos descritos em [17] e [36], baseado na diferença entre a cor do solo e do
restante do ambiente. A técnica é adequada para ambientes internos (indoor ) com
obstáculos estáticos e onde a cor do solo é uniforme. Supondo que a imagem analisada é retangular, com dimensões W × H e com um referencial de origem no topo
superior esquerdo, o algoritmo assume que os primeiros pixels a partir do centro
inferior (i.e. W/2, H) correspondem à cor do solo à frente do robô. Ele retira
uma amostra nesta região que servirá como base para a classificação do restante da
imagem. Em seguida, partindo da última linha horizontal em direção ao topo da
imagem, o algoritmo classifica cada pixel de acordo com a distância para a cor do
solo. Pixels com valores próximos são classificados como solo e pintados de ama16
relo. O resultado deste procedimento inicial é ilustrado na Figura 2.1b. O solo é
percebido como um grande componente conexo na imagem, possibilitando estimar
quanto espaço que o robô tem à sua frente.
(a) Visão original
(b) Identificação do solo
(c) Linhas de trajetórias possı́veis
Figura 2.1: Procedimento de detecção de obstáculos por diferenciação da cor do solo
O passo seguinte é determinar uma área livre para movimentação. O algoritmo
traça linhas radiais a partir do ponto de origem do robô, definindo possı́veis trajetórias para o veı́culo neste ambiente. O robô pode desviar de obstáculos próximos
seguindo as linhas mais longas. Se nenhuma linha estiver disponı́vel, ou caso elas
sejam curtas demais, o robô pode executar uma rotação e avaliar o cenário de outro
ponto de vista. A Figura 2.1c ilustra o resultado do procedimento. A distância entre
o robô e o obstáculo pode ser estimada como uma função direta do comprimento das
linhas de trajetórias. Desviar de um obstáculo requer movimentar a frente do robô
na direção das linhas mais longas. Dispositivos com visão omnidirecional podem
aproveitar o campo de visão estendido para decidir qual a melhor “rota de fuga”
com apenas uma observação.
17
O algoritmo apresenta algumas limitações com relação à variações de iluminação
e relevo do terreno. Seu funcionamento é baseado em três suposições sobre o ambiente [39]:
• Obstáculos devem ter coloração diferente da do solo;
• O solo deve ser plano e de cor uniforme;
• O cenário não pode conter obstáculos suspensos, separados do solo.
Para reduzir o efeito de manchas e ruı́dos no solo é possı́vel convoluir a imagem
original com um filtro-passa baixa antes da detecção. O sistema de cores utilizado
também pode ter impacto sobre o desempenho do algoritmo. Imagens em RGB
(Red Blue Green) são mais sensı́veis a variações de iluminação, por exemplo, o que
pode gerar detecção de falsos obstáculos à frente do robô. Converter as imagens
capturadas para um sistema HSV (Hue Saturation Value) pode eliminar alguns
problemas de iluminação.
2.1.2
Uma das formas de classificar os diferentes sistemas de navegação autônoma é com
relação ao objetivo da navegação. Em algumas aplicações o robô navega pelo ambiente sem nenhuma rota ou destino definidos. Sondas espaciais e veı́culos de reconhecimento de áreas inacessı́veis são exemplos destas aplicações. Outro grupo
de aplicações inclui os sistemas que precisam percorrer uma trajetória predefinida,
cobrir uma determinada área de atuação ou procurar um lugar especı́fico dentro de
um espaço de navegação mais extenso. Um robô aspirador de pó como o Roomba,
por exemplo, precisa elaborar uma estratégia para cobrir todo o espaço de atuação
(i.e. cômodos de uma casa) e retornar à estação base para recarga das baterias.
Já um robô seguidor de linhas, por outro lado, tem uma trajetória pré-estabelecida
pelas marcações no solo. Em ambos os casos, o propósito (ou missão) da navegação
tem um impacto decisivo no projeto dos algoritmos e sistemas de controle do robô.
Alguns sistemas de navegação autônoma utilizam técnicas de rastreamento de
objetos (Target Tracking) para determinar o tipo de movimentação do robô [40,
41]. Nestas aplicações, detectar um objeto especı́fico (e.g. marcações, pontos de
18
referência, rostos, etc.) pode servir para orientar o veı́culo durante a execução de
uma tarefa, indicar uma determinada direção a ser tomada ou mesmo indicar que o
destino foi atingido. Em aplicações de futebol de robô, por exemplo, é comum utilizar
algoritmos de detecção e rastreamento da bola para orientar a movimentação dos
jogadores [42, 43, 44].
Existe uma grande variedade de soluções para rastreamento, quase sempre determinadas pelo tipo o ambiente de navegação e o tipo de objeto detectados [45].
Algumas das dificuldades associadas à detecção e rastreamento de objetos são:
• Ruı́dos presentes na imagem;
• Padrões complexos de movimentação dos objetos;
• Sobreposição parcial ou total do objeto;
• Variações na iluminação do ambiente;
• Desempenho em aplicações de tempo real.
Para reduzir o impacto destes fatores, limitamos o objetivo dos experimentos de
navegação neste trabalho ao rastreamento de um objeto rı́gido, de coloração uniforme
e em ambientes internos. O rastreamento pode ser definido com um problema de
localizar um determinado objeto dentro da imagem capturada e orientar o robô em
direção a ele. A posição do objeto com relação à frente do robô deve servir de
entrada para o sistema de controle servo-visual. A navegação terá como objetivo
minimizar a distância entre a posição do objeto e o centro de referência da visão do
robô.
O primeiro problema de implementação do sistema de rastreamento é determinar
quais caracterı́sticas melhor diferenciam o objeto de interesse do resto do ambiente.
O melhor cenário ocorre quando o objeto tem caracterı́sticas visuais únicas (e.g.
cor, textura, formato) no cenário observado. Corpos rı́gidos de coloração uniforme
podem ser detectados rapidamente por algoritmos de limiarização (threshold ) de
imagens e detecção de contornos [46]. A Figura 2.2 ilustra o resultado da detecção
de um sólido vermelho por limiarização.
19
(b) Imagem binarizada
(c) Objeto detectado
Figura 2.2: Procedimento de detecção de objetos por threshold de uma cor especı́fica.
Nesta abordagem, a escolha do sistema de cores para representação das imagens
é de fundamental importância. Como é argumentado em [47], o sistema de cores
RGB é mais indicado para detecção de objetos multicoloridos. No entanto, o RGB
também é mais sensı́vel à variações de iluminação e possui uma transição entre
pixels bastante ruidosa. Para reduzir a sensibilidade a estas variações, as imagens
analisadas podem ser convertidas para o sistema de cores HSV antes da detecção. O
algoritmo completo para limiarização da imagem é apresentado na Figura 2.3. Na
etapa de classificação, cada pixel é comparado com relação aos limites HSV inferior
e superior da cor procurada. Pixels fora desta região são convertidos para preto e os
demais para branco (Figura 2.2b). O contorno aproximado do objeto é detectado a
partir da imagem binarizada (Figura 2.2c). Finalmente, supondo que a câmera foi
posicionada no topo do robô e apontada para a frente, a posição relativa do objeto
pode ser determinada pela distância até o centro da imagem.
A principal vantagem da técnica de detecção por threshold é a relativa simplicidade do algoritmo. O sistema pode ser rapidamente implementado com OpenCV
[48] e também não requer uma fase treinamento para detecção. Dentre as principais
desvantagens, porém, estão uma grande sensibilidade à variações de iluminação e as
restrições com relação ao tipo de ambiente navegado. Estes fatores podem limitar o
20
Figura 2.3: Algoritmo de Limiarização de imagens para detectar um objeto de cor
especı́fica.
campo de aplicações possı́veis.
Para ambientes e objetos mais complexos, é comum utilizar técnicas de detecção
de caracterı́sticas locais invariantes (local scale invariant features) [49, 50, 51]. Algoritmos de extração de features, como são conhecidos, localizam caracterı́sticas do
objeto que são invariantes à rotação, translação e ao redimensionamento para localizá-lo em outras imagens. Estas caracterı́sticas são chamadas de pontos-chave
(keypoints) e compreendem regiões da imagem contendo cantos (corners). Inicialmente é extraı́do um conjunto de pontos-chave de uma imagem de treinamento
contendo apenas o objeto a ser detectado. Juntamente com a lista de pontos chaves, também são calculados uma série de descritores sobre a região ao redor de cada
ponto-chave. A etapa seguinte consiste em procurar os mesmos pontos-chaves e descritores do objeto nas imagens capturadas durante a navegação (imagens de busca).
Quando um número suficiente de combinações (matches) é atingido, o objeto é localizado. O contorno do objeto é determinado calculando uma matriz de homografia
que determina a transformação perspectiva entre a imagem de treinamento e a imagem de busca. A Figura 2.4 resume o procedimento de detecção por comparação de
21
features.
Figura 2.4: Algoritmo de detecção de objetos utilizando detecção de features.
Dentre os algoritmos mais comuns de extração de features estão o SIFT [50] e
suas variações. O SIFT é um algoritmo bastante robusto e de alta-precisão, resistente à variações de iluminação e oclusões parciais do objeto. No entanto, uma
das desvantagens do SIFT em ambientes embarcados é o custo computacional e,
consequentemente, o tempo de execução que ele demanda. Como alternativa, o
SURF (Speed-up Robust Features), proposto inicialmente em [51], é uma variação
do SIFT original que reduz consideravelmente o tempo necessário de processamento,
facilitando a aplicação da técnica em plataformas de baixo poder computacional. A
Figura 2.5a apresenta um exemplo de detecção de um objeto utilizando o SURF
como detector de features. Na Figura 2.5b o mesmo objeto é encontrado mesmo
estando parcialmente encoberto. Cabe ressaltar que a fase de treinamento do processo de extração de features, onde são detectados os pontos-chave e os descritores
do objeto alvo, precisa ser realizada apenas durante o inı́cio do procedimento.
22
(a)
(b)
Figura 2.5: Detecção de objetos por comparação de features.
2.1.3
Localização e Mapeamento
Auto-localização é uma habilidade fundamental para implementação de robôs móveis
autônomos. De maneira geral, ela está associada à solução de perguntas como: Onde
eu estou? Como cheguei aqui? E como faço para chegar até outro ponto? As respostas para estas questões estão diretamente relacionadas ao tipo de representação
do ambiente utilizada em cada projeto. O ambiente navegado é normalmente representado por um mapa com estrutura e informações inteligı́veis para o robô. Dentre
outros aspectos, o tipo de mapeamento determina como o robô “entende” a sua
posição atual e a do ponto de destino, assim como a lista de movimentos que ele
precisa executar para ir de um a outro. O formato e a posição dos obstáculos e das
rotas livres entre dois pontos também podem ser representados com mais ou menos
detalhes dependendo da estratégia de mapeamento escolhida. Existem várias estratégias de mapeamento disponı́veis para navegação, em sua maioria probabilı́sticas
e com diferentes nı́veis de precisão [?]. Dois exemplos de mapeamento comuns para
aplicações em ambientes internos e semi-estruturados são as grades de ocupação e
os mapas topológicos.
As grades de ocupação dividem o espaço global de navegação em pequenas áreas
de formato regular e com dimensões próximas a do robô. Cada pequena área é
classificada como ocupada, ou não, indicando por onde o robô deve transitar [52].
O mapeamento das áreas ocupadas pode ser feito previamente durante o projeto
do sistema, ou pelo próprio robô com base nas leituras de sensores. Neste caso,
23
as grades de ocupação são mais adequadas para sistemas cujos sensores oferecem
poucos detalhes geométricos sobre o ambiente, como os sonares [53].
Um mapa topológico, por sua vez, representa um determinado ambiente como um
grafo, onde os nós são pontos conhecidos e as arestas são representações abstratas
do caminho entre eles. Uma possı́vel vantagem dos mapas topológicos é que o
sistema não precisa conhecer a geografia exata do ambiente para determinar uma
aresta. Para navegar entre dois nós consecutivos, o robô precisa apenas saber em qual
aresta ele está e como manter-se sobre ela. Esta caracterı́stica dos mapas topológicos
facilita o mapeamento de novos ambientes. As Figuras 2.6a e 2.6b ilustram as duas
estratégias de mapeamento para um mesmo ambiente interno.
(a) Grade de ocupação
(b) Mapa topológico
Figura 2.6: Estratégias de mapeamento de um ambiente interno.
Uma vez determinada a forma de representação do ambiente, a habilidade de
auto-localização pode ser dividida em três problemas interdependentes:
1. Como determinar a posição atual do robô a partir da ponto inicial de partida
e do registro de todos os deslocamentos realizados até então?
2. Como determinar a posição atual do robô sem nenhum conhecimento prévio
sobre o ponto de partida ou a quantidade de deslocamentos?
24
3. Como mapear dinamicamente o ambiente à medida que ele é navegado?
O último ı́tem é necessário para assegurar uma maior autonomia para o robô
móvel. Um mapeamento prévio do espaço de navegação, embora facilite a implementação do sistema, acaba reduzindo a flexibilidade de aplicação em novos ambientes. A autonomia e a flexibilidade de navegação de um robô móvel crescem de
acordo com a sua habilidade de mapear dinamicamente novos ambientes. Nestes casos, o mapeamento é feito com base nas leituras do conjunto de sensores disponı́veis
no sistema à medida que ele navega.
O problema de como determinar a posição atual do robô em um mapa, por
sua vez, pode ser resolvido com o auxı́lio de técnicas de odometria, com o uso de
marcações no terreno, ou por aparência (i.e. estado) dos sensores. No primeiro caso
o sistema mantém um registro de todos os deslocamentos realizados pelo robô a
partir de uma posição inicial conhecida. É possı́vel cruzar as informações de deslocamentos com as medidas armazenadas no mapa para determinar a posição atual do
sistema. O procedimento depende principalmente de um sensor capaz de medir com
precisão os deslocamentos realizados. Uma desvantagem desta abordagem, porém,
é o erro acumulado pelas leituras após um certo tempo de navegação. Os registros
de deslocamento normalmente acumulam um erro devido às perdas causadas por
forças dissipativas e pela própria imprecisão dos sensores. De tempos em tempos
é necessário reiniciar o registro deslocando o robô para um ponto conhecido, ou
corrigindo o erro acumulado por realimentação de outros sensores.
Quando a posição inicial e o registro de deslocamentos do robô não são conhecidos, a localização atual do robô pode ser determinada com o auxı́lio de marcações
artificiais no terreno. Aplicações comuns desta abordagem utilizam marcações RFID
em pontos conhecidos, sendo cada tag associada à um nó do grafo topológico ou a
uma posição na grade de ocupação. No entanto, embora esta abordagem seja mais
flexı́vel do que o mapeamento prévio e completo do ambiente, ela ainda exige que o
cenário seja inicialmente “preparado” para o sistema de navegação.
Uma alternativa mais flexı́vel é determinar a posição do robô comparando o
estado atual dos sensores (aparência) com o estado esperado em cada ponto do mapa.
Sistemas de localização visual podem ser encaixados nesta categoria. Neste contexto,
algoritmos de extração e comparação de features podem ser utilizados em ambientes
25
parcialmente conhecidos [54, 55, 56]. Normalmente o procedimento é dividido em
duas fases: na primeira etapa são adquiridas diferentes imagens de pontos especı́ficos
do ambiente. Um conjunto de pontos-chave e descritores é extraı́do de cada imagem
durante o treinamento e armazenado em um banco de dados. Em seguida, durante
a navegação, o robô pode comparar imagens recém-adquiridas (candidatas) com
as imagens previamente armazenadas. Quando a comparação atinge um número
satisfatório de combinações (matches), o robô identifica que chegou a um lugar
conhecido. Esta abordagem também pode ser utilizada em sistemas de mapeamento
dinâmico, onde um robô pode ir montando um mapa de conexões entre os diferentes
pontos de referência à medida que vai atingindo cada um deles.
Uma dificuldade inerente às técnicas de localização por visão computacional é a
sensibilidade à rotações no ponto de vista do robô. Algumas comparações podem
falhar em situações em que o robô não está na mesma posição em que a imagem
de referência foi capturada. Para contornar este problema, é comum optar por
sistemas de visão omnidirecional para localização, como em [55] e [56]. Imagens
omnidirecionais são menos sensı́veis à rotações e também permitem que pontoschave permaneçam visı́veis por mais tempo.
Manter um fluxo de comparação de imagens compatı́vel com a velocidade de
navegação do robô também é um problema para este tipo de sistema. A necessidade
de extrair e comparar features em tempo de navegação pode ser desafiadora, mesmo
utilizando algoritmos mais eficientes como o SURF. Uma alternativa para melhorar
o desempenho nestes casos é apontada em [57], onde o conjunto inicial de imagens
candidatas é “filtrado” por um algoritmo de comparação mais simples antes de serem
submetidas ao SIFT. A distância euclidiana entre os histogramas das imagens recémcapturadas e das imagens previamente armazenadas serve de base para a seleção
inicial de candidatas. Somente imagens com uma pequena distância em relação
aos nós conhecidos são encaminhadas para o algoritmo de extração e comparação
de features. O cálculo de distâncias euclidianas tem um tempo de execução muito
menor comparado à extração de features, o que torna a filtragem inicial bastante
vantajosa.
26
2.2
Sistema de Navegação
O sistema de navegação proposto neste trabalho utiliza um Raspberry Pi modelo B
como plataforma para de processamento de imagens e controle de movimentação, e
um mini-veı́culo de tração diferencial montado a partir de um kit Lego Mindstorms
NXT, equipado com um microcontrolador Atmel AT91SAM7S256 de 32 bits. A
aquisição das imagens para controle de navegação é feita utilizando uma ou mais
CMUCam3, ou uma câmera especı́fica para Raspberry Pi. A comunicação entre
o Raspberry Pi e veı́culo NXT é via Bluetooth. Nesta seção serão apresentados o
modelo geral de arquitetura do sistema e modelo dinâmico do veı́culo diferencial.
2.2.1
Arquitetura do Sistema de Navegação
O modelo geral de navegação é composto pelos elementos apresentados na Figura 2.7.
A câmera é o componente responsável pela captura e compressão das imagens para
navegação. Nos modelos monocular e multicâmeras, ambos descritos no Capı́tulo 4,
as imagens são capturadas por uma ou mais CMUCam3. No modelo catadióptrico,
a captura das imagens é feita por uma câmera especı́fica para Raspberry Pi.
Figura 2.7: Divisão geral de arquitetura.
Uma vez capturadas, as imagens são encaminhadas para a unidade de controle
de navegação, o Raspberry Pi. É nesta unidade que são executados os algoritmos
de identificação de obstáculos, rastreamento de objetos e localização do robô. O
Raspberry Pi também controla o estado atual do veı́culo, isto é, a velocidade das
rodas, o ângulo de orientação e a posição global dentro do espaço de navegação.
Todas estas variáveis são definidas de acordo com a missão de navegação associada
ao robô.
O módulo de movimentação Lego NXT é responsável pelo acionamento dos mo-
27
tores de acordo com as informações enviadas pela unidade central de controle. O
controle de cada velocidade é feito a partir dos comandos enviados pelo Raspberry
Pi via Bluetooth. As mensagens trocadas ente a unidade de controle e veı́culo são
comandos de texto (em ASCII) definidos na Tabela 2.1. Após a realização de cada
comando, o Lego envia uma resposta ACK ao sistema de navegação indicando a
conclusão da tarefa. O Raspberry Pi pode escolher esperar ou não o sinal de ACK
de acordo com a necessidade, mas é preciso considerar que a velocidade de movimentação do robô é sempre muito menor do que a de processamento de novas
imagens. Esperar o sinal de sincronia ACK serve para garantir que nenhuma nova
imagem é capturada enquanto o robô esteja se movendo.
Tabela 2.1: Comandos de movimentação para controle do veı́culo Lego.
COMANDO
DESCRIÇÃO
HS
Configura os motores para alta velocidade (180◦ /s)
LS
Configura os motores para baixa velocidade (90◦ /s)
MV [D]
Movimenta o veı́culo em linha reta por uma distância D, em centı́metros
RO [A]
Rotaciona o eixo central do veı́culo por A graus
RS [A]
Configura a velocidade do motor direito para A graus por segundo
LS [A]
Configura a velocidade do motor esquerdo para A graus por segundo
ST
Para a rotação dos motores imediatamente
A separação fı́sica entre a unidade de controle e o tijolo (brick ) NXT facilita
a substituição futura do veı́culo, desde que seja mantido o protocolo de troca de
mensagens entre os componentes. A Figura 2.8 mostra um exemplo do procedimento
de troca de mensagens entre o Raspberry Pi e o Lego NXT.
O veı́culo Lego NXT é controlado por um sistema operacional Lejos [58], que
oferece uma interface de programação em Java para manipular sensores e atuadores
ligados ao sistema. Alguns dos principais métodos disponı́veis para controle de
rotação dos motores são:
• NXTRegulatedMotor.setSpeed(int x): configura a velocidade de rotação do motor à uma razão de x graus por segundo.
• NXTRegulatedMotor.rotate (int z): rotaciona o motor por um ângulo especificado pelo parâmetro z, em graus, a partir da posição atual.
28
Figura 2.8: Sequência de comunicação entre o Raspberry Pi e o tijolo Lego NXT
• NXTRegulatedMotor.forward (): faz o motor girar no sentido horário até que
um método de parada seja chamado.
• NXTRegulatedMotor.backward (): faz o motor girar no sentido anti-horário
até que um método de parada seja chamado.
A velocidade dos motores é definida em termos de graus por segundo. Cada roda
é ligada diretamente ao motor mantendo um plano perpendicular ao solo. O modelo
matemático de movimentação do veı́culo será descrito na próxima seção.
2.2.2
Modelo de Navegação
Um modelo do veı́culo de navegação é representado na Figura 2.9. O robô possui
tração diferencial e se movimenta sobre um plano 2D com três graus de liberdade.
A posição atual do robô em qualquer instante é definida como p(t) = (x, y, θ), com
relação à origem do plano global de referência para navegação. O ângulo θ, com
valores entre -π e π, indica a rotação do plano local do veı́culo com relação ao eixo
x do plano global. Uma discussão detalhada sobre o projeto de robôs móveis de
tração diferencial e sobre o modelo cinemático associado a eles pode ser encontrada
em [59].
O controle de movimentação do robô é feito a partir da diferença entre as velocidades lineares da roda esquerda (vE (t)) e direita (vD (t)). A velocidade de translação
29
Figura 2.9: Representação do veı́culo em um plano de navegação
do ponto central do eixo entre as rodas é definida pela Equação 2.1. O veı́culo se
movimenta realizando uma trajetória circular com um Centro Instantâneo de Curvatura (CIC) localizado a uma distância R do ponto central entre as rodas, como
mostra a Figura 2.10.
v(t) = (vD (t) + vE (t))/2
(2.1)
Figura 2.10: Representação do Centro Instantâneo de Curvatura (C.I.C.)
O raio R com relação ao Centro Instantâneo de Curvatura e a velocidade angular
de rotação podem ser determinados através das Equações 2.2 e 2.3, conhecendo-se
as velocidades instantâneas de cada roda. Quando as velocidades vD (t) e vE (t)
são iguais, o raio de curvatura é infinito e a velocidade angular é zero, o veı́culo
se movimenta em linha reta. Caso as velocidades sejam iguais, mas com sinais
contrários, o raio de curvatura é zero, fazendo com que o robô gire sobre o ponto
central entre as rodas. Finalmente, quando somente uma das rodas tem velocidade
30
zero, o raio de curvatura será L/2 (sendo L a distância entre as duas rodas) fazendo
com que o robô gire sobre a roda parada.
R(t) =
L vD (t) + vE (t)
×
2
vD (t) − vE (t)
(2.2)
vD (t) − vE (t)
L
(2.3)
ω(t) =
Conhecendo a velocidade linear das rodas e o ponto atual do veı́culo com relação
ao plano de referência global, é possı́vel determinar a posição futura do veı́culo
utilizando a posição do centro instantâneo de curvatura. A posição do CIC é determinada através da Equação 2.4. Determina-se a nova posição do veı́culo (p(t + δt))
através da Equação 2.5. Caso o robô esteja se movimentando em linha reta (R
infinito e ω = 0), a posição futura pode ser determinada de forma mais simples pela
Equação 2.6
CIC(t) = (x(t) − R sin(θ(t)), y(t) + R cos(θ(t)))
(2.4)


 

 
CICx
cos(ωδt) − sin(ωδt) 0
R sin(θ(t))
x(t + δt)


 

 


 

 
p(t + δt) = y(t + δt) =  sin(ωδt) cos(ωδt) 0 R cos(θ(t)) + CICy  (2.5)


 

 
ωδt
0
0
1
θ(t)
θ(t + δt)


 
x(t) + v(t) cos(θ(t))δt
x(t + δt)

 


 

p(t + δt) = y(t + δt) =  y(t) + v(t) sin(θ(t))δt 

 

θ(t)
θ(t + δt)
(2.6)
O modelo descrito até aqui assume o seguinte conjunto de restrições sobre o
veı́culo e o ambiente de navegação:
• O plano das rodas deve ser sempre vertical;
• Deve haver apenas um ponto de contato entre a roda e solo;
• Não pode haver deslizamento entre a roda e o solo;
• O movimento do veı́culo ocorre somente sobre o plano horizontal;
• As rodas não deformam;
31
• As rodas são unidas por um chassi rı́gido.
O modelo também desconsidera uma série de problemas do mundo fı́sico, especialmente o atrito entre a roda e o solo. As equações assumem que é possı́vel
determinar com precisão a velocidade de cada roda em qualquer instante. As velocidades instantâneas vD (t) e vE (t) dependem da velocidade angular ϕ e do raio r de
cada roda, de acordo com a Equação 2.7.
vx (t) = rx × ϕx
(2.7)
No entanto, esta relação pode ser comprometida por uma uma série de fatores
imprecisos, por exemplo: a potência aplicada aos motores, a carga da bateria, o
peso do veı́culo, o coeficiente de atrito do solo e pequenas deformações na roda.
Todos estes fatores têm impacto sobre a determinação da velocidade angular e do
raio, dificultando a realização de medidas com precisão. Como resultado o sistema
acumula um erro de posicionamento à medida que vai se deslocando no ambiente.
Após algum tempo de navegação as medidas previstas pelas equações cinemáticas
podem estar totalmente invalidadas, impondo a necessidade do robô atualizar sua
posição por meio de marcações ou outros mecanismos de localização.
32
Capı́tulo 3
Aquisição de Imagens
Omnidirecionais
Um panorama omnidirecional é uma imagem retangular com um campo de visão
horizontal de 360 graus. Imagens deste tipo possuem uma grande variedade de
aplicações em áreas como vigilância, monitoramento, telepresença e robótica. Hoje
em dia, uma grande quantidade de câmeras e telefones celulares oferece suporte
para a criação de panoramas omnidirecionais com extrema facilidade, estimulando
o surgimento de novas aplicações em diferentes áreas. Em robótica, sistemas de
navegação autônoma são uma das principais áreas de aplicação para imagens panorâmicas, beneficiando-se especialmente do amplo campo de visão oferecido por
elas. No entanto, apesar da popularização e da variedade de ferramentas disponı́veis
para a aquisição, alguns desafios ainda precisam ser superados. Como exemplo, é
possı́vel citar os problemas de captura e manipulação de panoramas omnidirecionais
em sistemas de pequeno porte que exigem altas taxas de aquisição. Os mecanismos
envolvidos nestas tarefas são computacionalmente caros e podem exigir um tempo
de processamento muito alto para aplicações de tempo real. A análise dos mecanismos envolvidos na aquisição destas imagens é importante para a otimização e a
eliminação de gargalos em sistemas de visão omnidirecional.
Há três formas tradicionais de obter um panorama omnidirecional:
1. Rotacionando uma única câmera em torno do seu centro óptico [60] (monocular);
33
2. Utilizando várias câmeras dispostas em cı́rculo, cada uma responsável por uma
fração angular do campo de visão (multicâmeras) [61];
3. Com uma única câmera com o centro óptico alinhado a um espelho convexo
(catadióptrico)[29].
Nos modelos monocular e multicâmeras, o panorama omnidirecional é obtido pela
concatenação de vários segmentos consecutivos em um mesmo plano; já no modelo
catadióptrico, o panorama retangular é obtido após a transformação (dewarping) da
imagem esférica capturada. Apesar das diferenças estruturais, o projeto de sistemas
de visão omnidirecional precisa considerar três fatores fundamentais [62]: a resolução
do panorama final; o campo de visão compreendido e o tempo total de aquisição.
Os modelos podem ser comparados entre si de acordo com estes elementos. Os
sistemas monocular e multicâmeras oferecem grande resolução e um campo de visão
ajustável, porém, normalmente exigem um tempo de aquisição mais longo. Já os
sistemas catadióptricos apresentam o menor tempo de aquisição, mas também as
menores resoluções. A escolha da estratégia de aquisição para um sistema de visão
é sempre um compromisso entre estes três fatores e, normalmente, é determinada
pelo tipo de restrições em cada aplicação.
Neste capı́tulo serão apresentados alguns fundamentos matemáticos para a montagem de um panorama omnidirecional. Os modelos monocular e multicâmeras
serão abordados da Seção 3.1 e os sistemas catadióptricos na Seção 3.2. Os detalhes
de implementação dos protótipos de cada modelo de aquisição serão apresentados
no Capı́tulo 4.
3.1
Concatenação de Segmentos (Image Stitching )
O processo de concatenação de segmentos consecutivos para montar um panorama
retangular é conhecido na literatura como image stitching. Como é ilustrado na
Figura 3.1, cada segmento corresponde a uma fração angular do campo de visão.
Ao final do processo todos eles são mapeados em um mesmo plano do panorama.
A resolução horizontal da imagem final é igual à soma das resoluções individuais,
menos as áreas de intersecção entre imagens adjacentes. O segmentos podem ser
obtidos com uma única câmera girando em torno do próprio centro óptico, ou com
34
múltiplas câmeras dispostas em cı́rculo. O campo de visão total do panorama pode
ser ajustado de acordo com o número de segmentos utilizados. A Figura 3.2 mostra um sistema comercial para captura de panoramas omnidirecionais por image
stitching.
Figura 3.1: Panorama retangular montado a partir de segmentos consecutivos
Figura 3.2: Dispositivo multicâmeras para aquisição de panoramas omnidirecionais
por image stitching (Ladybug2 [63])
Quando todos os segmentos são capturados em um mesmo plano cada quadro é
somente uma translação do quadro anterior. Neste caso, o processo de concatenação
consiste basicamente na eliminação das áreas de intersecção e no alinhamento das
imagens em sequência. Já no caso dos panoramas circulares, cada segmento é capturado em um plano diferente do anterior e para alinhá-los é necessário realizar
uma transformação projetiva em cada um deles [64]. Escolhendo uma das imagens
como plano base para o panorama, a transformação consiste em mapear todos os
pixels das imagens seguintes para o plano escolhido, de acordo com parâmetros de
rotação, deslocamento e escala previamente calculados. Sendo p = (x, y)T um ponto
qualquer de um segmento e p0 = (x0 , y 0 )T este mesmo ponto no plano do panorama,
a transformação pode ser representada pela Equação 3.1. A matriz H3×3 é denominada matriz de homografia e realiza uma transformação projetiva entre imagens
de planos diferentes. Os parâmetros da matriz de homografia são determinados pe35
las Equações 3.2 e 3.3, utilizando pontos de correspondência conhecidos entre duas
imagens.
  
 
x
h
h
h
x
   11 12 13   
  
 
p = y  × h21 h22 h23  y 
  
 
1
h31 h32 h33
1
h11 x + h12 y + h13
h31 x + h32 y + 1
h21 x + h22 y + h23
y0 =
h31 x + h32 y + 1
x0 =
(3.1)
(3.2)
(3.3)
Para determinar um conjunto de pontos de correspondência é necessário que
haja uma área de superposição entre duas imagens consecutivas. Um algoritmo de
extração de features, como o SIFT ou detector de Harris [65], pode ser utilizado para
determinar os melhores pontos de correspondência. No mı́nimo oito pontos precisam
ser encontrados para resolver todos os parâmetros da matriz de homografia.
Em um panorama omnidirecional composto por seis quadros consecutivos, cinco
homografias precisam ser determinadas. As matrizes são calculadas em pares com
relação ao plano da imagem escolhida como base. O procedimento é ilustrado na
A
) é determinada entre os seguimentos S1 e
Figura 3.3. A primeira homografia (H3×3
B
), por sua vez, é determinada entre o segmento S3
S2. A segunda homografia (H3×3
e o plano formado pelo panorama S1-S2. A terceira homografia é formada entre S4
e o plano S1-S2-S3 e assim por diante.
Figura 3.3: Cálculo de homografias em cadeia
O processo de montagem dos panoramas pode ser otimizado se a posição de
36
captura dos segmentos for sempre a mesma. Como a transformação projetiva leva em
consideração somente a posição dos pixels entre imagens consecutivas, e não o valor
em cada um deles, o cálculo das homografias precisa ser feito apenas durante a fase
de construção do sistema. Uma vez determinadas as homografias, e mantendo-se a
disposição angular das câmeras, todas as montagens posteriores podem ser feitas com
as mesmas matrizes. Como o cálculo das homografias é a etapa mais complexa do
processo, realizá-lo somente durante a calibração reduz consideravelmente o tempo
de montagem dos panoramas durante a utilização do sistema. Excluindo o tempo
de calibração e cálculo das matrizes de homografia, o tempo total de aquisição de
um panorama é determinado pelas seguintes caracterı́sticas:
• A velocidade de rotação mecânica da câmera (para sistemas monoculares apenas);
• O tempo de captura de cada segmento;
• O tempo de multiplicação de cada imagem pela matriz de homografia correspondente;
• O tempo de transmissão do panorama para fora do sistema de visão.
Cada uma destas caracterı́sticas pode representar um gargalo de desempenho
durante a utilização do sistema. Em arquiteturas monoculares, por exemplo, a velocidade de rotação da câmera representa uma desvantagem com relação à alternativa
multicâmeras. Outro problema são os possı́veis “fantasmas” que podem aparecer na
imagem devido à movimentação de objetos no ambiente durante a captura. Os sistemas multicâmeras, por outro lado, podem ser configurados para capturar todos os
segmentos simultaneamente, eliminando a necessidade de ter um ambiente estático.
Nestas arquiteturas os maiores impactos no desempenho são causados pelo tempo
de multiplicação das homografias e, principalmente, pelo tempo de transmissão dos
segmentos entre as câmeras. Em resumo, o projeto de sistemas de aquisição por
image stitcing deve identificar os elementos responsáveis por estes fatores e balancear a escolha de cada um deles, garantindo o desempenho mais adequado em cada
aplicação.
37
3.2
Remapeamento (Dewarping )
Combinando uma câmera simples com um espelho convexo é possı́vel obter uma
imagem omnidirecional polar (donut) como a mostrada na Figura 3.4a. Os espelhos utilizados podem ter formato esférico, cônico, parabólico ou hiperbólico, cada
um fornecendo uma imagem com geometria especı́fica. Conhecer a geometria de
formação da imagem esférica é importante para aplicação de diferentes técnicas de
visão computacional diretamente sobre elas (e.g. geometria epipolar adaptada [66],
algoritmos de extração de features [67], etc.). A abordagem mais comum, no entanto, é converter as imagens esféricas para um formato mais simples, normalmente
um panorama retangular como o mostrado na Figura 3.4b, e realizar o processamento sobre ele. Uma das vantagens deste formato é que ele pode ser manipulado
com coordenadas cartesianas ao invés de coordenadas polares da imagem original.
Outra vantagem é que o panorama retangular pode ser analisado com técnicas tradicionais de visão computacional, sem a necessidade de incorporar adaptações para
a geometria especı́fica do espelho utilizado.
(a) Imagem omnidirecional polar (donut)
(b) Panorama cilı́ndrico
Figura 3.4: Exemplos de imagens omnidirecionais obtidas por uma câmera catadióptrica
38
As Figuras 3.5a e 3.5b apresentam dois modelos conceituais para construção de
uma câmera catadióptrica. Na Figura 3.5a a luz incide inicialmente sobre a superfı́cie
esférica e é refletida na direção da lente da câmera. O modelo da Figura 3.5b é
composto por dois espelhos, a luz incide inicialmente sobre um espelho côncavo, é
refletida para um espelho plano no topo do arranjo onde é novamente refletida na
direção da lente da câmera. O modelo da Figura 3.5b pode ser implementado com a
lente de 360◦ para telefones celulares ilustrada na Figura 3.6. Embora a construção
do segundo modelo seja relativamente mais complexa que a do primeiro, as imagens
capturadas são similares. A utilização de arranjos industrializados como a Kogeto
Dot [68] elimina a necessidade de realizar um alinhamento manual entre os espelhos
e facilita a sua incorporação em robôs de pequeno porte.
(a)
(b)
Figura 3.5: Modelos de implementação de uma câmera catadióptrica
Figura 3.6: Lente de 360◦ Kogeto Dot [68].
Matematicamente, uma câmera catadióptrica pode ser representada por um modelo de câmera projetiva, como na Equação 3.4. A matriz M̂ é uma matriz de
projeção que mapeia um ponto p no mundo real para um ponto p0 no plano da
imagem; ela deve conter os parâmetros intrı́nsecos da câmera e a transformação
39
entre as coordenadas do mundo externo e coordenadas da câmera. Em sistemas
catadióptricos, porém, como a luz incide sobre o espelho antes de atingir a câmera,
uma função de transformação F precisa ser adicionada (Equação 3.5) para representar o ponto sobre a superfı́cie do espelho.
p0 = M̂ × p
(3.4)
p0 = M̂ × F (p)
(3.5)
Para espelhos hiperbólicos, elı́pticos e parabólicos, a função F pode ser definida
pelo modelo de projeção unificada proposto em [69]. Para os demais formatos, uma
função de transformação especı́fica precisa ser determinada. Uma discussão detalhada sobre modelos de projeção para câmeras catadióptricas pode ser encontrada
em [29, 70] e [71].
A transformação de uma imagem esférica em um panorama retangular requer
um processo chamado dewarping (ou unwarping em algumas referências), algo como
“desenrolar” a imagem esférica em tradução livre. O procedimento mapeia todos os
pixels Io (u, v) da imagem esférica para uma posição (I(x, y)) correspondente no panorama retangular. Existem três formas tradicionais de realizar esta transformação:
mapeamento direto (pano-mapping) [72]; geometria discreta [73]; e mapeamento logpolar [74]. Cada abordagem oferece diferentes resultados com relação ao tempo de
processamento e à resolução do panorama final [75]. O procedimento para dewarping adotado neste trabalho é uma variação do modelo de mapeamento direto, ele
é dividido em duas etapas:
1. Cálculo de uma matriz de mapeamento entre os pixels das duas imagens;
2. Transformação a partir da matriz de mapeamento;
Na primeira etapa é calculada uma matriz de mapeamento para todos os pares
(x, y) → (u, v)) de acordo com a Equação 3.6. O parâmetro R é uma função linear
de y, variando por todo o comprimento da área efetiva da imagem omnidirecional
(i.e. excluindo o cı́rculo interno e a borda). O parâmetro α, por sua vez, é uma
função linear de x variando de 0 à 2π. O ponto Io (uo , vo ) corresponde ao centro da
40
imagem esférica.
I(x, y) = Io (R cos(α) + uo , R sin(α) + vo )
(3.6)
Para cada posição (x, y) do panorama, é calculado um par de coordenadas (α, R),
que determina a posição (u, v) do pixel correspondente no donut. Todos os pares
(x, y) → (u, v)) são então posicionados em uma matriz MW xH para consulta em
todas as transformações futuras. Esta divisão de etapas é possı́vel porque os relacionamentos entre os pixels são construı́dos com base na posição de cada um, e não no
seu valor. A segunda etapa ocorre durante a utilização do sistema (e.g. navegação
do robô) e consiste basicamente em transferir os pixels de uma imagem para outra
de acordo com os relacionamentos da tabela de mapeamento direto.
A resolução final do panorama retangular é determinada pelas Equações 3.7 e
3.8, onde o comprimento W é igual à circunferência do cı́rculo externo e a altura
H é igual a diferença entre os raios externo e interno da imagem. Estes parâmetros
podem ser observados na Figura 3.7 que representa o processo de dewarping.
W = 2π ×
(Rout + Rin)
2
H = Rout − Rin
(3.7)
(3.8)
Figura 3.7: Ilustração do procedimento de transformação de uma imagem polar em
um panorama retangular (dewarping).
41
Capı́tulo 4
Análise de Modelos de Aquisição
A eficácia de um sistema de navegação autônoma pode ser diretamente dependente
do volume de informações que ele é capaz de coletar sobre o ambiente navegado.
Esta dependência é ainda mais importante em aplicações para ambientes desconhecidos e sem mapeamento. Nestes casos, a realização das tarefas fundamentais de
navegação (i.e. localização, planejamento de rotas e desvio de obstáculos) é inteiramente determinada pelos tipos de sensores disponı́veis no sistema. Quanto mais
informações o sistema puder adquirir sobre espaço ao redor, mais precisos podem
ser os cálculos de localização e desvio de obstáculos durante a trajetória entre dois
pontos. Mesmo em ambientes altamente estruturados, ou previamente mapeados,
o robô precisa de algum nı́vel de observação externa para que possa corrigir erros
acumulados durante a movimentação (e.g odometria, identificação de marcações por
RFID, etc.).
Dentre as diferentes alternativas de sensoriamento para aquisição de dados sobre
o espaço de navegação, os sistemas de visão computacional são especialmente poderosos. Algumas tarefas de navegação podem ser executadas com bastante eficiência
utilizando visão computacional, atraindo uma grande variedade de projetos [76].
Como exemplo destas tarefas é possı́vel citar algoritmos de identificação e desvio de
obstáculos, localização do veı́culo, mapeamento 3D do ambiente e rastreamento de
objetos de interesse. O principal apelo dos sistemas de visão, com relação às outras
formas de sensoriamento, é o grande volume de informações (e.g. textura, cores,
formas, presença ou ausência de objetos) que pode ser extraı́do de um único sensor.
O volume de informações adquiridas também é diretamente proporcional ao campo
42
de visão da câmera utilizada, o que torna os sistemas de visão omnidirecional, estudados no Capı́tulo 3, especialmente vantajosos. Sistemas de visão omnidirecional
podem ser construı́dos de três formas diferentes: com uma única câmera rotacionada
em torno de si mesma (monocular); com várias câmeras interligadas em um arranjo
circular (multicâmeras); com uma única câmera com o centro de imagem apontando
para um espelho convexo posicionado sobre ela (catadióptrico).
Neste capı́tulo serão descritos e comparados os três protótipos implementados
para esta análise de arquiteturas, um para cada modelo de aquisição. Inicialmente
será apresentada uma caracterização individual dos elementos de hardware utilizados na implementação dos protótipos (e.g. câmeras e unidade de controle). O
objetivo da caracterização é definir fatores importantes como taxas de transmissão
de dados, desempenho de software e interfaces de ligação. Com os resultados da
caracterização será possı́vel identificar alguns dos principais gargalos de cada arquitetura e propor alterações especı́ficas para melhorar o desempenho. Cada protótipo
implementado deve gerar, no menor tempo possı́vel, um panorama omnidirecional
do espaço ao redor do robô. As imagens produzidas em cada arquitetura serão
posteriormente submetidas à técnicas de localização e identificação de obstáculos e
objetos de interesse. Os resultados de cada arquitetura serão comparados entre si.
4.1
Caracterização dos Componentes de Aquisição
e Processamento
O modelo arquitetural básico para um sistema de navegação por visão computacional
é composto pelos três elementos mostrados na Figura 4.1. O fluxo de informações
parte dos sensores de captura de imagens, passa pela unidade central de controle e
termina nos atuadores do sistema de movimentação. Os procedimentos necessários
para cumprir o fluxo completo de informações podem ser centralizados em uma única
unidade de processamento, ou divididos entre vários módulos especializados.
A aquisição de imagens é feita a partir de uma ou mais CMUCam3, para os modelos monocular e multicâmeras, ou com um módulo de vı́deo para Raspberry Pi, para
o modelo catadióptrico. Após a aquisição, as imagens são encaminhadas para um
módulo Raspberry Pi para montagem do panorama omnidirecional, e realização de
43
Figura 4.1: Arquitetura genérica de um sistema de navegação por visão computacional
tarefas de localização e identificação de obstáculos. O módulo Raspberry Pi também
calcula e envia coordenadas para o terceiro componente de movimentação, neste caso
representado por um mini-veı́culo montado a partir de um kit Lego Mindstorms. A
adição do Raspeberry Pi possibilita a utilização de bibliotecas de alto nı́vel para
manipulação de imagens como o OpenCV.
A divisão da arquitetura em módulos especializados possibilita a identificação
precisa de gargalos para a otimização do fluxo de informações e tarefas do sistema
de navegação. As responsabilidades e limitações de cada componente são definidas
com clareza, facilitando a sua substituição por modelos mais eficientes.
4.1.1
CMUCam3
O hardware básico para aquisição de imagens utilizado foi a CMUCam3 [77, 78].
Dentre os recursos disponı́veis na câmera destacam-se: duas interfaces UART (Universal Asynchronous Receiver Transmitter ) para comunicação externa, um microcontrolador Philips LPC2106 (core ARM7TDMI-S), expansão para cartões MMC de
até 4GB e um sensor CCD Omnivision OV6620, com resolução máxima de 352x288
pixels e amplitude horizontal de 120 graus. Além disso, o sistema oferece uma ampla
biblioteca de software para aquisição, transmissão e pré-processamento de imagens.
Cada imagem adquirida pela CMUCam3 é transmitida através de uma das interfaces UART disponı́veis na placa. Os protocolos de transmissão são definidos de
acordo com as necessidades do projeto. A câmera pode ser configurada para capturar imagens em RGB, HSV, YCbCr, ou em escala de cinza. É preciso observar
que o sistema de cores escolhido tem influência direta sobre o tamanho da imagem
44
final e sobre o tempo total de transmissão, no entanto, a velocidade de transmissão
é determinada exclusivamente pela taxa de transferência da UART utilizada.
O sensor OV6620 também pode ser configurado para realizar ajustes de tempo
de exposição e balanço de branco automaticamente. A resolução máxima oferecida
pelo sensor é 352x288 pixels, no entanto, o sistema pode ser ajustado para realizar
sub-amostragens da resolução total de acordo com uma proporção predefinida. Ao
configurar, por exemplo, a proporção de sub-amostragem de 1 (horizontal) para 2
(vertical), a imagem de saı́da tem uma resolução de 352x144 pixels. Também é
possı́vel restringir a captura a apenas um canal de interesse por vez, ou seja, caso
a câmera esteja configurada em RGB é possı́vel realizar operações sobre um dos
três canais de cores apenas. Este recurso facilita especialmente a localização de
objetos especı́ficos pela cor, a extração de histogramas e o cálculo de informações
da frequência de um único canal.
A CMUCam3 pode embarcar diferentes algoritmos de pré-processamento, compressão, reconhecimento de padrões especı́ficos de imagem e controle servo-visual,
eliminando a necessidade de enviar uma imagem completa para fora do sistema de
visão. Em aplicações mais simples, todo o sistema de visão e controle pode ser
embarcado direto na CMUCam, a exemplo do Spoonbot [79], um pequeno robô
móvel de mesa controlado por vı́deo para seguir objetos de uma cor especı́fica. Outro projeto, o Firefly Mosaic [80], monta uma rede de visão distribuı́da a partir
de um conjunto de CMUCam acopladas a um módulo de rede sem fio. Dentre as
aplicações possı́veis do Firefly, são mencionadas a de vigilância contra incêndios e o
monitoramento à distância de idosos em ambientes domésticos.
As principais limitações das CMUCam3, no entanto, são as interfaces seriais para
entrada de saı́da de dados. A melhor taxa alcançada nos experimentos feitos para
estas interfaces foi de 115200 bits por segundo (bps), o que é particularmente lento,
sobretudo quando é necessário transmitir imagens coloridas com resoluções mais
altas. Considerando que um robô navegando por um ambiente desconhecido precisa
adquirir algumas imagens por segundo para garantir uma movimentação segura, as
baixas taxas de transferências de imagens são uma limitação considerável.
Para fins de caracterização do equipamento utilizado, inicialmente foram feitas
medidas de tempos de aquisição de imagens de diferentes formatos e resoluções.
45
Para este experimento uma CMUCam3 foi ligada a um computador pessoal através
de um adaptador USB-RS232. Para cada resolução configurada, foi feita uma bateria de testes com cinquenta aquisições consecutivas, medindo-se o tempo entre
cada uma delas. O objetivo do experimento é determinar quanto tempo leva para
transmitir uma imagem para fora da CMUCam3 via interface serial. O resultados
são mostrados nas Figuras 4.2a e 4.2b. Para as imagens RGB o tempo de aquisição
de cada canal de cores é, em média, um terço do tempo total.
(a)
(b)
Figura 4.2: Tempos de aquisição de um único quadro em uma CMUCam3 para
diferentes resoluções e formatos de imagem: a) 352x288 pixels; b)176x143 pixels.
Uma das formas de reduzir o impacto da baixa velocidade de transmissão é
tentar retirar da câmera sempre o menor número de informações possı́vel, em outras
palavras, atribuir ao microcontrolador embarcado um maior número de operações
de pré-processamento sobre as imagens capturadas. Um exemplo disso é comprimir
as imagens em JPEG antes de enviá-las. As Figuras 4.2a e 4.2b mostram que o
tempo de aquisição de imagens JPEG, já incluindo o tempo gasto para compressão,
é ainda menor do que o tempo gasto para transmitir uma imagem em escala de cinza.
Este raciocı́nio tenta estabelecer uma divisão adequada de carga entre as diferentes
46
unidades de processamento do sistema. Como estamos tratando de sistemas de
navegação de baixo custo, é fundamental definir quais cálculos devem ser executados
em cada componente e estabelecer a combinação mais eficiente possı́vel.
Tomando como exemplo o procedimento de identificação de obstáculos apresentado no Capı́tulo 3, é possı́vel avaliar a melhor divisão de carga entre a CMUCam e
a unidade central de controle. A tarefa consiste em diferenciar o obstáculo do solo
através da cor, desde que o objeto esteja à frente do robô. De maneira resumida,
o algoritmo para identificação de obstáculos por este método requer as seguintes
etapas:
1. Captura da imagem;
2. Suavização de ruı́dos, necessário para uma melhor detecção da área da imagem
que corresponde ao solo em torno do robô;
3. Preenchimento de solo com uma cor sólida a partir da posição do robô até a
primeira borda encontrada na imagem.
4. Cálculo de área de solo livre à frente do robô.
O primeiro experimento consiste em executar os passos 1 e 2 na CMUCam e
transmitir uma imagem comprimida (JPEG) para a unidade central de controle. A
suavização é feita aplicando um filtro média móvel à imagem original. A Figura 4.3
apresenta os tempos de aquisição de 50 imagens suavizadas e comprimidas antes do
envio, todas elas com resolução de 176x143 pixels.
Figura 4.3: Tempos de transmissão de um único quadro JPEG após filtro passabaixa (imagem suavizada).
O próximo experimento consiste em executar todas as etapas da identificação de
obstáculos na CMUCa3m, enviando para unidade de controle somente a informação
47
de espaço livre à frente do robô. Todos os cálculos necessários para implementação
desta tarefa são executados localmente, eliminando a necessidade de envio das imagens para fora da câmera. O objetivo desta avaliação é verificar o quanto do total
de operações necessárias para navegação pode ser executado com eficiência pela
CMUCam3. A divisão de carga será válida se o tempo necessário para identificar
obstáculos for menor do que o tempo necessário para transmitir a imagem e realizar a operação em uma unidade de processamento mais robusta. O procedimento
completo de identificação de obstáculos foi implementado em linguagem C e embarcado juntamente com firmware básico da CMUCam3. O ambiente montado para o
experimento é descrito a seguir:
• Em um ambiente com solo verde foi posicionado um obstáculo azul inicialmente
à 30 cm e depois à 60 cm da câmera;
• Para cada posição foram capturadas 50 medidas de distância entre a câmera
e o obstáculo. Cada captura é iniciada após o recebimento, via UART, de um
comando de identificação de obstáculos.
• Os comandos para identificação de obstáculos foram enviados por um computador pessoal ligado via RS232 à CMUCam, simulando uma arquitetura
descentralizada do sistema de navegação.
• Para cada captura foi medido o tempo entre o envio do comando de identificação pela unidade controle e o recebimento da informação de distância até
o obstáculo.
As Figuras Figuras 4.4a e 4.4b apresentam os tempos medidos para o cálculo de
50 distâncias para os cenários com obstáculos à 30 cm e à 60 cm, respectivamente.
A Figura 4.5, por sua vez, apresenta uma imagem após o processamento para o
obstáculo posicionado à 60 cm de distância.
48
(a) Obstáculo à 30 cm
(b) Obstáculo à 60 cm.
Figura 4.4: Tempo gasto pela CMUCam3 para calcular a distância até um obstáculo
posicionado à frente da câmera
(b) Obstáculo à 60 cm.
Figura 4.5: Resultado do procedimento de identificação de um obstáculo à 60 cm
para a CMUCam3
Os tempos de cálculo das distâncias (Figura 4.4) são maiores do que os tempos
de aquisição (i.e. captura, filtro e transmissão) das imagens suavizadas (Figura
4.3). Para que esta alternativa seja competitiva é necessário que estes valores sejam
menores do que os obtidos caso o restante do procedimento fosse realizado fora da
49
câmera, por um hardware mais rápido.
4.1.2
Raspberry Pi
O Raspberry Pi é uma famı́lia de computadores “de bolso” (credit-card-sized ) desenvolvido pela fundação Raspberry Pi britânica (Raspberry Pi Foundation), com
o propósito inicial de fomento ao ensino de computação básica nas escolas [37]. O
modelo original é um SoC (System on a chip) composto de um processador ARM
ARM1176JZF-S, de 700Mhz, e 512MB de memória RAM (para os modelos B e B+
apenas), capaz de executar sistemas operacionais de alto-nı́vel como o Linux. O
Raspberry Pi é um computador de propósito geral de baixo consumo e pequenas
dimensões, com um conjunto variado de periféricos e interfaces de comunicação,
dentre elas: Ethernet, USB 2.0, HDMI, SPI e UART.
O sistema combina as proporções fı́sicas e o consumo de energia comuns em sistemas embarcados de pequeno porte, com as facilidades oferecidas por computadores
pessoais. É esta combinação que o torna ideal para aplicações embarcadas que realizam tarefas de alta complexidade. Umas das principais vantagens oferecidas pelo
Raspberry Pi em sistemas de visão computacional é a possibilidade de utilizar bibliotecas de alto-nı́vel como o OpenCV embarcadas no sistema. Esta caracterı́stica
reduz a necessidade de distribuir o processamento para tarefas de navegação, por
exemplo, em computadores pessoais e servidores de grande porte.
Em todos os experimentos desta pesquisa foi utilizado um Raspberry Pi modelo
B [38] como unidade central de processamento para as tarefas de navegação. O
protótipo de câmera catadióptrica foi implementado utilizando um módulo de vı́deo
especı́fico para o Raspberry Pi. Os modelos monocular e multicâmeras, por sua vez,
utilizaram o Raspberry interligado a uma ou mais CMUCam3 através da interface
de comunicação UART.
O procedimento de caracterização do desempenho do Raspberry, dentro do escopo desta pesquisa, foi realizado medindo-se o tempo de execução da mesma tarefa
de identificação de obstáculos discutida na seção anterior. Interligando o Raspberry
Pi com a CMUCam3 é possı́vel modularizar o processamento necessário à identificação de obstáculos. A interface UART entre os dois módulos é limitada à uma
taxa de transferência de 115200 bps. Por conta disso, é preciso ajustar bem o vo50
Figura 4.6: Tempo gasto pela Raspberry Pi para calcular a distância até um
obstáculo posicionado à 60 cm da CMUCam.
lume de informações trocados entre os módulos para garantir a maior eficiência das
demais tarefas de navegação.
Para verificar o desempenho desta divisão de carga, repetimos o experimento
de identificação de obstáculos à distâncias fixas, mas agora realizando o procedimento de identificação inteiramente no Raspberry Pi. A CMUCam3, desta vez,
é responsável apenas pela captura e compressão das imagens, enviando-as em formato JPEG para processamento na unidade central de controle. Com relação a
primeira alternativa implementada em C como firmware da CMUCam3, este modelo é beneficiado pelo uso do OpenCV no Raspberry Pi. Com um posicionamento
das barreiras idêntico ao descrito na seção anterior (60 cm) os tempos medidos para
este experimento são mostrados na Figura 4.6.
Cabe ressaltar que os resultados apresentados na Figura 4.6 correspondem apenas
ao tempos de execução do procedimento, desconsiderando o tempo de transmissão
das imagens da CMUCam3 para o Raspberry Pi. O tempo médio de transmissão
de um quadro em JPEG, sem a filtragem de suavização, entre a CMUCam3 e o
Raspberry pode ser observado na Figura 4.2a, sendo aproximadamente 0,5 segundo.
Somando este tempo ao tempo médio da Figura 4.6 (0,35 segundo) o tempo total
necessário para a tarefa de identificação de obstáculos nesta configuração é de 0,85
segundo.
4.1.3
Análise dos Resultados da Caracterização
Comparando os resultados obtidos para identificação de obstáculos da Seção 4.1.1
com o tempo gasto pelo Raspberry Pi para a mesma tarefa, é fácil observar que
51
o segundo apresenta uma melhor alternativa para o problema de interligação e divisão de carga. A CMUCam, embora seja muito versátil, possui baixo poder de
processamento e pouca memória disponı́vel para a realização de operações complexas sobre imagens. Outra desvantagem é que o projetista deve encarregar-se da
programação das rotinas necessárias para os procedimentos de computação visual,
otimizando cada algoritmo às limitações da arquitetura da câmera, sobretudo à falta
de memória para alocar imagens com resolução acima de 173x143 pixels. Utilizando
somente a CMUCam, embora ela disponibilize em seu firmware básico algumas
funções elementares de manipulação (e.g. convolução 2D, extração de histograma,
equalização, e compressão JPEG), o desenvolvedor estaria impossibilitado de utilizar ferramentas consolidadas como a biblioteca OpenCV. Finalmente, a CMUCam
apresenta uma séria limitação de comunicação com o mundo externo que é a interface serial UART como taxa máxima de transferência de 115200 bps. Esta limitação
é um gargalo importante para a realização de tarefas cujo tempo de resposta precisa
ser inferior à 1 segundo, por exemplo. Para contornar este problema é necessário
tomar medidas impactantes para a navegação, como reduzir a resolução das imagens
capturadas.
O melhor desempenho da interligação foi atingido quando a operação da CMUCam foi restrita à simples captura e compressão das imagens, sendo o restante do
processamento realizado no Raspberry Pi com auxı́lio da biblioteca OpenCV. A partir deste ponto a análise das arquiteturas seguintes irá considerar este modelo de
interligação.
4.2
Aquisição de Panoramas Omnidirecionais
Como descrito no Capı́tulo 3, um panorama omnidirecional pode ser obtido através
da concatenação de vários quadros consecutivos, cada um cobrindo uma fração angular dos 360◦ de amplitude horizontal, ou “desenrolando” (dewarping) uma imagem
obtida a partir de uma câmera catadióptrica. Nesta seção serão apresentados os
protótipos dos três métodos de aquisição, tendo em vista a aplicação de cada um no
contexto da navegação de dispositivos robóticos. Em todos os protótipos o principal
objetivo é montar um panorama omnidirecional para experimentos de navegação.
52
Nos modelos monocular e multicâmeras, os panoramas podem ser montados nas
próprias CMUCam3, ou no módulo central de processamento, o Raspberry Pi. No
modelo catadióptrico a captura e a montagem do panorama omnidirecional é feita
inteiramente no Raspberry Pi.
4.2.1
Arquitetura Monocular
O primeiro modelo implementado consiste em uma única câmera presa a um eixo
móvel ligado à um motor de passos simples, como ilustrado na Figura 4.7. A câmera
gira em torno do eixo vertical, capturando um quadro à cada passo do motor. O
controle dos passos do motor é determinado pelo software embarcado na câmera.
Após o recebimento de um comando para inı́cio da montagem de um panorama
omnidirecional, a CMUCam3 incrementa os passos do motor sempre após a captura
de cada quadro. A velocidade de movimentação do motor precisa ser compatı́vel com
o tempo de montagem do panorama a partir dos segmentos individuais capturados
durante a rotação. Neste protótipo cada quadro é capturado com um intervalo de
um segundo entre um passo e outro. Para que sempre haja uma área de superposição
entre dois quadros adjacentes, foi determinado um passo de 30◦ para este modelo.
Figura 4.7: Modelo monocular para aquisição de imagens omnidirecionais.
Nos modelos baseados em image stitching, as matrizes de homografia são calculadas durante a fase de projeto. A incorporação delas ao sistema é feita em duas
53
etapas: na primeira etapa, uma imagem de cada posição angular é capturada e enviada ao computador pessoal, onde as matrizes são calculadas utilizando o OpenCV.
Em seguida, as matrizes são registradas e incorporadas ao firmware da CMUCam3
para utilização. Como o deslocamento angular das imagens é sempre fixo, as matrizes não precisam ser recalculadas durante a operação do sistema, apenas aplicadas.
O procedimento de montagem do panorama retangular pode ser dividido em duas
etapas: 1. captura dos segmentos individuais e 2. concatenação (image stitching).
A etapa de concatenação pode ser realizada na própria CMUCam3, ou na unidade
central de controle. No primeiro caso, cada segmento é inicialmente armazenado
em um cartão de memória com a marcação da posição em que foi capturado. A
câmera realiza o procedimento de concatenação e envia o panorama completo para
a unidade central de controle. Uma segunda alternativa é enviar todos os quadros
para o Raspberry Pi já comprimidos em JPEG. A ligação entre a CMUCam3 e
o Raspberry Pi é via UART com uma taxa de transmissão de 115200 bps. No
Raspberry Pi o software de controle recebe os quadros na ordem correta e concatena
todos eles em um panorama retangular. Esta alternativa só é vantajosa se o tempo
de transmissão e concatenação no Raspberry Pi for menor do que o tempo de captura
e concatenação na CMUCam3. A Figura 4.8 apresenta os tempos de montagem dos
panoramas para cada estratégia. A Figura 4.9, por sua vez, apresenta um exemplo
de panorama obtido com protótipo monocular.
Figura 4.8: Tempos de aquisição e montagem de um panorama no protótipo monocular
O tempo de aquisição de um panorama neste modelo pode ser reduzido aumentando a velocidade de rotação do motor de passos. Para passos de 30◦ , com um
intervalo de um segundo entre todos eles, são consumidos em média doze segundos
54
(a) Panorama Omnidirecional
(b) Quadros individuais
Figura 4.9: Exemplo de panorama omnidirecional montado pelo protótipo monocular
para cobrir a circunferência somente com a rotação do protótipo.
4.2.2
Arquitetura Multicâmeras
A arquitetura monocular apresenta inconvenientes óbvios para aplicação em navegação robótica. O primeiro deles é a necessidade parar o veı́culo para montar
cada panorama. Como a câmera precisa ser rotacionada, o veı́culo precisa estar
parado para que as matrizes de homografia não sejam invalidadas. O tempo total
de aquisição também é limitado pela rotação do motor, como foi visto na seção anterior. Em um contexto de navegação automática esta alternativa tem um espaço
muito restrito de aplicações, apresentando como vantagens com relação às demais
uma menor complexidade de comunicação e a alta resolução dos panoramas finais.
O modelo multicâmeras, por sua vez, mantém a estratégia de captura de vários
55
segmentos independentes da arquitetura monocular, adicionando a vantagem da
aquisição simultânea. O resultado oferecido continua sendo um panorama omnidirecional de alta resolução, porém com maior robustez contra a movimentações do
veı́culo durante a aquisição. Um sistema de arranjo circular deve ser construı́do de
forma que haja uma superposição de uma parte do campo de visão de cada câmera
com relação aos seus adjacentes à esquerda e à direita. Como a CMUCam3 tem
uma amplitude horizontal de aproximadamente 120◦ , seis câmeras são suficientes
para cobrir a circunferência, mantendo 30◦ de superposição entre duas câmeras consecutivas. Aproveitando as duas interfaces de comunicação UART disponı́veis em
cada CMUCam3, é possı́vel interligar o arranjo de três formas: a) em estrela, b) em
barramento com árbitro central e c) em cadeia (daisy chain); Os três modelos de
interligação são apresentados nas Figuras 4.10a, 4.10b e 4.10c .
(a) Estrela
(b) Barramento
(c) Daisy Chain
Figura 4.10: Modelos de interligações multicâmeras
A interligação em estrela requer a adição de um microcontrolador central com
pelo menos seis interfaces UART de comunicação, que servirá de ponte entre a
unidade central de controle e as câmeras. A interface entre o microcontrolador
central e a unidade de controle do sistema de navegação (Raspberry Pi) pode ser
via USB, Wifi, ou Ethernet, todas elas com taxas de transmissão muito superiores
à da UART. Para adquirir cada quadro do panorama final, a unidade de controle
envia um comando ao microcontrolador central que, por sua vez, o reencaminha
para uma câmera especı́fica. Como cada quadro solicitado precisa fazer o caminho
de volta da câmera para o microcontrolador e deste para a unidade de controle, o
tempo médio para a aquisição de todos os seguimentos do panorama omnidirecional
56
é de pelo menos seis vezes o tempo de aquisição de cada quadro (desprezando-se o
tempo de envio entre o microcontrolador e a unidade de controle).
A implementação do protótipo em estrela apresenta inúmeras dificuldades e a
primeira delas é encontrar no mercado um microcontrolador com caracterı́sticas tão
peculiares como as seis interfaces de comunicação UART. Mesmo atendendo a este
requisito, o modelo proposto continua extremamente rı́gido e com pouca escalabilidade. Uma alternativa mais eficiente de interligação é unir todas as linhas Tx
(transmissão) das câmeras em um mesmo barramento multiplexado, ilustrado conceitualmente na Figura 4.10b, e com mais detalhes na Figura 4.11. Neste modelo,
a linha Tx do microcontrolador principal é distribuı́da entre todas as câmeras, enquanto as linhas Tx das câmeras são multiplexadas por um CI 74LS151, de oito
canais para um (Figura 4.11). Quando o microcontrolador solicita um quadro, ele
inicialmente envia um comando de captura contendo um endereço da câmera correspondente. Embora todas as câmeras recebam a solicitação, apenas aquela cujo
endereço foi especificado envia o quadro como resposta. O microcontrolador deve
configurar os bits de seleção do multiplexador para a linha adequada da câmera
requisitada.
Figura 4.11: Modelo de barramento multiplexado com 3 CMUCam3 e um 74LS151
Um protótipo do modelo em barramento foi construı́do interligando três CMUCam3, utilizando uma delas como árbitro. A câmera C1 é configurada como árbitro
do sistema e tem como responsabilidades a coordenação da aquisição dos quadros
das outras duas e a montagem do panorama omnidirecional. Os bits de seleção
do multiplexador estão ligados aos pinos de GPIO (General Purpose Input-Output)
disponı́veis na CMUCam3. Para solicitar um quadro à câmera C2, por exemplo, a
57
câmera C1 realiza o seguinte procedimento:
1. Configura os bits de seleção para o valor especı́fico da linha da câmera C2;
2. Envia o comando “GET-FRAME C2” através da interface serial;
3. Lê o quadro recebido na linha Rx da interface serial;
4. Armazena o quadro recebido no cartão de memória.
Foi realizado um experimento para medir os tempos de montagem e transmissão
de um panorama de 180◦ neste modelo. Inicialmente, foram medidos os tempos
de transmissão dos quadros das câmeras C2 e C3 para a câmera C1, e desta para
os Raspberry Pi. Nesta primeira etapa não foram incluı́dos os procedimentos de
montagem do panorama (i.e. transformações de homografia), somente o tempo
de transmissão dos quadros. Todos os segmentos capturados possuem resolução
de 176x143 pixels e estão em escala de cinza. O tempo médio de aquisição foi
de aproximadamente 2,5 segundos. Com exceção da primeira câmera do arranjo,
cada novo dispositivo adicionado acrescenta um tempo médio de 1 segundo para
transmissão do quadro associado a ele. A Equação 4.1 resume o tempo médio para
capturar todos os quadros em um arranjo com N câmeras. A constante k é o tempo
médio para a transmissão de um quadro em JPEG nesta resolução e tem um valor
aproximado de 0,5 segundo. Este valor foi medido experimentalmente e pode ser
observado na Figura 4.2a.
T = k + 2 × k(N − 1)
(4.1)
A Figura 4.12 apresenta os resultados para a aquisição de 20 panoramas consecutivos, todos montados no Raspberry Pi. Note que as matrizes de homografia foram
calculadas durante a calibração, cabendo a Raspberry somente o cômputo da transformação afim. O tempo médio de transmissão dos três quadros foi de 2,5 segundos,
já o tempo médio total para a montagem do panorama foi de 4,2 segundos.
Finalmente, no modelo daisy chain as câmeras são ligadas entre si em cadeia,
mostrado na Figura 4.10c. Cada câmera é ligada à sua esquerda através da primeira
UART (UART0), e à sua direita através da segunda UART (UART1). No inı́cio da
cadeia, a primeira câmera se conecta ao mundo externo pela UART0 e age como
58
Figura 4.12: Tempos de transferência e montagem de um panorama de 180◦ . Segmentos JPEG com resolução de 176x143.
árbitro das transmissões. Para adquirir o segmento correspondente a última câmera,
por exemplo, o árbitro deve enviar uma solicitação que atravessa toda a cadeia e cuja
resposta deve fazer caminho inverso até o primeiro nó. O procedimento é ilustrado
na Figura 4.13.
Figura 4.13: Solicitação de quadro no modelo daisy chain
Em cada salto um tempo médio de 0,5 segundo é necessário para transmitir
uma imagem em JPEG com resolução de 176x143 pixels. O primeiro segmento leva
então 0,5 segundo para ser transmitido da primeira câmera à unidade de controle.
O segundo seguimento, por sua vez, deve ser transmitido para a primeira câmera
(0,5s) e novamente para à unidade de controle (mais 0,5s). Finalmente, um terceiro segmento deve ser transmitido sucessivamente através de todos os saltos até o
Raspberry Pi. O tempo de aquisição de um único panorama cresce em progressão
59
aritmética com número de câmeras no arranjo em daisy chain, como descrito pela
Equação 4.2.
T =k×
(N + N 2 )
2
1≤N ≤6
(4.2)
A Figura 4.14 apresenta os tempos de transmissão e montagem de um panorama
retangular de 180◦ a partir de três segmentos individuais. Neste caso, cada quadro
foi enviado para o Raspberry Pi ligado à primeira câmera do arranjo via UART.
Na Figura 4.15 é mostrado um exemplo de um dos panoramas montados nesta
arquitetura.
Figura 4.14: Tempos de transmissão e montagem do panorama de 180 graus (3
câmeras) em daisy chain
(a) Panorama
(b) Quadros individuais
Figura 4.15: Panorama de 180◦ montando a partir de um arranjo de 3 CMUCam3
em daisy chain
60
4.2.3
Arquitetura Catadióptrica
O protótipo da câmera catadióptrica foi montado utilizando um Raspberry Pi B
como hardware básico para processamento, um módulo de vı́deo para Raspberry
Pi [81] e uma lente de 360◦ Kogeto Dot [68]. A lente Kogeto Dot foi posicionada
sobre o módulo de vı́deo que, por sua vez, é conectado ao Raspberry Pi via SPI.
O protótipo é similar ao modelo omnidirecional apresentado em [82], que também
utiliza a Kogeto Dot como espelho. A captura e manipulação básica das imagens
pode ser feita com uma biblioteca de software oferecida pela Fundação Raspberry Pi
escrita em Python (PiCamera). Os procedimentos mais complexos para navegação
são também implementados em Python utilizando OpenCV.
A taxa de aquisição da câmera varia de acordo com a resolução das imagens.
Utilizando a PiCamera foi possı́vel capturar imagens RGB de 480x480 em um tempo
médio de 0,58s por imagem. As Figuras 4.16a e 4.16b mostram uma imagem esférica
capturada pelo protótipo e o panorama retangular após o processo de dewarping,
respectivamente.
O procedimento de dewarping constrói uma matriz de correspondência entre todos os pontos da imagem polar e todos os pontos do panorama retangular. O cálculo
da matriz de correspondência leva em conta somente a posição relativa de cada pixel
nas duas imagens e não a intensidade deles. Essa condição permite que a mesma
matriz possa ser reutilizada em qualquer imagem obtida pela câmera, reduzindo o
tempo necessário para a montagem de um panorama durante a navegação. Para
imagens esféricas com resolução de 480x480, o tempo médio para cálculo da matriz de correspondência no Raspberry Pi é de aproximadamente 81 segundos. Esta
etapa precisa ser feita somente durante a primeira captura do protótipo. Uma vez
calculada a matriz de correspondência, a etapa seguinte é o transporte dos pixels
do donut para o panorama retangular. Esta etapa dura em média 0,21 segundos e
pode ser realizada durante o tempo de navegação para cada novo donut capturado.
A Figura 4.17 apresenta os tempos de dewarping medidos para uma série de 20
capturas sucessivas neste protótipo. Neste experimento a matriz de correspondência
foi calculada previamente e seus valores foram armazenados em um arquivo de texto.
À cada nova imagem esférica capturada, o sistema utiliza a mesma matriz para gerar
um panorama omnidirecional.
61
(a) Imagem esférica (donut)
(b) Panorama após o dewarping
Figura 4.16: Imagem esférica capturada pelo protótipo catadióptrico (a) e panorama
omnidirecional (b).
4.2.4
Comparação dos Modelos de Aquisição
Apesar das diferenças estruturais entre os modelos de aquisição apresentados nas
seções anteriores, é possı́vel compará-los de acordo com alguns critérios essenciais
em sistemas de visão computacional, por exemplo: o campo de visão oferecido, a
resolução das imagens e o tempo de aquisição de cada uma delas. A relevância individual destes critérios pode variar de acordo com a aplicação desejada, possibilitando
que um mesmo modelo seja apropriado para um determinado tipo de aplicação e
inadequado para outras.
Os modelos monocular e multicâmeras possuem um tempo de aquisição muito
alto para aplicações de navegação em tempo real, isto é, onde o robô precisa analisar
o cenário à medida em que vai navegando. Por outro, a resolução dos panoramas
oferecidos por estes modelos é superior à do modelo catadióptrico, o que pode ser
fundamental em tarefas de rastreamento de objetos, por exemplo. Para sistemas de
processamento offline de imagens os modelos de image stitching são normalmente a
62
Figura 4.17: Tempo de geração de um panorama retangular a partir de uma imagem
esférica de 480x480 pixels
melhor escolha, diferentemente dos sistemas de processamento em tempo real, como
os de navegação.
Para melhorar o desempenho de aquisição das arquiteturas monocular e multicâmeras é possı́vel reduzir os tempos de transmissão e processamento das imagens
utilizando equipamentos mais eficientes. As interfaces de comunicação UART disponı́veis nas CMUCam3, por exemplo, representam uma grande limitação para o
desempenho geral destes sistemas devido às baixas taxas de transmissão. O tempo
de transmissão dos segmentos, mesmo comprimidos, representa uma grande parcela
do tempo total de aquisição dos panoramas e pode ser reduzido com uso de interfaces
mais rápidas. Outra alternativa é reduzir o volume de informações trocadas entre
as câmeras, no entanto, esta solução exige também que parte do processamento seja
feita localmente, o que não se mostrou vantajoso com o microcontrolador embarcado na CMUCam3 (Seção 4.1.3). Em resumo, as seguintes melhorias devem ser
aplicadas aos modelos multicâmeras e monocular para torná-los compatı́veis com as
restrições de navegação em tempo real:
1. Substituir a interface de comunicação externa (UART) por modelos de maior
velocidade (SPI, USB, Firewire, etc.);
2. Substituir o microcontrolador da câmera por um de melhor desempenho;
3. Reduzir o volume de informações transmitidas entre as câmeras;
Em sistemas de navegação em tempo real e com baixo desempenho, o tempo de
aquisição e processamento das imagens é um critério importante para a escolha do
modelo de aquisição. Neste contexto o modelo catadióptrico representa uma grande
melhoria com relação aos demais. Com uma única captura o robô visualiza todo o
63
espaço ao seu redor, reduzindo as perdas com a transmissão e o alinhamento das
imagens. O tempo de dewarp foi inferior a meio segundo e pode ser melhorado ainda
mais com a utilização de modelos mais recentes do Raspberry Pi. Apesar disso,
a resolução oferecida por este modelo pode ser um fator limitante para algumas
tarefas de navegação. Algoritmos de limiarização e extração de features podem ser
consideravelmente limitados pela baixa resolução oferecida. A principal alternativa
para contornar este problema é a utilização de sensores e espelhos mais eficientes. No
caso especı́fico do protótipo implementado neste trabalho, um ajuste da distância
focal da câmera utilizada seria necessário para aumentar a resolução da imagem
polar. Como a lente Kogeto Dot é ajustada para câmeras de iPhone, a combinação
artesanal entre ela e a câmera do Raspberry Pi, que possui distância focal fixa, não
é ideal para obter a melhor resolução.
O campo de visão de cada modelo também pode ser ajustado de acordo com a
necessidade da aplicação. No modelo monocular o campo de visão pode ser reduzido ou ampliado de acordo com o número de passos realizados pelo motor. Nos
protótipos multicâmeras o mesmo resultado pode ser obtido aumentando ou diminuindo o número de câmeras. Finalmente, para ajustar o campo de visão no modelo
catadióptrico é necessário segmentar o panorama em regiões de interesse.
A Tabela 4.1 resume os resultados obtidos para cada modelo de acordo com os
critérios de resolução e tempo de aquisição. Os modelos de barramento e daisy chain
foram construı́dos para uma resolução angular de apenas 180◦ . Uma estimativa dos
tempos de transmissão para panoramas de 360◦ pode ser obtida através das Equações
4.2 e 4.1. Para os modelo de barramento o tempo de transmissão em um arranjo de
seis câmeras sobe para 5,5 segundos (de acordo com a Equação 4.1), enquanto no
modelo daisy chain esse valor atinge 10,5 segundos (Equação 4.2).
O modelo catadióptrico foi o único que apresentou um tempo de aquisição inferior
a um segundo, o que o torna mais adequado para aplicações de navegação em tempo
real, ainda assim, de baixa velocidade. O veı́culo robô utilizado neste trabalho é
capaz de mover-se com uma velocidade média de 7cm/s, o que sugere que as imagens
precisam ser processadas em menos de um segundo para que o robô possa manter
uma distância mı́nima de 7cm de qualquer obstáculo. O modelo catadióptrico,
portanto, será utilizado como sistema de aquisição de imagens omnidirecionais para
64
Tabela 4.1: Resumo dos tempo de aquisição e montagem de panoramas em cada
modelo arquitetural
Modelo
Quadros
Resolução do Panorama
Transmissão (s)
Montagem (s)
Monocular
12
912x143
12
1,7
Estrela
-
-
-
-
Barramento*
3
228x143
2,5
1,7
Daisy Chain*
3
228x143
3,1
1,7
1
1262x192
0,58
0,21
Multicâmeras
Catadióptrica
◦
* Protótipos de 180 .
os experimentos de navegação apresentados no próximo capı́tulo.
65
Capı́tulo 5
Experimentos de Navegação
A principal responsabilidade de um sistema de navegação visual é fornecer ao robô
uma série de comandos de movimentação com base no que foi observado sobre espaço
ao seu redor. O sistema de navegação coleta e interpreta imagens do ambiente e determina os movimentos seguintes de acordo com alguma estratégia de movimentação
pré-estabelecida. O objetivo geral de movimentação é o que define como e para onde
o robô deve se mover, justificando decisões tomadas ao longo do caminho. Exemplos comuns de objetivos de navegação são: seguir uma linha no chão, percorrer
um corredor até encontrar uma marcação especı́fica, localizar e seguir um objeto
conhecido, transitar de um ponto a outro de um mapa, etc. Cada objetivo tem nı́vel
de complexidade especı́fico, assim como um conjunto de restrições que determina
qual deve ser a melhor abordagem para a aquisição de imagens.
Um outro fator decisivo para a implementação de qualquer estratégia de navegação é o grau de conhecimento que o sistema possui sobre o ambiente navegado.
Em ambientes totalmente mapeados a estratégia de movimentação consiste em determinar a posição atual do robô e calcular a melhor trajetória através do mapa
até um ponto de destino. Um mapa de navegação é normalmente descrito como um
grafo, onde os nós representam pontos conhecidos e as arestas são os caminhos entre
eles. O robô deve conhecer o caminho a ser percorrido, podendo determinar com antecedência todas as manobras que precisam ser realizadas para alcançar um destino.
Algoritmos de planejamento de rotas podem ser utilizados para otimizar a escolha
das trajetórias. O sistema de visão, nestes casos, serve para realimentar o sistema
de controle, corrigindo erros de posicionamento e atualizando a localização do robô.
66
Ele é prescindı́vel caso o robô não acumule erros de posicionamento e odometria, ou
disponha de outras formas de verificar quando chegou a um nó do mapa.
Em ambientes não mapeados, por outro lado, o sistema de visão é uma peça fundamental para implementar a estratégia de navegação. A partir de um determinado
objetivo (e.g. localizar e seguir uma bola vermelha), o robô decide como se movimentar com base no que ele pode observar, reagindo à marcações e obstáculos ao
longo do caminho. Conhecendo a estratégia geral de navegação, o sistema de visão
também pode selecionar nas imagens somente um conjunto útil de informações, descartando informações desnecessárias e reduzindo o volume de processamento.
Os experimentos apresentados neste capı́tulo consideram o ambiente navegado
como parcialmente mapeado, ou totalmente desconhecido. O objetivo dos experimentos é demonstrar a viabilidade da utilização da arquitetura catadióptrica de
aquisição em um contexto de navegação autônoma. O modelo catadióptrico foi escolhido por apresentar o melhor desempenho de aquisição e uma menor complexidade
de construção. Além de mais rápido que os demais, o modelo catadióptrico também
é mais compacto fisicamente e possui um menor consumo de energia. Estas caracterı́sticas facilitam a sua integração ao robô móvel de pequeno porte descrito neste
capı́tulo.
Os experimentos realizados foram:
Rastreamento de objetos: Com o auxı́lio do algoritmo descrito na Seção 2.1.2,
o sistema deve ser capaz de localizar um sólido vermelho no campo de visão
omnidirecional, estimar a distância e rotação do objeto com relação ao robô e
movimentar o veı́culo até ele;
Mapeamento incremental: Utilizando o algoritmo de detecção do solo descrito
na Seção 2.1.1, o sistema deve ser capaz de identificar a posição de obstáculos
em sua trajetória e construir dinamicamente um mapa topológico do ambiente
navegado;
Localização: Utilizando algoritmos de extração de features para comparação de
imagens atuais com pontos previamente mapeados do cenário, o sistema deve
ser capaz de determinar se está ou não em um local conhecido e atualizar as
tabelas de planejamento de rotas a partir desta informação. O experimento
67
utiliza as estratégias de mapeamento topológico e comparação de features descritos na Seção 2.1.3.
Os experimentos de localização por comparação de features e mapeamento incremental foram inspirados nos experimentos realizados em [25], [83] e [84], onde os
autores apresentam uma série de resultados para mapeamento topológico de ambientes externos por comparação de imagens omnidirecionais. O sistema apresentado
é capaz de montar dinamicamente um mapa topológico do ambiente comparando
a visão atual do robô com imagens de pontos conhecidos previamente armazenadas. Uma abordagem semelhante para ambientes internos pode ser encontrada em
[85]. Neste trabalho adaptamos o escopo dos experimentos para ambientes internos
e controlados, reduzindo consideravelmente a complexidade das análises.
Na Seção 5.1 são apresentados os detalhes de construção do robô móvel e sua
integração com o sistema de visão. Também são apresentadas as caracterı́sticas
do cenário montado para realização dos experimentos de navegação. Na Seção 5.3,
por sua vez, é apresentado um experimento para estimar o raio médio das rodas
do robô móvel, com o objetivo de reduzir os erros acumulados de deslocamento
durante a navegação. O modelo de movimentação e as equações para controle de
deslocamentos também são apresentados nesta seção.
5.1
Cenário e Protótipo de Navegação
O veı́culo montado para navegação segue o modelo matemático estabelecido no
Capı́tulo 2, utilizando um kit Lego Mindstorms NXT. O protótipo completo é ilustrado na Figura 5.1a e suas dimensões são detalhadas nas Figuras 5.1b, 5.1c e 5.1d.
A lente Kogeto Dot para visão omnidirecional foi posicionada de cabeça para baixo
para que o robô tivesse uma boa visão do solo ao seu redor.
68
(a)
(b)
(c)
(d)
Figura 5.1: Protótipo de veı́culo de tração diferencial para navegação
A Figura 5.2 apresenta um panorama omnidirecional obtido pela câmera já posicionada sobre o robô. As hastes de sustentação da câmera podem servir de marcação
na imagem para demarcar os limites das regiões à frente, à esquerda, à direita e ao
fundo do veı́culo. Esta divisão pode ser útil para segmentar o panorama em regiões
de interesse e reduzir o tempo de processamento sobre elas.
Figura 5.2: Panorama omnidirecional capturado pelo protótipo de navegação
Todos os experimentos de navegação foram realizados sobre um piso emborrachado de 2m × 2m de cor verde, como ilustra a Figura 5.3. A padronização da
cor e da textura do solo é importante para melhorar a precisão dos algoritmos de
69
identificação de objetos por cor. Ela também ajuda a reduzir o impacto dos ruı́dos
causados por variações na iluminação do cenário, fator de significativa importância
devido à baixa resolução dos panoramas do modelo catadióptrico.
(a)
(b)
Figura 5.3: Piso padronizado para os experimentos de navegação
5.2
Arquitetura de Software
O software para de controle de navegação necessário para a realização dos experimentos foi implementado em linguagem Python e embarcado na unidade central
de controle (Raspberry Pi). A Figura 5.4 ilustra a organização geral do programa
que é organizado em camadas de acordo com o escopo e a funcionalidade de cada
componente.
A camada de controle de navegação ((Navigation Control ) contém os pontos de
entrada do software para cada experimento. Ela é responsável pela criação e sincronização das diferentes tarefas de navegação (Navigation Tasks). Como exemplo
destas tasks estão os objetos responsáveis pela detecção de obstáculos, mapeamento
incremental e comparação de imagens para localização. Cada um destes componentes utiliza os módulos das camadas inferiores para captura e análise dos panoramas
omnidirecionais.
A comunicação com o robô móvel é feita através de uma camada especı́fica
de comunicação (Comm) que encapsula os drivers de acesso a uma porta serial e
emulada sobre uma interface dispositivo bluetooth. O sistema também contém uma
camada para registro de informações de navegação e relatórios de experimentos
70
(Log/Database).
A Figura 5.5 apresenta um diagrama de classes dos principais componentes implementados e suas relações.
Figura 5.4: Arquitetura geral do software para controle de navegação.
Figura 5.5: Diagrama de classes do sistema de controle de navegação.
5.3
Caracterização para Odometria
Uma das dificuldades da implementação de robôs móveis é manter a compatibilidade
entre as distâncias que robô deve percorrer e as que ele realmente percorre. Devido a
71
ação de diferentes forças dissipativas, bem como às imprecisões inerentes ao controle
dos motores, é esperado que o sistema acumule um erro entre o deslocamento real e
o estimado, especialmente após um certo tempo de navegação. Este erro acumulado
dificulta a implementação dos algoritmos de localização baseados estritamente em
odometria.
No robô móvel implementado neste trabalho, os comandos para o deslocamento
são calculados como uma função de um ângulo de rotação dos motores a partir da
posição atual. Por exemplo, para uma dada velocidade angular ϕ de rotação dos
motores, para deslocar o veı́culo por uma distância D em linha reta, é necessário
girar os motores por um ângulo α a partir da posição atual. É possı́vel determinar
a distância percorrida D através da Equação 5.1, conhecendo-se a velocidade linear
vr (t) dos pneus, o ângulo α de deslocamento a partir da posição atual e velocidade
angular ϕ dos motores. O problema oposto para o sistema de navegação é decidir
qual o ângulo de rotação α deve ser aplicado aos motores para deslocar o robô por
uma distância D. Em ambos os casos a solução só é possı́vel conhecendo o valor do
raio das rodas do sistema.
D = vr (t) ×
α
ϕ
D = (r × ω) ×
r=
α
ϕ
D
α
(5.1)
(5.2)
(5.3)
Para minimizar os efeitos causados pelas imprecisões das deformações e do atrito
causados pelo contado entre os pneus e solo, o raio das rodas não pode ser medido
diretamente com paquı́metro, e sim estimado experimentalmente. O procedimento
adotado para estimar a medida dos raios leva em consideração a razão descrita pela
Equação 5.3, que relaciona uma distância D de translação em linha reta e o ângulo
α aplicado aos motores pelo firmware do sistema. O procedimento consiste nas
seguintes etapas:
1. Estabelecer uma velocidade angular ϕ fixa para os dois motores;
2. Posicionar o motor sobre a origem do plano de navegação;
72
3. Rotacionar os dois motores por vários ângulos α entre 60◦ e 720◦ (deslocamento
angular);
4. Para cada deslocamento angular anotar a distância percorrida em linha reta
pelo veı́culo;
5. Calcular um valor de raio r de acordo com a Equação 5.3 para cada par (D, α);
6. Calcular a média aritmética de todos os valores r encontrados.
O procedimento foi repetido com velocidades de 90 graus/segundo (π/2 rads/s) e
180 graus/segundo (π rads/s). Para cada velocidade foram realizados doze deslocamentos angulares entre 60◦ e 720◦ . O raio médio das rodas em cada velocidade pode
ser determinado como a média aritmética das doze medidas de raio. Os resultados
das medidas de distância e o raio médio em cada velocidade são exibidos nas Figuras
5.6a e 5.6b.
(a) 90 graus/s
(b) 180 graus/s
Figura 5.6: Medidas de distância percorrida para cada ângulo de rotação em função
do deslocamento angular
Uma vez determinado o raio médio e conhecendo a velocidade angular de rotação
dos motores, é possı́vel determinar a velocidade linear vr (t) em centı́metros por
segundo de cada roda de acordo com a Equação 5.4. Para a velocidade angular de
73
π/2 rads/s a velocidade linear estimada foi de 6, 18 cm/s, enquanto para π rads/s o
valor foi de 12, 59 cm/s.
vr (t) = r × ϕ
(5.4)
Dado um ponto à uma distância D à frente do robô, e conhecendo o raio médio
das rodas, é possı́vel calcular o deslocamento angular necessário para cobrir esta
distância com relativa precisão. Quando o ponto de destino não está à frente do
veı́culo, porém, é preciso utilizar técnicas de planejamento de trajetória. Sistemas
de controle por realimentação são normalmente utilizados para este tipo de planejamento [86, 87]. Neste trabalho, optamos por uma alternativa mais simples de
movimentação. Em cada deslocamento, o robô inicialmente alinha o ângulo de orientação (θ) com o ponto de destino para, em seguida, se movimentar em linha reta
até ele. Caso algum obstáculo seja encontrado no caminho, o robô realiza uma manobra de contorno e procura uma nova orientação em direção ao ponto de destino.
Para um ponto de destino q = (Qx , Qy ) no plano de navegação, o vetor direção
até o robô é definido pela Equação 5.5. A inclinação β que deve ser adotada pelo
robô é definida pela Equação 5.6. Para alinhar a orientação θ do veı́culo com o
vetor direção, o robô precisa realizar uma rotação γ definida na Equação 5.7. Após
o alinhamento, a distância necessária até o ponto q é o módulo do vetor direção,
definido na Equação 5.8.
  

dx
Qx − x

dˆ =   = 
dy
Qy − y
dx
)
dy
(5.6)
−π < γ ≤ π
(5.7)
d2x + d2y
(5.8)
β = tan− 1(
γ = β − θ,
D=
q
(5.5)
74
5.4
O procedimento para rastrear um objeto de cor especı́fica foi inicialmente explicado
na Seção 2.1.2, no Capı́tulo 2 desta dissertação. O algoritmo isola a região correspondente ao objeto no campo de visão do robô por um processo de limiarização
de cores. Dois limites de cores (i.e. HSV inferior e HSV superior) determinam a
coloração do objeto procurado e são configurados como informações de entrada. Em
seguida, o algoritmo classifica toda a imagem como dentro ou fora desta região,
binarizando a imagem inicial. O resultado da limiarização é uma imagem binária
que pode ser utilizada para estimar a posição do objeto com relação à parte frontal
do robô. A principal restrição para este procedimento é a necessidade do objeto ter
uma cor única com relação ao ambiente.
O objetivo do experimento descrito nesta seção é fazer o robô identificar uma
esfera vermelha de aproximadamente oito centı́metros de diâmetro para, em seguida,
aproximar-se dela em linha reta. A movimentação do robô após a localização da
esfera no panorama omnidirecional é divida em duas etapas:
• Rotação: o sistema rotaciona o veı́culo para alinhar a frente dele com a posição
da esfera.
• Translação: o sistema calcula a distância até a esfera e envia um comando ao
veı́culo para deslocamento em linha reta.
O ângulo α de rotação inicial do robô para alinhamento é determinado pela
Equação 5.9, onde W é a resolução horizontal da imagem e xb é a coordenada
horizontal do centro da esfera. De uma extremidade a outra do panorama o sistema
tem uma variação angular de 360◦ (i.e. 180◦ à −180◦ ), valores negativos de α indicam
que o objeto está posicionado à direita do centro da imagem, enquanto os valores
positivos indicam que ele está à esquerda. A escala de rotação é ilustrada na Figura
5.7.
α=
−360 × xb
+ 180
W
(5.9)
Após o alinhamento inicial o robô deve realizar uma translação até que esteja
a uma distância aproximada de 20cm. A distância relativa do robô até a esfera é
75
Figura 5.7: Escala de rotação a partir do centro do panorama retangular
estimada com base na distância (em pixels) do centro da esfera detectada até um
ponto no centro inferior da imagem, correspondente à frente do veı́culo. A relação
entre a distância em pixels e a distância real foi determinada experimentalmente a
partir de uma série de posições conhecidas. Os resultados são apresentados na Tabela
5.1. Para cada distância real a distância na imagem foi medida cinquenta vezes.
Uma distribuição normal foi montada com os resultados e os valores médios foram
utilizados para determinar o polinômio de ajuste da Equação 5.10. O polinômio
determina uma distância dist em centı́metros a partir do valor p em pixels. A
dispersão dos valores médios e o polinômio de ajuste são ilustrados no gráfico da
Figura 5.8. Na Tabela 5.1 também é possı́vel observar que quanto mais distante o
objeto é posicionado do veı́culo, menor é a taxa de detecção do algoritmo, caindo
para menos de 50% após um metro.
Tabela 5.1: Relação entre a distância real do objeto e a distância em pixels da
imagem
Distância (cm)
Distância na Imagem (Pixels)
Desvio padrão (Pixels)
Taxa de Detecção (%)
20
11
5
100
25
31
4
100
30
33
5
95
35
41
3
95
40
48
4
90
45
52
4
90
50
54
4
85
60
55
3
85
70
57
3
76
80
58
1
62
90
57
1
49
100
58
1
45
dist(p) = 1, 2942e − 005p5 − 0.0021635p4 + 0, 13775p3 − 4, 1152p3 + 56, 99p3 − 262, 71
(5.10)
76
Figura 5.8: Calibração do algoritmo para determinar a distância até o objeto detectado
O algoritmo de rastreamento foi verificado posicionado o mesmo objeto em quatro
pontos diferentes do campo de navegação, como mostra a Figura 5.9. O robô foi
posicionado no centro da arena e suas medidas foram comparadas com a distância
real do objeto. O objetivo do experimento é verificar se o sistema é capaz de:
1. Identificar a esfera em seu campo de visão, estimando o ângulo de rotação com
relação à frente do robô e a distância de translação até ele;
2. Alinhar a frente do veı́culo na mesma direção do objeto detectado;
3. Deslocar o robô até que ele esteja a uma distância de aproximadamente 20cm
do objeto.
Figura 5.9: Localização dos objetos para rastreamento
Uma verificação do alinhamento do robô é feita antes de cada translação. O
sistema foi configurado para realizar uma rotação somente quando o deslocamento
77
da bola com relação ao centro do panorama é maior que cinco graus. O controle de
alinhamento do robô busca minimizar o ângulo com relação ao objeto até que ele
esteja no intervalo entre zero e cinco graus. O algoritmo de controle de movimentação
do rastreamento é ilustrado na Figura 5.10, ele foi implementado em Python 2.7 e
executado no Raspberry Pi.
Figura 5.10: Algoritmo para controle de movimentação do rastreamento
Devido à posição da câmera no robô, objetos à menos de vinte centı́metros
não são visualizados. A distância percorrida em cada translação é sempre o valor
estimado menos vinte centı́metros (i.e. distância mı́nima de segurança). A Tabela
5.2 relaciona as medidas reais de distância, as distâncias em pixels e as estimadas
pelo polinômio de ajuste (Equação 5.10). O tempo médio de cada detecção foi de
1,23 segundo.
A Figura 5.11 apresenta as imagens obtidas pelo robô ao longo do caminho e a
trajetória realizada por ele.
78
Tabela 5.2: Relação entre a distância real e a distância estimada pelo algoritmo de
detecção de objetos
Distância na Imagem (px)
Dist. Real (cm)
Dist. Estimada (cm)
Erro (cm)
Erro (%)
13
20
28
-8
40
28
25
24
1
4
32
30
26
4
13
40
35
35
0
0
48
40
38
2
5
47
45
38
7
16
51
50
42
8
16
56
55
65
-10
18
56
60
65
-5
8
57
65
75
-10
15
55
70
58
12
17
58
75
87
-12
16
56
80
65
15
19
57
85
75
10
12
57
90
75
15
17
58
95
87
8
8
57
100
75
25
25
79
(a) Posição A
(b) Posição B
(c) Posição C
(d) Posição D
Figura 5.11: Trajetórias de rastreamento
80
5.5
Mapeamento Incremental
Para o experimento de mapeamento dinâmico o espaço de navegação foi mapeado
em uma grade de ocupação de acordo com a Figura 5.12a, com quadrados de 40cm
de lado. O centro de cada quadrado corresponde a um nó (i.e. pontos Sj,k ) do
grafo de navegação, representado pelo mapa topológico (S5×5 ) ilustrado na Figura
5.12b. Para navegar pela grade de ocupação o robô deve sempre seguir as arestas
de interligação entre os nós, atualizando constantemente sua posição e o ângulo
θ de orientação em relação ao sistema de coordenadas de referência. Todas as
rotações realizadas devem ser de 90◦ , -90, ou 180◦ , sendo proibida a movimentação
em diagonal entre os nós. O objetivo do experimento é navegar de um ponto a outro
do mapa identificando quais nós estão preenchidos por obstáculos. Para identificar os
obstáculos ao redor do veı́culo, o sistema de visão incorpora o algoritmo de detecção
descrito na Seção 2.1.1, do Capı́tulo 2, com algumas adaptações para o sistema de
visão omnidirecional.
(a) Grade de ocupação
(b) Grafo
Figura 5.12: Grade de ocupação do cenário e grafo de representação do ambiente
para mapeamento dinâmico
5.5.1
Detecção de Obstáculos
A detecção de obstáculos utilizada no mapeamento dinâmico baseia-se na segmentação das imagens capturadas em dois componentes: solo e obstáculos. O solo
é identificado pelo sistema como um grande componente conexo que começa ime81
diatamente após o robô (i.e. ponto O(W/2, H/2)) no centro inferior da imagem)
em todas as direções. Tudo o que está fora deste componente é classificado como
obstáculo. Conhecendo a área de solo livre ao redor do veı́culo é possı́vel determinar
a melhor forma de se mover através dele evitando colisões. A eficácia do algoritmo
é baseada em duas suposições sobre o ambiente a ser navegado, uma sobre o solo
e outra sobre os obstáculos. A primeira suposição é a de que o solo é plano e tem
coloração e textura uniformes, a segunda é a de que não há obstáculos suspensos.
Atendendo estas duas restrições o sistema pode identificar a área de solo livre até
um obstáculo e estimar a distância até ele como uma função direta do número de
pixels no solo.
Inicialmente, o panorama omnidirecional é dividido em cinco regiões, cada uma
correspondendo à uma seção do campo de visão. Em cada região é delimitada uma
área trapezoidal de segurança equivalente à vinte centı́metros de distância da borda
do veı́culo, os trapézios são ilustrados na Figura 5.13a. Uma amostra da cor do
solo é retirada no ponto central de cada trapézio e armazenada na memória. É
importante que o robô seja inicialmente posicionado em uma área sem obstáculos
na região de segurança, assegurando que as amostras coletadas são realmente do
solo. Em seguida o algoritmo “inunda” (flooding) a imagem a partir dos pontos de
amostragem, convertendo todos os pixels de valor próximo ao do solo para uma cor
sólida. Uma série de linhas de verticais são traçadas em espaços regulares partindo
da altura (i.e. coordenada y) de cada amostra até a borda do componente. O
comprimento em pixels de cada linha pode ser utilizado para determinar a distância
até o primeiro obstáculo naquela região da imagem. O resultado é ilustrado na
Figura 5.13b. Caso alguma dessas retas termine dentro do trapézio de segurança, o
robô identifica que aquela região tem um obstáculo muito próximo, e escolhe outra
direção. Na Figura 5.13b a direção escolhida é sinalizada com um cı́rculo azul.
O robô deve se movimentar sempre pela distância delimitada por um trapézio de
segurança livre de obstáculos. O comprimento dos trapézios foi escolhido de forma
que o veı́culo também possa fazer rotações sem colidir as laterais.
82
(a) Trapézios de segurança
(b) Detecção de solo
Figura 5.13: Resultado do procedimento de detecção de obstáculos
5.5.2
Planejamento de Rota
O planejamento de rota é feito com auxı́lio do algoritmo de Dijkstra para definir
o menor caminho entre dois nós de um grafo. O algoritmo inicialmente define um
peso unitário para cada aresta livre do grafo. A distância entre dois pontos do mapa
é definida como a soma dos pesos das arestas da trajetória escolhida. O algoritmo
avalia os caminhos possı́veis e retorna sempre o que oferece a menor distância.
Partindo de uma posição inicial S1×1 , com θ = 0, o robô calcula a primeira
trajetória assumindo que não há obstáculos no espaço de navegação. Durante trajetória, o robô utiliza o procedimento de detecção de obstáculos para verificar se
o próximo nó do caminho está livre ou ocupado. Caso esteja ocupado ele atualiza
a matriz de adjacências e calcula uma nova trajetória a partir do ponto atual. Se
próximo nó não estiver ocupado, ele avança 40cm em direção a ele. Não há garantia
de que o sistema possa mapear todos os obstáculos do posicionados no espaço de
navegação. Para isso seria mais eficiente forçar o robô a visitar todos os nós do
grafo. No entanto, quanto mais distantes estiveram a origem e o destino escolhidos,
maiores são as chances do sistema recalcular as rotas iniciais e, consequentemente,
visitar mais pontos do mapa.
5.5.3
Resultados de Mapeamento
Os obstáculos foram posicionados como mostra a Figura 5.14. O robô foi posicionado
no nó S1,1 , com θ = 0 e o destino escolhido foi o nó S5,1 . Os obstáculos cobrem os
nós: S1,3 , S2,5 , S3,1 , S3,2 , S3,3 , S5,3 , S5,4 e S5,5 .
O robô não tem conhecimento prévio sobre a posição das barreiras, por conta
83
Figura 5.14: Obstáculos para o experimento de mapeamento dinâmico
disso a primeira rota calculada é: S1,1 → S2,1 → S3,1 → S4,1 → S5,1 , como mostrado
na Figura 5.15a. Ao atingir o nó S2,1 , o robô percebe a presença de um bloqueio no
nó seguinte e atualiza a matriz de adjacências removendo a aresta entre eles. Com
o grafo atualizado, o sistema calcula uma nova rota até o destino, como mostrado
na Figura 5.15b. Uma nova rota é calculada toda vez que o veı́culo encontra um
bloqueio, o processo se repete até que o veı́culo atinja o nó de destino por um
caminho livre de obstáculos (Figura 5.15c). O grafo final representa um mapa do
ambiente com regiões que podem ou não serem navegadas.
A Tabela 5.3 apresenta todas as rotas calculadas pelo veı́culo até atingir o nó de
destino neste experimento. Os nós marcados como bloqueados contém obstáculos
identificados pelo robô. O tempo de cálculo de cada rota também é apresentado
na tabela. A Figura 5.16, por sua vez, apresenta alguns exemplos da visão do robô
durante o percurso. Os pontos vermelhos nas imagens da Figura 5.16 indicam os
pontos de intersecção entre o solo e os obstáculos identificados pelo algoritmo de
detecção.
84
(a)
(b)
(c)
Figura 5.15: Exemplo de rotas calculadas até o nó de destinoS5,1
Figura 5.16: Visão do robô durante o mapeamento
85
Tabela 5.3: Cálculo e atualização de rotas no grafo de navegação
Atual
Próximo
Bloqueado
Rota
Re-cálculo (ms)
Ângulo (◦ )
◦
-90◦
S1,1
S2,1
Não
S1,1 → S2,1 → S3,1 → S4,1 → S5,1
-
0
S2,1
S3,1
Sim
S2,1 → S3,1 → S4,1 → S5,1
2
-90◦
-
◦
S2,1
S2,2
S2,1 → S2,2 → S3,2 → S4,2 → S5,2 → S5,1
Não
Rotação (◦ )
0◦
-90
90◦
◦
S2,2
S3,2
Sim
S2,2 → S3,2 → S4,2 → S5,2 → S5,2 → S5,1
2,3
0
-90◦
S2,2
S2,3
Não
S2,2 → S2,3 → S3,3 → S4,3 → S4,2 → S5,2 → S5,1
-
-90◦
90◦
S2,3
S3,3
Sim
S2,3 → S3,3 → S4,3 → S4,2 → S5,2 → S5,1
2
0
-90◦
S2,3
S2,4
Não
S2,3 → S2,4 → S3,4 → S4,4 → S4,3 → S4,2 → S5,2 → S5,1
-
-90◦
90◦
S2,4
S3,4
Não
S2,3 → S2,4 → S3,4 → S4,4 → S4,3 → S4,2 → S5,2 → S5,1
-
◦
◦
-90◦
0
◦
S3,4
S4,4
Não
S2,3 → S2,4 → S3,4 → S4,4 → S4,3 → S4,2 → S5,2 → S5,1
-
-90
S4,4
S4,3
Não
S2,3 → S2,4 → S3,4 → S4,4 → S4,3 → S4,2 → S5,2 → S5,1
-
-90◦
S4,3
S4,2
Não
S2,3 → S2,4 → S3,4 → S4,4 → S4,3 → S4,2 → S5,2 → S5,1
-
0◦
-90◦
◦
0◦
◦
-180
S4,2
S5,2
Não
S2,3 → S2,4 → S3,4 → S4,4 → S4,3 → S4,2 → S5,2 → S5,1
-
-180
90◦
S5,2
S5,1
Não
S2,3 → S2,4 → S3,4 → S4,4 → S4,3 → S4,2 → S5,2 → S5,1
-
-90◦
-90◦
5.5.4
Discussão
A Figura 5.17 apresenta o grafo de representação do ambiente obtido após o final do
percurso de mapeamento. É possı́vel observar que somente as arestas identificadas
como bloqueio durante o percurso é que são removidas do grafo de representação do
ambiente. A precisão da representação final é proporcional ao número de bloqueios
que o robô foi capaz de identificar durante o percurso. No trajeto apresentado, a
partir do nó S2,4 o veı́culo não encontra mais arestas bloqueadas até o ponto de
destino. O único obstáculo identificado foi o que cobre os vértices S3,1 , S3,2 e S3,3 .
Uma forma de aumentar a cobertura do mapeamento seria forçar o robô a visitar
todos os nós do grafo de representação.
Figura 5.17: Grafo atualizado após o percurso
Uma outra limitação encontrada é o fato de que o robô não considera as rotações
necessárias na trajetória antes de escolher entre duas rotas com a mesma distância.
86
Por exemplo, quando o robô atinge o nó S4,2 , com orientação de −180◦ , ele escolhe
o caminho S4,2 → S5,2 → S5,1 , executando uma rotação a mais do que se tivesse
escolhido o caminho S4,2 → S4,1 → S5,1 . Uma forma de solucionar este problema é
utilizar pesos adicionais em arestas que exigem rotações, dada a orientação do atual
do robô.
Outro problema associado à este experimento é erro acumulado de odometria
durante o percurso. Quanto maior é a distância percorrida pelo robô, mais significativos se tornam os pequenos erros acumulados em cada rotação ou translação. Após
um certo tempo de navegação, a posição do robô deixa de corresponder à posição
esperada, inviabilizando a adoção de estratégias de mapeamento de todos os nós do
grafo.
5.6
Localização
O experimento de mapeamento dinâmico de obstáculos apresentado na seção anterior pressupõe que o robô conhece a sua posição inicial no mapa topológico. Durante
a execução de uma determinada rota, o robô determina a sua posição atual com base
em registro de todos os movimentos realizados desde o ponto de partida. Corrigindo
os erros de odometria, o sistema é capaz de determinar sozinho quando atinge cada
nó do percurso até o ponto de destino. O que fazer, no entanto, quando a posição
inicial do veı́culo não é conhecida inicialmente? A habilidade para determinar a
posição do robô com base na aparência atual dos sensores, ou seja, sem o registro
anterior de movimentação, é um dos ı́tens fundamentais dos problemas de localização, discutidos no Capı́tulo 2.
Nesta seção realizamos um experimento para determinar a localização atual do
robô móvel com base em um conjunto de imagens associadas à diferentes nós do mapa
topológico. O objetivo final do algoritmo de localização implementado é determinar
se o robô está ou não sobre um nó previamente mapeado. O sistema de visão
executa um algoritmo de extração e comparação de features para determinar qual
imagem do banco de dados mais se assemelha à da posição atual. O nó atual é
identificado quando um número mı́nimo de matches entre duas imagens é atingido.
Para detecção de pontos-chave e descritores na imagem foi utilizado o algoritmo de
87
extração ORB (Oriented FAST and Rotated BRIEF ) [88], uma alternativa eficiente
para o SIFT e SURF. A comparação de descritores foi feita com um comparador do
tipo FLANN (Fast Approximate Nearest Neighbors)[89].
5.6.1
Treinamento
Considerando o mapa topológico da Figura 5.18, o robô foi manualmente posicionado
sobre os nós S1,1 , S1,5 , S3,3 , S5,5 e S5,1 . Uma imagem local foi capturada pelo robô
em cada um destes pontos e armazenadas para comparação futura. A Figura 5.19
apresenta as cinco imagens capturadas.
Figura 5.18: Mapa topológico e pontos selecionados para localização
88
(a) S1,1
(b) S1,5
(d) S5,5
(c) S3,3
(e) S5,1
Figura 5.19: Imagens de pontos conhecidos do ambiente de navegação
Os algoritmos de extração de features podem ser executados diretamente sobre as
imagens polares, eliminando a necessidade de conversão para um panorama retangular nesta fase. Outra vantagem importante oferecida pelas imagens omnidirecionais
é uma maior invariabilidade rotacional. Esta caracterı́stica permite que um nó seja
identificado visualmente mesmo que o robô esteja com um ângulo atual de rotação
diferente do treinamento.
Para cada nó Sx,y mapeado previamente pelo sistema, a fase de treinamento
consiste em comparar o número de matches retornado na comparação com todos
os demais. O objetivo é determinar o valor mı́nimo de matches que sistema deve
utilizar para indicar quando ele “reconheceu” ou não um nó mapeado. Durante
a elaboração do experimento, foi observado que o algoritmo retorna um número
de matches proporcional à distância geográfica dos nós no cenário. Quanto mais
próximos estão dois nós, maior o número de matches entre eles. Por exemplo,
considerando uma imagem de treinamento capturada sobre o nó S1,5 , os números
de matches com relação aos nós S2,5 , S2,4 e S1,4 são de 38, 36 e 29, respectivamente.
Para nós mais distantes, como S3,3 , S4,2 e S5,1 , os valores são sempre inferiores
89
à 25. Com base nesta observação, um número mı́nimo de quarenta matches foi
então determinado para indicar quando uma comparação é bem-sucedida ou não.
Considerando um ponto de treinamento Sj,k , um ponto atual qualquer Cx,y e uma
função de comparação F (Cx,y , Sj,k ) que retorna o número de matches entre as duas
imagens, os seguintes resultados podem ser esperados nas comparações:
1. F (Cx,y , Sj,k ) ≥ 40, para Cx,y = Sj,k . Nó reconhecido com sucesso.
2. F (Cx,y , Sj,k ) < 40, para Cx,y 6= Sj,k . Neste caso o algoritmo também é bemsucedido, porque não identifica como iguais dois nós diferentes.
3. F (Cx,y , Sj,k ) < 40, para Cx,y = Sj,k . Falso-negativo. Neste caso o algoritmo
falha quando não reconhece o nó atual como previamente mapeado.
4. F (Cx,y , Sj,k ) ≥ 40, para Cx,y 6= Sj,k . Falso-positivo. Neste caso o algoritmo
falha, porque reconhece um nó desconhecido como um nó mapeado.
Os casos 1 e 2 são considerados bem-sucedidos, enquanto os casos 3 e 4 são
considerados com o falhas. Com a habilidade de reconhecer o nó atual com base na
comparação de imagens, é possı́vel repetir o experimento de mapeamento dinâmico,
mas agora sem a necessidade de posicionar o sistema sempre sobre o mesmo nó
inicial. Antes de iniciar o cálculo de rotas até um destino pré-configurado, o sistema
de visão compara o ponto de vista atual com as cinco imagens capturadas durante
o treinamento e determina de onde ele está partindo.
5.6.2
Reconhecendo o Nó Inicial
A eficácia do algoritmo de localização foi avaliada em dois experimentos separados. No primeiro experimento o sistema foi posicionado novamente sobre cada
um dos pontos de treinamento. O resultado esperado é que o sistema identifique corretamente o nó em que está (F (Cx,y , Sj,k ) ≥ 40), descartando os demais
(F (Cx,y , Sj,k ) < 40). A Tabela 5.4 apresenta o número de matches encontrados em
cada comparação. A Figura 5.20 apresenta o resultado da comparação da imagem
obtida sobre o nó S1,5 com todos os nós conhecidos.
Para validar o procedimento de comparação, um segundo experimento foi realizado, mas agora posicionando o robô sobre pontos não mapeados do cenário. O
90
Tabela 5.4: Número de matches com o robô posicionado sobre pontos conhecidos
do mapa
Nós Conhecidos
Nó Atual
Tempo por Comparação (s)
S1,1
S1,5
S3,3
S5,5
S5,1
S1,1
45
26
12
11
16
1,7
S1,5
19
57
13
15
30
1,7
S3,3
24
10
46
18
11
1,9
S5,5
12
21
14
49
17
1,73
S5,1
13
22
25
11
49
1,7
resultado esperado é que o robô não consiga um número mı́nimo de matches para
nenhuma das imagens do banco de dados de treinamento. A Tabela 5.5 apresenta
o número de correspondências obtidos em todas as comparações realizadas nesta
segunda etapa.
Tabela 5.5: Número de matches com o robô posicionado sobre pontos desconhecidos
do mapa
Nós Conhecidos
Nó Atual
Tempo por Comparação (s)
S1,1
S1,5
S3,3
S5,5
S5,1
S5,4
12
8
24
38
16
1,95
S5,2
17
20
22
16
47
1,9
S3,4
20
10
28
12
21
1,92
S3,1
34
9
23
18
10
1,9
S2,2
29
11
43
16
20
1,9
91
(a) S1,5 - S1,1
(b) S1,5 - S1,5
(c) S1,5 - S3,3
(d) S1,5 - S5,5
(e) S1,5 - S5,1
Figura 5.20: Resultado de comparações com o robô posicionado sobre o nó S1,5
5.6.3
Discussão
O algoritmo de localização utilizado baseia-se na comparação da imagem do local
atual com imagens previamente armazenadas de pontos conhecidos. Quanto mais
próxima for a aparência entre duas imagens, mais combinações de pontos chaves
(matches)são encontradas entre as duas. A Tabela 5.4 mostra que o sistema de
visão é capaz de identificar quando o robô é posicionado sobre um nó já conhecido.
Por outro lado, também na Tabela 5.5, os pontos S2,2 e S5,2 foram identificados
como os nós S3,3 e S5,1 do mapa, respectivamente. O algoritmo, neste caso, “falha”
na identificação de nós geograficamente muito próximos um do outro. Esta carac92
terı́stica pode ser um problema para cenários pequenos e regulares como o utilizado
neste experimento, mas tem um impacto menos significativos quando os ambientes
comparados são mais variados entre si. Uma forma de contornar esta limitação é
adicionar marcações visuais únicas aos nós conhecidos.
Uma outra limitação associada ao estado atual do algoritmo de localização é a de
não identificar a rotação do robô com relação à imagem de treinamento. É possı́vel
comparar o deslocamento dos pontos-chave entre a imagem teste e a de treinamento
para estimar a diferença de rotação entre as duas. Este cálculo é útil para que o robô
possa estimar não só a sua localização inicial, mas também o ângulo de orientação
com relação ao sistema global de referências. Na forma atual, o robô precisa ser
posicionado sempre com a mesma orientação sobre o mapa, para que ele seja capaz
de definir com precisão todos os movimentos até o destino.
Uma outra melhoria que pode ser incorporada ao algoritmo de localização é o
armazenamento apenas dos pontos-chave e dos descritores dos nós conhecidos, e
não da imagem completa. Esta alteração pode reduzir o tempo de execução do
algoritmo.
93
Capı́tulo 6
Conclusões
Este capı́tulo faz um resumo geral do trabalho apresentado nesta dissertação, discutindo os principais resultados e contribuições e apresentando direções para trabalhos
futuros.
6.1
Resumo de Resultados
O interesse central deste trabalho foi realizar um estudo sistemático de diferentes
arquiteturas de visão omnidirecional para utilização em robôs móveis de pequeno
porte. Aqui, o termo “pequeno porte” estabelece um escopo geral para as soluções
analisadas, direcionando a atenção da pesquisa para plataformas com pequenas dimensões fı́sicas, baixo consumo de energia e baixo poder de processamento. Outra
restrição de escopo foi a necessidade de elaborar um sistema que pudesse ser embarcado sem a incorporação de elementos computacionais de grande porte, como
servidores e computadores pessoais. O trabalho utilizou alternativas de hardware
e software que, ao mesmo tempo, atendessem a estas restrições e fossem capazes
de oferecer um conjunto mı́nimo de serviços para navegação. O objetivo final era
avaliar estratégias para desenvolver um sistema de visão omnidirecional fechado,
que pudesse ser integrado à diferentes plataformas móveis por meio de um protocolo
simples de troca de mensagens.
Um sistema de navegação autônoma é uma soma de tarefas fundamentais (i.e.
localização, identificação de obstáculos, planejamento de rotas) que operam em conjunto para levar o robô de um ponto A a um ponto B de forma segura e eficiente. Para
94
cada uma destas “tarefas fundamentais” existe uma infinidade de soluções possı́veis,
com vários nı́veis de precisão e complexidade. No caso especı́fico dos sistemas de
navegação por visão computacional, estes serviços precisam ser incorporados a um
fluxo de trabalho que compreende as seguintes etapas:
I Captura de imagens;
II Pré-processamento;
III Interpretação;
IV Tomada de decisão;
V Controle de movimentação.
Este fluxo de navegação visual é a linha geral que conecta os diferentes aspectos
desta dissertação. As etapas I e II estão presentes nos Capı́tulos 3 e 4, que se concentraram no estudo das melhores estratégias para aquisição de imagens omnidirecionais utilizando câmeras inteligentes (smartcams) e microcontroladores. O Capı́tulo
3 apresentou os fundamentos teóricos para a aquisição de panoramas omnidirecionais, enquanto o Capı́tulo 4 estudou a implementação de protótipos, enfatizando
as diferentes estratégias de interligação entre as câmeras e as unidades de processamento. Como resultado, foram construı́dos e analisados três protótipos de aquisição
por image stitching, sendo um monocular e dois multicâmeras, e um protótipo por
dewarping de imagens polares (catadióptrico).
Embora o modelo catadióptrico seja a escolha mais comum em projetos de visão
omnidirecional para robôs, os sistemas de image stitching não podem ser totalmente
descartados. Aplicações que precisam de altas resoluções podem utilizar esta abordagem desde que a arquitetura utilizada atenda às suas restrições de desempenho.
Um dos aspectos centrais desta pesquisa foi justamente o estudo das diferentes arquiteturas de interligação entre câmeras para implementar um sistema de visão por
image stitching. O objetivo foi responder perguntas como: é possı́vel construir um
sistema de image stitching utilizando smartcams como a CMUCam3 e computadores de bolso como Raspberry Pi? Em caso afirmativo, como atingir o melhor
desempenho? Quais os principais gargalos deste tipo de implementação?
95
O Capı́tulo 4 apresentou elementos para avaliar sistematicamente estes problemas. Os melhores resultados em image stitching foram alcançados com as arquiteturas de barramento compartilhado e daisy chain. Embora estes modelos não tenham
oferecido um tempo de aquisição compatı́vel com aplicações de navegação em tempo
real, a análise das formas de interligação fornece material de referência para outros
projetos semelhantes.
Os principais fatores que contribuı́ram para o baixo desempenho destas arquiteturas foram as limitações de processamento e transmissão de dados da CMUCam3. Estas dificuldades podem ser superadas com o uso de plataformas mais
robustas, por exemplo, a versão mais recente da CMUCam, a CMUCam5 Pixy [90],
equipada com um microcontrolador NXP LPC4330 (núcleo ARM Cortex-M4/M0,
204Mhz, dual core) e interfaces comunicação UART, SPI, I2C e USB para saı́da de
dados. Com uma comunicação rápida e unidades de processamento mais poderosas,
é possı́vel embarcar os algoritmos de filtragem e limiarização de imagens diretamente
nas smartcams, dedicando os recursos do Raspberry Pi (ou de outra unidade central
de processamento) para tarefas mais complexas.
As etapas III, IV e V do fluxo visual, por sua vez, foram objeto de estudo dos
Capı́tulos 2 e 5. Tendo em vista as restrições gerais de escopo do trabalho, o Capı́tulo
2 priorizou a análise de algoritmos com baixa complexidade e de fácil implementação
em ambientes embarcados. Os algoritmos escolhidos para rastreamento de objetos
e detecção de obstáculos baseiam-se em técnicas de comparação de valores de pixels
(limiarização); estratégias que, embora sejam sensı́veis à variações de iluminação,
não exigem computações complexas e grandes quantidades de memória. Para os
problemas de extração e comparação de features, por sua vez, foram escolhidos
algoritmos como o SURF e o ORB, versões mais eficientes do tradicional SIFT. O
Capı́tulo 2 (Seção 2.2) ainda define um modelo geral de integração entre o sistema
de captura de imagens, o processamento de navegação e o robô móvel em si, além
de um modelo cinemático para controle de movimentação e odometria.
Após o ciclo inicial de análise de algoritmos e protótipos de aquisição omnidirecional, a etapa seguinte do trabalho foi integrar todos estes elementos em um
contexto real de navegação. No Capı́tulo 5, o protótipo de aquisição catadióptrico
foi interligado ao robô móvel de acordo com os modelos apresentados no Capı́tulo
96
2. Foram realizados experimentos de navegação para problemas de rastreamento,
mapeamento dinâmico de obstáculos e localização inicial em um ambiente parcialmente conhecido. Os experimentos demonstraram a viabilidade da utilização de
plataformas como o Raspberry Pi em problemas de robótica móvel.
6.2
Discussão
O objetivo de desenvolver um sistema de navegação por visão como um componente
que pudesse ser integrado à diferentes plataformas móveis acompanhou este trabalho desde os primeiros meses. Buscávamos um sistema que implementasse todas
as etapas do fluxo de navegação visual e entregasse ao robô móvel, através de um
protocolo simples de comunicação, uma série de comandos para movimentação. Um
sistema como este precisaria integrar uma câmera para captura das imagens, uma
unidade de processamento e uma interface de comunicação com o mundo externo.
Todas estas caracterı́sticas podiam ser encontradas em plataformas de câmeras inteligentes (smartcams) como a CMUCam3, sugerindo uma alternativa inicial para
implementação.
A CMUCam3 reune, em uma mesma placa, um sensor CCD OV6620, um microcontrolador LPC2106, com núcleo ARM7TDMI-S de 64KB de SRAM, e uma
entrada para cartões de memória de até 4GB. A placa também oferece duas interfaces de comunicação serial e quatro pinos de GPIO (General Purpose Input/Output)
para comunicação externa. Em seu portfolio de aplicações constavam alguns sistemas de vigilância, teleconferência e controle de robôs de pequeno porte com visão
monocular.
Nossa primeira estratégia foi construir um sistema de visão omnidirecional inteiramente baseado em CMUCam3. A revisão teórica do assunto mostrou que existem
duas formas tradicionais para capturar um panorama omnidirecional: dewarping de
uma imagem polar e stitching de segmentos consecutivos. O primeiro método pode
ser implementado com um arranjo catadióptrico entre uma câmera e um espelho
convexo, já o segundo pode ser implementado com uma única câmera giratória (monocular) ou um arranjo circular multicâmeras. Enquanto o desempenho é a principal
vantagem do primeiro método, a resolução final do panorama é a do segundo.
97
O modelo catadióptrico é mais popular entre os trabalhos relacionados na literatura, fator que contribuiu para que ele seja a primeira escolha em projetos semelhantes. Estes projetos quase sempre optam por construir os próprios arranjos devido a
escassez de câmeras catadióptricas industrializadas no mercado. No nosso caso, as
tentativas de montar uma câmera catadióptrica alinhando manualmente uma CMUCam3 à um espelho convexo mostraram-se bastante desafiadoras. Uma alternativa
mais promissora surgiu da combinação entre um módulo de video especı́fico para
Raspberry Pi e uma lente Kogeto Dot de 360◦ . O modelo catadióptrico final foi
escolhido para integração com o robô móvel não só porque apresentou o melhor desempenho de aquisição, mas também por que era fisicamente mais compacto que os
demais, o que facilitou a montagem sobre o Lego NXT.
Para construir um sistema de aquisição por image stitching utilizando múltiplas
CMUCam3 seria necessário, além de determinar a melhor forma de interligar as
câmeras, distribuir o cálculo das transformações perspectivas entre os vários processadores. Uma vez definido o mecanismo de aquisição omnidirecional, a etapa
seguinte seria embarcar os algoritmos de interpretação de imagens e planejamento
de rotas ao arranjo de câmeras, transformando-o em um sistema de navegação propriamente dito. Neste ponto começaram as dificuldades causadas pelas limitações da
CMUCam3. Os primeiros ensaios realizados com a câmera (Seção 4.1.1) mostraram
uma limitação significativa: a interface de comunicação serial tornava a transmissão
de imagens completas muito lenta para os padrões de navegação em tempo real.
Além disso, apesar do microcontrolador LPC2106 disponibilizar interfaces de comunicação mais rápidas (e.g. I2C e SPI), elas já estavam ocupadas por outros
componentes da placa, impossibilitando a sua utilização no projeto.
A limitação no tempo de transmissão das imagens para fora da CMUCam3 não
seria tão importante caso todo o processamento de navegação ainda pudesse ser realizado dentro dela. Se os algoritmos de identificação de obstáculos, localização e
mapeamento fossem executados pela própria CMUCam3 em tempo de navegação,
o volume de informações transmitidos pelas interfaces seriais poderia ser reduzido
ao ponto de não impactar no funcionamento do sistema. Para avaliar esta possibilidade, foi medido o desempenho da execução de dois algoritmos necessários para
o fluxo de navegação visual: um filtro de suavização de imagens (convolução) e o
98
algoritmo de detecção de obstáculos por detecção de solo (limiarização). Os resultados apresentados na Seção 4.1.1 para estes ensaios não foram animadores, deixando
claro que a CMUCam3 não seria capaz de executar, em tempo hábil, os algoritmos
mais complexos para extração de features e planejamento de rotas. Uma unidade
de processamento de maior poder computacional precisava ser incorporada.
Seguindo a orientação geral para não incorporar elementos de grande porte, as
alternativas mais promissoras seriam incorporar microcontroladores mais poderosos,
hardware programável (FPGA) ou “computadores de bolso” como o Raspberry Pi. A
última alternativa pareceu mais vantajosa pelo fato de incorporar elementos de alto
nı́vel (i.e. Linux, OpenCV, Python, etc.) mantendo os mesmos nı́veis de consumo e
dimensões fı́sicas das demais. O Raspberry Pi é um computador de propósito geral
embarcado em um SoC Broadcom BCM2835 e BCM2836. As versões mais recentes
possuem um processador ARM Cortex-A7 de quatro núcleos e até 1GB de RAM.
O Raspberry Pi é capaz de rodar sistemas Linux e suporta bibliotecas de alto nı́vel
como o OpenCV. Também é possı́vel embarcar frameworks especı́ficos para robótica
como o ROS (Robot Operation System) [91].
O ensaio para caracterização da performance do Raspberry Pi foi apresentado
na Seção 4.1.2. O desempenho foi superior ao obtido pela CMUCam3. A melhor
interligação foi alcançada com a CMUCam3 responsável pela captura e compressão
das imagens, deixando o restante do processamento para o Raspberry Pi. O menor
tempo de transmissão de um quadro em JPEG da CMUCam3 para o Raspberry Pi
foi de 0,5 segundo, dando margem para a execução das demais tarefas em um tempo
compatı́vel com a velocidade do robô.
A arquitetura geral do sistema de navegação visual ficou definida desta forma:
a CMUCam3 responsável pela captura e compressão das imagens e o Raspberry Pi
responsável pela execução dos algoritmos de navegação. A incorporação do Raspberry Pi facilitou a implementação completa do fluxo visual e a integração com o
Lego NXT. Este resultado expandiu as possibilidades da pesquisa, possibilitando a
realização dos experimentos de navegação do Capı́tulo 5. Com o Raspberry Pi B rodando um sistema operacional Linux Raspbian Wheezy no papel da unidade central
de controle, todos os algoritmos puderam ser implementados em Python 2.7 com o
auxı́lio da biblioteca OpenCV. O software final de navegação foi uma combinação de
99
funções oferecidas pelo OpenCV e código próprio desenvolvido para este trabalho.
Foram criados diferentes módulos Python para executar todas as etapas do fluxo
visual de acordo com o experimento desejado.
6.3
Contribuições
As principais contribuições oferecidas por este trabalho podem ser resumidas da
seguinte forma:
• Um estudo sistemático de arquiteturas embarcadas para aquisição de imagens
omnidirecionais por image stitching, com enfoque especial nos modelos de interligação e distribuição de tarefas entre os elementos de processamento;
• A identificação de gargalos importantes para a implementação de sistemas
mono e multicâmeras de visão omnidirecional;
• A elaboração de uma arquitetura de visão fechada, capaz de ser integrada à
diferentes plataformas móveis através de um protocolo de troca de mensagens
e uma interface sem fio;
• Uma demonstração da viabilidade da utilização de plataformas como o Raspberry Pi em aplicações de robótica móvel;
• O desenvolvimento de soluções em Python para problemas de rastreamento de
objetos, identificação de obstáculos e mapeamento dinâmico em plataformas de
baixo poder computacional. A linguagem escolhida ainda permite a utilização
das mesmas soluções em outros ambientes além do Raspberry Pi, exigindo
pouca ou nenhuma adaptação;
• A implementação de um sistema catadióptrico de visão utilizando componentes de prateleira (off-the-shelf ) e a sua utilização em experimentos reais de
navegação não assistida;
As contribuições apresentadas fornecem um material de referência para outros
trabalhos do mesmo gênero, indicando vantagens e desvantagens de cada estratégia
e auxiliando futuras pesquisas na escolha do modelo mais adequado de aquisição.
100
6.4
Trabalhos Futuros
Devido à preocupação inicial com o desempenho das plataformas utilizadas neste
trabalho (i.e. Raspberry Pi e CMUCam3), e também ao objetivo de desenvolver
soluções totalmente embarcadas, a escolha dos algoritmos de interpretação de imagens e controle de navegação priorizou soluções mais “leves”, que exigissem poucos
recursos computacionais. Embora estes algoritmos nem sempre ofereçam os resultados mais precisos, foi possı́vel embarcá-los no Raspberry Pi e na CMUCam3. Um
desdobramento futuro deste trabalho pode ser a implementação de técnicas mais
robustas de navegação por visão, por exemplo: algoritmos de classificação de imagens por redes neurais, estratégias de controle probabilı́stico (e.g. Kalman Filters,
Particle Filters, etc.), localização e mapeamento simultâneos (SLAM).
Com relação aos componentes do sistema, também é possı́vel substituir as plataformas básicas de aquisição e processamento por versões mais recentes. A CMUCam5 Pixy parece ser uma boa alternativa para contornar as limitações da CMUCam3. Versões mais recentes do Raspberry Pi também oferecem um desempenho
muito mais alto com os mesmos nı́veis de consumo. Atualizar a aplicação das arquiteturas de interligação e dos algoritmos de visão nestes componentes, bem como
avaliar o ganho de desempenho desta alteração, pode ser uma direção futura para
esta pesquisa.
Finalmente, graças à portabilidade dos códigos desenvolvidos em Python durante
o trabalho, também é possı́vel adaptar as soluções para outras plataformas similares
ao Raspberry Pi como, por exemplo, o Intel Galileo [92] e o Beaglebone [93]. Um
outro desdobramento possı́vel é a utilização de frameworks especı́ficos para robótica,
como o ROS, nestas plataformas embarcadas.
101
Referências Bibliográficas
[1] MARKOFF, J., “Google Cars Drive Themselves, in Traffic”, New York Times,
v. 9, 2010.
[2] AG,
A.,
“Audi
piloted
driving”,
Disponı́vel
em:
http
:
//www.audi.com/com/brand/en/piloted − driving.html. Acesso em: 29
de julho de 2015, Julho 2015.
[3] MERCEDES-BENZ, I., “The Mercedes-Benz F 015 Luxury in Motion”, Disponı́vel em:
http : //www.landrover.com/experiences/news/jlr −
remote − control − range − rover − sport.html. Acesso em: 01 de Setembro de 2015, Outubro 2015.
[4] ROVER, J. L., “Jaguar Land Rover Showcase New Technologies Including A Remote Control Range Rover Sport”, Disponı́vel em: http :
//www.landrover.com/experiences/news/jlr − remote − control −
range − rover − sport.html. Acesso em: 29 de junho de 2015, 2015.
[5] AUTOMOTIVE
Vehicle
ENGINEERS,
Standards
S.
Committee”,
O.,
“On-Road
Disponı́vel
//www.sae.org/works/committeeHome.do?comtID
em:
=
Automated
http
:
T EV AV S.
Acesso em: 29 de junho de 2015, 2012.
[6] LILY, “Lily Camera”, Disponı́vel em: https : //www.lily.camera/. Acesso em:
29 de junho de 2015, 2015.
[7] GROTZINGER, J. P., CRISP, J., VASAVADA, A. R., et al., “Mars Science Laboratory mission and science investigation”, Space science reviews, v. 170,
n. 1-4, pp. 5–56, 2012.
102
[8] JONES, J. L., “Robots at the tipping point: the road to iRobot Roomba”,
Robotics & Automation Magazine, IEEE , v. 13, n. 1, pp. 76–78, 2006.
[9] ANDREW, A. M., “Mobile Robotics: A Practical Introduction”, Kybernetes,
v. 33, n. 8, pp. 1336–1337, 2004.
[10] GUILHERME, N., AVINASH, C., “Vision for mobile robot navigation: A survey”, IEEE Transactions on Pattern Analysis and Machine Intelligence,
v. 24, n. 2, pp. 237–267, 2002.
[11] TSUKIYAMA, T., “Rfid based navigation system for indoor mobile robots”.
In: World Congress, v. 18, n. 1, pp. 1084–1089, 2011.
[12] DURRANT-WHYTE, H., BAILEY, T., “Simultaneous localization and mapping: part I”, Robotics & Automation Magazine, IEEE , v. 13, n. 2, pp. 99–
110, 2006.
[13] ELFES, A., “Sonar-based real-world mapping and navigation”, In: Autonomous
Robot Vehicles, pp. 233–249, Springer, 1990.
[14] ISHIGURO, H., MAEDA, T., MIYASHITA, T., et al., “A strategy for acquiring
an environmental model with panoramic sensing by a mobile robot”. In:
Robotics and Automation, 1994. Proceedings., 1994 IEEE International
Conference on, pp. 724–729, 1994.
[15] INC,
N.
R.,
“Neato
Botvac”,
Disponı́vel
em:
http
:
//www.neatorobotics.com/robot − vacuum/botvac/. Acesso em:
29
de junho de 2015, 2012.
[16] ANSARI, M. A., UMRANI, F. A., “SONAR Based Obstacle Detection and
Avoidance Algorithm”. In: Signal Acquisition and Processing, 2009. ICSAP 2009. International Conference on, pp. 98–102, 2009.
[17] LENSER, S., VELOSO, M., “Visual sonar: Fast obstacle avoidance using monocular vision”. In: Intelligent Robots and Systems, 2003.(IROS 2003).
Proceedings. 2003 IEEE/RSJ International Conference on, v. 1, pp. 886–
891, 2003.
103
[18] DURRANT-WHYTE, H. F., Integration, coordination and control of multisensor robot systems. v. 36. Springer Science & Business Media, 2012.
[19] KAM, M., ZHU, X., KALATA, P., “Sensor fusion for mobile robot navigation”,
Proceedings of the IEEE , v. 85, n. 1, pp. 108–119, 1997.
[20] JOLLAY, D., RICKS, R., Sensor fusion for robot navigation, Tech. rep., Oak
Ridge National Lab., TN (USA), 1988.
[21] BENTO, L. C., NUNES, U., MOITA, F., et al., “Sensor fusion for precise
autonomous vehicle navigation in outdoor semi-structured environments”.
In: Intelligent Transportation Systems, 2005. Proceedings. 2005 IEEE ,
pp. 245–250, 2005.
[22] LEONARD, J. J., DURRANT-WHYTE, H. F., Directed sonar sensing for mobile robot navigation. v. 175. Springer Science & Business Media, 2012.
[23] GUIZZO,
em:
E.,
http
“How
:
Google’s
Self-Driving
Car
Works”,
Disponı́vel
//spectrum.ieee.org/automaton/robotics/artif icial −
intelligence/how − google − self − driving − car − works. Acesso em:
29 de junho de 2015, 2011.
[24] MÖLLER, B., POSCH, S., HAASCH, A., et al., “Interactive object learning
for robot companions using mosaic images”. In: Intelligent Robots and
Systems, 2005.(IROS 2005). 2005 IEEE/RSJ International Conference
on, pp. 2650–2655, 2005.
[25] CHEN, Z., BIRCHFIELD, S. T., “Qualitative vision-based mobile robot navigation”. In: Robotics and Automation, 2006. ICRA 2006. Proceedings
2006 IEEE International Conference on, pp. 2686–2692, 2006.
[26] HRABAR, S., SUKHATME, G. S., “Omnidirectional vision for an autonomous
helicopter”. In: Robotics and Automation, 2003. Proceedings. ICRA’03.
IEEE International Conference on, v. 1, pp. 558–563, 2003.
[27] KARTHIK, N. A., Vision System for Autonomous Navigation, Ph.D. Thesis,
NATIONAL INSTITUTE OF TECHNOLOGY, ROURKELA,INDIA,
2014.
104
[28] WANG, P., MENG, Z., LUO, C., et al., “Path Recognition for Agricultural
Robot Vision Navigation under Weed Environment”, In: Computer and
Computing Technologies in Agriculture VII , pp. 242–248, Springer, 2014.
[29] GASPAR, J. A. D. C. P., Omnidirectional vision for mobile robot navigation,
Ph.D. Thesis, Universidade Técnica de Lisboa, Lisboa, Portugal, 2002.
[30] BURBRIDGE, C., BURBRIDGE, C., BURBRIDGE, C., et al., “Efficient Robot Navigation with Omnidirectional Vision”, Proceedings of Towards Autonomous Robotic Systems (TAROS), v. 55, pp. 667, 2010.
[31] LEGO, I.,
“Lego Mindstorms NXT 2.0”,
Disponı́vel em:
http
:
//www.lego.com/en − us/mindstorms. Acesso em: 01 de Setembro de
2015, 2015.
[32] CHOSET, H. M., Principles of robot motion: theory, algorithms, and implementation. MIT press, EUA, 2005.
[33] BONIN-FONT, F., ORTIZ, A., OLIVER, G., “Visual navigation for mobile
robots: A survey”, Journal of intelligent and robotic systems, v. 53, n. 3,
pp. 263–296, 2008.
[34] SABE, K., FUKUCHI, M., GUTMANN, J.-S., et al., “Obstacle avoidance and
path planning for humanoid robots using stereo vision”. In: Robotics
and Automation, 2004. Proceedings. ICRA’04. 2004 IEEE International
Conference, Nova Orleães, Luisiana, EUA, on, v. 1, pp. 592–597, 2004.
[35] MICHELS, J., SAXENA, A., NG, A. Y., “High speed obstacle avoidance using
monocular vision and reinforcement learning”. In: Proceedings of the
22nd international conference on Machine learning, pp. 593–600, Bonn,
Renânia, Alemanha, 2005.
[36] ULRICH, I., NOURBAKHSH, I., “Appearance-based obstacle detection with
monocular color vision”. In: Innovative Applications of Artificial Intelligence Conference (IAAI), pp. 866–871, Association for the Advancement
of Artificial Intelligence: Austin, Texas, EUA, 2000.
105
[37] UPTON, E., HALFACREE, G., Meet the Raspberry Pi . John Wiley & Sons:
Reino Unido, 2012.
[38] RASPBERRYPI, F., “Raspberry Pi Model B”, Disponı́vel em:
https :
//www.raspberrypi.org/products/model − b/. Acesso em: 29 de junho
de 2015, 2012.
[39] GUZEL, M. S., BICKER, R., Vision based obstacle avoidance techniques. INTECH Open Access Publisher, 2011.
[40] WU, B.-F., LU, W.-C., JEN, C.-L., “Monocular vision-based robot localization
and target tracking”, Journal of Robotics, v. 2011, 2012.
[41] BENAVIDEZ, P., JAMSHIDI, M., “Mobile robot navigation and target tracking system”. In: System of Systems Engineering (SoSE), 2011 6th International Conference on, pp. 299–304, Albuquerque, Novo México, EUA,
2011.
[42] HONG, C., CHUN, S., LEE, J. S., et al., “A vision-guided object tracking and
prediction algorithm for soccer robots”. In: Robotics and Automation,
1997. Proceedings., 1997 IEEE International Conference on, v. 1, pp.
346–351, Albuquerque, Novo México, EUA, 1997.
[43] LU, H., ZHANG, H., YANG, S., et al., “Vision-based ball recognition for soccer
robots without color classification”. In: Information and Automation,
2009. ICIA’09. International Conference on, pp. 916–921, Zhuhai, China,
2009.
[44] LU, H., ZHANG, H., XIAO, J., et al., “Arbitrary ball recognition based on
omni-directional vision for soccer robots”, In: RoboCup 2008: Robot Soccer World Cup XII , pp. 133–144, Springer, 2009.
[45] YILMAZ, A., JAVED, O., SHAH, M., “Object tracking: A survey”, Acm computing surveys (CSUR), v. 38, n. 4, pp. 13, 2006.
[46] BRADSKI, G., KAEHLER, A., Learning OpenCV: Computer vision with the
OpenCV library. ”O’Reilly Media, Inc.”, 2008.
106
[47] GEVERS, T., SMEULDERS, A. W., “Color-based object recognition”, Pattern
recognition, v. 32, n. 3, pp. 453–464, 1999.
[48] ITSEEZ, I., “Open Source Computer Vision Library”, Disponı́vel em: http :
//opencv.org/. Acesso em: 01 de Setembro de 2015, 2015.
[49] LOWE, D. G., “Object recognition from local scale-invariant features”. In:
Computer vision, 1999. The proceedings of the seventh IEEE international
conference on, v. 2, pp. 1150–1157, 1999.
[50] LOWE, D. G., “Distinctive image features from scale-invariant keypoints”, International journal of computer vision, v. 60, n. 2, pp. 91–110, 2004.
[51] BAY, H., TUYTELAARS, T., VAN GOOL, L., “Surf: Speeded up robust
features”, In: Computer vision–ECCV 2006 , pp. 404–417, Springer, 2006.
[52] ELFES, A., “Using occupancy grids for mobile robot perception and navigation”, Computer , v. 22, n. 6, pp. 46–57, 1989.
[53] RASCHKE, U., BORENSTEIN, J., “A comparison of grid-type map-building
techniques by index of performance”. In: Robotics and Automation, 1990.
Proceedings., 1990 IEEE International Conference on, pp. 1828–1832,
Cincinnati, Ohio, EUA, 1990.
[54] SE, S., LOWE, D., LITTLE, J., “Vision-based mobile robot localization and
mapping using scale-invariant features”. In: Robotics and Automation,
2001. Proceedings 2001 ICRA. IEEE International Conference on, v. 2,
pp. 2051–2058, Seoul, Korea, 2001.
[55] PARK, S. Y., JUNG, S. C., SONG, Y. S., et al., “Mobile robot localization
in indoor environment using scale-invariant visual landmarks”. In: IAPR
Workshop Cognitive Information Processing, Santorini, Grécia, 2008.
[56] MURILLO, A. C., GUERRERO, J. J., SAGÜÉS, C., “Surf features for efficient
robot localization with omnidirectional images”. In: Robotics and Automation, 2007 IEEE International Conference on, pp. 3901–3907, Roma,
Itália, 2007.
107
[57] MAOHAI, L., HAN, W., LINING, S., et al., “Robust Omnidirectional Mobile Robot Topological Navigation System Using Omnidirectional Vision”,
Eng. Appl. Artif. Intell., v. 26, n. 8, pp. 1942–1952, Sept. 2013.
[58] SOLORZANO, J., BAGNALL, B., STUBER, J., et al., “Java for Lego Mindstorms”, Disponı́vel em: http : //www.lejos.org/. Acesso em: 01 de Setembro de 2015, 2006.
[59] SIEGWART, R., NOURBAKHSH, I. R., SCARAMUZZA, D., Introduction to
autonomous mobile robots. MIT press: EUA, 2011.
[60] DOS SANTOS, C. C., STOETER, S., RYBSKI, P. E., et al., “Mosaicking
images [panoramic imaging]”, Robotics & Automation Magazine, IEEE ,
v. 11, n. 4, pp. 62–68, 2004.
[61] IKEDA, S., SAT, T., YOKOYA, N., “High-resolution panoramic movie generation from video streams acquired by an omnidirectional multi-camera
system”. In: Multisensor Fusion and Integration for Intelligent Systems,
MFI2003. Proceedings of IEEE International Conference on, pp. 155–160,
2003.
[62] GLEDHILL, D., TIAN, G. Y., TAYLOR, D., et al., “Panoramic imaging: a
review”, Computers & Graphics, v. 27, n. 3, pp. 435–445, 2003.
[63] GREY, P. R., “Ladybug2 360 Degree FireWire Spherical Camera Systems”,
Disponı́vel em: http : //www.ptgrey.com/ladybug2 − 360 − degree −
f irewire − spherical − camera − systems. Acesso em: 01 de Setembrode
2015, 2015.
[64] SZELISKI, R., “Image alignment and stitching: A tutorial”, Foundations and
R in Computer Graphics and Vision, v. 2, n. 1, pp. 1–104, 2006.
Trends
[65] HARRIS, C., STEPHENS, M., “A combined corner and edge detector.” In:
Alvey vision conference, v. 15, p. 50, Manchester, Reino Unido, 1988.
[66] SVOBODA, T., PAJDLA, T., HLAVÁČ, V., “Epipolar geometry for panoramic
cameras”, In: Computer Vision-ECCV98 , pp. 218–231, Springer, 1998.
108
[67] SCARAMUZZA, D., CRIBLEZ, N., MARTINELLI, A., et al., “Robust feature extraction and matching for omnidirectional images”. In: Field and
Service Robotics, pp. 71–81, 2008.
[68] KOGETO, I., “Kogeto Dot”, Disponı́vel em: http : //kogeto.com/dot.html.
Acesso em: 29 de junho de 2015, 2013.
[69] GEYER, C., DANIILIDIS, K., “A unifying theory for central panoramic systems and practical implications”, In: Computer Vision-ECCV 2000 , pp.
445–461, Springer, 2000.
[70] GRASSI JUNIOR, V., OKAMOTO JUNIOR, J., “Development of an omnidirectional vision system”, Journal of the Brazilian Society of Mechanical
Sciences and Engineering, v. 28, n. 1, pp. 58–68, 2006.
[71] ISHIGURO, H., “Development of low-cost compact omnidirectional vision sensors”, In: Panoramic vision, pp. 23–38, Springer, 2001.
[72] JENG, S., TSAI, W., “Using pano-mapping tables for unwarping of omniimages into panoramic and perspective-view images”, Image Processing,
IET , v. 1, n. 2, pp. 149–155, 2007.
[73] TORII, A., IMIYA, A., “Panoramic image transform of omnidirectional images
using discrete geometry techniques”. In: 3D Data Processing, Visualization and Transmission, 2004. 3DPVT 2004. Proceedings. 2nd International Symposium on, pp. 608–615, 2004.
[74] WONG, W. K., CHOO, C. W., LOO, C. K., et al., “FPGA implementation of
log-polar mapping”, International Journal of Computer Applications in
Technology, v. 39, n. 1-3, pp. 12–18, 2010.
[75] PUA, W. S., WONG, W. K., LOO, C. K., et al., “A Study of Different Unwarping Methods for Omnidirectional Imaging”, Computer Technology and
Application 3 (2012), pp. 226–239, 2012.
[76] DESOUZA, G. N., KAK, A. C., “Vision for mobile robot navigation: A survey”,
Pattern Analysis and Machine Intelligence, IEEE Transactions on, v. 24,
n. 2, pp. 237–267, 2002.
109
[77] ROWE, A. G., GOODE, A., GOEL, D., et al., “CMUcam3: An open programmable embedded vision sensor”, 2007.
[78] GOODE, A ROWE, A., AGYEMAN, K., “CMUCam Project”, Disponı́vel em:
http : //www.cmucam.org. Acesso em: 29 de junho de 2015, 2012.
[79] GOODE, A ROWE, A., AGYEMAN, K., “SpoonBot Project”, Disponı́vel em:
http : //www.cmucam.org/projects/cmucam3/wiki/SpoonBot. Acesso
em: 29 de junho de 2015, 2012.
[80] ROWE, A., GOEL, D., RAJKUMAR, R., “Firefly mosaic: A vision-enabled
wireless sensor networking system”. In: Real-time systems symposium,
2007. RTSS 2007. 28th IEEE international , pp. 459–468, 2007.
[81] RASPBERRYPI, F., “Raspberry Pi Camera Module”, Disponı́vel em: https :
//www.raspberrypi.org/products/camera − module/. Acesso em: 29 de
junho de 2015, 2013.
[82] HART, C., A Low-cost Omni-directional Visual Bearing Only Localization System, Ph.D. Thesis, Case Western Reserve University, Cleveland, Ohio,
EUA, 2014.
[83] VALGREN, C., “Topological mapping and localization using omnidirectional
vision”, Licentiate thesis, Orebro University, 2007.
[84] VALGREN, C., LILIENTHAL, A. J., “SIFT, SURF & seasons: Appearancebased long-term localization in outdoor environments”, Robotics and Autonomous Systems, v. 58, n. 2, pp. 149–156, 2010.
[85] VALGREN, C., LILIENTHAL, A., DUCKETT, T., “Incremental topological
mapping using omnidirectional vision”. In: Intelligent Robots and Systems, 2006 IEEE/RSJ International Conference on, pp. 3441–3447, 2006.
[86] HE, S., “Feedback control design of differential-drive wheeled mobile robots”.
In: Advanced Robotics, 2005. ICAR’05. Proceedings., 12th International
Conference on, pp. 135–140, Seattle, Washington, EUA, 2005.
110
[87] PARK, J. J., KUIPERS, B., “A smooth control law for graceful motion of
differential wheeled mobile robots in 2D environment”. In: Robotics and
Automation (ICRA), 2011 IEEE International Conference on, pp. 4896–
4902, Shanghai, China, 2011.
[88] RUBLEE, E., RABAUD, V., KONOLIGE, K., et al., “ORB: an efficient alternative to SIFT or SURF”. In: Computer Vision (ICCV), 2011 IEEE
International Conference on, pp. 2564–2571, Barcelona, Espanha, 2011.
[89] MUJA, M., LOWE, D. G., “Fast Approximate Nearest Neighbors with Automatic Algorithm Configuration.” VISAPP (1), v. 2, 2009.
[90] GOODE, A ROWE, A., AGYEMAN, K., “CMUCam: Open Source Programmable Embedded Color Vision Sensors”, Disponı́vel em: http :
//www.cmucam.org/projects/cmucam5. Acesso em: 01 de Setembro de
2015, 2015.
[91] QUIGLEY, M., CONLEY, K., GERKEY, B., et al., “ROS: an open-source
Robot Operating System”. In: ICRA workshop on open source software,
v. 3, n. 3.2, p. 5, 2009.
[92] RAMON, M. C., Intel Galileo and Intel Galileo Gen 2 . Apress: Nova York,
EUA, 2014.
[93] COLEY, G., “Beaglebone black system reference manual”, Texas Instruments,
2013.
[94] KUBITZ, O., BERGER, M. O., PERLICK, M., et al., “Application of radio
frequency identification devices to support navigation of autonomous mobile robots”. In: Vehicular Technology Conference, 1997, IEEE 47th, v. 1,
pp. 126–130, Phoenix, Arizona, EUA, 1997.
[95] TREPTOW, A., ZELL, A., “Real-time object tracking for soccer-robots
without color information”, Robotics and Autonomous Systems, v. 48,
n. 1, pp. 41–48, 2004.
[96] THRUN, S., “Robotic mapping: A survey”. In: Exploring Artificial Intelligence
in the New Millenium, p. 2002, Morgan Kaufmann.
111
Apêndice A
Trabalhos Publicados
Alguns resultados obtidos nesta pesquisa foram aceitos para apresentação e publicados em anais de congressos nacionais. No contexto da análise de modelos de
aquisição, o artigo “Omnidirectional Multicamera Architecture for Mobile Robot Navigation”, foi publicado no IX Workshop de Visão Computacional (WVC), em 2013,
e o artigo “Análise de Arquiteturas Embarcadas de Baixo-custo para Aquisição de
Imagens Omnidirecionais”, foi aceito para publicação no XII Simpósio Brasileiro
de Automação Inteligente em 2015. Já no contexto de integração de um modelo
de aquisição omnidirecional como plataforma de navegação para robôs móveis, o
artigo “Omnidirectional Vision Architecture for Embedded Robot Navigation with
Raspberry Pi”, foi aceito para publicação no XI WVC também em 2015. Um resultado derivado da linha central da pesquisa foi também publicado no XX Congresso
Brasileiro de Automática, em 2014, no artigo “Cálculo De Distâncias Euclidianas
Entre Histogramas Para Sistemas De Localização Robótica Em FPGA”. Os resumos
e referências de cada artigo são listados a seguir.
Anderson A. do Nascimento, Paulo C. M. A. Farias. “Omnidirectional Multicamera Architecture for Mobile Robot Navigation”, IX
Workshop de Visão Computacional. Rio de Janeiro - RJ, 2013.
Sistemas de visão omnidirecional têm sido amplamente utilizados em
sistemas móveis de navegação devido a caracterı́sticas úteis das imagens
omnidirecionais, dentre elas: o campo de visão estendido, invariabilidade
rotacional e simetria. Embora os sistemas de visão omnidirecional mais
comuns sejam baseados em câmeras catadióptricas, eles apresentam pro112
blemas como baixa resolução das imagens e distorções naturais causadas
pelo uso de espelhos convexos. Para contornar estes problemas, panoramas
omnidirecionais retangulares podem ser utilizados. Este artigo analisa três
modelos diferentes de aquisição de imagens omnidirecionais baseados em
múltiplas câmeras. O projeto propõe a utilização de seis câmeras CMUCam3, dispostas em cı́rculo e interconectadas, cada uma responsável por
uma fração angular do panorama final. O panorama omnidirecional obtido
é mais adequado para aplicações de rastreamento de pequenos detalhes, ou
navegação de precisão.
Anderson A. do Nascimento, Paulo C. M. A. Farias. “Análise de Arquiteturas Embarcadas de Baixo-custo para Aquisição de Imagens Omnidirecionais”, XII Simpósio Brasileiro de Automação Inteligente. Natal - RN, 2015.
Este trabalho compara duas arquiteturas de baixo custo para aquisição
de imagens omnidirecionais, analisando suas aplicações em problemas de
robótica embarcada, como os de navegação autônoma. A primeira arquitetura é baseada em um arranjo de três câmeras CMUCam3 interligadas
por um barramento mestre-escravo. Cada câmera captura um segmento
individual de 60◦ , compreendendo uma parte de um panorama retangular
de 180◦ . O panorama é montado em um processo de image stitching incorporado ao firmware das câmeras do arranjo. O segundo modelo utiliza um
Raspberry Pi com um módulo de vı́deo e um espelho esférico. O resultado
é câmera catadióptrica com um campo de visão de 360◦ . As duas arquiteturas são submetidas a um algoritmo de detecção de obstáculos para
comparação de desempenho. O algoritmo é baseado na identificação de
obstáculos a partir da diferença entre a cor deles e a cor do solo ao redor
do robô. São medidos tempos de aquisição, montagem e processamento
dos panoramas nas duas arquiteturas.
Anderson A. do Nascimento, Paulo C. M. A. Farias. “Omnidirectional Vision Architecture for Embedded Robot Navigation with
Raspberry Pi”, XI Workshop de Visão Computacional. São Carlos - SP,
2015.
113
Sistemas de visão omnidirecional são ferramentas extremamente úteis
para navegação em robótica móvel. O campo de visão estendido pode ajudar o robô a mover-se com mais eficiência entre obstáculos, exigindo menos
observações do cenário. No entanto, normalmente estes sistemas demandam algoritmos de alto custo computacional para manipulação de imagens,
dificultando a execução em aplicações embarcadas de pequeno porte. Este
artigo descreve uma arquitetura funcional de aquisição de imagens omnidirecionais a partir de uma câmera catadióptrica. As imagens capturadas
alimentam um fluxo de imagens para duas tarefas de navegação: rastreamento de objetos por cor e detecção de obstáculos por segmentação. O
modelo descrito utiliza um Raspberry Pi como unidade central de processamento, juntamente com um veı́culo diferencial construı́do a partir de
um kit Lego Mindstorms NXT. São apresentados detalhes de arquitetura e
implementação do sistema, assim como uma avaliação de desempenho em
aplicações para ambientes internos.
Anderson A. do Nascimento, Paulo C.M.A. Farias. “Cálculo De
Distâncias Euclidianas Entre Histogramas Para Sistemas De
Localização Robótica Em FPGA”, XX Congresso Brasileiro de Automática. Belo Horizonte - MG, 2014.
Sistemas de navegação autônoma baseados em visão robótica geralmente lidam com dois problemas principais: detecção de obstáculos e localização. Em ambos os casos os algoritmos utilizados demandam um
pré-processamento das imagens de entrada para eliminar (ou isolar) caracterı́sticas especı́ficas e compensar variações de iluminação. Para navegação
em tempo real, o pré-processamento precisa ser feito com o máximo de
rapidez possı́vel, salvando tempo para os procedimentos mais robustos
de detecção e análise de cena. Esta necessidade impõe severas restrições
de desempenho da aquisição, o que justifica a adaptação das rotinas de
pré-processamento em hardware dedicado. Este projeto propõe a implementação em HDL (Hardware Description Language) de um módulo de
equalização de imagens e cálculo de distância euclidiana entre histogramas, para auxiliar mecanismos de localização em navegação autônoma.
114

do arquivo - Programa de Pós

Transcrição

Documentos relacionados

Nota de Alta

Inteligência Artificial

Desempenho de algorimos detectores de keypoints

UM ESTUDO COMPARATIVO ENTRE ARQUITETURAS NEURAIS

comunicarh - ed 10

Bolo do Caco Bimby: 27 min Ingredientes: 1 c. café sal

Desvio de Obstáculos Utilizando um Método Estéreo Semi

Projeto de Extensão: Difusão de anime na UTFPR

Lojamundi – Tecnologia Sem Limites www.lojamundi.com.br

Um robô por aluno: uma realidade possıvel