Caca

Projecto de 5º ano para a LEET – Ano lectivo 2003/2004

Relatório

Construção de Plataformas para Experiências de Mecatrónica

Márcio Neves , Marco Leonor
Email: a17331@alunos.det.ua.pt, a20610@alunos.det.ua.pt

Departamento de Electrónica e Telecomunicações
Universidade de Aveiro
3800 Aveiro, Portugal

Orientadores: Colaborador:
Ernesto Martins Luís Almeida
Pedro Fonseca

Índice

SUMÁRIO:........................................................................................................................................................................ 4
I. INTRODUÇÃO:............................................................................................................................................................ 5
II. ARQUITECTURA GERAL DO SISTEMA: ............................................................................................................ 7
III. A CALHA:.................................................................................................................................................................. 9
III-1. INTRODUÇÃO:........................................................................................................................................................... 9
III-2. MODELIZAÇÃO:........................................................................................................................................................ 9
III-3. ARQUITECTURA DA CALHA: .................................................................................................................................. 10
III-4. IMPLEMENTAÇÃO: ................................................................................................................................................. 13
III-4.1. Sensores:.................................................................................................................................................... 13
III-4.2. Actuadores:................................................................................................................................................ 15
III-4.3. Hardware:.................................................................................................................................................. 16
III-5. FIRMWARE/ CONTROLO: ....................................................................................................................................... 19
III-5.1. O algoritmo:............................................................................................................................................... 21
III-5.2. Linearização da medida dos sensores VS lookup table:........................................................................... 22
III-5.3. Filtragem: .................................................................................................................................................. 23
III-5.4. Descrição do software: .............................................................................................................................. 27
IV. A PLATAFORMA: .................................................................................................................................................. 33
IV-1. INTRODUÇÃO:......................................................................................................................................................... 33
IV-2. ARQUITECTURA DA PLATAFORMA: ....................................................................................................................... 33
IV-3. IMPLEMENTAÇÃO:.................................................................................................................................................. 35
IV-3.1. Sensores: .................................................................................................................................................... 35
IV-3.2. Actuadores: ................................................................................................................................................ 37
IV-3.3. Hardware: .................................................................................................................................................. 38
IV-4. FIRMWARE/ CONTROLO: ....................................................................................................................................... 39
IV-4.1. O algoritmo: ............................................................................................................................................... 40
IV-4.2. Influência do sensor sobre o bloco de controlo PD:................................................................................. 41
IV-4.3. Descrição do software:............................................................................................................................... 44
V. O PENDULO: ............................................................................................................................................................ 47
V-1. INTRODUÇÃO: .......................................................................................................................................................... 47
V-2. MODELAÇÃO:........................................................................................................................................................... 48
V-3. ARQUITECTURA DO PÊNDULO:................................................................................................................................ 50
V-3.1. Simulação em Matlab do sistema de controlo:........................................................................................... 51
V-3.2. Resultados obtidos na simulação:............................................................................................................... 52
V-4. IMPLEMENTAÇÃO: ................................................................................................................................................... 53
V-4.1. Sensores:...................................................................................................................................................... 53
V-4.2. Actuadores:.................................................................................................................................................. 54
V-4.3. Hardware:.................................................................................................................................................... 55
V-5. FIRMWARE / CONTROLO: ........................................................................................................................................ 57
V-5.1. Algoritmos (PID, Fuzzy): ............................................................................................................................ 57
V-5.2. Descrição do software: ................................................................................................................................ 62
VI. COMUNICAÇÕES CAN: ....................................................................................................................................... 66
VI-1. INTRODUÇÃO:......................................................................................................................................................... 66
VI-2. BREVE INTRODUÇÃO AO BARRAMENTO CAN:...................................................................................................... 66
VI-2.1. Formatos da trama CAN ........................................................................................................................... 67
VI-2.2. Detecção e sinalização de erros................................................................................................................. 68
VI-3. ORGANIZAÇÃO DOS NODOS:................................................................................................................................... 70
VI-3.1 Organização geral: ..................................................................................................................................... 70
VI-3.2 Comunicação calha pc_monitor: .......................................................................................................... 71
VI-3.3 Comunicação plataforma pc_monitor: ................................................................................................. 71
VI-3.4 Comunicação pêndulo pc_monitor: ...................................................................................................... 72
VI-3.5 Comunicação pc_monitor todas:........................................................................................................... 72

2/95
Relatório – Construção de Plataformas para Experiências de Mecatrónica
Márcio Neves, Marco Leonor

VI-3.6 Configuração das máscaras e filtros.......................................................................................................... 73
VI-4. IMPLEMENTAÇÃO DAS COMUNICAÇÕES – SOFTWARE:..................................................................................... 73
VI-4.1 Processamento de uma mensagem recebida:............................................................................................. 73
VI-4.2 Envio de uma mensagem:........................................................................................................................... 75
VI-5. O MÓDULO “CAN18XX8.H” .................................................................................................................................... 75
VII. PC_NODE: .............................................................................................................................................................. 77
VII-1. INTRODUÇÃO: ....................................................................................................................................................... 77
VII-2. ARQUITECTURA DO PC_NODE:.......................................................................................................................... 77
VII-3. IMPLEMENTAÇÃO: ................................................................................................................................................ 78
VII-3.1. Descrição funcional ................................................................................................................................. 78
VII-3.2. Protocolo de transporte definido sobre a comunicação série RS232...................................................... 80
VII-3.3. Hardware .................................................................................................................................................. 82
VII-3.4. Descrição do software .............................................................................................................................. 82
VIII. SOFTWARE DE MONITORIZAÇÃO: ............................................................................................................. 86
VIII-1. INTRODUÇÃO:...................................................................................................................................................... 86
VIII-2. MONIPRO ............................................................................................................................................................ 86
VIII-3. MONIPRO – ESTRUTURA INTERNA:..................................................................................................................... 89
IX. CONSIDERAÇÕES GERAIS SOBRE FUTURAS VERSÕES DO SISTEMA: ................................................ 93
BIBLIOGRAFIA:........................................................................................................................................................... 94
REFERÊNCIAS: ............................................................................................................................................................ 94

3/95

Sumário:

Este documento descreve o projecto e a construção de uma estrutura integrada de
plataformas mecatrónicas dedicadas à implementação de processos de controlo. O sistema inclui
três plataformas mecatrónicas independentes: esfera equilibrada numa calha, esfera equilibrada num
plano e pêndulo invertido, ligadas a um PC dedicado à sua monitorização e supervisão, através de
um barramento CAN. Além da montagem dos sistemas físicos e desenvolvimento do hardware
necessário ao controlo de cada plataforma, implementou-se também a referida rede de comunicação
CAN que interliga todos os nodos a um PC. Neste, corre uma aplicação que permite a
monitorização e alteração dos parâmetros de controlo (supervisão) dos sistemas em tempo real (on-
the-fly). O processamento de cada nodo relativo a cada uma das plataformas, é feito por um micro-
controlador da Microchip sendo também utilizado para implementar o ‘gateway’ entre a rede CAN
e o PC.
O desenvolvimento do software para os micro-controladores, foi feito em C usando como
compilador o PICC-18 da HI-Tech e o ambiente de desenvolvimento Hi-Tide. O software de
monitorização foi escrito em C++ usando o Microsoft Visual C++ 6.0. O ambiente de janelas
assenta nas bibliotecas MFC (Microsoft Foundation Classes) e o ambiente gráfico em OpenGL.
Este trabalho foi realizado no âmbito do projecto final do 5º ano da LEET da Universidade
de Aveiro 2003/2004.

