Requisitos

ESTRUTURAS

Requisitos Funcionais

ID	Nome do Requisito	Descrição	Prioridade	Responsável	Observações
RF01	Envelope Dimensional Limite	A estrutura não pode exceder 16,5 cm de comprimento nem 16,5 cm de largura. Não há limite para a altura.	Alta	Estrutura	Restrição física estrita da competição. Recomendado projetar com margem de segurança. (ex:14 cm X 14 cm).
RF02	Compatibilidade com o Chão e Paredes	O chassi/rodas deve operar em chassi de piso (Chão preto) e interagir com paredes de 5 cm de altura e 1,2 cm de espessura.	Alta	Estrutura	Garantir vão livre em relação ao solo adequado e evitar colisão do chassi com as paredes.
RF03	Atrito e Tração das Rodas	Selecionar e integrar pneus/rodas com alto coeficiente de atrito com a superfície de piso pintada de preto.	Alta	Estrutura	Permite acelerações e frenagens sem derrapagem, garantindo a precisão da odometria.
RF04	Suporte e Posicionamento dos Sensores	A estrutura deve fornecer suportes rígidos e calibrados para a fixação dos sensores de distância sensores de linha/cor.	Alta	Estrutura	O alinhamento dos sensores deve ser fixo e resistente a vibrações para não comprometer o mapeamento.
RF05	Proteção contra Danos ao Labirinto	O chassi deve possuir compartimentos adequados para fixação segura dos componentes.	Alta	Estrutura	Manter o centro de gravidade baixo para estabilidade em curvas rápidas.
RF06	Facilidade de Manutenção e Acesso	Deve permitir rápido acesso/troca da bateria e facilidade de limpeza/manutenção das rodas durante as pausas.	Alta	Estrutura	Pequenos reparos e limpeza das rodas são permitidos em repouso.
RF07	Modelagem e Manufatura	Toda a estrutura do robô e componentes mecânicos deverão ser modelados em CAD 3D.	Média	Estrutura	Obrigatório para documentação do projeto conceitual de estruturas (AP5).
RF08	Construção do Labirinto de Testes Local	Projetar e montar uma estrutura de pista de testes 4X4 células (72 X 72 cm²) com paredes brancas (5cm de altura) e topos vermelhos.	Média	Estrutura	Exigência para validação local e teste de integração do grupo antes da entrega final.

ENERGIA

Requisitos Funcionais

ID	Nome do Requisito	Descrição	Prioridade	Responsável	Observações
RF01	Alimentação autônoma embarcada	O sistema de energia deve alimentar todos os subsistemas embarcados (microcontrolador, sensores, motores e módulo de comunicação) a partir de uma fonte transportada pelo próprio Micromouse, sem cabos ou fontes externas.	Must Have	Energia	Operação 100% autônoma exigida no slide 7.
RF02	Regulação das tensões de operação	O sistema de energia deve fornecer, a partir da fonte, os níveis de tensão exigidos por cada subsistema, mantendo-os dentro da faixa de operação especificada pelos respectivos componentes.	Must Have	Energia	Faixas definidas no 4.2 (Tabela 7): fonte LiPo 2S de 7,0 a 8,4 V úteis (corte em 7,0 V) ou 4 × AA (6,0 V nominais); 5 V com pelo menos 1 A para o ESP32 e o LDO; 3,3 V com pelo menos 200 mA para ToF e encoders; 6 V médios nos motores por limite de PWM.
RF03	Compatibilidade com Múltiplas Fontes de Energia	O sistema de energia deve prover um meio de comutação manual para selecionar a fonte de alimentação ativa a partir de entradas de energia alternativas, sem alterações físicas na placa.	Should Have	Energia	Permite operar com fontes de químicas ou especificações diferentes sem reprojeto.
RF04	Medição do nível de carga	O sistema de energia deve disponibilizar ao microcontrolador uma grandeza elétrica que permita estimar a carga restante da fonte, sem impor um método específico de medição.	Must Have	Energia	Alimenta o dado de telemetria "consumo de bateria" (slide 11).
RF05	Sinalização do estado de energia	O sistema de energia deve indicar que o robô está energizado e sinalizar quando a carga atingir o nível mínimo de operação.	Should Have	Energia	Evita iniciar uma tentativa com carga insuficiente. Alerta em 3,7 V por célula (7,4 V) na LiPo, antes do corte em 3,5 V por célula (7,0 V); 5,0 V nas pilhas AA (4.2, seção 5.3).
RF06	Troca e recarga sem desmontagem	O sistema de energia deve permitir a troca ou a recarga da fonte sem desmontar a estrutura do Micromouse.	Must Have	Energia	Entre tentativas só são permitidos pequenos reparos com o robô em repouso (slide 10).
RF07	Instalação e remoção da fonte de energia	O sistema de energia deve permitir instalar e remover a fonte de energia sem ferramentas especiais, mantendo-a fixada à estrutura durante todo o percurso, sem deslocamento em curvas, vibração ou colisão.	Must Have	Energia	A fonte solta pode interromper a alimentação no meio da corrida; colisões são previstas no slide 10. A fonte é ligada por conector XT30 polarizado, sem solda (4.2, seção 4.4).

