Documento de Requisitos de Sistema

Documento de Requisitos de Sistema

Requisitos do Sistema VSSS-ERUS

G

V

,

L

L. T

,

L

B. B

,

R

R. R

Resumo

Este relatório de atividade contém os requisitos levantados para o sistema do Very Small Size Soccer da ERUS. Esse sistema foi pensado de acordo com os padrões e regras estabelecidos pelo Edital da categoria pela LARC, porém o sistema pode ser utilizado em qualquer competição que apresente a categoria, tanto por simulação quanto para a competição com robôs reais.

A proposta de desenvolvimento da equipe VSSS-ERUS em 2019 se encotra no TDP submetido para a LARC em 24 de Julho de 2019. A leitura completa do TDP pode ser feita tanto pelo site da LARC 2019 quanto pelo site da ERUS na página do TDP 2019 do VSSS-ERUS.

Palavras-chave: ERUS, UFES, VSSS.

1.

I

A Very Small Size Soccer é uma categoria de competições da LARC e de outras competições importantes de robótica, e seu principal objetivo é construir um sistema composto de um time de pequenos robôs que obedeçam regras vindas de um sistema computacional, por sua vez composto por visão e processamento de imagem e cálculos de navegação. A necessidade de modelar o sistema foi acordada em reunião semanal, no dia 21 de março de 2019, iniciando os esforços de pesquisa de métodos eficazes de modelagem que pudessem agilizar ao máximo o processo e não atrasar o cronograma do projeto. Essa necessidade foi vista a partir do momento que os membros componentes da equipe na época1se depararam com a situação de não compreender mais o sistema realizado anteriormente a eles.

A Equipe de Robótica da UFES é uma equipe formada por alunos de graduação e o tempo médio de permanência na equipe é de 2 semestres letivos, o que levou a equipe de VSSS a passar por uma renovação drástica nos seus membros. Essa renovação fez com que não restasse nenhum membro original do desenvolvimento da primeira versão do sistema. Dessa forma, um esforço de estudos e engenharia reversa foi realizado para gerar documentação para o sistema original, porém, durante esses esforços os membros constataram que muitas mudanças e melhorias poderiam ser realizadas, como modularizar melhor o sistema e mudar certos algoritmos e estratégias contidas nele. Assim, o estudo que era para documentação do antigo sistema se tornou um estudo para desenvolvimento de um novo sistema, melhor, mais robusto e mais modularizado.

Este documento apresenta o levantamento de requisitos do sistema de Very Small Size Soccer da ERUS. Para levantar tais requisitos, nossa equipe estudou tanto o sistema original desenvolvido pelos membros fundadores da equipe quanto as regras da categoria segundo o edital da LARC.

O documento está organizado de forma que temos o registro de alterações no tópico 2, contendo cada alteração relevante neste documento, assim como os responsáveis e a data, como pode ser visto na tabela 1. Depois temos a descrição do propósito do sistema no tópico 3 e a descrição de minimundo no tópico 4. Por fim, temos as tabelas de requisitos levantados apresentados no tópico 5. Como o sistema é muito grande e complexo e a equipe estuda uma forma de separá-lo em sistemas independentes que se comuniquem, os requisitos foram levantados para cada sub-sistema separadamente e suas tabelas são vistas de acordo com a separação feita pela equipe.

1_{Os membros componentes da equipe de VSSS-ERUS nos semestres 2018/02 e 2019/01 eram Gabriel Valdino, Lara L. Texeira, Lorena B. Bassani,}

2.

R

A

Versão Responsáveis Data Alterações

1.0 Lorena B. Bassani 26/03/2019 Início das Atividades de Levantamento de Requisitos. 1.1 Lorena B. Bassani 02/04/2019 Continuação das Atividades de Levantamento de Requisitos. 1.2 Gabriel Valdino,

Lara L. Texeira, Lorena B. Bas-sani, Ricardo R. Rauta

06/04/2019 Escrita dos Requisitos Levantados no Relatório de Projeto do VSSS

2.0 Lorena B. Bassani 16/09/2019 Criação deste documento. Escrita do Resumo e ajustes de layout. Defi-nição das seções do documento.

