Desculpa pela tela do google meets, eu infelizmente não vi, só comecei a gravar e troquei pro meu notebook onde mostro tudo. Como ta impossível de gravar nas rasp pelo congestionamento, vou deixar desta maneira.
PS: O trabalho em questão faz uso da BME280, ao rodar por favor utilize a rasp 40
.
cd trabalho-2-2023-2-MtsSrs
make
Feito isso basta executar o binário:
./bin/bin
No arquivo gpio.c
set a variável de controle "calibrated = 1", na linha 25 do arquivo;
int calibrated = 1;
No mesmo arquivo coloque o mock de dado das alturas, como o uso será da rasp40
temos as seguintes alturas. Modifique as linhas 11 ~ 14;
int groundHeight = 2190;
int floorOneHeight = 6443;
int floorTwoHeight = 12326;
int floorThrHeight = 21733;
No arquivo main.c
set a variável de controle "control = 1", na linha 19 do arquivo.
int control = 1;
PS: ESSA É UMA FORMA DE PULAR A CALIBRAGEM POR SER UM PROCESSO MODERADAMENTE DEMORADO, CASO HAJA MUDANÇAS NO ENCODER DA RASP 40 OU QUEIRA FAZER TESTE DE CALIBRAGEM NÃO FAÇA ESSAS MUDANÇAS!
Aqui faço uma experimentação básica mas vou mostrar o caso especial;
- Calibragem
O processo mais lento, chave do meu código, ele está com um PWM de 3, fazendo com que ocorra menos chances de perda de valor.
- Elevador Funcionando
Aqui nesse momento a dash está toda responsiva, tanto a temperatura é alterada a cada 1 segundo, quando dá pra ver a dinâmica do PWM. O elevador sobe de forma suave, sem guinadas.
- Display
Aqui mostra que a lógica do display, ele é atualizado a cada 1 segundo. O motivo pro estado do elevador ser "descendo" é por que o print foi tirado no momento que o elevador está fazendo mini correções em seu direcionamento, logo o display varia nesse momento entre "subindo" e "descendo".
5. O problema que pode ocorrer
Pelo meu pouco conhecimento com o uso das constantes do PID isso acabou se tornando algo comum, o elevador demora muito para chegar dentro de um range pre-estabelecido, o PWM fica sofrendo pequenas alterações e não ganha do atrito do motor. Infelizmente não fui capaz de corrigir este bug.
A minha main é baseada nesses comandos que o usuário pode entrar usando seus respectivos números:
1 - Request Encoder Value
2 - Send PWM control signal
3 - Send room temperature
4 - Read the registers
5 - Write in the registers
6 - Exit
7 - Elevator control
8 - Calibrate
9 - Floor command
Comando que apenas faz um request no encoder, o seu resultado só será visto em Live. Basta chamar com o número "1";
Envia um PWM de 50 para dash, é apenas um teste fixo para ver se a dash recebe. Basta chamar com o número "2";
Recupera a temperatura via I2C pelo BME280 e envia para dash. Basta chamar com o número "3";
Leitura do registrador, basta passar o endereço do registrador desejado em Hexadecimal no formato (OxOO ~ Ox0A) e a quantidade de bytes em Hexadecimal (0x01 ~ 0x0B), o retorno é dado em live.
Escrita do registrador, basta passar o endereço do registrador desejado em Hexadecimal no formato (0x00 ~ 0x0A) e a quantidade de bytes em Hexadecimal (0x01 ~ 0x0B) e qual valor escrever (0x00 ou 0x01), o retorno é dado em live.
Apenas termina o projeto
Controle do elevador:
1 - Para subir
2 - Para descer
0 - Para parar
Logo em seguida coloque o PWM: Range (0 - 100)
Botão mais importante, veja se o elevador está parado no encoder zero e chame a função de calibrar;
Passe um inteiro para qualquer valor de encoder aceitável no projeto (0 - 25500) o elevador irá até lá.
- Como o sensor pode ser pego na borda de baixo e no meu código eu dou uma faixa de 5 und. tanto para cima quanto para baixo, existe o caso infeliz onde o encoder está na posição, exemplo andar 1 = 5000 ~ 5050, se o encoder captar o número exato de 5000 o meu elevador possui uma chance de parar no 4995. Isso foi uma abordagem de minimizar o problema que eu nomeei de "orbita" onde o PID passava um PWM que não ganha do atrito inicial do motor e ficava parado ou subindo e descendo em torno do andar.
- A qualidade tá boa, o código ta modularizado mesmo com menor granularidade na parte das GPIO.C.
- O consumo de CPU está baixo, na casa dos 0.7% até 1.4%.
- Pelo fato de eu não saber mexer muito com as constantes do PID acontecem casos que o PWM não está dimensionado para atender ao objetivo do andar, ocorrendo a famosa "orbita" em torno do andar onde o elevador fica muito próximo do objetivo mas não freia.
ITEM | DETALHE | Feito |
---|---|---|
Controlador PID | Correta implementação do controlador PID (motor PWM), incluindo a leitura do encoder e acionamento da direção dos motores, correto posicionamento dos elevadores nos andares (ao parar no andar, o sinal do sensor do andar deve acender). | ✔️ |
Menu de controle | Correta leitura e acionamento de eventos baseados nos comandos dos usuários por meio dos botões no dashboard. | ✔️ |
Leitura da Temperatura Ambiente | Leitura dos valores de Temperatura Ambiente (Sensor BMP280). | ✔️ |
Comunicação UART | Leitura do encoder, botões e envio de temperatura e do sinal de controle através da comunicação MODBUS-UART. | ✔️ |
Mostrador no LCD | Apresentação do funcionamento do elecador menu no LCD incluindo o estado atual e a temperatura ambiente. | ✔️ |
Qualidade do Código | Utilização de boas práticas como o uso de bons nomes, modularização e organização em geral. | ✔️ |
README com Experimento | Documentação README com instruçoes de compilação, de uso e relatório do experimento com o gráfico e vídeo. | ✔️ |
Pontuação Extra | Qualidade e usabilidade acima da média. | ✔️ |