Real-time Operating System Timing Jitter and its impact on Motor Control

1. Real-time Operating System Timing Jitter and its impact on Motor Control Sistemas de Tempo Real 2006 João Ribeiro nº25673 Pedro Amaral nº25450

2. Motivação! • Os processadores de “uso geral” estão cada vez mais evoluídos em termos de performance; • Compatíveis com plataformas PC, com todas as vantagens que isso acarreta (dispositivos I/O a baixo custo, mais software disponível, etc.); • Assim, é de todo o interesse estudar a sua utilização em aplicações de tempo real, correndo claro, Sistemas Operativos de Tempo Real (SOTR).

3. Problemas conhecidos! • Este tipo de processadores, possuem mecanismos de optimização que introduzem incerteza temporal (não determinismo). • Estamos a falar de caches, pipelines, previsão de saltos, etc. (Lembram-se de AC2?) • Estes mecanismos melhoram a performance em termos médios, mas em certas situações introduzem grandes atrasos.

4. O que vamos abordar concretamente! • A utilização de processadores de “uso geral” no controlo de motores, usando um SOTR. • Medir o impacto do jitter do controlador (SOTR) no desempenho dos motores. • Finalmente, concluir se o uso de processadores de “uso geral” e um SOTR é ou não uma boa opção parra controlar motores.

5. Um pouco sobre motores! • Stepper motors: • Movem-se em passos discretos (steps); • Recebem de x em x tempo a próxima posição (next step); • Não fornecem feedback ao controlador. • Servo motors: • Existe um estado desejado (velocidade, posição, etc.); • Fornecem feedback ao controlador, que vai ajustando o estado do motor.

6. Plataforma de teste/controlador. • Pentium II 450 MHz. • 512 KByte cache. • SOTRs Real time Linux (RTL) and Real Time Application Interface (RTAI) – extensões ao SO Linux, que corre como um idle process quando nenhuma tarefa de tempo real está em execução. • Com estes SOTRs, devido à existência de tarefas non real time, é provável que surjam atrasos decorrentes de dirty cache, o que os torna bons para testes.

7. Afinal o que é o jitter? Diferença entre o instante ideal de ocorrência de um evento e o instante em que este evento realmente ocorre. Por exemplo, no caso do controlo de um robot do filme “Alien VS Predator”, cujo controlador, desenvolvido pela empresa Concept Overdrive é baseado em RTL : “The status of the motors must be updated 60 times per second, with each interval exactly timed. If one interval is slightly longer than the next - a problem called "jitter“ - the motors and actuators inappropriately slow down, then speed up by small amounts. Jitter, combined with the weight and inertia from robotic mechanics, causes visual vibration and shaking." Concept Overdrive Founder: Steve Rosenbluth

8. Como medir o jitter? • Usando uma tarefa de tempo real que lê o Pentium Time Stamp Counter (TSC) - contador que incrementa a cada ciclo de relógio – de 500 em 500 microsegundos e guardar o seu valor na memória. • Através do método dos mínimos desvios quadráticos (lembram-se de Elementos de Física e Mecânica?), calcular o desvio padrão dos valores ideais.

9. Resultados em RTL (normal processor loading) Eixo dos x em amostras; Eixo dos y em jitter (microsegundos);

10. Interpretação • Inicialmente, existem desvios maiores pois existe código que ainda não está em cache. • As barras agrupam padrões de valores de jitter, indicando que existem padrões também na execução de código que influenciam os valores de jitter (combinações de padrões de acesso à cache e previsões de salto). • Para análise de determinado padrão, teríamos de analisar detalhadamente todo o percurso entre a interrupção, mudança de contexto, scheduler, mudança de contexto e a tarefa propriamente dita. • O jitter de pior caso é de 3.5 microsegundos.

11. Resultados em RTL e RTAI com variação de loading do processador. • RTL • RTAI • RTL and RTAI Eixo dos x em microsegundos Eixo dos y em nº de amostras

12. Interpretação • O jitter aumenta com o aumento da carga do processador. • Os resultados de ambos os SOTR são comparáveis mas com padrões distintos, o que indica dependência do jitter do algoritmo de scheduling.

13. Como compensar o jitter? • Agendar a tarefa mais cedo, pelo menos o tempo do worst case jitter. • Desactivar interrupções. • Entrar em polling loop de leitura ao TSC até que chegue a altura certa para execução da tarefa (neste caso ler o valor do TSC e guardá-lo em memória).

14. Como compensar o jitter? T= Período ideal da tarefa (500 microsegundos). A = Período que iremos dar à tarefa tentando compensar o jitter. S = Período de serviço à tarefa para decisão de sleep ou polling. Área cinzenta = Tempo em que a tarefa fica em polling ao TSC.

15. Afinal qual é o objectivo? • Descobrir o valor de A que minimize a carga do processador. • Se A for muito pequeno, o mais certo é que esta acorde, verifique que o instante certo de leitura está para além do seu período, e volte a adormecer (tudo isto com um custo de tempo S). • Se A for demasiado grande, o mais certo é que a tarefa fique em polling durante um tempo demasiado grande.

16. Como podemos encontrar o valor de A ideal? • Sabendo que a carga do processador é dada por: • Sabendo o tempo de serviço S, podemos descobrir o valor de A que minimiza a carga.

17. E como medimos o valor de S? • Programamos a tarefa para enviar um output quando termina. • Com um osciloscópio, medimos o instante do sinal de interrupção do timer do processador. • Calculamos a diferença entre os dois valores anteriores.

18. Resultados: T=500ms e S=5ms Eixo dos x em valores de A (microsegundos); Eixo dos y em carga do processador.

19. Resultado sem e com, compensação de jitter. • Jitter de pior caso sem compensação é de 3.5 microsegundos. • Jitter de pior caso com compensação é de 0.098 microsegundos. • Obtemos assim, uma redução do jitter de cerca de 40 vezes. • O custo é de um aumento de carga do processador em cerca de 20%.

20. Então e os motores? • Consideramos stepper motors e a perda de torque devido ao jitter. • Torque é a força rotacional. • = Deslocação adicional do motor devido ao jitter. • = Torque consumido. K=small-angle spring constant h = holding torque S = step angle of motor

21. Resultados. Resultados da perda de Torque para valores de jitter não compensado e compensado: 3.5 e microsegundos e 0.098 microsegundos.

22. Conclusão. • O jitter pode ser compensado sacrificando cerca de 20% de tempo de processamento, o que permite segundo os resultados obtidos uma redução do jitter de 40 vezes. • Para jitter não compensado temos um consumo de torque inferior a 10% e para jitter compensado inferior a 1%. • Conclui-se que os processadores de uso geral podem ser usados satisfatoriamente no controlo de stepper motors.

23. Referências: • Fonte principal (fonte de todos os gráficos apresentados): http://www.isd.mel.nist.gov/projects/rtlinux/motor-jitter.pdf • SOTR: http://news.zdnet.com/2100-9593_22-6117479.html http://zone.ni.com/devzone/cda/tut/p/id/3938#7 http://www.planetanalog.com/features/OEG20010827S0037 http://www.mrtc.mdh.se/publications/0576.pdf • Motores: http://zone.ni.com/devzone/cda/tut/p/id/3656#0 http://www.romanblack.com/stepper.htm http://en.wikipedia.org/wiki/Torque