Requisitos Não Funcionais

ID	Nome do Requisito	Descrição	Prioridade	Responsável	Observações
RNF01	Separação entre potência e lógica	O sistema de energia deve manter a alimentação dos motores independente da alimentação da lógica, seja por fontes distintas, seja por barramentos regulados separados, de modo que os picos de corrente do acionamento não provoquem reinicialização do microcontrolador nem leituras erradas dos sensores.	Must Have	Energia
RNF02	Autonomia de operação	A fonte de energia deve manter o Micromouse em operação contínua por, no mínimo, 30 minutos, equivalentes aos três labirintos de 10 minutos cada, sem troca nem recarga.	Must Have	Energia	Slides 21, 22 e 23: cada labirinto tem 10 minutos, com até três tentativas dentro desse tempo. A LiPo de 650 mAh adotada dá cerca de 72 min no pior caso (4.2, Tabela 6).
RNF03	Dimensionamento da capacidade da fonte	A capacidade da fonte escolhida deve ser justificada por cálculo prévio do consumo médio e de pico de todos os subsistemas, considerando a autonomia exigida, a parcela realmente utilizável da capacidade nominal e uma margem de segurança mínima de 30%.	Must Have	Energia	Margem de 25% a 30% é a prática usual em robótica móvel.
RNF04	Proteções elétricas da fonte	O sistema de energia deve proteger o Micromouse contra sobrecorrente e curto-circuito, inversão de polaridade da fonte e descarga profunda da bateria.	Must Have	Energia	4.2, Tabela 9: fusível rearmável PTC de 2,0 A, diodo Schottky em série na entrada e corte por subtensão em 7,0 V feito pelo firmware. Apontado pelo item 2.3 da EAP.

Histórico de Versões (Requisitos — Energia)

Versão	Data	Descrição	Autor(es)
1.0	08/10/2026	Revisão dos requisitos de Energia diante do projeto conceitual v1.5: faixas de tensão no RF02, limites de alerta no RF05, conector no RF07, autonomia da bateria adotada no RNF02 e criação do RNF04 (proteções) #163.	João Marcos Moraes de Andrade, Giovana Martins de Brito

ELETRÔNICA

Requisitos Funcionais

