|
|
Linha 100: |
Linha 100: |
| [[Arquivo:EV3_Motor_UML.jpg|800px|thumb|center|Diagrama de Classe - Motor]] | | [[Arquivo:EV3_Motor_UML.jpg|800px|thumb|center|Diagrama de Classe - Motor]] |
| [[Arquivo:EV3_Sensor_UML.jpg|800px|thumb|center|Diagrama de Classe - Sensor]] | | [[Arquivo:EV3_Sensor_UML.jpg|800px|thumb|center|Diagrama de Classe - Sensor]] |
− | [[Arquivo:ClassesSR.jpg|1600px|thumb|center|Diagrama de Classe - SR]] | + | [[Arquivo:PJI2_Diagrama_0309.jpg|800|thumb|center|Diagrama de Classe - SR]] |
| {{collapse bottom | Classes}} | | {{collapse bottom | Classes}} |
| | | |
Edição das 17h48min de 1 de setembro de 2018
Projeto Integrador II
Alunos: João Leonardo Martins (joao.lm@aluno.ifsc.edu.br) e Vinícius Luz (vinicius.ls@aluno.ifsc.edu.br)
Objetivo Geral
Implantar tradicional caça de robôs para buscar determinados itens através de coordenadas.
Página da Disciplina
PJI2018-2
Diagramas
Caso de uso e descrição
|
Nome: Autentica robô
Identificador: CSU01;
Sumário: Após ter sido devidamente cadastrado, o robô é acionado pelo SS para que sua autenticação seja efetivada (isso deve ocorrer em todas as vezes que o robô é ligado ou que um novo jogo seja iniciado), isso se dá através de uma solicitação e posterior resposta do robô de qual é o endereço MAC de sua interface de rede Bluetooth;
Ator primário: Sistema Supervisório;
Precondições:
- Robô já ter sido cadastrado;
Fluxo principal:
- SS solicita o ID do robô;
- Robô responde com o MAC Address de sua interface de rede Bluetooth;
Fluxos de exceção:
- MAC address respondido não informado (problemas na obtenção do mesmo) ou endereço não cadastrado: autenticação negada e o robô não pode participar do jogo;
Nome: Recebe dados
Identificador: CSU02;
Sumário: Com cadastro e autenticação previamente concluídas, o SR tem condições de receber os dados do jogo do SS: coordenadas inicial e das caças, modo de operação, etc.;
Ator primário: Sistema Supervisório;
Precondições:
- Robô já ter sido cadastrado;
- O robô já ter se autenticado;
Fluxo principal:
- SS envia os dados para início do jogo;
- SR processa os dados e define sua posição inicial e mapeia as caças do jogo;
Nome: Modo de operação automático
Identificador: CSU03;
Sumário: Uma vez definido como operação automática, o algoritmo de busca das caças anteriormente declaradas através de coordenadas é executado, tendo como fonte de informação os sensores do robô - luminosidade (cor) e ultrassônico(distância), além de contar com os motores para deslocamento;
Atores primários: Sensores, Motores;
Precondições:
- Ter recebido os dados com sucesso;
- Posição inicial correta (0,0 ou 20,20);
Fluxo principal:
- Acionar sensores;
- Acionar motores;
- Ao se deparar com uma caça, enviar informação ao SS;
Fluxo de exceção:
- Obstáculo próximo (mudar trajetória);
- Se pausa/fim de jogo, voltar ao ponto inicial;
- Se recebe falha de validação da caça;
Nome: Modo de operação manual
Identificador: CSU04;
Sumário: Neste modo, apenas o sensor ultrassônico é habilitado de modo a evitar colisões. O controle do robô e envio das informações de caças não ficam a cargo do SR;
Ator primário: Sistema Supervisório, Motores;
Precondições:
- Posição inicial correta (0,0 ou 20,20);
Fluxo principal:
- Executar código para evitar colisões;
- Obter informações de deslocamento do SS e acionar os motores;
Fluxo de exceção:
- Alterar rota devido à distância do obstáculo;
|
Classes
|
Diagrama de Classe - Motor
Diagrama de Classe - Sensor
|
Requisitos
Funcionais
|
- RF01 O sistema deve permitir criação e gerência de cadastro de um robô.
- [SA] - O que deve ter neste cadastro? Como deve ser feito o cadastro, web?
- Sugestão: usuário, senha, nome. Cadastro via Web.
- RF02 O sistema de deve manter um histórico das partidas realizadas.
- [SA] - Qual tamanho do histórico?
- Sugestão: O histórico deve manter o resultado das últimas com o nome dos robôs participantes.
- Sugestão: 100 últimas partidas.
- RF03 O sistema deve ser capaz de fazer a autenticação dos robôs cadastrados.
- [SA] - Em que momento é feita a autenticação?
- Sugestão: a autenticação será ao iniciar uma partida. Antes de iniciar, solicitar partida.
- RF04 Os robôs devem ser capazes de operar nos modos manual e autônomo.
- [SR] - Existe algum requisito sobre o modo manual? Por onde o robo deve ser guiado?
- Sugestão: interface onde se possa utilizar as setas direcionais do teclado.
- RF05 O sistema deve validar e contabilizar as caças já encontradas pelo robô.
- [SA] - Afinal, o que será a caça? Como validar?
- RF06 O sistema deve dar início a partida, sortear os locais das caças e informá-los aos robôs.
- [SA] - Sortear os locais e informar, ou fazer tudo junto? Isso pode mudar a estratégia do robô. Onde será o início?
- Sugestão: primeiro sortear a informar os locais das caças. Depois iniciar.
- Sugestão: início no canto do tabuleiro.
- RF07 O sistema deve prover uma interface de monitoramento para o robô em modo autônomo.
- [SR] - Há algum requisito para a interface de monitoramento?
- Sugestao: o sistema deve conter o número de caças encontradas e o trajeto realizado. Poderá ser feito via mensagens na tela.
- RF08 O sistema deve prover uma interface de controle e monitoramento para o robôs em modo manual.
- [SR] - Existe algum requisito sobre o modo manual? Por onde o robo deve ser guiado?
- Sugestão: interface onde se possa utilizar as setas direcionais do teclado.
- RF09 O sistema deve permitir que, quando em modo autônomo, o robô execute os movimentos programados a partir do algoritmo implementado.
- [SR] - OK
- RF010 O sistema deve permitir pausa e reset da partida.
- [SA] - No reset, os robôs devem voltar ao início ou fazemos manualmente?
- Sugestão: Fazer manualmente.
- RF011 O sistema deve permitir que os resultados do jogo sejam vistos pelos espectadores em tempo real.
- [SA] - Há algum requisito para esta visualização?
- Sugestão: Interface web simples, com o placar do jogo.
- RF012 O sistema não deve permitir que os robôs se choquem.
- [SR] - OK
- RF013 O sistema deve declarar um vencedor assim que todas as caças forem encontradas.
- [SA] - OK, e os robôs devem parar as suas buscas.
- RF014 Antes de iniciar a partida, o sistema deve verificar a posição atual dos robôs.
- [SA] - Este requisito será necessário caso o ponto de partida seja sempre o mesmo (RF006).
- RF015 Após capturar uma caça, o robô deve avisar o SS, que por sua vez, deve avisar o SA para validação da caça. Esta validação deve retornar ::ao SR, confirmando-a ou não.
|
Não funcionais
|
- RNF01 A interface do sistema de comunicação com o usuário deve ser intuitiva.
- [SA] - Como será essa interface, afinal? Web?
- RNF02 O tabuleiro será composto por linhas pretas e todos com cor.
- [SR] - Como assim? Não entendi.
- Pelo que entendi, as linhas pretas (algo como uma fita isolante), serão utilizadas para limitar os quadrados coloridos, que terão diversas ::cores e somente uma ou outra será considerada caça.
- RNF03 O tabuleiro terá as dimensões definidas (2m x 2m).
- OK
- RNF04 O tabuleiro será composto por 100 quadrados de dimensões: 20cm x 20cm.
- OK
- RNF05 O tabuleiro será limitado por uma borda vermelha.
- OK
- RNF06 O placar mostrado aos usuários deve ser de fácil identificação.
- OK, web?
- RNF07 O robô deve ter uma cor para identificação.
- Cada robô possui uma cor pré-definida ou o SA define no momento da partida?
- O robô deve ter uma etiqueta de identificação.
|
Diário das Aulas
30/7/18
Aula 1
|
- Definição do grupo;
- Aula expositiva;
- Organização das tarefas através da ferramenta Trello;
|
6/8/18
Aula 2
|
- Efetuada a leitura da documentação do EV3-Python: apesar do bot já possuir o linux instalado, estudamos como seria a implementação do mesmo;
- Início da montagem do robô: encontramos algumas dificuldades pois o equipamento estava completamente desmontado, com isso, até entendermos que a montagem seria basicamente livre, sofremos um pouco na idealização do EV3;
- Alinhamento sobre comunicação com o robô: ficou definido que vamos utilizar um adaptador wi-fi no mesmo, sendo assim, um terceiro equipamento se fez necessário, uma vez que a o EV3 não conecta na rede do Instituto;
- Alguns exemplos de implementação foram observados na documentação do EV3, conforme pode ser obtido através destes links: Exemplos Motor e Exemplos Sensor
- Diagrama Geral do Projeto:
Diagrama Geral do Projeto
Classe Motor
|
Diagrama de Classe - Motor
|
Classe Sensor
|
Diagrama de Classe - Sensor
|
Requisitos Funcionais
|
- RF01 O sistema deve permitir criação e gerência de cadastro de um robô.
- [SA] - O que deve ter neste cadastro? Como deve ser feito o cadastro, web?
- Sugestão: usuário, senha, nome. Cadastro via Web.
- RF02 O sistema de deve manter um histórico das partidas realizadas.
- [SA] - Qual tamanho do histórico?
- Sugestão: O histórico deve manter o resultado das últimas com o nome dos robôs participantes.
- Sugestão: 100 últimas partidas.
- RF03 O sistema deve ser capaz de fazer a autenticação dos robôs cadastrados.
- [SA] - Em que momento é feita a autenticação?
- Sugestão: a autenticação será ao iniciar uma partida. Antes de iniciar, solicitar partida.
- RF04 Os robôs devem ser capazes de operar nos modos manual e autônomo.
- [SR] - Existe algum requisito sobre o modo manual? Por onde o robo deve ser guiado?
- Sugestão: interface onde se possa utilizar as setas direcionais do teclado.
- RF05 O sistema deve validar e contabilizar as caças já encontradas pelo robô.
- [SA] - Afinal, o que será a caça? Como validar?
- RF06 O sistema deve dar início a partida, sortear os locais das caças e informá-los aos robôs.
- [SA] - Sortear os locais e informar, ou fazer tudo junto? Isso pode mudar a estratégia do robô. Onde será o início?
- Sugestão: primeiro sortear a informar os locais das caças. Depois iniciar.
- Sugestão: início no canto do tabuleiro.
- RF07 O sistema deve prover uma interface de monitoramento para o robô em modo autônomo.
- [SR] - Há algum requisito para a interface de monitoramento?
- Sugestao: o sistema deve conter o número de caças encontradas e o trajeto realizado. Poderá ser feito via mensagens na tela.
- RF08 O sistema deve prover uma interface de controle e monitoramento para o robôs em modo manual.
- [SR] - Existe algum requisito sobre o modo manual? Por onde o robo deve ser guiado?
- Sugestão: interface onde se possa utilizar as setas direcionais do teclado.
- RF09 O sistema deve permitir que, quando em modo autônomo, o robô execute os movimentos programados a partir do algoritmo implementado.
- [SR] - OK
- RF010 O sistema deve permitir pausa e reset da partida.
- [SA] - No reset, os robôs devem voltar ao início ou fazemos manualmente?
- Sugestão: Fazer manualmente.
- RF011 O sistema deve permitir que os resultados do jogo sejam vistos pelos espectadores em tempo real.
- [SA] - Há algum requisito para esta visualização?
- Sugestão: Interface web simples, com o placar do jogo.
- RF012 O sistema não deve permitir que os robôs se choquem.
- [SR] - OK
- RF013 O sistema deve declarar um vencedor assim que todas as caças forem encontradas.
- [SA] - OK, e os robôs devem parar as suas buscas.
- RF014 Antes de iniciar a partida, o sistema deve verificar a posição atual dos robôs.
- [SA] - Este requisito será necessário caso o ponto de partida seja sempre o mesmo (RF006).
- RF015 Após capturar uma caça, o robô deve avisar o SS, que por sua vez, deve avisar o SA para validação da caça. Esta validação deve retornar ::ao SR, confirmando-a ou não.
|
Requisitos Não Funcionais
|
- RNF01 A interface do sistema de comunicação com o usuário deve ser intuitiva.
- [SA] - Como será essa interface, afinal? Web?
- RNF02 O tabuleiro será composto por linhas pretas e todos com cor.
- [SR] - Como assim? Não entendi.
- Pelo que entendi, as linhas pretas (algo como uma fita isolante), serão utilizadas para limitar os quadrados coloridos, que terão diversas ::cores e somente uma ou outra será considerada caça.
- RNF03 O tabuleiro terá as dimensões definidas (2m x 2m).
- OK
- RNF04 O tabuleiro será composto por 100 quadrados de dimensões: 20cm x 20cm.
- OK
- RNF05 O tabuleiro será limitado por uma borda vermelha.
- OK
- RNF06 O placar mostrado aos usuários deve ser de fácil identificação.
- OK, web?
- RNF07 O robô deve ter uma cor para identificação.
- Cada robô possui uma cor pré-definida ou o SA define no momento da partida?
- O robô deve ter uma etiqueta de identificação.
|
Papéis dos Atores
|
Ator |
Papel
|
Usuário |
Iniciar partida em modo autônomo
|
Usuário |
Iniciar partida em modo manual
|
Usuário |
Controlar robô em busca de caças no modo manual
|
Usuário |
Monitorar robô em modo autônomo
|
Usuário |
Posicionar o robô para o início da partida
|
SS |
Informar ao robô onde estão as caças
|
SS |
Informar ao robô se a caça encontrada foi validada
|
SS |
Informar ao robô sobre o início da partida
|
SS |
Informar ao robô sobre o término da partida
|
SS |
Informar ao robô se a autenticação foi validada
|
SS |
Informar ao robô sobre pausas na partida
|
Onde: SS - sistema supervisório; Usuário - jogador
|
|
Casos de Uso
|
- Construção diagramasr.png de diagrama UML conforme bibliografia:
Imagem 1: diagramas de casos de uso para o SR
|
|
13/8/18
Aula 3
|
Levantamentos sobre discussões em sala
Alteração da definição do diagrama geral do projeto.
Diagrama Geral do Projeto
|
|
Pontos levantados a respeito dos requisitos de projeto.
Considerações sobre requisitos do projeto
|
Sistema Robô [SR]
- Deve ter um ID para validação e será baseado no MAC do Bluetooth do robô;
- A posição inicial sempre será (0,0) ou (20,20);
- A cor do robô será definida no momento do cadastro no SA.
Sistema Supervisório [SS]
- Modo manual: movimentações para direita, esquerda, cima e baixo;
- Não há requisitos para a interface com usuário, poderá ser web, desktop, etc;
- A caça será uma coordenada, que varia de (0,0) a (20,20);
- No modo automático, o monitoramento do robô deverá exibir informações sobre as caças encontradas e a sequência de movimentações;
- Para reinício da partida, o jogador deverá reposicionar manualmente o robô nas posições iniciais;
- SS deverá informar ao SA que está pronto para iniciar uma partida;
- O robô deverá parar enquanto aguarda a validação da caça.
Sistema Auditoria [SA]
- A validação da caça deverá ser manual;
- O SA deverá informar o SS do início da partida, já com a localização das caças.
|
Códigos executados para testes no robô.
Código teste motor
|
- !/usr/bin/env python3
from ev3dev.ev3 import *
import time
m_l = Motor(OUTPUT_B)#left motor
m_r = Motor(OUTPUT_C) #right motor
- run forward for tree seconds:
m_l.run_timed(time_sp=3000, speed_sp=500)
m_r.run_timed(time_sp=3000, speed_sp=500)
time.sleep(2)
- run "forever"
for x in range(0,500):
x=x+1
m_l.run_forever(speed_sp=50)
m_r.run_forever(speed_sp=50)
if x ==500:
m_l.stop(stop_action='brake')
m_r.stop(stop_action='brake')
- turn back
m_l.run_timed(time_sp=3000, speed_sp=-500)
m_r.run_timed(time_sp=3000, speed_sp=-500)
time.sleep(2)
for y in range(0,500):
y=y+1
m_l.run_forever(speed_sp=-50)
m_r.run_forever(speed_sp=-50)
if y ==500:
m_l.stop(stop_action='brake')
m_r.stop(stop_action='brake')
- rotate
m_l.run_timed(time_sp=3000, speed_sp=500)
time.sleep(3)
m_r.run_timed(time_sp=3000, speed_sp=500)
</syntaxhighlight>
|
Código teste luminosidade
|
- !/usr/bin/env python3
from ev3dev.ev3 import *
from time import sleep
- Connect EV3 color sensor and check connected.
cl = ColorSensor()
assert cl.connected, "Connect a color sensor to any sensor port"
- Put the color sensor into COL-REFLECT mode
- to measure reflected light intensity.
- In this mode the sensor will return a value between 0 and 100
cl.mode='COL-REFLECT'
while True:
print(cl.value())
sleep(1)
</syntaxhighlight>
|
Código teste distância
|
- !/usr/bin/env python3
from ev3dev.ev3 import *
import time
m_l = Motor(OUTPUT_A)#left motor
m_r = Motor(OUTPUT_D) #right motor
us = UltrasonicSensor()
us.mode='US-DIST-CM'
units = us.units
distance = us.value()/10
print(str(distance) + " " + units)
while True:
distance = us.value()/10
print(str(distance) + " " + units)
time.sleep(1)
</syntaxhighlight>
|
Ajustes no Diagrama UC do SR
Diagrama UC do SR - descrição
|
Nome: Autentica robô
Identificador: CSU01;
Sumário: Após ter sido devidamente cadastrado, o robô é acionado pelo SS para que sua autenticação seja efetivada (isso deve ocorrer em todas as vezes que o robô é ligado ou que um novo jogo seja iniciado), isso se dá através de uma solicitação e posterior resposta do robô de qual é o endereço MAC de sua interface de rede Bluetooth;
Ator primário: Sistema Supervisório;
Precondições:
- Robô já ter sido cadastrado;
Fluxo principal:
- SS solicita o ID do robô;
- Robô responde com o MAC Address de sua interface de rede Bluetooth;
Fluxos de exceção:
- MAC address respondido não informado (problemas na obtenção do mesmo) ou endereço não cadastrado: autenticação negada e o robô não pode participar do jogo;
Nome: Recebe dados
Identificador: CSU02;
Sumário: Com cadastro e autenticação previamente concluídas, o SR tem condições de receber os dados do jogo do SS: coordenadas inicial e das caças, modo de operação, etc.;
Ator primário: Sistema Supervisório;
Precondições:
- Robô já ter sido cadastrado;
- O robô já ter se autenticado;
Fluxo principal:
- SS envia os dados para início do jogo;
- SR processa os dados e define sua posição inicial e mapeia as caças do jogo;
Nome: Modo de operação automático
Identificador: CSU03;
Sumário: Uma vez definido como operação automática, o algoritmo de busca das caças anteriormente declaradas através de coordenadas é executado, tendo como fonte de informação os sensores do robô - luminosidade (cor) e ultrassônico(distância), além de contar com os motores para deslocamento;
Atores primários: Sensores, Motores;
Precondições:
- Ter recebido os dados com sucesso;
- Posição inicial correta (0,0 ou 20,20);
Fluxo principal:
- Acionar sensores;
- Acionar motores;
- Ao se deparar com uma caça, enviar informação ao SS;
Fluxo de exceção:
- Obstáculo próximo (mudar trajetória);
- Se pausa/fim de jogo, voltar ao ponto inicial;
- Se recebe falha de validação da caça;
Nome: Modo de operação manual
Identificador: CSU04;
Sumário: Neste modo, apenas o sensor ultrassônico é habilitado de modo a evitar colisões. O controle do robô e envio das informações de caças não ficam a cargo do SR;
Ator primário: Sistema Supervisório, Motores;
Precondições:
- Posição inicial correta (0,0 ou 20,20);
Fluxo principal:
- Executar código para evitar colisões;
- Obter informações de deslocamento do SS e acionar os motores;
Fluxo de exceção:
- Alterar rota devido à distância do obstáculo;
|
|
20/8/18
Aula 4
|
Diagrama de classe SR
|
|
|
27/8/18
{{Collapse top | Aula 5
Discussão sobre o diagrama de classes - sistema robô:
- Ajustar diagrama de classes SR:
- Detalhar classe ComunicaSS (basicamente a classe existente refere-se à classe Socket), onde atributos da mesma seriam: "- caças atualizadas", "- manual", "- automático", etc.;
- Estabelecer relação entre as classes;
- Implementar classe mover;
- Elaborar um diagrama de sequência para a classe SR;
- Tabela mapeando todos os dados trocados entre o SS e o SR e vice-versa;
{{Collapse top| Tabela SS vs SR
Origem |
Destino |
Mensagem
|
SS |
SR |
Get ID
|
SS |
SR |
Success
|
SS |
SR |
Fail
|
SS |
SR |
Send coord.
|
SS |
SR |
Pause
|
SS |
SR |
End of game
|
SS |
SR |
Turn on righ
|
SS |
SR |
Turn of left
|
SS |
SR |
Emergency stop
|
SS |
SR |
Refresh list
|
SS |
SR |
Emergency stop
|
SR |
SS |
ACK
|
SR |
SS |
Send MAC address
|
SR |
SR |
Cood. reached
|
SR |
SR |
|
SR |
SR |
|
SR |
SS |
|
SR |
SR |
|
SR |
SR |
|
SR |
SR |
|
SR |
SR |
|
|}
|}
Bibliografia
- BEZERRA, Eduardo. Princípios de análise e projetos de sistemas com UML, 2002. Rio de Janeiro. Editora Campus LTDA.