Diagrama de caso de uso

No diagrama de caso de uso definiu-se apenas um ator que é o bloco SH. Os dois casos de uso definidos no diagrama são: ler sensor e comandar atuadores, conforme ilustrado na Figura 3.6.

Sub-sistema drivers/sensores

Ler sensor

Comandar atuadores Bloco SH

Figura 3.6: Diagrama de casos de uso Descrição dos casos de usos:

1. Ler sensor - a leitura dos sensores deve ser realizada de modo que as amostras apresentem ruídos mínimos. Este caso de uso deve ser executado considerando a frequência na qual o sen- sor adquire as amostras. Para o sensor MPU6050, frequências de leituras maiores que 200 Hz (i.e., 5 ms) podem comprometer os dados obtidos. Portanto, o período mínimo considerado para se realizar uma leitura é de 5 ms.

2. Comandar atuadores - o comando dos atuadores deve ser realizado visando a correção da po- sição da gimbal, utilizando a informação computada a partir dos dados dos sensores. O sinal de controle gerado é um sinal PWM conectado aos drivers responsáveis pelo acionamento dos motores brushless. Este caso de uso deve ser executado considerando a frequência de 1 KHz (i.e., 1 ms).

Os drivers apresentam delay da ordem de nanosegundos (i.e., 900 ns) em suas atuações de comando liga-desliga do PWM conforme especificações técnicas do driver.

As justificativas para as escolhas das frequências mencionadas anteriormente (leitura dos sensores e comando dos atuadores) encontram-se detalhadas no Capítulo 4.

3.3.2 Diagrama de pacotes

O projeto pode ser dividido em pacotes que reúnem agrupamentos lógicos das funcionali- dades do sistema. Assim, o projeto encontra-se dividido em quatro pacotes principais: KL25Z, Controle, Gimbal e Sensor conforme ilustrado na Figura 3.7. Os pacotes são definidos segundo os componentes físicos e a própria implementação do software embarcado e estão descritos a seguir:

KL25Z Controle

Gimbal Sensor

«Usage»

«Usage»

«Usage»

Figura 3.7: Diagrama de pacotes

∘ KL25Z - contém todos os arquivos disponibilizados pelo KL25Z como por exemplo os ar- quivos que contêm as funções de interrupção;

∘ Controle - contém os arquivos desenvolvidos relacionados ao controle onde as funções de comandar o atuador se encontram;

∘ Gimbal - contém o arquivo principal (main.c) desenvolvido onde a maioria das funções são chamadas; e

∘ Sensor - contém os arquivos desenvolvidos relacionados ao sensor MPU6050 onde todos os comandos como calibrar o sensor e ler seus dados se encontram.

3.3.3 Diagrama de definição de blocos

O diagrama de definição de blocos modela a estrutura do sistema em componentes/blocos juntamente com suas propriedades, operações e relacionamentos. Para a modelagem do diagrama de definição de blocos considera-se primeiramente as funcionalidades dos diagramas de caso de uso e pacotes definidos anteriormente. O diagrama de definição de blocos encontra-se ilustrado na Figura 3.8. Os blocos mencionados nesta subseção são componentes de software, diferentemente dos blocos da Seção 4.2, que define os blocos do sistema.

Os blocos FRDMKL25Z, Gimbal, Events, MPU6050 e Control ilustrados na Figura 3.8 são descritos a seguir.

1. Bloco de software FRDMKL25Z - contém todas as definições da plataforma KL25Z e do kit de desenvolvimento de software Kinetis Software Development Kit (KSDK);

2. Bloco de software Gimbal - bloco principal que agrega todos os outros blocos, responsável por gerenciar as chamadas das operações de aquisição de dados e controle;

3. Bloco de software Events - responsável por gerenciar as interrupções necessárias para realizar o controle cujo ciclo periódico deve ser respeitado;

4. Bloco do software Control - responsável por comandar os atuadores. Assim, a cada período pré-definido as operações desse bloco são executadas para manter a gimbal estável, respei- tando a frequência máxima de leitura dos dados dos sensores; e

5. Bloco de software MPU6050: responsável pela leitura dos dados não tratados dos sensores bem como a computação desses dados. O sensor MPU6050 possui uma biblioteca de código aberto disponível, a qual possibilita realizar alterações de acordo com a aplicação a ser im- plementada. As principais operações desse bloco de software são: comunicação com o sensor por meio do protocolo I2_{C, inicialização do sensor, escolha do modo de operação, calibração}