4/95

I. Introdução:

Grande parte dos sistemas electrónicos desenvolvidos, são criados para interagir com um
determinado processo físico, que pode ser mecânico, térmico, químico, óptico etc. Qualquer que
seja a área da aplicação, a electrónica destina-se na grande maioria dos casos, ou para promover a
monitorização, ou o controlo do processo em causa.
A interligação entre a electrónica e a mecânica, foi baptizada de mecatrónica sendo esta a
área de suporte ao nosso estudo e implementação de sistemas de controlo. Aqui, um sistema
electrónico interage com um ou diversos componentes mecânicos de forma a realizar uma dada
tarefa. Para que esta interligação seja possível, é necessária uma interface de ligação entre
grandezas eléctricas e físicas: os sensores medem uma grandeza física, e por sua vez, os actuadores
convertem grandezas eléctricas em algum tipo de força que realiza trabalho sobre um sistema físico.
Este tipo de sistemas encontram-se hoje em dia um pouco por todo o lado, quer seja em
aplicações domésticas (ex. um forno que se mantém à temperatura indicada pelo utilizador), quer
seja em aplicações industriais (ex. um braço robótico que roda a uma determinada velocidade) ou
mesmo num automóvel (ex. ABS – sistema que trava a roda sem a bloquear, por forma a permitir a
manoberabilidade do automóvel durante a travagem).
Devido à crescente importância do controlo, torna-se evidente a necessidade de plataformas
didácticas laboratoriais que estimulem a aprendizagem desta área, motivando os intervenientes
através da experimentação com sistemas de controlo reais, podendo servir também como banco de
ensaio para a investigação de novas estratégias de controlo. As estruturas criadas neste projecto têm
um pouco das duas vertentes, visto que são plataformas de teste contendo sensores, actuadores e um
micro-controlador que fecha a malha, e, permitem que seja visualizado o efeito imediato da
mudança dos parâmetros do controle no sistema físico, expondo assim o interesse da área visto que
se pode interagir com o sistema directamente.
Tipicamente, no estudo desta área recorre-se à utilização intensiva de software de simulação
matemática para implementar e ver a resposta de algoritmos de controlo. É relevante referir a
vantagem de um sistema real face a um sistema implementado com base na simulação, visto que um
sistema simulado deixa com frequência escaparem alguns pormenores muito relevantes ao controlo,
como a frequência de amostragem com que é possível implementar o sistema, limitações dos
sensores, actuadores, microcontrolador, variações nas tensões de alimentação, entre outras.

5/95

O sistema (plataformas, rede que permite a monitorização, gateway, etc.) para além de
permitir estudar um vasto número de algoritmos de controlo, pode ser usado também para projectar
comunicações entre nodos que podem compor um sistema mais complexo.
No decorrer deste documento começa-se por apresentar a arquitectura geral do sistema
descrevendo-se posteriormente cada uma das estruturas respectivo nodo e software, em capítulos
separados.

6/95

II. Arquitectura geral do sistema:

O sistema está assente sobre uma rede CAN (figura 1) que permite a comunicação entre os
nodos que a constituem. Cada nodo tem um micro-controlador PIC18F258 que se encarrega quer do
controle das estruturas, quer das comunicações RS232 (quando aplicável) e CAN. Os nodos
debitam para o barramento CAN uma trama de dados que contém uma descrição acerca do estado
de cada plataforma, sendo esta capturada pelo nodo gateway permitindo à aplicação monitora o
conhecimento global do sistema. Esta, por sua vez, transmite à rede qualquer alteração de
parâmetros que o utilizador solicite a partir do programa monitor, permitindo assim uma grande
interactividade entre o utilizador e as estruturas que compõem o sistema.
O sistema comunica através de tramas CAN standard (identificador de 11 bits) a uma taxa
de 1Mbps. O nodo que faz a ponte entre a rede CAN e a ligação ponto a ponto RS232 que é
estabelecida com o PC, não se limita apenas a fazer uma conversão da informação, mas gere
também a informação recebida actuando como buffer e supervisor de comunicações das estruturas.
Assim, quando é feito um pedido de actualização de dados por parte do software monitor do PC o
nodo envia apenas os dados actualizados ao PC. Da mesma maneira, quando o utilizador requer
alterações aos parâmetros de controlo de alguma das estruturas, o nodo recebe de imediato o
pedido, e transmite-o via CAN logo que possível.
A monitorização do movimento das estruturas, é uma característica que se pretende que o
sistema seja dotado, mas não o torna um sistema do tipo Hard Real Time, isto é, não é critico perder
uma amostra acerca do estado das plataformas, nem mesmo receber uma amostra errada, pelo que a
este nível não é feita qualquer validação dos dados recebidos. No entanto, as alterações dos
parâmetros de controlo são seguidas de uma mensagem de acknowledge da respectiva estrutura,
para garantir que foram feitas as alterações pedidas pelo utilizador.
Existem geralmente duas soluções de software para o processamento de um dado stream de
dados, que no caso dos nodos das plataformas são as amostras recebidas dos sensores a uma dada
taxa de amostragem: processamento amostra a amostra ou processamento bloco a bloco recorrendo
a buffers de software. O segundo método, implica que o atraso mínimo dependa do tamanho dos
buffers, e requer muito mais memória, pelo que se optou por basear os sistemas num processamento
amostra a amostra, que é conceptualmente mais simples, e o atraso mínimo depende apenas do
tempo de processamento de cada amostra.
Por sua vez, o software de monitorização, tal como qualquer programa desenvolvido sobre o
Windows ou outro sistema de janelas, é um programa que interage com o utilizador numa politica

7/95

“event triggered”, reagindo portanto aos pedidos do utilizador. Independentemente destes eventos
assíncronos gerados pelo utilizador, o software funciona com base em eventos gerados a partir de
timers programados, que despoletam ora a actualização do ecrã com os respectivos modelos das
estruturas, ora a leitura do estado das mesmas.

Figura 1: Layout do sistema

8/95

III. A CALHA:

III-1. Introdução:

Nesta estrutura pretende-se equilibrar uma bola numa dada posição de uma calha, actuando
na inclinação da calha em resposta à posição lida da bola. O sistema deverá ser capaz de estabilizar
a bola na posição pretendida e reagir a perturbações externas mantendo a bola nessa mesma
posição.

III-2. Modelização:

Esfera na calha:
m: massa da esfera
J: momento de inércia da esfera
θ: ângulo que a calha faz com a direcção horizontal
R: raio da esfera

