Transcrição

1 OBTENDO LATÊNCIAS DE MICROSEGUNDOS PARA CONTROLAR ROBÔS USANDO LINUX E UM ÚNICO PROCESSADOR Rodrigo Rosenfeld Rosas, Hans Jorg Andreas Schneebeli Campus Universitário de Goiabeiras, Av. Fernando Ferrari, 514, CEP PPGEE/Universidade Federal do Espírito Santo Vitória, ES, Brasil s: [email protected], [email protected] Abstract In order to robots work properly, some existing time restrictions must be met while processing data from sensors and controlling drivers. One possible solution is to use a dedicated microcontroller for controlling the basic operations of the robot, like speed control, odometry and sensor data processing and another processor for controlling the rest of the system. Another approach is to use the same processor for doing both tasks, by using a realtime operating system (RTOS). We show how to use some Linux extensions (patches) for achieving that goal by turning it a RTOS, being able to meet hard realtime requirements with very low latency, allowing the use of a single CPU for controlling a full robotic system in both high and low level, like acquiring sensor data in high speed. Keywords Real-Time, Linux, Xenomai, RTAI, RTLinux, Robotics, Framework. Resumo Para que robôs executem tarefas corretamente, é necessário que sejam atendidas as restrições temporais que existem naturalmente ao processar os dados provenientes dos sensores e realizar o laço de controle dos atuadores. Uma alternativa é utilizar um processador específico para essas tarefas, como aquele existente em um micro-controlador e outro para tarefas de alto nível. Outra técnica é utilizar o mesmo processador para ambas as tarefas, utilizando um sistema operacional de tempo-real (RTOS). Este trabalho explora o uso de algumas extensões ao Linux com fim de torná-lo um RTOS, com latência muito baixa, capaz de realizar tarefas com restrições temporais críticas e apresenta as vantagens de sua utilização no campo da Robótica, permitindo que se utilize um único processador para gerar sinais de PWM e capturar sinais de transdutores, além de controlar todo o sistema. Palavras-chave Tempo-Real, Linux, Xenomai, RTAI, RTLinux, Robótica, Framework. 1 Introdução Há muitos anos vêm se desenvolvendo vários projetos para facilitar a programação de robôs. A maior parte desses projetos não permite a programação de tarefas com fortes restrições temporais. Pretendemos desenvolver um framework que torne possível tal programação, além de aproveitar as boas idéias já propostas em grandes projetos, como Player/Stage (Gerkey et al., 2003) e OROCOS (Bruyninckx, 2001), entre outros. Este trabalho concentra-se na aplicação em controle de robôs móveis, mas as idéias aqui apresentadas são úteis para as diversas áreas de Robótica. Robôs móveis possuem restrições temporais durante a captura e processamento dos sinais obtidos pelos sensores para gerar as saídas para os atuadores. Grande parte dos robôs comerciais dispõe de um processador específico para realizar tarefas básicas, como controle de velocidade e sistemas de odometria e um segundo processador para realizar tarefas mais complexas e muitas vezes sem restrições temporais severas. Esse esquema é bastante utilizado atualmente e está ilustrado na figura 1. Porém, em diversas outras situações, estas tarefas complexas também possuem restrições de tempo críticas e são então denominadas tarefas de tempo-real. Pretendemos mostrar que é possível utilizar um único processador para realizar ambas as tarefas como ilustra a figura 2, fazendo com que seja responsável por controlar o sinal PWM dos atuadores, obter os dados dos sensores com precisão e realizar o controle de todo o robô baseado nesses dados. Figura 1: Um computador se comunica com um microcontrolador para controlar o robô. Para que estas restrições de tempo sejam atendidas, é necessário utilizar um sistema operacional que proveja garantias de tempo de execução de cada rotina envolvida no processo. Tais sistemas são denominados sistemas operacionais de tempo real, ou abreviadamente RTOS Real- Time Operating System. Sistemas operacionais muito utilizados por pesquisadores de Robótica como Windows e Linux não provêem essas garantias de tempo. Vários outros sistemas menos conhecidos, contudo, permitem a programação de tarefas em tempo-real, como o QNX, VxWorks, AMX e diversos outros, mas são caros. Nesse trabalho, mostramos como adaptar o

