Atividade #1088
FechadaMeta #1087: Usar o padrão STP na nova documentação
Adaptar o diagrama de classes do artigo para a SSL, com o máximo de atributos definidos, assim como os "getters" e "setters".
Adicionado por Gabriel Borges da Conceição aproximadamente 5 anos atrás. Atualizado mais de 4 anos atrás.
Descrição
Em pesquisas feitas, foi encontrado um diagrama de classes genérico para futebol de robôs. O objetivo dessa tarefa é adaptar esse diagrama com as classes que definimos.
O diagrama de classes se encontra em:
http://www.aspecs.org/FIRA_Robot_Soccer
Arquivos
| IMG_4940.jpg (1,05 MB) IMG_4940.jpg | Carla Cosenza, 01/05/2019 18:55 h | ||
| IMG_8373.jpg (1,25 MB) IMG_8373.jpg | Carla Cosenza, 01/05/2019 20:15 h | ||
| picture942-1.png (89,1 KB) picture942-1.png | Lucas Germano, 14/05/2019 15:23 h |
Atualizado por Carla Cosenza há aproximadamente 5 anos
- Arquivo IMG_4940.jpg IMG_4940.jpg adicionado
Fizemos o diagrama de classes, sem os atributos primeiro, para conseguir visualizar melhor. Estamos fazendo o diagrama com atributos agora.
Atualizado por Carla Cosenza há aproximadamente 5 anos
Uma dúvida que tivemos é se vai existir a classe Eventos, ou se só serão métodos.
Atualizado por Carla Cosenza há aproximadamente 5 anos
Outro problema que temos, é que usando o diagrama que desenhamos, o robô não tem um atributo para identificar sua personalidade, os seus métodos vão definir isso. Logo talvez seja melhor criar uma classe personalidade.
Atualizado por Carla Cosenza há aproximadamente 5 anos
Talvez seja melhor usar um enum para isso.
Atualizado por Carla Cosenza há aproximadamente 5 anos
- Arquivo IMG_8373.jpg IMG_8373.jpg adicionado
A gente escolheu esses atributos para cada classe. Não colocamos atributos para Play pois não sabemos como que essa classe iria funcionar.
Atualizado por Gabriel Borges da Conceição há aproximadamente 5 anos
Carla Cosenza escreveu:
Outro problema que temos, é que usando o diagrama que desenhamos, o robô não tem um atributo para identificar sua personalidade, os seus métodos vão definir isso. Logo talvez seja melhor criar uma classe personalidade.
Acho que seria melhor se a decisão de personalidades fosse um método de Ally. O método usaria o atributo array (Robot) robots.
Atualizado por Luiz Renault Leite Rodrigues há aproximadamente 5 anos
Carla Cosenza escreveu:
Uma dúvida que tivemos é se vai existir a classe Eventos, ou se só serão métodos.
Pode existir sim.
Atualizado por Lucas Germano há aproximadamente 5 anos
Carla Cosenza escreveu:
Uma dúvida que tivemos é se vai existir a classe Eventos, ou se só serão métodos.
Como o major falou pode existir sim, daí teríamos algo do tipo para acessar algum evento: WorldState.Events.IdTouchingBall
Ou seja, eles estariam embutidos no World State.
Atualizado por Gabriel Borges da Conceição há aproximadamente 5 anos
Quais foram as vantagens que vcs viram de criar as classes "Offensive" e "Defensive" ao invés de fazer "Attacker", "Striker" e "Defender" descendentes diretos (classes filhas) de "Robot"?
Atualizado por Lucas Germano há aproximadamente 5 anos
Estou tentando fazer a parte do diagrama que contém Plays, Tactics e Skills. Precisando de algumas inspirações fui olhar o código da tigers e o que descobri foi:
OBS: O código deles pode ser baixado em: https://www.tigers-mannheim.de/index.php?id=65
Um artigo deles que ajuda a navegar pelo código: https://tigers-mannheim.de/download/papers/2011-AI-Structure_Koenig.pdf
Sobre o sistema de skills deles: https://tigers-mannheim.de/download/papers/2011-Studienarbeit_Bot_Skill-Teichmann_Graeser.pdf
Algumas classes deles são dividadas em:
ASkill: Classe abstrata de skill, todas as skills herdam dessa classe
ESkill: Enum contendo todas as skills, cada elementeo no enum tem referência para a classe skill que a executa
ISkill: Interface para acessar os atributos de Skill sem mudá-los
Aqui está o exemplo da ERole(Em Java, claro):
public enum ERole implements IInstanceableEnum
{
// offensive roles
ATTACKER(new InstanceableClass(AttackerRole.class)),
SUPPORTIVE_ATTACKER(new InstanceableClass(SupportiveAttackerRole.class)),
KEEP_DIST_TO_BALL(new InstanceableClass(KeepDistToBallRole.class)),
OPPONENT_INTERCEPTION(new InstanceableClass(OpponentInterceptionRole.class))
...
}APlay:
- List<ARole> roles;
- EPlay type;
ARole:
- ERole type;
- BotID botID;
- ISkill currentSkill;
- bool newSkill;
- IStateMachine<IState> stateMachine;
A classe BotID é utilizada para identificar os robôs de todos os times, ela extende AObjectID.
ASkill
- IState IDLE_State = new DefaultState();
- ESkill skillName;
- IStateMachine<Istate> stateMachine = new StateMachine<>(IDLE_STATE);
- ABot bot;
...
ABot
- String[] BOT_NAMES;
- BotID botID;
- EBotType type;
- TrajectoryWithTime<IVector3> curTrajectory = null;
- double kickerLevelMax = 200;
Depois de ter uma ideia como as classes base deles são feitas, fui olhar uma Play deles para ver como eles implementavam. A play que fui olhar se chamava OffensivePlay, a primeira coisa que é feita no construtor é passar o comportamento de cada robô para eles de acordo com sua personalidade:
public OffensivePlay()
{
super(EPlay.OFFENSIVE);
strategyToRoleMap.put(EOffensiveStrategy.KICK, ERole.ATTACKER);
strategyToRoleMap.put(EOffensiveStrategy.SUPPORTIVE_ATTACKER, ERole.SUPPORTIVE_ATTACKER);
strategyToRoleMap.put(EOffensiveStrategy.STOP, ERole.KEEP_DIST_TO_BALL);
strategyToRoleMap.put(EOffensiveStrategy.DELAY, ERole.DELAYED_ATTACK);
strategyToRoleMap.put(EOffensiveStrategy.FREE_SKIRMISH, ERole.FREE_SKIRMISH);
strategyToRoleMap.put(EOffensiveStrategy.INTERCEPT, ERole.OPPONENT_INTERCEPTION);
strategyToRoleMap.put(EOffensiveStrategy.RECEIVE_PASS, ERole.PASS_RECEIVER);
}
...O código deles é bem complexo atualmente e com certeza não devemos nos basear em tudo o que fazem, mas algumas ideias para a nossa implementação podem ser uteis.
Atualizado por Lucas Germano há aproximadamente 5 anos
Comecei a fazer o diagrama, mas ainda não está nem perto de pronto:
https://drive.google.com/file/d/1Q6apXIaL_1npCdG02SeitQa_EgS-FBGn/view?usp=sharing
Atualizado por Gabriel Borges da Conceição há aproximadamente 5 anos
- Data prevista alterado de 01/05/2019 para 11/05/2019
Atualizado por Lucas Germano há aproximadamente 5 anos
- Arquivo picture942-1.png picture942-1.png adicionado
Todos da intel fizeram um mutirão nesse fds que passou e passamos muito tempo discutindo a implementação e a estrutura que o código teria. Como o Labview tem uma ferramente que converte o diagrama de classes para código pronto, decidimos desenhar e escrever o diagrama de classes direto na ferramenta do labview. O diagrama ficou como mostra a imagem a seguir:
Várias discussões foram feitas, como por exemplo: o goleiro deve ter uma play específica para ele, por questões de desempenho, seu comportamento deve ser mantido isolado do resto do time, para que ele possa reagir melhor e mais rápido aos comportamentos inimigos.
A vision e a COM foram mantidos como uma classe só cada, visto que não iremos orientar-los a objeto, continuarão do jeito que estão hoje em dia.
Temos agora que colocar os atributos das classes, colocar os métodos mais básicos e então começaremos a codar de verdade. Sabemos que coisas novas aparecerão a medida que formos codando, mas acredito que iremos implementando a medida que formos precisando.
Atualizado por Nicolas Oliveira há aproximadamente 5 anos
Atualizar o diagrama para a atual implemetação.
Atualizado por Gabriel Borges da Conceição há mais de 4 anos
- Situação alterado de Em andamento para Fechada