Só vamos ter forças a realizar trabalho segundo a direcção da calha (eixo x). A força de
atrito, considerando que não há derrapamento da esfera, não realiza trabalho segundo o eixo X, no
entanto provoca um binário na esfera que a faz entrar em rotação. Assim:

9/95

(torque) τ = b × F ⇔
⇔ τ = R.Fa . sin(π 2) = R.Fa (1)
x = α .R ⇔ α = x (2)
R
∂θ
2
τ = J. 2
∂t
Substituindo (1) e (2) :
1 ∂2x
Fa = J .
R 2 ∂t 2
∂2x
∑ F =m 2 ⇔
∂t
1 ∂2 x ∂2 x
⇔ P. sin(θ ) − J . =m 2 ⇔
R 2 ∂t 2 ∂t
∂ 2 x 5g
θ ( Atendendo a que para pequenos ângulos, sin(θ ) ≈ θ )
⇔ =
∂t 2 7
A partir do modelo do sistema, espera-se então, que o controlador e os seus parâmetros
sejam independentes da bola que se pretende equilibrar, visto que o resultado obtido para o
comportamento da bola, é independente das características físicas da mesma. O seu comportamento
dinâmico apenas depende de uma constante e do ângulo da calha .

III-3. Arquitectura da Calha:

Do ponto de vista de um sistema de controlo, este é um sistema SISO (Single Input, Single
Output) em que temos como entrada a posição da bola e como saída o ângulo da calha (figura 2).
O bloco controlador
reage, não à posição da bola
directamente, mas sim ao erro
entre a posição pretendida para
a bola e a sua posição efectiva.
O ponto pretendido para a bola
é denominado de setpoint.
A forma como a
actuação é feita na calha de
maneira a diminuir o valor do Figura 2: Diagrama do sistema de controlo implementado
erro (E(k) - figura 2), depende
inteiramente da forma como o bloco controlador é implementado. No nosso quotidiano
encontramos inúmeros exemplos de processos de controlo que realizamos intuitivamente sem

10/95

sequer nos apercebermos. Tome-se como exemplo o acto de temperar a água num banho: cada
pessoa tem uma temperatura óptima à qual prefere tomar banho (setpoint), e enquanto não se sente
esta temperatura (sensing), ora se aumenta a água fria, ora se diminui (actuation). A forma como se
aumenta ou diminui a água é o processo de controlo e este pode ser feito de diversas formas.
É neste ponto do projecto de um sistema
que a modelação matemática do mesmo se torna
relevante. Através do modelo físico do sistema
que se pretende controlar, é possível estudar o
impacto de alguns algoritmos de controlo no
mesmo, sem ter efectivamente que os
implementar fisicamente. Assim, é possível ficar
com uma ideia prévia à implementação da
performance dos algoritmos estudados.
Figura 3: Resposta impulsional do modelo
Neste caso é feita uma simulação de
físico da calha com a malha fechada através
controlo recorrendo a controladores P, PD, PI e
de um controlador P.
PID e traça-se a resposta impulsional (sinal que
melhor caracteriza um sistema por ser composto
por um infinito de componentes de frequência) do
modelo do sistema e analisa-se a performance de
cada um dos controladores.
Na figura 3 temos a resposta de um
controlador P – proporcional – e verifica-se que
este tipo de controlo não é viável no sistema em
causa uma vez que o sistema nunca estabiliza no
setpoint predefinido. Por outro lado o acréscimo
Figura 4: Resposta impulsional do modelo
de um factor derivativo (figura 4) permite reagir à
físico da calha com a malha fechada através
velocidade com que a bola se aproxima do
de um controlador PD
setpoint. Esta informação acerca da velocidade
permite que o sistema tenda a estabilizar, tornando o controle PD apropriado para o sistema.
Verifica-se também que o acréscimo de um factor integral (figura 5), que geralmente é introduzido
para reduzir o erro em regime estacionário, não só não contribui para o melhor desempenho do
controlador P, formando um PI – proporcional integral – como o instabiliza. De facto o controlador
PD – proporcional derivativo – é o controlador adequado para o sistema uma vez que a
implementação de um PID (figura 6) – proporcional integral derivativo – não trás benefícios

11/95

Figura 5: Resposta impulsional do modelo Figura 6: Resposta impulsional do modelo
físico da calha com a malha fechada através físico da calha com a malha fechada através
de um controlador PI. de um controlador PID
relevantes devido ao facto de a função de transferência do sistema já ter um factor integral (1/s2 –
ver modelo fisico).
A não ser em casos muito específicos em que se conhece claramente a configuração do
mapa de pólos e zeros e consequentemente o lugar das raízes do sistema a tentar controlar, ao
processo de achar um controlador adequado para o sistema está sempre inerente uma tarefa de
experimentação de vários tipos de controlo e análise do comportamento resultante depois da malha
fechada.

12/95

III-4. Implementação:

Figura 7: Fotografia da estrutura da Calha.

III-4.1. Sensores:

Numa primeira abordagem ao problema da determinação da posição da bola, foi usado como
sensor de posição para a bola um fio resistivo, sobre o qual uma esfera condutora rolava. Construiu-
se para isso uma calha em que na superfície de contacto com a esfera foi colado um fio resistivo
com resistência de aproximadamente 10Ω/m. Numa primeira impressão a solução era muito
promissora, já que: não impunha qualquer limitação ao tamanho da calha, o tempo de aquisição
dependia apenas da ADC a utilizar e a função que relaciona a posição da bola com a resistência
medida é linear. No entanto surgiu um problema relacionado com a resistência superficial da esfera
condutora. O peso da esfera só por si, não era o suficiente para que houvesse uma condutividade
perfeita entre o fio resistivo e a esfera condutora, e as leituras da resistência do fio permaneciam
constantes e iguais à resistência total do fio a grande parte do tempo, mesmo apesar da bola se estar
a deslocar ao longo da calha.
Numa medição experimental da resistência superficial da esfera efectuada pousando a esfera
sobre duas pontas de prova, e medindo a sua resistência com um ohmímetro, obteve-se um valor
médio de 100kΩ para esta resistência. Na impossibilidade de arranjar um fio resistivo nessa ordem
de valores, ou preferivelmente superior, abandonou-se esta solução.

13/95

Para determinar então a posição da bola, escolheu-se para sensores das distâncias
d(sensor_e) e d(sensor_r) (figura 7) o Sharp GP2-D12, que é um sensor que infere acerca da
distância de um objecto a partir de um emissor de infravermelhos e um CCD (application note 1).
Este sensor foi escolhido pelo seu baixo custo, apesar de apresentar alguns problemas relevantes
abaixo descritos:
1. Tem uma gama de medição
apenas de 10 a 80 cm (figura 8).
2. Para medições acima de 40 cm, o
ruído na saída analógica causa um grande erro
de medida devido à resposta não linear deste
sensor: a amplitude do ruído mantém-se, mas a
variação da tensão em função da distância da
bola é cada vez menor (figura 8).
3. O valor da saída analógica apenas
é actualizado a cada 38,3±9,6 ms (datasheet –
figura 3 “Timing Chart”).
Estes problemas causam limitações tanto
a nível da estrutura mecânica como a nível do
controlador a implementar. Em resposta à não
Figura 8: Resposta do Sharp GP2D12
linearidade dos sensores, optou-se por usar dois
sensores, um em cada extremidade da calha. A
gama de leitura reduzida, implica um limite
físico no comprimento da calha, que foi
estabelecido num valor não superior a 60cm, em
que cada sensor cobre os seus 30cm de calha
adjacentes, de forma a limitar o erro máximo de
medição da distância.
Uma grande parte do ruído destes
sensores, é caracterizado por picos de tensão de
elevada amplitude (figura 9). Este ruído tem que
Figura 9: Sinal à saída do Sharp GP2D12
ser suprimido de alguma forma, para evitar que
uma amostragem seja feita neste instante, degradando o sinal de entrada.

