Grupo3-PJI2-2018-2

De MediaWiki do Campus São José
Revisão de 17h48min de 1 de setembro de 2018 por Vinicius.ls (discussão | contribs) (→‎Diagramas)
Ir para navegação Ir para pesquisar

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

Geral do projeto
Diagrama Geral do Projeto
Caso de uso e descrição
Diagrama Geral do Projeto2


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:

  1. Robô já ter sido cadastrado;

Fluxo principal:

  1. SS solicita o ID do robô;
  2. Robô responde com o MAC Address de sua interface de rede Bluetooth;

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado;
  2. O robô já ter se autenticado;

Fluxo principal:

  1. SS envia os dados para início do jogo;
  2. 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:

  1. Ter recebido os dados com sucesso;
  2. Posição inicial correta (0,0 ou 20,20);

Fluxo principal:

  1. Acionar sensores;
  2. Acionar motores;
  3. Ao se deparar com uma caça, enviar informação ao SS;

Fluxo de exceção:

  1. Obstáculo próximo (mudar trajetória);
  2. Se pausa/fim de jogo, voltar ao ponto inicial;
  3. 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:

  1. Posição inicial correta (0,0 ou 20,20);

Fluxo principal:

  1. Executar código para evitar colisões;
  2. Obter informações de deslocamento do SS e acionar os motores;

Fluxo de exceção:

  1. Alterar rota devido à distância do obstáculo;
Classes
Diagrama de Classe - Motor
Diagrama de Classe - Sensor
Diagrama de Classe - SR

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
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

  1. !/usr/bin/env python3

from ev3dev.ev3 import * import time

m_l = Motor(OUTPUT_B)#left motor m_r = Motor(OUTPUT_C) #right motor

  1. 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)

  1. 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')

  1. 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')
  1. 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

  1. !/usr/bin/env python3

from ev3dev.ev3 import * from time import sleep

  1. Connect EV3 color sensor and check connected.

cl = ColorSensor() assert cl.connected, "Connect a color sensor to any sensor port"

  1. Put the color sensor into COL-REFLECT mode
  2. to measure reflected light intensity.
  3. 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

  1. !/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
Diagrama Geral do Projeto2
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:

  1. Robô já ter sido cadastrado;

Fluxo principal:

  1. SS solicita o ID do robô;
  2. Robô responde com o MAC Address de sua interface de rede Bluetooth;

Fluxos de exceção:

  1. 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:

  1. Robô já ter sido cadastrado;
  2. O robô já ter se autenticado;

Fluxo principal:

  1. SS envia os dados para início do jogo;
  2. 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:

  1. Ter recebido os dados com sucesso;
  2. Posição inicial correta (0,0 ou 20,20);

Fluxo principal:

  1. Acionar sensores;
  2. Acionar motores;
  3. Ao se deparar com uma caça, enviar informação ao SS;

Fluxo de exceção:

  1. Obstáculo próximo (mudar trajetória);
  2. Se pausa/fim de jogo, voltar ao ponto inicial;
  3. 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:

  1. Posição inicial correta (0,0 ou 20,20);

Fluxo principal:

  1. Executar código para evitar colisões;
  2. Obter informações de deslocamento do SS e acionar os motores;

Fluxo de exceção:

  1. Alterar rota devido à distância do obstáculo;
20/8/18
Aula 4
Diagrama de classe SR

ClassesSR.jpg

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.
Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=Grupo3-PJI2-2018-2&oldid=149592”