MAC 499
Trabalho de Formatura Supervisionado
Alunos : Danilo Eiji Seki
Thiago Schumacher Barcelos
Supervisor : Prof. Dr. Carlos Hitoshi Morimoto
Tipo de trabalho : Iniciação Científica
Projeto
Introdução

Uma das áreas de pesquisa de grande interesse no campo da Interação Humano-Computador é o aumento da velocidade da interação. A entrada nos sistemas atualmente em uso é limitada à escrita através de um teclado e ao apontamento, através de dispositivos tais como o mouse, canetas ópticas ou touch screens. Tais métodos de entrada são insuficientes para atender às necessidades de novos dispositivos computacionais como, por exemplo, computadores pessoais portáteis. Ainda, novos paradigmas de interação, como a realidade virtual, criam novas necessidades no desenvolvimento de dispositivos de interação.

olho

Uma possibilidade em estudo há vários anos é o desenvolvimento de rastreadores de olhar, ou seja, dipositivos capazes de indicar a posição observada pelo usuário, em geral sobre a tela de um monitor. Este trabalho baseia-se em um rastreador de olhar descrito em [1] e no MAGIC Pointing [2], que é uma aplicação do rastreamento de olhar nas interfaces WIMP (Windows, Icons, Menus and Pointing). O MAGIC Pointing usa a informação da posição observada pelo usuário para acelerar o controle do cursor do mouse.

mouse

Infelizmente, a precisão atualmente obtida pela tecnologia de rastreamento cria alguns obstáculos ao uso da informação da posição observada, exigindo o desenvolvimento de técnicas de ajuste dos dados fornecidos pelo rastreador. Esse é exatamente o objetivo do MAGIC Pointing - em [2] foram descritas duas estratégias de posicionamento do mouse a partir da posição observada. O objetivo desse trabalho foi a implementação e teste de uma nova estratégia de posicionamento que, com o objetivo de melhorar o ajuste, leva em consideração mais informações sobre o alvo de interesse usual do usuário nas interfaces atuais - os widgets, ou controles.

O problema e a proposta
A tecnologia de rastreamento de olhar

câmera infravermelhaA tecnologia de rastreamento de olhar empregada neste trabalho usa uma câmera sensível à luz infra-vermelha que possui dois conjuntos de luzes: um próximo ao eixo óptico e um afastado. O conjunto central acende intermitentemente, gerando dois tipos de imagem de olho: um com a pupila iluminada pelo primeiro conjunto de luzes (como no efeito que conhecemos como o efeito de "olho vermelho" em fotografias), e um com a pupila escurecida. Um processo de subtração byte a byte das imagens é realizado, obtendo-se uma figura binária (contendo apenas cores pretas e brancas), onde aplica-se um algoritmo de reconhecimento de formas, identificando a forma da pupila e do brilho ocular gerado pelo segundo conjunto de luzes.

A partir da posição encontrada da pupila (Ppupil) e do brilho ocular (Pglint), é possível obter o vetor Ppupil - Pglint , que indica a posição observada pelo usuário, após um processo de calibragem: o usuário é solicitado a olhar para nove posições na tela do monitor, e a partir de um processo de aproximação usando um polinômio do segundo grau, obtem-se uma transformação de um vetor Ppupil - Pglint para um ponto na tela do monitor.

olho brilhante - olho normal = resultado da subtração

A pergunta que surge é: como utilizar essa informação recém-gerada para melhorar a interação? A aplicação imediata que surge é usar essa informação para o controle do cursor do mouse. Estudos mostram que a aquisição de um alvo (target acquisition) de apontamento exige, dentre outras tarefas, uma busca visual do alvo desejado seguida por uma tarefa motora. Teoricamente, existindo uma maneira de eliminar a tarefa motora, uma parcela de tempo necessária para obter o alvo seria eliminada.

linhas da pupila e brilho

Porém, não é o que pode acontecer atualmente na prática por uma série de fatores. Antes de tudo, o olho não é uma "ferramenta" precisa como as mãos, por exemplo, estando sujeito a uma série de pequenos movimentos involuntários. Existe ainda um grau de imprecisão causado pela aproximação feita pelo processo de calibragem. Ainda, os modelos mais eficientes de calibragem existentes atualmente exigem que a cabeça do usuário fique parada, causando um certo grau de desconforto no uso do sistema.

MAGIC Pointing