14/95

III-4.2. Actuadores:

Em robótica, os actuadores mais comummente utilizados são servos. Um servo é geralmente
um motor DC sem escovas, que trabalha em conjunto com um dispositivo de medição de posição
que faz o seu feedback permitindo assim o controlo do ângulo do eixo do motor.
O controlo da posição pretendida para o servo é dado a partir da duração do impulso na
entrada de controlo do servo, técnica designada por PWM (Pulse Width Modulation). O servo está à
espera de ver um pulso a cada 20ms em que a largura do impulso é que determina a posição do
eixo. Assim, variando a largura do impulso entre 1ms e 2ms, obtemos uma deflexão do eixo entre 0
e 210º aproximadamente.
Foi eleito este tipo de actuadores, devido à facilidade de controlo do mesmo, preço e
também pela facilidade em o obter.
O acoplamento do servo-motor à calha, não é feito directo ao eixo de rotação da calha, mas
sim através de um braço
ajustável em comprimento
(figura 10). Assim, é possível
calibrar mecanicamente a
posição horizontal da calha em
função da posição de repouso
do servo. Desta forma, o eixo
de rotação é um mecanismo
mecânico que não expõe o
servo ao peso da calha,
contribuindo assim para um
aumento do tempo de vida do
Figura 10: Acoplamento do servo à calha
servo.

15/95

III-4.3. Hardware:

+5V +5V

C2 C1
100nF 100nF

U2 20 3 JP1
PIC18F258 U1
1
6
VDD VCC CANL 2
RB0 RA0 RB2
21 2 1 7
RB0/INT0 RA0/AN0/CVref TXD CANH 3
RB1 RA1 RB3
22 3 4
RB1/INT1 RA1/AN1 RXD
RB2 RA2
23 4 5 HEADER 3
RB2/CANTX/INT2 RA2/AN2/VREF- VREF
RB3 RA3
24 5 8
RB3/CANRX RA3/AN3/VREF+ GND RS

1
RB4 RA4
+5V 25 6
RB4 RA4/TOCKI
RB5 RA5
26 7 PCA82250 JP2
RB5/PGM RA5/AN4/SS/LVDIN 2
RB6
R1 27
RB6/PGC JUMPER
RB7 28

2
RB7/PGD RC0
10K 11 BARRAMENTO
RC0/T1OSO/T1CKI RC1
SW1 12
CAN
RC1/T1OSI RC2
13
RC2/CCP1 R3
RC3
1 14 R2
MCLR/VPP RC3/SCK/SCL RC4
15 +5V 120
RC4/SDI/SDA RC5
CLEAR 16
RC5/SDO
VSS RC6
8 17
VSS1 RC6/TX/CK RC7
19 18 100K JP3
VSS2 RC7/RX/DT
1
OSC1/CLKI OSC2/CLKO/RA6 2
3
9 10 HEADER 3

X1

10MHZ
C3 C4
+ +
22pF 22pF

+12V
+5V VDD VCC
U3
JP5 D1
1 2 1 3
2 VIN VOUT

GND
1 100nF +
+ +
1N4007
C5 C6 R4 C7
12V 100uF 100nF 3k3 L7805CV

2
JP6
VSS
+5V D2
2 LED
1

12V
4
TX
3
RC6
2
RC7
1
RX
JP4
Placa do Pic18F258

Figura 11: PIC18F258, alimentação e driver CAN

R_+5V

R_U1
16

MAX202
R_+5V 13 12
VCC

R1IN R1OUT 9
R_RX_232 R_RC7 CONNECTOR DB9
8 PIC_RX
R2IN R2OUT 14
R_JP1 11 1
T1IN T1OUT 7
R_RC6 R_TX_232
R_C1 PIC_TX 10 6
4 T2IN T2OUT R_TX_232
100nF 2
3 R_RC7 R_C2 1 7
2 C+
R_RC6 R_RX_232
100nF 3 3
1 C1-
4 8
C2+
5 4
C2-
4 HEADER 2 9
GND

V+
6 5
V-
R_+5V
R_P1
15

R_C3 R_C4 R_GND
100nF 100nF

Placa RS232 do Pic18F258
Incorporada numa ficha DB9

Figura 12: Interface RS232

16/95

CON2 R8 330 D8
RA0 +12V RB0
1 2 PWM
RA1 RB7
3 4
RB6
5 6 R9 330 D9
Saidas
RB5 RB7
7 8 CAN Module
Digitais de
RB4
9 10
11 12 R10 330 D10
Monitorização
RB1 RB6
13 14 ADC Module
RB0
15 16
VSS 17 18 R11 330 D11
RB5
19 20 CAN Tx
21 22
23 24 R12 330 D12
RB4
25 26 CAN Rx

CON26

Ligação ao Modulo PIC

+5V_sensor
J5

1
2
Alimentação
3
U3
+5V_motor
+12V RA0
1 2 Sensor de Posição Esquerdo
Entradas
VIN VOUT
analógicas do uC RA1
GND
C3 LM7805 C6 +5V_sensor
3

100uF 100nF J6

1
2
+5V_motor 3
U4 J4
+5V_sensor
+12V RB0
1 2 1 Sensor de Posição Direito
Saida PWM
VIN VOUT 2
do uC
GND 3
C8 LM7805/TO C7
3

100nF 100nF
RC Serv o

Figura 13: Alimentação dos sensores e servo e indicações luminosas

A saída dos sensores de posição terá um valor máximo de 2.6V (figura 8), mais
aproximadamente 0.4V referente aos picos periódicos que aparecem à saída dos sensores (figura 9),
o que leva a por em causa a amplificação ou não do sinal proveniente dos sensores. A
compatibilização da gama de saída dos sensores com a gama de entrada da ADC (0 a 5V) pode
também ser conseguida a partir da introdução de uma referência positiva na ADC do
microcontrolador de 3V.
Qualquer uma das soluções implica um acréscimo do hardware no sistema, ora para
amplificar o sinal ora para criar uma referência para a ADC. O benefício introduzido por este
acréscimo de hardware não é razoável para que justifique a sua implementação. A redução da gama
de entrada da ADC de 5V para 3V implica uma redução de 20mV(5/28) para 12mV(3/28) para a
menor variação detectada pela ADC. Como o nível de ruído pode chegar à ordem dos 400mV (figura 9), este
acréscimo de resolução na medida do sensor torna-se irrelevante.
O microcontrolador utilizado disponibiliza uma grande quantidade de portos de entrada/ saída que
permite que seja implementado um sistema de leds que indica o estado de diversas operações em
curso:
PWM: brilha mais ou menos dependendo da inclinação da calha.
CAN MODULE: indica a inicialização com sucesso do modulo de comunicações CAN.
ADC MODULE: indica a inicializaçao com sucesso do modulo de adquisição de dados a
partir da ADC do PIC18F258.