2.1 Lorena B. Bassani 16/09/2019 Escrita dos Requisitos contidos no relatório de desenvolvimento. Revisão das classificações dos requisitos de Trajetória (dois não funcionais foram reclassificados como funcionais e seus textos foram revisados) e dos requisitos de Comunicação (uma regra de negócio foi reclassificada como requisito não funcional).

2.2 Lorena B. Bassani 16/09/2019 Escrita da introdução e dos textos das seções 5.1, 5.2, 5.3 e 5.4. 2.3 Lorena B. Bassani 17/09/2019 Escrita da descrição do propósito do sistema, com descrição do desafio

e proposta de resolução aprovada no TDP em 2019. Escrita da descrição de minimundo e do texto de introdução da seção 5, além da alteração do texto das seções 5.1, 5.2 e 5.3.

2.4 Lorena B. Bassani 18/09/2019 Escrita dos textos das seções 5.5, 5.6, 5.7 e 5.8.

Tabela 1: Tabela de Alterações deste Documento

3.

D

P

S

O propósito do novo sistema do VSSS é substituir o sistema original por um mais modularizado e bem documentado, com maior manutenibilidade e mais possibilidade de substituição gradativa dos módulos.

Com o sucesso do primeiro sistema de VSSS da ERUS, nós passamos a enxergar a possibilidade de melhorar nosso de-sempenho, testar novas técnicas e algoritmos, até mesmo desenvolver certas partes com auxílio de técnicas de inteligência artificial. Mas então, o que estava nos impedindo?

Falta de documentação e organização. Nosso sistema foi feito de forma muito bem pensada pelos membros originais da equipe, mas não foi deixado nenhum documento dizendo o que foi muito bem pensado. Por mais que tínhamos um sistema que foi capaz de ganhar terceiro lugar na LARC, não fazíamos ideia dos conceitos utilizados e do que cada parte fazia, estávamos aleatoriamente mudando partes para ver se tínamos algum resultado, mas é claro que acabamos bagunçando muito mais que melhorando qualquer coisa. Precisávamos urgentemente de um entendimento mais profundo do sistema. Ao começarmos a estudar profundamente o nosso sistema, percebemos que desenvolver um novo sistema seria muito proveitoso para a equipe, tanto para conseguirmos melhorar nossos conhecimentos e nossa documentação quanto para fazer um sistema com maior manutenibilidade.

Nos subtópicos 3.1 e 3.2 nós apresentamos o desafio do VSSS e fazemos um resumo da nossa proposta para resolução do desafio do VSSS.

3.1.

Descrição do Desafio

O desafio IEEE VSSS (Very Small Size Soccer) da LARC (Latin American Robotics Competition) propõe a construção de um time de futebol de robôs. Cada equipe é formada por três robôs autônomos de tamanho limitado (7.5 x 7.5 x 7.5cm), controlados unicamente por um computador externo que utiliza uma câmera de vídeo para aquisição de dados visuais do campo de futebol e comanda os robôs por meio de uma interface de comunicação sem fio.

recursos, além do fato que ele não possui sensoriamento externo próprio, apenas sensoriamento para situações internas2. Outra dificuldade é o processamento de imagem por visão computacional e tomada de decisão, além de fazer os robôs obedecerem as decisões tomadas.

3.2.

Proposta para Solucionar o Desafio

Resumiremos a proposta de solução para o desafio3. Nossa proposta é uma solução em arquitetura multinível, onde cada nível de controle tem uma tomada de decisão a partir das informações dadas pela camada superior.

A camada imediatamente superior é o Sistema de estratégia e tomada de decisão baseada em feedback por visão computacional. Nela nós analisamos a situação atual do jogo e decidimos o melhor lugar para enviar cada robô.

A camada central é a camada de navegação, calcula as trajetórias e possui algoritmos de navegação, tendo como resultado final as velocidades desejadas para cada roda de cada robô.

A camada mais baixa é o controlador PID, que a partir das velocidades procura controlar o robô com feedback da velocidade real.

