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
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).
2
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.
3
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.
4
Um pouco sobre motores!
Stepper motors:
Servo motors:
• Movem-se em passos
discretos (steps);
• Existe um estado
desejado (velocidade,
posição, etc.);
• Recebem de x em x
tempo a próxima posição
(next step);
• Não fornecem feedback
ao controlador.
• Fornecem feedback ao
controlador, que vai
ajustando o estado do
motor.
5
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.
6
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
7
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.
8
Resultados em RTL (normal processor loading)
Eixo dos x em amostras;
Eixo dos y em jitter (microsegundos);
9
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.
10
Resultados em RTL e RTAI com variação de
loading do processador.
a)
b)
c)
RTL
RTAI
RTL and RTAI
Eixo dos x em microsegundos
Eixo dos y em nº de amostras
11
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.
12
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).
13
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.
14
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.
15
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.
16
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.
17
Resultados: T=500ms e S=5ms
Eixo dos x em valores de A (microsegundos);
Eixo dos y em carga do processador.
18
Resultado sem e com, compensação de jitter.

Jitter de pior caso sem

Jitter de pior caso com

Obtemos assim, uma redução
do jitter de cerca de 40 vezes.

compensação é de 3.5
microsegundos.
compensação é de 0.098
microsegundos.
O custo é de um aumento de
carga do processador em cerca
de 20%.
19
Então e os motores?

Consideramos stepper motors e a perda de torque devido ao

Torque é a força rotacional.

jitter.
= Deslocação adicional do motor devido ao jitter.
K=small-angle spring constant
h = holding torque
S = step angle of motor

= Torque consumido.
20
Resultados.
Resultados da perda de Torque para valores de jitter não
compensado e compensado: 3.5 e microsegundos e 0.098
microsegundos.
21
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.
22
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
23