17/95

CANTX: sinaliza a transmissão de uma mensagem CAN.
CANRX: sinaliza a recepção de uma mensagem CAN.

18/95

III-5. Firmware/ Controlo:

Como foi referido, o tipo de controlador implementado nesta estrutura foi um controlador
PD – proporcional derivativo - (figura 14), que tem como entrada o sinal de erro (set point –
posição) e actua sobre a saída (sinal de controlo PWM do servo).

Figura 14: Controlador implementado na calha

Quando se pretende definir uma taxa de amostragem para um sensor, relativo a um dado
processo de controlo, existem geralmente algumas directivas desejáveis de serem cumpridas:
- Amostrar o mais rápido possível para obter o máximo de exactidão
- Amostrar o mais lento possível para poupar no tempo de processamento
- Amostrar tão lento quanto possível de forma a que o ruído não domine o sinal de entrada
- Amostrar a uma taxa múltipla da do algoritmo de controlo de forma a minimizar o jitter
De facto, não é possível fazer um cálculo determinístico para a frequência de amostragem
óptima. No entanto é possível fazer uma abordagem sistemática ao problema e calcular a frequência
de amostragem procurada ponderando qualitativamente alguns factores em causa:
1º - Conhecer as características dos sensores/ actuadores da aplicação:
- o Sharp GP2-D12 tem uma taxa de refrescamento, na pior das hipóteses de 21Hz e
na melhor 35Hz;
- o servo-motor utilizado actualiza a posição do eixo no máximo a uma frequência de
50Hz.
2º - Calcular um limite inferior e superior para a frequência de amostragem:

19/95

- como limite superior consideramos os 50Hz impostos pelo servo;
- o limite inferior depende da dinâmica do processo físico a controlar e não é
conhecido à partida..
3º - Identificam-se os prós e os contras entre usar os extremos calculados no ponto anterior,
e atribuem-se prioridades às características em jogo, identificadas:
- geralmente, numa aplicação embedded, o recurso que tem que ser cuidadosamente
distribuído, é o tempo de processamento do microcontrolador ou processador utilizado. O tempo de
processamento gasto por cada tarefa é bastante relevante, e tipicamente a amostragem consome
parte desse tempo. O limite superior da frequência de amostragem permitida pelos sensores/
actuadores é muito pouco exigente perante o microcontrolador em causa.
Para simplificar o sistema, e visto não haver vantagens em fazer de outra forma, optou-se
por tornar o processo de controlo, a amostragem e actuação síncronos, isto é, a funcionarem à
mesma frequência.
Quanto ao limite inferior, apesar de não se conhecer, empiricamente sabemos que
considerar que a bola pode mover-se na pior das hipóteses com um movimento harmónico de 10Hz
já é uma boa margem para o sistema físico em causa (ver estudo sobre a dinâmica do sistema na
secção de filtragem). Assim, pelo critério de Nyquist que diz que a frequência de amostragem para
um dado sistema tem que ser maior do que duas vezes a sua componente de frequência máxima,
(fs>2*fmax), a frequência de amostragem teria que ser superior a 20Hz.
Apesar de uma frequência de amostragem de 20Hz, já ser supostamente suficiente para
caracterizar o movimento pretendido, o sistema foi projectado para uma frequência de amostragem
de 50Hz por algumas razões:
- o impacto desta subida da frequência de amostragem sobre o tempo de
processamento não é significativa.
- o critério de Nyquist impõem uma condição necessária e suficiente para ser
possível reconstruir o sinal, mas o processo de reconstrução requer algum calculo computacional.
Como o controlo é feito em malha fechada, não é necessário conhecer todo o sinal. Apenas as
amostras mais recentes são necessárias para aplicar na malha de feedback.
- o sinal de controlo do servo tem um período de 20ms (50Hz), e por razoes de estruturação
do software de controlo, torna-se vantajoso tornar o algoritmo de controlo síncrono com a geração
do sinal de controlo do servo-motor.

20/95

III-5.1. O algoritmo:

Figura 15: Organização do software de controlo da calha

Para marcar uma referência temporal no software que garanta que a amostragem é feita
efectivamente a 50Hz, recorreu-se a um timer disponibilizado pelo microcontrolador, que gera uma
interrupção de 20ms em 20ms. O atendimento a esta interrupção incrementa uma variável inteira
denominada de tick, que permite que o ciclo principal do programa execute à taxa pretendida.
Cada amostra obtida é filtrada por um filtro FIR sendo de seguida processada pelo bloco
controlador_PD. Neste estágio do processamento é calculada a actuação a aplicar à calha de forma
a obter o controlo pretendido. Para que o valor calculado não exceda os limites permitidos para o
controlo do servo, este é clipado antes de ser usado na actuação.
Por fim, o estado da estrutura é enviado via CAN e o microcontrolador verifica se existem
mensagens que pretendam alterar os parâmetros de controlo. Caso existam, são imediatamente
alterados, e esta alteração faz-se sentir logo na amostragem seguinte.

21/95

III-5.2. Linearização da medida dos sensores VS lookup table:

A tensão obtida pela ADC ligada aos
sensores de posição, fornece uma medida da posição
da bola na calha. A dependência desta tensão com a
posição da bola pode ser estabelecida por
correspondência directa (lookup table) ou
algebricamente através de uma expressão
matemática.
A partir de um conjunto de pontos
experimentais, traçou-se a resposta do Sharp GP2-
Figura 16: Resposta dos Sharp
D12 (figura 16) e fez-se corresponder as medidas à
posicionados nas extremidades da calha
distância a que a bola se encontrada da extremidade
de 60cm
onde o sensor está implantado. Como foi necessária
a presença de um segundo sensor na extremidade oposta de forma a aumentar a fiabilidade das
medidas, foi também traçada a resposta do mesmo (figura 16).
Tem então que ser estabelecida uma relação biunívoca entre ambos os sensores e a posição
da bola. Para isso, optou-se por subtrair as respostas
dos sinais, visto que o resultado aproxima em muito
uma recta (figura 17).
Obtemos então uma resposta de forma
aproximadamente linear entre a medida obtida a
partir dos sensores e a posição efectiva da bola na
calha, à parte de uma constante, o que se torna muito
vantajoso em termos do controlo e do tempo de
processamento que o micro-controlador teria que
Figura 17: Diferença entre a leitura dos despender caso fosse necessário implementar uma
dois sensores solução do tipo lookup table.
A partir de uma regressão linear feita aos pontos que permitem desenhar a curva
representada na figura 10, obtém-se a seguinte relação: Vadc=0,0832*d, em que d é a posição da
bola, considerando o 0 da posição à distância de 30cm. Então, d obtém-se simplesmente por d =
12*Vadc.

