Programação concorrente

As várias tarefas a serem executadas pelo subsistema computacional foram im- plementadas de forma a serem executadas paralelamente em múltiplos fluxos de exe- cução, por meio de tarefas periódicas. Isto permite que se tenha uma consistência no período de atualização das diversas variáveis envolvidas e, mais ainda, se pondere o esforço concedido a cada tarefa.

Além disto, a programação concorrente torna possível a exploração dos recursos computacionais modernos, tais como processadores paralelos e com vários núcleos. Apesar deste não ser o caso para os recursos utilizados, a programação realizada está pronta para ser utilizada com vantagens em computadores IBM/PC que possuírem tais processadores.

Apesar do comportamento padrão do sistema operacional GNU/Linux utilizado para os testes não fornecer suporte a tempo real, é possível utilizar versões modificadas do núcleo, como por exemplo, as modificações de Ingo Molnár [2, 1], os núcleos Xeno- mai, RTAI ou RT-Linux, para que se possuam garantias de execução. Todavia, tanto a comunicação quanto à aquisição de imagens das câmeras são executadas sob o pro- tocolo USB que, em última análise, é não determinístico, de forma que continua sendo impossível garantir a execução a tempo.

Ainda assim, considerando que as tarefas essenciais serão exercidas pelo sub- sistema eletro-eletrônico e que este tem programação cuidadosa no que se refere às características de tempo real, é possível fazer um estudo aproximado dos tempos de resposta (atraso na execução das tarefas com relação ao período estipulado) médios e máximos, que também são comumente chamados de latência da tarefa. No que se re- fere às tarefas de visão utilizando as câmeras e comunicação, pode-se também contar o número de falhas para cada mil períodos, indicando falha de comunicação USB. No caso de falha, o ciclo da tarefa é ignorado (as variáveis relativas a ela não sofrem alteração) e só volta-se a realizar outra requisição no próximo ciclo.

A opção de suporte a tempo real de Ingo Molnár está no processo de inclusão na árvore de desenvolvimento do núcleo padrão do GNU/Linux, o que torna sua instalação e testes mais fáceis de serem realizados, quando em comparação aos outros núcleos. Devido a esta facilidade de uso, optou-se por realizar os testes em duas versões do núcleo, com e sem o suporte de tempo real de Ingo Molnár, embora não se pretendesse garantir o tempo real, é conhecido que os núcleos de tempo real oferecem menor latência mesmo em aplicações que desconsideram o tempo real, em parte devido ao escalonador de tarefas. Os resultados dos testes podem ser vistos na tabela 10.

Tabela 10: Desempenho das tarefas periódicas (teste executado durante 1 hora de ope- ração)

Núcleo convencional Núcleo Ingo Molnár

Latência média 5,2ms 4,9ms

Latência máxima 210ms 13,0ms

Como esperado, o uso do suporte tempo real diminui consideravelmente a latên- cia, sobretudo a latência máxima. Por outro lado, algumas tarefas, como a aquisição de imagem via USB, não poderiam ser interrompidas, pois neste uma parte da imagem (ou mesmo toda ela) pode ser perdida ou corrompida.

Assim, observa-se que, como o suporte a tempo real tende a interromper quais- quer operações para manter a latência esperada, ocorrem mais falhas de comunicação via USB, resultando em imagens corrompidas. Assim, deve-se analisar qual compor- tamento é mais desejado no sistema. Como se assumiu aceitável mesmo a latência máxima para o núcleo convencional, optou-se pela utilização deste para que os testes de sistemas de visão pudessem ocorrer de maneira mais confiável.

A tabela 11 ilustra os vários fluxos de execução, descrevendo o período de exe- cução desejado para cada e resumidamente a funcionalidade implementada.

Tabela 11: Fluxos de execução implementados

Fluxo Período CPU Descrição

Bot 50ms 1ms Base – Comunicação com o subsistema eletro-eletrônico, atu- aliza os valores lidos dos sensores e o modelo interno de posi- ção da plataforma, envia comandos para os motores e executa o controle de trajetória

Nav 500ms 15ms Navegação – atualiza o mapa, com base nas leituras acumula- das dos sensores, (re)calcula o caminho até o objetivo

Loc 500ms 10ms Localização – atualiza a posição atual da plataforma baseado em realimentação externa, de forma a melhorar a estimativa a partir do modelo interno

Cam 100/250ms 45/100ms Câmera – Realiza as operações do sistema de visão, incluindo medição de perfis de distância, localização de marcos conhe- cidos. Os valores de período de 100/250 ms são para visão monocular e estereoscópica, respectivamente

Main sob demanda N/A Fluxo principal – inicia os outros fluxos, espera comunicação de programas externos e retorna a resposta das requisições. Finaliza os outros fluxos de forma controlada no caso de requi- sição de desligamento

Os períodos utilizados são somente valores típicos, que inclusive são ajustados dinamicamente. Por exemplo, em uma operação de alinhamento com um alvo reconhe- cido pelo sistema de visão, o período do fluxo Cam pode ser reduzido. Da mesma forma,

ao alterar os parâmetros do sistema de visão estereoscópica é possível obter tempos de execução maiores ou menores, que são tomados como base para o ajuste de período, que assim é variável quando existe o chaveamento de modos.

A coluna “CPU"da Tabela 11 diz respeito ao poder de processamento necessário dentro do período de execução para executar completamente a tarefa (com o sistema computacional utilizado). Ao fazer a razão CPU/Período e somando todas as linhas, tem- se que a ocupação do processador é próxima de 60% do tempo, indicando que existe disponibilidade de processamento para alguma expansão desejada.

Devido ao número de fluxos de execução, um cuidado especial precisa ser to- mado no sentido de evitar o compartilhamento de dados e recursos e, quando neces- sário, realizar o devido controle do intertravamento dos fluxos e impedir que a interação entre os fluxos gerasse uma parada operacional.