ID	Nome do Requisito	Descrição	Prioridade	Responsável	Observações
RF1	Detecção de paredes	O sistema eletrônico deve detectar a presença de paredes ao redor do Micromouse por meio dos sensores, disponibilizando essas informações ao sistema de controle para auxiliar no mapeamento e na navegação pelo labirinto.	Must Have	Eletrônica	Deve funcionar considerando as características da pista (chão preto, paredes brancas com topo vermelho, 5 cm de altura, células de 18 cm). Os testes de detecção devem ocorrer antes da integração.
RF2	Controle dos motores	O sistema eletrônico deve acionar e controlar os motores do Micromouse, permitindo sua movimentação, realização de curvas e paradas durante a navegação, garantindo compatibilidade elétrica entre microcontrolador, drivers e motores.	Must Have	Eletrônica	Deve ser validado por testes de movimento, curvas e paradas.
RF3	Aquisição de dados de telemetria	O sistema eletrônico deve integrar circuito de leitura da tensão da bateria e disponibilizar ao sistema de controle os dados necessários à telemetria e monitoramento de movimento.	Must Have	Eletrônica	Inclui divisor de tensão para leitura da bateria no ADC. Os dados devem ser disponibilizados ao software/firmware para envio ao sistema web.
RF4	Comunicação sem fio com a telemetria	O sistema eletrônico deve transmitir os dados coletados (bateria, velocidade, trajeto) via módulo Bluetooth para o sistema web de telemetria, garantindo o envio correto das informações a cada tentativa.	Must Have	Eletrônica	Módulo Bluetooth previsto no orçamento (item 10 do TAP). Complementa o RF3 (aquisição/disponibilização interna dos dados) e sustenta o RF24 do Firmware.
RF5	Sinalização de estado do robô	O sistema eletrônico deve acionar indicadores visuais e sonoros (LED e buzzer) para sinalizar o estado do Micromouse (início do percurso, erro/colisão, conclusão do labirinto).	Should Have	Eletrônica	Relaciona-se ao RF25 do Firmware.
RF6	Interface de sinais para odometria dos motores	O sistema eletrônico deve rotear as linhas de pulso de passo e direção (STEP/DIR) entre microcontrolador e drivers, viabilizando o cálculo de passos, distância e velocidade pelo firmware.	Must Have	Eletrônica	Sustenta o RF3 e o RF22 do Firmware. Como os motores são de passo (open-loop), a contagem é feita pelo firmware a partir dos pulsos enviados ao driver (RF7).
RF7	Driver dos motores de passo	O sistema eletrônico deve incluir circuitos driver dedicados para os motores de passo, responsáveis por fornecer a corrente e a sequência de acionamento de fases necessárias ao movimento, com proteção contra sobrecorrente nos enrolamentos.	Must Have	Eletrônica	Complementa o RF2. Corrente nominal do driver deve ser compatível com os motores Nema 11 (itens 5 e 14 do orçamento).
RF8	Condicionamento de sinal dos sensores	O sistema eletrônico deve condicionar (amplificar/filtrar) os sinais dos sensores infravermelhos antes da leitura pelo microcontrolador, garantindo distinção confiável entre piso preto, paredes brancas e topo vermelho.	Must Have	Eletrônica	Sensores previstos nos itens 1, 2, 8 e 9 do orçamento. O limiar de leitura deve ser ajustável para calibração, sustentando o RF1.
RF9	Interface do DIP switch de configuração	O sistema eletrônico deve conectar o DIP switch de 4 vias a entradas digitais do microcontrolador, permitindo ao firmware ler o tipo de labirinto e os modos de operação sem reprogramação.	Should Have	Eletrônica	Viabiliza o RF27 do Software: as vias 1 e 2 selecionam o labirinto. Componente já previsto no item 6 do orçamento.
RF10	Driver dos indicadores visuais e sonoros	O sistema eletrônico deve fornecer o circuito de acionamento (resistor limitador e/ou estágio de chaveamento) do LED e do buzzer, evitando corrente excessiva nas saídas digitais do microcontrolador.	Should Have	Eletrônica	Suporta o RF5. Componentes previstos no item 11 do orçamento.

Requisitos Não Funcionais