22/95

Assim, a hipótese, de uma lookup table, que consiste em termos os valores tabelados e o
acesso à tabela é feito indexando o valor pretendido a partir da variável tensão, neste caso, fica
posta de parte visto que obtemos de uma forma algo indirecta, mas funcional uma resposta linear
dos sensores.

III-5.3. Filtragem:

Numa fase preliminar, todo o controlo foi implementado passando ao controlador uma
leitura directa dos sensores, ignorando os picos apresentados por estes. De facto o controlador PD
projectado (figura 14) respondeu de forma positiva apesar de frequentemente o sistema se
instabilizar devido a perturbações do sinal de entrada. Veja-se como exemplo disso, a captura da
posição lida para a bola (figura 18) com o controlador a responder com parâmetros Kp = 1.6 e Td =
0.25.
De facto, a magnitude do erro apresentado
na figura 18 sugere que os picos referidos que
ocorrem periodicamente nas medições dos
sensores, ou mesmo os erros introduzidos por
outras fontes, não podem ser ignorados,
remetendo-nos para uma necessidade de filtrar o
sinal.
Para a filtragem do sinal de entrada
(diferença entre os sinais dos 2 sensores de Figura 18: Gráfico da posição da bola com
distância) recorreu-se a técnicas de processamento o sistema a responder sem o sinal de
digital de sinal para projecto de um filtro FIR, entrada filtrado
após uma tentativa prévia de resolução do problema com filtro analógico de 1ª ordem, sem
resultados aceitáveis.
O sinal dos sensores requer um passa-baixo que filtre as altas-frequências introduzidas no
sinal pelo ruído. Assim para o projecto do FIR é necessário definir a frequência de corte para o
sinal, separando o que é variação do sinal inerente ao movimento da bola e o que é a variação
devido ao ruído dos sensores. Não há um processo determinístico que faça o cálculo desta fronteira,
pelo que é feita uma aproximação, seguindo uma percepção de alguma forma intuitiva do
comportamento físico do sistema.

23/95

Figura 19: Movimento harmónico da bola na calha

Para uma estimativa da frequência de corte do filtro consideramos o caso em que a calha de
60cm está inclinada de um ângulo θ = 45º, que a bola parte do repouso de uma extremidade (figura
19 A)).
No momento que a bola passa pelo centro e a sua velocidade é máxima, a calha roda -90º
(figura 19 B)). Considerando que há conservação da energia mecânica, a bola atinge extremidade
oposta da que partiu, anula-se a sua velocidade, e inverte o sentido do movimento.
Este sistema, origina na bola um
movimento oscilatório com uma frequência que
pode ser determinada pelo tempo de descida da
bola: o tempo da sua descida é igual a
exactamente um quarto do período de oscilação
(tdescida = Tosc/4). Atendendo a que x = x0 + vox*t
+ 0.5*ax*t2, temos para o tempo de descida um
valor de 0.294 segundos (considerando ax =
g*sin(45º), g = 9.8m.s-1, x0 = 0, x = 0.30). Temos
então um movimento harmónico com uma
Figura 20: Resposta em frequência do filtro
frequência de 0.85Hz. O valor desta frequência
FIR desenhado
de oscilação, depende apenas do tempo de descida da bola, pelo que convém calcular o seu valor
máximo. No caso limite, já que temos uma resolução dos sensores de 1cm, considere-se o tempo de
descida da bola se ela partir apenas a 1cm da posição central. Nestas condições, obtemos um
movimento harmónico com um período de oscilação de 4.65Hz.
Assim, considerar variações no sinal com frequência superior a 4.65Hz, não faz qualquer
sentido, uma vez que esta variação do sinal deverá ser causa de erros de medição. Seguindo esta

24/95

análise empírica, o projecto do filtro FIR foi feito segundo a aproximação de REMEZ, com banda
de passagem de 0 a 4Hz, banda de transição de 4 a 8Hz e banda de atenuação para frequências
superiores a 8Hz.
A resposta do filtro com as bandas de
passagem, transição e atenuação referidas, sendo
projectado com ordem N = 11, é como indicada
na figura 20. Note-se que apesar de ser possível
implementar um filtro de maior ordem, e
consequentemente maior atenuação, isto não
pode ser feito já tem que haver um compromisso
entre a sua ordem e o atraso introduzido no sinal.
Quanto maior for o número de coeficientes do
filtro maior é o atraso introduzido no sinal,
Figura 21: Consequência da filtragem na
piorando o panorama para o controlo. Para uma
energia do sinal proveniente dos sensores
ordem de N = 11, o atraso introduzido no sinal é de N*Ts = 220ms (Ts = 20ms) (veja-se na figura
22 o desfasamento entre o sinal original e o sinal filtrado).
Depois do sinal filtrado e calculadas as transformadas de Fourier, é visível a atenuação

Figura 22: Resultado final da filtragem (sinal a azul) num sinal com ruído (sinal a vermelho)

25/95

quase completa da energia em frequências superiores a 8Hz, já fazendo-se notar um decréscimo
desta na banda de transição do filtro (figura 21). Os resultados no sinal filtrado são bastante
significativos, e os picos inerentes ao ruído são
completamente suprimidos (figura 22). Note-se
que representação do sinal filtrado vem a azul e o
original a vermelho.
Na representação gráfica apresentada na
figura 22 de uma captura do movimento da bola
na calha, é visível uma oscilação que se faz sentir
na análise espectral do sinal capturado. O filtro
FIR referido, depois de projectado terá que deixar
passar as frequências na gama acima referida de 0
Figura 23: Pico de energia a uma frequência
a 5Hz para não atenuar as frequências relativas ao
de 0.3Hz aproximadamente relativo ao
movimento da bola. No caso concreto da análise,
carácter harmónico do movimento da bola.
verifica-se de facto um pico que indica uma
frequência fundamental de 0.3Hz, que caracteriza este movimento harmónico, e este pico não se
apresenta atenuado à saída do filtro, como é visível na figura 23.

26/95

III-5.4. Descrição do software:

Descrevem-se aqui todos os módulos de software (figura 24) que constituem o programa que
o microcontrolador executa de forma a fazer funcionar a calha.

Figura 24: Módulos de software que constituem o firmware de controlo da Calha

“adc_module.h”

Este módulo encarrega-se da aquisição de dados a partir da ADC do microcontrolador (PIC
18F258). É constituído por duas funções que se encarregam respectivamente da inicialização do
hardware e da conversão e posterior leitura do valor presente no canal pretendido.

void adc_init(unsigned char configuration);

Esta função inicializa o hardware tal como especificado no byte de configuração
configuration, e solicita à ADC a primeira conversão no canal especificado.
O byte configuration, pode ser um OR de um conjunto de definições criadas para a
configuração dos registos do hardware:

#define CHANNEL0
#define CHANNEL 1
#define CHANNEL 2
#define CHANNEL 3
#define CHANNEL 4