2 Figura 2: Uma única unidade de processamento realiza todas as tarefas necessárias para controlar o robô. Linux para torná-lo uma opção que atinja os objetivos acima. Apresentamos, então, na seção 4, a plataforma utilizada para realizar a prova de conceito. Finalmente, na seção 6, mostramos os resultados obtidos com tal abordagem e explicamos na seção 7 os futuros caminhos deste trabalho para concluir o framework final. 2 Utilizando o Linux em Tempo Real Algumas soluções existem para tornar o Linux em um sistema operacional de tempo real. Uma alternativa é retirar todo o indeterminismo temporal existente no núcleo (kernel) do Linux e procurar diminuir as latências quando possível. Uma grande vantagem é poder usufruir de toda a estrutura já existente. Uma parte da API POSIX, contudo, não é determinística e não deveria ser usada em tarefas críticas, mas apenas em tarefas de baixa prioridade com restrições de tempo menos severas. Porém, a dificuldade de realizar tais mudanças, mantê-las ao longo do tempo e, principalmente, garantir o funcionamento correto de todo o núcleo torna tal abordagem impraticável. Outra solução, que vem sendo bastante utilizada, com êxito, por diferentes projetos, é a construção de um nanokernel de tempo real que execute o kernel do Linux como a tarefa de menor prioridade, como mostra a figura 3. Dessa forma, sempre que não houver qualquer tarefa de tempo real sendo executada, o Linux normal é executado. As mudanças no núcleo original do Linux são mínimas e muito mais fáceis de serem mantidas, além de permitir o desenvolvimento normal do núcleo original. O usuário utiliza uma API específica para criar e executar as tarefas de temporeal e pode comunicar-se com processos normais do Linux em um contexto não determinístico. A desvantagem é que é necessário adaptar quaisquer drivers cujo comportamento necessite ser realizado em um tempo determinado. Ou seja, não é possível utilizar os drivers que acompanham o kernel padrão do Linux em um contexto de tempo-real. Além disso, é necessário aprender uma nova API para programar as tarefas de Figura 3: O nanokernel realiza as funções mais básicas de gerenciamento de tarefas. tempo-real. Porém, há uma grande vantagem nessa abordagem. Em sistemas de tempo-real, geralmente, uma pequena parte das tarefas é crítica e precisa ser realizada em um tempo determinado. Muitas outras funções, como interface e certos tipos de comunicação não dependem de tal garantia. Dessa forma, é possível utilizar o Linux padrão para realizar tais funções, enquanto as tarefas críticas são executadas em um contexto determinístico. É possível trocar informações entre os dois domínios sem perder o determinismo das tarefas de tempo real. Dessa forma, é possível utilizar toda a infraestrutura existente no Linux para executar a interface do sistema e todos os outros processos não determinísticos sem qualquer adaptação. Grandes projetos que utilizam essa abordagem são: RTLinux (Yodaiken and Barabanov, 1996): Foi o primeiro a usar essa abordagem e inspirou os outros projetos. Possui uma versão gratuita e de código aberto, sob a licença GPL e outra com aprimoramentos que é comercializada pela FMSLabs, cujo proprietário obteve uma patente sobre a abordagem utilizada, nos EUA. RTAI (RTAI: Real-Time Application Interface, 1998; Mantegazza et al., 2000): Inspirado na abordagem utilizada pelo RTLinux, esse projeto vem sendo bem utilizado porque, além de ser totalmente livre, permite a programação de tarefas no espaço do usuário, como será explicado detalhadamente mais adiante. Xenomai (Gerum, 2004): Originado a partir de um projeto intermediário, o Fusion, que foi desenvolvido em conjunto com o RTAI utilizando uma abordagem um pouco diferente para se livrar da patente do autor do RTLinux, Victor Yodaiken. 3 Comparação Entre as Alternativas Todos esses projetos atendem os requisitos necessários para o presente trabalho, mas alguns são mais vantajosos. Uma vez que o RTLinux possui

