Desenvolvimento de Algoritmos de Controlo para Locomoção de um Robot Humanóide Relatório Final de Projecto Milton Ruas da Silva Nº21824 Orientação: Prof. Dr. Filipe Silva (DETI-IEETA) Prof. Dr. Vítor Santos (DEM-TEMA) Universidade de Aveiro Departamento de Electrónica, Telecomunicações e Informática, IEETA Licenciatura em Engenharia Electrónica e Telecomunicações Julho de 2006

Índice

1.INTRODUÇÃO	5

1.1.ENQUADRAMENTO DO PROJECTO	7

1.2.OBJECTIVOS DO TRABALHO	8

1.3.DESCRIÇÃO DA PLATAFORMA HUMANÓIDE	9

2.ARQUITECTURA DAS COMUNICAÇÕES	11

2.1.ARQUITECTURA DO SISTEMA	13

2.1.1.Protocolos de Comunicação	14

2.2.COMUNICAÇÃO RS-232	15

2.2.1.Protocolo	15

2.2.2.Unidade Principal	19

2.2.2.1.Configuração da Unidade Principal	19

2.2.2.1.Device Drivers da Unidade Principal	20

2.2.3.Unidade Master	25

2.2.3.1.Configuração do Master	25

2.2.3.2.Funcionamento da USART no Master	26

2.2.3.3.Base de Dados Global do Sistema	28

2.3.COMUNICAÇÃO CAN	29

2.3.1.Protocolo CAN	30

2.3.2.Configuração do CAN	33

2.3.2.1.Inicializações	33

2.3.2.2.Troca de Pacotes via CAN	37

2.3.3.Funcionamento do CAN na unidade Master	38

2.3.4.Funcionamento do CAN nas unidades Slave	40

2.3.4.1.Base de Dados Local	40

2.3.4.2.Transmissão e Recepção de Mensagens	41

2.4.ORGANIZAÇÃO DO SOFTWARE	42

2.4.1.Unidade Master	42

2.4.2.Unidade Slave	45

2.5.RESOLUÇÃO DE PROBLEMAS	47

2.6.CONCLUSÕES	48

3.SISTEMA DE CONTROLO DE BAIXO-NÍVEL	49

3.1.CONTROLO DA PLATAFORMA HUMANÓIDE	51

3.1.1.A Unidade de Controlo Local	52

3.2.ACTUADORES: OS SERVOMOTORES	55

3.2.1.Setup Experimental	59

3.2.2.Actuação sobre o Servomotor	60

3.2.3.Leitura Sensorial do Servomotor	63

3.2.3.1.Medição de Corrente	64

3.2.3.2.Medição da Posição	66

3.2.3.3.Organização das interrupções de medição sensorial	67

3.3.ESTUDO DO SERVOMOTOR EM MALHA ABERTA	71

3.3.1.Resposta ao Degrau em Malha Aberta	72

3.3.2.Controlo de Velocidade	73

3.3.2.1.Respostas em malha aberta	75

3.4.ESTUDO DO SERVOMOTOR EM MALHA FECHADA	77

3.4.1.O Controlador	77

3.4.2.Controlo Integral (I)	79

3.4.3.Controlo Proporcional+Integral (PI)	81

3.4.4.Controlo Integral+Derivativo (ID)	82

3.4.5.Controlo Proporcional+Integral+Derivativo (PID)	83

3.4.6.Algumas Notas	85

3.5.MONITORIZAÇÃO DE CORRENTE	87

3.5.1.Estudo Estático da Corrente	87

3.5.2.Estudo Dinâmico em Malha Aberta	87

3.5.3.Estudo Dinâmico em Malha Fechada	91

3.6.APLICAÇÃO DOS ALGORITMOS NO ROBOT HUMANÓIDE	93

3.6.1.Movimento de Flexão em Malha Aberta de uma Perna	93

3.6.1.1.Na Ausência de Carga:	93

3.6.1.2.Na presença de uma Carga de cerca de 2Kg:	95

3.6.2.Movimento de Flexão em Malha Fechada de uma Perna	97

3.6.3.Movimento das duas Pernas	98

3.7.ORGANIZAÇÃO DO SOFTWARE	100

3.8.RESOLUÇÃO DE ANOMALIAS	106

3.9.CONCLUSÕES	107

4.CONTROLO DAS FORÇAS DE REACÇÃO	109

4.1.INTRODUÇÃO	111

4.2.ESTRUTURA DOS PÉS	112

4.2.1.Sensores de Força: os Extensómetros	112

4.2.2.O Pé como Elemento Sensitivo a Forças Externas	112

4.3.MEDIÇÃO DAS FORÇAS DE REACÇÃO	114

4.3.1.Interface entre os Extensómetros e o Microcontrolador	114

4.3.1.1.Versão original do circuito de Acondicionamento de Sinal	114

4.3.1.2.Versão melhorada do Circuito de Acondicionamento de Sinal	115

4.3.1.3.Versão Futura do Circuito de Acondicionamento de Sinal	118

4.3.2.Resultados Experimentais	119

4.3.2.1.Setup Experimental	119

4.3.3.Amostragem dos Sensores	122

4.3.4.Notas Importantes	124

4.4.MEDIÇÃO DO CENTRO DE PRESSÃO	124

4.4.1.Representação do Centro de Pressão	125

4.4.2.Cálculo do Centro de Pressão	125

4.5.CONTROLO DE EQUILÍBRIO	127

4.5.1.Estrutura do Controlador	127

4.5.2.Controlo Proporcional	128

4.5.3.Controlo através da Matriz Jacobiana	128

4.5.3.1.Cálculo da Matriz Jacobiana	129

4.5.3.2.O Controlador utilizando a Matriz Jacobiana	131

4.6.RESULTADOS EXPERIMENTAIS	133

4.6.1.Variação do Declive do Plano de Suporte	133

4.6.1.1.Variação da inclinação do plano segundo o eixo xx	134

4.6.1.2.Variação da inclinação do plano segundo o eixo yy	135

4.6.1.3.Variação da inclinação do plano simultaneamente segundo o eixo xx e yy	136

4.6.2.Pressão isolada sobre os Sensores de Força	137

4.6.2.1.Pressão no Ponto Intermédio entre cada par de Sensores	138

4.6.2.2.Pressão isolada sobre cada Sensor	139

4.6.3.Introdução de Perturbações Externas	140

4.6.4.Experiências Adicionais	142

4.7.ORGANIZAÇÃO DO SOFTWARE	144

4.8.CONCLUSÕES	146

5.NOTAS FINAIS	147

5.1.AGRADECIMENTOS	149

5.2.BIBLIOGRAFIA	149

INTRODUÇÃO

Resumo:

Neste trabalho pretende-se desenvolver e implementar um conjunto de estratégias e algoritmos de controlo para a locomoção de um robot humanóide de baixo custo, bem como a revisão de toda a arquitectura de comunicações de modo a permitir a troca eficiência de informação entre todos os nós.

Este robot compreende 22 graus de liberdade com o peso e as dimensões adequadas à participação no concurso Robocup mundial, modalidade humanóide. Espera-se que os frutos deste trabalho contribuam para tal ambição.

A concepção de um robot Humanóide constitui um dos maiores desafios na área da robótica: construir um ser artificial antropomórfico semelhante ao homem é um sonho inato do nosso engenho, e não é para menos, pois o ser humano é a forma de vida mais complexa existente à face da Terra. O século XX encheu a nossa imaginação com livros e filmes que demonstram esse sonho do ser artificial capaz de, além de ajudar a desempenhar tarefas, aprender coisas por si mesmo, interagir connosco, expressar emoções, possuir uma consciência própria... tudo características que por enquanto ainda consideramos como puramente humanas. Marcas como a Honda, a Sony ou a Fujitsu já deram os primeiros passos no desenvolvimento de máquinas que imitam os comportamentos físicos dos seres humanos, como caminhar, dançar ou pegar objectos. Outros passos também já foram dados no que respeita ao processamento de visão, de som, com o objectivo de realizar tarefas ou simplesmente de interagir com o ser humano.

Fig. 3: KHR 3 (Hubo Lab). Fig. 2: Asimo da Honda. Fig. 1: QRIO da Sony.

ENQUADRAMENTO DO PROJECTO

Muitos outros grupos de investigação iniciaram a construção de robôs de baixo custo no sentido de realizarem investigação em áreas tão diversas como o controlo, a percepção, a navegação, o comportamento ou a cooperação. Este foi, também, o móbil principal que levou um grupo, resultante da cooperação do D.E.M. com o D.E.T.I. da Universidade de Aveiro, a encetar a tarefa de construção de uma tal plataforma. O estado actual de desenvolvimento perspectiva a abordagem de algoritmos eficientes ao nível do controlo, planeamento e percepção.

A motivação para os projectos propostos na área da robótica humanóide é encontrada em diversas vertentes, das quais se destacam as seguintes:

A aposta nos robôs humanóides como a via mais promissora para chegar a sistemas de elevada mobilidade, versatilidade de operação e facilidade de interacção com os humanos;

A criação de uma plataforma de investigação de grande valor pedagógico face aos enormes desafios científicos e técnicos, à diversidade de problemas, ferramentas e níveis de integração;

A promoção do envolvimento de um grupo de estudantes da UA em competições robóticas internacionais. Por exemplo, o ROBOCUP e o FIRA são duas organizações internacionais que realizam anualmente competições na classe dos humanóides.

OBJECTIVOS DO TRABALHO

Neste trabalho pretende-se estudar, desenvolver e implementar um conjunto de estratégias e algoritmos simples de controlo para o robô humanóide. O projecto pode ser decomposto pelas seguintes fases:

Análise do estado actual de desenvolvimento do sistema e compreensão dos problemas tecnológicos envolvidos:

Avaliação do desempenho ao nível do controlo, planeamento e percepção tendo em conta os requisitos físicos e funcionais colocados pela participação no ROBOCUP.

Introduzir alguns melhoramentos possíveis ao sistema existente.

Melhoramento dos algoritmos de comunicação entre os diversos nós da arquitectura, de modo a optimizar a troca de informação relativa a actuação e leituras sensoriais;

Melhoramento dos algoritmos de actuação e leitura sensorial dos actuadores;

Estudo da melhor estratégia de controlo a adoptar nas juntas de modo a realizar comportamentos relativos à locomoção: o estudo do comportamento de um servomotor foi efectuado de modo a analisar qual a melhor estratégia de controlo;

Posteriormente testou-se a estratégia delineada efectuando movimentos com os membros inferiores da estrutura humanóide (pernas).

Contemplou-se comportamentos especiais relativos ao equilíbrio estático e dinâmico: como por exemplo equilibrar uma perna na vertical na variação do plano de suporte.

Por isso, o relatório está organizado em dois capítulos principais:

Capítulo 1 – Implementação dos algoritmos de troca de informação entre os diversos módulos;

Capítulo 2 – Implementação dos algoritmos de actuação directa e leitura sensorial dos servomotores e estudo da resposta dos actuadores introduzindo controladores externos para a compensação.

DESCRIÇÃO DA PLATAFORMA HUMANÓIDE

A plataforma humanóide possui um conjunto de 22 graus de liberdade, distribuídos da seguinte forma:

2 em cada pé (2x2);

1 em cada joelho (1x2);

3 em cada anca (3x2);

2 no tronco (2x1);

3 em cada braço (3x2);

2 no suporte da câmara (cabeça) (2x1).

A estrutura é constituída essencialmente por alumínio e aço nos eixos e outros pequenos componentes, pesando um total de 6 Kg com as baterias incluídas, e medindo cerca de 60 cm. Estes valores foram estabelecidos de acordo com as regras impostas pelo RoboCup, baseando-se no pressuposto de que para valores superiores estes, o uso de servomotores de baixo custo poderá tornar-se inviável dada a impossibilidade de conciliar binários de motores e pesos dos equipamentos e acessórios como as baterias.

Por razões de estética e de acomodação de componentes, foi adoptada uma estrutura em forma de exoesqueleto (carapaça) dotando assim o sistema de módulos ocos onde são alojados os motores, sensores, cablagens, placas de controlo, etc (Fig. 4).

Fig. 4 - Modelo 3D do robot e implementação actual.

Preocupações com a autonomia energética do sistema, exigiram a escolha de baterias de elevada capacidade de corrente, até porque é necessário alimentar 22 motores de binário apreciável (embora uns mais do que outros). Tendo em conta esses aspectos utilizaram-se duas baterias de 7.4V ligadas em paralelo com uma capacidade máxima de 9600mAh.

No que respeita ao controlo, foram assumidas, desde logo, as vantagens de uma arquitectura distribuída e modular baseada num bus CAN responsável por permitir a troca de informação entre as diversas unidades de controlo a partir de uma unidade mestre que faz a gestão da rede e que está directamente ligada a uma unidade primária de decisão que, neste momento, é um computador vulgar. Posteriormente substituir-se-á o computador por uma embedded motherboard do tipo PC-104 ou nano ITX com as mesmas funcionalidades que um PC, no que respeita ao necessário, com as vantagens de dimensões reduzidas e de baixo custo.

Neste momento, a plataforma é constituída por 9 unidades de controlo, 8 de controlo local dos actuadores e sensores, e um de controlo de tráfego na rede CAN. As unidades de controlo local estão distribuídas de forma a agrupar conjuntos de três actuadores relativos a um determinado membro, como é o caso das pernas ou dos braços (Fig. 5). Com uma arquitectura deste género, pretende-se pretende-se que o hardware que constitui estes módulos seja idêntico com um software adaptado a cada um deles. Implementando esta estratégia consegue-se um grau de fiabilidade superior, uma vez que os módulos são independentes permitindo que as anomalias sejam mais facilmente detectadas e corrigidas. Os módulos podem ser trocados facilmente e adaptados à tarefa necessária, pois bastará programar o algoritmo específico à tarefa.

Em resumo, apresentam-se as vantagens da arquitectura distribuída:

Sistemas fiáveis (operação independente)

Sistemas de controlo mais simples

Mais fácil detecção de anomalias

Actualização fácil de firmware

Fig. 5 - Arquitectura distribuída da plataforma.

Na percepção destacam-se os sensores proprioceptivos e alguns inerciais:

Potenciómetros de medição da posição das juntas;

Sensores de força para medição das forças de reacção dos pés;

Inclinómetros e giroscópios para medição da aceleração gravítica e da velocidade angular respectivamente serão incorporados num futuro próximo.

Os sensores do tipo 2 e 3 serão designados por sensores especiais dada a sua natureza específica e podem ser ligados um conjunto máximo de quatro sensores a cada unidade de controlo local. Tal compromisso deve-se a questões de organização da informação trocada entre as diversas unidades de controlo (ver secção 2.2.1).

ARQUITECTURA DAS COMUNICAÇÕES

Resumo:

Este capítulo descreve a organização distribuída da plataforma humanóide e como é realizada a comunicação entre os diversos nós de modo a poder trocar informação sensorial e de actuação sem o risco de colisões num barramento de natureza partilhada.

ARQUITECTURA DO SISTEMA

O sistema de controlo implementado é baseado numa configuração master/slave, e é constituído por três tipos de unidades ligadas em rede:

A unidade central de controlo é responsável pela gestão global dos procedimentos, efectuando o cálculo das configurações que as juntas tem de adoptar em função dos valores dos sensores.

A unidade Master (mestre) tem como principal tarefa servir de interface entre a unidade principal de controlo e as unidades slave;

As unidades Slave (escravo), cujas principais funções são a geração da onda de pulso modulado (PWM) de controlo dos servomotores e a aquisição dos sinais dos diversos sensores da plataforma.

Entre os diversos nós são utilizados como meios de comunicação:

Linha série ponto-a-ponto, baseada na norma RS-232, entre a unidade central e a unidade Master: acesso assíncrono byte a byte a um baudrate de 115200 bps.

CAN (Controller Area Network) entre a unidade master e as unidades slave: é utilizada a versão fullCAN 2.0A a uma taxa de transmissão/recepção de 833.3 Kbps.

A unidade central de controlo ainda não está completamente definida, permanecendo em aberto soluções baseadas em PDA, placas de controlo genéricas (como as baseadas no padrão PC104) ou placas de controlo dedicadas (Fig. 6). Por enquanto é utilizado um PC externo com recurso ao software MatLab para enviar e receber dados por uma linha série para o controlador master.

Para as unidades de controlo local (master/slave), a escolha recaiu sobre os microcontroladores PIC da série 18F da Microchip – PIC18F258 – por possuírem diversos periféricos e interfaces para redes de comunicações, incluindo o CAN (Fig. 8).

Fig. 6: Exemplo de uma board PC-104.	Fig. 7: Placa de controlo Master/Slave.	Fig. 8: Rede completa de Microcontroladores.

Até ao momento, a rede implementada é constituída por uma placa master, pelo qual designaremos por MCU (Master Control Unit), que efectua a interface entre a unidade principal e as unidades slave, e oito placas slave, designadas por SCU (Slave Control Unit), que efectuarão o controlo local até três actuadores através da geração de uma onda de pulso modulado em largura (PWM), e a aquisição de até 16 sinais analógicos usando um multiplexer (Fig. 7).

A organização enunciada na Fig. 5 tem como objectivo agrupar as juntas que estão directamente relacionadas, como é o caso das juntas do tornozelo e do joelho que possuem um controlador dedicado, que, por aquisição dos sinais analógicos dos sensores de força instalados nos pés, pode controlar o equilíbrio por compensação em malha fechada. Numa evolução futura direccionada para a adaptação à irregularidade do solo, estas juntas poderão corrigir a sua posição de forma reactiva para que a projecção do centro de massa do robot não se situe fora da área de apoio dos pés. Obter-se-á assim um controlo localizado independente do resto do sistema sem que haja necessidade permanente de interagir com a unidade central de controlo.

Os sinais analógicos adquiridos actualmente, para além dos sensores de força, são provenientes dos potenciómetros de posição de cada actuador. Estes valores são convertidos e registados localmente e depois enviados via CAN para o controlador Master. Os Slaves estão preparados também para receber mensagens via CAN: estas mensagens consistem basicamente nas posições finais que os actuadores têm de tomar, a velocidade a que têm que se mover e os parâmetros de compensação para os algoritmos de controlo internos.

O controlador master tem a tarefa de receber a informação enviada pelos slaves via CAN e registá-la para que esteja disponível para ser enviada para a unidade central de controlo quando solicitada. Este controlador mantém, por isso uma representação do estado actual das juntas (actuadores e sensores) que disponibilizará ao controlo central sempre que este o pedir. O processo é bidireccional e o controlador master também recebe as ordens da unidade central e despacha para o slave respectivo.

Tabela 1: Características do Hardware.

Unidade Central de Controlo	Computador com porta série RS-232 Software de suporte: MatLab 7.01 (R14) Device Drivers de comunicação série: mini-toolbox cport v1.3
Unidades de controlo local Master/Slave	PIC18F258 da Microchip Memória de programa: 2 MB Memória de dados: 4 KB Velocidade de processamento: 10 MIPS (fosc=40MHz com a PLL activa) Instruções de 16 bits e datapath de 8 bits Definição de prioridades nas interrupções. Diversos periféricos: timers, módulos CCP, interfaces para redes de comunicação, ADC, etc…

Protocolos de Comunicação

Desenvolveram-se dois protocolos de comunicação, nomeadamente para…

a linha série RS-232 entre o PC e a unidade Master

e para o CAN entre a unidade Master e os Slaves,

…de modo a poder trocar dados sensoriais e de actuação entre o PC e as unidades Slave.

Entre os dados sensoriais podem-se enumerar (para um SCU):

Posição dos três servomotores (em graus);

Velocidade correspondente (em graus/s);

Corrente consumida por cada servomotor;

Valores dos sensores de força de cada pé (quatro sensores por pé);

Saída dos Giroscópios (em graus/s);

Saída dos inclinómetros.

Quanto aos dados de actuação:

Posição final a atingir por cada servomotor;

Velocidade média para a realização do movimento;

Parâmetros de compensação para o controlo local (KP, KI e KD).

Considera-se que o controlo de actuação deve ser feito de forma isolada a cada uma das três juntas, e por isso as diversas juntas podem realizar movimentos com diferentes velocidades e diferentes parâmetros de compensação. Tal é útil no último caso, pois cada junta pode estar sujeita a diferentes esforços, e por isso, é rentável aplicar diferentes parâmetros de controlo a cada uma.

COMUNICAÇÃO RS-232

Protocolo

A comunicação RS-232 entre o PC e a unidade Master é efectuada assincronamente e é orientada ao byte (start bit+8 bits+stop bit), ou seja, é transmitido um byte de dados em cada transmissão/recepção. Pretende-se que numa única mensagem esteja contida toda a informação relativa a um parâmetro a ler/actuar das três juntas de um SCU, o que implica que cada mensagem seja constituída por vários bytes. Como por exemplo, para ordenar o SCU X a colocação das juntas nas posições A, B e C, são necessários no mínimo quatro bytes: três para as três posições A, B e C; e um indicando a identificação do SCU.

Data (8 bits)
Start bit	Stop bit

Estrutura de um pacote USART (transmissão/recepção de um byte)

Comandos PC→Master:

As mensagens no sentido PC→master são constituídas por cinco bytes. O primeiro byte sinalizará a mensagem como sendo um comando de solicitação à unidade master (MESSAGE_REQ=0xFF); o segundo byte conterá um código (opcode) indicativo da operação a realizar, do SCU alvo e de parâmetros adicionais; e os últimos três bytes conterão parâmetros a atribuir às três juntas no caso de um comando de actuação.

byte 1	byte 2	byte 3	byte 4	byte 5
MessageType=0xFF	OpCode	Joint 1	Joint 2	Joint 3

Mensagem USART PC→Master de actuação.

byte 1	byte 2	byte 3	byte 4	byte 5
MessageType=0xFF	OpCode	0	0	0

Mensagem USART PC→Master de leitura sensorial.

Tabela 2: Campos das mensagens PC→Master via USART

Pacotes	Função:	Valores possíveis:
Message Type	Indica o tipo da mensagem	MESSAGE_REQ (0xFF): Pedido de actuação/consulta; MESSAGE_ERROR (0xFE)*: Pedido de retransmissão da última mensagem enviada pelo Master; MESSAGE_TEST (0xFA)*: Pedido de transmissão (por parte do Master) de uma mensagem de teste. A mensagem de resposta será da forma – FA F9 F8 F7 F6 F5 (hex).
OpCode	Código indicando o que é solicitado e a quem se destina (apenas útil para uma mensagem MESSAGE_REQ).	(Ver Tabela 3)
Joint 1/2/3	No caso de uma mensagem MESSAGE_REQ de actuação sobre as juntas, estes três bytes estabelecem valores a serem atingidos pelos actuadores.	Mensagem de actuação: Posição final/velocidade média a atribuir a cada junta de um determinado SCU. Mensagem de leitura sensorial: campos nulos.

(*) Nestas condições apenas é enviado o primeiro byte (Message Type), sem a necessidade dos restantes.

bit 7	6	5	4	3	2	1	bit 0
Operation	SCU ID	Parameter

Byte OpCode

Tabela 3: Campos do pacote OpCode nas mensagens PC→Master via USART.