27/95

Estas definições permitem escolher o canal do qual se pretende o valor convertido. São
usadas tanto na função adc_init() como na função read_value() que se descreve a seguir.

#define CONF0
#define CONF1
#define CONF2
#define CONF3

O PIC 18F258 permite uma versatilidade de configurações para os seus pinos reservados à
ADC. Os pinos de I/O da PORTA podem ser configurados desde entrada analógica, entrada/ saída
digital e referência positiva ou negativa da ADC. A escolha de umas das configurações CONFx
permite seleccionar uma combinação predefinida para o funcionamento dos pinos (tabela 1).

AN4 AN3 AN2 AN1 AN0
CONF0 A A A A A
CONF1 A V+ A A A
CONF2 A V+ V- A A
CONF3 D D D D A
Tabela 1: Configurações possíveis para os pinos da ADC do PIC18F258

#define LEFT_JUSTIFIED
#define RIGHT_JUSTIFIED

Como estamos a lidar com uma ADC de 10 bit, num microcontrolador com barramento/
registos de 8 bit, o resultado terá que ser necessariamente dividido por 2 registos. O módulo permite
também configurar se o resultado vem justificado à esquerda, com os 8 bits mais significativos
juntos num registo (ADRESH) e os 2 menos significativos noutro (ADRESL), ou justificado à
direita com os 8 bits menos significativos em ADRESL e os 2 mais significativos em ADRESH.

Exemplo de utilização: adc_init(CHANNEL0 | CONF0 | LEFT_JUSTIFIED);

unsigned int read_value(unsigned char channel);

28/95

Esta função (figura 25) permite
adquirir a partir da ADC um valor convertido
do sinal à entrada do canal escolhido para a
leitura. A aquisição é feita por pooling ao bit
GO/~DONE presente no registo ADCON0, e
é portanto bloqueante. Uma vez que o
algoritmo de controlo não pode prosseguir
sem o valor actualizado dos sensores, não faz
sentido a aquisição ser feita por interrupção. O
tempo que a rotina leva a devolver um valor
convertido, é o tempo de aquisição do canal
(tempo que tem que ser esperado de forma às
capacidades internas da ADC terem tempo de
carregar/ descarregar), sendo considerado o
pior caso de operação em condições extremas
de 15µs, mais o tempo de conversão que é
Figura 25: Diagrama de fluxo da função
aproximadamente de 12 TAD, com 1 TAD =
unsigned int read_value(unsigned char
1,6µs, resultando num total de
channel)
aproximadamente 35µs.

Exemplo de utilização: posicao = read_value(CHANNEL0);

“controller.h”

Este módulo de software implementa o controlador PD (proporcional-derivativo), do sistema
(figura 14). Recebe como sinal de entrada o valor lido para a posição da bola e devolve um valor
representativo da inclinação da calha que será posteriormente passado ao módulo “isr.h” a partir de
uma variável global denominada de pwm1. Este módulo é controlado não só pela função
controller_PD() nele implementada, mas também por um conjunto de variáveis de âmbito global:
set_point, kp e td.

int controller_PD(double pos);

29/95

Esta função implementa exactamente o diagrama de blocos do controlador apresentado na
figura 14. Recebe um valor do tipo double que representa a posição da bola na calha e devolve um
valor inteiro que representa a inclinação a aplicar na calha de forma a controlar o sistema. Os
parâmetros do bloco controlador podem ser alterados modificando as variáveis de âmbito global
referidas. As funções dedicadas à implementação do processo de controlo foram desenvolvidas de
maneira a ser possível aplicar o algoritmo de controlo a qualquer tipo de sistema. Assim, não é
estabelecido qualquer limite na gama de valores que as variáveis que constituem este módulo de
software (set_point, kp e td) aceitam. O algoritmo no geral garante apenas que o valor de saída deste
bloco é limitado (clipping – figura 15) para que o valor que é passado ao módulo dedicado ao
controlo dos servos esteja dentro da gama. A ordem de grandeza dos valores para as variáveis de
controlo depende apenas do processo físico. Se houver uma mudança significativa num parâmetro
físico, como por exemplo o atrito da bola a equilibrar na calha, com uma troca de bolas, certamente
os valores destas variáveis para atingir o controlo podem sofrer ligeiros ajustes. É com vista a tirar o
máximo de informação possível do algoritmo de controlo, que não se faz qualquer limitação aos
valores destas variáveis.

Exemplo de utilização: pwm1 = controller_PD(position);

set_point

Esta variável define a posição em que a bola deverá estabilizar na calha. Pode ser alterada
em qualquer altura que o sistema reage na próxima amostra tratada pelo bloco controlador.

kp

Esta variável define o coeficiente proporcional do bloco controlador. Pode ser alterada em
qualquer altura que o sistema reage na próxima amostra tratada pelo bloco controlador. O
coeficiente proporcional pesa a deflecção do ângulo da calha tanto mais quanto mais a bola está
afastada do setpoint definido.

td

Esta variável define o coeficiente derivativo do bloco controlador. Pode ser alterada em
qualquer altura que o sistema reage na próxima amostra tratada pelo bloco controlador. Este

30/95

coeficiente permite que o sistema tenha uma percepção da velocidade com que a bola se aproxima
do setpoint, antecipando a actuação sobre a inclinação da calha.

“fir.h”

Este módulo de software implementa o filtro digital FIR de ordem N = 11 (12 coeficientes)
que faz a filtragem do sinal de entrada obtido a partir da leitura dos Sharp GP2-D12 descrito em III-
5.3.

double filter(double sample);

Esta função calcula a amostra filtrada a partir da forma directa II para filtros FIR. Os
coeficientes ficam guardados em memória, assim como a linha de atrasos para o filtro (figura 26).

Exemplo de utilização: posiçao = filter(posiçao);

Figura 26: Estrutura do filtro FIR implementado (forma directa-II)

“isr.h”

A este módulo é encarregue a tarefa de gerar o sinal necessário ao movimento do servo. Para
isso o software faz um uso intensivo das interrupções de hardware geradas a partir do timer 2 que é
um timer programável.
Além do movimento dos servos, é também incrementada uma variável de âmbito global
denominada de tick incrementada a cada 20ms (período de amostragem do sistema) que permite
manter o sistema a uma taxa de amostragem fixa e bem determinada (figura 15).

void pwm_init(void);

31/95

Esta função inicializa o modulo “isr.h” programando o timer 2 para gerar uma interrupção
no final de contagem (quando o valor do timer iguala o valor do registo PR2).

pwm1

Esta variável de âmbito global permite comunicar com este módulo munindo a rotina de
interrupção por ele implementada da capacidade de definir a duração da largura do impulso gerado
com objectivo de controlar o servo. O seu valor deverá estar entre 0 e 1000 para que a largura do
impulso varie de 1ms a 2ms respectivamente, repetindo-se este ciclo a uma taxa de 50Hz (o sinal de
controlo do servo tem portanto uma resolução de 1000 pontos).

void interrupt isr(void);