do sensor e obtenção dos ângulos de posição da gimbal a partir dos dados do giroscópio e acelerômetro. Além disso, nesse bloco encontra-se implementada a fusão de dados visando maximizar precisão dos resultados.

FRDMKL25Z«File» flagReadyPWM:unsigned int=FALSE count:int PIT IRQHandler():void TPM0 IRQHandler():void I2C1 IRQHandler():void «Subsystem»

KLZ25Z::events Controle::control«Subsystem» ref:float=0 roll:float pitch:float rollObs:float pitchObs:float coef:float coefy:float Kp:float=1,5 Ki:float=600 Kd:float=0 Kpy:float=4,5 Kiy:float=1130 Kdy:float=0 uCnv1:int uCnv2:int uCnv3:int uCnv4:int uCnv5:int uCnv6:int tpmBase:void* erroPID:float=0 erroPIDy:float=0 startPWM():void setPWM():void observador():void «Subsystem» Sensor::MPU6050 dataAcc:int dataGyro:int ax:float ay:float az:float gx:float gy:float gz:float accelBias:float gyroBias:float aRes:float gRes:float dtSensor:float=5 roll:float pitch:float init MPU():void whoAmI MPU():void getGyroRawX MPU():void calibrate MPU():void reset MPU():void calcPitchRoll MPU():void fastArcTan MPU():float «Subsystem» Gimbal::gimbal flagReadyPWM:unsigned int count: int main() «Usage» «Usage» «Usage» «Usage»

Figura 3.8: Diagrama de definição de blocos

3.3.4 Diagrama de sequência

O diagrama de sequência evidencia a sequência temporal de mensagens comunicadas entre os elementos envolvidos nesse diagrama.

Utilizou-se um diagrama de sequência com o foco principal no loop de controle dos moto- res ilustrado na Figura 3.9. Primeiramente é necessário inicializar o sistema formado pela plata- forma KL25Z por meio da função init(). Em seguida, se estabelece uma comunicação com o

MPU6050 com a operação whoAmI_MPU() por meio do protocolo I2_{C. Uma vez estabelecida a}

comunicação é preciso calibrar o sensor (calibrate_MPU, incializá-lo com a calibração esta- belecida (init_MPU) e obter os primeiros dados (calcPitchRoll_MPU) e os coeficientes do observador (observador()) para entrar no loop de controle. A cada 1 ms ocorre uma interrup- ção de hardware para o sistema atuar nos motores por meio dos sinais de PWM sendo que os duty cycles são definidos pela operação setPWM(). Finalmente, quando atingir um intervalo de tempo igual a 5 ms, calcula-se novamente os dados do sensor e em seguida o observador, reiniciando-se o ciclo de controle.

Gimbal:gimbal KLZ25Z:events Sensor:MPU6050 Controle:control

init() whoAmI MPU() accelBias, gyroBias calibrate MPU() init MPU() calcPitchRoll MPU() roll, pitch observador() coef, coefy PIT IRQHandler() <100𝜇s> setPWM() <2135𝜇s> calcPitchRoll MPU() roll, pitch observador()

[Periódico - 1 ms (Controle PID)]

[Periódico - 5 ms (Aquisição/Computação de Dados)]

<10𝜇s> coef, coefy

3.3.5 Máquina de estados

O diagrama de máquina de estados tem como objetivo descrever o comportamento do sistema por meio de seus estados e transições.

A Figura 3.10 ilustra a máquina de estados do sitema formado pelo bloco SH, drivers e sensores para controle da gimbal. Assim, três estados (Inicializa, SetPWM e Leitura) são definidos e representam respectivamente a inicialização do sistema, o comando dos atuadores e a leitura dos sensores. A transição entre os estados ocorre por meio dos eventos flagReady, flag1 mse flag5 ms. Essas transições são definidas de acordo com as interrupções do módulo periodic interrupt timer - PIT (PIT_IRQHandler) do microcontrolador. Ocorrem interrupções no estado de leitura uma vez que é necessário comandar os atuadores em um intervalo de tempo menor que 5 ms, tempo necessário para amostragem dos sensores.

Inicializa SetPWM Leitura

flag1ms

flag1ms

flag5ms flagReady

Figura 3.10: Máquina de estados