SCU id	Operation	Parameter
SCU alvo relativo à operação (endereçável a 15 SCU's)	OP_APPLY_JOINT (0b00) Mensagem de actuação sobre as três juntas do SCU alvo (SCU id). PARAM_POSITION (0b00) Posição (em graus) a ser atingida. PARAM_VELOCITY (0b01) Velocidade média do movimento a efectuar. PARAM_CURRENT (0b10) Parâmetro sem significado do ponto de vista de actuação! PARAM_SPECIAL (0b11) Activação/desactivação do PWM aplicado aos motores e da filtragem dos valores sensoriais do servo. OP_APPLY_CONTROL (0b01) Mensagem de actuação sobre as três juntas do SCU alvo com a definição dos parâmetros do controlador PID. PARAM_KI (0b00) Parâmetro de controlo integral. PARAM_KP (0b01) Parâmetro de controlo proporcional. PARAM_KD (0b10) Parâmetro de controlo derivativo. PARAM_CONTROLON (0b11) Tipo de controlo a aplicar na junta. OP_READ_SENSORS (0b10) Mensagem de leitura dos sensores adicionais (sensores de força dos pés, giroscópio e inclinómetro). PARAM_POSITION (0b00) Posição actual de cada junta. PARAM_VELOCITY (0b01) Velocidade média de cada junta. PARAM_CURRENT (0b10) Corrente drenada por cada servo. PARAM_SPECIAL (0b11) Saída dos sensores especiais. OP_READ_EXTBUFF (0b11) Leitura do buffer externo do Master. Por predefinição corresponderá ao status do barramento CAN. ———

Tabela 4: Tipo de controlo a seleccionar no campo PARAM_CONTROLON.

Tipo de Controlo sobre as juntas	Designação	PARAM_CONTROLON
Controlo em malha aberta	NO_CONTROL	0b00
Controlo de posição	LOCOMOTION_CONTROL	0b01
Controlo das forças de reacção	REACTION_CONTROL	0b10
Controlo de equilíbrio no tronco	BALANCE_CONTROL	0b11

De notar, que a actuação é feita directamente às três juntas numa única mensagem, mas com a desvantagem de apenas se poder actuar num parâmetro cada vez (posição final, velocidade média ou um parâmetro do controlador).

Respostas Master→PC:

Na resposta, o Master responde com uma mensagem de 6 bytes, cuja estrutura é a seguinte:

Message Type: possui o valor MESSAGE_SUCESS (0xFB);

OpCode: opcode utilizado pela mensagem original PC→Master;

Data 1-4: dados sensoriais no caso de um pedido de consulta sensorial.

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6
0xFB	OpCode	Data 1	Data 2	Data 3	Data 4

Formato geral de uma mensagem de resposta Master→PC.

Esta estrutura é geral e pode assumir várias formas de acordo com a operação envolvida:

No caso de uma operação de actuação (OP_APPLY_*), os bytes 2-5 possuem o mesmo valor que a mensagem original com o último byte nulo;

Numa leitura sensorial (OP_READ_SENSORS), o byte OpCode é igual à da mensagem original com os bytes sucessivos contendo a informação sensorial pedida. Se os dados sensoriais concernem aos servo motores, três bytes são utilizados para conter a informação relativa a cada um deles, e o último é utilizado para transmitir informação de status do SCU em causa. Se concernem aos sensores especiais, são utilizados todos os quatro bytes ou para conter a informação de um dos conjuntos dos sensores de força (de um pé) ou para o conjunto giroscópio+inclinómetro.

Se for solicitada a leitura do buffer externo do master (OP_READ_EXTBUFF), o status do barramento CAN é devolvido.

O formato das mensagens de resposta descritos apresentam-se de seguida:

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6
0xFB	==	==	==	==	0

Mensagem de actuação aplicada com sucesso

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6
0xFB	==	Joint 1	Joint 2	Joint 3	SCU status

Mensagem de leitura sensorial das juntas

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6
0xFB	==	Data 1	Data 2	Data 3	Data 4

Mensagem de leitura dos sensores especiais

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6
0xFB	==	Error Code	# TX errors	# RX errors	0

Mensagem de leitura do buffer externo do Master (status do barramento CAN)

De notar, que na leitura sensorial das juntas, na mesma mensagem é transportado os valores dos três servos. No entanto, apenas um parâmetro pode ser lido – ou posição, ou velocidade média ou corrente.

Quanto à leitura dos sensores especiais, note também, a limitação de quatro valores, daí a limitação imposta anteriormente de apenas usar quatro linhas analógicas dedicadas a este género de sensores: ou o conjunto dos sensores de força, ou conjunto giroscópio+inclinómetro.

No entanto, podem ocorrer situações anómalas na recepção do comando por parte do Master, podendo-se discernir duas situações possíveis:

Mensagem de pedido inválido: os parâmetros solicitados pelo PC não fazem sentido (ex.: SCU alvo não existente). Neste caso uma mensagem de Message Type de código MESSAGE_INVREQ (0xFC), com todos os restantes bytes iguais à da mensagem original, é retornada ao PC.

Mensagem de erro: houve um erro na recepção da mensagem proveniente do PC. Uma mensagem com todos os 6 bytes de código MESSAGE_ERROR (0xFE) é retornada ao PC.

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6
0xFC	==	==	==	==	0

Mensagem sinalizadora de um pedido inválido.

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6
0xFE	0xFE	0xFE	0xFE	0xFE	0xFE

Mensagem sinalizadora de um erro na comunicação PC→Master.

Tabela 5: Tipos de mensagens USART (primeiro byte de cada frame).

Tipo de Mensagem	Designação	Código
Mensagem de solicitação	MESSAGE_REQ	0xFF
Mensagem de erro	MESSAGE_ERROR	0xFE
Mensagem de aviso	MESSAGE_WARNING	0xFD
Mensagem indicadora de pedido inválido	MESSAGE_INVREQ	0xFC
Mensagem indicadora de sucesso do pedido efectuado	MESSAGE_SUCESS	0xFB
Mensagem de teste	MESSAGE_TEST	0xFA

Unidade Principal

Configuração da Unidade Principal

Como configurações gerais optou-se por efectuar as transacções à velocidade máxima permitida sem a aplicação de controlo de comunicações. Elas são:

Baudrate: 115200 bps

Tamanho da palavra de dados: 8 bits

Número de stop bits: 1

Bit de paridade: desactivado

Controlo de comunicações por handshaking: desactivado

Utilizou-se um computador Pentium com porta série RS-232 embutida, com o sistema operativo Microsoft® Windows XP, como unidade principal, para comunicar com a unidade master. O software utilizado foi o MatLab 7.0 através da mini-toolbox cport v1.3 que oferece device-drivers para troca directa por RS-232 tanto de caracteres como de strings e valores numéricos inteiros.

Para inicializar as comunicações através do cport é necessário seguir as seguintes instruções:

Abrir as comunicações especificando a porta série a usar (COM?) guardando o handler da linha aberta.

Porta utilizada: COM1

handler=cportopen('com1')

Se handler=0, a ligação falhou!

Configurar a linha especificando as seguintes características:

Campo	Valor
Baudrate	115200 bps
Tamanho do byte	8 bits
Descarte dos bytes nulos	desactivado
Controlo de fluxo pela linha DTR	desactivado
Controlo de fluxo pela linha RTS	desactivado
Término das operações de leitura/escrita na ocorrência de um erro	activado
Caracter a usar no caso de um erro de paridade	nenhum
Tempo de timeout entre dois caracteres consecutivos	1 ms

Tabela 6: Configurações gerais do cport.

state=cportconfig(handler,	'BaudRate',115200,	...

'ByteSize',8,	...

'fNull','OFF',	...

'fDtrControl','OFF',	...

'fRtsControl','OFF',	...

'fAbortOnError','ON',	...

'ErrorChar',-1,	...

'ReadIntervalTimeout',1,	...

'ReadTotalTimeoutMultiplier',5,	...

'ReadTotalTimeoutConstant',100,	...

'WriteTotalTimeoutMultiplier',1000,	...

'WriteTotalTimeoutConstant',1000);

Para efeitos de debugging é útil usar um terminal RS-232. Recomenda-se a utilização do terminal R.E.Smith por permitir a troca de bytes de qualquer código ASCII (caracter ou não) e a visualização das saídas/entradas em formato hexadecimal.

Em caso de uso de um terminal as seguintes opções são suficientes:

Campo	Valor
Porta	COM1
Baudrate	115200
Bits de dados	8
Paridade	Nenhum
Bits de paragem	1
Controlo de fluxo	Nenhum

Tabela 7: Configurações de um terminal RS-232 (No caso do R.E.Smith, usar COM1, 115200, N-8-1).

No caso de haver algum problema durante o funcionamento é necessário reinicializar as comunicações. Para isso basta fazer...

stat=cportreset(handler)

Para terminar as comunicações é só usar o comando cportclose:

stat=cportclose(handler)

Caso haja algum problema na configuração do cport, pode obter as definições correctas através do seguinte procedimento:

Fechar todos os programas e reiniciar o computador;

Ligar as comunicações através do terminal R.E.Smith seguindo as opções da Tabela 7;

Verificar a conectividade e de seguida desligar as comunicações;

Abrir o MatLab e ligar a porta série através dos comandos do cport definindo apenas o baudrate;

Anotar as configurações tomadas fazendo stat=cportconfig(handler).

Redefinir as configurações do cport com estes dados.

Sempre que um programa tenha utilizado a porta série antes, as configurações a adoptar pelo cport serão as mesmas que desse programa. A partir daqui é só configurar a porta série com estes dados sempre que uma ligação é estabelecida.

Device Drivers da Unidade Principal

Para automatizar o processo de leitura/escrita dos dados sensoriais/actuadores, device drivers foram escritos na forma de funções em MatLab. Elas são:

Ficheiro	Função	Descrição
initcom.m	[H,state]=initcom(gate,rate)	Criação de uma nova ligação.
killcom.m	stat=killcom(H)	Término da ligação.
calibcom.m	calibcom(H)	Pedido de envio de uma sequência de teste.
readcanstat.m	[array,...]=readcanstat(H)	Consulta do estado do barramento CAN.
readjoint.m	[servos,...]=readjoint(H,scu_id,param)	Leitura das posições das juntas de um SCU.
readspecial.m	[special,...]=readspecial(H,scu_id)	Leitura dos sensores especiais.
applyjoint.m	[...]=applyjoint(H,scu_id,param,servos)	Actuação nas juntas de um determinado SCU.
applycontrol.m	[...]=applycontrol(H,scu_id,param,servos)	Actualização dos parâmetros PID de uma determinado SCU.

Tabela 8: Lista de device drivers da unidade principal.

initcom Estabelecimento de uma nova ligação via RS-232 [handler,state]=initcom(gate,rate) Entradas: gate -> Porta a utilizar (1,2,...) rate -> baudrate a definir Saídas: handler -> ID da linha de comunicações state -> Configurações da linha

killcom Término de uma ligação RS-232 existente. stat=killcom(handler) Entradas: handler -> ID da linha série Saídas: stat -> retorna 1 em caso de sucesso

calibcom Pedido de envio de uma sequência de teste por parte do master. calibcom(handler) Entradas: handler -> ID da linha série.

readcanstat Leitura do estado do barramento CAN entre slaves. [array,state,rx,error,errorstr,tries]=readcanstat(H) Entradas: H => Handler para comunicar com o Master Saídas: array => [estado de erro, #erros de transmissão, #erros de recepção] state => Bits de estado dos servos rx => Mensagem de baixo nível recebida error => Código de erro, se existente errorstr => String descritiva do erro tries => Número de tentativas para efectuar a comunicação

readjoint Leitura de um parametro sensorial dos servos de um SCU [servos,state,rx,error,errorstr,tries]=readjoint(H,scu_id,param) Entradas: H => Handler para comunicar com o Master scu_id => Identificador do SCU alvo param => Parametro a ler (0:posição, 1:velocidade, 2:corrente) Saídas: servos => Parametro de saída [servo1,servo2,servo3] state => Bits de estado dos servos rx => Mensagem de baixo nível recebida error => Código de erro, se existente errorstr => String descritiva do erro tries => Número de tentativas para efectuar a comunicação

readspecial Leitura dos sensores especiais (sensores de força ou giroscópio+inclinómetro). [special,rx,error,errorstr,tries]=readspecial(H,scu_id) Entradas: H => Handler das comunicações com o Master scu_id => Identificador do SCU alvo Saídas: special => Valores dos sensores especiais rx => Mensagem de baixo nível recebida error => Código de erro, se existente errorstr => String descritiva do erro tries => Número de tentativas para efectuar a comunicação

applyjoint Aplicação de uma ordem de posição ou velocidade a cada motor de uma junta. [rx,error,errorstr,tries]=applyjoint(H,scu_id,param,servos) Entradas: H => Handler para comunicar com o Master scu_id => Identificador do SCU alvo param => Parametro a aplicar (0:posição, 1:velocidade) servos => Dados a aplicar [servo1,servo2,servo3] Saídas: rx => Mensagem de baixo nível recebida error => Código de erro, se existente errorstr => String descritiva do erro tries => Número de tentativas para efectuar a comunicação

applycontrol Ajuste dos parametros do controlador PID para o posicionamento do servo [rx,error,errorstr,tries]=applycontrol(H,scu_id,param,servos) Entradas: H => Handler para comunicar com o Master scu_id => Identificador do SCU alvo param => Parametro a modificar (0:KI, 1:KP, 2:KD, 3:PID on) servos => Dados a aplicar [servo1,servo2,servo3] Saídas: rx => Mensagem de baixo nível recebida error => Código de erro, se existente errorstr => String descritiva do erro tries => Número de tentativas para efectuar a comunicação

Todos os device drivers, tanto os de consulta sensorial como os de actuação, seguem um algoritmo semelhante ao enunciado na Fig. 9.

Fig. 9: Algoritmo geral dos device drivers da unidade principal.

A construção da mensagem baseia-se na definição de um array de bytes, cuja estrutura segue o formato de um comando PC→Master (secção 2.2.1).

O envio da mensagem, constituído pelos vários bytes, é feita segundo o algoritmo descrito na Fig. 10. É enviado um byte de cada vez para a porta série, e caso ocorra algum erro são reinicializadas as comunicações voltando de seguida a tentar reenviar o mesmo byte. O processo só termina quando todos os bytes forem enviados com sucesso.

A recepção da mensagem de resposta está descrita na Fig. 11 e é executada logo após o envio do comando. A mini-toolbox cport oferece-nos já uma função que permite ler imediatamente um array de 6 bytes da porta série indicando se a recepção teve sucesso em cada um deles. Caso tal não aconteça, as comunicações são reinicializadas e o reenvio do comando é repetido com a consequente leitura da resposta.

Fig. 10: Algoritmo de envio de uma mensagem para o Master.

Fig. 11: Algoritmo para recepção da mensagem de resposta do Master.

Unidade Master

Configuração do Master

Para configurar a unidade microcontroladora a operar com a linha RS-232 é necessário efectuar um conjunto de passos que serão descritos a seguir. Primeiramente é necessário configurar os pinos RX (recepção) e TX (transmissão) como entrada e saída respectivamente:

TRISC=(TRISC | 0x80) & 0xBF;

De seguida é necessário configurar o baudrate da comunicação através do registo SPBRG. Para a frequência de CPU FCPU=10MHz e para um baudrate desejado de 115200, segundo a fórmula...

... o registo SPBRG deve assumir o valor de 21.

Configurar o modo de funcionamento de transmissão através do registo TXSTA e de recepção pelo registo RCSTA.

Registo TXSTA

Campo	Parâmetro	Valor	Descrição
CSRC	Clock Source Select bit	X	——
TX9	9-bit Transmit Enable bit	0	Selects 8-bit transmission
TXEN	Transmit Enable bit	1	Transmit enabled
SYNC	USART Mode Select bit	0	Asynchronous mode
BRGH	High Baud Rate Select bit	1	High speed
TRMT	Transmit Shift Register Status bit	—	(Read only)
TX9D	9th bit of Transmit Data	X	——

Tabela 9: Configuração do registo TXSTA.

Registo RCSTA

Campo	Parâmetro	Valor	Descrição
SPEN	Serial Port Enable bit	1	Serial port enabled (configures RX/DT and TX/CK pins as serial port pins)
RX9	9-bit Receive Enable bit	0	Selects 8-bit reception
SREN	Single Receive Enable bit	X	——
CREN	Continuous Receive Enable bit	1	Enables continuous receive
ADDEN	Address Detect Enable bit	X	——
FERR	Framing Error bit	—	(Read only)
OERR	Overrun Error bit	—	(Read only)
RX9D	9th bit of Received Data	—	(Read only)

Tabela 10: Configuração do registo RCSTA.

Finalmente é necessário activar/desactivar as interrupções respectivas e defini-las como alta prioridade (não esquecer de activar a funcionalidade de dupla prioridade):

IPR1bits.RCIP=1; // Interrupções de alta prioridade

IPR1bits.TXIP=1;

PIE1bits.RCIE=1; // (Des)Activação das interrupções

PIE1bits.TXIE=0;

Funcionamento da USART no Master

As Fig. 12 e Fig. 13 apresentam os algoritmos para troca de informação entre o master e a unidade principal.

Fig. 12: Algoritmo de recepção de informação, via USART, pelo Master

Fig. 13: Algoritmo de transmissão de informação, via USART, pelo Master.

Para evitar congestionamento de largura de banda de CPU, optou-se por uma solução baseada no agendamento de transmissão, em vez da transmissão imediata das mensagens de resposta. Tal permite a transmissão dos vários bytes sempre que for possível, possibilitando, desta forma, a execução de outras tarefas em paralelo sem terem que esperar que a transmissão se finalize. Ao mesmo tempo também é possível a recepção e a transmissão de informação simultaneamente.

Os algoritmos evidenciados na Fig. 12 e Fig. 13 relativamente à recepção e transmissão respectivamente, são executadas em paralelo entre si e, simultaneamente, com outras tarefas, como será o caso da comunicação CAN com as unidades slave. Para a implementação do protocolo, dois buffers implementados por software são utilizados para armazenamento dos bytes recebidos (buffer de recepção) e dos bytes a transmitir à unidade principal (buffer de transmissão). Note que a recepção/transmissão é efectuada por interrupção, pelo que a recepção/transmissão de um stream de bytes implica várias entradas/saídas da rotina de serviço à interrupção: tal implica que os buffers de entrada e saída devam ser estáticos para um acesso permanente do seu conteúdo sem perda de dados.

Base de Dados Global do Sistema

O processamento da mensagem recebida a partir da unidade principal é baseada na análise do byte opcode segundo a descrição na Tabela 3. Uma vez decifrado o conteúdo da mensagem, uma base de dados global com a informação sensorial e de actuação de cada uma das unidades slave, é acedido para consulta ou actualização, dependendo se se trata de uma operação de consulta sensorial ou de actuação respectivamente. A base de dados é dividida em duas estruturas, uma para a informação sensorial e outra para a de actuação.

Estrutura sensorial

// Estrutura descritiva dos sensores typedef struct { byte sysStatus; // Estado do sistema struct_servo servo[N_SERVOS]; // Sensores dos servos unsigned char special[N_SPECIAL_SENSORS]; // Sensores de força dos pés } struct_sensors; extern struct_sensors sensors[N_SCU]; // Conjunto global dos sensores

Estrutura de actuação

typedef struct { // Estrutura de actuação de status para cada SCU struct { bool pwm; // PWM on/off bool filter; // Filter on/off } sysStatus; // Estrutura de Controlo para cada junta struct { byte ki, kp, kd; enum_controlType type; } control[N_SERVOS]; struct_servo servo[N_SERVOS]; } struct_actuators; extern struct_actuators actuators[N_SCU]; // Conjunto global dos ctuadores

Estruturas adicionais

// Tipo enumerado do género de controlador implementado em cada junta typedef enum { NO_CONTROL = 0b00, // Funcionamento em malha aberta LOCOMOTION_CONTROL = 0b01, // Controlo de posição e velocidade REACTION_CONTROL = 0b10, // Controlo das forças de reacção nos pés BALANCE_CONTROL = 0b11 // Controlo de equilíbrio no tronco } enum_controlType; // Estrutura descritiva de um servo typedef struct { signed char position; // Posição signed char velocity; // Velocidade unsigned char current; // Corrente consumida } struct_servo;

Esta base de dados constitui uma imagem de todas as unidades slave, pelo que a consulta sensorial pode ser efectuada de forma imediata sem ser necessária qualquer comunicação adicional com o slave em questão. Já no que toca à actuação apenas é necessário actualizar a variável de interesse, e um mecanismo à parte encarrega-se de transmitir ao destino a nova informação. Este mesmo mecanismo também é responsável por manter a imagem sensorial de todas as unidades slave sincronizada e com o mínimo de atraso temporal.

Este mecanismo trata-se do segundo protocolo de comunicação implementado, o CAN, que é responsável pela troca de informação entre o Master e todos os Slaves. Este mecanismo trabalha de forma independente das comunicações USART e apenas tem como tarefa a actualização da base de dados sensorial e a transmissão aos slaves dos valores contidos na base de dados de actuação. Todo este processo ocorre a uma taxa de 1 KHz (1 ms) completando a actualização de todo o conjunto em apenas 8 ms (para 8 slaves).

As estruturas evidenciadas correspondem à versão 2.00 do software, em que se considera que para cada SCU pode estar ligado um conjunto de sensores de força (caso dos SCU's associados às pernas), ou um conjunto giroscópio+inclinómetro (restantes SCU's). Não existe por isso distinção do género de sensores usados em cada SCU pelo que a unidade principal deve ter conhecimento da localização dos diversos sensores usados.

COMUNICAÇÃO CAN

A comunicação CAN é implementada entre o Master e as diversas unidades Slave e tem como finalidade o redireccionamento dos dados de actuação, provenientes da unidade principal, para cada unidade Slave, e, no sentido oposto, o envio dos dados sensoriais para a unidade Master, de modo a que esta actualize a base de dados com a informação sensorial de todas as unidades por forma a permitir à unidade principal a sua consulta.

O CAN é um sistema de comunicações série multi-ponto que foi desenvolvido originalmente para a indústria automóvel para possibilitar as comunicações entre diversos componentes em ambientes extremamente ruidosos. Para tal, o sinal que serve de suporte à comunicação é definido em corrente e não em tensão. É um protocolo baseado na mensagem e não no endereço, o que significa que as mensagens são transmitidas na forma de broadcasting para todos os nós existentes na rede, cabendo a cada um a decisão de a aceitar ao não. As mensagens são constituídas por um identificador que pode possuir 11 ou 29 bits, de acordo com a versão A ou B respectivamente, e até 8 bytes de dados (Fig. 14).

Fig. 14: Formato standard das mensagens CAN.

De modo a eliminar a hipótese de colisão destrutiva de pacotes (no caso de envio simultâneo de mensagens por diferentes nós) como acontece nas redes Ethernet, o CAN é dotado de um sistema de colisão determinístico bit a bit (CSMA/BA – Carrier Sense Multiple Access / Bit-wise Arbitration) que no caso de uma colisão de pacotes apenas um prevalece (o de maior prioridade), enquanto que os restantes são destruídos. No último caso, os nós associados a esses pacotes devem tentar retransmitir mais tarde. Desta forma garante-se que a largura de banda oferecida pela rede não é desperdiçada, havendo sempre o transporte de mensagens desde que pelo menos um nó transmita.

Fig. 15: Exemplo de aplicação utilizando o CSMA/BA.

Para implementação deste sistema um dos bits é definido como dominante (bit 0) e o outro como recessivo (bit 1), de modo que quando dois bits colidem um com o outro “vence” o dominante. Esta estratégia é implementada bit a bit ao nível do identificador conferindo, deste modo, prioridades de acordo com o seu valor. Deste modo, quanto menor for o valor do identificador, maior é a prioridade da mensagem (Fig. 15). Segundo esta política é vantajoso atribuir um endereço de menor valor numérico à unidade master de modo a conferir-lhe a máxima prioridade e às restantes unidades é-lhes atribuído endereços de valor crescente à medida que a sua ordem de importância na rede diminui. Desta forma, atribuiu-se o endereço 0b0000 ao master e os endereços 0b0001 até 0b1000 para os oito slaves, dando maior prioridade às unidades respeitantes aos membros inferiores dado que requerem maior atenção ao nível do controlo.

Unidade Controladora	Secção a que respeita	Endereço na Rede
Master	Unidade mestre	0b0000
Slave 1	Perna direita	0b0001
Slave 2	Perna esquerda	0b0010
Slave 3	Anca direita	0b0011
Slave 4	Anca esquerda	0b0100
Slave 5	Tronco	0b0101
Slave 6	Braço direito	0b0110
Slave 7	Braço esquerdo	0b0111
Slave 8	Cabeça	0b1000

Tabela 11: Endereços atribuídos às diversas unidades de controlo.

Outro benefício da comunicação baseada na mensagem é o facto de se poderem adicionar outros nós à rede sem haver necessidade de reprogramar todos os nós existentes. O novo nó adicionado receberá igualmente as mensagens que circulam na rede, decidindo por si só se deve ou não processar a informação contida. Esta foi uma das principais razões que motivaram a escolha do CAN, permitindo, desta forma que a rede possa ser modificada sem qualquer implicação ao nível do controlo local.

No microcontrolador em causa, é utilizada a versão fullCAN 2.0A cujas características principais são:

Mensagens com um identificador de 11 bits e um máximo de 8 bytes de dados;

Filtragem completa do conteúdo do identificador (todos os bits do identificador podem ser utilizados para configuração da filtragem);

Associação do identificador a buffers de dados;

Múltiplos buffers de transmissão/recepção: 3 buffers de transmissão e 2 buffers de recepção;

Processamento e recuperação automática de erros.

Protocolo CAN

De acordo com os dados a trocar entre o Master e cada Slave, e utilizando todos os 8 bytes de dados em cada mensagem, é possível efectuar trocas de informação, quer de actuação, quer sensoriais, recorrendo a apenas dois pacotes para cada instanciação (16 bytes). Para efeitos de rigor na linguagem o termo pacote será utilizado para referir a informação trocada numa transacção atómica CAN (Fig. 14) e mensagem será utilizada para descrever a troca completa de informação (dois pacotes). O protocolo é enunciado a seguir.

bit 10	9	8	7	6	5	4	3	2	1	bit 0
Source address	Destination address	Index	Operation

Identificador de um pacote CAN

Campo	Descrição
Source Address	Endereço do nó emissor da mensagem
Destination Address	Endereço do nó destinatário da mensagem
Index	Índice do pacote dentro de uma mensagem: 0: primeiro pacote; 1: segundo pacote.
Operation	Operação associada à mensagem: 0b00: actualização sensorial; 0b01: actualização de actuadores.

Tabela 12: Campos do identificador de um pacote CAN.

De notar que apenas o campo destination address é útil para a recepção de cada pacote, pois é ele quem define o destino do pacote. Já o campo source address está presente nos bits mais significativos com o propósito de definir a prioridade do pacote de acordo com endereço do remetente. Desta forma, mensagens enviadas pelo master possuem a máxima prioridade, e dentro dos slaves, os dos membros inferiores possuem maior prioridade de envio (ver Tabela 11). Como cada mensagem é constituída por dois pacotes, o campo index identifica a ordem do pacote, e o campo operation refere a função dos dados transportados.

Transacção Master→Slave

As mensagens trocadas do master para slaves, têm como função a actualização dos actuadores das juntas a que dizem respeito, pelo que transportará as seguintes informações para cada um dos três servomotores associados:

Posição a atingir;

Velocidade média do movimento;

Flags de activação dos controladores locais;

Parâmetros de compensação dos controladores (Proporcional, Integrador e Derivativo);

Source address	Destination address	Index	Operation
0	0	0	0	X	X	X	X	X	0	1

Identificador de uma mensagem de actualização de actuadores

O identificador destas mensagens possuem o endereço 0b0000 no source address indicativo de que o pacote é proveniente da unidade master, e o campo operation contém o código 0b01 descrevendo que o pacote tem como intenção fazer uma actualização dos actuadores. O campo destination address identifica o SCU alvo.

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6	byte 7	byte 8
Position 1	Position 2	Position 3	Velocity 1	Velocity 2	Velocity 3	Control Flags	KD 3

Dados do primeiro pacote de actualização de actuadores (Index=0)

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6	byte 7	byte 8
KI 1	KI 2	KI 3	KP 1	KP 2	KP 3	KD 1	KD 2

Dados do segundo pacote de actualização de actuadores (Index=1)

Cada mensagem é constituída por dois pacotes em que tanto a posição final, como a velocidade média e os parâmetros de compensação para cada servomotor são actualizadas de uma só vez.

O byte Control Flags tem como função indicar qual o tipo de controlador a estar activo em cada um dos servomotores (ver Tabela 4) e se os sinais de controlo dos motores (PWM), bem como os filtros sensoriais, devem estar activos (valores booleanos).

bit 7	6	5	4	3	2	1	bit 0
PWM	Filter	Controller 3	Controller 2	Controller 1

Byte Control Flags do primeiro pacote

Transacção Slave→Master

Por outro lado é necessário actualizar a base de dados do master pelo envio de mensagens CAN com os dados sensoriais de cada slave para o master. Tal é executado logo após a recepção do pacote de actuação e com o retorno das seguintes informações:

Posição;

Velocidade média;

Corrente consumida;

Output dos sensores adicionais;

Source address	Destination address	Index	Operation
X	X	X	X	0	0	0	0	X	0	0

Identificador de uma mensagem de actualização sensorial

Os pacotes de actualização sensorial devem possuir no campo destination address o endereço da unidade master (0b0000), dado que a mensagem se destina a ele, e o campo operation a 0b00 indicativo de que a mensagem contém dados sensoriais. O source address contém o endereço do slave respectivo.

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6	byte 7	byte 8
Sensor Flags	Position 1	Position 2	Position 3	Velocity 1	Velocity 2	Velocity 3	Slave Status

Dados do primeiro pacote de actualização sensorial (Index=0)

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6	byte 7	byte 8
Sensor Flags	Current 1	Current 2	Current 3	Special 1	Special 2	Special 3	Special 4

Dados do segundo pacote de actualização sensorial (Index=1)

Os valores de saída dos sensores adicionais estão descritos nos campos Special apenas podendo fazer parte apenas de uma das seguintes classes:

Sensores de força de um dos pés (4 sensores);

Inclinómetro e Giroscópio (2 + 2 valores);

No entanto é indiferente de onde provém estes dados, dado que a unidade principal (PC) conhece à priori o género de sensores especiais conectados a cada unidade slave.

O byte sensor flags é puramente redundante, dado que a informação que contém também é transportado no identificador do pacote, e poderá ser usado no futuro para conter mais dados sensoriais.

bit 7	6	5	4	3	2	1	bit 0
Source Address	Index	0	0	0

Byte Sensor Flags

Campo	Descrição
Source Address	Endereço do slave remetente.
Index	Índice do pacote na mensagem de dados.

Tabela 13: Campos do byte Sensor Flags.

Já o byte slave status contém flags indicadoras do estado de funcionamento da unidade slave.

bit 7	6	5	4	3	2	1	bit 0
PWM flag	Filter flag	0	0	Deadline error	Motion finished

Byte Slave Status do primeiro pacote

Campo	Descrição
PWM flag	Indica se os sinais de controlo dos motores (PWM) estão activos.
Filter flag	Indica se os filtros dos sensores provenientes dos servomotores estão activos.
Deadline Error	Indicador da ocorrência de violação de deadline da execução da função main dentro do período de PWM (20ms).
Motion Finished	Indicador do término do movimento para cada servomotor (3 bits para 3 motores).

Tabela 14: Campos do byte Slave Status.

Configuração do CAN

Inicializações

As definições de funcionamento do CAN devem ser iguais entre a unidade Master e as unidades Slave de modo a permitir o correcto sincronismo entre todas as entidades envolvidas na rede, pelo que as opções tomadas devem ser implementadas em todas as unidades.

Como condições base seguiram-se as seguintes linhas:

Escolha da versão CAN mais universal: fullCAN 2.0A;

Configuração da velocidade na máxima possível (≤ 1 Mbps);

Máscara das mensagens não destinadas ao próprio SCU – apenas as mensagens com o endereço destino igual ao do próprio são aceites;

Dado o facto das mensagens serem constituídas por dois pacotes, aproveitou-se a presença de dois buffers de recepção para redireccionar cada uma para um buffer à parte – dupla filtragem;

Igualmente, utilizou-se dois buffers de transmissão para transmitir cada um dos dois pacotes.

A seguir são descritos as principais operações na configuração deste recurso.

a) Modo de Configuração

O PIC 18F258 possui seis modos de operação, dos quais apenas 3 nos são úteis:

Modo disable: o PIC não transmite nem recebe quaisquer mensagens;

Modo de configuração: necessário antes de activar as transmissões/recepções;

Modo de operação normal: recepção e transmissão de mensagens válidas, via CAN.

Antes de colocar o PIC a processar mensagens via CAN, é necessário antes, colocar o PIC em modo de configuração e definir os seus parâmetros de configuração. Apenas depois deste passo coloca-se o PIC no modo de operação normal.

Para definir o modo de funcionamento, os bits REQOP do registo CANCON devem ser modificados para o modo de interesse, e esperar a mudança efectiva pelo polling aos bits OPMODE do registo CANSTAT.

b) Baudrate

Todos os nós na rede CAN devem ter o mesmo bitrate nominal – número de bits transmitidos por segundo – sem no entanto ser necessário que todos os nós tenham a mesma frequência de oscilação. No entanto é necessário o cuidado em programar o baudrate prescaler e o número de time quanta (explicado adiante) em cada segmento de bit, de modo a manter o bitrate nominal. O bitrate máximo depende da qualidade do transmissor e do oscilador, e da presença de ressincronizações, mas poderá atingir o valor máximo de 1 Mbps numa situação ideal.

Dado que a transmissão utiliza codificação NRZ e que os osciladores e transmissores podem variar de nó para nó, é necessário introduzir bit stuffing para possibilitar a extracção de relógio para efeitos de sincronização. Tal é feito de modo a garantir uma alternância de bit pelo menos de 6 em 6 bits.

Uma unidade denominada por DPLL é utilizada para a sincronização dos dados recebidos e para garantir o bitrate nominal nos dados transmitidos. Funções de bus timing executadas dentro de cada bit frame, como a sincronização com o oscilador local, compensação do atraso introduzido pela rede e posicionamento de amostragem, implicam a particionamento de cada bit em vários segmentos definidos a partir de períodos de tempo mínimos chamados Time Quanta (TQ).

Fig. 16: Particionamento temporal de um bit.

Pela Fig. 16 podemos identificar 4 tipos de segmento:

Segmento de sincronização: utilizado para sincronizar os vários nós da rede – duração fixa de 1 TQ;

Segmento de propagação: utilizado para compensar os atrasos introduzidos na rede – duração entre 1 e 8 TQ.

Segmento de fase 1: número de TQ antes da amostragem do bit – duração entre 1 e 8 TQ.

Segmento de fase 2: fornece um atraso antes da mensagem seguinte – duração de 2 a 8 TQ.

A duração dos segmentos de fase 1 e 2 não são parâmetros estáticos e podem sofrer variações para efeitos de ressincronização. O parâmetro SJW (Synchronization Jump Width) define a forma como se farão estas flutuações contendo o número máximo de TQ que serão adicionados ao segmento de 1 ou subtraídos ao segmento 2.

Para definição das durações de cada segmento algumas regras deverão ser respeitadas. Elas são:

1 + Seg. de propagação + Seg. de fase 1 + Seg. de fase 2 ≥ 8

Seg. de propagação + Seg. de fase 1 ≥ Seg. de fase 2

Seg. de fase 2 ≥ SJW

Para o nosso caso, de forma a conseguir a máxima velocidade, definimos a mínima duração para cada bit, ou seja 8 TQ. A distribuição de Time Quanta está indicada a seguir:

Segmento de sincronização: 1 TQ (não configurável);

Segmento de propagação: 2 TQ;

Segmento de fase 1: 3 TQ;

Segmento de fase 2: 2 TQ;

SJW: 2 TQ.

Com base nestes parâmetros, e de modo a conseguir a máxima velocidade de Fbit=1Mbps, o baudrate a definir no registo BRP seria de 1.5. Como estes registos são inteiros têm que se arredondar para o lado que diminua a velocidade, ou seja, para cima. Neste caso BRP deverá ser de 2!

com

Para BRP=2, o bitrate nominal efectivo será de 833 Kbps.

c) Máscaras e Filtros

Os filtros são utilizados para automatizar o processo de aceitação de mensagens. No caso das mensagens de actuação, apenas se destinam a um SCU particular não possuindo qualquer interesse para os restantes. Desta forma, na perspectiva de cada SCU apenas algumas das muitas mensagens que passam pelo seu porto de entrada devem ser processadas, pelo que se a verificação do endereço destino fosse feita por software, a largura de banda de CPU atribuída a este processo seria tanto mais pesada quanto maior fosse o número de unidade slaves na rede.

De modo a automatizar o processo de aceitação, uma máscara pode ser utilizada para indicar quais os bits do identificador que contém o padrão de interesse para a unidade em questão (como por exemplo o endereço destino) e filtros podem ser utilizados para fazer a selecção dos padrões e redireccionar para determinados buffers. Desta forma, apenas as mensagens cujos bits da secção do identificador programado coincide com o padrão especificado, são aceites e carregados para os buffers de recepção gerando uma interrupção para o posterior processamento.

Máscara do bit n	Filtro do bit n	Valor do bit n	Resultado
0	x	x	Rejeitado
1	0	0	Aceite
1	0	1	Rejeitado
1	1	0	Rejeitado
1	1	1	Aceite

Tabela 15: Resultado da filtragem para cada bit.

Pela Tabela 15 podemos verificar que apenas os bits definidos a 1 pela máscara serão considerados para filtragem. Todos os outros serão rejeitados à priori. Dos que são considerados para filtragem são comparados com um determinado padrão sendo apenas aceites os que coincidem com esse padrão. Apenas as mensagens em que todos os bits do filtro são aceites, são consideradas para processamento por parte do programador.

Para o PIC 18F258 é possível utilizar todos os bits do identificador na máscara e filtragem e definir até dois padrões de filtragem para armazenamento imediato no primeiro buffer de recepção e até 4 padrões para armazenamento no segundo buffer (Fig. 17).

Fig. 17: Registos associados à mascaragem e filtragem.

Para o nosso caso em concreto, de acordo, com a estrutura do identificador enunciado anteriormente, a máscara a definir cobrirá os bits do endereço destinatário e do index do pacote, ou seja, possuirá o seguinte padrão:

bit 10	9	8	7	6	5	4	3	2	1	bit 0
Source address	Destination address	Index	Operation
0	0	0	0	1	1	1	1	1	0	0

Máscara a aplicar ao identificador

De seguida definir-se-ão dois filtros, de modo a aceitar unicamente os pacotes cujo endereço destino corresponda ao próprio SCU, e destes, redireccionar os de index 0 (primeiro pacote) para o buffer de recepção 0, e os de index 1 (segundo pacote) para o buffer de recepção 1 (Tabela 16).

Redirecção dos pacotes	Registos a configurar	Padrão
Buffer 0	RXF0 0 0 0 0 a3 a2 a1 a0 0 0 0 RXF1 0 0 0 0 a3 a2 a1 a0 0 0 0
Buffer 1	RXF2 0 0 0 0 a3 a2 a1 a0 1 0 0 RXF3 0 0 0 0 a3 a2 a1 a0 1 0 0 RXF4 0 0 0 0 a3 a2 a1 a0 1 0 0 RXF5 0 0 0 0 a3 a2 a1 a0 1 0 0

Tabela 16: Configuração dos filtros para redireccionamento de pacotes para os dois buffers de recepção (padrão a3 a2 a1 a0 = endereço do SCU).

Desta forma, redireccionando cada um dos dois tipos de pacotes para um buffer à parte, evita-se a perda de informação caso ocorra overflow, pois apenas o buffer cuja informação é equivalente ao novo pacote (index igual) é substituído.

d) Transmissão e Recepção de Mensagens

Finalmente, também é necessário configurar a forma como as mensagens serão transmitidas e recebidas.

Para a recepção, é necessário definir a recepção de apenas pacotes válidos cujo identificador segue o formato da versão CAN 2.0A (11 bits), e deve-se assegurar que o overflow do buffer 0 para o buffer 1 está desactivado, dado que estamos a usar um buffer para cada tipo de pacote.

Finalmente devemos colocar o bit RXFULL de cada buffer a zero, para a sua abertura à recepção de novas mensagens, verificando também se o interrupt flag associado está desligado.

Para a transmissão, os identificadores das mensagens deverão estar de acordo com o formato standard, ou seja, deverão possuir 11 bits de comprimento, e é necessário definir prioridades para cada um dos três buffers, para definição da ordem de transmissão no caso de vários agendamentos simultâneos.

Por questões de similaridade de comportamento, também se reservará um buffer de transmissão para cada tipo de pacote, fazendo apenas uso de dois buffers. O buffer 0 utilizado para os pacotes de index 0 possuirá a máxima prioridade e o buffer 1 possuirá a prioridade mínima (Tabela 17).

Buffer	Pacotes associados	Prioridade	Registos
Buffer 0	Index 0	Máxima	TXB0CON=0b11
Buffer 1	Index 1	Mínima	TXB1CON=0b10
Buffer 2	——	——	TXB2CON=0b01

Tabela 17: Atribuição de prioridades entre cada buffer de transmissão.

e) Modo de Operação Normal

Para colocar o CAN a funcionar só resta definir o modo de operação normal no registo CANCON.

Resumindo...

Colocação do PIC no modo de configuração;

Definição da duração de cada segmento de bit;

Definição do bitrate para a velocidade pretendida;

Configuração da máscara de recepção;

Configuração dos dois filtros para cada um dos buffers de recepção;

Definição do formato standard para os identificadores dos pacotes a transmitir;

Definição de prioridades entre buffers de transmissão;

Configuração da recepção para apenas pacotes válidos com identificadores de 11 bits;

Overflow do buffer 0 para o buffer 1 desactivado;

Clear dos interrupt flags de recepção;

Abertura dos buffers para recepção;

Colocação do PIC no modo de operação normal.

(Os passos 6 a 11 devem ser aplicados a cada um dos buffers de recepção/transmissão.)

Troca de Pacotes via CAN

Esta secção apresenta os procedimentos a efectuar nos PICs 18F258 para a troca de pacotes utilizando a rede CAN. Estes microcontroladores oferecem uma gama diversificada de registos que permitem controlar diversos aspectos, como por exemplo o comprimento do identificador ou o conjunto de dados e, também, no domínio da recuperação de erros.

Na recepção de um pacote que passe a máscara e um dos dois filtros, o seu conteúdo é carregado no buffer associado ao seu index n. Os procedimentos a seguir descritos devem-se aplicar relativamente a esse buffer:

Verificação da recepção de uma mensagem inválida através da flag IRXIF;

Confirmação da utilização do buffer n através da flag RXFULL;

Transferência do buffer n para o Acess Bank Area, de modo a se poder aceder a ele a partir de qualquer banco de memória. Para tal deve-se definir a janela de endereçamento de acordo com o buffer em uso (window address bits);

Verificação da ocorrência de overflow;

Leitura do identificador do pacote;

Validação do comprimento de dados recebidos;

Leitura dos dados;

Libertação do buffer n pela recolocação da flag RXFULL a zero;

Reposição da janela de endereçamento para o seu valor original;

Reposição do interrupt flag associado ao buffer n (RXBnIF) a zero;

Transmissão de um pacote usando o buffer n:

Verificar se o buffer n está pronto para transmissão (TXREQ deve ser zero);

Definição da janela de endereçamento para o buffer de transmissão n;

Definição do identificador;

Definição do comprimento do pacote (8 bytes);

Definição do conjunto de dados a enviar;

Activação da transmissão do buffer n (TXREQ=1);

Reposição da janela de endereçamento para o seu valor original;

Clear do interrupt flag associado ao buffer n (TXBnIF).

Os procedimentos de configuração e de troca de mensagens estão definidos numa biblioteca denominada por candrivers para utilização por parte do programador.

Funcionamento do CAN na unidade Master

A troca de informação é desencadeada a partir da unidade Master, estando os Slaves programados para responder imediatamente após a recepção dos pacotes oriundos do Master. A Fig. 18 apresenta o algoritmo utilizado na unidade master para gerir a troca de informação.

Fig. 18: Algoritmo de troca de informação pelo CAN no Master.

Todas as transmissões e recepções são desencadeadas a partir de um timer programado para gerar interrupções de 250 em 250μs. Começa-se por transmitir um pacote relativo à actuação processando de seguida o pacote de resposta com os dados sensoriais, isto para cada um dos dois pacotes de cada mensagem com uma periodicidade de 250μs. Desta forma a troca de informação para um SCU, o que inclui o envio da mensagem de actuação e a recepção da mensagem sensorial, tem a duração de 1ms. Para uma arquitectura com 8 SCUs, a actualização completa de todas as unidades dura 8ms.

