Relatório – SAURON
Testes realizados em 28 e 29/06/09
Introdução
Nos dias 28 e 29 de junho, realizamos a segunda bateria de testes da biblioteca embutida de
navegação do robô, a SonARNL. Dessa vez, mapeamos o Bloco C, pavimento superior, inteiro.
Os resultados não foram satisfatórios. Em nenhum dos mais de 10 testes, o robô foi capaz de
chegar até o destino final.
Mapa
O grupo utilizou uma planta, no formato de AutoCAD, do prédio da Eng. Elétrica fornecida por
Erika Kato, segundo indicação de Diego Gallo. O pavimento superior do bloco C (i.e. C2-X) foi
desenhado no Mapper3, o programa de edição de mapas da MobileRobots. Alguns pontos de
interesse foram adicionados; o mapa completo está na última página.
Durante os testes, algumas imprecisões na planta foram corrigidas. A região das salas C2-1X,
em especial, precisou ser medida quase por inteiro. Além disso, objetos grandes e estáticos
como bebedouro, armário, cofre, sofá etc. foram adicionados à planta.
Testes
Nossa intenção era executar um teste simples de início, e então, efetuar medições de modo a
calcular a precisão do robô. No entanto, não conseguimos realizar a mais básica das tarefas:
navegá-lo de um canto a outro do corredor, numa linha reta. Durante todo o teste,
mantivemo-nos atrás do robô para não influenciar seus sonares.
Tentamos realizar o seguinte percurso: a partir da primeira coluna à esquerda de quem sai do
LTI (ponto verde claro no mapa), navegar até a sala C2-13, no lado oposto do corredor. O
caminho ideal é quase uma reta, mas o robô não conseguiu, em nenhum dos mais de dez
testes realizados, cumpri-lo. Na vez que chegou mais longe, ultrapassou o cruzamento em
frente às rampas, mas se perdeu em frente à secretaria do PCS. O caso mais comum foi perda
de localização por volta da sala C2-38.
Detectamos um padrão: em todas as vezes nas quais se perdeu, o robô acreditava estar no
lado errado do corredor. Por exemplo, ele achava estar próximo à parede da sala C2-30,
quando na verdade estava encostado à rampa oposta. Sua localização no eixo x1, contudo, era
boa. Um fato curioso é que as amostras, resultado da localização de Monte Carlo e exibidas
pelo programa MobileEyes, geralmente se concentravam no lado correto do corredor.
1
X = eixo paralelo ao corredor dos laboratórios
Houve inclusive uma ocorrência na qual o robô entrou no corredor que leva à escada de
acesso ao andar, próximo à sala C2-43, tendo sido instruído a se movimentar à sala C2-13.
Tampouco foram raros os acidentes. Os sonares garantem proteção contra colisões frontais,
mas muitas vezes o robô, acreditando estar no lado oposto do corredor, efetuou um giro de
360º quando estava encostado à parede, raspando o notebook e a alça traseira.
Notamos que à medida que o mapa era refinado, havia alguma melhora no desempenho do
robô, mas não conseguimos um comportamento consistente em hora alguma: se às vezes ele
chegava a ultrapassar o cruzamento dos corredores, no teste seguinte ele poderia muito bem
se perder antes da primeira porta de vidro.
De maneira interessante, notamos que o robô se saiu muito pior neste teste do que na semana
passada. Naquela ocasião, conseguimos com que ele se movimentasse até a sala C2-43, em
frente às escadas, repetidas vezes e com alta taxa de sucesso. Não conseguimos repetir o feito
nestes testes.
Hipóteses
Essa última observação serve de base para especulação quanto às razões do fracasso. Por que
parou de funcionar? De imediato, podemos rejeitar mudanças no software de
navegação/localização. Os testes iniciais deste fim-de-semana foram realizados com uma
versão mais recente, SonARNL 1.7, mas, quando percebemos a regressão no desempenho,
voltamos à biblioteca anterior (versão 1.5.1). Não houve mudança.
Consideramos, então, duas hipóteses:

Simetria do ambiente: o trajeto que percorremos seria excessivamente simétrico no
eixo y, dificultando a localização do robô. Isso, aliado a um odômetro pouco preciso,
teria causado os problemas. O problema não teria se manifestado nos testes
anteriores porque havíamos modificado artificialmente o ambiente, de modo a
introduzir assimetria (e.g. sofá virado, uma porta de vidro fechada). Isso não é uma
opção no ambiente final.
Pode-se argumentar que o ambiente não é tão simétrico assim: há o corredor da
escada e a rampa, por exemplo. Contudo, a maior parte das perdas de localização
ocorreu antes disso.

Imprecisão do mapa: a fidelidade da planta que utilizamos de base não é muito
elevada. Medindo manualmente, detectamos erros da ordem de 5-10 cm.
Acumulados, esses erros teriam levado à perda de localização do robô. Como na
semana passada fizemos todas as medições por conta própria, o problema não teria se
manifestado.
Por outro lado, pode-se perguntar se uma expectativa de mapas tão precisos assim é
realista para um sistema de navegação robótica. Se erros de uma dezena de
centímetros causam efeitos catastróficos, o que acontecerá num ambiente
movimentado, cheio de obstáculos dinâmicos?
Figura 1 Mapa do pavimento superior do bloco C