Leitura dos Sensores
Foram realizados diversos experimentos para verificar a taxa máxima de leitura do estado dos sensores via canal de áudio no telefone celular com processador ARM. Com o objetivo de medir os piores tempos de execução, optou-se pela medida de desempenho de reconhecimento de dígitos DTMF por segundo, já que o reconhecimento de tons únicos é mais eficiente.
A figura 5.6 ilustra um sistema usado especificamente para testar a leitura de sensores. Um microcontrolador foi programado para gerar tons DTMF ou tons únicos de áudio em diferentes intervalos de tempo. Sua saida foi conectada aos dispositivos em teste, e os tons gerados com diferentes intervalos. Os testes foram realizados várias vezes até que se observou perdas de dados.
Pelos testes feitos, no pior caso, o tempo de computação da FFT levou 17ms, resul- tando em um limite teórico máximo de 58.8 FFTs por segundo. A Figura 5.7 mostra os resultados experimentais do sistema rodando em três dispositivos diferentes, que são: um telefone celular HTC G1 com processador ARM de 528MHz, um tablet com processador ARM de 1GHz e um netbook com processador x86 de 1GHz. Todos os testes foram executados na plataforma Android.
A Figura 5.7 mostra que mesmo o dispositivo com menor poder computacional pode manter uma taxa de reconhecimento de 40 dígitos DTMF por segundo sem perder nenhum dígito transmitido. Existem várias causas para a perda de pacotes apresentada no gráfico que se inicia em 40Hz. Uma das causas são as diferentes características do hardware de captura de áudio de cada dispositivo. Outra causa é relacionada com o escalonador de tarefas do sistema operacional Android (consequentemente do Linux), que pode não apresentar um bom determinismo quando a carga de processamento da CPU é elevada.
5.2. ASPECTOS TÉCNICOS 79 Lego Mindstorms NXT. Quando conectado a um computador ou smartphone via blueto- oth, a taxa máxima de leitura de sensores é de 20Hz, porém se vários sensores são lidos, esta taxa é dividida pelo número de sensores. Por exemplo, um software que faz a lei- tura de dois encoders e de dois sensores de toque obtém uma taxa de leitura aproximada de 5Hz por sensor. Já quando o brick do NXT está conectado a um computador usando cabo USB, a taxa máxima de leitura de sensores sobe para 166Hz. Dessa forma, se forem usados dois encoders e dois sensores de toque, então a taxa de leitura de cada sensor será de 41.5Hz, uma performance comparável ao do sistema proposto neste trabalho, que é de 40Hz para cada sensor.
0 20 40 60 80 100 0 10 20 30 40 50 60 70 80 Perda de digitos (%)
Frequência de leitura dos sensores (Hz) Telefone
Tablet Netbook
Figura 5.7: Desempenho do sistema de reconhecimento de dígitos DTMF em diversos dispositivos.
Como demonstrado, nos sistemas baseados em Android, é possível ler o estado de sensores a 40Hz, e assim fechar malhas de controle. Assim, um dos exemplos implemen- tados permite ao N-Bot receber um comando de movimentação e realizar determinado deslocamento enquanto monitora seus sensores para desativar os motores quando a posi- ção solicitada é atingida.
Para o ambiente de programação sem o uso do celular, onde as FFT são calculadas diretamente no navegador web do usuário, a performance obtida em um PC com sis- tema operacional Linux e processador de 1.6GHz, foi de cerca de 5ms, que oferece um desempenho bastante superior àquela obtida no sistema que é executado nos dispositi- vos móveis com Android, contudo não foi possível obter taxas de leitura de sensores superiores a 4.9Hz. Para identificar o motivo desta baixa performance, várias partes do sistema foram testadas de forma isolada e notou-se que existe uma limitação na interface de chamadas de função entre elementos JavaScript de um navegador web e elementos em
80 CAPÍTULO 5. RESULTADOS
Flash/ActionScript. Enquanto o programa em JavaScript por si só pode executar até 40 mil instruções por segundo, o programa em Flash pode executar as FFTs de leitura de sensores em 5ms. Mesmo assim, pela limitação na interface entre estes dois elementos, a performance caiu para 4.9Hz. Esta limitação pode ser melhorada em trabalhos futuros atráves de implementações do sistema com novas tecnologias.
Temporização e Geração dos Tons DTMF
Para ajustar a velocidade de movimento dos motores é interessante que o sistema possa gerar um sinal de controle com uma determinada frequência. Isso pode ser feito utilizando laços que alternam entre a geração de tons DTMF e a espera por um intervalo de tempo. A função de espera (delay) está disponível e pode ser usada facilmente nos programas para dispositivos baseados em Android. Contudo, no ambiente web que dispensa o uso do telefone, foi necessário adotar uma abordagem diferenciada.
No ADWN, o programa de controle do robô é executado em JavaScript. Entretanto, essa linguagem possui uma filosofia de programação baseada no uso de eventos assín- cronos, e não possui funções de espera. Ao tentar implementar uma função desse tipo, observamos que uma espera ocupada deixa todo o navegador bloqueado e sem resposta até que a espera ocupada acabe, resultando em uma solução indesejável pela sua natureza bloqueante.
A melhor solução encontrada foi adaptar e integrar um framework para execução de threads em JavaScript [Maki 2007, Maki & Iwasaki 2007] ao nosso sistema, resultando em um ambiente com possibilidades de programação paralela virtual onde blocos de có- digo são executados de forma paralela, mas sem o conhecimento do escalonador de tarefas do sistema operacional nem o mapeamento para diversos processadores. Esse framework divide um código a ser executado em várias partes, e agenda a execução de cada uma dessas partes usando a função setTimeout da linguagem JavaScript. Também adiciona- mos uma função que interrompe a execução durante um intervalo de tempo solicitado. Para tanto, essa função também usa a chamada setTimeout para agendar a continuidade da execução do programa.
Com essa solução, diversos trechos de código podem ser implementados tanto de forma textual quanto em blocos, e esses serão executados em paralelo de acordo o sis- tema de agendamento. Para validar o funcionamento do sistema, alguns testes foram feitos em um computador com processador dual core AMD E-450 nos sistemas Linux e Windows. O ambiente foi testado nos navegadores Mozilla Firefox 16.0.1 e Google Chrome 22.0.1229.94.
A Figura 5.8 mostra um esquema do ambiente usado para realizar os testes no sistema. Um computador foi preparado para gerar sequências de dígitos DTMF com vários inter- valos de tempo. Este sinal é conectado, via cabo de áudio, ao decodificador de DTMF em teste, e a saída deste decodificador é conectada a um analisador lógico que também é conectado ao computador. Dessa forma, o computador pode gerar sequências de dígi- tos DTMF em diferentes intervalos e monitorar quanto tempo leva para cada dígito ser decodificado, bem como a taxa máxima de decoficiação obtida pelo conversor em testes.
Como mencionado, pretende-se gerar uma onda de forma quadrada que possibilite controlar a velocidade dos motores. Para tanto, é desejável que o sistema possua compor-
5.2. ASPECTOS TÉCNICOS 81
Figura 5.8: Ambiente de testes para análise desempenho da temporização para geração de tons DTMF.
tamento de tempo real, exibindo determinismo ao gerar o sinal. Para realizar os testes, um programa em blocos foi feito com o objetivo de gerar um sinal de áudio através de tons DTMF. Foram testadas diversas frequências, e foi observado que os dois navegadores, nos mesmos sistemas operacionais podem gerar sinais DTMF que alternam em até cerca de 6Hz.
A Figura 5.9 mostra os resultados dos testes em diversas situações. Assim, o programa em blocos foi ajustado para gerar frequências de 1, 2, 3, 4, 5 e 6Hz, e o osciloscópio analisou se o sinal gerado estava na frequência esperada. Tanto o Firefox quanto o Chrome foram analisados em uma situação normal, e com o sistema operacional configurado para dar alta prioridade (AP) a essas tarefas, o que, teoricamente, facilitaria o cumprimento de rotinas de temporização com maior precisão.
Também foram feitos outros experimentos, fora do ambiente web ADWN, e observou- se que todos os dispositivos testados podem gerar sinais de áudio de até 11KHz com grande estabilidade e precisão. O que reduz consideravelmente a frequência final nos pulsos obtidos na saída do circuito de controle de motores são a especificação de sinais do tipo DTMF e o conversor de DTMF MT8870. Como o DTMF foi projetado para oferecer robustez em linhas de transmissão ruidosas, sua especificação determina que um dígito DTMF válido deve ser composto do sinal DTMF de duração mínima de 45ms seguido por um silêncio inter-dígito de 40ms, totalizando 85ms [Durda 1995].
Mais uma vez notou-se que para o ADWN, a limitação na temporização para gerar tons DTMF está relacionada com a interface entre JavaScript e ActionScript, já que, assim como na FFT, a geração e captura de áudio é feita pelo módulo em ActionScript que se comunica com o módulo em JavaScript, onde existe um limite de velocidade entre estes dois subsistemas do ADWN.
Com 85ms por dígito, a máxima frequência que pode ser gerada é de 11.76Hz. Assim, o limite na implementação e experimentos exibidos na Figura 5.9 também é devido ao tempo de propagação do sinal no decodificador de DTMF. Entretanto, observamos que é possível utilizar tons DTMF com temporizações abaixo do padrão e obter sinais de até 50Hz na saída do decodificador de DTMF. Esse resultado foi obtido usando a ferramenta
82 CAPÍTULO 5. RESULTADOS
dtmfdial[Nahshon 1998], configurada para gerar uma sequência DTMF com tempo de 10ms por dígito e de 10ms no intervalo inter-dígito. Para que o MT8870 suporte esses tempos, é necessário mudar seu circuito, substituindo o resistor de ajuste de 300KΩ por um de 1KΩ.
A Figura 5.9 mostra que em todas situações analisadas, o desvio padrão da frequência gerada não foi maior que 1Hz. No geral, o pior caso observado teve um desvio de 7% entre a saída real e a frequência configurada no software.
0 0.2 0.4 0.6 0.8 1 1 2 3 4 5 6 Desvio Padrão (Hz) Windows 7 − Frequência (Hz) Firefox Firefox (AP) Chrome Chrome (AP) 0 0.2 0.4 0.6 0.8 1 1 2 3 4 5 6 Desvio padrão (Hz) Linux − Frequência (Hz) Firefox Firefox (AP) Chrome Chrome (AP)
Figura 5.9: Desempenho dos navegadores Mozilla Firefox e Google Chrome para alternar a geração de tons DTMF tanto no Windows quanto no Linux (AP = Alta Prioridade).
Durante os testes, foram observados alguns fatos interessantes: primeiro, ao abrir novas abas no navegador, o sinal gerado torna-se irregular e sua frequência vai diminuindo até atingir 0Hz enquanto o usuário visualiza outra aba. Ao voltar para a aba do N-Bot, a frequência especificada volta ao normal. Esse comportamento foi observado tanto no Linux quanto no Windows em ambos os navegadores. Constatamos assim que enquanto se visualiza outras abas (páginas), scripts JavaScript em execução em qualquer outra aba são negligenciados pelo navegador.
Nota-se que o navegador continua executando o JavaScript de outras abas, mas sem determinismo ou previsibilidade. Assim, se durante a geração de um sinal de 7Hz, o usuá- rio seleciona outra aba do navegador, imediatamente a frequência é reduzida, de forma indeterminada, para um valor entre 0Hz e 1Hz. Esse comportamento é aceitável no Fire- fox, onde todas as páginas, programas e scripts rodam no contexto de um único processo do sistema operacional. Já o Google Chrome mapeia cada aba aberta para um processo do sistema operacional, por isso, se esperava maior determinismo e confiabilidade usando o Chrome. Em todos os casos, contudo, uma nova janela do navegador não interfere na geração de frequência e performance do ambiente do N-Bot, permitindo que se navegue na Internet enquanto o N-Bot é controlado pelo mesmo navegador em uma janela dedi- cada. Finalmente, vale lembrar que esse comportamento repetiu-se em testes feitos com diferentes prioridades do sistema operacional, até a mais alta do sistema (AP).
Notamos que os resultados apresentados não comprometem o funcionamento do sis- tema, e melhorias podem ser obtidas com modificações de software, eletrônicas ou mecâ- nicas.
5.2. ASPECTOS TÉCNICOS 83 Com relação ao sistema baseado em microcontrolador e descrito na Seção 4.2, alguns testes também foram realizados usando um microcontrolador AtMega328, e foi obtida uma taxa de envio de comandos de 10Hz, porém não foi feita nenhuma otimização na im- plementação. Acreditamos que essa taxa seja adequada, já que os comandos só precisam ser enviados para mudar estados de atuadores, como por exemplo: iniciar o movimento de um motor, mudar sua velocidade, ou parar. Além disso, o sistema tem a vantagem de conectar o microcontrolador ao dispositivo de controle com baixo custo e simplicidade, via áudio, dispensando etapas de configuração e pareamento, como no caso de conexões bluetooth, por exemplo.
Análise de Desempenho de Processadores ARM
Como um dos focos desse trabalho é o uso de dispositivos móveis que possuem pro- cessadores ARM para controle de robôs, optou-se pela execução de um estudo sistemático sobre o desempenho de processadores ARM em tarefas relacionadas ao Anwide e ao N- Bot, que são: a execução de um servidor web, e cálculos de ponto flutuante, já que a FFT requer um extenso número de multiplicações em ponto flutuante. Este trabalho, também é uma de nossas contribuições à comunidade e foi publicado em veículo relevante [Aroca & Gonçalves 2012].
Um mito entre os desenvolvedores é que processadores de sistemas embarcados po- dem não ter desempenho aceitável para execução de um servidor web ou para execução de tarefas com demanda de alto poder de processamento. Outro aspecto importante em robótica é a economia de energia, já que os robôs são alimentados por bateria. O estudo realizado inclui a comparação de desempenho absoluta e da eficiência energética entre processadores ARM e processadores x86, que equipam os PCs tradicionais. Essas duas plataformas são bastante comuns em computadores de controle de robôs.
Um ambiente de testes foi preparado para realizar os testes de performance dos pro- cessadores ARM. Este ambiente pode ser visto na Figura 5.10, e consiste no uso de uma placa com processador ARM conectada um computador que gera dados de teste e coleta dados de performance e uso de energia, além de um multímetro digital com saída serial RS-232 conectada diretamente ao PC, que coleta todos dados a cada um segundo. A Fi- gura 5.11 mostra uma foto da placa PandaBoard, com um processador ARM Cortex-A9 durante os testes. Cada dado apresentado nos gráficos de desempenho à seguir consistem em uma média de 30 valores coletados durante os testes. Além disso, os testes de servidor web foram realizados utilizando a ferramenta Apache Benchmark (ab).
A Figura 5.12 mostra a análise de desempenho da execução do servidor web Apa- che, um dos mais tradicionais, nas plataformas analisadas. Nota-se claramente que os processadores ARM oferecem uma vantagem em relação ao número de requisições aten- didas pelo gasto de energia. Além disso, o desempenho absoluto é totalmente aceitável no contexto do Anwide, que requer apenas alguns acessos HTTP por segundo.
A Figura 5.13 mostra o resultado da análise de performance para execução de cálculos em ponto flutuante, que foi feita utilizando a ferramenta linpack. Embora os proces- sadores x86 ofereçam desempenho absoluto maior, nota-se que os processadores ARM também podem realizar alguns milhões de operações de ponto flutuante por segundo, um valor aceitável para a execução das FFTs necessárias no sistema Anwide.
84 CAPÍTULO 5. RESULTADOS
Figura 5.10: Esquema de teste dos proessadores ARM.