Essa proposta é apenas uma proposta superficial de como encarar o problema, cada uma dessas camadas precisa ser projetada da forma correta, assim daremos continuidade do levantamento de requisitos.

4.

D

M

No contexto da competição de Very Small Size Soccer, temos um desafio de controle de múltiplos robôs com baixo poder de processamento e poucos recursos para que executem coordenadamente uma tarefa predefinida por um sistema computacional.

Esses robôs são muito pequenos, como sugerido no nome da categoria, com tamanho máximo de 7,5cm x 7,5cm x 7,5cm. Não é permitido sensoriamento externo nos pequenos robôs, apenas sensores de condições internas como bateria ou velocidade. A forma de monitorar o comportamento deles é por meio de uma câmera posicionada a 2 metros da arena. Aos robôs não é permitido o envio de comandos por um humano, apenas por um sistema computacional que deve utilizar apenas do sistema de visão para coletar informações sobre os acontecimentos e tomar as decisões de forma autônoma. As únicas intervenções humanas possíveis são durante intervalos na partida, com exceção dos comandos para inciar ou pausar o processamento.A comunicação entre sistema e os robôs deve ser por algum meio sem fio.

Os robôs devem ter um uniforme com uma área visível na parte superior que contenha a cor do seu time, sendo decidida pela organização entre amarelo e azul, sendo essa área um quadrado de no mínimo 3,5cm de lado ou um círculo de no mínimo 4cm de diâmetro. Além da cor do time, o robô pode conter uma segunda cor, que não pode ser da cor do outro time nem laranja, que é a cor da bola. O robô também pode conter uma área preta além das duas cores. Com o uniforme o robô não pode ultrapassar as dimensões de 8cm x 8cm x 8 cm.

Cada time é composto de 3 robôs, dessa forma, os objetos em campo são 6 robôs (3 de cada time) e uma bola de cor laranja.

O software não pode ser alterado por humanos durante o jogo, podendo mudanças de comportamento ser feita apenas de forma autônoma pelo próprio sistema.

Cada partida é composta por dois tempos de 5 minutos com um intervalo de 10 minutos entre eles. Ao time é aplicada uma punição caso seus robôs não parem de jogar quando o juiz especifica que a partida foi pausada.

Os robôs podem conter braços e pernas, desde que quando em suas expansões máximas não ultrapassem o tamanho máximo para o robô. O robô pode ainda encobrir até 30% da bola.

Os robôs podem trocar de posição durante a partida, sendo considerado goleiro qualquer robô que esteja na área de gol de defesa de seu time. Nas áreas de gol não podem haver dois robôs do mesmo time. Ou seja, não podem haver dois goleiros defendendo o gol nem dois atacantes tentando fazer o gol.

Durante os intervalos é permitido que o controlador4possa fazer alterações e ajustes no sistema.

Para poder completar o desafio, a equipe fará um sistema que planeja a melhor trajetória para cada robô, com uma interface gráfica que permita configurações diversas por parte do controlador, com por exemplo configuração nas referências das

2

Medição de velocidade das rodas, nível de tensão da bateria, etc...

3_{A proposta completa pode ser encontrada no TDP da equipe submetido para a LARC 2019} 4

cores, referências de limites do campo, dos IDs dos robôs presentes em campo e mudanças manuais de papel de cada robô5ou permitir que o papel fique variável para que o sistema decida qual o melhor papel para cada robô. Desejamos um sistema de navegação confiável, que a partir da posição de objetivo definida para cada robô, garanta que ele chegue lá sem bater em nenhum outro robô nem nas laterais limitadoras do campo.

Para ter uma ideia melhor do processamento e comportamento do sistema, a equipe deseja fazer alguns modos de visualização para a interface gráfica, como um modo de filtro de cor para a visão, modo de trajeto calculado por robô e campos potenciais calculados por robô.

A equipe utiliza uma câmera de captura de imagem por HSV para que a identificação de cores seja mais precisa. Os robôs utilizaram controlador de velocidade para mover-se e o sistema fornecerá o controlador de posição. Também tem disponível módulos XBee para comunicação. O planejamento da equipe é em fazer entre 5 e 6 robôs para a competição, de forma a ter robôs reservas durante a partida, uma vez que é permitido fazer substituições.