Optou-se por uma política time-triggered para minimizar as interferências temporais com a comunicação pela USART que, por sua vez, funciona numa base event-triggered, uma vez que se baseia na resposta a mensagens de request oriundas do PC. O valor de 250μs resultou de um compromisso entre velocidade e mínima interferência temporal com o funcionamento da USART. Note que o processamento de um pacote CAN tanto para transmissão como para recepção foi medida como possuindo uma duração média de 100μs, restando cerca de 150μs para a execução das tarefas relativas à USART, que pela experiência, demonstrou-se ser suficiente para o cumprimento de todas as deadlines.

Transmissão e Recepção de Mensagens

Do ponto de vista do Master todas as mensagens a enviar são de actuação, e todas as recebidas são de carácter sensorial, pelo que, no último caso, é escusado o processamento do identificador, excepto para o conhecimento do SCU fonte e do index do pacote. No caso do endereço destino e da operação apenas são verificados para efeitos de teste do correcto funcionamento.

As mensagens de actuação a enviar vão buscar os valores a aplicar nos slaves à base de dados global que o PC periodicamente actualiza. Já as mensagens de carácter sensorial que vão chegando, actualizam constantemente as variáveis da mesma base de dados. É este mecanismo que garante a periódica actualização da base de dados sensorial e das unidades slave, no que toca à actuação.

Procedimento de envio de um pacote de actuação:

Construção do identificador com base no endereço destino e no index do pacote (endereço origem e operação conhecidos);

Construir o array de dados a enviar, a partir da base de dados de actuação, de acordo com o index da mensagem;

Enviar o pacote (identificador + array de dados) pelo buffer de transmissão adequado ao index;

Actualização do estado de erro, se ocorreu algum.

Recepção de um pacote de carácter sensorial:

Obtenção do identificador e do array de dados do pacote recebido;

Actualização da base de dados sensorial, a partir do endereço origem e do index do pacote;

Actualização do estado de erro, se ocorreu algum.

Operação I/O	Causa do Erro	Label	Padrão
Recepção/Transmissão	Erro geral	CAN_ERROR	0b00000001
Recepção	Mensagem inválida RX_INVALIDMSG_ERROR 0b00000010 Overflow RX_OVERFLOW_ERROR 0b00000100 Comprimento de dados inválido RX_INVALID_LENGTH 0b00001000 Identificador inválido RX_INVALID_ID 0b00010000 Dados inválidos RX_INVALID_DATA 0b00100000
Transmissão	Erro de transmissão TX_NOTPOSSIBLE 0b01000000 Transmissão impossível TX_ERROR 0b10000000

Tabela 18: Causas de erro na comunicação CAN.

Na ocorrência de erros, uma estrutura estática armazena a causa do erro na forma de um byte fazendo a operação booleana or entre os diversas códigos segundo a Tabela 18. Duas outras variáveis fazem a contagem dos erros de transmissão e de recepção.

// Estrutura descritiva dos erros ocorridos struct { enum CAN_ERRORS flags; // Causas byte tx_count, rx_count; // Número de ocorrências } canErrors;

Quando um comando USART de operação OP_READ_EXTBUFF é pedido pelo PC, uma mensagem é devolvida contendo a causa do erro e a quantidade de erros de transmissão e de recepção. Uma vez consultados, estes valores são reinicializados a zero.

byte 1	byte 2	byte 3	byte 4	byte 5	byte 6
0xFB	==	Error Code	# TX errors	# RX errors	0

Mensagem de leitura do estado do barramento CAN

Funcionamento do CAN nas unidades Slave

Nas unidades slave, a comunicação CAN é efectuada segundo a política event-triggered, dado que apenas é accionada quando são recebidas mensagens do master. A Fig. 19 evidencia o algoritmo presente em cada unidade slave.

Fig. 19: Algoritmo de troca de informação pelo CAN no Slave.

Quando um pacote é recebido no buffer 0 (primeiro pacote de actuação) uma interrupção é gerada, e na Rotina de Serviço à Interrupção (RSI) os dados de actuação são actualizados e um pacote com informação sensorial é enviado (primeiro pacote). Por sua vez, se a interrupção corresponder à chegada de um pacote no buffer de recepção 1, o processo é equivalente mas respeitante ao segundo pacote de cada mensagem.

Base de Dados Local

Como as novas informações de actuação nunca são aplicadas imediatamente, torna-se necessário armazenar estes valores numa base de dados local para posterior acesso pelas tarefas de controlo local. O mesmo se passa com a informação sensorial que quando é gerada tem que ser armazenada para que a tarefa de comunicação CAN possa acedê-la mais tarde para o envio das mensagens de resposta.

Esta base de dados local é muito semelhante à base de dados apresentada na unidade master, mas agora com a diferença de ser de carácter local, ou seja, apenas armazena a informação sensorial ou de actuação de um único SCU – o próprio.

// Tipo enumerado do género de controlador implementado em cada junta typedef enum { NO_CONTROL = 0b00, // Funcionamento em malha aberta LOCOMOTION_CONTROL = 0b01, // Controlo de posição e velocidade REACTION_CONTROL = 0b10, // Controlo das forças de reacção nos pés BALANCE_CONTROL = 0b11 // Controlo de equilíbrio no tronco } enum_controlType; // Estrutura descritiva do estado de um servo typedef struct { signed char position; // Posição signed char velocity; // Velocidade unsigned char current; // Corrente consumida } struct_servo;

Base de dados sensorial

// Estrutura descritiva dos sensores typedef struct { struct { bool pwm; // Motores ligados/desligados bool filter; // Filtros ligados/desligados bool deadlineError; // Violação de deadline bool motionFin[N_SERVOS]; // Movimento terminado } sysStatus; // Estado sensorial do sistema struct_servo servo[N_SERVOS]; // Sensores dos servos (posição, velocidade e corrente) unsigned char special[N_SPECIAL_SENSORS]; // Sensores especiais } struct_sensors; extern volatile struct_sensors sensors; // Sensores

Base de dados de actuação

// Estrutura descritiva dos actuadores typedef struct { // Estrutura de actuação de status para cada SCU struct { bool pwm; // PWM on/off bool filter; // Filter on/off } sysStatus; // Estado da actuação do sistema struct { byte kp, kd, ki; // Parâmetros Kp, Kd e Ki bool type; // Tipo de Controlador } control[N_SERVOS]; // Controlador struct_servo servo[N_SERVOS]; // Informação de actuação (posição, velocidade e corrente) } struct_actuators; extern volatile struct_actuators actuators; // Actuadores

De forma a minimizar a interferência temporal com as restantes tarefas da unidade, as interrupções de recepção de mensagens provenientes do master (Fig. 19) foram definidas como sendo de baixa prioridade, enquanto que as restantes são de alta. Desta forma a troca de mensagens em cada slave só é feita em background, ou seja, nos tempos livres do processador.

Transmissão e Recepção de Mensagens

Do ponto de vista de cada slave todas as mensagens a enviar são de carácter sensorial, e todas as recebidas são de actuação, pelo que, no último caso, é escusado o processamento do identificador, excepto para o conhecimento do index do pacote. O endereço origem (MCU), endereço destino (o próprio) e da operação apenas são verificados para efeitos de teste do correcto funcionamento da troca de mensagens.

Envio de um pacote de carácter sensorial:

Construção do identificador com base no index do pacote (endereço origem, destino e operação conhecidos);

Construir o array de dados a enviar de acordo com o index da mensagem, a partir dos dados sensoriais obtidos directamente;

Enviar o pacote (identificador + array de dados) pelo buffer de transmissão adequado ao index;

Recepção de um pacote de actuação:

Obtenção do identificador e do array de dados do pacote recebido;

Actualização dos actuadores de acordo com o index do pacote;

No caso das unidades slave, dispensa-se o processamento de erros, uma vez que se pretende reduzir ao mínimo o consumo de largura de banda da rede. O processamento de erros, implicaria a transmissão de mensagens para o master do estado da unidade, o que poderia aumentar o risco de saturação da rede.

ORGANIZAÇÃO DO SOFTWARE

Unidade Master

As relações de inclusão entre os diversos módulos estão esquematizadas na Fig. 20. Cada módulo representa um par de ficheiros .h e .c com o protótipo das funções externas e a sua implementação respectivamente. Apenas o módulo Master apenas possui um ficheiro .c dado que é o que contém a função main.

Fig. 20: Relações de inclusão dos módulos de software do Master.

Módulo Master

Este módulo é o primeiro a ser executado (função main) e é responsável por fazer a chamada das funções de configuração presentes no módulo PIC. Após os procedimentos de configuração, fica preso numa dummy task em que o único software em execução é proveniente da rotina de serviço à interrupção definida no módulo PIC.

Módulo PIC

Módulo com a implementação da rotina de inicialização do PIC e da rotina de serviço às interrupções provenientes da USART e do CAN. É neste módulo que são inicializados e implementados os mecanismos de comunicação com a unidade principal (secção 2.2.3.2) e as unidades slave (secção 2.3.3).

Tabela 19: Funções do módulo PIC.

Funções	Descrição
initPic	Inicialização dos periféricos associados às comunicações USART e CAN.
isr	Implementação dos mecanismos de comunicação pela USART com a unidade principal e da comunicação CAN com as unidades slave.

Módulo USART

Módulo com os device drivers para inicialização (secção 2.2.3.1) e implementação do protocolo USART descrito na secção 2.2.1.

Tabela 20: Funções para manipulação dos buffers da USART.

Funções	Descrição
usartInit	Inicialização da USART no PIC segundo os dados descritos na secção 2.2.3.1.
usartStreamMode	Esta função indica se o buffer de recepção está vazio ou não. Em caso negativo a USART está em modo de recepção de um stream de bytes (true retornado).
usartStoreRx	Armazenamento de um byte no buffer de recepção.
usartGetTx	Obtenção de um byte armazenado no buffer de transmissão.
usartResetRxBuff	Reinicialização a zero de todo o buffer de recepção.
usartResetTxBuff	Reinicialização a zero de todo o buffer de transmissão.
usartStore2extBuff	Armazenamento de um byte no buffer externo.

A função usartStore2extBuff refere a existência de um terceiro buffer denominado por buffer externo. Tal destina-se aos módulos externos que pretendam enviar informação adicional pela USART. Tal é o caso do módulo CAN que disponibiliza à unidade principal, através desta função, o estado de funcionamento do barramento CAN (estado de erro). Para o PC aceder a estes dados apenas tem de enviar um comando com o operation=OP_READ_JOINT e parameter=PARAM_CANSTATUS. O formato da mensagem de resposta está descrita na secção 2.2.1.

A Tabela 21 apresenta um conjunto de funções de mais alto nível, que fazem uso dos device drivers explícitos atrás, para processamento dos comandos provenientes do PC e construção da mensagem de resposta a retornar (secção 2.2.3.2).

Tabela 21: Funções de construção da mensagem de resposta para uso da Rotina de Serviço à Interrupção.

Funções	Descrição
usartSendTestMsg	Rotina de envio de uma mensagem com o formato FA F9 F8 F7 F6 F5 (hex). Esta mensagem tem como propósito testar o funcionamento da USART.
usartSendStatus	No caso dos comandos de actuação, dois tipos de mensagens podem ser retornados, excluindo as mensagens com erros de recepção por parte do master. Elas são a confirmação da actuação com sucesso ou parâmetros inválidos (secção 2.2.1). Em tais casos é enviada uma mensagem com todos os bytes iguais ao do comando de actuação à excepção do primeiro com a indicação do estado: MESSAGE_SUCESS (0xFB) ou MESSAGE_INVREQ (0xFC). Esta função tem o objectivo de construir uma mensagem igual à última recebida com o primeiro byte igual ao estado a retornar.
usartProcessMsg	Rotina de processamento dos comandos enviados do PC para o master para construção da mensagem de resposta.

Módulo CAN

Módulo com a implementação das funções de alto nível para a recepção e o envio de mensagens CAN (secção 2.3.3) segundo o protocolo descrito na secção 2.3.1.

Tabela 22: Funções de alto nível para troca de mensagens via CAN.

Funções	Descrição
canInit	Inicialização do periférico CAN e dos timers e interrupções associados.
canSendMsg	Envio de uma mensagem CAN com dados de actuação a aplicar a um determinado SCU.
canReceiveMsg	Recepção de uma mensagem CAN com os dados sensoriais de um determinado SCU.
canClearStatus	Reinicialização do estado de erro do barramento CAN.

Módulo CANDRIVERS

Módulo com os device drivers básicos para inicialização e transmissão/recepção de pacotes via CAN (secção 2.3.2).

Tabela 23: Device drivers da comunicação CAN.

Funções	Descrição
myCANInitialize	Inicialização do periférico CAN.
myCANSendMessage	Envio de um pacote através do primeiro buffer de transmissão vazio.
myCANSendMessage0	Envio de um pacote através do buffer de transmissão 0.
myCANSendMessage1	Envio de um pacote através do buffer de transmissão 1.
myCANSendMessage2	Envio de um pacote através do buffer de transmissão 2.
myCANReceiveMessage	Leitura de um pacote no primeiro buffer de recepção cheio.
myCANReceiveMessage0	Leitura de um pacote no buffer de recepção 0.
myCANReceiveMessage1	Leitura de um pacote no buffer de recepção 1.

Módulo GLOBAL

Módulo com a definição da base de dados com os dados de actuação e sensorial de todos os SCUs da arquitectura (estruturas descritas na secção 2.2.3.3).

Tabela 24: Funções presentes no módulo GLOBAL.

Funções	Descrição
initGlobal	Inicialização de toda a base de dados para os valores origem.
initSensors	Inicialização somente da base de dados sensorial.
initActuators	Inicialização somente da base de dados de actuação.

Módulo TYPES

Módulo com a definição de tipos de variáveis extra para uso nos restantes módulos. Eles são:

Tipo de variável	Descrição
bool	Tipo booleano (true ou false) (tipo enumerado).
byte	Tipo inteiro de 8 bits sem sinal (unsigned char).
word	Tipo inteiro de 16 bits sem sinal (unsigned int).
dword	Tipo inteiro de 32 bits sem sinal (unsigned long).

Módulo P18F258

Biblioteca com a definição de todos os registos e bits correspondentes do PIC 18F258 para o seu controlo (ver datasheet da Microchip, PIC18F258).

Unidade Slave

A Fig. 21 apresenta as relações de inclusão entre os vários módulos de software da unidade slave. Os módulos a verde são iguais aos utilizados na unidade master, pelo que dispensam apresentações. Quanto aos módulos a vermelho não estão relacionados com as comunicações e por isso não estão cobertos neste capítulo.

Fig. 21: Relações de inclusão dos módulos de software de cada Slave.

Módulo Slave

Módulo com a função iniciadora main, responsável pela chamada das funções de configuração presentes nos outros módulos e por executar tarefas em background durante o funcionamento normal.

Módulo PIC2

Módulo com a implementação da rotina de inicialização do PIC e da rotina de serviço às interrupções, uma das quais provenientes do CAN. É neste módulo que são inicializados e implementados os mecanismos de comunicação com a unidade master.

Tabela 25: Rotinas do módulo PIC2 responsáveis por gerir as comunicações CAN.

Funções	Descrição
initPic	Inicialização das comunicações CAN e de outros periféricos destinados ao controlo local.
lowISR	Rotina de Serviço à Interrupção responsável por gerir as interrupções provenientes do CAN.
...	(outras tarefas para controlo local)

Módulo CAN

Módulo com a implementação das funções de alto nível para a recepção e o envio de mensagens CAN (secção 2.3.4) segundo o protocolo descrito na secção 2.3.1, mas no que respeita à unidade slave.

Tabela 26: Funções de alto nível para troca de mensagens via CAN.

Funções	Descrição
initCan	Inicialização do periférico CAN e das interrupções associadas.
sendCanMessage	Envio de uma mensagem CAN com dados de sensoriais para a unidade master.
receiveCanMessage	Recepção de uma mensagem CAN proveniente do master com os dados de actuação a aplicar.
checkCan	Verificação do bloqueio do CAN, no caso do PIC se encontrar no modo bus-off.

A função checkCan é útil para verificar se a unidade ainda possui a interface CAN activa e em funcionamento. Cada nó na rede pode comportar-se de três formas diferentes durante o seu funcionamento:

Modo error-active: mensagens normais e frames de erro (na ocorrência de erros) com bits dominantes são trocadas com os outros nós para lhes indicar a ocorrência de anomalias;

Modo error-passive: as frames de erro passam a ser constituídas por bits recessivos para evitar a interferência destrutivas das mensagens provenientes de outros nós;

Modo bus-off: o nó é bloqueado em termos de recepções e transmissões.

Na ocorrência de erros, um contador é incrementado, sendo também decrementado na ausência deles. Quando atinge um valor limite o modo de funcionamento vai alternando para o modo seguinte até atingir o modo bus-off, bloqueando as recepções e as transmissões com os outros nós.

Esta função foi construída devido ao facto de as unidades esporadicamente bloquearem as suas comunicações e ter assim um meio para verificar a causa.

Módulo GLOBAL

Módulo com a definição da base de dados com os dados de actuação e sensorial do próprio SCU (secção 2.3.4.1).

Tabela 27: Funções presentes no módulo GLOBAL.

Funções	Descrição
initGlobal	Inicialização de toda a base de dados para os valores origem.
initSensors	Inicialização somente da base de dados sensorial.
initActuators	Inicialização somente da base de dados de actuação.
reinitServo	Reinicialização das posições dos actuadores para os valores origem (definidos à priori pelo próprio SCU).

RESOLUÇÃO DE PROBLEMAS

Implementando os algoritmos descritos em cada nó, observou-se uma eficiente troca de mensagens sem corrupção de dados e sem atrasos aparentes.

No entanto, esporadicamente, observa-se nalgumas unidades slave, o bloqueio das comunicações CAN no arranque do sistema ou ao fim de alguns minutos de funcionamento.

Neste último caso, suspeita-se que por acumulação de erros de transmissão e de recepção o respectivo módulo CAN entre em modo bus-off desligando todas as transmissões e recepções. Embora o protocolo construído faça a contagem dos erros e armazene a sua causa, para consulta pela unidade principal, ainda não é suficiente para apurar a causa dos erros. Porém verifica-se que ocorrem erros de entrega de mensagens inválidas e de overflow, mas sem no entanto se verificar nenhum problema a nível prático. Como a troca de mensagens isoladas funciona em óptimas condições, pensa-se que a causa pode estar por detrás da gestão da largura de banda da rede, que, com a sobrecarga de mensagens na rede, as de menor prioridade podem-se atrasar de uma forma acumulativa até provocar o bloqueio da unidade local respectiva. Tal ideia é suportada pelo facto, de até agora, as unidades que são bloqueadas correspondem às de menor prioridade. Mais investigação deve ser feita para perceber melhor o que está em causa.

No que respeita à desactivação de alguns nós logo no arranque do sistema, observa-se que tal só se verifica no uso de vários nós, e varia consoante se transfere a alimentação entre diferentes baterias e a fonte de alimentação da bancada. Tal pode estar relacionado com os picos de corrente que os actuadores provocam no arranque, sendo necessário desactivar/activar o sistema repetidamente, ou substituir a fonte para resolução do problema. No entanto, ainda não se conhece em pormenor as origens da anomalia, de forma a poder apontar uma solução.

CONCLUSÕES

A arquitectura de comunicações adoptada para a estrutura humanóide, revelou-se bastante simples de implementar seguindo uma lógica bastante intuitiva. Esta arquitectura segue um formato distribuído, com a associação de cada trio de juntas (normalmente associadas a um membro físico) a uma unidade de controlo local baseada num PIC que se responsabiliza em aplicar os sinais de controlo e ler a informação sensorial. Estas unidades de controlo interligam-se umas às outras por meio de um único barramento que partilha as mensagens em circulação a todas as unidades de controlo a ele ligadas. Este barramento também se interliga a uma unidade mestre (master) que por sua vez está conectada à unidade principal, neste caso um PC, que é responsável por enviar os comandos de actuação e de leitura sensorial a cada unidade local. Deste modo, cada unidade tem uma funções específica, deslocalizando assim, da unidade principal, todas as tarefas de controlo dos servomotores e de distribuição das mensagens entre os diversos slaves.

Implementando os protocolos de comunicação tanto série entre o PC e o master, como o CAN entre o master e os slaves seguindo a metodologia de funcionamento enunciada, a fiabilidade das comunicações revelou-se bastante boa com a troca de mensagens à velocidade máxima possível e sem a detecção de corrupção de dados ou de atrasos excessivos na sua entrega.

Apesar dos problemas ainda existentes na operacionalidade, de uma forma geral, o sistema de comunicações está suficientemente funcional para operar directamente sobre as juntas a partir do PC como unidade principal. Utiliza-se o software MatLab para fazer a interface uma vez que oferece uma linguagem de alto nível e intuitiva para programação das sequências de comandos a aplicar nas juntas e também para monitorar os sinais de saída. O capítulo 3 faz uso dos device drivers enunciados na secção 2.2.2.1 para o envio de comandos de actuação e leitura do sinal de posição e outros associados ao actuador.

SISTEMA DE CONTROLO DE BAIXO-NÍVEL

Resumo:

Este capítulo tem como objecto de estudo os actuadores presentes nas juntas no que toca à leitura do seus sensores e à sua actuação. Posteriormente combinaremos estes dois procedimentos de forma a corrigir eventuais desvios ao comportamento esperado, pela introdução de um compensador externo. Posteriormente este controlador será utilizado nas juntas do robot responsáveis pela locomoção.

CONTROLO DA PLATAFORMA HUMANÓIDE

Como já foi mencionado no capítulo 1, o robot humanóide é constituído por oito unidades de controlo local, que denominámos por slaves, que podem controlar até 3 graus de liberdade dos 22 existentes na arquitectura actual, e que se interligam a um computador (unidade principal), através de uma unidade master, para o envio de comandos de actuação com base na informação sensorial medida.

Fig. 22: Arquitectura da plataforma humanóide.

Como actuador para cada grau de liberdade, estamos a utilizar servomotores, que não são nada mais, nada menos, do que motores adaptados para efectuar controlo de posição. Como vantagens estes motores permitem-nos fazer medidas da sua posição e da sua corrente consumida o que nos possibilitará mais adiante fazer controlo externo para correcção de eventuais desvios ao comportamento ideal.

Para além do controlo sobre as juntas, também existem um conjunto de sensores adicionais destinados ao equilíbrio desta plataforma. Eles são:

Sensores de força aplicados directamente sobre a base de cada pé, implementados a partir de extensómetros – resistências que variam o seu valor de acordo com a sua deformação.

Inclinómetros para medição da verticalidade do tronco. Estes inclinómetros são basicamente acelerómetros que medem a aceleração da gravidade nos seus dois eixos ortogonais – na posição vertical o vector gravidade deve coincidir com o seu eixo vertical.

Giroscópios para medição da velocidade angular de certos pontos do corpo.

Para já, ainda só foram testados os sensores de força aplicados na base dos pés, com o intuito de assegurar a projecção do centro de massa do corpo sobre o centro de um dos pés (quando apenas um pé está assente no solo). Desta forma, para pequenas velocidades e pequenas acelerações, o robot mantém-se em equilíbrio. Este assunto será discutido de forma mais detalhada no próximo capítulo.

Neste capítulo apenas serão discutidos os actuadores e o seu controlo de forma a permitir:

Fazer o controlo de posição de modo a garantir que o actuador atinge sempre a posição solicitada;

Fazer o controlo de velocidade, variando o seu valor de acordo com as necessidades;

Que os movimentos das juntas sejam os mais suaves possíveis, sem acelerações bruscas nem velocidades muito elevadas;

Embora os servomotores tenham sido escolhidos por possuírem um controlador interno de posição, contrariamente aos outros géneros de motores, veremos adiante que apresenta muitos problemas na concretização dos objectivos enunciados, principalmente na presença de grandes cargas no seu eixo.

A Unidade de Controlo Local

A Fig. 23 apresenta a constituição de uma unidade de controlo local – slave – com o microcontrolador PIC18F258 e a electrónica de interface para os servomotores e os diversos sensores adicionais.

Fig. 23: Constituição de uma unidade slave.

Como se pode observar, cada slave, possui uma interface para o barramento CAN constituído pelo MCP2551 CAN driver uma interface adicional para comunicar pela USART e um DIP switch que permite via hardware configurar o endereço da unidade (slave address). Para a actuação, é possível controlar três servomotores com a disponibilidade de um pino dedicado a cada um para aplicação directa de um sinal modulado em duty-cycle para o controlo de posição. Adicionalmente, um multiplexer de 16 canais é utilizado para fazer a aquisição sensorial dos servomotores e dos sensores especiais.

Fig. 24: Imagens de uma unidade de controlo local.

As imagens da Fig. 24 correspondem à versão implementada no ano lectivo anterior (2004/05). No que respeita a este ano, modificações foram feitas de modo a resolver alguns bugs. Elas são:

Fusíveis de 2A substituídos por de 3.15A;

Devido aos picos de corrente induzidos pelo arranque dos servomotores, provou-se ser insuficiente a corrente máxima de 2A, pelo que foi necessário aumentar para um escalão acima: 3.15A.

Condensador electrolítico de 1μF adicionado à entrada do regulador de tensão;

Para evitar a ocorrência de resets nos PICs adicionou-se um condensador de filtragem à entrada do regulador de tensão, para estabilização da tensão de entrada.

Condensador SMD de 100nF colocado aos terminais da alimentação do PIC;

De modo a conferir maior estabilidade na alimentação do PIC colocou-se um condensador de filtragem directamente sobre os pinos da alimentação. Por uma questão de boas práticas é recomendado colocar um condensador de filtragem de elevado valor à entrada do regulador e um condensador de menor valor directamente sobre os pinos de alimentação de cada circuito integrado que esteja ligado à saída do regulador. Por isso, caso uma nova versão seja construída no futuro, aconselha-se a implementação deste método.

Remoção das resistências de potência ligadas entre a massa dos servomotores e a do SCU;

Com a presença desta resistência, verificava-se que os níveis de corrente consumidos eram bastante maiores que na sua ausência. Como estas resistências eram utilizadas para medição de corrente, e tendo em conta que se descobriu outro método para efectuar este procedimento, estas resistências foram curto-circuitadas (ver secção 2.1.3.1).

Adicionadas resistências de 10KΩ entre a entrada de actuação de servomotor e a massa.

Por motivos desconhecidos, alguns servomotores, na ausência do sinal de entrada de actuação, ficavam descontrolados efectuando movimentos contínuos sem uma posição final específica. Descobriu-se que ligando uma resistência à entrada do sinal de actuação com o outro terminal à massa, este efeito deixava de se verificar.

ACTUADORES: OS SERVOMOTORES

Para a actuação sobre as juntas é essencial tanto o controlo de posição como de velocidade, e dado que em média cada junta não possui uma excursão de movimento superior a 180º, uma solução baseada em servomotores foi a mais imediata. Podem-se enunciar as seguintes vantagens e desvantagens para esta escolha:

Excursão de posição de 180º;

Controlador de posição incluído;

Relativamente pequeno e compacto;

Relativamente barato;

Não oferece controlo de velocidade.

Fig. 26: Servomotor da HITEC Fig. 25: Representação do interior de um servomotor.

Olhando para o interior deste actuador podemos discernir os seguintes componentes:

Motor DC;

Caixa redutora;

Mecanismo de feedback da posição angular do motor (potenciómetro);

Electrónica de controlo do motor a partir de um sinal digital;

Electrónica de controlo de posição.

Pode-se, por isso, concluir que estes servos, não são nada mais do que simples motores DC que incluem electrónica interna responsável por implementar o controlo de posição em malha fechada a partir de um sinal externo de referência. Este sinal externo define a posição a ser atingida é da forma de uma onda quadrada modulada em largura de impulso – PWM (Pulse Width Modulation) –, cuja largura é que define a posição final. Desta forma, a posição do eixo do servo é controlada a partir do duty-cycle de uma onda quadrada de formato digital (Fig. 27).

Spec	Values
Control system	Pulse Width Control 1.5 ms neutral
Voltage range	Fig. 27: Sinal de PWM aplicado no servomotor. 4.8V to 6.0V
Teat voltage	@ 4.8V	@ 6.0V
Speed (no load)	60º/0.19 s	60º/0.14 s
Stall torque	1.94 Nm	2.42 Nm
Operating angle	45º /one side pulse traveling 400ms
Direction	clockwise/pulse traveling 1.5 to 1.9 ms
Current drain	8mA (idle); 700mA (no load running)
Dead bandwidth	8 ms
Dimensions	66 x 30 x 57.6 mm
Weight	152g

Tabela 28: Especificações do servo da HITEC HS-805BB.