3 recursos limitados na versão gratuita, não acompanhando a última versão do kernel e permitindo programação de tarefas apenas no espaço do kernel, tal sistema não será utilizado. O projeto Xenomai, por ser originário do RTAI, herdou todas as suas boas características. Apresentaremos, então essas características comuns e, em seguida, aquelas específicas do Xenomai. 3.1 Características do RTAI e Xenomai O projeto RTAI foi o primeiro dos três a suportar um modelo de programação que permita o desenvolvimento de aplicações de tempo-real críticas (hard realtime) no espaço de usuário. A versão gratuita do RTLinux, sequer suporta este modelo, como já foi mencionado. O Linux é dividido em dois espaços básicos de gerenciamento de memória, o espaço do kernel e o espaço do usuário. O primeiro é bem menor e é utilizado pelo sistema operacional em si e os módulos ou drivers que nele são inseridos. Nesse espaço, todo programa (na forma de módulo) possui acesso total ao hardware e uma latência menor pois acessa as funções providas pelo kernel como uma simples chamada de função, em vez de usar interrupções de software que possuem um overhead maior. Porém, é mais trabalhoso desenvolver um módulo do que uma aplicação, além do fato de um módulo ser específico para um determinado kernel, diferentemente de uma aplicação normal que executa no espaço do usuário. Um módulo do kernel não pode utilizar bibliotecas de qualquer tipo, inclusive a biblioteca padrão do C, a libc. Assim, a programação é bem mais limitada. Além disso, um erro no módulo causa instabilidade no sistema e torna o processo de desenvolvimento muito mais demorado. Para facilitar a programação de sistemas de tempo-real, RTAI provê um módulo, o LXRT, e uma API que permitam a programação de sistemas de tempo-real a partir do espaço do usuário, através de chamadas de sistema, que é um mecanismo similar a IOCTLs. RTAI mostrou que o aumento na latência, de apenas alguns microsegundos, ao utilizar essa abordagem é aceitável para vários projetos com restrições temporais críticas e justifica seu uso pela facilidade de programação obtida. Outros podem preferir utilizá-lo na fase de desenvolvimento para agilizá-la e depois converter o programa final em um módulo para reduzir a latência. Também é possível escolher quais os métodos IPC devem ser incluídos no sistema, entre outros fatores com a finalidade de reduzir o footprint final, eliminando-se os recursos não utilizados Xenomai Quando surgiu, com o nome de Fusion, além de procurar não se enquadrar na licença de Victor Yodaiken, Xenomai também tinha como objetivo reestruturar o RTAI para torná-lo mais flexível, criando uma API nativa mais coerente e aceitando diversas outras APIs, emulando RTOS tradicionais. Na época, Philippe Gerum lançou o projeto do nanokernel ADEOS, com uma abordagem diferente da que constava na patente. ADEOS provê uma abstração dos recursos do hardware e permite que núcleos de tempo-real sejam criados em cima dessa abstração, como ilustra a figura 4. Esta abstração mostrou-se uma vantagem, uma vez que é possível instalar mais de um sistema operacional de tempo-real com a mesma modificação do kernel. Isso de fato aconteceu, uma vez que o RTAI também passou a fazer uso desse projeto para obter acesso ao hardware. Processos Linux Linux Tarefas de tempo real Xenomai Xenomai ADEOS (micro kernel) Hardware Tarefas de tempo real RTAI RTAI... Outros Dominios Figura 4: O nanokernel ADEOS e seus domínios. Além de promover o reuso de software, é fácil alternar entre o RTAI e o Fusion ou Xenomai, apenas removendo alguns módulos e carregando outros sem a necessidade de reiniciar todo o sistema operacional. Além disso, cada sistema operacional executando sobre o nanokernel, que são considerados como domínios, podem ser executados concorrentemente, se forem projetados para tal. Assim, o Linux é considerado um domínio secundário e vários domínios podem ser registrados concorrentemente. Em nosso projeto, contudo, utilizaremos apenas um domínio de tempo-real como domínio primário e o Linux como domínio secundário. Com Xenomai, é possível utilizar skins, que emulam APIs de RTOS tradicionais, facilitando o processo de transição desses sistemas para um sistema baseado em Linux, o que mostra também a flexibilidade do sistema e uma base sólida e bem estruturada. Outra vantagem do projeto Xenomai é a existência de um skin, o RTDM (Real-Time Driver Model), para programação de drivers em um contexto de tempo real. Além de facilitar a programação desses drivers, o skin provê uma API comum para os utilizadores dos drivers, facilitando