5.

R

S

O levantamento de requisitos foi realizado de forma coletiva por meio de duas reuniões semanais da equipe, realizadas nos dias 26 de março de 2019 e 02 de abril de 2019, onde discutimos sobre o domínio de aplicação e as funcionalidades que gostaríamos que o sistema apresentasse dentro das restrições estabelecidas pelas regras da categoria.

Dessa forma, obtivemos algumas tabelas de requisitos para cada módulo e para o sistema como um todo, passada para o Astah para que fosse parte do arquivo de projeto.

A atual lista de requisitos totaliza 55 requisitos dentre requisitos de Comunicação, Controle, Estratégia, Interface, Visão, Trajetória e Navegação.

Nessa seção a equipe apresenta os requisitos levantados durante os estudos do desafio e do sistema original. Os requisitos estão apresentados em tópicos por subsistema, além dos requisitos que dizem respeito ao sistema como um todo, apresentado no tópico 5.1.

Os requisitos de subsistemas apresentados são os requisitos de comunicação (tópico 5.2), requisitos de controle (tópico 5.3), requisitos de estratégia (tópico 5.4), requisitos de interface com usuário (tópico 5.5), requisitos de navegação (tópico 5.6), requisitos de calculo de trajetória (tópico 5.7) e requisitos de visão (tópico 5.8).

5.1.

Requisitos que Dizem Respeito a todo o Sistema

Alguns requisitos levantados regem todos os subsistemas do projeto. São, em sua maioria, regras de negócio levantadas a partir de uma leitura minuciosa das regras da categoria de acordo com o edital da LARC.

Esses requisitos falam sobre as interações do sistema com humanos e com seus robôs, além de restrições de cores e tamanhos que os robôs podem possuir e formas de comunicação possíveis ou não. Também cobre algumas partes sobre regras de movimentação dos robôs na arena e da composição dos times.

Por último, temos requisitos especificando a necessidade de construir um sistema modular que permita a substituição e melhoria dos módulos de forma independente.

5

5.1.1.

Regras de Negócio do Módulo do Sistema

ID Nome Descrição

RNS01 Regra de Negócio de Sistema 01 O sistema deve ser independente de auxílio humano, com exceção de comandos de iniciar e pausar e configurações feitas em períodos de intervalo de jogo.

RNS02 Regra de Negócio de Sistema 02 Os robôs devem conter uma área visível com a cor do time (amarelo ou azul) sendo no mínimo um quadrado com 3.5cm de lado ou um círculo com 4cm de diâmetro.

RNS03 Regra de Negócio de Sistema 03 Os robôs podem conter uma segunda cor, além de preto e a do time, que auxilia o sistema a reconhecê-lo, desde que não seja laranja, branco ou cinza.

RNS04 Regra de Negócio de Sistema 04 Um robô na área do gol de seu próprio time é considerado goleiro e não pode acontecer de mais de um robô de cada time estar em alguma área de gol.

RNS05 Regra de Negócio de Sistema 05 A comunicação entre computador e robô deve ser feita sem auxílio de fios.

RNS06 Regra de Negócio de Sistema 06 Os robôs devem respeitar um tamanho limite de 7,5cmx7,5cmx7,5cm e não deve ultrapassar 8cmx8cmx8cm com uniforme.

RNS07 Regra de Negócio de Sistema 07 Cada time é composto por 3 robôs e terá uma cor, amarelo ou azul, definida pela organização. Em campo haverá 6 robôs e uma bola por vez.

RNS08 Regra de Negócio de Sistema 08 Só podem ser feitas alterações no software de forma autônoma ou durante intervalos de jogo.

Tabela 2: Tabela de Regras de Negócio do Sistema

5.1.2.

Requisitos Não Funcionais do Sistema

ID Nome Descrição

RNFS01 Requisito Não Funcional de Sis-tema 01

Cada módulo deve ser passível de ser testado individualmente. RNFS02 Requisito Não Funcional de

Sis-tema 02