Para cada modelo de servomotor este sinal deve assumir determinadas especificações, mas para um dos modelos utilizados (HITEC HS-805BB1 Estes dispositivos podem ser adquiridos no site http://www.maxxprod.com ) estas devem ser as características do sinal de PWM:

Frequência de 50 Hz (Período de 20 ms);

Duty-cycle variável entre 1 (0º) e 2 ms (180º).

Mais dados podem ser consultados na Tabela 28 com indicações do duty-cycle correspondente à posição neutra ou central (90º) (control system), gama das tensões do sinal de PWM (voltage range), em que observa que aceita sinais digitais de 5V provenientes do PIC, binário máximo, corrente consumida, e outros.

A escolha do modelo HITEC HS-805BB para as juntas mais exigentes, recaiu essencialmente pelo seu binário máximo de 2.42 N.m. Simulações em CATIA da plataforma humanóide realizando um passo (ano 2004/05) demonstram que no pior cenário as juntas podem estar submetidas a binários de cerca de 2.6 N.m (Tabela 29). O modelo HS-805BB destacou-se por possuir o máximo binário da gama disponível, que mesmo assim, mostra ser insuficiente para o nosso caso. Para resolver este problema, introduziram-se correias de transmissão que multiplicam o binário máximo pela relação entre número de dentes do eixo do servo e da junta.

Tabela 29: Binários exigidos na simulação de um passo.

Fig. 28: Correia de transmissão aplicada a um servo.

Nas juntas dos pés e dos joelhos utilizaram-se relações de transmissão de 2:1 e de 2.2:1 assegurando um binário máximo de 5.3 N.m assumindo como 2.42 o binário máximo do servomotor, e nas juntas das ancas aumentou-se a margem para 1:3.75 dada a sua exigente natureza (máximo de 9.1 N.m).

Olhando para o interior do servo na tentativa de perceber melhor a sua electrónica interna, a Fig. 29 apresenta o circuito de controlo de um servo semelhante aos da HITEC – o FUTABA S3003 – cujo sinal de PWM (input pulse) apresenta as mesmas especificações que as descritas atrás.

Estes dispositivos utilizam como feedback tanto o sinal de posição como de velocidade que, além de fornecer um controlo preciso de posição, permite estabilizá-lo de modo a conduzi-lo para a posição desejada com o mínimo de oscilação.

Em funcionamento normal, o sinal de PWM da entrada é comparado com o sinal resultante de um gerador de impulso linear controlado a partir da posição obtida pelo potenciómetro e da velocidade medida a partir da força contra-electromotriz do motor (tensão gerada entre impulsos de potência). O sinal gerado é da mesma forma que o de entrada e, para baixas velocidades, a sua largura de impulso deve corresponder à posição efectiva do motor.

A diferença de largura de impulso entre estes dois sinais, conhecido como sinal de erro, é em seguida amplificado através de um amplificador de impulso que depois é aplicado numa ponte H (BAL6686) que controla o motor. Facilmente se percebe que quando a largura de impulso do sinal de entrada é igual à resultante pelo gerador de impulso (erro zero) a diferença é de largura nula e nenhum sinal é aplicado ao motor deixando-o em repouso – note que o motor em si é controlado em velocidade pelo que se nenhum sinal for aplicado ele tende para o repouso.

Fig. 29: Circuito do controlador de posição de um FUTABA S3003.

Representando matematicamente as operações envolvidas, verificamos que:

À posição medida pelo potenciómetro p(t) é aplicado um ganho KP representado pela resistência de 22KΩ que é somada à velocidade resultante da força contra-electromotriz multiplicado pelo ganho KD representado pelo paralelo das resistências de 910K e de 330KΩ.

O resultado da soma f(t) é introduzido no gerador de impulso linear que produz um sinal de PWM para comparação (em termos de largura de impulso) com o sinal de entrada de referência r(t) através do comparador de largura de impulso produzindo o sinal de erro e(t) também do formato PWM.

O sinal de erro é amplificado num factor de K através de um amplificador de impulso e é aplicado ao motor através de uma ponte H.

Logo, concluindo:

Fig. 30: Representação esquemática do controlador de posição interno.

Comparando a Fig. 29 e a Fig. 30 podemos relacionar o elemento s como o sensor de velocidade, a diferença R(s) – F(s) como o comparador de largura de impulso e o ganho K como o amplificador de largura de impulso. Verifica-se então dois tipos de compensação presentes: a compensação série executada pelo ganho proporcional K e a compensação paralela realizada na realimentação através de um ganho PD (proporcional+derivativo) à posição medida. Note que o sinal proveniente da realimentação f(t) para posterior comparação não depende exclusivamente da posição medida, mas também da velocidade actual o que confere uma maior estabilidade na realização do percurso para a posição desejada.

Um pormenor que vale a pena salientar é a ausência da componente integral no controlo, o que poderá originar erros em regime estacionário quando aplicadas cargas elevadas no eixo.

Setup Experimental

Para efeitos de testes ao actuador em questão, uma base experimental foi montada tendo em vista a realização de movimentos variando os seguintes parâmetros:

Excursão do movimento (posição inicial e final);

Velocidade do movimento2 Embora não seja possível fazer controlo directo de velocidade, é possível a partir do controlo de posição induzir uma determinada velocidade ao dispositivo. Tal é explicado no capítulo seguinte. ;

Carga aplicada no eixo.

... de forma a poder avaliar a performance do servomotor pela monitorização da posição efectiva que percorre ao longo do tempo e da corrente consumida.

Fig. 31: Arquitectura das comunicação no setup.

Fig. 32: Setup experimental.

Load	Mass (g)	Torque (N.m)
0	9	0.009
1	258	0.253
2	463	0.454
4	675	0.662
1+4	924	0.906
2+4	1129	1.108
1+2+4	1378	1.352

Tabela 30: Lista de cargas utilizadas para teste.

Pela Fig. 31 podemos visualizar a arquitectura das ligações com a unidade principal (PC). Como só tencionámos testar um único actuador, apenas precisamos de uma unidade slave que liga ao PC segundo a rede de comunicações utilizada na plataforma humanóide.

O servomotor, por sua vez, encontra-se fixo num torno de fixação para poder mover cargas de uma forma segura. As cargas são presas ao servo através de um braço de massa desprezável e de 10 cm de comprimento que percorre a excursão dos 180º desde a posição vertical inferior até ao ponto vertical superior. Esta opção é muito útil dado que nos permite estimar o valor do binário resultante da força gravítica através da seguinte fórmula...

... em que m é a massa da carga, g a aceleração gravítica (9.81 m/s2), L é o comprimento do braço (0.1m) e θ é a posição angular do braço, com 0º na posição central (perpendicular ao vector gravidade), +90º no extremo superior e -90º no extremo inferior. A partir dela sabemos que nos extremos o binário gravítico é nulo e no ponto central (braço e FG perpendiculares) ele é máximo.

A Tabela 30 indica a lista de massas utilizadas durante os testes. Embora as especificações destes servos indiquem um binário máximo de 2.42 N.m, na prática verificou-se que este estava muito abaixo deste valor deixando de responder para cargas superiores a 1.5 Kg (binário τ=1.47 N.m) talvez devendo-se a desgaste destes actuadores. Tal justifica o facto da massa mais elevada da lista ser de 1.38 Kg.

Actuação sobre o Servomotor

Tal como foi descrito na secção 3.1 cada unidade de controlo local é capaz de gerar três sinais de PWM independentes entre si, a partir do microcontrolador PIC disponibilizando-os através de três pinos reservados que se podem ligar directamente aos servomotores. Note, contudo, a necessidade de adicionar a cada saída de PWM uma resistência de 10KΩ à massa para drenagem da carga existente aquando da ausência de PWM. Sem este elemento, nestas circunstâncias, o servo poderá deslocar-se à máxima velocidade para posições imprevistas que podem não se encontrar na gama anunciada dos 180º resultando no encrave num dos extremos com o máximo consumo de corrente. Tal comportamento imprevisto pode danificar estes dispositivos não mencionando a própria estrutura do humanóide.

Fig. 33: Resistência a adicionar a cada saída de PWM do PIC.

Vamos agora descrever como é programado o PIC para gerar os três sinais de PWM. Tendo em mente a geração destes sinais de forma automática sem nunca colocar o CPU em espera (por polling) várias opções são-nos oferecidas, nomeadamente utilizando...

Módulo de PWM (CCP);

Módulo de comparação (CCP);

Interrupções.

Dado o PIC 18F258 só possuir dois módulos CCP (CCP e ECCP) tal é insuficiente para gerar três sinais de PWM, com a agravante da frequência mínima configurável para o módulo de PWM ser bastante superior a 50 Hz. Por isso só nos resta a última opção recorrendo unicamente a interrupções baseadas em timers.

Só pensando na geração de um único PWM bastaria o uso de dois timers: um para a elevação do sinal a 1 com uma frequência fixa de 50 Hz e um segundo para a descida do sinal a zero depois de um determinado período de tempo após a elevação. Desta forma obtém-se um sinal de PWM cujo período de tempo a 1 corresponde ao duty-cycle desejado para definição da posição do servo.

Fig. 34: Geração de um sinal de PWM através de dois timers.

A Fig. 34 esquematiza este procedimento fazendo uso dos timers 1 e 2:

O timer 1 é programado para gerar uma interrupção a cada 20ms (50Hz de frequência):

A cada instanciação o pino de PWM é elevado a um;

Após cada interrupção do timer 1, o timer 2 é programado para gerar uma segunda interrupção após um período de tempo correspondente ao duty-cycle desejado (entre 1 e 2 ms):

Após a ocorrência desta interrupção, o pino de PWM é baixado a zero.

No entanto, importa escalar este procedimento para a geração de três sinais de PWM que, embora todos tenham a mesma frequência, o duty-cycle gerado para os três servos devem ser independentes entre si. Uma solução poderia ser o uso de timers extra, mas dada a limitação de recursos, desenvolveu-se um método que permite o controlo de N servos usando apenas estes dois timers, cuja quantidade N apenas depende da velocidade de processamento do CPU:

O timer 1 é programado para gerar uma interrupção a cada 20ms (50Hz de frequência):

A cada instanciação o pino de PWM é elevado a um;

Após cada interrupção do timer 1, o timer 2 é programado para gerar uma segunda interrupção após um período de tempo correspondente ao duty-cycle mínimo: 1ms.

Na ocorrência da primeira interrupção, o timer 2 é reprogramado para gerar interrupções de alta frequência de periodicidade correspondente à variação mínima de posição do servo Δpos. Para um passo de 1º, o período será:

A cada instanciação da interrupção de alta frequência (passo de 5.56μs), a cada servo é verificado se o PWM correspondente deve baixar a zero nessa iteração. Em caso negativo, nada é feito e a próxima iteração é aguardada para uma nova avaliação.

Na última iteração (correspondente ao duty-cycle máximo) todos os sinais de PWM devem estar a zero e o timer 2 é desligado. O processo é repetido na próxima interrupção do timer 1.

Fig. 35: Organização temporal das interrupções na geração do PWM.

A Fig. 35 demonstra bastante bem este processo. A cada servomotor é atribuído uma variável indicadora da largura de impulso a aplicar, que nada mais é o número de iterações durante as interrupções de alta frequência a manter o sinal a 1. Após a primeira interrupção um contador é utilizado para contagem das iterações que vão decorrendo entre o período de 1 a 2 ms e em cada uma delas é comparado com a variável atribuída a cada servomotor da duração do impulso. Quando o contador for igual a essa variável, o sinal de PWM correspondente é baixado a zero. Desta forma a N servomotores são utilizadas N variáveis, sendo que a única limitação é o CPU ter tempo de verificar todos os sinais de PWM e aplicar quaisquer modificações dentro do intervalo Thf=5.56μs, pelo que a quantidade máxima de servos é dependente da velocidade do CPU. Para uma frequência de relógio de CPU de 10MHz a quantidade máxima de instruções assembly que podem ser executadas em cada iteração, é por isso:

Esta quantidade máxima não nos dá grande liberdade para o cumprimento da deadline dos 5.56μs, pelo que ou aumentamos a velocidade de CPU, ou diminuímos o número de servos a controlar, ou então, na impossibilidade de modificar estes parâmetros, aumentamos o período Thf pelo aumento do passo de posição Δpos.

Para o nosso caso em concreto, pretendemos controlar três motores utilizando um CPU com 10MHz de velocidade, pelo que só possuímos, para avaliar cada servo, cerca de 18 instruções. Como para além do processamento também entram nas contas o atraso de atendimento à interrupção, mais o código extra executado até chegar à secção de código de interesse, este limite é facilmente violado. Dada a impossibilidade de aumentar ainda mais a velocidade de CPU nem de querer aumentar o período Thf sob pena de perda de resolução do servo, reestruturou-se a forma de atendimento às interrupções de forma a eliminar o tempo extra resultante do tempo de atendimento à interrupção mais o código extra. Tal foi conseguido fazendo com que o atendimento às interrupções durante o período de descida do PWM, fosse feito por polling dentro da própria RSI, em vez do procedimento normal de saída e reentrada nesta rotina.

A Fig. 36 apresenta o algoritmo adoptado em que, na ocorrência da primeira interrupção do timer 2 a entrada na RSI é feita, e só volta a sair dela após o atendimento por polling de todas as interrupções de alta frequência até ao fim da zona de descida do PWM. Desta forma garante-se que em cada iteração, o CPU só se dedica ao bloco de código de avaliação da descida de PWM conseguindo cumprir assim a deadline imposta dos 5.56μs.

A única desvantagem desta técnica prende-se com a impossibilidade de execução simultânea de outras tarefas durante este período. No entanto tal não é problemático dado que só corresponde a 5% de tempo de cada período de PWM.

Fig. 36: Atendimento às interrupções de alta frequência.

Leitura Sensorial do Servomotor

Embora, por defeito, o modelo escolhido não disponibilize externamente os sinais de posição e de velocidade para feedback, é possível extrair o sinal de posição dado o fácil acesso ao potenciómetro interno. Desta forma, abriram-se todos os servomotores e adicionou-se um fio extra ligado ao terminal do potenciómetro indicador da posição angular do eixo (Fig. 25). Já quanto à velocidade desconhece-se a forma de aceder a este dado. Tendo acesso à informação da posição, é possível monitorar constantemente a posição do servo a partir da unidade de controlo local e transmiti-la ao PC através da rede de comunicações, podendo avaliar continuamente a performance de cada actuador.

Deslocando o servo, na ausência de carga, verifica-se uma variação da tensão de saída entre 0.8 e 1.8 V ao longo dos 180º de excursão, podendo ser amostrado pelo PIC através da ADC. Utilizando as tensões de referência standard para a ADC (0 e +5V) precisamos de pelo menos 10 bits para o quantificador, tendo em conta que necessitamos de uma resolução que permita distinguir 180 posições possíveis (resolução de 1º).

Como a ADC do PIC oferece-nos a opção de quantificação a 10 bits tal é conveniente aproveitar.

No entanto, a medição não é tão simples como amostrar a tensão de saída quando desejado, pois na presença de cargas no eixo e/ou de velocidades elevadas surge um estranho impulso acima do nível de tensão correspondente à posição, pelo que se a medição for executada no momento do impulso o resultado será falso. Tal motivo é devido ao facto de nos modelos da HITEC, contrariamente aos da FUTABA como se verifica na Fig. 29, a tensão de referência (massa) do potenciómetro não é a mesma que para a ADC do PIC, pelo que, embora para a electrónica de controlo interna este sinal corresponderá sempre à posição do servo, para a perspectiva da ADC, este sinal possuirá oscilações na forma de impulsos ao longo do tempo, mesmo sem variar a posição do servo.

Testando diversas situações através do osciloscópio concluímos que estes impulsos possuíam propriedades não casuais:

O impulso ocorre acima da tensão indicadora da posição;

A amplitude do impulso é constante e apenas varia com a tensão de alimentação;

Período de repetição coincidente com o PWM aplicado (50Hz);

Ponto de início sincronizado com o fim do impulso de PWM;

Largura dependente da carga e da velocidade.

Fig. 37: Impulso de tensão medido na presença de cargas/velocidades elevadas.

O último aspecto foi o que se revelou mais interessante: quando se aumentava a carga aumentava-se a velocidade, a largura deste impulso aumentava. Tentando relacionar a largura deste impulso com a massa da carga efectuou-se o seguinte teste: fazia-se deslocar o servo para um conjunto de posições entre -90º e +90º, e para cada uma delas o actuador era deixado em repouso e media-se a largura do impulso. Desta forma, assegurávamos que a largura medida apenas era devida à gravidade (sem a interferência da velocidade). Esta experiência foi executada para duas cargas de massas diferentes, uma aproximadamente dupla da da outra.

Fig. 38: Relação entre a posição e a largura de impulso.

Analisando cada carga à parte, verifica-se o comportamento sinusoidal ao longo das diversas posições sugerindo a relação com a função seno. Ora pela Equação 1 se conclui que a largura do impulso de tensão está directamente relacionada com o binário gravítico. Relacionando os valores entre as duas cargas, tal fundamento é reforçado dada a relação de multiplicação entre os dois conjuntos – aproximadamente de dois!

Ora como se sabe a corrente está directamente relacionada com o binário...

... pelo que a largura de impulso é um indicador da corrente drenada pelo servo. Por esta razão, de agora em diante, este impulso será denominado por impulso de corrente. Este comportamento confirma a actuação sobre o motor DC de uma forma digital, também utilizando sinais no formato de PWM através da ponte H.

Note que, pelas características do sinal de posição, é possível medir tanto a posição como a corrente a partir desta única fonte, sem a necessidade de qualquer electrónica adicional para a medição de corrente!

Medição de Corrente

No ano anterior sugeriu-se um método para a medição de corrente baseado no uso de uma resistência de baixo valor em série com a alimentação do servo.

Fig. 39: Configuração possível para medição da corrente.

Embora esta forma permita uma leitura de corrente mais simplificada e de resultado sempre disponível (sem a necessidade de algoritmos de medição de largura de impulsos) acrescenta muitos mais inconvenientes do que vantagens:

Emissão excessiva de calor nas situações de maior consumo de corrente.

A presença da resistência provoca um aumento da corrente consumida pelo servo. Tal é explicado pelo facto de na resistência se verificar uma queda de tensão o que resulta numa diminuição da tensão de alimentação do servo, que será tanto maior, quanto maior for a corrente consumida. Com esta diminuição, o servo tem de realizar um maior esforço o que equivale a aumentar a corrente drenada.

Dada a queda de tensão na resistência, a tensão de referência (massa) do servo varia de acordo com a corrente consumida, o que interferirá na medição de posição uma vez que a ADC não usa a mesma tensão de referência. Desta forma, além do sinal de posição do potenciómetro ser afectado de impulsos adicionais, também será afectado pelo offset introduzido pela queda de tensão da resistência.

O último ponto sobressai-se pelo facto de “estragar” o sinal de posição e exigir também a medição da tensão referência do servo para compensar a variação: simplifica na medição de corrente, mas dificulta na de posição.

Em alternativa, optou-se por remover estas resistências pelo seu curto-circuito nas placas slave e recorrendo a ferramentas baseadas em software medir a corrente pela determinação da largura do impulso de corrente.

Fig. 40: Organização das interrupções (setas) na medição sensorial.

A Fig. 40 descreve bem a estratégia adoptada. Uma interrupção baseada no timer 0 é gerada durante todo o período de PWM com uma periodicidade de 200μs. Apenas na zona de descida do PWM ela é inibida não se pretendendo interferir com as interrupções de alta frequência. Sempre que o timer 0 gera uma interrupção, a tensão de saída do potenciómetro é medido e é comparado com um determinado limiar logo após o “ADC reading”. Se estiver abaixo desse limiar considera-se a não ocorrência do impulso de corrente, mas caso esteja acima, uma variável contadora da largura de impulso é incrementada. No fim do período de PWM (considerado logo após a zona de descida de PWM) esta variável contadora indicará a largura do impulso medido no período de PWM anterior. De notar que a resolução de medição da largura de impulso é tanto maior quanto menor for a periodicidades das interrupções. No entanto não convém definir períodos muito curtos sob pena de não atribuir suficiente largura de banda de CPU para o programa principal ser executado completamente num período de PWM. A periodicidade de 200μs foi o melhor valor encontrado e permite executar no total 95 medições, ou 31 para cada servo, ao longo de um período de PWM excluindo a zona de descida de PWM, ou seja, ao longo de 19 ms.

O valor do limiar a considerar depende da amplitude do impulso, mas sabendo que este apenas varia com a tensão de alimentação, mantendo uma amplitude sempre superior a 1.0V utilizando baterias de 7.4V, definiu-se o limiar como 1.0V. Note que este limiar encontra-se acima da tensão DC pelo que é necessário em cada período de PWM medir a tensão mínima e utilizá-la para o período seguinte como sendo a tensão base dos impulsos.

Contudo este método possui uma desvantagem. Em situações de elevada exigência, em que a corrente consumida é próxima da máxima, a largura do impulso de corrente pode ocupar praticamente todo período de PWM inibindo a capacidade de leitura da posição e da largura do impulso, dado que o valor mínimo corresponde ao topo do impulso de corrente. É, por isso, de evitar que esta situação se alcance, quer impondo limites físicos, quer pela adopção de estratégias de controlo que minimizem a corrente a consumir – uma delas é a limitação de velocidade.

Medição da Posição

Já foi referido anteriormente que a componente DC da saída do potenciómetro está relacionada à posição do servo, pelo que a tarefa de guardar o valor mínimo deste sinal, executada para efeitos de detecção do impulso de corrente, é aproveitada para o cálculo da posição angular do servo.

Convencionando a tensão mínima como correspondendo à posição +90º e a tensão máxima como -90º, recorrendo a uma relação linear podemos determinar a posição com ADCres igual ao resultado da ADC, m sendo a relação entre a variação de posição e a variação de ADCres (declive) e b o valor referência quando ADCres é nulo (ordenada na origem).

(Equação 2)

...com ADC(x) sendo o valor convertido pela ADC correspondente à tensão x (V):

Logo

Esta conversão é implementada no PIC através da macro:

#define POS(volt,...) (origin - (volt)*SLOPE/QUOCIENT)

... em que origin corresponde à ordenada na origem b, SLOPE/QUOCIENT é o declive m, e volt é o resultado da conversão da ADC (ADCres). Note que o declive m é inferior à unidade daí a necessidade do formato SLOPE/QUOCIENT para poder utilizar apenas valores inteiros (SLOPE<QUOCIENT).

Contudo, não é possível garantir que a gama da tensão de saída esteja compreendida entre 0.8 e 1.8V para qualquer servomotor, podendo-se verificar variações até cerca de 0.2V. Tal é problemático para o cálculo da posição angular, pois estamos a considerar uma relação de correspondência constante quando tal não acontece entre dois actuadores. No entanto, note que esta diferença é mais notória para o parâmetro b do que para o m. O valor de b exige que os extremos de posição possuam exactamente os valores enunciados, mas para o valor de m só é exigido uma excursão entre extremos de 1.0V o que já é mais frequente acontecer. Este pequeno detalhe permite-nos assim a utilização de uma rotina de calibração simples de modo a acertar o parâmetro b de acordo com o servo a lidar.

Considerando o parâmetro m constante, o que é uma aproximação aceitável, sempre que o sistema é ligado, se assegurarmos que cada servo está numa posição conhecida à priori, é fácil calcular o valor de b através da Equação 2 e utilizá-lo nas medições consequentes.

A rotina de calibração é executada sempre que o sistema arranca e segue o seguinte algoritmo:

A primeira mensagem de actuação já chegou? Só passar para o passo 2, quando afirmativo;

Actuação sobre os servomotores de forma a cumprir a posição solicitada pela unidade master;

Esperar dois segundos para a cumprimento do movimento e estabilização do sinal de posição;

Amostragem de 25 medidas da saída do servo (25 períodos de PWM de duração);

Cálculo da média aritmética do valor medido;

A partir da seguinte equação (baseada na Equação 2) determinar o valor de b a partir da posição solicitada pelo master e do valor médio ADCres:

Activação dos filtros de medição sensorial.

Desta forma, a medição da posição é adaptado a cada servomotor de uma forma personalizada com mínimos erros de cálculo (apenas dependem de m).

Organização das interrupções de medição sensorial

A medição de tensões analógicas a partir de uma ADC, como se sabe, não é imediata, demorando um determinado intervalo de tempo até o resultado estar pronto. Para se proceder à amostragem é necessário percorrer um conjunto de passos:

Fig. 41: Algoritmo de leitura dos três servomotores.

Selecção do entrada do multiplexer correspondente ao servo a ler;

Esperar que o multiplexer efectivamente seleccione a entrada e tenha uma saída estável (alguns microsegundos) – tempo de estabilização;

Esperar cerca de 20μs para a ADC possuir um valor estável na sua entrada – tempo de aquisição;

Iniciar conversão da ADC;

Esperar que a ADC termine a conversão (cerca de 40μs) – tempo de conversão;

Leitura do valor convertido e processamento (cerca de 10μs);

Fig. 42: Multiplexagem na leitura dos servos.

Só depois de executados os primeiros 5 passos, a tensão de saída do servo pode ser medida com segurança. Somando estes períodos de tempo, incluindo o tempo de execução do código de processamento do resultado, verificamos que todo o processo é executado em menos de 80μs, pelo que restam 120μs para execução de outras tarefas iniciadas pela função main.

No entanto, não nos esqueçamos que temos aplicar este processo a três actuadores. Para não sobrecarregar o CPU de repetir este procedimento três vezes em cada período de 200μs optou-se por efectuar multiplexagem na leitura, ou seja, em cada período de 200μs apenas um servo é lido, mas no período seguinte o servo a ler é outro, completando-se a leitura dos três servos ao fim de três períodos (600μs). Logo após a leitura do terceiro, volta ao primeiro repetindo de novo todo o processo (Fig. 42).

A Fig. 41 apresenta o algoritmo implementado, com uma gestão temporal mais eficiente, seleccionando a entrada do multiplexer correspondente ao servo seguinte no fim do código que processa as interrupções provenientes do timer 0 (RSI), e não no início, deixando livres 150μs entre o fim da execução do código e o atendimento da próxima interrupção para estabilização da saída do multiplexer e o cumprimento do tempo de aquisição da ADC. Desta forma, quando o timer 0 voltar a gerar uma interrupção poder-se-á arrancar com a ADC de imediato apenas tendo de esperar por uma interrupção por parte da ADC indicando a prontidão do valor convertido. Em termos de tempo efectivo envolvido na leitura apenas temos os 10μs do código de processamento do valor convertido, uma vez que sempre que é necessário introduzir um tempo de espera o CPU não fica bloqueado em modo de espera, mas retorna ao programa normal deixando encarregues às interrupções a tarefa de voltar prosseguir a sequência de operações.

Um outro aspecto a salientar é a coabitação entre as interrupções de medição sensorial e as interrupções para actuação (Fig. 35 e Fig. 40). Dada a igualdade, em termos de prioridade entre os dois tipos, um mecanismo que evite a interferência entre os dois torna-se fundamental para evitar atrasos que comprometam a fiabilidade de funcionamento destes dispositivos. Um atraso na interrupção para a gestão da actuação poderia resultar num sinal de PWM modificado que alteraria sem intenção a posição do servo, ou um atraso nas interrupções envolvidas na medição poderia comprometer a validade dos resultados. Para evitar problemas deste género impuseram-se as seguintes condições:

As interrupções gestoras do sinal de PWM nunca devem sofrer interferência por parte de outras e devem ser sempre cumpridas no instante a que foram programadas;

As interrupções gestoras da medição sensorial nunca podem ser interrompidas a meio da sua execução, ou seja, quando a primeira operação é executada – arranque da ADC – é fundamental a sua execução sem atrasos até ao fim. Deste modo o processo de leitura sensorial deve ser considerado como uma operação atómica. Contudo este processo, como um todo, pode ser inibido de modo a não interferir com as interrupções gestoras do PWM.

O mecanismo de coabitação deve então seguir este procedimento: em cada interrupção proveniente do timer 0 (medição sensorial) ainda antes de se proceder à primeira operação – o arranque da ADC – deve-se verificar se há tempo para a execução completa de todo o processo de medição ainda antes da próxima interrupção gestora do PWM:

Antes da interrupção do timer 1 responsável por elevar o sinal de PWM a 1;

Antes da primeira interrupção do timer 2 que inicia a zona de descida do PWM a 0.

O intervalo de tempo mínimo considerado, para o processo de medição sensorial estar autorizado a iniciar deve corresponder à periodicidade do timer 0, ou seja, 200μs. Se para a próxima interrupção de actuação faltar mais de 200μs a medição sensorial é autorizada a arrancar, pois é garantido que finaliza antes dela chegar. Quando a zona de descida de PWM começa, as interrupções de medição sensorial devem ser inibidas de modo a poder dedicar toda a largura de banda do CPU para as interrupções de alta frequência. Quando esta zona finaliza os dados sensoriais amostrados durante o período de PWM anterior são tratados e estas interrupções são reactivadas.

Quanto ao processamento do sinal de saída do servo, a Fig. 44 descreve o algoritmo utilizado para cada servo em cada iteração ao longo de um período de PWM (caixa “converted voltage is processed” da Fig. 41).

Fig. 43: Processamento final (fim do período de PWM).

Fig. 44: Algoritmo de processamento da tensão medida para cada servomotor.

No fim de cada período de PWM, os valores da tensão mínima e da largura de impulso são processados em cada servo para determinação da posição, velocidade média e corrente consumida (Fig. 43):

Cálculo da posição com base na tensão mínima: A posição correspondente ao valor mínimo da ADC é calculado a partir da relação linear...

Filtragem da posição: O valor da posição obtido é filtrado de modo a evitar variações bruscas. São utilizados dois filtros:

Filtro de média não linear: este filtro, muito usado em processamento de imagem, é usado apenas para remover picos nos valores medidos, sem interferir de de nenhuma forma no sinal na ausência deles. O atraso introduzido é apenas de uma amostra.

y	→ amostra obtida

y_max	→ máximo valor da amostra admitido

y_min	→ mínimo valor da amostra admitido

y_new	→ Valor filtrado

y_prev	→ Valor da amostra anterior (não filtrado)

// Limitação da saída

if (y>y_max) y_new=y_max;

else if (y<y_min) y_new=y_min;

else y_new=y;

// Actualização das amplitudes limite

if (y>y_prev) {

y_max=y;

y_min=y_prev;

}

else {

y_max=y_prev;

y_min=y;

}

// Actualização da saída anterior

y_prev=y;

Filtro de média linear: este filtro é aplicado a seguir ao não linear e tem como função a suavização do sinal resultante. Apenas é feita uma média igualitária entre a nova amostra e a anterior.

ynew_prev → Valor filtrado anterior

// Filtro Passa-baixo

y_new = (y_new+ynew_prev)/2;

ynew_prev = y_new;

Normalização da largura do impulso de corrente: De modo a permitir a redefinição da periodicidade do timer 0 (timer0per) sem interferir no resultado da largura do impulso de corrente, o resultado é normalizado para a gama entre 0 e 100 (percentagem) através de uma regra proporcional:

Estimação da velocidade: Embora não seja possível medir directamente a velocidade, é possível estimá-la a partir da variação de posição. Definindo a velocidade mínima mensurável como sendo 10º/s precisamos de medir a variação de posição correspondente a 100ms uma vez que o valor mais pequeno que conseguimos medir é 1º. No entanto, é desejável que tenhamos sempre a velocidade disponível todos os 20 ms sem ter que esperar 100 ms para poder ler este dado. Tal é possível usando arrays circulares (Fig. 45):

Um array de 5 posições pode armazenar até 5 posições antigas – pos(n-1) até pos(n-5) – em que a posição mais antiga corresponde à posição de há 100 ms atrás (20ms*5). Se em cada período de PWM armazenarmos a posição acabada de medir no elemento mais antigo, em todos os 20 ms temos disponível o valor de posição de há 100ms atrás, ainda antes da actualização do array com o novo valor. Desta forma, a cada 20ms, podemos calcular a variação de posição verificado nos últimos 100 ms.

Fig. 45: Array circular para armazenamento de posições.

Este array tem o nome de circular, pois o elemento mais antigo, a que chamaremos de index, está sempre em contínua rotação ao longo do array: quando introduzimos um valor no elemento mais antigo, esse elemento passa a ser o mais novo e o elemento a seguir passa a ser o mais antigo.

Estimação da velocidade:

Actualização do array:

Actualização do elemento mais antigo

Cálculo da largura de impulso média: Dada a instabilidade do valor de corrente medido (largura de impulso) implementou-se o cálculo da média de todos os valores de corrente medidos nos últimos 100ms. De modo a ter sempre um valor actualizado todos os 20ms seguiu-se a mesma estratégia que para a estimação de velocidade: um array circular para armazenamento dos cinco valores de corrente mais recentes. A cada 20ms é introduzido o novo valor medido e é calculada a média do conjunto considerando esse valor como a final.

Actualização da base de dados local (sensorial): Ver secção 1.2.4.1 (base de dados local).

Armazenamento da tensão mínimo medida: necessário para o conhecimento da tensão base dos impulsos de corrente para o período de PWM seguinte.

ESTUDO DO SERVOMOTOR EM MALHA ABERTA

Agora que os detalhes de funcionamento do microcontrolador foram apresentados, vamos agora estudar o comportamento do servomotor sob determinadas condições de modo a avaliar a sua performance. O estudo será feito do ponto de vista de um sistema no qual aplicaremos uma entrada e queremos saber qual é a sua resposta (Fig. 46).

Fig. 46: Representação do servomotor por uma função de transferência G(s).

Ora, tendo sido discutido o funcionamento interno do servomotor na secção 2.1 (Fig. 29), infelizmente apenas era uma aproximação ao nosso modelo e além disso não conhecemos os valores das grandezas enunciadas. Por tudo isto iremos estudar o comportamento do sistema G(s), desconhecendo a sua função de transferência.

Embora, pudéssemos tentar encontrar esta expressão experimentalmente através de métodos bastante conhecidos como é o caso das regras de Ziegler-Nichols, tal não nos leva muito longe, pois como é sabido, as juntas da plataforma humanóide estão sujeitas a variações de inércia pelo que o comportamento dos servos torna-se bastante não linear. Teríamos, por isso, uma função de transferência diferente para cada carga aplicada.

Este capítulo tem como objectivo estudar primeiramente a resposta em malha aberta do servo, ou seja, aplicando um sinal (ou uma sequência de sinais) de PWM na entrada r(t), analisar a resposta pela leitura da posição angular y(t). Rotinas em MatLab para uso pela unidade principal foram especialmente construídas para este efeito enviando para o slave respectivo uma ordem de actuação, e logo de seguida monitorar a posição do servo o tempo suficiente para permitir captar informação informação importante.

Algum vocabulário não muito comum será utilizado pelo que convém, antes de tudo, esclarecer o seu significado para evitar qualquer dúvida ou ambiguidade:

Tempo de crescimento/subida: tempo que a resposta demora a crescer entre 10% e 90% da distância total a percorrer;

Tempo de atraso: instante que a resposta atinge 50% da distância total percorrida;

Tempo de pico: instante em que a resposta passa pela posição máxima/mínima (depende do sentido de deslocamento);

Tempo de estabelecimento: tempo necessário para que a resposta entre, sem voltar a sair , numa determinada vizinhança , previamente especificada , do valor final da resposta. Dois a cinco por cento é normalmente a margem especificada.

Overshoot: oscilação verificada em torno do valor final no fim da resposta. O seu valor corresponde normalmente à relação entre a margem máxima de oscilação e a distância total percorrida.

Erro em regime estacionário: diferença entre o valor final e o valor desejado após estabilização da resposta.

Estas definições correspondem a características da curva de resposta do sistema a testar e normalmente são usados para avaliar a sua performance (Fig. 47). No caso de um actuador ideal, todos estas características deviam ser nulas, mas infelizmente tal não existe na realidade: os sistemas levam tempo a reagir e a atingir o seu valor final, e por vezes podem entrar em oscilação (overshoot) quando a entrada é demasiado exigente. Este capítulo procurará perceber o quanto os servomotores se desviam da resposta ideal, e posteriormente tentaremos encontrar soluções para a sua melhoria.

Fig. 47: Exemplo da resposta de um sistema (Gf) com a indicação das suas características.

Resposta ao Degrau em Malha Aberta

Com uma carga aplicada no eixo, segundo a forma apresentada na Fig. 32, inicializou-se o servo na posição inicial de -45º e enviou-se um comando de actuação para a posição de +45º – um degrau é aplicado. Monitorizou-se o percurso percorrido através do comando de leitura de posição durante 1.5s para duas cargas diferentes: 258 e 1138g (Fig. 48).

Fig. 48: Comparação das respostas ao degrau para duas cargas no percurso de -45 para +45º.

Requested position º	measured position º	Error º	Torque (Nm)
-80	-80	0	0.198
-60	-62	2	0.569
-40	-45	5	0.872
-20	-28	8	1.069
0	-9	9	1.138
+20	+11	9	1.069
+40	+33	7	0.872
+60	+55	5	0.569
+80	+80	0	0.197

Tabela 31: Erros em regime estacionário em diferentes posições para uma carga de 1138g.

Comparando as respostas da carga de 258g com a de 1138g, constata-se uma diferença dos tempos de subida evidenciando um atraso maior para cargas elevadas, o que é compreensível uma vez que o esforço dispendido é maior. Um segundo aspecto é a diferença no erro em regime estacionário: para a massa leve o erro é praticamente nulo, mas para a mais pesada já é mensurável um erro de cerca de 9º.

Adicionalmente, fez-se uma experiência tendo em vista estudar a relação do erro em regime estacionário com o binário resultante da força gravítica. Deslocando o servo para um conjunto de posições conhecidas, para cada uma delas, esperou-se pela finalização do movimento e pela estabilização do sinal de posição, anotando de seguida a posição medida pelo microcontrolador (Tabela 31). Comparando a posição solicitada com a efectiva observa-se que o erro aumenta à medida que a posição se aproxima do ponto 0º, o que demonstra que quanto maior é o binário gravítico maior é a dificuldade em atingir a posição final resultando num erro em regime estacionário não nulo.

Outro aspecto a salientar é a visível instabilidade durante a realização do trajecto o que é mais notório para a carga elevada do que para a baixa. Além disso observa-se um salto no início da trajectória para posições inferiores a -45º seguidamente com inversão de velocidade em direcção ao valor final. No entanto este comportamento não foi o que aconteceu realmente, tendo-se observado um movimento rápido e sem oscilações durante todo o percurso. Tal sugere que a posição lida a partir do potenciómetro está a ser perturbada por algo.

Fig. 49: Resposta ao degrau de -45 para +45º com uma carga de 924g. Fig. 50: Resposta ao degrau de +45 para -45º com uma carga de 924g.

Os gráficos da Fig. 49 e Fig. 50 apresentam a execução do mesmo percurso mas nos dois sentidos para uma carga de 924g. Como se pode observar, continuam a surgir os picos de corrente no trajecto inicial em ambos os casos. No caso da descida de +45 para -45º verifica-se um abaixamento brusco na posição medida até metade do trajecto onde ocorre uma recuperação.

A presença de acelerações bruscas, como acontece no arranque da trajectória, pode provocar picos de corrente, que em termos sensoriais, correspondem a um impulsos de corrente que podem ocupar toda o período de PWM. Nestas circunstâncias a posição considerada como sendo a tensão mínima deixa de poser ser medida sofrendo um aumento em tensão para o topo do impulso, que, em termos de posição angular, corresponde a uma descida brusca, tal como os gráficos nos mostram.

Neste sentido, pode-se dizer que a presença do impulso de corrente está a mascarar as medições de posição do servo agravando os resultados na presença de cargas elevadas. No entanto, tal deixa de se verificar nos últimos instantes ainda antes da finalização da trajectória e durante a fase estacionária, demonstrando que não só a massa da carga aumenta as exigências de corrente, como também a velocidade e as acelerações bruscas.

Controlo de Velocidade

Como se pode concluir, os servomotores são muito sensíveis a velocidades e acelerações bruscas provocando muito facilmente picos de corrente que impedem a correcta leitura da sua posição. De modo a prevenir este efeito, tentou-se introduzir algum controlo de velocidade de modo a eliminar estas variações bruscas, com a adicionante de ganharmos na capacidade de poder regular a velocidade segundo as nossas necessidades e de possibilitar movimentos mais suaves. No entanto, como não temos possibilidade de fazer o controlo directo de velocidade, utilizar-se-á o controlo de posição para executar trajectórias que no seu todo definem uma velocidade média que pode ser configurável.

Até agora temos vindo a aplicar degraus de posição aos servos tal como exemplifica a Fig. 51. Se aplicarmos uma sucessão de degraus de variação de amplitude e intervalo de tempo o mais pequenos possíveis, cuja amplitude final de cada degrau aumenta proporcionalmente até atingir a posição desejada, temos a aplicação de uma rampa de posições cujos extremos de posição e duração total definem a velocidade média do movimento. A Fig. 52 apresenta um exemplo de uma trajectória em rampa desde -45º até +45º com uma duração de 1.8s, o que corresponde a uma velocidade média de 50º/s.

Fig. 51: Aplicação de um degrau de -45º para +45º no instante t=1,8s. Fig. 52: Aplicação de uma rampa de posição de velocidade média 50º/s.

Enquanto que a aplicação de um degrau introduz um delta de Dirac na velocidade e na aceleração provocando facilmente picos de corrente, a trajectória em forma de rampa contêm essas variações bruscas pela aplicação sucessiva de pequenos degraus o que limita a velocidade do servo e também a sua necessidade de consumo de corrente. Esta trajectória pode ser implementada através da Equação 3.

com Ta=20ms (período de PWM).	(Equação 3)

No entanto, se quisermos optimizar ainda mais o consumo de corrente, podemos implementar trajectórias, de modo a limitar os deltas de Dirac de aceleração que continuam a verificar-se no caso da rampa. Se além de variarmos a posição, também variarmos a velocidade de modo a ser nula no início e no fim da trajectória, a necessidade de consumo de corrente decai ainda mais. Tal é exequível através de uma equação polinomial de terceira ordem que introduz velocidade zero no início e no fim de cada trajectória.

Fig. 53: Trajectória polinomial de terceira ordem. Fig. 54: Comportamento da velocidade e da aceleração na trajectória polinomial.

Como se pode verificar, deixa de se verificar deltas de Dirac até à segunda derivação da posição (aceleração). Se quiséssemos ir ainda mais longe, podíamos aumentar a ordem do polinómio de modo a garantir aceleração nula no início e no fim. No entanto tal não foi implementado dado ao facto de que quanto maior é a ordem do polinómio maior é a velocidade instantânea a meio do trajecto. Ordem três corresponde a um bom compromisso para o que é preciso.

Respostas em malha aberta

Voltando a amostrar a resposta dos servos em malha aberta, agora com a implementação de trajectórias, podemos observar, para o caso da rampa (Fig. 55 e Fig. 56), a estabilidade acrescida nas respostas qualquer que seja a carga aplicada. Os efeitos de picos de posição e as oscilações durante o percurso praticamente desapareceram demonstrando o consumo controlado de corrente com esta solução.

Fig. 55: Resposta à rampa com duas cargas diferentes (Δp=5º, Δt=100ms). Fig. 56: Resposta à rampa com uma carga pesada (Δp=5º, Δt=100ms).

A Fig. 57 apresenta as respostas correspondentes às trajectórias polinomiais com a observação dos mesmos resultados que com a rampa.

Fig. 57: Resposta ao polinómio para duas cargas diferentes (Ttraj=1s).

No entanto, continua-se a verificar o crescente tempo de atraso e erro em regime estacionário com a carga aplicada em relação à trajectória esperada. Para corrigir estas características torna-se importante realizar alguma espécie de controlo adicional ou ao nível do controlador interno do servo, ou externamente, usando o sinal de posição como feedback e o sinal de PWM para controlo da posição.

ESTUDO DO SERVOMOTOR EM MALHA FECHADA

Este capítulo descreve algumas estratégias para melhoria da resposta dos servos, em termos de:

tempo de subida;

tempo de estabelecimento;

erro em regime estacionário.

O objectivo será minimizar ao máximo estes parâmetros de modo a aproximar ao máximo a resposta da trajectória solicitada.

Várias metodologias podem ser seguidas para compensação, como por exemplo a substituição da electrónica de controlo dos actuadores. No entanto, procura-se por métodos de compensação que não modifiquem estas unidades de forma a permitir a fácil substituição em caso de necessidade. Por razões de simplicidade realizar-se-á o controlo externamente ao servo usando para isso o microcontrolador para implementar a lei de controlo mais adequada. Com a implementação do controlador por software, é possível alterar os parâmetros ou a estrutura do controlador ou modificando simplesmente o código, ou por troca de informação do PC para o slave respectivo, evitando assim intervenções ao nível do hardware.

O Controlador

A Fig. 58 descreve a metodologia a usar: o controlador representado pelo bloco GC(z) é implementado ao nível do microcontrolador que fará uso do sinal de PWM u(t) e do sinal de posição p(t) como feedback para comparação com a posição desejada r(t).

Fig. 58: Controlo externo do servomotor.

A partir daqui já não se dirá que um determinado duty-cycle do PWM corresponde a uma determinada posição, pois tal depende muito da inércia aplicada sobre o eixo, mas simplesmente é um sinal de controlo que para uma determinada carga corresponde a uma determinada posição. Para tal, a lei de controlo GC(z) seguirá um método para procurar o sinal de PWM mais adequado para que o sinal de posição medido p(t) coincida com a posição solicitada r(t). Esse método é apresentado na e é baseado num compensador clássico do tipo PID.

Fig. 59: Compensador PID incremental.

Este compensador é baseada na equação de compensação PI-D no domínio de Laplace, sendo convenientemente adaptada para o caso digital:

No domínio digital (z) temos:

Colocando a equação na forma incremental:

Em termos numéricos:

... em que Δ corresponde a uma variação relativamente à amostra anterior.

De modo a minimizar a instabilidade resultante do aumento da ordem da equação diferencial substituamos na secção derivativa e(n) por r(n)-y(n) com r(t) constante. Desta forma a instabilidade da componente derivativa deixa de estar relacionado com as variações do sinal de referência3 Recomenda-se o teste da lei de controlo sem a inclusão do sinal de referência também na componente proporcional: .

Esta é a lei de controlo implementada no microcontrolador cujos parâmetros KI, KP e KD são passados pelo PC através da rede de comunicações. Prevê-se que a componente integral resolva o problema do erro em regime estacionário e as restantes componentes lidem com a velocidade do sistema, mas que fique bem claro, que não é lícito importar “ideias feitas” provenientes de disciplinas relacionadas com o controlo de sistemas, uma vez que nem sequer iremos lidar com entradas em degrau, mas sim numa sucessão de degraus, o que pode resultar em efeitos diferentes no resultado final.

Note que o controlo é realizado de forma incremental, calculando em cada iteração o incremento a dar ao sinal de controlo u(t) a fornecer ao servo. Optou-se por esta solução dadas as vantagens que oferece:

Não são necessárias variáveis de elevada resolução para armazenar o resultado de somas;

Protecção wind-up;

Transferência bumpless simplificada.

A alternativa ao algoritmo incremental exigiria a actualização de um somatório a cada iteração (elemento 1/s) o que implicaria o recurso a variáveis de elevada dimensão (longs ou doubles) para armazenar o resultado, o que nem sempre é favorável em arquitecturas baseadas em microcontroladores.

Além disso poderia ocorrer a requisição de uma posição fora dos extremos do servo (-90 e +90º) sem que a integração seja capaz de inverter a tendência do sinal de controlo uma vez que o seu incremento apenas se limita ao valor do extremo. Só ao fim de algum tempo, que não seria pouco, a soma pode ser suficiente para inverter a tendência, resultando numa perda significativa na reactividade da resposta. Este fenómeno denomina-se por wind-up e é devida à saturação do actuador. Embora haja bastantes soluções para este problema, a mais simples é a do algoritmo incremental, pois não existe qualquer integrador, fazendo com que numa situação de saturação o sinal de controlo u(n) deixe automaticamente de aumentar resultando imediatamente na inversão da tendência.

Um outro pormenor são as transferências bumpless, que não são nada mais do que a activação e desactivação do controlador em pleno funcionamento do servo. Pretende-se que quando o controlador é ligado ou desligado, o actuador não sofra qualquer variação brusca de posição. Embora não haja nenhum problema, por parte das duas soluções, na situação de desactivação do controlador, o problema surge na reactivação. Na solução com integrador, se a integração parar de funcionar durante a desactivação, quando reactivado, o sinal de controlo u(n) não corresponderá ao sinal r(t) que anteriormente era aplicado directamente, pois o resultado da integração deixou de ser actualizado, o que resulta num deslocamento brusco para uma posição desconhecida.

Por outro lado, se nunca se parar a integração corremos o risco da soma atingir valores excessivamente elevados ou mesmo de sofrer overflow, bastando para isso que os pedidos de actuação nunca correspondam ao valor de feedback – tal é frequente na presença de cargas. O resultado reflectir-se-ia em movimentos bastante oscilatórios na reactivação, acabando por provocar o fenómeno de wind-up!

Uma solução seria, em todas as reactivações, calcular o valor da soma de modo a que o sinal de controlo u(t) correspondesse ao valor de r(t) e inicializar a soma com esse valor. No caso do algoritmo incremental, se definirmos o valor u(n-1) como o último valor aplicado no servo, quer com o controlador ligado, quer desligado, escusamo-nos de qualquer preocupação com este procedimento.

No entanto há uma desvantagem com este algoritmo, resultante do aumento da ordem de um para dois na remoção do integrador. Na presença de ruído, este compensador torna-se mais sensível podendo levar o sistema mais facilmente à instabilidade. Daí a necessidade do formato PI-D em que é o sinal de saída e não o de erro o utilizado na componente derivativa eliminando qualquer possibilidade de instabilidade resultante de variações do sinal referência r(t). Mesmo assim recomenda-se o uso de valores baixos para o parâmetro KD.

Controlo Integral (I)

Vamos agora testar o controlador para várias cargas e percursos utilizando as trajectórias em forma de rampa e de polinómio de terceira ordem, usando como referência as respostas em malha aberta para a sua avaliação.

Comecemos por utilizar a componente integral, definindo os parâmetros KP e KD a zero. Experimentando o valor de 0.08 para KI para duas massas de elevado valor (Fig. 60 e Fig. 61) pode-se observar em ambos os casos a eliminação do erro em regime estacionário. No caso da Fig. 61 a diferença de dois graus é devida ao efeito da banda morta presente na entrada do controlador. Repare no sinal de saída do controlador solicitando ao servo uma posição mais elevada do que a desejada de modo a que ela seja cumprida na presença da carga eliminando assim o erro em regime estacionário.

Fig. 60: Resposta à rampa com uma carga de 675g (KI=0.08). Fig. 61: Resposta à rampa com uma carga de 1129g (KI=0.08).

Aumentando o valor de KI para 0.20 e realizando o trajecto de -45 para +45º com uma carga de 1129g (Fig. 62 e Fig. 63), além da ausência do erro em regime estacionário, o tempo de atraso da resposta relativamente à trajectória solicitada é melhorado na presença do controlador o que beneficia o tempo de estabelecimento.

Fig. 63: Erro da resposta da Fig. 51. Fig. 62: Resposta à rampa com uma carga de 1129g (KI=0.20).

De modo a estudar os efeitos do parâmetros KI na resposta do servo, realizou-se uma experiência, no qual para uma massa elevada de 924g efectuando um percurso fixo (-45 a +45º) experimentaram-se vários valores de KI. As respostas podem ser visualizadas da Fig. 64 à Fig. 67.

Fig. 64: KI=0.02 (m=924g) Fig. 65: KI=0.07 (m=924g) Fig. 66: KI=0.15 (m=924g) Fig. 67: KI=0.30 (m=924g)

Por observação, constata-se que para baixos valores, a resposta tende a atrasar-se demasiado, mas à medida que vai aumentando o tempo de atraso diminui com melhorias significativas relativamente à resposta em malha aberta. O caso da Fig. 67 evidencia a resposta típica para valores excessivos do KI: durante a fase transitória, tanto a posição medida como o sinal de controlo apresenta-se bastante oscilatório provocando no fim overshoot. No entanto seria desejável conter este overshoot de modo a melhorar ainda mais o atraso de cerca de 150ms medido pouco antes de se verificar as oscilações.

Quanto ao erro em regime estacionário, em todos os casos apresentados ele é eliminado, o que sugere que é suficiente a presença do integrador, independentemente do parâmetro KI, exceptuando-se, obviamente, o valor nulo.

Controlo Proporcional+Integral (PI)

Vamos agora adicionar a componente proporcional, mantendo a integral pois é fundamental para a eliminação do erro em regime estacionário.

Para melhor percebermos as vantagens da componente proporcional, primeiramente definamos um KI de modo a provocar um ligeiro overshoot na resposta do servo. A Fig. 68 e Fig. 69 apresentam um exemplo para uma carga de 924g com overshoot para KI=0.10 e KP =0.04.

Fig. 69: Erro da resposta da Fig. 55. Fig. 68: Fenómeno do overshoot para valores de KI elevados (carga de 924g)

Mantendo fixo o valor de KI em 0.10 vamos aumentar o parâmetro KP para 0.30 (Fig. 70 e Fig. 71).

Fig. 71: Erro da resposta da Fig. 57. Fig. 70: Correcção do overshoot com o aumento de KP (carga de 924g).

Pode-se constatar que o overshoot desapareceu sem afectar significativamente o tempo de atraso. De modo a melhor perceber estes resultados registaram-se várias respostas para diferentes valores de KP mantendo fixas a trajectória solicitada e a carga. A Fig. 72 e a Fig. 73 apresentam os resultados para dois valores diferentes de KI agora utilizando trajectórias polinomiais.

Fig. 72: Variação de KP para KI=0.05 (carga de 675g). Fig. 73: Variação de KP para KI=0.10 (carga de 675g).

Analisando o gráfico da Fig. 73 com KP=0.10 confirma-se o que se havia dito sobre os efeitos no overshoot: o overshoot é reduzido chegando mesmo a deteriorar o tempo de estabelecimento caso este valor seja excessivo, sem no entanto alterar significativamente o tempo de atraso.

Para um KI mais pequeno – 0.05 – (Fig. 72), pode-se evidenciar mais claramente os efeitos de um KP excessivo em valor: o tempo de estabelecimento é claramente prejudicado levando muito mais tempo a atingir o valor final, mas o tempo de atraso é melhorado acelerando o seguimento da trajectória no seu início. Ocorre, por isso, um ponto de cruzamento entre as diversas respostas quase coincidente com o término da trajectória.

Logo, conclui-se que deve haver um compromisso entre o tempo de atraso e o tempo de estabelecimento de modo a não perder demasiado num dos lados. O parâmetro KP deve, por isso, ser escolhido tendo em conta estes aspectos.

Controlo Integral+Derivativo (ID)

Substituindo a componente proporcional pela derivativa podemos observar que praticamente não afecta a acção integral, tal como se observar na Fig. 74 e na Fig. 75, pelo que não se encontra utilidade para este tipo de controlo.

Fig. 75: Resposta ao polinómio com KI=0.10 e KP=0.00 (carga de 675g). Fig. 74: Resposta ao polinómio com KI=0.05 e KP=0.00 (carga de 675g).

Controlo Proporcional+Integral+Derivativo (PID)

Introduzindo agora todas as três componentes podemos optimizar todos os parâmetros de modo a encontrar a melhor relação entre:

Tempo de atraso;

Tempo de estabelecimento;

Overshoot;

Oscilação durante a fase transitória.

Por análise de cada componente do controlador, apresentadas nas secções anteriores, já podemos relacionar estes parâmetros com cada um deles:

A componente integral está directamente relacionada com o tempo de atraso, sendo tanto menor quanto maior for o parâmetro KI. No entanto para valores excessivos começa a instabilizar com o surgimento de overshoot.

Resumindo:

Diminui o tempo de atraso;

Aumenta o overshoot para valores de KI elevados.

A componente proporcional é utilizada para contenção do overshoot, sendo capaz também de melhorar o tempo de atraso se KP possuir valores elevados, sob pena do tempo de estabelecimento se deteriorar.

Logo, temos:

Redução do overshoot;

Para valores elevados de KP:

O tempo de atraso é melhorado;

O tempo de estabelecimento deteriora-se.

Embora ainda não tenha sido demonstrado a utilidade da componente derivativa, acredita-se que ela é capaz de conferir estabilidade durante a fase transitória, pelo que, para valores limite da compensação PI será interessante incluir a componente derivativa para acréscimo da estabilidade.

Combinando estas três componentes deveremos conseguir uma resposta muito próxima da ideal, com um tempo de atraso muito pequeno, um tempo de estabelecimento próxima da duração da trajectória, overshoot nulo e um comportamento suave durante a fase transitória.

Como procedimento para fazer o tunning da compensação seguiram-se os passos seguintes:

Aumentar KI, de modo a optimizar o tempo de atraso, até começar a ocorrer overshoot;

Aumentar o valor de KP o suficiente para eliminar o overshoot. Não convém utilizar este parâmetros para optimizar o tempo de atraso, uma vez que o tempo de estabelecimento é, ao mesmo tempo, agravado. Deixemos, por isso, essa tarefa à acção integral;

Se a resposta transitória ainda não for demasiado oscilante, voltar ao passo 1 para melhorar ainda mais o tempo de atraso;

Se começar a instabilizar durante a fase transitória, aumentar o parâmetro KD de modo a conferir suavidade durante o percurso;

Voltar ao passo 1.

A Fig. 76 compara dois ensaios executados durante o tunning correspondentes a um ajuste inicial e a outro final, verificando-se uma melhoria de cerca de 6º no erro máximo em regime transitório. A Fig. 77 apresenta um caso de exagero nos parâmetros de compensação levando à instabilidade. De modo a evitar estas situações convém executar o algoritmo de tunning em passos pequenos, permitindo assim encontrar os parâmetros óptimos mais facilmente.

A partir de certo ponto, ao qual chamaremos de compensação limite, a melhoria já começa a ser mais exigente com variações muito mais pequenas dos parâmetros de compensação. Quando tal começa a ocorrer considere o tunning como terminado com os parâmetros óptimos correspondentes ao ajuste anterior.

Fig. 77: Situação de instabilidade (m=675g). Fig. 76: Comparação entre dois conjuntos de parâmetros durante o tunning (m=675g).

Para a carga de 675g encontraram-se como parâmetros óptimos o conjunto KI=0.39, KP=1.46 e KD=0.15 com um erro máximo de menos de 5º (Fig. 78). No entanto, note que nos encontramos numa situação em que o sistema torna-se muito susceptível à instabilidade face a perturbações externas. A Fig. 79 exemplifica este caso, em que o ensaio com os parâmetros óptimos é repetido verificando-se agora alguma instabilidade.

Fig. 78: PID optimizado para uma carga de 675g. Fig. 79: Repetição do ensaio com os parâmetros de compensação óptimos.

Algumas Notas

Embora a solução de controlo baseada num PID aparente ter bons resultados, não dos devemos esquecer que determinado um conjunto óptimo de parâmetros para compensação dos desvios do servo, apenas se aplica nas condições em que foi feito o tunning:

Massa da carga;

Posição inicial e final, ou melhor dizendo, variação do binário ao longo da travessia;

Período do trajecto;

Tensão de alimentação e corrente máxima fornecida.

Mudando qualquer um destes parâmetros resulta invariavelmente na alteração da resposta do servo podendo conferir-lhe maior estabilidade ou torná-lo instável:

O aumento da massa da carga induz à instabilidade, uma vez que o servo tem de fazer um “esforço” maior para a mover, no sentido que tem de aplicar maior binário no motor, e por isso, o tempo de atraso será acrescido. Numa situação destas em que o sinal de feedback tem dificuldade em acompanhar a “velocidade” do controlador (definido pelo factor de integração KI), o sinal de controlo tende a saturar facilmente provocando fenómenos de overshoot. Por outro lado, se a carga diminuir de massa, o sinal de feedback consegue acompanhar perfeitamente o sinal de controlo conferindo uma maior reactividade à sua correcção.

Se o percurso da trajectória for alterado, a trajectória de binário também muda fazendo com que o servo tenha de dispender mais ou menos energia, de acordo com o caso, para a realizar. Esta situação é equivalente à da modificação da carga, na medida que quando o binário a que está sujeito aumenta (aproxima-se do ponto 0º) é equivalente a aumentar a massa da carga, e vice-versa.

Além da carga influenciar a resposta do servo, também a velocidade influencia. Tal é devido ao facto, de não só a força gravítica fazer parte do binário exercido no servo, mas também a velocidade e a sua variação (aceleração). Desta forma, diminuindo o período da trajectória, estamos a aumentar a velocidade o que interfere no binário exercido no induzindo uma resposta mais instável.

Um outro detalhe importante são as condições de alimentação eléctrica dos servomotores. Caso a corrente máxima a fornecer seja limitada ou a tensão de alimentação é baixa, o binário a aplicar no motor para executar um determinado movimento aumenta, introduzindo atraso na resposta e logo maior instabilidade. Para minimizar estes problemas, duas baterias de Lítio de 7.4V são ligadas em paralelo de modo a fornecer uma corrente de 9600 mAh ao sistema.

Como se pode constatar, estamos a lidar com um processo altamente não linear em que as condições iniciais aplicadas nos servomotores estão sempre a mudar, o que é um problema, uma vez que o controlo clássico baseado num PID não entra em consideração com as condições iniciais.

Uma forma de dar a volta a esta questão corresponde a actualizar em tempo real o valor dos parâmetros de compensação de modo a adaptar o controlador a cada situação específica. Foi pensando nesta questão que se decidiu que a compensação via software seria a melhor opção, uma vez que é muito fácil mudar os parâmetros de controlo sem intervenções a nível de hardware como acontecia se o controlador estivesse implementado fisicamente. De modo a evitar a modificação do código na modificação destes valores, os parâmetros de controlo são passados a cada slave via barramento CAN, sendo a unidade principal, o PC, a responsável por atribuir os valores de compensação mais apropriados a cada acção.

No entanto, outro problema surge: como é que se detectam as situações mais ou menos exigentes em cada junta; e caso consigamos detectá-las, que lei de controlo seguirão os parâmetros de compensação? Para já tentaremos responder à primeira questão. Muito embora, no teste de um só servo, haja uma relação estreita entre binário aplicado e posição, tal deixa de acontecer na presença de várias juntas que se interligam em série por meio de elos, como é o que acontece com cada perna. Além disso, a velocidade da junta também afecta o binário pelo que é preciso discernir cada uma destas fontes de binário. Uma das formas de estimação do binário aplicado baseia-se na medição da corrente consumida por cada servomotor: quanto maior for o binário aplicado, maior é a corrente consumida pelo que a medição desta grandeza pode ajudar na detecção de situações de elevado ou de baixo stress sobre a juntas.

MONITORIZAÇÃO DE CORRENTE

Estudo Estático da Corrente

Comecemos por avaliar a corrente consumida em situações de carácter estático, ou seja, com o servomotor em repouso, analisando-a de acordo com o binário aplicado. A Fig. 80 e a Fig. 81 apresentam um conjunto de medições de corrente realizadas com o servo em repouso para cada uma das posições avaliadas.

Fig. 80: Medição estática da corrente para duas cargas num percurso em subida (-90º a +90º). Fig. 81: Medição estática da corrente para duas cargas num percurso em descida (+90º a -90º).

Como não entram nos resultados o factor velocidade, estes apenas dependerão da força gravítica o que será de esperar que o valor máximo de corrente corresponda à posição 0º (máximo binário) e os valores mínimos aos extremos ±90º (binário nulo), tal como nos mostram os gráficos. Comparando com duas massas diferentes verifica-se que quanto maior é a massa da carga, maior é a corrente consumida evidenciando a estreita relação da força gravítica com a corrente consumida. No entanto note a diferença numérica dos resultados quando a medição se processo no sentido descendente (+90 para -90º) comparativamente ao oposto: na descida a corrente consumida é menor, talvez devido ao facto de os movimentos exigirem menor esforço que no outro caso... no entanto tal ainda não está completamente esclarecido uma vez que estamos a estudar o servo em repouso e não em movimento.

Estudo Dinâmico em Malha Aberta

Introduzindo agora o elemento velocidade, fizemos vários capturas do consumo de corrente com o servo em pleno movimento – estudo dinâmico da corrente. Começámos por realizar movimentos seguindo a trajectória polinomial sem o controlador PID, ou seja, em malha aberta.

Por questões de rigor não vamos caracterizar cada trajectória a partir das posições inicial e final, uma vez que o que nos interessa é a variação de binário resultante da força gravítica. Aliás, as posições deixam de ter significado quando a configuração do servo é modificada para além da indicada na Fig. 32, pelo que referiremos o binário gravítico inicial, final e intermédio com a equivalência do percurso usando posições de referência segundo a configuração original:

Trajectória desde o ponto de binário nulo até ao máximo: equivalente ao trajecto de ±90º para 0º em subida ou em descida;

Trajectória desde o ponto de máximo binário até ao nulo: equivalente ao trajecto de 0º até ±90º em subida ou em descida;

Trajectória entre pontos de binário intermédio passando pelo valor máximo: equivalente ao trajecto entre -45º e +45º.

Fig. 82: Resposta em malha aberta de uma trajectória polinomial de 1s entre dois pontos de binário intermédio para duas cargas.

Fig. 84: Medição da corrente ao longo do tempo do trajecto da Fig. 82. Fig. 83: Medição da corrente para cada posição do trajecto da Fig. 82.

Realizando movimentos entre dois pontos de binário intermédio passando pelo valor máximo (equivalente ao percurso desde -45º a +45º na configuração original do servo) continua-se a verificar um comportamento corrente versus posição (Fig. 83) muito semelhante ao caso estático (Fig. 80), mas com a adicionante de ocorrer uma maior oscilação na distribuição ao longo das posições. A Fig. 84 mostra-nos o comportamento ao longo do tempo evidenciado este aspecto.

Fig. 85: Resposta em malha aberta de uma trajectória polinomial de 1s desde o ponto de binário nulo até ao máximo.

Fig. 86: Medição da corrente para cada posição do trajecto da Fig. 85. Fig. 87: Medição da corrente ao longo do tempo do trajecto da Fig. 85.

Aplicando um trajecto desde um ponto de binário nulo até ao máximo (-90º até 0º), podemos verificar na Fig. 86 e na Fig. 87 o crescente consumo de corrente à medida que o binário aumenta. No entanto, note numa ligeira descida da corrente quando a trajectória termina: como a força gravítica não diminui neste ponto, a causa provável pode estar residente na velocidade do servo. Até ao fim do percurso temos a contribuição da força gravítica e da velocidade no binário aplicado ao servo, mas no fim apenas temos a força gravítica o que pode justificar o decréscimo da corrente.

De modo a estudarmos melhor este fenómeno, realizámos uma segunda experiência, desta vez com uma trajectória iniciando num ponto de máximo binário, e terminando em binário nulo (equivalente ao percurso desde 0º até 90º na configuração original) (Fig. 88).

Seria de esperar que o início da resposta correspondesse à máxima corrente, uma vez que é neste ponto em que a componente gravítica do binário é mais significativa, e fosse descendo até zero quando chegasse ao ponto de binário nulo. No entanto, pela Fig. 90, não é isso o que se verifica: embora no instante inicial já esteja em consumo uma corrente não pouco significativa, após o arranque do movimento, ela aumenta ainda mais atingindo um máximo no ponto coincidente à máxima velocidade. Só a partir daqui é que a corrente começa a baixar continuamente até zero.

Fig. 88: Resposta em malha aberta da trajectória polinomial de 1s desde o ponto de máximo binário até ao nulo.

Fig. 90: Corrente consumida ao longo do tempo do trajecto da Fig. 88. Fig. 89: Corrente consumida em cada posição do trajecto da Fig. 88.

Este comportamento indica-nos claramente que a força gravítica não é a única que contribui na corrente consumida, contribuindo também a velocidade e a aceleração.

com

Uma questão surge, entretanto. Apenas conseguimos medir o binário total aplicado ao motor, mas, no entanto, apenas nos interessa o resultante da força gravítica, pois é a componente que nos indica a inércia a que está submetida. Para conseguirmos isolar esta informação precisaríamos de conhecer a velocidade e aceleração em cada instante, uma vez que se relaciona com o respectiva componente de binário de forma proporcional:

No entanto, apenas conseguimos fazer uma estimativa da velocidade em cada 100ms (muito sujeita a erro) e não podemos medir a aceleração, além que desconhecemos os parâmetros K, fm e Jm para podermos relacionar as diversas componentes. Por enquanto este problema ainda carece de solução.

Estudo Dinâmico em Malha Fechada

Nas análises seguintes vamos considerar agora o controlador PID ligado, ensaiando os mesmos trajectos que foram aplicado em malha aberta. Vemos então verificar se o consumo de corrente sofre variações significativas devido ao controlo.

Fig. 91: Resposta em malha fechada de uma trajectória polinomial de 1s entre dois pontos de binário intermédio.

Fig. 92: Corrente consumida em cada posição do trajecto da Fig. 91. Fig. 93: Corrente consumida ao longo do tempo do trajecto da Fig. 91.

Optimizando o controlador para as condições iniciais:

Trajectória: entre pontos de binário intermédio (-45 a +45º);

Velocidade correspondente ao período de 1s;

Cargas de 675g e de 1129g.

Medimos a resposta em termos de corrente, e pode-se verificar pela Fig. 92 e pela Fig. 93 uma oscilação ainda mais notória da corrente consumida. Tal é facilmente explicável pelas variações do sinal de controlo para compensar a posição solicitada: agora já não se trata de uma variação polinomial como acontecia em malha aberta, mas dependente do sinal de erro entre o sinal de feedback e a trajectória polinomial desejada, o que pode resultar num consumo de corrente mais irregular. A resposta ao longo do tempo evidencia claramente este consumo irregular.

Fig. 94: Resposta em malha fechada de uma trajectória polinomial de 1s desde o ponto de binário nulo até ao máximo.

Fig. 95: Corrente consumida em cada posição do trajecto da Fig. 94. Fig. 96: Corrente consumida ao longo do tempo do trajecto da Fig. 94.

Para a trajectória do mínimo para o máximo binário (-90º a 0º) o consumo de corrente ainda é mais irregular, talvez devido ao crescente binário aplicado em toda o trajecto, fazendo com que o servo tenha mais dificuldades em acompanhar a taxa de integração do controlador. Tal resulta numa maior variação do sinal de controlo aumentando, por isso, a instabilidade do consumo de corrente.

Em jeito de conclusão, verificamos que o consumo de corrente com o controlador presente é muito mais oscilante trazendo bastantes problemas na sua interpretação, o que dificulta a procura por uma lei de variação dos parâmetros de controlo. Por enquanto este problema continua sem solução à vista, ainda mais pela dificuldade em extrair o binário resultante da força gravítica.

APLICAÇÃO DOS ALGORITMOS NO ROBOT HUMANÓIDE

Conectando o microcontrolador, com os algoritmos de controlo implementados, a três servomotores correspondentes às seguintes juntas de uma perna humanóide:

Servo 1: junta do pé (de rotação dianteira);

Servo 2: junta do joelho;

Servo 3: junta da anca (de rotação dianteira).

... executámos vários movimentos, no qual apresentamos neste capítulo apenas o de flexão (Fig. 97), dada a sua relevância na realização de um passo. Inicialmente fizémo-lo sem carga, e posteriormente adicionámos uma carga de cerca de 2Kg ao topo da perna (Fig. 98).

Fig. 97: Movimento de flexão de uma perna.	Fig. 98: Carga de 2Kg utilizada no topo da perna.

Movimento de Flexão em Malha Aberta de uma Perna

Na Ausência de Carga:

Como se pode visualizar nas figuras seguintes, na ausência de carga, o erro em regime estacionário é praticamente nulo, praticamente sem a necessidade de praticar controlo externo.

Fig. 99: Junta do pé.

Note na natureza errática na estimação da velocidade. Tal deve-se ao processo de medição baseada na variação de posição, que infelizmente introduz bastante erro.

Fig. 100: Junta do Joelho.

Fig. 101: Junta da Anca.

Na presença de uma Carga de cerca de 2Kg:

Fig. 102: Junta do pé.

Fig. 103: Junta do joelho.

Fig. 104: Junta da anca.

Com a carga de 2Kg, surpreendentemente verifica-se pouca variação do erro em regime estacionário, com um baixo consumo de corrente. Note que agora o esforço é distribuído pelas três juntas, pelo que as condições não são tão exigentes como as utilizadas no capítulo anterior.

Movimento de Flexão em Malha Fechada de uma Perna

As figuras seguintes apresentam o comportamento das juntas, agora com o controlador ligado.

O caso mais exigente verifica-se no caso da junta do pé (Fig. 105), com erro em regime transitório de 14º e em regime estacionário de 5º. Com o controlador ligado, a resposta melhorou bastante reduzindo o erro máximo em regimen transitório para menos de metade, e eliminando o erro em regime estacionário.

Fig. 105: Junta do pé.

Fig. 106: Junta do joelho.

Fig. 107: Junta da anca.

Movimento das duas Pernas

Fig. 108: Movimento de flexão nas duas pernas.

Utilizando agora, as duas pernas juntas (Fig. 108), com a aplicação de uma carga de massa partilhada entre os dois membros, executou-se o mesmo movimento de flexão para teste das juntas do pé, do joelho e da anca. Adicionalmente, de modo a testar a junta lateral do tornozelo do pé, realizou-se um deslocamento para o lado. As figuras seguintes demonstram os resultados referentes a apenas uma das pernas, dado que os da outra perna são bastante semelhantes.

Fig. 109: Conjunto das duas pernas executando um movimento de flexão (sequência superior) e um movimento lateral (sequência inferior) com uma carga de 2.1Kg em completa sincronia de pernas.

Fig. 110: Resposta ao polinómio com um controlador PI. Imagens superiores e inferior esquerda: comportamento das três juntas envolvidas no movimento de flexão; imagem inferior direita: comportamento da junta lateral do pé na realização do deslocamento lateral.

Como se pode observar, só com a presença do controlador interno, a resposta das juntas mais exigentes (juntas do pé) apresentam um comportamento com um apreciável tempo de atraso e de erro em regime estacionário, que é deveras melhorado com a introdução da compensação PI externa. Demonstra-se assim, com estes dados as vantagens da implementação do controlador.

ORGANIZAÇÃO DO SOFTWARE

A Fig. 111 visualiza a estrutura do software das unidades de controlo local, já apresentada no capítulo 2 (Fig. 21). Os blocos a verde já foram descritos nesse capítulo e o a vermelho será referido no capítulo 4.

Fig. 111: Relações de inclusão dos módulos de software de cada Slave.

Módulo PIC2

Este módulo define as funções de controlo de baixo nível dos servomotores a serem utilizadas pelas bibliotecas de mais alto nível, e as rotinas de atendimento às interrupções responsáveis pela gestão do PWM de actuação e pela leitura sensorial dos servos. É este módulo que implementa as ideias apresentadas na secção 3.2 sobre o controlo de baixo-nível dos actuadores.

Tabela 32: Funções de acesso externo do módulo PIC2.

Função	Descrição
initPic	Inicializações relativas às configurações dos periféricos do microcontrolador.
wait	Função bloqueante que gera um atraso de n ms (n passado como argumento). Esta função faz uso dos timers relativos à actuação.
waitTick	Função bloqueante que espera pelo período de PWM seguinte (20ms no pior dos casos).
servoActuation	Actuação directa sobre a posição dos servomotores. As variáveis com a informação do número de iterações a manter o sinal de PWM a 1 durante a zona de descida são actualizadas para as posições solicitadas.
statusPWM	Activação/desactivação dos sinais de PWM à saída do PIC.
statusFilter	Activação/desactivação dos filtros aplicados à posição medida.
limitPosition	Limitação do um valor entre os extremos de posição do servo: -90 e +90º.

A função que mais se destaca desta lista, é sem dúvida, a servoActuation pois é ela que define qual deve ser ao duty-cycle do sinal de PWM. É esta função que inicializa as variáveis de duração do impulso de PWM que posteriormente serão comparadas com um contador durante a zona de descida de PWM.

Tabela 33: Funções internas do módulo PIC2.

Função	Descrição
initLocal	Inicialização das estruturas de dados locais ao módulo.
sampleExtraSensors	Leitura dos sensores adicionais (coberto pelo capítulo 4).
updateServoMeasures	Medição iterativa do sinal de saída do servo ao longo de um período de PWM, para cálculo da tensão mínima e da largura do impulso de corrente (Fig. 44).
finalizeServoMeasures	Finalização do processamento sensorial (executado no fim do período de PWM). A posição angular do servo (em graus) e a corrente consumida normalizada entre 0 e 100 são determinados (Fig. 43).
filter	Filtragem da posição medida usando métodos lineares e não-lineares.
delay	Geração de um atraso recorrendo somente à instrução nop (no operation).
highISR	Rotina de serviço à interrupção de alta prioridade. Nesta rotina é feita gestão da actuação e do processamento sensorial dos servomotores.
lowISR	Rotina de serviço à interrupção de baixa prioridade. Nesta rotina é feita a gestão das comunicações CAN da unidade slave (capítulo 2).

A Fig. 112 apresenta um diagrama de blocos do algoritmo em funcionamento na rotina de atendimento às altas interrupções, pondo em prática as ideias apresentadas na secção 3.2.

Fig. 112: Algoritmo da RSI de alta prioridade.

Módulo SERVO

Este módulo implementa as rotinas de execução da compensação dos servomotores, uma das quais o controlo de posição segundo o modelo PID descrito na secção 3.4. Outras rotinas podem ser usadas para calibração na medição de posição dos servos ou para definição de parâmetros referência a usar pelos controladores (Tabela 34).

Tabela 34: Funções globais da biblioteca SERVO.

Função	Descrição
calibration	Calibração dos servomotores. É esperada a primeira ordem de actuação proveniente da unidade Master, e seguidamente é atribuído o PWM correspondente à posição solicitada a cada servomotor. Após o término do deslocamento, a calibração de medição da posição é efectuada com a associação da tensão à saída do potenciómetro à posição solicitada (secção 3.2.3.2).
servoRequest	Atribuição da posição final a atingir. Ao contrário da função servoActuation do módulo PIC2, a posição solicitada não é atribuída imediatamente ao servo em causa, mas fica armazenada para utilização por parte dos controladores. Estes por sua vez, utilizarão este valor como a posição de referência a ser atingida através dos algoritmos implementados – PID no caso do controlo de posição.
initController	Inicialização das variáveis estáticas utilizadas pelos algoritmos de compensação. Apenas as variáveis associadas ao controlo de posição PID são inicializadas.
controller	Execução dos algoritmos de controlo – um deles é o compensador de posição dos servomotores descrito na secção 3.4.

Esta biblioteca implementa todos os algoritmos de controlo a executar na estrutura humanóide, sendo a compensação PID da posição dos servomotores um deles. A Tabela 4 apresenta os quatro tipos de controlo que podem ser seleccionados através de ordens de actuação executadas pela unidade de controlo principal – o PC – utilizando os barramentos de comunicações RS-232 e CAN. As rotinas que implementam cada um dos quatro algoritmos de controlo apresentam-se na Tabela 35 e são chamadas pela função controller.

Tabela 35: Rotinas de implementação da compensação chamadas pela função controller.

Função	Descrição
openloopControl	Controlo dos servomotores em malha aberta. A posição indicada na chamada da função servoRequest é atribuída ao servo em causa, sem passar por qualquer algoritmos de compensação.
locomotionControl	Compensação PID da posição de cada servomotor.
reactionControl	Compensação das forças de reacção aplicadas nos pés segundo o modelo proporcional.
JacobianControl	Compensação das forças de reacção através da matriz Jacobiana.

Os algoritmos de controlo a vermelho na Tabela 35 são utilizados para o controlo de equilíbrio por parte da perna de suporte e serão referenciados com mais detalhe no capítulo 4.

Módulo TRAJECTORY

Este módulo implementa o controlo de velocidade nos servomotores pela aplicação de posições segundo uma determinada trajectória que imprimem a cada servomotor uma determinada velocidade média e eliminam as descontinuidades na forma de deltas de Dirac nas trajectórias de velocidade e de aceleração. A trajectória implementada segue a curva de um polinómio de terceiro grau tal como indicado na Fig. 53. A secção 3.3.2 explica com mais detalhe esta estratégia.

Tabela 36: Funções globais da biblioteca TRAJECTORY.

Função	Descrição
initTrajectory	Inicialização dos parâmetros estáticos utilizados na realização de cada trajectória.
trajectory	Cálculo e realização iterativa de uma trajectória.

As variáveis indicadas na função initTrajectory são apresentadas a seguir:

// Estrutura com os dados necessários acerca de um trajecto typedef struct { enum_trajectType type; // Tipo de trajectória em execução double coef[4]; // Coeficientes da função theta=a0+a1*t+a2*t^2+a3*t^3 word period; // Duração em ticks da trajectória em execução word time; // Tempo em curso (em ticks) signed char theta_final; // Posição final da trajectória (valor referência) byte control_type; // Tipo do controlador em aplicação } struct_trajectory; static struct_trajectory traject[N_SERVOS];

Dos tipos de trajectória que podem ser realizados (type) discernem-se dois:

Free traject: Nenhuma trajectória será aplicada, e a posição final theta_final a atingir é directamente atribuída ao servomotor em causa. Este tipo de trajecto é aplicado quando a duração solicitada (period) é nula.

Normal traject: Realização da trajectória polinomial de coeficientes coef, cuja duração do trajecto é period e a posição final é theta_final. Esta trajectória é implementada sempre que period é positivo.

A Tabela 37 visualiza as rotinas invocadas pelo função global trajectory.

Tabela 37: Funções estáticas invocadas pela função trajectory da biblioteca TRAJECTORY.

Função	Descrição
executeTrajectory	Execução de uma de duas trajectórias: free_traject ou normal_traject.
calcTrajectory	Cálculo de uma nova trajectória a realizar.

A rotina executeTrajectory é sempre executada, implementando um dos dois tipos de trajecto apresentados, usando o parâmetro theta_final (posição final) no caso free traject (trajecto livre), e os parâmetros time e coef para o caso normal_traject (trajecto polinomial):

time indica o tempo decorrido desde o início da trajectória;

coef são os coeficientes do polinómio de terceira ordem {a0, a1, a2, a3} utilizados para o cálculo da posição a aplicar para o instante time:

Sempre que a unidade Master solicita uma posição ou um tipo de controlador diferente de theta_final e/ou de control_type respectivamente, a trajectória em execução é interrompida, e um novo trajecto é calculado tendo em conta os novos valores referência. A rotina calcTrajectory realiza esta tarefa calculando uma nova trajectória de acordo com a duração solicitada pelo Master (period):

Duração nula: execução do trajecto livre (free traject) indicando a opção através da variável type.

Duração positiva: execução do trajecto polinomial (normal traject), calculando para isso os coeficientes coef do polinómio de terceiro grau a aplicar.

Em ambos os casos, as restantes variáveis estáticas da estrutura struct_trajectory são redefinidas tendo em conta o novo trajecto.

Módulo SLAVE

Programa principal com a inicialização do PIC e a invocação das rotinas de implementação do controlo de posição e velocidade dos servomotores.

Fig. 113: Algoritmo da função main no programa principal slave.

Módulo MyMATHS

Esta biblioteca implementa as funções matemáticas necessárias para a programação dos módulos SERVO e TRAJECTORY. As funções seno e coseno apenas serão úteis para a implementação do controlador das forças de reacção descrito no capítulo 4.

Função	Descrição
abs	Cálculo do módulo de um valor inteiro com sinal signed int. Retorno no formato unsigned int.
seno	Cálculo da função trigonométrica seno. O argumento é passado em graus e o retorno é um valor inteiro com sinal signed char entre -100 e +100:
coseno	Cálculo da função trigonométrica coseno. O argumento é passado em graus e o retorno é um valor inteiro com sinal signed char entre -100 e +100.

As funções seno e coseno são implementadas recorrendo a uma lookup table com a associação do resultado a cada valor angular (Tabela 38).

Tabela 38: Lookup table para a função seno.

Ângulo (º)	Seno (×100)
0	0
1	1
2	3
3	5
4	6
5	8
...	...
81	98
82	99
83	99
...	...
89	99
90	100

Apenas nos é útil armazenar a gama de 0 a +90º, uma vez que o conjunto de resultados repete-se para outros ângulos fora deste intervalo. Deve-se, contudo, adaptar o argumento para a gama [0,90]º e aplicar correctamente o sinal ao resultado final.

No que respeita à resolução da lookup table, é suficiente armazenar o resultado para cada ângulo inteiro, uma vez que o algoritmos de medição sensorial do potenciómetro de posição de cada servomotor também só consegue medir com uma resolução de 1º.

De notar que a lookup table da função seno (Tabela 38) também pode ser utilizada para o cálculo do coseno dado que:

... pelo que apenas uma lookup table é suficiente.

RESOLUÇÃO DE ANOMALIAS

Embora, em função dos dados sensoriais, as respostas possuem uma boa qualidade, a nível mecânico já não é bem assim, com os efeitos elásticos das correias de transmissão e as folgas das juntas a tornaram-se significativos. Ao fim de cada conjunto de testes com uma carga elevada, verificava-se um deslocamento do parafuso de aperto de cada correia resultando no aparecimento de uma folga nas juntas mais exigentes. Tal exigia o reajuste do parafuso de aperto para corrigir a folga (Fig. 114).

Fig. 114: Aperto das correias de transmissão: junta lateral (esquerda) e dianteira do pé (restantes).

Um outro problema mais complexo prende-se com a ligação da junta do joelho com uma chaveta que garante a ligação da perna inferior com a superior. Ao fim de algum tempo começou a ocorrer folga nesta ligação, resultando numa degradação permanente dos movimentos, dado que esta folga não é reajustável. Recomenda-se por isso, a substituição do material utilizado por outro mais resistente, ou na impossibilidade desta solução, adicionar mais uma chaveta de fixação no outro lado do joelho (Fig. 115 à direita).

Também se verificaram algumas folgas permanentes ao nível do veio do tornozelo com a presença de algumas ligações deficientes entre este veio e o veio do pé. Recomenda-se, também a revisão destas ligações (imagem esquerda e central da Fig. 115).

Fig. 115: Localização das principais folgas existentes: juntas lateral (esquerda)e dianteira (central) do pé e chaveta de ligação do joelho (direita).

Como se pode concluir, muito embora o comportamento dos servomotores seja considerada como muito bom pelos resultados sensoriais, em termos mecânicos ainda há muitos aspectos que precisam de ser melhorados sob pena de tornar ineficaz os algoritmos de controlo de posição e velocidade. Aconselha-se, por isso, uma séria revisão à estrutura das pernas, uma vez que são estes membros que terão de suportar os esforços mais exigentes, nomeadamente:

no aperto das correias de transmissão: estas são as principais causas de folgas, aumentando à medida que se verifica um esforço, correndo o risco de provocar saltos de dentes. Uma solução que já foi indicada corresponde a efectuar o aperto de forma dinâmica com o recurso a uma espécie de mola, tornando automático o processo de ajuste.

ao nível das ligações entre os veios e os elos tornando-os mais robustos quer pelo aumento da resistência dos materiais quer pelo aumento do número de ligações. Tal convêm ser estudado;

CONCLUSÕES

Este capítulo teve como objecto de estudo, os servomotores utilizados para actuação. Como são dispositivos relativamente pequenos e baratos que já oferecem o controlo de posição, foram escolhidos dada a sua simplicidade de interface com um microcontrolador – podem-se ligar directamente – podendo controlar a sua posição simplesmente através de um sinal digital de PWM cuja largura de pulso define a posição do servo. Os modelos da HITEC, nomeadamente o modelo HS-805BB para as juntas de grande esforço, foram escolhidos dada o seu elevado binário (2.42 N.m @6V) comparativamente a outras marcas.

No entanto, cedo nos apercebemos que estes dispositivos não são perfeitos não oferendo qualquer tipo de controlo de velocidade – simplesmente se deslocam para a posição final à sua velocidade máxima – algo nada favorável quando pretendemos controlar a posição e a velocidade das juntas para que realizem movimentos suaves de velocidade limitada. Contudo, pela aplicação de um conjunto crescente (ou decrescente) de pequenos degraus de posição em forma de rampa, conseguimos implementar uma espécie de controlo de velocidade indirecto, na medida em que os extremos de posição da rampa e o intervalo de tempo da sua duração impõe uma velocidade média do movimento. Uma forma de trajectória mais exigente é o polinómio de terceiro grau que além de permitir a definição de uma velocidade média garante outros aspectos como é o caso de velocidade nula e acelerações limitadas no início e no fim da trajectória, algo importante para prevenir eventuais picos de corrente e limitar o consumo de corrente durante o percurso na realização destas trajectórias.

Mais tarde verificou-se que embora estes actuadores apresentem respostas praticamente ideais (resposta semelhante à trajectória solicitada), na presença de cargas tal deixa de ser verídico verificando um acentuado tempo de atraso no acompanhamento da trajectória solicitada e uma dificuldade em atingir o valor final devido à presença da força gravítica no binário aplicado (erro em regime estacionário não nulo). Usando o sinal de feedback de posição que o servo disponibiliza, por comparação com a posição desejada, tentou-se implementar uma lei de controlo que permitisse corrigir estes desvios. Esta lei de controlo baseou-se num compensador clássico do tipo PID (Proporcional+Integrador+Derivador), que por meio de diversos ensaios, conseguimos associar cada componente às características da resposta de modo a permitir-nos escrever um procedimento para rapidamente encontrarmos, através de ensaios, um conjunto de parâmetros que aproximem bastante a resposta do servo à desejada.

No entanto um conjunto de parâmetros do controlador só se adequa a uma situação específica de carga, trajectória e velocidade específicos, pelo que seria importante detectar os vários cenários possíveis para que o controlador se adaptasse. Tal seria possível pela medição do binário aplicado no motor que varia de acordo com a inércia presente.

Usando o sinal de saída do potenciómetro interno do servo, conhecido por estar relacionado com a sua posição, descobrimos que além de nos fornecer a posição também nos providencia a corrente corrente consumida pelo dispositivo, que por sua vez está relacionada com o binário aplicado ao motor. Desta forma poderíamos aplicar um controlador de força que adaptaria os parâmetros de controlo de acordo com a corrente drenada pelo motor. No entanto este sinal apresenta uma natureza bastante oscilatória, ainda mais com o controlo de posição, estando relacionada não só com o binário resultante da força gravítica como também do que resulta da velocidade e da aceleração. Para já desconhece-se qual seria o formato da lei de controlo deste adaptador, nem que parâmetros deverá assumir pela que mais investigação será necessária sobre este tópico.

Mesmo assim, nas experiências que temos realizado sobre as pernas do humanóide temos vindo a utilizar parâmetros fixos do controlador de posição, que claro, são bastante limitados para garantir a estabilidade em qualquer uma das juntas devendo, estes valores, corresponder ao pior caso. Infelizmente ficamos a perder, que em grande das juntas os parâmetros não são os mais optimizados introduzindo atrasos adicionais que por vezes podem ser piores do que se o controlador estivesse desligado (em malha aberta).

Efectuando ensaios sobre as pernas acabámos por verificar que as exigências em termos de binário são bastante inferiores às testadas com o servo isolado, com respostas de bastante qualidade mesmo em malha aberta. Apenas a estrutura mecânica das pernas se revelou incapaz de executar movimento com as cargas mais pesadas provocando folgas, que embora algumas fossem ajustáveis, outras revelaram-se sem solução com a necessidade de substituir peças. Esperemos que no trabalho futuro que se segue, estas contrariedades sejam levadas a sério não só no sentido de eliminar quaisquer folgas existentes, como também em aplicar novas técnicas e materiais que atribuam robustez à estrutura, independentemente da solicitação imposta.

Outros aspectos que precisam de ser limados prendem-se com a alimentação dos actuadores e das unidades de controlo local. Mesmo com o uso de duas baterias de elevado fornecimento de corrente em paralelo, verifica-se esporadicamente um aparente reset de alguns PIC's, na medida que por vezes alguns servos deslocam-se para a posição original a alta velocidade. Como esta anomalia é muito esporádica iremos por de parte bugs do software.

Considerando a hipótese de um reset por parte de um slave, nada deveria acontecer, uma vez que quando iniciam o seu funcionamento esperam por um comando do master e só depois aplicam o PWM com a posição válida, que deverá corresponder à posição actual. Se alguma coisa ocorrer é um deslocamento mínimo devido ao controlador PID. Por isso, este não deverá ser o problema.

Se o reset ocorresse no master, todos os slaves dirigir-se-iam para as suas posições originais e não apenas um ou outro como se observa, pela que esta opção também é posta de parte.

Logo aparentemente, o problema não se deve a um reset. Eventualmente pode ser devido a informação incorrecta nas mensagens CAN. Apenas é estranho dado que as mensagens de actuação teriam de possuir valores 0 nos campos de posição e velocidade durante imenso tempo para serem visualizados os efeitos. Se se deve a isto, em princípio resolvendo bug do bloqueio do barramento CAN enunciado nas conclusões do capítulo 1, deveremos também resolver este problema.

CONTROLO DAS FORÇAS DE REACÇÃO

Resumo:

Este capítulo apresenta um género de controlo a efectuar sobre as juntas além do controlo de posição/velocidade apresentado no capítulo 3. Sempre que uma perna não necessite de realizar controlo na locomoção, como é o caso da perna de suporte durante a marcha, é importante manter o equilíbrio da plataforma, de modo a que o centro de massa projectado sobre o solo se mantenha sempre centrado sobre o pé de suporte. Um controlador de equilíbrio que garanta esta condição é o assunto deste capítulo.

INTRODUÇÃO

O capítulo 3 descreveu várias técnicas de compensação, nomeadamente de posição e de velocidade, de modo a corrigir desvios introduzidos pelos próprios servomotores na realização de trajectórias. No entanto, é sabido, que durante a marcha da plataforma humanóide, apenas uma das pernas possui a tarefa da realização da trajectória correspondente à execução de um passo, sendo que a outra fica responsável pela manutenção do equilíbrio da estrutura de modo a manter a sua posição vertical.

Este capítulo apresenta, por isso, várias técnicas para a realização desta tarefa, baseadas na medição das forças de reacção aplicadas directamente sobre a base dos pés. Note que esta estratégia segue o comportamento do corpo humano, que pela sensação das forças aplicadas sobre os pés procura o equilíbrio do corpo pelo movimento das juntas das pernas e do tronco. Dado que, no caso do robot humanóide, o seu centro de massa localiza-se na região da cintura, o movimento do tronco poderá ser dispensado bastando mover as juntas das pernas.

O processo de controlo pensado, baseia-se na medição de vários sensores de força localizados na base de cada pé, que medem as forças de reacção aplicadas sobre eles, e permitem determinar o ponto onde se localiza o centro de pressão, que, para baixas velocidades, coincidirá com a projecção do centro de massa da estrutura sobre os pés. Ora sabe-se que, na situação de equilíbrio, o centro de pressão deve coincidir com a posição central de cada pé, pelo que um futuro controlador de equilíbrio deve utilizar esta posição como ponto de referência a atingir. Este capítulo estudará dois tipos de controladores: o primeiro baseado numa abordagem bastante simplista seguindo uma lei proporcional, e o segundo, um tanto mais complexo, que procura relacionar com mais precisão as forças aplicadas sobre cada pé com a velocidade angular a aplicar nas juntas.

Nesta fase do projecto apenas se testaram os algoritmos desenvolvidos apenas para uma das pernas à parte, dado que se confia que estes algoritmos podem ser aplicados de forma igual a cada perna sem perda de generalidade.

ESTRUTURA DOS PÉS

Sensores de Força: os Extensómetros

Pretende-se desenvolver um pé que seja capaz de medir as forças de reacção aplicadas ao longo da sua área, de modo a permitir avaliar a posição do centro de pressão aplicado.

Para medição das forças de reacção, a solução mais económica e viável consiste na utilização de extensómetros (Fig. 116) que são basicamente resistências cujo valor ohmico varia com a sua deformação.

Fig. 116: Exemplo de um extensómetro típico.

Aproveitando esta propriedade elástica que relaciona proporcionalmente a deformação com a força aplicada, podemos colocar vários extensómetros ao longo da área de cada pé, e, pela medição da sua deformação, medir a força aplicada sobre cada um deles. No entanto, note que esta relação proporcional apenas é válida para uma pequena zona de funcionamento denominada por zona elástica (Fig. 117). Apenas nesta zona se pode garantir que o material recue sempre ao seu estado inicial após uma deformação, e que assegure que o valor da deformação é sempre igual para uma determinada força imposta.

Fig. 117: Relação entre força imposta e deformação elástica.

Para medição da deformação, pelo seu valor ohmico, uma ponte de Wheatstone será utilizada, onde uma das resistências é substituída pelo extensómetro. A ponte permite medir uma diferença de potencial aplicada nos seus extremos que varia com o valor resistivo. De notar que os extensómetros normalmente deformam-se cerca de 2 a 5% do seu valor, estando assim limitados a medir pequenas deformações, pelo que se torna necessário amplificar a saída com o recurso a um amplificador de instrumentação para acomodar este sinal à ADC do PIC.

O Pé como Elemento Sensitivo a Forças Externas

A ideia essencial é tornar cada pé sensível a forças externas, de modo a poder determinar parâmetros como a inclinação do pé ou a presença de perturbações externas na perna, de modo a accionar os mecanismos necessários para compensar esses desvios. Para tal utilizou-se a estrutura do pé adoptada no ano lectivo anterior em que são usados quatro sensores de força, um em cada extremidade do pé.

A estrutura do pé baseia-se na presença de duas plataformas paralelas entre si: uma inferior que interage com o solo, e uma superior que faz a ligação ao tornozelo – a Fig. 119 exemplifica estas duas plataformas. Na plataforma inferior quatro aberturas foram feitas em formato rectangular, uma em cada canto da plataforma, que servem de apoio a pequenas peças de igual formato, mas de comprimento ligeiramente superior, de modo a não penetrar nas aberturas. A Fig. 118 exemplifica a colocação destas pequenas peças que deverão possuir propriedades elásticas de modo a que, na presença de uma força externa, sejam capazes de se deformar usando todo o espaço livre da abertura.

Fig. 118: Colocação dos sensores na estrutura do pé.

Fig. 119: Estrutura completa de um pé.

Cada extensómetro é colocado na parte inferior de cada peça, medindo, deste modo, a sua deformação, ou seja, a força aplicada. A Fig. 120 apresenta o plano inferior das peças utilizadas, já com o extensómetro colado, tendo sido escolhido o acrílico dado o seu elevado grau de elasticidade.

Fig. 120: Peça de acrílico contendo o extensómetro para medição da sua deformação. Fig. 121: Pontos de contacto entre as 2 plataformas do pé.

Estas peças deformáveis são os únicos pontos de contacto da plataforma superior, usando para isso parafusos que assentam directamente sobre o centro destas peças. Desta forma, as forças aplicadas sobre a plataforma superior distribuem-se unicamente pelas peças de acrílico, com os extensómetros a medir a força total aplicada. A Fig. 121 apresenta um ponto de contacto, em que se observa o parafuso directamente assente sobre a localização do extensómetro de modo a poder medir de uma forma eficiente a força aplicada nesse ponto.

Toda a estrutura está visualizada na Fig. 122 com cada extensómetro a medir a força aplicada em cada canto do pé permitindo efectuar uma estimativa do centro de pressão a partir da distribuição das quatro forças.

Fig. 122: Visão completa do pé.

Numa versão posterior, dever-se-á substituir o material usado nas peças com os extensómetros para outro ainda mais flexível e com melhores características para mais facilmente recuar sempre para a posição original. Um material com estas características foi encontrado nas lâminas das serras de corte de metal, dada a sua constituição ser de aço laminado. O facto de este material permitir o seu fácil corte por uma máquina CNC aliado à sua elevada resistência e baixo preço demonstra ser uma boa escolha. Mais novidades esperam-se no próximo ano.

MEDIÇÃO DAS FORÇAS DE REACÇÃO

Interface entre os Extensómetros e o Microcontrolador

Agora que é possível medir as forças aplicadas ao longo da base de um pé é necessário amostrar estes sinais através do microcontrolador e fazer uso destes sensores.

Versão original do circuito de Acondicionamento de Sinal

A Fig. 123 apresenta o circuito de acondicionamento de sinal para cada extensómetro, utilizado no ano anterior para aplicação numa entrada analógica do microcontrolador.

Fig. 123: Circuito de interface original dos extensómetros.

Uma ponte de Wheatstone é utilizada para medir a resistência ohmica do extensómetro pela sua queda de tensão. Numa situação de equilíbrio, a tensão nos terminais 2 e 3 do amplificador devem ser iguais, pelo que...

...com EXT correspondente ao valor ohmico do extensómetro e RCAL relacionado com a potenciómetro de calibração.

A situação de equilíbrio de que falamos pode não corresponder necessariamente à ausência de força aplicada sobre os sensores, uma vez que pode existir já uma pré-carga dada por exemplo pelo peso da plataforma superior do pé e do restante corpo. No entanto, tal não é problemático, uma vez que apenas nos interessa a distribuição de forças pelos sensores. Dada a existência desta pré-carga, torna-se necessário calibrar a ponte de Wheatstone através do potenciómetro POT de modo a que a diferença de potencial na saída da ponte seja nula durante equilíbrio.

A presença do amplificador de instrumentação INA129P justifica-se pelo facto da gama de excursão do sinal de saída ser demasiado pequeno para processamento por parte do PIC. Repare que a resistência do extensómetro apenas varia até um máximo de 5% do seu valor standard (120Ω), o que corresponde a uma queda de tensão máxima de...

De forma a adaptar esta excursão para a de 5V que a ADC suporta é necessário amplificar este sinal. Dado que o amplificador de instrumentação é alimentado com um VDD de 5V com uma tensão máxima de saída de VDD – 0.8V considerámos a tensão de entrada máxima no PIC como 4V. Logo o ganho máximo será:

O ganho do amplificador é controlado através da resistência RG pela seguinte fórmula (para o INA129):

Na realidade usou-se um RG bastante inferior – 100Ω no caso da Fig. 123 – dado que nas situações testadas não se atingia a deformação máxima de 5% mas um valor mais abaixo. Note que para valores inferiores de RG o ganho é superior.

Versão melhorada do Circuito de Acondicionamento de Sinal

No entanto, a configuração da Fig. 123 apresenta vários problemas quando testada na prática. Um dos problemas está relacionado com o potenciómetro POT usado na calibração: o potenciómetro utilizado permite variar a resistência de calibração RCAL=R4+POT entre 120 e 220Ω o que representa uma enormidade comparado com a variação que o extensómetro pode apresentar – 114 a 126Ω (±5% de 120Ω) – o que confere ao potenciómetro uma resolução muito baixa, mesmo sendo multi-volta, além que não é possível calibrar para valores inferiores a 120Ω. Para melhorar o procedimento de calibração substituiu-se o conjunto R4+POT pelo seguinte circuito:

Fig. 124: Circuito de calibração da ponte de Wheatstone.

(Resistência total de calibração)

Fig. 125: Relação entre o potenciómetro e a resistência total de calibração.

Pela substituição da resistência série RS para 430Ω e pela adição de uma resistência RP de 130Ω em paralelo, o resultado da calibração melhorou drasticamente. Como se constata pelos cálculos e pela Fig. 125 agora é possível tanto calibrar abaixo como acima do valor referência dos 120Ω e, além disso, sem modificar o potenciómetro POTCAL de 100Ω4 Dada a dificuldade na obtenção de potenciómetros multi-volta inferiores a 100Ω optou-se por não modificar este componente. é possível calibrar a resistência total de calibração RCAL só para a vizinhança do valor referência conferindo uma resolução bastante boa na execução deste procedimento.

Mantendo fixo o potenciómetro POTCAL nos 100Ω, as resistências RS e RP podem ser calculadas tendo em vista um valor mínimo e máximo de calibração (RCAL(min) e RCAL(max) respectivamente):

→

Dada a não usual correspondência entre os valores calculados e as resistências existentes no mercado, é aconselhável o cálculo iterativo dos parâmetros RS, RP, RCAL(min) e RCAL(max) até à obtenção de um compromisso aceitável.

Outro problema observado relacionava-se com a instabilidade do sinal de saída: sempre que o circuito era ligado, a tensão à saída do amplificador era estabelecido num valor não nulo e começava a diminuir até estabilizar num valor final ao fim de algum tempo. Este tempo de estabilização correspondia a alguns minutos com variações na ordem do meio volt o que invalidava qualquer estratégia de correcção via software. Mais tarde verificou-se que o mesmo sucedia quando se provocava intencionalmente variações de temperatura, com a presença de flutuações significativas no sinal de saída. Concluiu-se, por isso, que estas flutuações deviam-se à ausência de simetria na ponte de Wheatstone por parte dos componentes utilizados, mais concretamente no que respeita aos coeficientes de temperatura das resistências.

Repare que pela expressão de equilíbrio calculada atrás...

... se o produto EXT×R3 não variar na mesma proporção que o produto R1×RCAL após uma modificação de temperatura, o sinal de saída é alterado. Tal é provocado por diferentes coeficientes de temperatura nas resistências. Embora estes coeficientes sejam, por natureza muito baixos, não nos podemos esquecer que a ordem de grandeza do sinal de saída da ponte é igualmente baixo o que pode tornar significante este desvio. Experimentalmente comprovou-se que a presença do potenciómetro era a causa destas flutuações, o que sugere um coeficiente de temperatura deste componente muito diferente dos restantes.

De forma a resolver este problema, definiu-se uma nova configuração da ponte, de modo a que, na presença de qualquer interferência externa, os diversos componentes compensem o desvio anulando-o. Tal foi conseguido através da adição de um segundo potenciómetro (potenciómetro fixo POTFIXED) e de um segundo extensómetro (extensómetro espelho EXTMIRR) para compensar eventuais desvios introduzidos aos primeiros (Fig. 126).

→	Extensómetro de medição da deformação

→	Extensómetro espelho de EXT

→	Resistência fixa (potenciómetro fixo)

→	Resistência de calibração

Por questões de simplicidade fixou-se POTFIXED nos 50Ω (resistência resultante RFIXED=120Ω) e colocou-se o extensómetro espelho num local próximo ao usado para medição mas sem a aplicação de qualquer força. O potenciómetro de calibração POTCAL continua a ser o usado para calibração da ponte.

Fig. 126: Ponte de Wheatstone com compensação de interferências externas.

Note que os produtos RFIXED×EXTMIRR e EXT×RCAL são simétricos entre si no que respeita aos componentes utilizados, pelo que qualquer interferência externa introduzida num dos produtos, repercute-se automaticamente no outro, compensando o desvio e ajudando a manter a estabilidade da tensão de saída.

Fig. 127: Implementação do circuito de acondicionamento de sinal.

Versão Futura do Circuito de Acondicionamento de Sinal

Outro melhoramento espera-se deste circuito que, embora ainda não tivesse sido implementado, indica-se nesta secção com a esperança de ser útil. A Fig. 128 apresenta uma nova configuração que apenas muda a localização dos componentes. Esta nova configuração permite limitar a corrente consumida de modo a poupar energia e a limitar a dissipação por efeito de Joule nas resistências da ponte.

Segundo a configuração da Fig. 126 a corrente consumida é de cerca de 42mA por cada circuito, o que para um conjunto de 8 sensores (para dois pés) teríamos um consumo de 333mA.

A desvantagem desta configuração, é que a corrente que atravessa cada extensómetro é sempre de 21mA (IEXT/2) qualquer que seja o valor das resistências RS e RP pois só permite limitar a corrente consumida num só ramo da ponte. Segundo a nova configuração (Fig. 128) é possível limitar a corrente em ambos os ramos da ponte de Wheatstone incluindo a consumida por cada extensómetro.

Para a redução da corrente em ambos os ramos é suficiente aumentar a resistência RCAL e RFIXED na mesma proporção:

Note, contudo, que com este procedimento, a excursão do sinal de saída da ponte diminui exigindo o aumento do ganho do amplificador de instrumentação:

Fig. 128: Circuito de acondicionamento de sinal com simetria completa.

Resultados Experimentais

Setup Experimental

Utilizou-se a estrutura do pé descrita indicada na Fig. 122 com os seus quatro sensores ligados a placas de acondicionamento de sinal usando o circuito da Fig. 126. Por sua vez, as suas saídas eram ligadas a quatro entradas analógicas da placa de controlo local (Fig. 23). A leitura digital segue o algoritmo mais simples: conversão analógico-digital para um valor de 8 bits e envio dos resultados dos quatro sensores para a unidade de controlo principal (PC).

Dois tipos de experiências foram realizadas:

A primeira, colocando vários pesos, previamente calibrados, sobre cada sensor: cada sensor foi testado de forma isolada (Fig. 130);

E a segunda, colocando os pesos sobre o ponto central da base do pé: os quatro sensores foram medidos simultaneamente (Fig. 131).

A lista de pesos calibrados é indicada a seguir na Tabela 39: os pesos 1 a 4 correspondem a cilindros de metálicos e o peso B corresponde a uma bateria pesando aproximadamente 2Kg. Usaram-se estes pesos de forma isolada e combinados uns com os outros de modo a obter um massa máxima de cerca de 4Kg.

Carga	Massa (g)	Peso (N)
0	0	0.00
1	249	2.44
2	454	4.45
3	713	6.99
4	666	6.53
B	1946	19.1

Tabela 39: Lista de pesos usados no teste dos sensores de força.

A Tabela 40 indica os valores registados em cada uma das experiências para cada sensor, com o azul e o verde localizados na parte dianteira e o branco e castanho na parte traseira do pé (Fig. 129). Todos os sensores foram calibrados com o valor 40 na ausência de carga.

Fig. 130: Medição independente de cada sensor. Fig. 131: Medição dos sensores em conjunto. Fig. 129: Localização dos sensores no pé.

Teste de cada sensor isolado (experiência 1)	Teste conjunto: pesos colocados no centro do pé (experiência 2)
Cargas	Peso (N)	Azul	Verde	Branco	Castanho	Azul	Verde	Branco	Castanho
0	0.00	40	40	40	40	40	40	41	40
1	2.44	54	51	55	53
2	4.45	67	66	69	66	48	40	42	48
1+2	6.90	84	83	84	81
4	6.53	82	81	81	79	55	46	46	56
4+1	8.98	98	97	96	94
4+2	11.0	110	110	108	106	64	55	54	64
4+1+2	13.4	127	123	124	120
4+3	13.5	128	125	124	122	69	60	59	69
4+3+1	16.0	144	137	142	135
4+3+2	18.0	158	147	155	147	77	69	67	75
4+3+2+1	20.4	173	160	177	162
B	19.1	160	157	171	163	85	65	64	86
B+1	21.5	174	166	190	186
B+2	23.5	186	180	200	197	95	71	71	95
B+2+1	26.0	208	193	214	210
B+4	25.6	100	75	75	102
B+4+2	30.1	110	82	83	111
B+4+3	32.6	114	85	87	116
B+4+3+2	37.1	125	91	92	124
B+432+1	39.5	130	94	97	129

Tabela 40: Resultados experimentais para cada sensor nas duas experiências.

Fig. 132: Relação entre a medição de cada sensor e o peso aplicado (experiência 1)

A Fig. 132 apresenta graficamente os dados registados para cada sensor testado isoladamente (experiência 1), e confirma-nos a relação esperada entre a força gravítica aplicada sobre cada extensómetro e a deformação medida: trata-se sem dúvida de uma relação proporcional. As rectas traçadas correspondem à regressão linear “robusta” baseada nos pontos de massa inferior a 2000g, e pode-se observar que para cargas inferiores a este valor, a recta estimada coincide praticamente nos pontos medidos com coeficientes de correlação muito próximos de 1. Veja-se a Tabela 41 em que até os declives e as ordenadas na origem são bastante próximos entre as várias respostas.

Parâmetro da regressão y = m×x + b	Sensor Azul	Sensor Verde	Sensor Branco	Sensor Castanho
Declive m	38.378	40.607	39.720	39.734
Ordenada na origem b	0.0648	0.0592	0.0621	0.0588
Coeficiente de correlação R2	0.9999	0.9999	0.9999	0.9999

Tabela 41: Parâmetros das regressões lineares traçadas.

Para cargas superiores a este valor verifica-se um pequeno desvio principalmente no caso dos sensores branco e castanho. Este comportamento relaciona-se pelo facto de até à carga de 2000g as massas foram adicionadas de forma acumulativa, e após este valor, todas elas foram removidas para a colocação da massa B, o que provocou um retorno dos extensómetros à posição original seguida de nova deformação. O facto de não voltarmos a obter o mesmo comportamento linear sugere que ou a massa B não estava devidamente centrada sobre o sensor (difícil dado o formato da bateria) ou que os sensores estavam no limite da zona elástica de funcionamento. Recomenda-se por isso, que estes sensores não sejam utilizados para forças superiores a 20N.

Fig. 133: Valores dos sensores com massas colocadas no centro da base (experiência 2)

Analisando as dados obtidos colocando vários pesos no centro do pé e medindo os quatro sensores (experiência 2) podemos observar o mesmo efeito evidenciado atrás para cargas superior a 2000g (Fig. 133). Outro resultado interessante é a assimetria das respostas quando os sensores funcionam em conjunto: os sensores azul e castanho apresentam valores superiores em relação aos restantes, e, para cargas superiores a 2Kg, a diferença ainda é maior. Como já se comprovou que os sensores estão a funcionar correctamente pela experiência 1, tal nos leva a concluir que a plataforma superior do pé não é completamente homogénea com distribuições de força diferentes ao longo da estrutura.

Amostragem dos Sensores

O procedimento de leitura utilizado na secção anterior não efectuava qualquer processamento, lendo o valor da ADC e passando-o directamente à unidade Master pelo barramento CAN. No entanto tal não é favorável, pois verificou-se experimentalmente que a saída dos extensómetros varia ao longo do tempo transmitindo-se essa variação para o circuito de acondicionamento de sinal. Ora, embora se possa ajustar o potenciómetro de calibração presente na ponte de Wheatstone é muito difícil garantir que algum tempo depois as saídas permaneçam constantes e iguais entre si. Tal pode ser motivado por variações de pré-carga ou simplesmente pelo ruído presente tanto à saída do extensómetro como no circuito de acondicionamento.

Para ultrapassar este problema incluiu-se um segundo procedimento de calibração por software que considera os valores iniciais como correspondendo à posição de equilíbrio5 A partir daqui consideraremos equilíbrio como correspondendo à situação de perna/corpo vertical: o centro de pressão assenta sobre o centro da base do pé. da perna/corpo. A partir daqui todas as medições consequentes são feitas a partir dos valores originais pela adição de um offset.

A calibração segue o seguinte procedimento para cada um dos 4 sensores:

Amostragem e armazenamento de 25 valores de cada sensor de força;

Cálculo da média;

Armazenamento do valor médio de cada sensor (valor original) para correcção das medições futuras.

No passo 1, a leitura dos sensores de força é realizada na forma pura, ou seja, sem a adição de qualquer offset, e só depois do procedimento de calibração, é introduzido o factor de correcção determinado pelo passo 3. Tal correcção é baseada na seguinte expressão:

... em que Sensoroutput é o valor convertido pela ADC, e Sensororiginal é o valor original medido na calibração.

No que toca à operação de leitura, dois procedimentos são essenciais:

Leitura do sensor pela ADC: valor digital de 8 bits correspondente à tensão analógica de entrada;

Correcção do valor lido: “desconto” do valor original do sensor, podendo obter resultados positivos ou negativos (respectivamente acima ou abaixo do valor original);

O valor lido directamente do sensor adapta-se a uma variável do tipo char (8 bits) pelo que pode ser armazenada numa variável deste género. No entanto, a correcção a partir do valor original pode resultar num valor de 9 bits (resultado entre -256 e +256) pelo que após esta operação, o resultado não pode ser armazenado numa variável de 8 bits. Note que a hipótese de uso de variáveis de maior resolução está excluída, uma vez que nas mensagens CAN apenas é possível trocar valores de 8 bits.

Como solução, ao valor lido directamente do sensor é-lhe retirada resolução num factor de 2 (conversão da representação de 8 para 7 bits) e efectuando de seguida a diferença com o valor original, representado também com 7 bits. O resultado será por isso um valor de 8 bits que pode ser armazenado numa variável do tipo char. A diminuição de resolução é realizada pela simples divisão por dois, ou pela shiftagem de um bit para a direita.

A partir desta operação podemos obter resultados entre -128 e +128. Contudo, a representação de valores negativos não faz muito sentido, uma vez que nunca temos forças negativas aplicadas sobre cada sensor, mas sim forças abaixo do valor inicial. Forças negativas implicariam que as placas de acrílico, onde estão fixos os extensómetros, se deformassem no sentido inverso, o que nunca acontece, uma vez que os parafusos de apoio só estão aplicados numa face das placas.

Interessa-nos por isso obter sempre resultados positivos, mas para tal precisaríamos de conhecer à priori a força aplicada inicialmente, o que não sabemos nem temos meios de saber. Para resolver este pormenor, em vez de atribuirmos zero ao resultado inicial iremos atribuir o valor 128 (28-1=128), com os resultados consequentes variando entre 0 e 256 em torno do 128, mas sempre com valores positivos. Uma condição deste género pressupõe que a força inicial situa-se a meia escala do valor máximo, o que nem sempre é verdade, mas pelo menos permite-nos dar a garantia de resultados sempre positivos. De qualquer maneira, a unidade principal de controlo (PC) sempre pode corrigir este resultado pela adição de um segundo offset!

Segundo este princípio o novo algoritmo de calibração será:

Leitura e armazenamento de 25 valores de cada sensor de força considerando um offset nulo;

Cálculo da média dos 25 valores (Sensororiginal);

Armazenamento do novo valor de offset a usar nas medições consequentes:

Quanto à leitura de um sensor de força, o algoritmo seguido é o seguinte:

Amostragem do valor analógico na representação de 8 bits (char) – excursão de 0 a 255;

Redução da resolução para metade (7 bits) – excursão entre 0 e 127;

Correcção do resultado pela adição do offset determinado durante a calibração:

Repare que o valor Sensororiginal possui 7 bits, uma vez que tem de passar pelo procedimento de leitura com a divisão por dois. Só não é afectado pelo offset, uma vez que neste momento ele ainda é nulo. No cálculo do offset a usar no futuro, o seu valor estará compreendido entre 1 e 128 permanecendo com a resolução de 7 bits.

Nos procedimentos de leitura, a excursão de Resultado pode usar toda a gama dos 8 bits, ou seja entre 0 e 255, dado que Sensoroutput e offset podem assumir qualquer valor entre 0/1 e 127/128. No entanto, note que o ponto 128 corresponde ao estado de equilíbrio com que os sensores se encontravam inicialmente...

... com resultados inferiores a 128 para leituras abaixo do valor original, e superiores a 128 para leituras superiores a este valor.

Uma vez que um futuro controlador funcionará a um ritmo de 50Hz (ritmo de PWM de controlo dos motores), a amostragem é executada a todos os quatro sensores em todos os períodos de PWM após a descida do seu impulso. Eis o procedimento executado em cada ciclo e para cada sensor:

Selecção da entrada do multiplexer associado ao sensor a ler;

Espera de 200ns para estabilização do sinal à saída do multiplexer e à entrada da ADC;

Arranque da ADC e espera até a conversão finalizar;

Leitura do valor convertido pelo algoritmo indicado previamente;

Todos os sensores lidos? Em caso negativo passar ao sensor seguinte e voltar ao passo 1;

Em caso afirmativo, seleccionar a entrada do multiplexer associado ao primeiro servomotor a ler;

Deixar estabilizar os sinais (200ns).

Logo após o passo 7, o PIC estará preparado para ler o sinal de posição do primeiro servomotor para cálculo posterior da posição e da corrente consumida (ver secção 3.2.3).

Notas Importantes

Um aspecto importante que deve ter sempre em conta, é que nunca se conhece a força absoluta aplicada sobre cada sensor de força. Aquilo que se conhece é o que se pode medir: uma variação de força aplicada em cada sensor a partir de condições iniciais, tais como:

Deformação inicial das placas de acrílico que sustêm os extensómetros;

Força de pré-carga introduzida pelo peso da plataforma humanóide na situação de equilíbrio;

Amplificação introduzida pelo circuito de acondicionamento de sinal;

Offset introduzido na calibração da ponte de Wheatstone;

Offset introduzido pela calibração via software.

Pelo que a única coisa que temos conhecimento é que:

A variação do sinal medido está relacionado proporcionalmente com a variação da força aplicada;

O sinal medido está relacionado com a força através de um offset.

Embora se possa conhecer o offset pela análise dos dados experimentais (Tabela 41) não nos podemos esquecer que esse valor apenas se aplica a condições iniciais específicas. O que se sabe, é que as condições de pré-carga da plataforma humanóide, bem como a deformação inicial das placas de acrílico não são sempre constantes o que dificulta obviamente esta tarefa. Ainda para piorar, as saídas iniciais dos extensómetros estão sempre em mudança pelo que os offsets de calibração nunca são estáticos.

A ideia apresentada na secção 4.2.2 de substituir as placas de acrílico por placas de aço laminado permite-nos melhorar a performance dos sensores, mas no entanto, as variações inerciais inerentes à locomoção continuam presentes, pelo que não existe uma solução simples para a resolução deste problema.

Contudo, garante-se que a relação de variação entre a deformação e a força é estática pelo que se pode conhecer a variação de força aplicada. Pela Tabela 41 sabe-se que a constante que relaciona a deformação com a força aplicada é de cerca de 4:

... ou seja, sabe-se que uma variação na deformação de uma unidade corresponde a uma variação de força na ordem dos 0.25N. Apenas o valor absoluto é que não se pode conhecer!

MEDIÇÃO DO CENTRO DE PRESSÃO

Representação do Centro de Pressão

O centro de pressão é dado pela projecção da força gravitacional da plataforma humanóide combinada com as forças inerciais inerentes ao próprio movimento, sobre cada pé. Para baixas velocidades as forças inerciais podem ser desprezadas só entrando em linha de conta a força gravitacional da estrutura que cada pé suporta. Como a força gravitacional resultante está relacionada com o centro de massa, podemos dizer que, para baixas velocidades, o centro de pressão corresponde à projecção do centro de massa da estrutura sobre cada pé.

Olhando só para o caso de uma perna, diz-se que o centro de pressão corresponde ao ponto geométrico localizado na base do pé que corresponde à projecção do centro de massa da perna.

Fig. 134: Projecção do centro de massa sobre o pé na situação de equilíbrio.

A Fig. 134 representa a projecção do centro de massa sobre um pé no caso de equilíbrio de apenas uma perna. Quando a perna se encontra na posição vertical, o seu centro de massa é projectado sobre o centro geométrico da base do pé, ou seja, nas coordenadas (x,y)=(0,0).

Cálculo do Centro de Pressão

Como já foi evidenciado na secção anterior, o centro de pressão é dado em coordenadas cartesianas bidimensionais (x,y) segundo o plano do pé. Contudo, não podemos determinar este parâmetro de uma forma analítica com base no cálculo do centro de massa, uma vez que este pressupõe o uso de velocidades extremamente baixas. Como alternativa podemos medir experimentalmente esta grandeza utilizando as forças de reacção obtidas a partir dos extensómetros.

Tal pode ser feito pela análise da distribuição das forças ao longo dos quatro sensores:

Se os quatro sensores indicarem a mesma força, o centro de pressão localiza-se sobre o centro do pé;

Se um sensor apresenta uma força não nula, com as restantes nulas, o centro de pressão desloca-se completamente para a localização do sensor de valor não nulo.

O cálculo do centro de pressão baseia-se por isso, numa média pesada das quatro forças usando a localização dos sensores. Seja a localização dos sensores dada pelos vectores d1, d2, d3 e d4 segundo os eixos cartesianos indicados na Fig. 134:

O centro de pressão é dado pelas expressões:

→

Estas são as expressões usadas para a determinação da localização do centro de pressão nos dois eixos cartesianos.

De notar que o parâmetro Fi indicado corresponde à força absoluta medida. No entanto, tal como foi indicado na secção anterior, esse valor não é mensurável: apenas conseguimos medir um valor que está relacionado com a força segundo uma constante e depende de um valor inicial definido durante a calibração. No que toca à relação proporcional entre o valor medido do sensor e a força aplicada, podemos ignorá-la, uma vez que no cálculo do centro de pressão a constante relacional é anulada entre o numerador e o denominador. Já no que respeita ao valor inicial tal já não se pode fazer!

A força absoluta F é constituída pela combinação da força medida através dos sensores Fmed com o valor inicial no momento da calibração F0 (F=Fmed+F0), pelo que o centro de pressão absoluto CoP também corresponde à combinação entre o centro de pressão obtido a partir da medição dos sensores CoPmed com o centro de pressão inicial CoP0. Embora se garanta que no momento da calibração cada perna está em equilíbrio, pelo que seria de esperar um centro de pressão inicial CoP0 nulo e logo o centro de pressão absoluto CoP coincidiria com o medido (CoPmed), tal não é verdade, uma vez que para ser assim seria necessário garantir que os seguintes factores:

Distribuição de forças ao longo da plataforma superior do pé;

Características elásticas das placas de acrílico;

Deformação inicial das placas de acrílico;

Valores das resistências e do potenciómetro de calibração de cada ponte de Wheatstone;

...fossem iguais entre os quatro sensores de força, o que, obviamente, não são!

Por isso, espera-se que na situação de equilíbrio CoP0 não seja nulo, ou seja, espera-se que as quatro forças medidas inicialmente não sejam constantes. No entanto, a calibração força que estas grandezas sejam constantes pela adição de um offset associado ao valor inicial, fazendo com que o centro de pressão seja nulo sempre que a perna se encontrar na posição definida no início. Claro que convém garantir que inicialmente cada perna está em equilíbrio.

Por isso, a grande utilidade do procedimento de calibração é de atribuir o valor zero ao centro de pressão quando as pernas se encontram na posição de equilíbrio, para que futuros algoritmos de controlo possam procurar um determinado estado desejável sem a preocupação das condições iniciais dos sensores.

CONTROLO DE EQUILÍBRIO

Nesta secção procurar-se-á construir um controlador de equilíbrio que, baseando-se na medição do centro de pressão aplicado nos pés, procure o equilíbrio do plataforma humanóide. Este controlador deverá ser utilizado na perna de suporte na realização da marcha: enquanto uma perna é responsável pelo movimento correspondente a um passo, a outra apenas terá de garantir o equilíbrio da plataforma de modo a evitar qualquer tipo de instabilidade.

No caso de uso de uma só perna, o estado de equilíbrio corresponderá à posição vertical, dado que é a única configuração em que o centro de massa coincide com o ponto central do pé.

Nos testes realizados neste ano lectivo apenas se teve a preocupação do desenvolvimento dos algoritmos de controlo tendo apenas utilizado uma perna para os testes. Testes a realizar no futuro deverão incluir os restantes componentes da estrutura humanóide para análise de comportamentos tanto na presença de irregularidades no solo, como de perturbações externas aplicadas ao longo do corpo, como por exemplo um empurrão.

Estrutura do Controlador

Procurou-se seguir os mesmos princípios que os delineados no controlo de locomoção descritos no capítulo 3, ou seja, implementar um controlador com o mínimo de intervenções a nível de hardware, e construi-lo através de ferramentas via software, de modo a conferir-lhe características de fácil adaptação através de ordens directas da unidade principal de controlo (PC), utilizando para isso a rede de comunicações entre os diversos nós.

Por isso, o controlador deverá seguir a estrutura indicada na Fig. 135, com o bloco de controlo GC(z) e de cálculo do centro de pressão (secção 4.4.2) implementados em software. Com base no centro de pressão desejado CoPref – coordenadas nulas para o caso do equilíbrio – e no centro de pressão medido CoPmed, calculado a partir das forças de reacção, um algoritmo de controlo GC(z) será implementado actuando indirectamente na velocidade v(t) dos três servos da perna associados aos sensores de força: só quando o estado desejado é atingido a velocidade a aplicar será nula colocando os servos em repouso. Como os servos não são controláveis em velocidade, a sua aplicação é feita pelo incremento/decremento sucessivo de posição: o parâmetro v(t) determinado pelo controlador corresponde às variações de posição a aplicar, sendo adicionados às posições actuais dos servos.

Fig. 135: Diagrama de blocos do controlo de equilíbrio de uma perna.

As secções seguintes centram-se na implementação do bloco GC(z), ou seja, na implementação de um controlador, que, com base nos sensores de força, atinja o estado de equilíbrio.

Controlo Proporcional

O tipo de controlo mais simples de implementar, é o controlo proporcional, cuja velocidade a aplicar depende proporcionalmente do erro do centro de pressão. Sendo assim...

A lei de controlo é indicada na última equação verificando-se a relação proporcional entre o erro do centro de pressão e(n) e a velocidade aplicada aos motores v(n) pela constante KP (o produto das últimas duas grandezas é escalar). No entanto note que a perna a equilibrar possui três motores:

Motor lateral do pé;

Motor dianteiro do pé;

Motor do joelho.

... e o parâmetro de velocidade v(n) apenas controla dois motores. Como estes dois motores devem estar associados à deslocação (x,y) da perna de modo a corrigir o centro de pressão (CoPx,CoPy) medido, estes motores deverão corresponder às duas juntas ortogonais do pé (0 e 1). A junta do joelho não é, por isso, utilizada para a compensação.

Junta lateral do pé:
Junta dianteira do pé:

Controlo através da Matriz Jacobiana

Contudo gostaríamos de utilizar todas as juntas para efectuar compensação, incluindo a do joelho quando as duas ortogonais do pé não fossem suficientes. Um exemplo claro da utilidade desta junta é dado quando a junta dianteira do pé satura num dos seus extremos, utilizando-se a partir daí a junta do joelho para continuar a compensação.

Outro pormenor a salientar, relaciona-se com a falta de rigor apresentada na lei de controlo proporcional apresentada: estamos a relacionar o erro do centro de pressão, que é uma grandeza linear de distância, com um parâmetro angular – velocidade – só através de uma constante! Sempre que se pretende relacionar uma grandeza linear com outra angular, uma matriz, denominada por Jacobiano, é utilizada. Por isso, a lei de controlo será modificada de modo a incluir este novo parâmetro:

A matriz Jacobiana representa a relação entre a derivada de um parâmetro linear com a derivada de um parâmetro angular. Para o nosso caso pretendemos relacionar centro de pressão (parâmetro linear) com a posição (parâmetro angular) pelo que:

... cujo centro de pressão CoP é um valor ternário representado nas coordenadas espaciais (x,y,z) e q corresponde às posições θ0, θ1, e θ2 das juntas lateral e dianteira do pé, e do joelho respectivamente. Note que nesta matriz já está incluída a posição do joelho o que prevê a controlabilidade desta junta. Embora a coordenada z de CoP não tenha significado, optou-se por incluí-lo, pois confere o formato quadrado à matriz Jacobiana, o que facilita o cálculo da sua inversa.

Cálculo da Matriz Jacobiana

Para podermos calcular esta matriz teremos de conhecer a relação entre o centro de pressão e cada uma das juntas θ. Dado que não conhecemos nenhuma expressão analítica que nos forneça tal informação, faremos a suposição do centro de pressão coincidir com o centro de massa, o que até verdade se nos restringirmos a velocidades baixas.

Já o centro de massa podemos calcula-lo através da expressão analítica:

... em que Mi representa a massa de cada elo, e Ri a distância do início de cada elo ao seu centro de massa.

Fig. 136: Diagrama representativo de uma perna sob a vista lateral (esquerda) e dianteira (direita).

A Fig. 136 representa uma perna sob duas perspectivas diferentes – de lado e de frente. A partir deste diagrama, as expressões dos centros de massa para as diversas componentes espaciais podem ser deduzidas:

Seja CoMz' como a localização do centro de massa no eixo zz sem a consideração da elevação h:

Então:

Calculando agora as derivadas parciais relativamente a cada junta θi, obtemos:

Com:

Assim obtemos, por fim, a matriz Jacobiana J com cada linha representando cada componente espacial (x,y,z), e cada coluna representando cada junta q=(θ0,θ1,θ2).

Para o cálculo da matriz Jacobiana várias grandezas deverão ser conhecidas:

Massa de cada elo (M1 e M2);

Comprimento de cada elo (L1 e L2);

Posição do centro de massa de cada elo (R1 e R2);

Posição angular de cada junta (θ0, θ1 e θ2).

As primeiras três referem-se a grandezas estáticas do sistema e deverão ser conhecidas à priori. Já as posições angulares q deverão ser medidas pois estão sempre em constante mudança. Devido a este facto a matriz Jacobiana é uma matriz dinâmica que depende de q e que, por isso, varia ao longo do tempo.

Um detalhe importante a salientar, é que as posições medidas pelos potenciómetros não podem ser inseridas directamente nas equações dado que a orientação dos eixos e os valores iniciais indicados na Fig. 136 diferem relativamente aos medidos. Um exemplo simples refere-se à junta dianteira do pé: na posição vertical a posição θ1, segundo a Fig. 136 deverá corresponder a 90º, mas medindo através do microcontrolador teremos 0º. Temos, por isso, de fazer uma adaptação das posições medidas ao conjunto q=(θ0,θ1,θ2) utilizado nas equações.

Tabela 42: Dados do deslocamento dos servos na perna esquerda (perspectiva do robot).

Junta	Sentido do deslocamento	Offset na medição	Relação de transmissão
Lateral do pé	+1	0º	2.6
Dianteira do pé	+1	0º	2.6
Joelho	–1	+70º	2.6

Tabela 43: Dados do deslocamento dos servos na perna direita (perspectiva do robot).

Junta	Sentido do deslocamento	Offset na medição	Relação de transmissão
Lateral do pé	–1	0º	2.6
Dianteira do pé	–1	0º	2.6
Joelho	+1	–70º	2.6

A Tabela 42 e a Tabela 43 indicam os dados de deslocamento dos servos para cada perna. O sentido de deslocamento é comparado com o da Fig. 136 (+1 se coincide com o sentido indicado na figura, e –1 se é o inverso), o offset indica as posições medidas com a perna na vertical, e a relação de transmissão refere-se às correias de transmissão utilizadas nos servos. Com base nestes valores, uma equações de adaptação pode ser deduzida:

Ao θ medido é-lhe retirado o valor correspondente à posição vertical (offset) e o seu sinal é trocado de acordo com o valor de sentido. Depois é dividido pela relação de transmissão para obtermos o ângulo efectivo. Se, por acaso, a junta corresponde à dianteira do pé, dever-se-á adicionar 90º, dado que, segundo a Fig. 136, esta junta possui 90º na posição vertical.

Agora que o valor de θ está adaptado já podemos utilizá-lo nas equações do Jacobiano.

O Controlador utilizando a Matriz Jacobiana

Pela lei de controlo enunciada atrás, cada parâmetro, à excepção da matriz Jacobiana, corresponde a uma matriz coluna ternária:

Com o erro e a matriz Jacobiana correspondendo às seguintes expressões:

A velocidade v e a constante de proporcionalidade KP dizem respeito a cada junta (θ0,θ1,θ2), e o erro do centro de pressão e diz respeito a cada componente espacial (x,y,z). A componente z do erro também foi incluída dado o produto vectorial exigir três elementos. Como esta componente não é mensurável atribuiu-se permanentemente o valor nulo.

Quanto à matriz Jacobiana, ela depende das posições angulares das juntas, pelo que nunca é constante. Devido a este facto seria necessário calcular sempre, em tempo real, a inversa desta matriz, o que em termos de carga de processamento é muito pesado para um microcontrolador. Para contornar este problema, aproximou-se a inversa à matriz transposta, o que até apresenta vantagens uma vez que se evitam as singularidades que tornam o sistema instável.

Logo substituindo e considerando o erro do centro de pressão nulo na componente zz:

... temos para cada junta:

Junta lateral do pé:
Junta dianteira do pé:
Junta do joelho:

Estas expressões são utilizadas pelo microcontrolador para controlar cada junta. Ao contrário do caso do controlo proporcional, agora temos a junta do joelho em funcionamento o que deve conferir maior rapidez na correcção da componente yy do centro de pressão.

RESULTADOS EXPERIMENTAIS

Vamos agora pôr em prática os algoritmos de controlo descritos e observar os seus resultados. Os controladores foram configurados de modo a procurar a posição de equilíbrio, ou seja, o ponto, cujo centro de pressão, coincide com o centro geométrico do pé: coordenadas (x,y)=(0,0).

Considerando CoPx e CoPy como os centros de pressão medidos em cada componente espacial (x,y):

Junta lateral do pé:
Junta dianteira do pé:
Junta do joelho:

Três experiências foram realizadas para testar a eficiência destas leis de controlo:

Variação do declive do plano de apoio;

Pressão sobre cada um dos sensores;

Introdução de perturbações externas.

Variação do Declive do Plano de Suporte

A primeira experiência põe em prática a ideia sugerida sobre a tarefa da perna de suporte na realização da locomoção, ou seja, na presença de irregularidades do solo, como variação do seu declive ou presença de corpos estranhos, a perna deve mover-se de modo a garantir o equilíbrio da estrutura.

Nesta experiência aplicaram-se variações da inclinação do plano de suporte a uma perna, cujo controlador deverá procurar a posição de equilíbrio, ou seja, a posição vertical. A Fig. 137 apresenta a experiência realizada: segundo o sistema de eixos apresentado na Fig. 134 efectuaram-se variações na inclinação do plano, primeiramente segundo o eixo dos yy e depois segundo o eixo xx.

Fig. 137: Variação da inclinação do plano de suporte segundo o eixo yy (esquerda) e o eixo xx (direita).

Os resultados estão expressos nos gráficos seguintes onde se visualiza a posição do centro de pressão segundo os eixos xx e yy (da Fig. 134), a posição q dos servomotores presentes na perna de teste:

Servo 0: junta lateral do pé (usada para compensar o CoP segundo o eixo xx);

Servo 1: junta dianteira do pé (usada para compensar o CoP segundo o eixo yy);

Servo 2: junta do joelho (usado para compensação adicional do CoP segundo o eixo yy).

... e a corrente consumida por cada um deles em unidades normalizadas (percentagem), para um tempo de medição de 30s. Os resultados são comparados entre os dois tipos de controlador apresentados.

Variação da inclinação do plano segundo o eixo xx

Fig. 138: Variação do declive do plano segundo o eixo xx (controlo proporcional).

Fig. 139: Variação do declive do plano segundo o eixo xx - controlo pelo Jacobiano.

Neste primeiro ensaio apenas se variou a componente xx do plano, verificando-se, segundo os gráficos da Fig. 138 e da Fig. 139, algumas variações na componente xx do CoP durante a compensação. Por análise, pode-se observar que, embora se incline o plano até cerca de 45º, o controlador não permite erros do CoP superiores a 2 mm do ponto de equilíbrio.

Usando o controlador proporcional pode-se constatar que o servomotor responsável por compensar esta componente (servo 0 – junta lateral do pé) foi o único a ser utilizado atingindo um deslocamento máximo de cerca de 45º, por forma a compensar a inclinação de 45º introduzida.

Comparando agora com o controlador que utiliza o Jacobiano, pode-se observar um comportamento muito semelhante, também com um deslocamento do servo 0 na ordem dos 45º. Como a junta do joelho pouco interfere com a componente xx do CoP, esta manteve-se praticamente imóvel.

Variação da inclinação do plano segundo o eixo yy

Efectuando agora variações da inclinação do plano segundo o eixo yy, pode-se verificar, pela Fig. 140 e pela Fig. 141, um comportamento análogo ao do caso anterior, mas com a diferença de apenas ser utilizado o servo 1 (junta dianteira do pé) para compensar a variação do CoP no eixo yy.

As primeiras experiências efectuadas (não visualizadas aqui) evidenciaram uma inferior sensibilidade na compensação desta componente apresentando uma reacção bastante lenta no controlo. Tal é explicado pelo formato rectangular do pé: dado que a distância entre o conjunto dianteiro e traseiro dos sensores é muito maior que entre os conjuntos laterais, é de esperar que a sensibilidade na medição do CoPy seja bastante menor que na medição do CoPx. Para colmatar este problema aumentou-se a elasticidade das placas de acrílico dianteiras pela diminuição da sua secção. Esta modificação permitiu aumentar a sensibilidade da compensação na componente yy sem afectar significativamente a da componente xx, apresentando como único inconveniente o aparecimento de alguma oscilação devida a ruído.

Fig. 140: Variação do declive do plano segundo o eixo yy (controlo proporcional).

Utilizando o algoritmo de controlo incluindo a matriz Jacobiana (Fig. 141), podemos observar a novidade do uso da junta do joelho na compensação, introduzindo maior eficiência na compensação.

Fig. 141: Variação do declive do plano segundo o eixo yy - controlo pelo Jacobiano.

Variação da inclinação do plano simultaneamente segundo o eixo xx e yy

Fig. 142: Inclinação do plano segundo os eixos xx e yy.

Os gráficos da Fig. 143 apresentam os resultados para a variação do plano simultaneamente nos eixos xx e yy, observando-se deslocamentos simultâneos por parte dos dois servomotores do pé, de modo a corrigir as variações do CoP nas duas componentes espaciais.

Embora não sejam visualizados os resultados para o compensador com a matriz Jacobiana, os resultados são bastante semelhantes.

Fig. 143: Variação do declive do plano na diagonal dos eixos xx e yy (controlo proporcional).

Pressão isolada sobre os Sensores de Força

A segunda experiência procura explorar os resultados na pressão directa sobre os sensores. Os resultados devem ser semelhantes à anterior com deslocamentos opostos ao sensor premido. Esta experiência permite analisar os efeitos quando apenas um sensor sente variações da força aplicada sobre si, esperando-se observar uma reacção mais rápida. Desta forma, pode-se tirar conclusões sobre a velocidade de resposta do controlador.

Fig. 144: Pressão directa sobre os sensores de Força.

Dois ensaios foram efectuados:

Pressão no ponto intermédio entre cada par de sensores (cima, baixo, esquerda e direita);

Pressão isolada em cada sensor.

Pressão no Ponto Intermédio entre cada par de Sensores

Fig. 145: Pressão no ponto intermédio entre cada par de sensores (frente, trás, esquerda e direita) - controlo Proporcional.

Fig. 146: Pressão no ponto intermédio entre cada par de sensores (frente, trás, esquerda e direita) - controlo pelo Jacobiano.

Os gráficos da Fig. 145 e da Fig. 146 foram registados premindo os sensores na seguinte sequência:

Sensores dianteiros;

Sensores traseiros;

Sensores da esquerda;

Sensores da direita.

Pode-se evidenciar em ambas as figuras, a utilização inicial do servo 1 (junta dianteira do pé) para compensar as variações do CoP na componente yy (pressão nos sensores dianteiros e traseiros), bem como o uso da junta do joelho no caso do controlador com o Jacobiano (Fig. 146).

Já durante a pressão dos sensores laterais, apenas se verifica variação do CoP no eixo xx e, por isso, apenas é utilizado o servo 0 (junta lateral do pé) em ambos os casos de compensação.

Pressão isolada sobre cada Sensor

Neste ensaio premiu-se cada sensor, de forma directa e isolada, relativamente aos restantes. Tal procedimento provoca deslocamentos na diagonal, uma vez que o deslocamento deve ser oposto ao sensor premido, o que implica o uso simultâneos de todos os servos, tal como se pode constatar na Fig. 147 e na Fig. 148.

A sequência dos sensores premidos foi a seguinte:

Sensor dianteiro esquerdo;

Sensor dianteiro direito;

Sensor traseiro esquerdo;

Sensor traseiro direito.

Fig. 147: Pressão de cada sensor de forma isolada (superior esquerdo, superior direito, inferior esquerdo, inferior direito) - controlo Proporcional.

Fig. 148: Pressão de cada sensor de forma isolada (superior esquerdo, superior direito, inferior esquerdo, inferior direito) - controlo pelo Jacobiano.

Introdução de Perturbações Externas

A terceira experiência explora os efeitos da presença de perturbações externas. Entende-se por perturbações externas, as forças que não são aplicadas directamente sobre os pés, mas que de forma indirecta são sentidas pelos sensores de força. Um exemplo é a aplicação de forças sobre uma perna ou sobre a estrutura da plataforma, como toques ou empurrões, em que inevitavelmente os sensores dos pés detectarão estas anomalias e o controlador responderá da mesma forma como se se tratasse de uma aplicação directa da força sobre o pé.

Seria interessante fazer com que o controlador distinguisse estes tipos de aplicação, podendo eventualmente aplicar diferentes tipos de controlo para melhor se adequar à situação em causa, mas infelizmente, não existem meios de detectar a origem das forças pelo que ficaremos limitados a um único tipo de controlo.

Aplicaram-se perturbações, na forma de empurrões, sobre a perna em teste na seguinte sequência:

Frente;

Trás;

Esquerda;

Direita.

... sob a perspectiva de trás da perna.

Empurrões suficientemente bruscos foram aplicados de forma a provocar o levantamento do pé sobre o solo, de modo a analisar o comportamento do controlador no caso em que o centro de massa da perna deixa de coincidir com o centro de pressão.

Fig. 149: Introdução de perturbações externas na perna (frente, trás, esquerda e direita) - controlo Proporcional.

Fig. 150: Introdução de perturbações externas na perna (frente, trás, esquerda e direita) - controlo pelo Jacobiano.

Um controlador baseado no centro de massa como o implementado, procura fazer o deslocamento oposto ao introduzido pela nova força: se uma força externa desloca o centro de pressão para um valor diferente do de referência, o controlador assumirá que o centro de massa se deslocou na mesma direcção – para os sensores do extremo oposto aonde foi aplicada a força – e, por isso, efectuará o deslocamento oposto, de modo a repor o centro de massa na posição de equilíbrio. Tal implica que a perna tenda a fazer movimentos na direcção onde é aplicada a força externa. Este efeito acontece nas experiências realizadas, cujos gráficos da Fig. 149 e da Fig. 150 nos mostram, apresentando-se mais intenso no caso em que o pé se levanta do solo.

Embora este efeito seja desejável, uma vez que procura contrariar a presença de forças externas, verifica-se o problema de se deixar de garantir a postura vertical da perna na situação de equilíbrio, uma vez que a presença da força estranha faz divergir o CoP medido do CoM da estrutura. Mais ainda, se a base do pé deixar de estar em completo contacto com o solo, o CoP tende a deslocar-se e a manter-se na extremidade oposta à aplicação da força, independentemente da postura da perna, resultando na saturação das juntas. Tal situação corresponde à máxima divergência entre CoP e CoM.

Outro aspecto a salientar reside no facto de nem sempre ser necessária compensação negativa no controlo do centro de massa. Tal acontece no caso da adaptação dos pés a pisos irregulares: neste caso as juntas dos pés devem adaptar-se até toda a sua base assentar no piso. Para tal, também pode ser usado como feedback a posição do centro de pressão, mas agora com compensação positiva no controlo – deslocamento dos servos no sentido oposto. Apenas depois de este procedimento estar completo (base do pé em contacto com o solo) o algoritmo tradicional é que pode entrar em funcionamento. Este controlador de compensação oposta poderá ser utilizado na perna de locomoção até esta se encontrar completamente assente sobre o solo, e só a partir deste ponto, o algoritmo de equilíbrio com base no centro de massa entraria em funcionamento, passando a atribuir a função de suporte a esta perna.

Experiências Adicionais

Nesta experiência adicional, levantou-se a perna, de modo a suspender o pé, e observou-se o comportamento do controlador. Segundo a Fig. 151 e a Fig. 152, quando o pé está suspenso, o valor do centro de pressão afasta-se do ponto de equilíbrio, o que provoca o deslocamento dos servomotores. Como este deslocamento em nada afecta a medição de forças nos sensores (dada a ausência de forças de reacção), o centro de pressão continuará desequilibrado, independentemente da posição dos servos, levando à saturação na actuação dos servos.

Estes resultados sugerem que a distribuição de forças sobre a base do pé não é homogénea. Embora após activação todos os sensores sejam inicializados num determinado valor inicial, a força absoluta aplicada em cada um é diferente, o que faz com que na ausência do plano de suporte as forças medidas sejam diferentes de sensor para sensor resultando num valor do CoP diferente do valor inicial. É este offset que provoca o deslocamento dos servos até à saturação.

Para esta falta de homogeneidade contribuem os seguintes factores;

Diferente natureza das placas de acrílico de suporte aos extensómetros: como os sensores da frente são mais sensíveis que os traseiros, o CoP medido é deslocado para a traseira do pé quando levantado.

Plataforma superior do pé não homogénea;

Mesmo resolvidos estes dois aspectos, ocorre um novo problema: se no momento da calibração, o CoM do robot não coincide com a posição de equilíbrio, como é o caso em que a perna não está exactamente na vertical, verifica-se uma diferença nas forças absolutas aplicadas inicialmente. Esta diferença revelar-se-á na ausência do solo, resultando no desequilíbrio permanente dos sensores. Como condições para que tal não aconteça é necessário que:

A plataforma superior do pé seja completamente homogénea;

As quatro placas de acrílico sejam exactamente iguais, e estejam fixas à plataforma superior de forma semelhante entre si.

O centro de massa da estrutura do robot coincida com o centro de pressão nulo no momento da calibração.

Estas são condições muito difíceis de garantir, pelo que ainda não existem soluções em vista para resolver este problema.

Fig. 151: Levantamento do pé no ar - controlo proporcional.

Fig. 152: Levantamento do pé no ar - controlo pelo Jacobiano.

ORGANIZAÇÃO DO SOFTWARE

A Fig. 153 apresenta os últimos módulos a descrever (a cinzento), cujos algoritmos de compensação de equilíbrio estão implementados. Os blocos a verde já foram explicitados nos capítulos anteriores.

Fig. 153: Relações de inclusão dos módulos de software de cada Slave.

Módulo SERVO

Este módulo já foi apresentado na secção e implementa as rotinas de execução da compensação dos servomotores. As suas funções de acesso global estão acessíveis na Tabela 34 com a função controller possuindo a responsabilidade de invocar as rotinas que implementam os algoritmos de controlo (Tabela 35).

Tabela 44: Rotinas de implementação da compensação chamadas pela função controller.

Função	Descrição
openloopControl	Controlo dos servomotores em malha aberta. A posição indicada na chamada da função servoRequest é atribuída ao servo em causa, sem passar por qualquer algoritmos de compensação.
locomotionControl	Compensação PID da posição de cada servomotor.
reactionControl	Compensação das forças de reacção aplicadas nos pés segundo a lei proporcional (secção 4.5.2).
JacobianControl	Compensação das forças de reacção utilizando a matriz Jacobiana (secção 4.5.3).

Os algoritmos de compensação de equilíbrio descritos na secção 4.5 estão implementados nas rotinas reactionControl e JacobianControl sendo necessário um comando applycontrol por parte do PC para selecção do controlador de equilíbrio pretendido (ver Tabela 4).

Como estas duas funções baseiam-se no controlo de velocidade e não directamente pela posição, construiu-se a rotina applyVelocity que implementa a acção de velocidade através do in/decremento de posição. Adicionalmente foi incorporado um limitador de velocidade de modo a evitar qualquer tipo de instabilidade na acção do controlador.

Módulo DATA

Este módulo contém as ferramentas necessárias para a implementação dos algoritmos de equilíbrio presentes na biblioteca SERVO. Além disso possui todas as características físicas do pé e da perna utilizados (Tabela 45 e Tabela 46).

Tabela 45: Características do pé sensível às forças de reacção.

Localização de cada sensor (mm)
Sensor	Coordenada x	Coordenada y
Dianteiro esquerdo	-32.5	6.20
Dianteiro direito	32.0	6.20
Traseiro esquerdo	-35.0	-6.25
Traseiro direito	34.0	-6.25

Tabela 46: Características físicas da perna.

Parâmetro	Símbolo	Valor
Massa do elo inferior	M1	450 g
Massa do elo superior	M2	450 g
Comprimento do elo superior	L1	95 mm
Comprimento do elo inferior	L2	95 mm
CoM do elo superior	R1	47 mm
CoM do elo superior	R2	47 mm

A localização dos sensores de força (Tabela 45) foram obtidas por medição directa, enquanto que as características da perna foram consultadas no relatório do ano lectivo anterior (Tabela 46).

Também os parâmetros da Tabela 42 e da Tabela 43 foram incluídos para conversão da posição medida para a posição angular a usar no cálculo da matriz Jacobiana (fim da secção 4.5.3.1).

Tabela 47: Funções do módulo DATA.

Função	Descrição
calcCoP	Cálculo das coordenadas do centro de pressão com base nas forças de reacção.
jacobianMatrix	Cálculo da matriz Jacobiana para aplicação do controlador de equilíbrio baseado no Jacobiano.

Para o cálculo do centro de pressão são relacionados os parâmetros de localização dos sensores de força indicados na tabela Tabela 45 com as suas saídas tal como expresso na secção 4.4.2.

No que toca à matriz Jacobiana as grandezas da Tabela 46 são utilizadas para o cálculo de cada elemento da matriz usando também as funções trigonométricas definidas na biblioteca mymaths. As expressões analíticas para o cálculo dos vários elementos estão disponíveis na secção 4.5.3.1.

CONCLUSÕES

Este capítulo apresentou dois algoritmos de controlo destinados à perna de suporte durante a locomoção, tendo como objectivo a manutenção do equilíbrio da estrutura humanóide, usando como feedback as forças de reacção fornecidas pelos extensómetros presentes na base de cada pé. Estes sensores permitem medir a localização geométrica do centro de pressão (CoP) utilizando-se este parâmetro num controlador para que, por movimento das juntas de cada perna, o estado de equilíbrio seja atingido fazendo com que o CoP (ou centro de massa – CoM – para baixas velocidades) coincida com o centro geométrico de cada pé.

O primeiro algoritmo de carácter puramente proporcional – velocidade das juntas proporcional ao erro do CoP – permite controlar as duas juntas ortogonais do pé (junta lateral e dianteira) de modo a compensar as variações do CoP nos eixos xx e yy. Apenas quando estas duas componentes forem nulas, é considerado que a estrutura está em equilíbrio. O segundo algoritmo procura fazer uso da junta do joelho para optimizar o controlo. Para tal é adicionado um novo termo na lei de controlo: a matriz Jacobiana que relaciona de uma forma mais precisa o erro do CoP e a velocidade angular a aplicar às três juntas. Embora esta matriz seja calculada a partir do CoM (pouco precisa para elevadas velocidades, uma vez que o CoP diverge do CoM à medida que se aumenta a velocidade) e se usar a operação transposta à matriz em vez da inversa, o resultado até é bastante satisfatório com respostas bastante reactivas e o uso completo das três juntas de cada perna, tal como demonstraram os resultados experimentais.

Estes algoritmos mostraram ser possível, o controlo de equilíbrio de uma perna, mantendo a postura vertical qualquer que fosse a inclinação do plano de suporte. Comparando a eficácia dos dois algoritmos apresentados, não foi possível evidenciar diferenças significativas na realização da tarefa em causa, pelo que muito provavelmente não se justifica a utilização do algoritmo com a matriz Jacobiana, dada a sua complexa implementação que exige o conhecimento físico da perna em uso, como a massa dos elos, os seus comprimentos e a posição dos centros de massa de cada um. Além disso, após a inclusão da perna na restante estrutura humanóide, o cálculo da matriz torna-se bastante mais complexo pois é necessário entrar em linha de conta com toda a restante estrutura. Usando apenas o controlo proporcional, muito embora não sejamos capazes de controlar a junta do joelho, é possível efectuar a compensação com uma boa velocidade de reacção e com reduzidas oscilações.

Como extra, estes controladores também permitem efectuar a compensação na aplicação de forças externas, como a presença de empurrões, fazendo com que as juntas respondam contrariando a força introduzida e, assim, ajudar a manter o estado de equilíbrio. No entanto ainda resta resolver a questão, de como se pode garantir a postura vertical das pernas independentemente da força aplicada, uma vez que deixamos de medir, nestas circunstâncias, o CoM, que noutras circunstâncias coincidiria com o CoP medido.

De salientar também, que na compensação do declive do plano, embora o sistema fosse calibrado com a perna na vertical, ao fim de algum tempo de funcionamento, a postura vertical na situação de equilíbrio desaparecia, dando a entender que a deformação dos extensómetros modificava-se ao longo do tempo para uma determinada postura. Este comportamento apenas pode ser atribuído às placas de acrílico com a ocorrência de histerese na sua deformação. Estudando outros materiais, chegou-se à conclusão que, se substituirmos o acrílico por aço laminado presente nas lâminas das serras de corte de metal, as propriedades elásticas eram bastante melhoradas com uma elevada flexibilidade na deformação e facilidade no retorno à posição original (baixa histerese). Será interessante num futuro próximo efectuar esta modificação.

Chegou-se também à conclusão que os controladores de equilíbrio também podem ser usados para adaptar os pés a pisos irregulares. Isso poderá ser executado no futuro pela perna motriz apenas ao nível do pé, estando a ser usadas as restantes juntas para ordens directas de locomoção. Usando compensação positiva – deslocamento dos servos a favor do deslocamento do CoP – os pés tendem a adaptar-se ao piso, terminando a função de motricidade quando estes estiverem completamente assentes sobre o solo, e iniciando logo de seguida a função de perna de suporte.

No entanto ainda subsiste o problema presente na ausência de forças de reacção. É o caso em que o pé está suspenso no ar, que pelo facto de no momento da calibração, as forças absolutas aplicadas sobre os sensores não serem iguais, na ausência do solo os quatro sensores de força apresentam saídas diferentes resultando num CoP não nulo. Como nesta situação particular não é possível compensar o CoP, dada a inexistência de forças de reacção, o controlador satura os actuadores nos seus valores limite. Embora se conheçam as causas de tal problema, ainda se encontra em aberto uma solução.

NOTAS FINAIS

AGRADECIMENTOS

Agradece-se toda a cooperação por parte do Departamento de Mecânica pela disponibilidade de recursos e toda a ajuda fornecida para a realização deste projecto, em especial atenção ao co-orientador de projecto Vítor Santos que nunca mediu esforços na resolução dos desafios que se foram apresentando ao longo deste ano.

BIBLIOGRAFIA

Milton Ruas, Filipe M. T. Silva, Vítor M. F. Santos, “Parameter Measurement for Speed and Torque Control of RC Servomotors on a Small-Size Humanoid Robot”, nas actas do Encontro Científico Robótica2006, Guimarães, 2006.

Milton Ruas, Filipe M. T. Silva, Vítor M. F. Santos, “Techniques for Velocity and Torque Control of RC Servomotors for a Humanoid Robot”, aceite para publicação nos proceedings da 9th International Symposium on Climbing and Walking Robots and Associated Technologies, 11-14 September 2006

Milton Ruas, Filipe M. T. Silva, Vítor M. F. Santos, “A Low-Level Control Architecture for a Humanoid Robot”, submetido à International Conference on Humanoid Robots 2006.

Vítor M. F. Santos, Filipe M. T. Silva, “Engineering Solutions to Build an Inexpensive Humanoid Robot Based on a Distributed Control Architecture”, proceedings of the IEEE International Conference on Humanoid Robots 2005.

Vítor M. F. Santos, Filipe M. T. Silva, “Development of a Low-Cost Humanoid Robot: Components and Technological Solutions”, proceedings of the CLAWAR 2005.

Luís Gomes, Mauro Silva, “Concepção e Desenvolvimento de Unidades de Percepção e Controlo para um Robot Humanóide”, Relatório final de projecto 2004/05 – Departamento de Mecânica

Nuno Beça, Ângelo Cardoso, “Desenvolvimento e Integração das Sub-estruturas Inferior e Superior para a Locomoção de uma Plataforma Humanóide”, Relatório final de projecto 2004/05 – Departamento de Mecânica.

K. S. Fu, R. C. Gonzalez, C. S. G. Lee; “Robotics: Control, Sensing, Vision and Intelligence”, MacGraw-Hill, 1987

Índice de Figuras

Fig. 1: QRIO da Sony.	7

Fig. 2: Asimo da Honda.	7

Fig. 3: KHR 3 (Hubo Lab).	7

Fig. 4 - Modelo 3D do robot e implementação actual.	9

Fig. 5 - Arquitectura distribuída da plataforma.	10

Fig. 6: Exemplo de uma board PC-104.	13

Fig. 7: Placa de controlo Master/Slave.	13

Fig. 8: Rede completa de Microcontroladores.	13

Fig. 9: Algoritmo geral dos device drivers da unidade principal.	23

Fig. 10: Algoritmo de envio de uma mensagem para o Master.	24

Fig. 11: Algoritmo para recepção da mensagem de resposta do Master.	24

Fig. 12: Algoritmo de recepção de informação, via USART, pelo Master	26

Fig. 13: Algoritmo de transmissão de informação, via USART, pelo Master.	27

Fig. 14: Formato standard das mensagens CAN.	29

Fig. 15: Exemplo de aplicação utilizando o CSMA/BA.	29

Fig. 16: Particionamento temporal de um bit.	34

Fig. 17: Registos associados à mascaragem e filtragem.	35

Fig. 18: Algoritmo de troca de informação pelo CAN no Master.	38

Fig. 19: Algoritmo de troca de informação pelo CAN no Slave.	40

Fig. 20: Relações de inclusão dos módulos de software do Master.	42

Fig. 21: Relações de inclusão dos módulos de software de cada Slave.	45

Fig. 22: Arquitectura da plataforma humanóide.	51

Fig. 23: Constituição de uma unidade slave.	52

Fig. 24: Imagens de uma unidade de controlo local.	52

Fig. 25: Representação do interior de um servomotor.	55

Fig. 26: Servomotor da HITEC	55

Fig. 27: Sinal de PWM aplicado no servomotor.	55

Fig. 28: Correia de transmissão aplicada a um servo.	56

Fig. 29: Circuito do controlador de posição de um FUTABA S3003.	57

Fig. 30: Representação esquemática do controlador de posição interno.	58

Fig. 31: Arquitectura das comunicação no setup.	59

Fig. 32: Setup experimental.	59

Fig. 33: Resistência a adicionar a cada saída de PWM do PIC.	60

Fig. 34: Geração de um sinal de PWM através de dois timers.	60

Fig. 35: Organização temporal das interrupções na geração do PWM.	61

Fig. 36: Atendimento às interrupções de alta frequência.	62

Fig. 37: Impulso de tensão medido na presença de cargas/velocidades elevadas.	63

Fig. 38: Relação entre a posição e a largura de impulso.	64

Fig. 39: Configuração possível para medição da corrente.	64

Fig. 40: Organização das interrupções (setas) na medição sensorial.	65

Fig. 41: Algoritmo de leitura dos três servomotores.	67

Fig. 42: Multiplexagem na leitura dos servos.	67

Fig. 43: Processamento final (fim do período de PWM).	68

Fig. 44: Algoritmo de processamento da tensão medida para cada servomotor.	68

Fig. 45: Array circular para armazenamento de posições.	70

Fig. 46: Representação do servomotor por uma função de transferência G(s).	71

Fig. 47: Exemplo da resposta de um sistema (Gf) com a indicação das suas características.	72

Fig. 48: Comparação das respostas ao degrau para duas cargas no percurso de -45 para +45º.	72

Fig. 49: Resposta ao degrau de -45 para +45º com uma carga de 924g.	73

Fig. 50: Resposta ao degrau de +45 para -45º com uma carga de 924g.	73

Fig. 51: Aplicação de um degrau de -45º para +45º no instante t=1,8s.	74

Fig. 52: Aplicação de uma rampa de posição de velocidade média 50º/s.	74

Fig. 53: Trajectória polinomial de terceira ordem.	74

Fig. 54: Comportamento da velocidade e da aceleração na trajectória polinomial.	74

Fig. 55: Resposta à rampa com duas cargas diferentes (Δp=5º, Δt=100ms).	75

Fig. 56: Resposta à rampa com uma carga pesada (Δp=5º, Δt=100ms).	75

Fig. 57: Resposta ao polinómio para duas cargas diferentes (Ttraj=1s).	75

Fig. 58: Controlo externo do servomotor.	77

Fig. 59: Compensador PID incremental.	77

Fig. 60: Resposta à rampa com uma carga de 675g (KI=0.08).	79

Fig. 61: Resposta à rampa com uma carga de 1129g (KI=0.08).	79

Fig. 62: Resposta à rampa com uma carga de 1129g (KI=0.20).	80

Fig. 63: Erro da resposta da Fig. 51.	80

Fig. 64: KI=0.02 (m=924g)	80

Fig. 65: KI=0.07 (m=924g)	80

Fig. 66: KI=0.15 (m=924g)	80

Fig. 67: KI=0.30 (m=924g)	80

Fig. 68: Fenómeno do overshoot para valores de KI elevados (carga de 924g)	81

Fig. 69: Erro da resposta da Fig. 55.	81

Fig. 70: Correcção do overshoot com o aumento de KP (carga de 924g).	81

Fig. 71: Erro da resposta da Fig. 57.	81

Fig. 72: Variação de KP para KI=0.05 (carga de 675g).	82

Fig. 73: Variação de KP para KI=0.10 (carga de 675g).	82

Fig. 74: Resposta ao polinómio com KI=0.05 e KP=0.00 (carga de 675g).	82

Fig. 75: Resposta ao polinómio com KI=0.10 e KP=0.00 (carga de 675g).	82

Fig. 76: Comparação entre dois conjuntos de parâmetros durante o tunning (m=675g).	84

Fig. 77: Situação de instabilidade (m=675g).	84

Fig. 78: PID optimizado para uma carga de 675g.	84

Fig. 79: Repetição do ensaio com os parâmetros de compensação óptimos.	84

Fig. 80: Medição estática da corrente para duas cargas num percurso em subida (-90º a +90º).	87

Fig. 81: Medição estática da corrente para duas cargas num percurso em descida (+90º a -90º).	87

Fig. 82: Resposta em malha aberta de uma trajectória polinomial de 1s entre dois pontos de binário intermédio para duas cargas.	88

Fig. 83: Medição da corrente para cada posição do trajecto da Fig. 82.	88

Fig. 84: Medição da corrente ao longo do tempo do trajecto da Fig. 82.	88

Fig. 85: Resposta em malha aberta de uma trajectória polinomial de 1s desde o ponto de binário nulo até ao máximo.	89

Fig. 86: Medição da corrente para cada posição do trajecto da Fig. 85.	89

Fig. 87: Medição da corrente ao longo do tempo do trajecto da Fig. 85.	89

Fig. 88: Resposta em malha aberta da trajectória polinomial de 1s desde o ponto de máximo binário até ao nulo.	90

Fig. 89: Corrente consumida em cada posição do trajecto da Fig. 88.	90

Fig. 90: Corrente consumida ao longo do tempo do trajecto da Fig. 88.	90

Fig. 91: Resposta em malha fechada de uma trajectória polinomial de 1s entre dois pontos de binário intermédio.	91

Fig. 92: Corrente consumida em cada posição do trajecto da Fig. 91.	91

Fig. 93: Corrente consumida ao longo do tempo do trajecto da Fig. 91.	91

Fig. 94: Resposta em malha fechada de uma trajectória polinomial de 1s desde o ponto de binário nulo até ao máximo.	92

Fig. 95: Corrente consumida em cada posição do trajecto da Fig. 94.	92

Fig. 96: Corrente consumida ao longo do tempo do trajecto da Fig. 94.	92

Fig. 97: Movimento de flexão de uma perna.	93

Fig. 98: Carga de 2Kg utilizada no topo da perna.	93

Fig. 99: Junta do pé.	94

Fig. 100: Junta do Joelho.	94

Fig. 101: Junta da Anca.	95

Fig. 102: Junta do pé.	95

Fig. 103: Junta do joelho.	96

Fig. 104: Junta da anca.	96

Fig. 105: Junta do pé.	97

Fig. 106: Junta do joelho.	97

Fig. 107: Junta da anca.	98

Fig. 108: Movimento de flexão nas duas pernas.	98

Fig. 109: Conjunto das duas pernas executando um movimento de flexão (sequência superior) e um movimento lateral (sequência inferior) com uma carga de 2.1Kg em completa sincronia de pernas.	99

Fig. 110: Resposta ao polinómio com um controlador PI. Imagens superiores e inferior esquerda: comportamento das três juntas envolvidas no movimento de flexão; imagem inferior direita: comportamento da junta lateral do pé na realização do deslocamento lateral.	99

Fig. 111: Relações de inclusão dos módulos de software de cada Slave.	100

Fig. 112: Algoritmo da RSI de alta prioridade.	101

Fig. 113: Algoritmo da função main no programa principal slave.	104

Fig. 114: Aperto das correias de transmissão: junta lateral (esquerda) e dianteira do pé (restantes).	106

Fig. 115: Localização das principais folgas existentes: juntas lateral (esquerda)e dianteira (central) do pé e chaveta de ligação do joelho (direita).	106

Fig. 116: Exemplo de um extensómetro típico.	112

Fig. 117: Relação entre força imposta e deformação elástica.	112

Fig. 118: Colocação dos sensores na estrutura do pé.	113

Fig. 119: Estrutura completa de um pé.	113

Fig. 120: Peça de acrílico contendo o extensómetro para medição da sua deformação.	113

Fig. 121: Pontos de contacto entre as 2 plataformas do pé.	113

Fig. 122: Visão completa do pé.	114

Fig. 123: Circuito de interface original dos extensómetros.	114

Fig. 124: Circuito de calibração da ponte de Wheatstone.	116

Fig. 125: Relação entre o potenciómetro e a resistência total de calibração.	116

Fig. 126: Ponte de Wheatstone com compensação de interferências externas.	117

Fig. 127: Implementação do circuito de acondicionamento de sinal.	118

Fig. 128: Circuito de acondicionamento de sinal com simetria completa.	119

Fig. 129: Localização dos sensores no pé.	120

Fig. 130: Medição independente de cada sensor.	120

Fig. 131: Medição dos sensores em conjunto.	120

Fig. 132: Relação entre a medição de cada sensor e o peso aplicado (experiência 1)	121

Fig. 133: Valores dos sensores com massas colocadas no centro da base (experiência 2)	122

Fig. 134: Projecção do centro de massa sobre o pé na situação de equilíbrio.	125

Fig. 135: Diagrama de blocos do controlo de equilíbrio de uma perna.	127

Fig. 136: Diagrama representativo de uma perna sob a vista lateral (esquerda) e dianteira (direita).	129

Fig. 137: Variação da inclinação do plano de suporte segundo o eixo yy (esquerda) e o eixo xx (direita).	133

Fig. 138: Variação do declive do plano segundo o eixo xx (controlo proporcional).	134

Fig. 139: Variação do declive do plano segundo o eixo xx - controlo pelo Jacobiano.	134

Fig. 140: Variação do declive do plano segundo o eixo yy (controlo proporcional).	135

Fig. 141: Variação do declive do plano segundo o eixo yy - controlo pelo Jacobiano.	136

Fig. 142: Inclinação do plano segundo os eixos xx e yy.	136

Fig. 143: Variação do declive do plano na diagonal dos eixos xx e yy (controlo proporcional).	137

Fig. 144: Pressão directa sobre os sensores de Força.	137

Fig. 145: Pressão no ponto intermédio entre cada par de sensores (frente, trás, esquerda e direita) - controlo Proporcional.	138

Fig. 146: Pressão no ponto intermédio entre cada par de sensores (frente, trás, esquerda e direita) - controlo pelo Jacobiano.	138

Fig. 147: Pressão de cada sensor de forma isolada (superior esquerdo, superior direito, inferior esquerdo, inferior direito) - controlo Proporcional.	139

Fig. 148: Pressão de cada sensor de forma isolada (superior esquerdo, superior direito, inferior esquerdo, inferior direito) - controlo pelo Jacobiano.	140

Fig. 149: Introdução de perturbações externas na perna (frente, trás, esquerda e direita) - controlo Proporcional.	141

Fig. 150: Introdução de perturbações externas na perna (frente, trás, esquerda e direita) - controlo pelo Jacobiano.	141

Fig. 151: Levantamento do pé no ar - controlo proporcional.	143

Fig. 152: Levantamento do pé no ar - controlo pelo Jacobiano.	143

Fig. 153: Relações de inclusão dos módulos de software de cada Slave.	144

Índice de tabelas

Tabela 1: Características do Hardware.	14

Tabela 2: Campos das mensagens PC→Master via USART	15

Tabela 3: Campos do pacote OpCode nas mensagens PC→Master via USART.	16

Tabela 4: Tipo de controlo a seleccionar no campo PARAM_CONTROLON.	16

Tabela 5: Tipos de mensagens USART (primeiro byte de cada frame).	18

Tabela 6: Configurações gerais do cport.	19

Tabela 7: Configurações de um terminal RS-232 (No caso do R.E.Smith, usar COM1, 115200, N-8-1).	20

Tabela 8: Lista de device drivers da unidade principal.	21

Tabela 9: Configuração do registo TXSTA.	25

Tabela 10: Configuração do registo RCSTA.	25

Tabela 11: Endereços atribuídos às diversas unidades de controlo.	30

Tabela 12: Campos do identificador de um pacote CAN.	31

Tabela 13: Campos do byte Sensor Flags.	32

Tabela 14: Campos do byte Slave Status.	33

Tabela 15: Resultado da filtragem para cada bit.	35

Tabela 16: Configuração dos filtros para redireccionamento de pacotes para os dois buffers de recepção (padrão a3 a2 a1 a0 = endereço do SCU).	36

Tabela 17: Atribuição de prioridades entre cada buffer de transmissão.	36

Tabela 18: Causas de erro na comunicação CAN.	39

Tabela 19: Funções do módulo PIC.	42

Tabela 20: Funções para manipulação dos buffers da USART.	43

Tabela 21: Funções de construção da mensagem de resposta para uso da Rotina de Serviço à Interrupção.	43

Tabela 22: Funções de alto nível para troca de mensagens via CAN.	43

Tabela 23: Device drivers da comunicação CAN.	44

Tabela 24: Funções presentes no módulo GLOBAL.	44

Tabela 25: Rotinas do módulo PIC2 responsáveis por gerir as comunicações CAN.	45

Tabela 26: Funções de alto nível para troca de mensagens via CAN.	46

Tabela 27: Funções presentes no módulo GLOBAL.	46

Tabela 28: Especificações do servo da HITEC HS-805BB.	55

Tabela 29: Binários exigidos na simulação de um passo.	56

Tabela 30: Lista de cargas utilizadas para teste.	59

Tabela 31: Erros em regime estacionário em diferentes posições para uma carga de 1138g.	72

Tabela 32: Funções de acesso externo do módulo PIC2.	100

Tabela 33: Funções internas do módulo PIC2.	101

Tabela 34: Funções globais da biblioteca SERVO.	102

Tabela 35: Rotinas de implementação da compensação chamadas pela função controller.	102

Tabela 36: Funções globais da biblioteca TRAJECTORY.	103

Tabela 37: Funções estáticas invocadas pela função trajectory da biblioteca TRAJECTORY.	103

Tabela 38: Lookup table para a função seno.	105

Tabela 39: Lista de pesos usados no teste dos sensores de força.	119

Tabela 40: Resultados experimentais para cada sensor nas duas experiências.	120

Tabela 41: Parâmetros das regressões lineares traçadas.	121

Tabela 42: Dados do deslocamento dos servos na perna esquerda (perspectiva do robot).	131

Tabela 43: Dados do deslocamento dos servos na perna direita (perspectiva do robot).	131

Tabela 44: Rotinas de implementação da compensação chamadas pela função controller.	144

Tabela 45: Características do pé sensível às forças de reacção.	145

Tabela 46: Características físicas da perna.	145

Tabela 47: Funções do módulo DATA.	145