---
# System prepended metadata

title: 2° reunião (17/01)

---

### 17/01

Membros: Braguinha, Marques, Francisco, Kakastro, Rafael, Julio, Viana

Autores: Marques, Viana

 
 ## Geral
### Considerações iniciais 
* Os feedbacks foram dados de forma tranquila
* Os membros se sentiram confotáveis com a quantidade de tasks e do Trello
* Seria importante ter uma ideia de data limite para as tasks, embora a maioria delas já esteja nesses moldes
### Próximos passos :athletic_shoe: 
* Iremos começar a vir bastante para a sala, para testagem da placa, montar a placa do seguidor. Por conta disso é importantíssimo fazermos e lermos todos os resumos de tasks sendo feitas. Eles deverão ser feitos tanto no trello ou no whatsapp de uma forma bem mais objetiva.
### Ausência do Braguinha em uma competição 
* Na RCX ele não poderá estar presente, logo iria precisar de alguma pessoa para administrar o grupo no momento.
* Braguinha propôs a ideia de do dia 15 de fevereiro em diante algum membro "trocar de lugar" com ele para assumir o papel. Haverá constante acompanhamento do Braguinha em relação a esse membro.
    * O membro que iria assumir o papel de líder só iria passar as tasks, e o Braga iria assumir papel de membro eletroprog ou mec dependendo da pessoa que assumisse.
* Discussões sobre a ideia :thought_balloon: 
    * Francisco e Marques: Pode ser uma pressão muito grande cair no colo de um membro que não se via preparado para isso.
    * Francisco: A preparação que o Felipe deu para a competição foi boa o suficiente para estarmos um pouco mais coordenados e a falta de liderança não ter sido uma grande questão. Talvez o mesmo possa ser feito para a RCX - preparação forte na pré competição e escolher um membro mais experiente para ter um plano de ação na RCX

* Braga deve mandar formulário para refletirmos um pouco sobre como foi as primeiras semanas
 
---
 ## Eletroprog :zap: :computer: 
 ### Feedback sobre o diagrama do Coordenador de Programação :computer: 
* Organização ficou boa, mas poderia ter tido um fluxograma, unindo justamente todos os arquivos e estipulando a lógica entre cada parte dos arquivos. Poderia ser uma boa ideia justamente para também integrar todos os membros com o código
* O diagrama está completo e todos arquivos\classes foram aprovados pelo Renan
* Já podem partir pro código/fluxograma
* Discussão acerca do Datacenter
    * Lembrando, datacenter seria um arquivo para armazenar a maioria das variáveis que serão usados no programa
    * Renan não viu problema em usarmos datacenter, mas somente para armazenamento de variáveis! Evitar colocar lógicas dentro do datacenter, só irá dificultar ainda mais a compreensão. Seria importante também tentarmos colocar primordialmente variáveis estáticas
    * Achou justo criar as variáveis dentro do próprio arquivo que será usado (variáveis do encoder dentro do arquivo de encoder, por exemplo). Outra opção seria criar mais arquivos com as variáveis específicas para cada componente. Um arquivo para variáveis do encoder e outro arquivo para a lógica por si só
    * Porém um bom começo seria fazer isso no mesmo arquivo
    *  Comentário datacenter (Marcel):
 
         o datacenter do jeito que foi implementado no código antigo era horrível. Ele contribuía para a desorganização do código, porque ficava várias variáveis tudo juntas e não necessariamente elas tinham haver umas com as outras.

        O ideal de um código é evitar ao máximo o uso de variáveis globais, mas sei que pra nossa aplicação é inviável não ter elas, então eu sou fã de duas opções:

        Ou deixa cada variável em seu respectivo .hpp para ela estar associada a aquele contexto. Sendo honesto acho essa a opção mais válida. Ou você cria diversos arquivos de configurações para cada assunto e neles você coloca as variáveis organizadas por contexto. Acredito que dessas duas formas fica melhor a organização, mas cabe a vocês decidirem
* Classe vs Namespace
    * Renan diz que no código dos minis tinham muitos namespace dentro de namespace, o que deixava a organização um pouco confusa
    * Não vê problema em usarmos namespace, mas acha que certos componentes valem à pena ser usados com classe (tipo motores)
    * Uma outra sugestão que ele deu foi criarmos um namespace para cada componente ao invés de usar o datacenter. Assim, criaríamos um namespace de encoder para armazenar as variáveis do mesmo

### Repositório do código 
* Como uma task extra fazer o repositório para o linha vermelha

### Escolha entre os tipos de ESC
* Temos a possibilidade de usar um grande esc que consiga controlar as quatro ventoinhas por si só ou 4 escs individuais e menores para controlar cada uma individualmente

### Uso do pescoço 
* Por mais que talvez não vamos usar o pescoço em competições, é importante fazermos a implementação pela redditus

### Tasks dos Eletroprogs :electric_plug: 
* Fazer testagem dos componentes do neon tanto com código tanto debbugando a placa (Provável líder: Marques)
* Rafael ficou responsável por mostra a montagem do Neon para  Júlio, Marques e Giovanni
* Verificar componentes no Altium para vermos se temos suficiente para o neon reserva (Braga + Julio)
* Soldagem do Neon reserva (Kauan e Giovanni)

### Mistério do ESC queimado :fire: 
* Descobrir o motivo do esc ter ido de base
* Avisar ao thiago sobre a provável causa ser injetar sinal primeiro do que potência, mas não temos explicação para esse fenômeno

### TENHAM MELHOR ORGANIZAÇÃO DE BRANCHES NO GIT!!!!!!!!!!!!!

---
 
 ## Mecânica
 
 ### Task mecânicas para até o final do mês (2 semanas) :male-mechanic: 
* Correção das peças atuais (tarefas no solid)
* Manufatura da pista 
 ### Capacitação de montagem pendente:
 - Giovanni
 ## ADM
 
 ## MKT
 ### Felipe irá ajudar o Braguinha para deixar o Trello bonitinho