ID	Nome do Requisito	Descrição	Prioridade	Responsável	Observações
RNF1	Confiabilidade elétrica	O sistema eletrônico deve operar durante o desafio sem reinicializações ou falhas elétricas não planejadas (causadas por ruído, quedas de tensão ou mau contato) que interrompam o funcionamento do Micromouse.	Must Have	Eletrônica	Deve ser verificado em testes contínuos e nos testes de integração. O sistema deve permanecer operacional pelos 10 minutos do desafio.
RNF2	Estabilidade da alimentação	Os níveis de tensão entregues a cada subsistema eletrônico (lógica do microcontrolador, sensores e drivers dos motores) devem ser validados e mantidos dentro da faixa de operação de cada componente, inclusive durante os picos de corrente dos motores.	Must Have	Eletrônica	A regulação e a estabilidade da tensão propriamente ditas são responsabilidade da energia (itens 2 e 12). Este requisito cobre a validação, no lado da eletrônica, de que cada componente recebe tensão compatível com sua especificação.
RNF3	Integração e compactação	Os componentes eletrônicos (PCB, sensores, conexões e drivers) devem ser organizados fisicamente de forma compacta e segura sobre a estrutura do robô, de modo que a disposição também permita a montagem e a manutenção dos componentes.	Must Have	Eletrônica	Trata da organização/arranjo dos componentes.
RNF4	Restrição dimensional do hardware	A placa de circuito impresso (PCB) deve ser projetada com dimensões reduzidas (máximo de 12 cm de comprimento por 12 cm de largura), garantindo que o robô montado com sensores e rodas não ultrapasse o limite de 16,5 cm definido pela Estrutura.	Must Have	Eletrônica	Garante margem física para manobras dentro da célula de 18 cm × 18 cm sem colisão mecânica.
RNF5	Proteção dos pinos de sensoriamento	O sistema eletrônico deve proteger as entradas digitais/analógicas do microcontrolador contra picos de tensão e descargas eletrostáticas vindas de sensores e conectores externos.	Should Have	Eletrônica	Foco na integridade dos sinais de sensoriamento, distinto das proteções de linha de potência já cobertas pela Energia (itens 13 e 14).
RNF6	Temporizador de watchdog	O sistema eletrônico deve implementar um circuito ou função de watchdog capaz de reiniciar automaticamente o microcontrolador caso o firmware trave durante a tentativa.	Must Have	Eletrônica	Reforça o RNF1 e o RNF07 do Software. Crítico diante do limite de 10 minutos por labirinto. É uma reinicialização controlada, diferente das falhas não planejadas que o RNF1 busca evitar.
RNF7	Padronização de conectores	O sistema eletrônico deve padronizar os conectores entre PCB, motores, sensores e fonte de energia, evitando inversão de conexão e facilitando a manutenção nas pausas entre tentativas.	Should Have	Eletrônica	Conectores JST previstos nos itens 7 e 16 do orçamento. Relaciona-se ao requisito 6 de Estrutura.
RNF8	Documentação do esquemático elétrico	Todo o circuito eletrônico (PCB, conexões e drivers) deve ser documentado em esquemático elétrico e diagrama de conexões, versionado no repositório do projeto.	Must Have	Eletrônica	Equivalente ao requisito 7 de Estrutura. Necessário para o projeto conceitual (AP5) e alinhado à RNF13 do Software. É mais um requisito de processo/entrega do que de comportamento do sistema em si.
RNF9	Capacidade de I/O do microcontrolador	O microcontrolador selecionado deve possuir pinos digitais/analógicos suficientes para os sensores de parede/linha, os drivers dos motores, o módulo Bluetooth, o DIP switch, o LED e o buzzer, sem necessidade de multiplexação adicional.	Must Have	Eletrônica	Requisito de dimensionamento a ser validado na escolha do microcontrolador durante o projeto conceitual.

SOFTWARE

Requisitos Funcionais