O sistema deve ser implementado de forma que seus módulos sejam substituíveis e alterados sem afetar uns aos outros. Isto é, é desejável bom encapsulamento e independência entre módulos.

Tabela 3: Tabela de Requisitos Não Funcionais do Sistema

5.2.

Requisitos do Modulo de Comunicação

A comunicação é o subsistema responsável por realizar a comunicação do sistema computacional com cada robô, sendo necessário que suas atividades sejam simples e rápidas, para que não provoquem atraso ou que a informação enviada torne-se obsoleta e inutilizável.

Os requisitos de comunicação falam sobre a necessidade de estabelece um padrão de comunicação e da necessidade de ter um sistema com um certo nível de confiança de acordo com o tipo de mensagem enviada.

5.2.1.

Requisitos Funcionais do Módulo de Comunicação

ID Nome Descrição

RFC01 Requisito Funcional de Comunica-ção 01

O módulo deve formatar a mensagem no padrão entendido por seu receptor.

RFC02 Requisito Funcional de Comunica-ção 02

O módulo deve enviar as mensagens devidamente endereçadas a seus receptores.

Tabela 4: Tabela de Requisitos Funcionais do Módulo de Comunicação

5.2.2.

Regras de Negócio do Módulo de Comunicação

ID Nome Descrição

RNC01 Regra de Negócio de Comunicação 01

O módulo deve receber os comandos no formato de dois inteiros de velocidade e um comando de direção.

Tabela 5: Tabela de Regras de Negócio do Módulo de Comunicação

5.2.3.

Requisitos Não Funcionais do Módulo de Comunicação

ID Nome Descrição

RNFC01 Requisito Não Funcional de Comu-nicação 01

A mensagem de pausa deve ter garantia de entrega.

Tabela 6: Tabela de Requisitos Não Funcionais do Módulo de Comunicação

5.3.

Requisitos do Módulo de Controle

O modulo de controle diz respeito aos componentes robóticos e como eles se comportam no sistema. Cada robô deve ser capaz de receber ordens e cumpri-las. Uma vez que todo o planejamento de trajetória e reconhecimento de mundo é feito pelo sistema computacional, o robô não precisa se preocupar com essas tarefas.

A real preocupação do módulo de controle é cumprir com os comandos recebidos do sistema computacional da forma mais fiel possível para que o objetivo principal do sistema seja cumprido.

5.3.1.

Requisitos Funcionais do Módulo de Controle

ID Nome Descrição

RFR01 Requisito Funcional de Controle 01 Com a informação das velocidades e da direção, cada robô deve ser capaz de obedecer e mover-se de acordo.

RFR02 Requisito Funcional de Controle 02 O robô pode conter braços e pernas e usá-los em jogadas. RFR03 Requisito Funcional de Controle 03 O robô pode enviar um sinal caso a bateria fique fraca.

RFR04 Requisito Funcional de Controle 04 Ao Receber um comando para parar o robô deve imediatamente parar de mover-se.

5.3.2.

Regras de Negócio do Módulo de Controle

ID Nome Descrição

RNR01 Regra de Negócio de Controle 01 Cada robô deve conter um ID único.

RNR02 Regra de Negócio de Controle 02 Cada robô deve ser capaz de receber e compreender mensagens de comando.

RNR03 Regra de Negócio de Controle 03 Os braços e pernas não podem ultrapassar os limites de tamanho do robô, mesmo totalmente esticados.

RNR04 Regra de Negócio de Controle 04 O robô não pode encobrir mais que 30% da bola.

Tabela 8: Tabela de Regras de Negócio do Módulo de Controle

5.3.3.

Requisitos Não Funcionais do Módulo de Controle

ID Nome Descrição

RNFR01 Requisito Não Funcional de Con-trole 01

Ao receber um comando de pausa, o robô deve enviar uma confir-mação de seu recebimento.

Tabela 9: Tabela de Requisitos Não Funcionais do Módulo de Controle

5.4.

Requisitos do Módulo de Estratégia