A proposta do MAGIC Pointing é então conjugar, nas ações do usuário necessárias para efetuar o apontamento, a busca visual do alvo e a tarefa motora, diminuindo a necessidade de realização dessa última em vez de eliminá-la. A informação do rastreamento de olhar é usada para determinar a região aproximada de interesse do usuário, enquanto que o mouse é usado para fazer o ajuste fino da posição do cursor.

Veja abaixo uma animação explicando o que acontece quando o sistema detecta uma posição dentro de um raio de tolerância centrada no apontador do mouse:

detecção próxima

Agora, veja a animação explicando o que acontece quando a posição detectada está distante do apontador do mouse:

detecção distante

Existem várias alternativas de definição da política de posicionamento do cursor a partir da posição indicada pelo rastreador. Já foram implementadas e descritas em [2] duas políticas: uma faz a movimentação do cursor para a posição observada somente quando o usuário movimenta o mouse, e outra movimenta o cursor sempre que a posição observada afasta-se além de um certo limite da posição do cursor do mouse.

Nossa proposta

As políticas já implementadas atuam sempre sobre a posição informada pelo rastreador, sujeita as várias formas de imprecisão descritas anteriormente. Com o objetivo de atenuar o efeito dessas imprecisões, a proposta deste trabalho é agregar ao MAGIC Pointing mais informação a respeito da interface sobre a qual ele atua.

botão de procura

Mais precisamente, a proposta é agregar ao sistema informações sobre os widgets que compôem a interface - afinal, é sobre cada ícone, botão ou caixa de texto que está focada a atenção visual do usuário ao realizar suas tarefas. Considerando que a dimensão da maioria dos widgets usuais está próxima dos limites de precisão do sistema, buscamos maior eficiência e conforto na execução de tarefas reais nas interfaces gráficas.

Animação da política de widgets sem encontrar objetos próximos:

detecção distante de widget

Animação da política de widgets encontrando objetos próximos:

detecção próxima de widget

Planejamento inicial

Inicialmente, em conjunto com nosso orientador, decidimos pelo cronograma exibido abaixo.

Atividade Jun Jul Ago Set Out Nov Dez
1 X
2 X X X
3 X X
4 X X
5 X X
6 X
7 X X
8 X X
  1. Familiarização com ferramentas e ambiente de desenvolvimento, e programa de rastreamento do olhar
  2. Implementação de extensões do MAGIC Pointer
  3. Estudo do método de avaliação de interfaces
  4. Definição dos experimentos e elaboração dos formulários de avaliação
  5. Implementação, testes e refinamentos dos experimentos e formulários
  6. Condução dos experimentos
  7. Análise dos resultados
  8. Elaboração do relatório final e documentação
Organização

Como o projeto foi desenvolvido por uma equipe, é importante descrever a organização desse grupo de trabalho. Nossa equipe, na verdade uma dupla, foi formada pelos alunos Danilo Eiji Seki e Thiago Schumacher Barcelos. Todo o desenvolvimento do projeto foi feito em etapas de desenvolvimento paralelo com eventuais desenvolvimentos em conjunto.

Durante um período inicial, Thiago estudou a linguagem de programação C++ e principalmente todo o código-fonte da versão existente do programa. Daí para frente, alternamos os dois métodos de desenvolvimento. Nos reunimos para discutir o projeto e desenvolvermos em conjunto, lado a lado, no laboratório. Desse modo, pudemos nos comunicar, nos conscientizando das idéias um do outro e tomar decisões em conjunto, sempre discutindo e levando em consideração ambas as opiniões.

No final do dia, discutíamos o que foi feito e o que precisaria e poderia ser feito em paralelo. Normalmente, foram realizados nesses períodos pesquisas sobre a estrutura do sistema operacional, pesquisas e testes sobre a API (biblioteca de desenvolvimento) do mesmo e, logicamente, desenvolvimento em seções distintas do código, que poderiam ser facilmente unificadas. Após algum tempo trabalhando individualmente, marcávamos sempre que podíamos novas sessões de trabalho simultâneo, para discutimos e definir novas responsabilidades.

Ferramentas e Técnicas