ID	Nome do Requisito	Descrição	Prioridade	Responsável	Observações
RF01	Visualizar telemetria do robô	O sistema web deve permitir ao usuário visualizar os dados de telemetria do Micromouse durante e após a execução, como velocidade, bateria, tempo de percurso e status	Must Have	Frontend	Requisito essencial para o acompanhamento da execução do robô.
RF02	Visualizar os Dados da Execução	O sistema deve permitir ao usuário visualizar os principais dados de uma execução após sua finalização, incluindo tempo, velocidade e desempenho.	Must Have	Frontend	As informações devem ser apresentadas de forma organizada em ordem cronológica de execução.
RF03	Visualizar histórico de execuções	O sistema deve apresentar para o usuário uma seção na aplicação que forneça o histórico de todas as execuções já realizadas.	Must Have	Frontend	Em ordem decrescente de execução (da última para a primeira).
RF04	Visualizar execução em tempo real	Caso haja uma execução com tentativa em "running", o sistema deve fornecer ao usuário os dados dessa execução na tela inicial, com o tempo da última atualização e o trajeto atualizado conforme a telemetria chega.	Should Have	Frontend	Ex.: mensagem "última atualização há 4 segundos". Consumo via SSE (EventSource), não polling periódico (RF06).
RF05	Visualizar os dados captados no health-check	O sistema deve fornecer ao usuário, durante a execução e após o término da mesma, os dados coletados no health-check que liberou a tentativa, em uma área específica, separada do resto dos dados coletados na página da execução específica.	Must Have	Frontend	Conectado ao RNF03.
RF06	Fornecer dados de uma execução em tempo real	O sistema deve expor um fluxo SSE com os dados de telemetria de uma execução com tentativa em "running", enviando cada atualização assim que registrada no backend.	Should Have	Backend	Preferível a polling para trajeto em tempo real (menor latência e menos carga). REST permanece para consultas e comandos operacionais.
RF07	Consulta ao histórico de execuções	O sistema deve permitir ao usuário consultar as execuções anteriores do Micromouse, apresentando os dados registrados de cada tentativa para possibilitar a análise do desempenho.	Must Have	Backend	O histórico deve apresentar as informações de cada execução de forma organizada.
RF08	Receber telemetria do micromouse	O sistema deve receber os dados de telemetria enviados pelo micromouse durante a corrida, contendo no mínimo a célula atual, o nível de bateria e o instante de envio (timestamp).	Must Have	Backend	Slide 11. Transporte alinhado ao TAP: Bluetooth serial (RF4 Eletrônica), via ponte no notebook; formato da mensagem (ex.: JSON) a definir com firmware.
RF09	Registrar trajeto no labirinto	O sistema deve armazenar, em ordem cronológica, a sequência de células visitadas pelo micromouse por execução, permitindo reconstruir o trajeto completo.	Must Have	Backend	Slide 11. Sugestão de representação: coluna + linha (ex.: A1, B2), igual aos exemplos do enunciado.
RF10	Registrar início de corrida	O sistema deve criar registro de execução lógica e de tentativa (UC01), associando tipo de labirinto (4x4, 8x4 ou 12x4), attempt_index (1…3, TAP), tentativa_id único (RF17) e data/hora de início.	Must Have	Backend	Slides 5, 11 e 23. O health-check (UC20) é anterior à tentativa e vale por 7 minutos: a tentativa só abre se o último health-check estiver aprovado, dentro da validade e com o tipo do DIP igual ao informado, e já nasce em running. O robô só parte com o comando largar do operador (RF39).
RF11	Calcular consumo de bateria	O sistema deve calcular o consumo de bateria da corrida a partir das leituras recebidas, informando o nível atual e o total consumido desde o início.	Must Have	Backend	Slide 11. Tensão (V) e % pela curva da fonte ativa (LiPo 2S ou pilhas AA, doc 4.2); consumo = nível no início − nível atual.
RF12	Calcular velocidade média	O sistema deve calcular a velocidade média do micromouse, dividindo a distância percorrida pelo tempo decorrido.	Must Have	Backend	Slide 11. Distância = nº de células percorridas × 18 cm (slide 9); o ToF frontal e os encoders refinam a posição dentro da célula.
RF13	Calcular tempo de conclusão	O sistema deve calcular o tempo total da corrida, do início até a chegada à área de objetivo.	Must Have	Backend	Slide 11. Usar uma única fonte de relógio (micromouse ou servidor) para evitar erros de sincronização.
RF14	Calcular comparação de tempo gasto entre execuções	O sistema deve calcular, a partir do melhor tempo já executado em um caminho completo, uma comparação em porcentagem do quanto melhor foi o tempo gasto na última execução.	Should Have	Backend	Ajudará na análise sobre a evolução do Micromouse a cada execução, já que há um limite de tempo para a prova.
RF15	Registrar informações sobre a falha de uma execução	O sistema deve registrar, por tentativa, a célula da falha (quando houver) e o motivo.	Must Have	Backend	Motivos automáticos: time_exceeded, falha_componente, encerrado_operador (BOOT). Falha de trajeto: collision, stuck, out_of_track. Encerramento manual (UC04 / RF30): operador escolhe collision, stuck ou out_of_track e observação opcional (≤ 100 caracteres), e a tentativa é marcada também com a origem encerrado_operador. Em falha_componente, registrar o componente (bateria, sensores, motores).
RF16	Registrar os status de uma execução	O sistema deve registrar status da tentativa: running, success, failed; e da execução lógica: em_andamento, concluida, cancelada.	Must Have	Backend	Tentativa: running durante o trajeto; success/failed ao término. O health-check é um registro anterior à tentativa. Execução lógica: em_andamento enquanto houver tentativas disponíveis no TAP; concluida com sucesso; cancelada por timeout global, terceira tentativa sem sucesso ou substituição por nova execução (UC12.1, UC12.2).
RF17	Garantir unicidade entre as execuções	Cada tentativa persistida deve ter tentativa_id único, ligada a uma execucao_id (execução lógica).	Must Have	Backend	Conexão com a integridade dos dados RNF01.
RF18	Registrar uma única execução por vez	O sistema não deve abrir nova tentativa enquanto existir outra em running.	Must Have	Backend	Após success ou failed, permitir retomada respeitando o limite de 3 por execução lógica (RF19). Nova execução cancela a execução anterior em andamento.
RF19	Enviar feedback de execução recusada	O sistema deve informar de forma clara quando uma execução solicitada foi negada, registrando o evento como uma tentativa rejeitada quando a recusa ocorre em uma execução existente (Retomar); a recusa de Nova execução é só informada ao operador.	Must Have	Backend
RF20	Detectar paredes e obstáculos	O sistema deve detectar paredes/obstáculos ao redor do Micromouse em tempo real.	Must Have	Firmware	Pré-requisito para a navegação autônoma. Sensores ToF de distância (I²C); parede quando a distância fica abaixo de um limiar calibrado.
RF21	Controlar a movimentação do Micromouse	O sistema deve controlar a movimentação do Micromouse (avançar, curvar, parar).	Must Have	Firmware	Controle PID com encoders e centralização no corredor pelos ToF laterais.
RF22	Calcular velocidade do Micromouse	O sistema deve calcular a velocidade do Micromouse a partir dos dados de movimento disponíveis.	Must Have	Firmware	Campo de telemetria exigido; velocidade medida pelos encoders.
RF23	Monitorar bateria	O sistema deve monitorar o nível/consumo de bateria.	Must Have	Firmware	Campo de telemetria exigido; evita parada sem aviso durante a corrida.
RF24	Transmitir telemetria para o sistema web	O sistema deve transmitir os dados de telemetria (bateria, velocidade, trajeto) para o sistema web.	Must Have	Firmware	Envio obrigatório especificado; ausência penaliza a nota em 25%. Protocolo/formato a definir.
RF25	Sinalizar estado do robô	O sistema deve sinalizar visual e sonoramente o estado do robô (início, erro/colisão, conclusão).	Could Have	Firmware	Apoia depuração e acompanhamento da corrida pela equipe e pela banca.
RF26	Detectar chegada ao objetivo	O sistema deve detectar quando o Micromouse alcançou a área de objetivo, a célula no canto oposto ao de partida no tipo de labirinto selecionado no DIP switch (RF27).	Must Have	Firmware	Sustenta o critério de aceite e o campo de telemetria "desafio cumprido (S/N)". Como o tipo é conhecido, basta alcançar uma célula de objetivo; a orientação do labirinto é resolvida pela regra detalhada no algoritmo de navegação do projeto conceitual de software.
RF27	Ler o tipo do labirinto no DIP switch	O sistema deve ler, na inicialização, o tipo de labirinto (4x4, 8x4 ou 12x4) selecionado nas vias 1 e 2 do DIP switch, usá-lo para definir a área de objetivo e enviá-lo na telemetria do health-check.	Must Have	Firmware	O código 11 é inválido e reprova o health-check. Se o tipo lido divergir do informado em Nova execução (ou Retomar), o backend recusa a abertura e a web alerta o operador; nenhuma tentativa é criada. A web não envia o tipo ao robô (RNF06).
RF28	Rastrear localização e trajeto no labirinto	O sistema deve monitorar a localização do Micromouse e registrar a sequência de células percorridas no labirinto.	Must Have	Firmware	Relacionado ao monitoramento da localização e ao mapeamento do labirinto.
RF29	Realizar um health-check antes de uma execução	O sistema deve realizar um health-check que busca garantir que todos os componentes essenciais para uma execução estejam de acordo, para evitar falhas no meio do processo.	Should Have	Firmware	Verificar funcionamento adequado entre software e hardware, nível de bateria, mobilidade das rodas para curvas, inicialização dos sensores ToF no I²C e resposta dos encoders ao acionar os motores. Lista fixa de 8 itens: bateria, 3 ToF, 2 motores e 2 encoders. Também valida o código lido no DIP switch (RF27).
RF30	Encerrar execução em andamento	O sistema deve permitir que o operador encerre manualmente a tentativa em andamento (UC04), via modal com motivo obrigatório (collision, stuck ou out_of_track) e observação opcional (≤ 100 caracteres), registrando o motivo escolhido e a origem encerrado_operador.	Must Have	Backend	A tentativa passa a failed; a execução lógica permanece em_andamento para Retomar tentativa (n/3). Enviar interrupção Bluetooth quando aplicável (RF39). Encerramento automático (UC12.1, UC12.2) não exige downlink. Parada física: RF41.
RF31	Detectar perda de comunicação	O sistema deve detectar a ausência de mensagens de telemetria por um intervalo configurável e sinalizar a execução como sem comunicação.	Must Have	Backend	Permite diferenciar "Micromouse parado" de "conexão perdida". Sustenta o RF04 do frontend.
RF32	Detectar estouro do tempo limite	O sistema deve monitorar a duração da execução lógica, contada desde Nova execução e somando todas as tentativas e os intervalos entre elas, e, ao atingir 10 minutos, encerrar a tentativa aberta como failed com motivo time_exceeded e cancelar a execução lógica (UC12.1).	Must Have	Backend	Relacionado aos critérios de tempo máximo da prova (TAP).
RF33	Armazenar os dados finais da execução	Ao término da execução, o sistema deve gravar em banco de dados o tipo do labirinto, o trajeto, o consumo de bateria, a velocidade média, o tempo de conclusão, o status, o motivo da falha (quando houver), o número da tentativa e a data/hora.	Must Have	Backend	Exige armazenamento em banco de dados para consultas.
RF34	Consultar execuções de um labirinto	O sistema deve permitir consultar as execuções de um labirinto escolhido pelo usuário, exibindo os dados específicos daquele labirinto.	Must Have	Backend
RF35	Consultar execuções de todos os labirintos	O sistema deve permitir consultar as execuções de todos os labirintos em uma única exibição.	Must Have	Backend
RF36	Consultar detalhes de uma execução	O sistema deve permitir consultar todos os dados de uma execução específica, incluindo o trajeto completo, para reexibição do percurso.	Must Have	Backend	Sustenta o RF02 e o RF05 do frontend.
RF37	Registrar paredes detectadas	O sistema deve receber e armazenar as paredes detectadas pelo Micromouse em cada célula, permitindo exibir o mapa descoberto do labirinto.	Could Have	Backend	Não exigido na telemetria, mas o mapeamento é requisito do robô e enriquece a visualização do trajeto.
RF38	Retomar execução após falha	Após falha de componente ou de trajeto, o operador deve poder retomar a execução lógica com Retomar tentativa (n/3) (UC31), abrindo nova tentativa com mapa preservado quando couber; telemetria pode marcar retomada.	Must Have	Backend	Falha consome tentativa do TAP. Nova tentativa_id, attempt_index incrementado, UC20 antes de running. Registrar evento com horário, célula e componente (se houver). Retomada inválida → tentativa rejeitada (RF19).
RF39	Enviar comandos do contrato ao Micromouse	O sistema deve enviar ao Micromouse, pela ponte Bluetooth serial, os três comandos do contrato: interromper, quando o operador encerrar manualmente uma tentativa (RF30); largar, quando o operador iniciar a tentativa em Nova execução ou Retomar; e health_check, quando o operador pedir novo health-check com o robô parado, fora de tentativa.	Must Have	Backend	Os comandos vão na resposta ao POST /telemetria (4.4.1, seção Comando da web para o robô). O robô só parte com o último health-check aprovado. Não inclui iniciar/parar genérico nem teleoperação (RNF06).
RF40	Controles operacionais na interface	O sistema web deve oferecer Nova execução, Encerrar tentativa (modal RF30), Retomar tentativa (n/3) e o indicador Tentativa n/3, conforme TAP.	Must Have	Frontend	Sem controle de acesso: interface no notebook da equipe, rede local. Botões genéricos iniciar/parar fora do escopo desta versão.
RF41	Usar o botão BOOT para parar e apagar a memória	O sistema deve usar o botão BOOT da placa da ESP32 conforme o estado do robô: durante a corrida, um toque para o robô e envia "failed" com motivo encerrado_operador; com o robô parado, um toque (cerca de 1 s) apaga o mapa.	Must Have	Firmware	Parada de emergência que funciona sem rede. O toque é usado quando a equipe recoloca o robô na largada sem aproveitar o mapa; em Retomar tentativa (n/3), o mapa e a posição são preservados (RF38). Não exige hardware novo.
RF42	Persistir mapa e estado em memória não volátil	O sistema deve gravar na memória flash (NVS) o mapa das paredes, a posição, o estado da execução e o tipo de labirinto a que o mapa pertence, atualizando-os a cada célula nova.	Must Have	Firmware	Permite retomar de onde parou depois de uma reinicialização (RF38). Ao ligar, se o tipo no DIP switch for diferente do gravado, o mapa é zerado.