A Estratégia é o subsistema responsável pelas previsões de estados, cálculo de objetivos e mudanças de comportamento. Dessa forma, ela é como o pensamento consciente, aquele que planeja e verifica situações, sendo o lugar mais próximo de uma inteligência mais sofisticada.

Esse módulo é onde se concentra algumas das principais funções e processamentos do sistema, uma vez que seu objetivo é definir as jogadas e detectar as oportunidades ou situações de perigo do jogo.

Futuramente, esse é o primeiro e principal módulo onde poderíamos implantar técnicas de Inteligência Artificial para aprimorar nosso sistema.

5.4.1.

Requisitos Funcionais do Módulo de Estratégia

ID Nome Descrição

RFE01 Requisito Funcional de Estratégia 01 O módulo deve definir para onde os robôs aliados devem ser deslo-cados no próximo instante do jogo.

RFE02 Requisito Funcional de Estratégia 02 O módulo deve conseguir prever a posição dos inimigos e da bola no próximo instante.

RFE03 Requisito Funcional de Estratégia 03 O módulo deve considerar a tarefa de cada robô (goleiro, atacante, defesa) para calcular seu comportamento.

RFE04 Requisito Funcional de Estratégia 04 O módulo pode alterar as tarefas dos robôs caso verifique que é desejável.

RFE05 Requisito Funcional de Estratégia 05 O módulo deve responder as posições desejadas e atuais dos aliados e prevista dos inimigos.

5.4.2.

Regras de Negócio do Módulo de Estratégia

ID Nome Descrição

RNE01 Regra de Negócio de Estratégia 01 O módulo deve receber um estado de jogo, ou seja, posições atuais dos robôs e da bola, e realizar seus cálculos com essas informações. RNE02 Regra de Negócio de Estratégia 02 O módulo não pode definir dois goleiros ao mesmo tempo.

RNE03 Regra de Negócio de Estratégia 03 O módulo não pode enviar dois robôs para área de gol, tanto aliada quanto inimiga.

RNFE01 Requisito Não Funcional de Estra-tégia 01

O módulo deve considerar os limites do campo, não gerando posi-ções fora dele como resposta.

Tabela 11: Tabela de Regras de Negócio do Módulo de Estratégia

5.5.

Requisitos do Módulo de Interface com Usuário

O módulo de interface com usuário é o módulo responsável pela apresentação e pela interação com o controlador do sistema. Ele é responsável por fornecer as imagens da câmera, informações sobre a computação de partes críticas do sistema e por configurações que precisam ser feitas.

Nesse módulo teremos a oportunidade de mudar o ID dos robôs em campo, ligar o ID a cor do uniforme para o sistema reconhecer o robô, calibrar cores e limites do campo, alterar papel dos robôs ou definir como responsabilidade do sistema e ainda iniciar ou pausar a movimentação dos robôs em campo durante a partida.

5.5.1.

Requisitos Funcionais do Módulo de Interface com Usuário

ID Nome Descrição

RFI01 Requisito Funcional de Interface 01 Quais robôs estão em campo deve ser configurável pela interface gráfica a partir de seus IDs, dizendo qual robô (pelo ID) está usando que cor de uniforme.

RFI02 Requisito Funcional de Interface 02 A estratégia principal pode ser alterada pela interface.

RFI03 Requisito Funcional de Interface 03 As cores podem ser calibradas pela interface gráfica para melhorar a precisão de reconhecimento dos objetos.

Tabela 12: Tabela de Requisitos Funcionais do Módulo de Interface com Usuário

5.5.2.

Regras de Negócio do Módulo de Interface com Usuário

ID Nome Descrição

RNI01 Regra de Negócio de Interface 01 Qualquer modificação só pode ser feita com jogo pausado, incluso configurações, estratégias e IDs de jogadores.

Tabela 13: Tabela de Regras de Negócio do Módulo de Interface com Usuário

5.6.

Requisitos do Módulo de Navegação

O módulo de navegação é o módulo responsável por guiar cada robô até seu devido lugar. Ele permite que, dado uma trajetória para cada robô, ele possa cumprir com essa trajetória, calculando as velocidades necessárias em cada roda para que o robô faça o caminho correto.

5.6.1.