O projeto foi desenvolvido tanto no laboratório do IME como nas residências dos participantes. Os recursos de hardware no início do projeto eram uma câmera de espectro infravermelho com LED's infravermelhos e um computador no laboratório e, nas residências de cada um, seus respectivos computadores. Durante esse período, como o equipamento disponível não era "poderoso" suficiente para executar o aplicativo com desenvoltura, concentramos nossos esforços em aprendizado e pesquisa em casa. De acordo com o previsto, novos computadores foram adquiridos e instalados no laboratório. Por nós, foram utilizados principalmente dois computadores, Latin-1 e Latin-2, com poder computacional suficiente para executar o Eyetracker e o Magic Pointing sem problema algum.

Latin-1 e Latin-2 eram os nomes das máquinas no ambiente Windows XP, no qual o projeto foi desenvolvido. Além disso, ambas as máquinas possuíam configurações idênticas: processador AMD Athlon XP 1600+, 512 MB de RAM e placa de captura de vídeo da Pinacle. Estando em rede e possuindo os mesmos aplicativos de desenvolvimento instalados, as máquinas foram utilizadas indistintamente. Havia preferência apenas pela máquina na qual estava, em cada momento, conectada a câmera e, nesta última, a fonte de energia, pois desse modo não haveria necessidade de se trocar as conexões.

Na aspecto de software, foram utilizados diversos programas, cada um com sua finalidade específica. Para programação e desenvolvimento (desenho) da interface, foi utilizado o programa Microsoft Visual C++. Os programas Tera Term e puTTy foram utilizados para acessar a Rede Pró-Aluno do IME e para transferir arquivos dela e para ela. Finalmente, para navegar na Internet, ler e enviar eMails e, principalmente, consultar documentações on-line, foi utilizado o Microsoft Internet Explorer.

Outro aspecto muito importante de software é a biblioteca de reconhecimento de imagens. Versões antigas do programa utilizavam a Microsoft Vision SDK, uma biblioteca experimental desenvolvida por grupos de pesquisa da Microsoft. No entanto, ramificações mais recentes do programa já fornecidas para nós utilizam uma outra biblioteca, a OpenCV, da Intel. Dentre algumas vantagens podemos citar o fato da OpenCV ser disponibilizada sob uma licença de código aberto e ter uma versão para Linux, já que nosso orientador tem planos de portar o sistema para essa plataforma.

Implementação

Após a etapa de aprendizado e familiarização, iniciamos a implementação do projeto. Tendo recebido do nosso orientador uma versão do programa para modificar, começamos por implementar políticas de posicionamento do mouse. A partir dela, utilizando nossos conhecimentos, criamos então três políticas de posicionamento para testar o comportamento do sistema. Duas dessas políticas dividiam a tela em nove partições e, a partir da posição indicada pelo rastreador, moviam o cursor do mouse para o centro ou canto superior esquerdo de cada partição. Uma terceira política ainda movia o mouse apenas quando a posição observada estava a uma determinada distância da posição atual do mouse. Verificamos que o cursor do mouse permanecia muito "instável" com essas políticas, e que maiores refinamentos seriam necessários.

diagrama

Logo depois tomamos contato com uma implementação anterior do MAGIC Pointing, que não sabíamos até aquele momento que existia. Essa implementação já tinha vários filtros dos dados oriundos do rastreador implementados, além das políticas descritas em [2]. Porém, sua implementação foi feita pensando-se na integração com uma versão mais antiga do rastreador. O código estava estruturado para compilar como uma DLL (Dynamic Link Library); após algum trabalho de adaptação, esse código estava em funcionamento com a nova versão do rastreador.

Partimos, então, para a implementação da nova extensão. O primeiro passo foi implementar um handler para um evento de janela gerado pelo sistema operacional. Esse handler é chamado sempre que uma janela é ativada, movida ou redimensionada, e é útil porque esse é o momento para obter novamente infomações sobre o posicionamento dos widgets. As informações sobre widgets são mantidas em uma lista linear, para que a cada dado recebido pelo MAGIC Pointing não seja necessário fazer uma nova chamada à API. Foi necessário manter a lista linear em uma região de memória compartilhada entre processos pelo sistema operacional devido a uma curiosa particularidade do Windows. Por estar contido no código de uma DLL, o código do handler é mapeado no espaço de memória do processo que possui a janela que gerou o evento. Desse modo, se a lista não estivesse em uma região de memória compartilhada, o programa rastreador não encontraria a lista. O espaço de memória que contém a lista ligada deve, então, ser acessível a cada processo que gerar um evento descrito acima.