Esta função por sua vez, é a que atende à interrupção gerada pelo final de contagem do timer
2 e encarrega-se de colocar à saída RB0 (saída PWM de controlo do servo-motor - pino 0 da
PORTB) o valor digital necessário à geração do sinal PWM pretendido. Dentro desta função, o
valor de PR2 é alterado dinamicamente de forma a termos interrupções nos momentos precisos em
que é necessário mudar o estado de RB0 para ser gerado o sinal de controlo do servo.
Esta função será explicada com mais detalhe no capítulo relativo ao software da plataforma,
uma vêz que esta função está estendida ao controle de dois servos e não apenas ao de um.

“can18xx8.h”

Este módulo está referenciado num capítulo deste documento reservado às comunicações
CAN, uma vez que é um módulo de software comum a todos os nodos da rede CAN. É então aí
feita uma descrição detalhada de todas as comunicações relativas ao sistema (ver capitulo VI).

32/95

IV. A PLATAFORMA:

IV-1. Introdução:

O objectivo deste setup é fazer o controlo da posição de uma bola num plano, actuando
sobre a inclinação do plano. A ideia é que a bola se mantenha numa coordenada indicada mesmo
perturbando a posição da bola empurrando-a, ou lançando-a para o plano com uma velocidade
inicial em qualquer direcção diferente de zero. O controlo deverá ser robusto suficiente para
compensar esta perturbação inicial no movimento da bola. Este setup pode ser considerado como
sendo um sistema de controlo que é uma extensão do anteriormente descrito (Calha). O controlo é
feito agora em duas dimensões.

IV-2. Arquitectura da Plataforma:

O controlo feito a duas dimensões implementado neste setup, tira partido do principio da
ortogonalidade entre duas grandezas. Sabe-se que duas grandezas que se provem ser ortogonais,
então elas são independentes uma da outra, ou seja, não existe nenhuma função que faça a
caracterização de uma delas em função da outra. Isto é, se o movimento da bola no plano for
decomposto segundo um sistema de eixos que forma uma base do sub-espaço vectorial no qual o
plano está contido, garante-se a independência linear das duas dimensões.
Ora, se o sistema de coordenadas escolhido for o sistema cartesiano clássico que é
→
→
representado pela base <(1,0) x ; (0,1) y >, então podemos garantir a independência do controlo para
cada uma das direcções do movimento.
O sistema de controlo da calha, é então aplicado exactamente da mesma maneira a cada um
dos eixos do sistema da Plataforma. O sistema pode então reagir de maneira distinta ao movimento
da bola projectado no eixo dos X ou projectado ao eixo dos Y, dependendo apenas do bloco
controlador implementado (figura 27).

33/95

Figura 27: Diagrama do sistema de controlo implementado

O processo de controlo para este setup leva então ao limite o princípio da ortogonalidade já
que do ponto de vista da implementação o problema é visto como se se tratassem de duas calhas
independentes. Assim, todo o estudo prévio feito relativamente à implementação de um controlador
para a Calha, adapta-se na sua totalidade a cada um dos eixos ortogonais do movimento da bola na
Plataforma. O bloco utilizado no fecho da malha de feedback do sistema é, da mesma forma que na
Calha, um bloco do tipo “PD Controller”.

34/95

IV-3. Implementação:

Figura 28: Fotografia da estrutura da Plataforma.

IV-3.1. Sensores:

A CMUcam (figura 29), é um sistema
óptico de reconhecimento de cor, de baixo
custo, que pode ser utilizado, entre outras
coisas, para o reconhecimento de objectos em
robótica. No caso específico deste projecto, a
CMUcam é usada como um sensor de posição
que permite determinar as coordenadas de
uma bola num plano. Para melhor
desempenho do sensor, utiliza-se um plano
branco e uma bola de cor escura para que haja Figura 29: Diagrama do sistema de controlo
um grande contraste entre o objecto em implementado
movimento e a cor de fundo. O módulo de
visão não é constituído apenas por um bloco de captura de imagem, mas tem também já integrado
um microcontrolador que faz um tratamento da imagem e permite que seja enviada via RS232 uma

35/95

trama de dados a uma taxa de 17Hz, que indica a coordenada do centro de massa do objecto que se
pretende detectar.
Como qualquer camera, um dos seus constituintes é uma lente óptica que permite que a
imagem seja focada num sensor CCD. A distância focal da lente deste componente óptico faz
depender a altura a que tem que ser montada a camera (figura 28), da área que se pretende cobrir.
Para uma área de aproximadamente (50x50)cm2, estimou-se a altura a que a camera tem que ser
montada entre 90cm a 100cm. O facto da resolução da camera ser um valor fixo, implica também
que a resolução em termos da posição é sempre dependente desta área. A resolução é sempre
calculada pelo número de pixels que a camera capta numa determinada direcção sobre a distância
que se pretende cobrir. Neste caso específico para a direcção com pior resolução da camera, será de
(50/80 = 0.625) cm/pixel.
O facto do módulo de captura de imagem possuir um sensor CCD que não é simétrico nos
dois eixos (80x144), implica que uma das direcções sobre a qual o movimento da bola se
decompõe, tenha praticamente metade da resolução da outra. Este facto tem um impacto sobre o
bloco controlador, que se verifica numa diferença de “suavidade” do controlo entre o movimento
segundo os dois eixos.
A CMUcam tem algumas particularidades que são relevantes à sua utilização que apesar de
serem descritas no seu manual (manual v2.0) convém referi-las aqui. Quando a camera é ligada ou
se faz um reset, o sensor CCD tem que estar exposto à luminosidade por um período não inferior a 5
segundos para que seja feito um ajuste do ganho de luminosidade. A CMUcam não reage bem às
variações da luminosidade ambiente pelo que a fiabilidade das medidas tende a decrescer quando
existem variações bruscas na luz ambiente. Para uma correcta inicialização do módulo de captura de
imagem, o botão do reset do módulo do PIC tem que permanecer premido durante este tempo de
pelo menos 5 segundos e só decorrido este tempo é que se deixa de primir o botão de reset
permitindo a inicialização da electrónica do setup (figura 30).

Figura 30: Passos de inicialização da CMUcam

36/95

IV-3.2. Actuadores:

Tal como o setup da Calha, foram
servo-motores os actuadores utilizados para
fazer variar a inclinação do plano em
resposta à posição da bola (III-4.2.).
Foi usado um servo para cada um
dos eixos e foram acoplados (figura 31 –
fase de projecto; figura 32 – resultado final)
de forma a tentar não violar nenhuma
condição que pusesse em causa o princípio Figura 31: Plataforma em fase de projecto
da ortogonalidade referido. Isto é, cada (SolidWorks 2003).
servo tem que movimentar o plano apenas
no eixo que lhe foi atribuído. É necessário
tanto da parte da actuação como da parte do
sensoring, garantir a independência de
ambos os eixos em que o movimento da bola
é decomposto.

Figura 32: Acoplamento do servo à Plataforma.

37/95

Caca

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Destaque

Destaque (8)

Semelhante a Caca

Semelhante a Caca (20)

Último

Último (9)

Caca