Requisitos Funcionais do Módulo de Navegação

ID Nome Descrição

RFN01 Requisito Funcional de Navegação 01

A partir das trajetórias, o módulo deve gerar comandos no formato de duas velocidades e uma direção.

RFN02 Requisito Funcional de Navegação 02

Ao receber uma nova trajetória, o módulo deve imediatamente tentar levar o robô ao trajeto.

Tabela 14: Tabela de Requisitos Funcionais do Módulo de Navegação

5.7.

Requisitos do Módulo de Trajetória

O módulo de trajetória é o módulo responsável por, dado um ponto de localização do robô e um ponto de objetivo dele, seja traçado uma trajetória que não passe por locais inapropriados, como por fora do campo ou por cima de obstáculos, mesmo que móveis. Ele cria uma trajetória de vários pontos até o objetivo que foi especificado.

5.7.1.

Requisitos Funcionais do Módulo de Trajetória

ID Nome Descrição

RFT01 Requisito Funcional de Trajetória 01 O módulo deve calcular o melhor trajeto entre origem e destino. RFT02 Requisito Funcional de Trajetória 02 O Sistema deve calcular uma trajetória que deve respeitar os limites

do campo, não passando por fora dele.

RFT03 Requisito Funcional de Trajetória 03 O Sistema deve calcular uma trajetória que deve evitar os pontos de obstáculos.

Tabela 15: Tabela de Requisitos Funcionais do Módulo de Trajetória

5.7.2.

Regras de Negócio do Módulo de Trajetória

ID Nome Descrição

RNT02 Regra de Negócio de Trajetória 01 O módulo precisa receber posições de origem e destino do robô e as posições dos obstáculos.

Tabela 16: Tabela de Regras de Negócio do Módulo de Trajetória

5.8.

Requisitos do Módulo de Visão

O módulo de visão é o módulo responsável por capturar e interpretar as imagens a partir da câmera, de modo a conseguir identificar todos os objetos em campo. Esse módulo deve responder a posição de cada objeto, bola, robôs aliados e robôs inimigos.

5.8.1.

Requisitos Funcionais do Módulo de Visão

ID Nome Descrição

RFV01 Requisito Funcional de Visão 01 O sistema deve estar atrelado a uma câmera.

RFV02 Requisito Funcional de Visão 02 O sistema deverá possuir uma interface gráfica com o usuário. RFV03 Requisito Funcional de Visão 03 O sistema deverá possibilitar que o usuário faça a calibração das

cores de cada agente, ou seja, uma forma de comprovar que o sistema está sabendo identificar os agentes por suas cores. RFV04 Requisito Funcional de Visão 04 O sistema deverá permitir que o usuário faça a calibração dos

extre-mos do campo.

RFV05 Requisito Funcional de Visão 05 O sistema deverá possuir uma forma de calcular a orientação atual de cada jogador aliado.

RFV06 Requisito Funcional de Visão 06 O sistema deverá possuir uma forma de calcular a posição atual de cada agente.

RFV07 Requisito Funcional de Visão 07 O sistema deve conseguir identificar cada posição importante do campo.

RFV08 Requisito Funcional de Visão 08 O sistema deve ser capaz de transformar a unidade de pixels em centímetros.

Tabela 17: Tabela de Requisitos Funcionais do Módulo de Visão

5.8.2.

Regras de Negócio do Módulo de Visão

ID Nome Descrição

RNV01 Regra de Negócio de Visão 01 A cor do time deve ser azul ou amarela.

RNV02 Regra de Negócio de Visão 02 Cada imagem deve ser independente, ou seja, não pode ser influen-ciada por informações anteriores.

RNV03 Regra de Negócio de Visão 03 Devem haver um comando de inicialização e um de pausa, que devem ser distintos, para marcar quando pode começar e quando deve pausar o processamento.

RNV04 Regra de Negócio de Visão 04 O módulo precisa conhecer o ID de cada jogador aliado em campo e a associação de ID com cor de uniforme deve ser feita em períodos de pausa do processamento.

RNV05 Regra de Negócio de Visão 05 A câmera deve capturar as imagens em HSV.