O handler então chama outra função que busca os widgets contidos na janela. A partir de um número inteiro, que é seu identificador único, utiliza funções da API para realizar um procedimento muito semelhante a uma busca em profundidade no que seria uma árvore hierárquica de widgets. Nesse momento os widgets que podem ser tratados pelo MAGIC Pointing são identificados e adicionados à lista. Note que no momento nosso programa mapeia apenas os objetos da janela ativa. Isso acontece porque assumimos que os widgets que não estão na janela ativa não serão apontados com grande freqüencia ou importância. Essa aparente negligência aumenta significativamente a eficiência do mapeamento, pois tratar os widgets de janelas de segundo plano tem vários complicadores, como objetos parcialmente visíveis, centros escondidos, prioridade para elementos de primeiro plano, etc.

A DLL tem quatro pontos de entrada, uma para cada política de posicionamento do cursor do mouse implementada.

Além disso tudo, fizemos uma alteração na calibragem do sistema. Pelo método original, o programa tentava capturar nove detecções válidas, ou seja, nove frames nos quais tanto o centro da pupila como o brilho ocular eram detectados com sucesso. O problema disso é que nem sempre é fácil conseguir uma detecção válida - devido principalmente a ruído na imagem e foco da câmera, quanto mais nove em seguida. Com isso, perdíamos mais tempo na calibragem do que no teste desejado. No método modificado, assumimos que próximo ao momento da detecção válida, houve pelo menos uma detecção válida anterior na qual o usuário estava observando o ponto em questão da calibragem. Com isso, reduzimos o número de erros na calibragem para zero, aumentando consideravelmente a eficiência de nossos esforços.

Finalmente, já preparando a fase de testes, alteramos levemente a interface gráfica do programa. Essencialmente, adicionamos a possibilidade de escolha da política de posicionamento sem a necessidade de se alterar o código fonte e recompilar o programa.

screenshot
Clique na imagem para vê-la em tamanho real.

Estado final do projeto

Embora muito tenha sido feito, o projeto, infelizmente, não pôde ser concluído. Podemos dizer que vários fatores contribuíram para isso. Os mais significativos provavelmente são a má eficiência do uso tempo, o grande esforço desviado para outras disciplinas e talvez um objetivo um tanto mal dimensionado. Mas mesmo com tudo isso, várias etapas do projeto foram completadas, e tantas outras iniciadas ou já planejadas. Segundo o programa descrito no planejamento inicial, cumprimos a primeira e a segunda etapa. Respectivamente, nos familiarizamos com as ferramentas, o ambiente de desenvolvimento e o programa de rastreamento de olhar, e implementamos a extensão do MAGIC Pointer. Embora sejam apenas duas das oito partes que foram propostas, acreditamos que essas etapas representem grande parte do trabalho que havia sido previsto.

A primeira etapa, de aprendizado e familiarização com linguagens, ambiente e o programa em si, pode ser considerada totalmente completa. Após vários meses em contato com o projeto, adquirimos proficiência básica a avançada em todas essas áreas de conhecimento. Por exemplo, a respeito da estrutura do Windows e seus métodos, a aquisição de conhecimento, a partir de agora, será através da leitura da documentação, com a qual já nos habituamos. Não nos esquecendo da linguagem C++, já conseguimos ler com certa facilidade programas escritos com ela e também programar utilizando alguns recursos e características específicas dela.

Quanto à implementação, segunda etapa do projeto, podemos resumir o que foi descrito na seção dedicada a esse assunto. Conseguimos modificar o código criando uma base para o reconhecimento de widgets que, apesar de estar reconhecendo e tratando um número limitado de widgets, pode ser facilmente extendida para responder perfeitamente a qualquer widget do sistema de janelas, desde que a API forneça informações suficientes sobre eles. Atualmente, reconhecemos botões, caixas de seleção (list boxes) e caixas de opção (radio e check buttons).

Apesar de iniciada a pesquisa das funções apropriadas da API, enfrentamos problemas em diferenciar algumas classes comuns de widgets. Em particular, não conseguimos diferenciar caixas de agrupamento, tratadas como botões pelo sistema de janelas Windows. Apesar de devidamente testado, o reconhecimento de widgets desabilitados ainda não foi incorporado ao código. Finalmente, o problema de manipular ícones da área de trabalho e botões de barras de ferramentas foi pesquisado e identificamos métodos que poderão resolver a questão, dependendo ainda de testes mais refinados.