Requisitos Não Funcionais

ID	Nome do Requisito	Descrição	Prioridade	Responsável	Observações
RNF01	Integridade dos dados	A aplicação web deve apresentar os dados de telemetria recebidos sem alterações ou arredondamentos que comprometam sua interpretação, mantendo a unidade de medida do sistema.	Must Have	Frontend	Fundamental para evitar que o usuário interprete dados incorretos durante a execução.
RNF02	Tempo de resposta da interface	A interface web deve apresentar os novos dados de telemetria em até 2 segundos após o recebimento das informações do sistema.	Must Have	Frontend	Requisito de desempenho para visualização da telemetria. Compõe o orçamento de latência definido no RNF04.
RNF03	Arquitetura das informações	A interface web deve apresentar, sem rolagem e em resolução de 1366x768, os seguintes dados de uma execução: status, tempo decorrido, célula atual, nível de bateria e velocidade média. Os demais dados podem exigir rolagem.	Must Have	Frontend	Nenhuma informação é omitida, apenas organizada pelo que precisa ser visto com mais frequência. Verificável por inspeção na resolução de referência.
RNF04	Latência no acompanhamento em tempo real	Durante uma execução em tempo real, o intervalo entre o envio do dado pelo Micromouse e sua exibição na tela não deve passar de 3 segundos, distribuídos em até 1 segundo entre o recebimento pelo backend e a disponibilização do dado e em até 2 segundos entre essa disponibilização e a atualização da tela (RNF02).	Should Have	Backend	Limite único fim a fim, que substitui a faixa anterior de 3 a 5 segundos. Somada ao RNF02, a faixa anterior admitia até 7 segundos de atraso total. Medição: da leitura na ponte até a tela; o trecho Bluetooth é medido à parte, na bancada, sem comando de sincronia ao robô.
RNF05	Persistência dos dados	Os dados das execuções devem permanecer disponíveis após a reinicialização do servidor ou do computador que o hospeda.	Must Have	Backend
RNF06	Não interferência na corrida	O sistema não deve enviar comandos de navegação nem alterar código ou memória do robô sobre o labirinto. O downlink se limita aos três comandos do contrato (interromper, largar, health_check), descritos no RF39.	Must Have	Backend	Encerramento automático (UC12.1, UC12.2) não exige downlink. Trajeto decidido apenas pelo firmware.
RNF07	Independência da execução	Uma falha no backend ou na rede não deve interromper a execução do Micromouse, que deve continuar resolvendo o labirinto de forma autônoma.	Must Have	Backend
RNF08	Tolerância a perda de conexão	Em caso de queda de comunicação, o sistema deve aceitar a reconexão do Micromouse e manter os dados da execução já recebidos.	Must Have	Backend	Queda de até 10 s: o firmware reenvia os eventos gerados durante a queda e o backend descarta os repetidos pelo seq. A partir de 10 s vale o RF31.
RNF09	Validação dos dados recebidos	O sistema deve validar as mensagens de telemetria recebidas (formato, campos obrigatórios e faixas válidas, como célula dentro dos limites do labirinto) e descartar as inválidas sem interromper o serviço.	Must Have	Backend	Evita que uma leitura corrompida derrube o sistema durante a apresentação.
RNF10	Funcionamento em rede local	O sistema deve funcionar em rede local, sem depender de acesso à internet, no local definido pelos professores.	Should Have	Backend
RNF11	Capacidade de processamento da telemetria	O sistema deve processar pelo menos 10 mensagens de telemetria por segundo sem atraso acumulado.	Should Have	Backend
RNF12	Desenvolvimento próprio	O backend deve ser desenvolvido pela equipe, sem uso de plataformas prontas de telemetria ou dashboard.	Must Have	Backend
RNF13	Documentação da API	Os endpoints e o formato das mensagens de telemetria devem estar documentados no repositório do projeto.	Should Have	Backend
RNF14	Versionamento do código	Todo o código do software deve ser versionado no repositório GitHub do grupo, seguindo a organização do template da disciplina.	Must Have	Software	Repositório 2026_2_PI1_Grupo01_Juliana. Equivalente ao RNF8 da Eletrônica, que prevê o versionamento dos arquivos de hardware.