4 o reuso de software. O projeto Xenomai define que as tarefas executando em contexto de tempo-real estão no domínio primário, enquanto que as tarefas agendadas pelo kernel do Linux pertencem ao domínio secundário. Quando uma tarefa do domínio primário depende de um recurso do domínio secundário, o agendador do sistema Xenomai transfere a tarefa automaticamente para o agendador do kernel do Linux e eleva a prioridade do Linux, que até então era a menor, para a prioridade da tarefa que depende do recurso do Linux. Tal comportamento é coerente com a proteção que o Xenomai provê contra problemas de inversão de prioridade. O projeto RTAI não faz essa mudança de domínios automaticamente. Em vez disso, existem funções próprias para esse fim na API: a rt make hard real time() e a rt make soft real time(). A abordagem do Xenomai é, não só mais fácil, como endereça o problema de um modo mais lógico. Por exemplo, se uma tarefa de prioridade 3 necessita de um recurso do Linux, é natural que o Linux passe a ter prioridade 3 durante esse intervalo. No caso do RTAI, uma tarefa de prioridade 1 estaria sendo executada com maior prioridade que o Linux, mesmo quando a tarefa 3 depende de um recurso do Linux para prosseguir. Em qualquer caso, uma vez que o Linux esteja em execução, o sistema deixa de ser determinístico a partir da prioridade do Linux para baixo, nesse momento. É interessante notar que, nesse caso, uma tarefa de prioridade 4 ou superior não seria afetada pelo indeterminismo. Figura 5: Foto do robô construído. unidade de processamento na placa a bordo do robô. Apenas os circuitos básicos para se fazer o acionamento das rodas, como pontes-h, reguladores de tensão e buffers para proteção da porta paralela, além dos componentes necessários para obter os dados dos encoderes, como mostra a figura Sumário e Escolha do Sistema Operacional A tabela 1 sumariza as características dos três projetos investigados. Como mostra a tabela, o projeto Xenomai se destacou por possuir as mesmas propriedades positivas dos outros dois, além de algumas vantagens exclusivas e por isso o adotamos em nosso trabalho. 4 A Plataforma de Teste Para testar o sistema escolhido em Robótica, construimos um robô bem simples (ver figura 5), sem processamento a bordo, cujo único sensor é um encoder ótico em cada roda. O robô possui dois motores, um para cada roda, e é montado na configuração de par diferencial, com uma roda livre. Todo o acionamento, sinais de controle e processamento é realizado externamente ao robô, através de um cabo flat de 15 fios. Uma fonte externa alimenta uma placa bem simples a bordo do robô, a qual comunica-se com um PC através da porta paralela. É importante frisar que não há qualquer micro-controlador ou Figura 6: Representação da montagem do circuito Os sensores óticos são formados por pares emissor-receptor de infra-vermelho, como os utilizados para controle-remoto e possuem um custo muito baixo. Há dois pares por roda, de modo a se obter um sinal em quadratura, permitindo ao sistema de controle identificar o sentido de rotação de cada roda. Em cada roda, estão dispostos um disco fixo na roda e uma máscara fixa no robô, como mostra a figura 7 e o sinal é capturado através da reflexão de luz infravermelho emitida. As janelas da máscara estão defasadas uma da outra de modo que os sinais elétricos dos pares de sensores de uma mesma roda estejam defasados de 90 entre si.

