DESENVOLVIMENTO DO SISTEMA DE VISÃO PARA A PLATAFORMA MÓVEL UTOPIA
António Patacho*, Alfredo Martins*†, Eduardo Pereira da Silva*†, João Paulo Baptista*, José Miguel Almeida*†
* Laboratório de Sistemas Autónomos - Instituto Superior de Engenharia do Porto, Rua Dr. Bernardino de Almeida, 431, 4200-072 PORTO, PORTUGAL,
† Instituto de Sistemas e Robótica, Rua Dr. Roberto Frias, 4200 PORTO, PORTUGAL
Sumário
Este trabalho, enquadra-se nos esforços do laboratório de sistemas autónomos do ISEP no que diz respeito à obtenção de um sistema de visão para robótica móvel, de baixo custo e versátil, baseado em componentes 'off-the-shelf', para equipar a plataforma Móvel UTOPIA. A arquitectura do sistema desenvolvido consiste na utilização de câmaras USB ligadas a um sistema computacional com o sistema operativo Linux. O sistema será composto pela integração do 'hardware' comercialmente disponível' anteriormente referido, uma distribuição de Linux com 'drivers' para as câmaras utilizadas e um conjunto de bibliotecas de funções. O sistema foi utilizado numa aplicação de um robot futebolista, para a sua localização da bola e dos outros robots. Palavras Chave: Sistema de Visão, Robótica Móvel, Baixo custo, Câmara USB.
1 INTRODUÇÃO
Este trabalho, enquadra-se nos esforços do laboratório de sistemas autónomos do ISEP no que diz respeito à obtenção de um sistema de visão para robótica móvel de baixo custo, baseado em componentes 'off-the-shelf', e versátil, capaz de facilmente se adaptar aos requisitos de uma determinada aplicação. Mais concretamente, a implementação deste sistema insere-se no projecto da plataforma móvel autónoma UTOPIA [Martins, 2001], pretendendo-se dotar esta plataforma de capacidades sensoriais baseadas em visão de baixo custo.
O sistema desenvolvido consiste num conjunto de hardware, um conjunto de bibliotecas de software, e o código relacionado com uma aplicação de teste específica.
A aplicação de teste que serviu de base para o teste do sistema desenvolvido, foi um sistema de visão para uma robot futebolista, mais concretamente, um robot vocacionado para a participação na classe F2000 das provas do Robocup. Nesta aplicação específica, pretendia-se que o sistema fornecesse informações sobre o posicionamento de vários objectos, quer fixos quer móveis, no referencial do robot. As informações obtidas devem por um lado, ter uma taxa de actualização elevada, e por outro, ter um baixa e previsível latência.
Este artigo está organizado da seguinte forma: inicialmente, serão analisados os requisitos impostos ao projecto, quer funcionais quer a nível da arquitectura do sistema e da sua plataforma de desenvolvimento. Seguidamente, são descritas as opções de projecto tomadas, nomeadamente a definição estrutural do sistema.
A arquitectura de software possuí características hierárquicas possuindo um conjunto de camadas encapsulam níveis de abstracção cada vez mais elevados.
Por fim, são apresentados alguns resultados que permitem ter uma ideia da funcionalidade e capacidade deste sistema para ser utilizado em robótica móvel. Concluindo-se o artigo, com algumas considerações relevantes sobre o sistema e referencias a trabalho futuro a realizar.
2 REQUISITOS
Um sistema de visão pode ser utilizado para muitas tarefas e cada tarefa pode ter requisitos operacionais diferentes. Podemos dizer, como exemplo, que um sistema de visão projectado para detectar defeitos numa linha de montagem de automóveis não será o ideal para utilizar num sistema de segurança de um banco. A concepção de um sistema de visão à medida do objectivo traz vantagens principalmente ao nível de rapidez, recursos e funcionalidades. No entanto,
podem existir desvantagens tais como a portabilidade e facilidade de "upgrade" que podem ser originadas pelo facto da especificidade do sistema projectado. Deste modo, chegamos ao seguinte conjunto de requisitos para a arquitectura do nosso sistema de visão, e cuja discussão se segue.
• Suportar múltiplas câmaras,
• Permitir um “frame-rate” razoável e com latência determinista.
• Portabilidade do software – suportado por várias arquitecturas de processadores, e câmaras.
• Baixo custo do sistema e do desenvolvimento do mesmo, bem como da manutenção do projecto. É importante que o sistema seja capaz de obter e tratar informação proveniente de mais do que uma fonte. Deste modo, o hardware utilizado deveria permitir a captura de imagens a partir de múltiplas câmaras. A utilização de múltiplas câmaras também deveria ser versátil, ou seja, deveria ser de fácil ligação e de fácil configuração.
O conjunto de hardware e software deveria garantir também que os resultados finais fossem obtidos rapidamente, ou seja, é importante garantir que conseguimos tratar imagens com um determinado “frame-rate”. O valor deste “frame-rate” é importante pois estamos a trabalhar com uma aplicação de robótica móvel, o que implica uma maior dinâmica em todo o processo.
O sistema operativo a utilizar deve ser portável de modo a não ficarmos limitados a um tipo de arquitectura de processadores. É importante que o sistema operativo também seja capaz de suportar um alargado leque de hardware de aquisição de vídeo e outros periféricos, uma vez que o sistema de vídeo pode estar partilhar o sistema computacional com outros subsistemas do robô.
Por outro lado, o sistema operativo deve dar garantias de acompanhar os sucessivos avanços no hardware. Todas estes requisitos não devem implicar um aumento no custo, quer de aquisição como de manutenção, do sistema operativo.
Os requisitos apresentados até este ponto focaram principalmente nos requisitos para a arquitectura, no que diz respeito a requisitos funcionais, podemos salientar:
• Versátil.
• Capacidade de detecção de objectos por cores e tipos de fronteiras.
• Permitir o fornecimento de estimativas sobre a posição dos objectos a pesquisar.
3 ARQUITECTURA
Para o desenvolvimento do projecto a primeira decisão a tomar foi em relação à arquitectura a utilizar. Das várias soluções possíveis que se considerou, podem-se destacar as seguintes:
• Hardware embebido + CCD
• PC + Frame grabber + Câmara de vídeo composto
• PC + Câmara USB
Nos 3 pontos seguintes, vamos proceder à discussão das vantagens e desvantagens das 3 hipóteses sugeridas.
3.1 Hardware embebido + CCD matricial A utilização de hardware dedicado exclusivamente ao sistema de visão permite libertar o processador principal do robot para outras tarefas. No entanto, o uso de hardware dedicado leva a que:
1. Seja necessário um elevado tempo de desenvolvimento, devido a todas as fases do projecto do hardware. O que significa tempo gasto sem ser em desenvolvimento de funcionalidades do sistema de visão propriamente dito.
2. O projecto de hardware pode ficar dependente de um determinado componente (ex: CCD ou microcontrolador) que, devido a rápida evolução destes componentes, pode ficar descontinuado, implicando alterações morosas no projecto. 3. No caso de alterações no hardware, seja
necessário o estudo dos novos componentes e a escrita de drivers para interface com os mesmos. 3.2 PC + Frame grabber + Câmara de vídeo
composto
Esta opção tem como vantagens a qualidade da imagem mas à custa de um preço mais elevado. A necessidade de utilização de várias câmaras, pode levantar problemas técnicos na utilização de muitos "frame-grabber’s” devido a limitações de “slots” e de IRQ e IO dos barramentos normalmente utilizados. Adicionalmente, caso se pretenda a utilização de cartas embebidas com barramento em formato PC/104 ou outros menos comercializados, os custos ainda são superiores.
3.3 Sistema computacional tipo PC + Câmara USB
Esta possibilidade consiste na utilização de uma ou várias câmaras ligada directamente ao PC que faz todo o processamento relativo às tarefas do robot. Deste modo, e de forma semelhante ao caso anterior, existe uma necessidade de não sobrecarregar o processador com o sistema de visão de modo a ser possível desempenhar as outras tarefas. Uma vez que normalmente os PC são equipados com pelo menos 2 portos USB, os custos para a utilização de até duas câmaras são relativos originando apenas do custo das câmaras (tipo “webcam”) utilizadas.
Um outro ponto importante, é o facto de num futuro próximo o aumento de banda proporcionado com a introdução do novo USB 2.0 [USB IF, 2001], permitir a utilização de mais câmaras e em modos de
maior resolução e/ou “frame-rate”. Sendo o sistema apenas limitado pela capacidade de processamento das imagens.
A escolha da arquitectura a utilizar, e de acordo com os requisitos traçados na secção anterior, recaiu na combinação de PC c/ USB + WebCam USB.
3.4 Sistema Operativo
O sistema operativo escolhido para proceder ao desenvolvimento desta aplicação foi o Linux.
A sua escolha prende-se com o facto de sendo um sistema operativo aberto (com código fonte livre) possuir as melhores características para a utilização quer do ponto de vista educacional quer para fins de investigação e desenvolvimento. De facto, para além de possuir um conjunto de características e qualidade técnica por si só, o facto de ser livre permite por um lado efectuar o desenvolvimento sem ligações comerciais particulares e acima de tudo permite o acesso ao código. Isto acarreta uma vantagem primordial pois para além das possibilidades didácticas que nos confere (tendo em atenção os objectivos educativos do sistema), permite-nos também conhecer com todo o detalhe o funcionamento de todo o sistema e desta forma efectuar o projecto de forma muito mais eficaz. O factor custo é também uma vantagem significativa. Acresce a que sendo um sistema operativo desenvolvido segundo um modelo cooperativo com um vasto número de programadores, temos a garantia do seu continuado desenvolvimento, a adaptação a novo hardware (e neste caso em particular a existência de drivers para novos modelos de câmaras) e a possibilidade de apoio por parte desta comunidade cooperativa de desenvolvimento. Do ponto de vista técnico apresenta um conjunto de funcionalidades face a possíveis competidores. Como é um sistema operativo bastante escalável e modular é possível inserir módulos no kernel à medida das nossas necessidades ou instalar novos serviços possibilitando a utilização de uma distribuição compacta e versátil. Esta é uma grande vantagem pois permite-nos utilizar um sistema operativo que ocupa e consome poucos recursos, quer em necessidade de memória quer em armazenamento, sem perda de funcionalidade. Para um sistema de visão que vai funcionar em robótica móvel é necessário garantir que se consiga agir em tempo útil. A existência de extensões para o Linux para tempo real (quer dedicadas por distribuição, quer a mais usuais como o RTLinux ou RTAI) permite-nos ter a garantia da satisfação dos diversos requisitos quer “soft” ou “hard2 “realtime” A possibilidade de utilizar o barramento USB é de extrema importância devido às vantagens provenientes da sua utilização cada vez mais universal para comunicação com periféricos e em particular com câmaras.
Com o lançamento do kernel 2.4.0 , o suporte para USB em Linux foi incorporado no kernel eliminando algumas das questões de estabilidade levantadas em versões anteriores.
Em Linux é utilizado o Video4Linux como camada de software para trabalhar com vídeo. As ferramentas que são disponibilizadas são suficientes para a concretização do sistema de visão. É uma das componentes que se encontra em desenvolvimento e como tal é de esperar a melhoria das funcionalidades oferecidas e de desempenho.
3.5 Câmaras Vídeo
As câmaras utilizadas são do tipo “webcam”. Este tipo de câmaras têm várias vantagens que justificam a sua utilização.
O seu preço é bastante reduzido. Actualmente o preço de uma câmara deste tipo é menor do que duas dezenas de contos, tornando-as bastante acessíveis quando comparadas com outro tipo de câmaras. O facto de não necessitarem de qualquer tipo de hardware adicional para proceder à aquisição de imagens também contribui para que seja uma solução barata.
Apesar do seu baixo custo a qualidade de imagem que estas câmaras fornecem, embora sendo menor do que outro tipo de câmaras, é suficiente para a nossa aplicação. Além disso, estas câmaras têm um tamanho e um peso reduzido, graças à sua simplicidade, e apresentam reduzidos consumos energéticos.
Com estas câmaras é possível atingir valores de 30 frames por segundo com um formato de 320x240. O driver desenvolvido para Linux ainda não suporta 60fps neste formato, embora isso já seja possível. Com a utilização do formato 640x480 não é possível obter um “framerate” superior a 15 fps. Este valor é limitado pela largura de banda do barramento USB. Com a futuro aumento da taxa de transferência do barramento USB [USB IF, 2001] será possível alcançar um “framerate” ainda maior. A ligação USB é útil pois é de extrema facilidade e universal, não trazendo o problema de futuras incompatibilidades. Uma das desvantagens da utilização deste tipo de câmaras é a falta de informação relativa as características técnicas dessas câmaras. Os valores dos ângulos de abertura horizontal e do ângulo de abertura vertical, bem como a distância focal nem sempre são fornecidos. O facto destas câmaras serem orientadas para uso não profissional faz com que os fabricantes não divulguem as especificações técnicas dos seus dispositivos.
3.6 Escolha do barramento USB
A escolha do tipo de ligação a utilizar foi relativamente fácil. A opção de utilizar câmaras com USB [USB IF,2001] é justificada pela crescente utilização e generalização deste barramento. Cremos
que é um tipo de ligação que se manterá por alguns anos dada a forte aceitação do mercado. Actualmente as câmaras do tipo “webcam” vendidas são com ligação USB sendo já difícil encontrar com ligação à porta paralela. Este tipo de ligação tem muitas vantagens. È de fácil de ligação e permite ligações do tipo hotswap. Deste modo é possível fazer a substituição de uma câmara facilmente e sem ter de fazer um “reboot”. É uma ligação simples e pouco sujeita a problemas de conexão. Cada PC vem normalmente com dois portos USB sendo possível aumentar o seu número facilmente. Este facto permite-nos pensar na possibilidade de utilizar mais do que uma câmara.
4 SOFTWARE
Um sistema de visão trabalha com imagens que podem exigir elevados recursos computacionais para as processar. É essencial que se consiga dar importância àquilo que realmente merece importância. Numa imagem, normalmente, apenas uma pequena parte tem informação útil. Os algoritmos utilizados devem ser o mais eficientes possível, mas não devem desprezar informação excessivamente. Esta relação entre estas duas características deve ser ajustada para cada situação. Na maioria das situações é desejável que um sistema de visão computacional, tenha o comportamento semelhante ao da visão do ser humano. Podemos dar como exemplo o condutor de um carro, viajando ao longo de uma estrada no campo. As suas tarefas visuais consistem em seguir a estrada, observar o tráfego e sinais e evitar obstáculos na estrada. Para realizar estas tarefas ele não precisa de analisar detalhadamente tudo o que vê.
O humano é capaz de recolher informação detalhada de uma pequena região de toda a imagem, não deixando de ter noção de tudo o que está na imagem. Esta capacidade permite ao condutor prestar atenção à estrada, enquanto que quase não repara no arbusto que se move ou nas folhas que caem. Outro exemplo poderá ser o operário que inspecciona uma peça à procura de um defeito. O objecto pode ser grande mas o operário localiza rapidamente os pontos que necessitam de uma inspecção mais rigorosa.
É essencial que um sistema de visão seja capaz de implementar estas estratégias de visão "inteligente". Estas podem passar por uma analise a toda a imagem de uma forma rápida e eficiente, de modo a dirigir a análise mais detalhada para onde é necessário. Uma melhoria ainda mais significativa obtém-se através da integração de informação recolhida nos instantes anteriores e de modelos do sistema, prevendo em que região de imagem devemos concentrar-nos, ou, se necessário, dirigir o nosso "olhar" num dado sentido. O nosso sistema de visão segue duas grandes linhas de orientação. É necessário que o sistema de visão seja o mais rápido possível e gaste o mínimo de recursos possível. Todo o desenvolvimento efectuado
teve em consideração o compromisso entre rapidez e a qualidade da informação obtida.
O sistema de visão foi desenvolvido de uma forma hierárquica. Deste modo foi possível construir funcionalidades complexas à custa das mais elementares e desenvolver diferentes níveis de funcionalidades que permitem a utilização flexível do sistema.
Na figura seguinte podemos observar a arquitectura de software do sistema. Device Driver Video4Linux Processamento de cor Classificação de objectos Hardware (USB, câmera) Gestor do Sensor Pedidos Informação de Visão
Sistema Operativo ( Linux)
Hardware Sistema de Visão
Fig. 1. Arquitectura de software.
Deste modo podemos dividir o sistema de visão em várias componentes.
4.1 Abertura do device
Para a obtenção da imagem é necessário proceder à abertura do device relativo à câmara. Esta camada permite-nos estabelecer as ligações com as câmaras que estiverem a ser utilizadas. O suporte para um determinada câmara pode ser incluído no Kernel do Linux aquando da sua compilação ou pode estar sob a forma de um modulo do ‘Kernel’, que pode ser adicionado ou removido dinamicamente, quando necessário.
4.2 Aquisição de imagem
Para trabalhar com o vídeo em Linux é necessário utilizar o Video4Linux , que consiste num conjunto de funções que permite ao utilizador configurar e adquirir vídeo e áudio de um dado dispositivo. O Video4Linux tem definidas um conjunto de estruturas que são utilizadas em conjunto com uma diversidade de parâmetros de configuração da forma de I/O, para realizar as mais variadas tarefas.
4.3 Análise da imagem
A camada anterior fornece-nos uma imagem pronta para ser trabalhada. Esta camada, disponibiliza um
conjunto de funções de processamento da imagem que permitem retirar dela a informação desejada. O processamento da imagem pode incluir algum processamento de cor. Este pode ser definido por forma a calibrar, equalizar ou alterar a informação de cor recebida com objectivos determinados (tais como melhorar a sensibilidade geral do sistema a determinadas cores ou eliminar ruído).
Mais uma vezes relembramos que o principal objectivo consiste na identificação de objectos
Fig. 2. Imagem exemplo e identificação por amostragem.
pertencentes ao cenário que nos envolve. Surge neste momento a questão de como detectar um objecto na imagem? É de conhecimento prévio quais, e como são os objectos possíveis de encontrar.
Existem três pontos importantes que serviram de ponto de partida para a escolha da melhor técnica a utilizar para referida identificação
• O facto de conhecermos a forma e o tamanho dos objectos permite-nos desenvolver um tipo de análise de imagem que melhor se adapta a cada objecto.
• Todos os objectos têm cores bem definidas e conhecidas. O conhecimento destas cores será essencial no processo de identificação dos objectos.
• Na nossa aplicação existem dois tipos de objectos: os móveis e os imóveis. No entanto, todos eles têm uma localização previsível (os moveis podem causar maior dificuldade). O facto de conhecermos a sua posição vai-nos
possibilitar minimizar o tempo de processamento e escolher a melhor técnica a utilizar.
Deste modo a classificação de objectos fornece-nos a informação sobre os objectos na imagem.
4.4 Gestor do sensor
O sistema de visão em robótica móvel pode ser utilizado para muitos fins. Por exemplo em futebol robótico pode ser usado para localizar a bola, para localizar o robot, para identificar balizas alvo, etc. Estas diferentes utilizações do mesmo recurso sensorial necessitam de informação diferente da imagem. Se para localizar a bola pode bastar encontrar a zona de uma dada cor na imagem (neste caso laranja) para localizar os adversários não basta procurar uma só cor. Por outro lado, existem prioridades em termos de informação a processar, e é necessário coordenar o processamento da imagem com a sua utilidade pois uma imagem passada de um objecto em movimento pode perder a sua validade. A tarefa do módulo gestor do sensor é gerir o processamento de imagem e fornecer a informação pretendida para os diversos utilizadores, sejam eles módulos de navegação, desvio de obstáculos ou coordenação e planeamento. Cada cliente do gestor regista-se indicando que informação pretende receber e define o modo de recepção. O gestor sensorial é responsável por processar as imagens e descartar imagens velhas e iniciar o processo de aquisição de novas imagens.
Utiliza todas as funcionalidades das camadas inferiores e efectua a sua parametrização.
4.5 Teste
Embora não constitua por si só uma camada ou módulo do sistema, importa referir a importância das ferramentas de teste no desenvolvimento do sistema. Todos os resultados obtidos com o sistema de visão devem ser dignos de confiança. Para isso também foram desenvolvidas várias ferramentas de teste quer para o desenvolvimento quer para monitorar o seu funcionamento. Estas ferramentas também nos permitem saber qual o grau de confiança que devemos ter nos nossos resultados.
5 APLICAÇÃO AO ROBOCUP
Na aplicação deste sistema de visão ao robô Utopia para a participação no robocup, importa definir os pontos que se seguem:
• Definição do numero de câmaras
• Posicionamento das câmaras
• Objectos de interesse
• Métodos usados no seu posicionamento
Serão utilizadas duas câmaras, uma vez que, por um lado, devido às limitações actuais do USB 1.1 e das capacidades de processamento instaladas no sistema computacional utilizado, seria difícil obter imagem de mais de duas câmaras a uma taxa de refrescamento aceitável. Por outro, a utilização de apenas uma câmara dificultava a alocação da visão em simultâneo à localização própria, navegação, localização dos outros robôs, e localização e seguimento da bola.
A utilização de duas câmaras permite colocar uma fixa com o mecanismo de chuto, que pode rodar em torno do centro do robô. Esta tem como função primordial a localização da bola com maior precisão, de modo a ser possível efectuar manobras de recepção da bola e o controlo do chuto da mesma. E uma segunda câmara, montada num mecanismo de rotação adicional, destinada a detecção de marcas do campo (postes, balizas, e marcas no chão) e de outros robôs. Esta última tem como função a localização dos robôs da própria equipa bem como dos adversários, no campo. Sendo a divisão da atenção sensorial variável consoante a tarefa do sistema, isto é, quando por exemplo o robô está a efectuar movimentos mais rápidos de deslocação, a atenção sensorial focará as questões de obstáculos à movimentação para uso pelo subsistema de desvio de obstáculos (principalmente robôs da equipa adversária, uma vez que os outros elementos da equipa fornecem dados sobre o seu posicionamento). Quando o robô está apenas em suaves movimentos de posicionamento no campo, a maior parte da atenção poderá ser dirigida para marcas no campo, no caso da incerteza na posição ser baixa, ou adversários, bola ou mesmo robôs da própria equipa cuja incerteza no posicionamento próprio seja elevada.
No que diz respeito à qualidade da informação, ela varia com o tipo de objectos a ser visualizados e com a posição das câmaras. Isto é, apesar de a câmara só fornecer realmente o equivalente a dois ângulos num sistema esférico, sendo a distancia uma incógnita. Partindo de alguma informação sobre o ambiente do robô, por exemplo que as marcas no chão do campo estão situadas determinado num plano, podemos obter, uma estimativa da posição destas marcas no referencial do robô.
Como podemos verificar pela figura seguinte, neste tipo de colocação da câmara, a qualidade da informação sobre a distância de um objecto decresce de forma não linear com a distancia deste.
∆ α
d
Robot
h Câmara
Fig. 3. Qualidade de medida versus distância.
Para a classificação de objectos aplicada ao futebol robótico, foram implementados vários métodos [Patacho,2000]. São utilizados várias pesquisas de detecção quer por varrimento de cor quer por detecção e seguimento de contorno (ver Fig. 2 e 4). Estes métodos usam amostragem adaptativa por forma a tirar partido da informação conhecida à priori e aumentar a rapidez de processamento. Adicionalmente são usados apenas varrimentos por linha ou coluna, quando não é necessário identificar a outra dimensão (como por exemplo na detecção das marcas verticais nos cantos do campo.
Fig. 4. Identificação por pesquisa de contorno.
6 RESULTADOS
Em seguida são apresentados alguns resultados em termos de tempos de execução para diferentes funções de análise de imagem.
O configuração do sistema usada nos testes foi: Câmara Philips Vesta Pro
PC Pentium III 450 MHz, 64 Mb RAM Kernel Linux 2.4.2
6.1 Pesquisa da bola pelo método de amostragem Sem estimativa inicial
Tempo (ms) Passo
Amostragem Bola a 1 m Bola 4 m
1 23.8 23
2 6 5.9
4 1.5 1.5
Tabela 1. Pesquisa de bola sem estimativa inicial. Com estimativa inicial
Tempo (ms) Passo
Amostragem Bola a 1 m Bola 4 m
1 3 0.131
2 0.75 0.036
4 0.20 0.0086
Tabela 2. Pesquisa de bola com estimativa 6.2 Pesquisa da bola por contorno:
Toda a imagem : 14 ms Com estimativa: 95 µs
Saliente-se nestes resultados a importância da estimativa inicial para reduzir a carga computacional. Com uma só câmara, para imagens com o formato 320x240, conseguimos garantir a utilização de um framerate entre 25 e 30 fps, dependendo da quantidade de informação a pesquisar.
A utilização de duas câmaras vai permitir-nos obter valores semelhantes se utilizarmos imagens com o formato de 160x120, ou valores ligeiramente diferentes se utilizarmos outras combinações de formatos.
7 CONCLUSÕES
Neste artigo, foi apresentado o estado do desenvolvimento do sistema de visão da plataforma móvel Utopia: a sua motivação, justificação da arquitectura de hardware e software utilizadas, uma possível aplicação a um futebolista robótico, alguns resultados preliminares bem como ideias sobre possíveis formas de utilização da informação obtida pelo sistema.
O sistema desenvolvido apresenta um conjunto de vantagens significativo face às soluções actualmente empregues em visão robótica, de entre estas salienta-se a relação custo/desalienta-sempenho e a adquação aos avanços técnicos em termos de sistemas computacionais, meios de comunicação de dados e sistemas de aquisição de imagem. A utilização do binómio Linux – Câmara USB permite tirar partido do baixo custo determinado pelo mercado das câmaras, do desenvolvimneto tecnológico que esse mercado induz e das capacidades técnicas do sistema operativo.
No entanto, existe muito trabalho que ainda está a decorrer ou que será brevemente abordado, e do qual podemos salientar:
1. No que diz respeito ao sistema de visão:
§ Definir um conjunto de teste padrão, bem definidos e de fácil execução, para a avaliação da performance do sistema, quer em termos de custo computacional, que em termos da qualidade da informação obtida. § Incrementar o conjunto de funções de
análise de imagem disponíveis na biblioteca respectiva.
§ Optimizar as funções existentes.
§ Implementar funções de auto-calibração em termos de cores, iluminação e outros parâmetros da imagem.
2. No que diz respeito à aplicação ao futebol robótico:
§ Implementar funções de auto-calibração das posição das câmaras.
§ Análise dos resultados quando as câmaras são sujeitas a movimentos rápidos de rotação e translação.
§ Análise da variância da informação quando os robôs estão em movimento, devido as oscilações das câmaras.
§ Integração das informações provenientes das câmaras com o sistema de “dead reckoning” e bússolas magnéticas.
§ Implementação de estratégias de controlo e gestão do sistema de visão por forma a maximizar a informação obtida consoante as necessidades do sistema num determinado instante.
Finalmente, importa salientar que as opções tomadas garantem uma robustez do sistema a possíveis situações de obsolescência, e permitem tomar partido dos avanços tecnológicos que possam surgir quer em termos computacionais, quer em termos de barramento USB, quer em termos de câmaras vídeo de baixo custo. Adicionalmente, podemos referir que a mesma arquitectura seria possível de utilizar com outro tipo de barramento serie como o 'Firewire' ou mesmo a integração com inúmeros tipos de dispositivos de aquisição de imagem.
8 REFERÊNCIAS
USB IF (2000b), “Universal Serial Bus Revision 2.0 specification”, USB Implementers Forum, Inc. 2000.
Patacho, António e Marques, César (2000), "Sistema de visão para Robótica Móvel", Trabalho Final de Curso, ISEP, 2000.
Martins, Alfredo, A. Patacho, E. Silva, L. Lima, J. Baptista e J. Almeida, “Do projecto à
implementação da plataforma móvel UTOPIA”, Actas de Festival Robótica 2001, Guimarães, 25-28 Abril 2001.