As etapas seguintes à implementação seriam a modelagem de testes, a realiazação dos mesmos e a análise dos resultados. Embora não tenhamos iniciado oficialmente essa fase, já realizamos alguns trabalhos que a facilitarão. Por exemplo, foi feita uma rápida remodelagem da interface do programa e uma alteração no método de calibragem com o objetivo de deixar os testes menos confusos e, principalmente, menos cansativos para o usuário.

Também começamos a considerar algumas rotinas de teste que poderão ser utilizadas para avaliar o sistema. Basicamente, teríamos duas rotinas de teste. A primeira rotina verificaria a conformidade do apontamento auxiliado pelas informações sobre widgets com a já estabelecida Lei de Fitts. Para tanto, o usuário observaria (e posicionaria o mouse sobre) um objeto (provavelmente, um botão) no canto superior esquerdo na tela. Em seguida o usuário clicaria em outros objetos que apareceriam em posições com diferentes distâncias da posição original. Para testar o tamanho, exibiríamos objetos de diferentes tamanhos e em diferentes direções, mas a um mesmo raio de uma posição inicial. A segunda rotina consistiria de alguma tarefa usual do ambiente Windows (por exemplo, abrir uma aplicação ou copiar um arquivo), para que o usuário pudesse, com base em sua experiência anterior no ambiente, dar sua opinião subjetiva sobre o novo sistema; se este lhe parece tornar a tarefa mais ou menos rápida, mais ou menos confortável...

Como se pode ver, o projeto está pronto para ser acabado, bastando algumas peças finais e, talvez, algum refinamento e ajuste das rotinas principais. Em seguida, já seria possível concluir as etapas de estudo de métodos de teste e os testes em si. Como é um projeto interessante e que, sobretudo, ainda lida com diversas tecnologias não abordadas no curso regular do Bacharelado em Ciência da Computação, acreditamos que futuros pesquisadores - ou alunos a procura de um trabalho de formatura - possam considerar a possibilidade de dar continuidade a ele, tanto ampliando a sua funcionalidade quanto desenvolvendo aplicações que utilizem o apontamento auxiliado pelo olhar.

Acompanhamento

O acompanhamento feito pelo professor doutor Carlos Hitoshi Morimoto teve um perfil liberal, ou seja, após uma discussão inicial sobre o projeto, o professor nos deixou livres para nos organizarmos. Essa abordagem permite, principalmente em trabalhos em grupo, o desenvolvimento da capacidade de planejamento pessoal e de atribuição de funções, em suma, da administração dos recursos humanos.

Mesmo com o acompanhamento liberal, o professor perguntou ocasionalmente sobre o andamento projeto e sobre as dificuldades, auxiliou no desenvolvimento do cronograma e marcou eventuais reuniões. Nessas reuniões, avaliamos o que já havia sido feito e o que restava fazer, e, quando necessário, discutimos e redefinimos etapas e cronogramas.

Mas esse modelo, como qualquer outro, possui seus defeitos. Como trabalhamos em dupla, discutimos a maior parte dos problemas entre nós mesmos, pecando por não consultar suficientemente o professor. Dessa forma, chegamos a despender tempo e energia para resolver problemas que já haviam sido resolvidos em outras ocasiões.

Levando-se em consideração os prós e os contras de tal tipo de acompanhamento, concluímos que essa abordagem é melhor do que auxiliar o estudante em cada detalhe, na medida que aumenta a flexibilidade e a independência do estudante, características muito importantes profissionalmente.

Referências bibliográficas
1
C. H. Morimoto, D. Koons, A. Amir e M. Flickner.
Frame-rate pupil detector and gaze tracker.
Em To be presented at: ICCV'99 - Framerate computer vision applications, Corfu, Greece, Setembro 1999
(URL : http://www.ime.usp.br/~hitoshi/framerate)
2
S. Zhai, C. H. Morimoto e S. Ihde.
Manual and gaze input cascaded (MAGIC) pointing.
Em Proc. of the ACM SIGCHI - Human Factors in Computing Systems Conference, páginas 246-253, Pittsburgh, PA, Maio 1999.

Valid HTML 4.01!Valid CSS Level 2!

Testado com Microsoft Internet Explorer 6.x (Windows) e Opera 6.x (Windows e Linux).