5 Característica RTLinux RTAI Xenomai Hard realtime x x x Suporta mecanismos IPC x x x Possui baixa latência (us) x x x Existem ferramentas de depuração x x x Suporte a múltiplos processadores x x x Alocação dinâmica em tempo-real x x Tempo-real no espaço do usuário x x Suporta últimas versões do kernel x x Suporte a skins x Transição automática para o Linux x Facilita desenvolvimento de drivers x API POSIX RTAI Nativa, POSIX,... Arquiteturas suportadas x86,arm,sh x86,ppc,arm,mips +Blackfin,-MIPS* * Em relação ao RTAI Tabela 1: Comparação entre RTOS baseados em Linux (a) Disco. (b) Máscara. As duas janelas estão defasadas de 90 entre si. Figura 7: Disco e máscara utilizados no encoder Pretende-se até o final do projeto, mostrar que é possível controlar o robô com uma câmera de vídeo, utilizando um sistema operacional de temporeal e garantir seu funcionamento independente da carga de processamento utilizada pelo Linux, sem a necessidade de se utilizar um processador independente. Contudo o driver da placa de captura de imagem ainda está em desenvolvimento e só serão mostrados neste artigo os resultados já obtidos utilizando-se somente os dados dos sensores dos encoderes. 5 O Sistema de Controle Com o robô pronto, compilamos o kernel do Linux com o patch do ADEOS e os módulos do Xenomai e colocamos o sistema para funcionar. Foi muito mais simples que imaginávamos e tudo correu perfeitamente bem. Finalmente, começamos a programação das tarefas de controle. Criamos uma tarefa para capturar as variações dos sinais dos sensores através de polling e, dessa forma, estimar a velocidade. Inicialmente, fizemos testes utilizando a interrupção da portaparalela com resultados muito satisfatórios. Utilizamos um Pentium IV 1,7 GHz e pudemos contar as transições corretamente até pelo menos 200 khz, ajustando a freqüência em um gerador de sinais. A partir daí o computador não respondia mais, devido ao uso excessivo do processador. Ao reduzir a freqüência do gerador de sinais o sistema voltou a responder, o que mostra que as tarefas de tempo-real de fato possuem prioridade maior que o Linux e que o último só é executado quando nenhuma tarefa de tempo-real está utilizando o processador. Porém, apenas um pino da porta paralela gera interrupções e como precisávamos de quatro sinais, um para cada encoder, foi necessário utilizar a técnica de polling, a qual também mostrou-se satisfatória. Na velocidade máxima do motor o sensor contava 50 transições por segundo, o que resulta em uma transição a cada 20 ms. Utilizouse um período de polling de um centésimo desse tempo, ou seja, 200 us, com o qual se obtém uma precisão de cerca de 1 % na medida da velocidade para a velocidade máxima, que é o pior caso. Porém, em situações extremas, a latência máxima pode chegar a 20us, o que reduziria a precisão, mas a diferença é imperceptível: de 0,99 % para 1,09 %. Em situações normais, a imprecisão é muito menor. Problemas freqüentes de deslizamento das rodas durante as curvas causam imprecisões muito maiores no sistema de odometria. Poder-se ia aumentar o tempo de polling, mas a intenção aqui é mostrar que é possível utilizar um período de 200us para realizar a odometria sem atingir qualquer deadline. O projeto Xenomai disponibiliza, opcionalmente, alguns descritores de arquivo no sistema de arquivos proc, o que permite saber a quantidade de deadlines atingidos, entre outras estatísticas. A velocidade angular é estimada dividindose o ângulo de cada setor pelo tempo entre duas transições do sinal do encoder. Como sabemos o diâmetro da roda, estimamos a velocidade linear com base na angular. Outra abordagem é possível: contar o número de transições em um intervalo de

6 tempo. Contudo, como são poucas transições por unidade de tempo (50 Hz na velocidade máxima), tal método apresentaria, entre outros problemas, imprecisões elevadas, principalmente em velocidades baixas. Este tópico não será aqui discutido por não ser relevante ao tema principal desse trabalho. Além da tarefa de estimação das velocidades de cada roda, há ainda uma tarefa para estimar as velocidades angulares e lineares instantâneas, além da posição e orientação do robô a partir da referência inicial. Criamos outra tarefa, com período de 100ms, para controlar as velocidades de cada roda com o propósito de atingir uma posição final, utilizando um controlador integrador normal. Outra tarefa foi criada para gerar o sinal de PWM para as pontes-h que controlam a velocidade dos motores com período do PWM de 20 ms e resolução de 1%. Por fim, uma última tarefa, de menor prioridade, sem restrições severas de tempo, exibia as informações de velocidade, posição e orientação do robô a cada segundo. 6 Resultados e Conclusões Obtivemos com esse sistema um resultado parcial bastante satisfatório. Foi possível controlar o robô até a posição final com erro médio inferior a 5 cm para uma distância de 3 metros, defasados de 45 da orientação inicial do robô, e erro máximo inferior a 10 cm, inclusive sob condições de cargas elevadas de processamento utilizado pelo Linux. Nenhum deadline foi alcançado em todos os experimentos. É possível utilizar técnicas de controle melhores e ajuste dos períodos de cada tarefa de modo a se obter um resultado ainda melhor, mas esse não é o objetivo do presente trabalho. Finalmente, mostramos a viabilidade do uso do Linux, juntamente com uma modificação para torná-lo determinístico, em sistemas que tenham restrições de tempo severas, com baixa latência e facilidade de uso. Mostramos também que é possível, com um sistema operacional de tempo-real, utilizar um único processador para realizar todas as tarefas necessárias para o robô, sem precisar de outra unidade de processamento para realizar o controle de velocidade e processamento dos sinais dos encoderes. Embora, nos experimentos citados o computador estivesse externo ao robô, a abordagem seria muito parecida para uma plataforma em que uma única placa de computador SBC (Single Board Computer) controlasse o robô, como mostrado na figura 8. 7 Futuros Trabalhos A próxima etapa é desenvolver a API do framework final para programação de robôs móveis SBC Figura 8: É possível implementar um robô com bateria, placa mãe e processamento a bordo utilizando-se o framework desenvolvido. para realizar tarefas com restrições de tempo, além de implementar parte dela. Um driver determinístico para a placa de captura de imagens já está quase pronto e pretendemos realizar o mesmo controle de posição baseado em imagem e comparar os resultados obtidos com o sistema odométrico. Agradecimentos Agradecemos a CAPES pelo apoio financeiro, que viabilizou o desenvolvimento deste trabalho. Agradecemos também aos diversos integrantes da lista de desenvolvimento do projeto Xenomai, que nos auxiliaram bastante a entender o funcionamento do sistema. Em especial a Jan Kiszka e Philippe Gerum. Referências Bruyninckx, H. (2001). Open robot control software: the OROCOS project., ICRA, IEEE, Seoul, Korea, pp Gerkey, B. P., Vaughan, R. T. and Howard, A. (2003). The Player/Stage project: Tools for multi-robot and distributed sensor systems, Proceedings of the International Conference on Advanced Robotics, Coimbra, Portugal, pp URL: gerkey/- research/final papers/icar03-player.pdf Gerum, P. (2004). Xenomai - Implementing a RTOS emulation framework on GNU/Linux, Technical report. URL: Mantegazza, P., Dozio, E. L. and Papacharalambous, S. (2000). RTAI: Real Time Application Interface, Linux Journal 2000(72es): 10. URL: article/3838 RTAI: Real-Time Application Interface (1998). URL: Yodaiken, V. and Barabanov, M. (1996). A Real- Time Linux. URL: