Ir para o conteúdo

Semana 6

Depuração e confiabilidade

Descubra por que um robô se comporta mal (mecânica, programação ou sensor) e prove que ele funciona de novo e de novo.

  • 70 a 85 minutos
  • Missão: Diagnosticar e corrigir bugs mecânicos, de programação e de sensor, e depois provar que um robô é confiável com um teste de três rodadas.

Os estudantes pegam os robôs reativos que montaram e os tornam confiáveis. Eles aprendem que depurar é o trabalho de descobrir por que o resultado real é diferente do resultado esperado, e que os bugs vêm em três famílias: mecânicos (alguma coisa física), de programação (uma instrução errada ou faltando) e de sensor (uma leitura, um limiar ou uma calibração ruins). Eles praticam com missões de depuração preparadas de propósito, conhecem variáveis e contadores para guardar e acompanhar valores, e fazem ensaios de confiabilidade (a mesma tarefa três vezes) registrando o esperado x o real para provar que o robô funciona mesmo.

Ao terminar esta semana, você vai conseguir

  • Explicar a depuração como descobrir por que o resultado real difere do resultado esperado
  • Diferenciar bugs mecânicos, de programação e de sensor pelos sintomas deles
  • Usar uma variável ou um contador para guardar ou acompanhar um valor num programa
  • Fazer um ensaio de confiabilidade: repetir a mesma tarefa três vezes e registrar o esperado x o real
  • Diagnosticar um robô que se comporta mal e descrever a solução

Aprender

O que depurar é de verdade

Toda vez que você roda um programa, tem dois resultados na cabeça: o esperado (o que DEVERIA acontecer) e o real (o que ACONTECEU). Quando eles batem, o robô está funcionando. Quando não batem, existe um bug, e depurar é o trabalho de detetive de descobrir por que eles diferem.

Quem depura bem não fica cutucando o robô a esmo: compara o esperado com o real, olha o sintoma de perto e muda uma coisa de cada vez, para conseguir saber o que resolveu.

Por exemplo: Esperado: parar diante da parede. Real: bateu na parede. -> Tem um bug para achar.; Esperado: virar à esquerda. Real: virou à direita. -> Compare o bloco com o que você queria dizer.

As três famílias de bugs

Os bugs vêm em três famílias, e nomear a família já é meio caminho andado. Um bug mecânico é um problema físico no corpo do robô: uma roda frouxa, um fio se arrastando pelo chão, uma engrenagem que patina. Um bug de programação é um erro nas instruções: um número errado, um bloco faltando, ou blocos fora de ordem. Um bug de sensor é um problema de percepção: uma leitura ruim, um limiar ajustado no valor errado, ou um sensor que precisa de calibração.

O truque é ler o sintoma e chutar a família primeiro. Se o robô erra exatamente do mesmo jeito toda santa vez, o bug costuma estar no programa. Se funciona às vezes e às vezes não, desconfie de alguma coisa mecânica ou de uma leitura de sensor instável.

Por exemplo: Mecânico: o robô puxa para um lado porque uma roda está frouxa.; Programação: o robô vira por 2 segundos em vez de 1 porque o número está errado.; Sensor: o robô nunca para porque o limiar de distância está pequeno demais.

Variáveis e contadores: guardar e acompanhar valores

Às vezes um programa precisa lembrar de um número. Uma variável é uma caixinha com nome que guarda um valor, e esse valor pode mudar enquanto o programa roda. Um contador é uma variável especial usada para contar: ela começa em zero e sobe de um em um cada vez que alguma coisa acontece, tipo toda vez que o robô desvia de um obstáculo.

As variáveis também guardam valores de calibração: números que você mede uma vez e armazena para as leituras de um sensor significarem a coisa certa. Guardar um valor quer dizer que depois você pode usá-lo, mudá-lo e conferi-lo, em vez de ficar chutando.

Por exemplo: Um contador que soma 1 a cada obstáculo desviado.; Um valor de calibração guardado para o nível de luz do chão branco.; Uma variável que lembra quantas voltas o laço já deu.

Confiabilidade: provar com ensaios repetidos

Um robô que funciona uma vez pode só ter dado sorte. Confiabilidade quer dizer fazer o mesmo trabalho corretamente de novo e de novo, e você não pode afirmar isso sem prova. A prova é um ensaio de confiabilidade: você roda a mesma tarefa várias vezes, com o mesmo caso de teste em cada rodada, e anota o resultado esperado e o resultado real de cada uma.

Se as três rodadas baterem com o que você esperava, o robô é confiável para aquele caso de teste. Se uma rodada sair diferente, você achou um bug que estava escondido à vista de todos, e aquela rodada que falhou é justamente a pista de que você precisa.

Por exemplo: Rode a tarefa de parar diante da parede 3 vezes a partir da mesma largada e anote cada uma.; Esperado "para" nas três rodadas; real "para, para, bate" quer dizer que a rodada 3 tem um bug.

Palavras para conhecer

Depuração:
O trabalho de descobrir por que o resultado real de um robô é diferente do resultado esperado, e depois consertar isso.
Variável:
Um lugar com nome dentro de um programa, que guarda um valor capaz de mudar enquanto o programa roda.
Contador:
Uma variável usada para contar: ela começa num número e sobe de um em um cada vez que alguma coisa acontece.
Valor guardado:
Um número ou um dado que um programa mantém numa variável para poder usar ou mudar depois.
Valor de calibração:
Um número que você mede e salva para as leituras de um sensor significarem a coisa certa, como o nível de luz de um chão branco.
Resultado esperado:
O que DEVERIA acontecer quando o programa roda direito, ou seja, o que você prevê antes de testar.
Resultado real:
O que ACONTECEU quando você de fato rodou o robô, e que você observa e anota.
Caso de teste:
Uma situação específica que você monta de propósito para testar, tipo "uma parede a exatamente 15 cm".
Bug mecânico:
Um problema físico no corpo do robô, como uma roda frouxa, um fio se arrastando ou uma engrenagem travada.
Bug de programação:
Um erro nas instruções: um bloco ou número errado, faltando ou fora de ordem.
Bug de sensor:
Um problema na percepção: uma leitura ruim, um limiar errado, ou um sensor que precisa ser calibrado.
Confiabilidade:
O quanto um robô faz o mesmo trabalho corretamente de novo e de novo, comprovado por ensaios repetidos.

Segurança em primeiro lugar

Leia isto antes de montar ou colocar um robô para funcionar nesta semana.

  • Caution:Desligue o robô antes de apertar rodas, mexer em fios ou conferir peças mecânicas.
  • Caution:Mantenha a área de teste e a pista de obstáculos livres de mãos, pés e bagunça durante as rodadas.
  • Note:Use tesoura sem ponta com um adulto se for refazer um para-choque de papel ou alguma peça do modelo.
  • Note:Salve o seu programa e o registro de testes com frequência, para que atualizar o navegador não apague os seus resultados.

Mãos à obra

Escolha o seu caminho

Dá para fazer este curso com um kit de robótica, com o simulador no navegador, ou sem eletrônicos, com materiais de casa. Escolha um: você pode trocar quando quiser sem perder o seu trabalho.

Missões de Detetive de Bugs

Kit de robótica

Diagnosticar um robô que se comporta mal: decidir se o bug é mecânico, de programação ou de sensor, e depois consertá-lo.

  • Em cada missão, escreva primeiro o resultado esperado e o resultado real. A diferença entre os dois é o sintoma que você está investigando.
  • Faça a pergunta das três famílias: isso é físico (mecânico), é de instrução (programação), ou é um problema de percepção (sensor)? Use o sintoma para chutar antes de mexer em qualquer coisa.
  • Mude UMA coisa de cada vez, rode de novo e anote se o resultado real agora bate com o esperado.

Depure um robô de kit que se comporta mal

Você precisa de: Um robô reativo da semana 5, Folha de atividade Detetive de Bugs, Fita métrica

Passos

  1. 1Peça a um adulto ou colega que coloque em segredo um bug num robô que já funcionava (afrouxar uma roda, mudar um número num bloco, ou ajustar um limiar ruim).
  2. 2Rode o robô e escreva na folha o resultado esperado e o resultado real.
  3. 3Decida a família do bug a partir do sintoma, e depois investigue as causas prováveis em ordem.
  4. 4Conserte a única coisa de que você desconfia, rode de novo e confirme que o resultado real agora bate com o esperado.

Como é quando dá certo: O estudante nomeia a família certa do bug, faz um único conserto direcionado, e o resultado real do robô volta a bater com o esperado.

Fique de olho em:
  • O resultado esperado e o real foram os dois anotados
  • A família do bug foi identificada corretamente
  • Foi feita uma mudança de cada vez
  • O robô funciona depois do conserto

Segurança: Desligue o robô antes de apertar rodas ou mexer em fios. Mantenha os dedos longe das partes em movimento enquanto ele funciona.

Se não funcionar

Consertar "tudo" de uma vez, então ninguém sabe qual era a causa
- Desfaça todas as mudanças menos uma; faça uma única mudança, rode de novo e veja se era aquilo.
Não dá para decidir a família do bug
- Rode três vezes: o mesmo resultado errado toda vez aponta para a programação; resultados diferentes apontam para algo mecânico ou um sensor instável.

Vá além: Coloque um bug no robô de um colega e veja se ele consegue diagnosticar a família só pelo sintoma.

Ensaio de confiabilidade de três rodadas

Kit de robótica

Provar que um robô é confiável rodando a mesma tarefa três vezes e comparando o resultado esperado com o real a cada rodada.

  • Escolha uma tarefa bem definida e um caso de teste (exatamente a mesma montagem em toda rodada). Escreva o resultado esperado uma vez só: ele é o mesmo para as três rodadas.
  • Rode a tarefa três vezes SEM mudar nada entre uma rodada e outra. Anote o resultado real e marque Bateu? (sim ou não) em cada uma.
  • Três acertos querem dizer confiável para esse caso de teste. Qualquer diferença é um bug para caçar com os passos do Detetive de Bugs.

Ensaio de confiabilidade no robô de kit

Você precisa de: Um robô reativo da semana 5, Registro de teste de três rodadas, Fita métrica

Passos

  1. 1Escolha uma tarefa como "parar antes da parede" e coloque a parede na mesma distância em toda rodada: esse é o seu caso de teste.
  2. 2Escreva o resultado esperado: "o robô para sem encostar na parede".
  3. 3Rode três vezes exatamente a partir da mesma largada, anotando o resultado real e o Bateu? a cada vez.
  4. 4Se alguma rodada não bater, diagnostique a família do bug e conserte, e depois refaça as três rodadas.

Como é quando dá certo: Uma tabela de três rodadas preenchida; um robô confiável bate com o resultado esperado nas três.

Fique de olho em:
  • O mesmo caso de teste é usado nas três rodadas
  • O resultado esperado foi escrito uma vez só
  • Três resultados reais e o Bateu? foram registrados
  • Qualquer diferença é investigada

Segurança: Mantenha a área de teste livre e fique longe das partes em movimento. Volte o robô para a mesma linha de largada a cada rodada.

Se não funcionar

Os resultados vão mudando ao longo das três rodadas
- Confira as pilhas e a posição de largada: uma bateria acabando é uma causa mecânica ou de energia da falta de confiabilidade.
Bate duas vezes e depois falha
- A rodada que falhou é a sua pista: examine a leitura do sensor e a montagem física logo depois dessa rodada.

Vá além: Acrescente uma quarta e uma quinta rodada e veja se a confiabilidade se mantém conforme a bateria vai descarregando.

Contador de obstáculos

Kit de robótica

Usar uma variável como contador que soma um a cada obstáculo desviado pelo robô, e depois ler o valor guardado.

  • Coloque uma variável contador em 0 no começo. Cada vez que o robô perceber e desviar de um obstáculo, some 1 ao contador.
  • Isso é um valor guardado: o contador lembra quantos obstáculos foram enfrentados, e você pode conferir no final.
  • Preveja quantos obstáculos existem na pista, e depois compare a sua previsão com o valor final do contador.

Conte os obstáculos desviados no robô de kit

Você precisa de: Um robô reativo da semana 5, Uma pista curta de obstáculos, Lápis e papel

Passos

  1. 1Coloque em 0 uma variável chamada "obstáculos" no começo do programa.
  2. 2Mantenha um laço que lê o sensor; dentro do ramo "se tem obstáculo", vire para desviar E some 1 a "obstáculos".
  3. 3Percorra a pista e depois mostre ou leia o valor final do contador.
  4. 4Compare o contador com quantos obstáculos você realmente colocou.

Como é quando dá certo: O valor final do contador é igual ao número de obstáculos de que o robô realmente desviou.

Fique de olho em:
  • O contador começa em 0
  • Ele soma 1 só quando um obstáculo é desviado
  • O valor guardado final é lido
  • Ele é comparado com a contagem real

Segurança: Mantenha a pista livre de mãos e pés enquanto o robô anda.

Se não funcionar

O contador está alto demais
- O robô está somando 1 mais de uma vez por obstáculo: garanta que a contagem aconteça uma vez por detecção, e não a cada volta do laço.
O contador fica em 0
- Confira se o passo de somar 1 está dentro do ramo "se tem obstáculo", e não fora dele: é um bug de programação.

Vá além: Acrescente uma regra: quando o contador chegar a 3, o robô para e avisa que terminou.

Programe o robô

Build a program from blocks, then run it on the simulator. On the kit path, use the same steps in your robot's app; unplugged, act the blocks out on a floor grid. Your program saves on this device.

Programa do contador de obstáculos

Um programa que coloca um contador em 0, roda um laço para ler o sensor, e soma 1 ao contador cada vez que desvia de um obstáculo.

Pronto

Adicionar um bloco

Eventos e execução

Movimento

Controle

Dados

Saída

Variáveis e contadores

count

O seu programa

  • Zerar contador
  • Andar
Coluna 1, linha 1Coluna 2, linha 1: marcador redred marker at column 2, row 1Coluna 3, linha 1Coluna 4, linha 1: marcador redred marker at column 4, row 1Coluna 5, linha 1Coluna 6, linha 1: marcador redred marker at column 6, row 1Goal zone at column 6, row 1Robot at column 1, row 1
  • Robô (a seta aponta para onde ele olha)
  • Zona de objetivo (contorno tracejado)
  • Marcador colorido (ponto)

Mapa: Uma grade de 6 por 1. O robô começa na coluna 1, linha 1, virado para direita. A zona de objetivo fica na coluna 6, linha 1. Há 3 marcadores coloridos.

Pronto.

Pronto para rodar. · 0 steps

Estado do robô

Coluna
1
Linha
1
Virado para
direita
Distância à frente
5 casas
Toque
livre
Em cima de uma linha
não
Luz
80
Na zona de objetivo
não
Colisões
0
Passos
0

Robô na coluna 1, linha 1, virado para direita. Distância à frente: 5 casas. Toque: livre. Em cima de uma linha: não. Luz: 80. Fora da zona de objetivo.

Saída do log

Nada registrado ainda.

  • Heads up: This program has no safe stop behavior. Add a safe stop so the robot stops when it is done or blocked.

Conserte o freio quebrado

Este programa deveria parar o robô na casa bem antes da parede, mas um valor errado na verificação de distância faz ele parar no lugar errado. Preveja a família do bug, mude o único valor na condição do repetir-até, e rode de novo até ele parar direito.

Pronto

Adicionar um bloco

Eventos e execução

Movimento

Controle

Dados

Saída

Variáveis e contadores

Nenhuma ainda.

O seu programa

  • Repetir até
    • Andar
  • Missão concluída
Coluna 1, linha 1Coluna 2, linha 1Coluna 3, linha 1Coluna 4, linha 1Coluna 5, linha 1: paredeGoal zone at column 4, row 1Robot at column 1, row 1
  • Robô (a seta aponta para onde ele olha)
  • Zona de objetivo (contorno tracejado)
  • Parede (cinza, com um X)

Mapa: Uma grade de 5 por 1. O robô começa na coluna 1, linha 1, virado para direita. A zona de objetivo fica na coluna 4, linha 1. Há 1 parede.

Pronto.

Pronto para rodar. · 0 steps

Estado do robô

Coluna
1
Linha
1
Virado para
direita
Distância à frente
3 casas
Toque
livre
Em cima de uma linha
não
Luz
80
Na zona de objetivo
não
Colisões
0
Passos
0

Robô na coluna 1, linha 1, virado para direita. Distância à frente: 3 casas. Toque: livre. Em cima de uma linha: não. Luz: 80. Fora da zona de objetivo.

Saída do log

Nada registrado ainda.

Preveja

Commit to a guess before you test - then see how close you were. Your predictions save automatically.

Como conferir: Faça as três rodadas, registre o real x o esperado e o Bateu?, e compare a sua previsão com o que aconteceu de verdade.

Como conferir: Investigue as causas prováveis e veja se a família que você previu foi a que resolveu.

Como conferir: Percorra a pista, leia o contador e compare com o número que você previu e com a contagem real de obstáculos.

Testar e melhorar

Teste de confiabilidade de três rodadas

Escolha uma tarefa e um caso de teste. Escreva o resultado esperado uma vez só, e depois rode a mesma tarefa três vezes sem mudar nada. Anote o resultado real e se ele bateu em cada rodada.

O que medir: Se o resultado real bateu com o esperado em cada uma das três rodadas

RunResultado esperadoResultado realBateu? (S/N)

Registro de diagnóstico de bugs

Em cada missão de depuração, registre o sintoma, a família de bug de que você desconfia, a única mudança que você tentou, e se isso corrigiu a diferença.

O que medir: Qual família de bug era a responsável e se uma única mudança direcionada resolveu

SintomaFamília suspeitaÚnica mudança tentadaConsertou? (S/N)

Missões de depuração

Each robot below misbehaves on purpose. Work out whether the bug is mechanical, in the program, or with a sensor - then check the fix.

O robô que gira no lugar

Um robô que deveria andar reto para a frente fica girando no mesmo lugar, rodopiando como se uma roda fosse para a frente e a outra para trás.

Sintoma: Os dois motores funcionam, mas o robô gira em vez de andar para a frente, e gira do mesmo jeito em toda rodada.

Dica: Olhe as rodas: as duas estão girando, mas em sentidos opostos, e nada está frouxo. Pense em como um dos motores está ligado ou configurado, e não nos comandos de andar.

Ver a solução

Solução: Troque a ligação do motor invertido (ou inverta a configuração de direção só daquele motor) para as duas rodas irem para a frente juntas. Rode de novo e confirme que o robô agora anda reto em vez de girar.

Causas prováveis

  1. 1Um motor está ligado ao contrário, então a roda dele gira no sentido errado.
  2. 2A configuração de direção de um motor está invertida em relação à do outro.
  3. 3Os dois motores estão montados em espelho, mas são acionados como se apontassem para o mesmo lado.

A parede diante da qual ele não para

Um robô deveria andar para a frente e parar quando o sensor de distância dissesse que a parede está perto, mas ele entra direto na parede e continua empurrando sem nunca parar.

Sintoma: Em toda rodada o robô nunca para: o resultado real é uma batida, mesmo havendo uma instrução de parar no programa.

Dica: O sensor lê direitinho e o bloco de parar está lá. Leia em voz alta a comparação que está dentro do laço: conforme a parede se aproxima, a condição que deveria parar o robô chega a virar verdadeira em algum momento?

Ver a solução

Solução: Inverta o operador de comparação (ou troque os dois lados dele) para a condição de parada virar verdadeira quando a distância ficar pequena. Rode de novo e confirme que o robô para antes da parede.

Causas prováveis

  1. 1A comparação está invertida: ele para quando a distância é "maior que" em vez de "menor que", então isso nunca é verdade enquanto o robô se aproxima.
  2. 2Os dois lados da comparação estão trocados.
  3. 3O operador errado (um > onde era para ser <) impede a condição de parada de disparar.

O contador que conta demais

Um robô passa por três marcadores e deveria relatar uma contagem de 3, mas relata um número enorme, tipo 47.

Sintoma: O valor final do contador é muito maior que o número de objetos reais: ele cresce a cada volta do laço em vez de uma vez por objeto.

Dica: Olhe o contador subindo enquanto ele anda. Ele soma 1 uma vez por objeto, ou uma vez a cada passagem pelo laço, mesmo sem nenhum objeto novo na frente?

Ver a solução

Solução: Zere o contador no começo e mova o "soma 1" para dentro da condição que detecta um objeto NOVO. Rode de novo e confirme que a contagem final bate com o número real de objetos.

Causas prováveis

  1. 1O "soma 1" está fora da verificação "estou vendo um objeto?", então ele conta a cada volta do laço.
  2. 2O contador nunca é zerado no começo da rodada.
  3. 3O robô fica parado ao lado do mesmo objeto por várias voltas e conta ele toda vez.

O seguidor de linha que falha na claridade

Um robô seguidor de linha funcionou perfeitamente ontem. Hoje, numa sala bem mais clara, ele sai direto da linha toda vez, e o programa não mudou.

Sintoma: O robô ignora a linha e não corrige o rumo, mesmo com o código que corrigia certinho na luz de ontem.

Dica: O código é idêntico ao de ontem; o que mudou foi a sala. Leia hoje o valor de luz ao vivo em cima da linha e fora dela, e compare os dois com o limiar do programa.

Ver a solução

Solução: Leia os valores de luz de hoje em cima da linha e fora dela, escolha um limiar novo na metade do caminho entre os dois, guarde esse valor de calibração e rode de novo. O robô deve voltar a seguir a linha.

Causas prováveis

  1. 1O limiar de luz foi calibrado para a sala mais escura de ontem e agora está errado.
  2. 2A luz mais forte subiu todas as leituras acima do limiar, então "em cima da linha" nunca é registrado.
  3. 3O sensor não foi recalibrado para as condições de luz de hoje.

O robô que nunca termina

Um robô deveria andar para a frente, desviar de alguns obstáculos e depois parar no objetivo, mas ele continua andando e desviando para sempre e nunca termina, nem depois de chegar ao objetivo.

Sintoma: O robô nunca encerra o programa: ele repete o comportamento de desviar e andar sem fim, sem parar.

Dica: O desviar em si funciona. O problema é que o robô nunca sai do laço. Procure uma saída: existe alguma condição que encerre o laço quando o objetivo for alcançado?

Ver a solução

Solução: Acrescente uma saída: um repetir-até que termine no objetivo, ou um "se estiver no objetivo, então pare", para o laço poder acabar. Rode de novo e confirme que o robô para ao chegar ao objetivo.

Causas prováveis

  1. 1O comportamento está dentro de um laço infinito sem saída.
  2. 2Um repetir-até tem uma condição que nunca consegue virar verdadeira.
  3. 3Não existe uma "parada segura" nem um "missão concluída" para quando o objetivo for alcançado.

O código bom que mesmo assim puxa para o lado

O programa de um robô está correto e não mudou (semana passada ele andava reto), mas agora ele faz curva para um lado toda vez que anda para a frente, mesmo num trecho curto e sem obstáculos.

Sintoma: Em vez de andar reto, o robô puxa para um lado do mesmo jeito em toda rodada, embora o código não tenha mudado.

Dica: Ele falha do mesmo jeito toda rodada, mas o programa já se provou correto na semana passada. Antes de mexer no código, olhe o corpo e as rodas do robô, ou a superfície e a montagem simuladas.

Ver a solução

Solução: Não mexa no código. Encaixe de novo e aperte as duas rodas, tire qualquer fio ou sujeira que esteja se arrastando (ou reinicie a superfície e o alinhamento simulados). Rode de novo e confirme que ele volta a andar reto.

Causas prováveis

  1. 1Uma roda ou um eixo está frouxo ou não encaixou direito.
  2. 2Um fio ou uma peça se arrasta pelo chão de um lado, ou uma roda raspa na estrutura.
  3. 3No simulador, algum ajuste de superfície ou de alinhamento faz um lado escorregar.

A parada que chega tarde demais

Um robô usa o sensor de distância para parar antes de uma parede. Em velocidade baixa ele para perfeitamente, mas quando é acelerado passa do ponto e encosta na parede, com exatamente o mesmo limiar.

Sintoma: Em alta velocidade o robô para tarde demais e bate na parede; em baixa velocidade esse mesmíssimo programa para a tempo.

Dica: O limiar que funciona devagar não basta quando ele está rápido: o robô percorre mais distância entre uma leitura e outra. Pense em como a velocidade e o limiar de parada trabalham juntos, e mude só um deles de cada vez.

Ver a solução

Solução: Mude uma coisa de cada vez: ou diminua a velocidade de deslocamento, ou aumente o limiar de distância para ele parar mais cedo. Rode de novo na velocidade desejada e confirme que ele para a tempo.

Causas prováveis

  1. 1Em alta velocidade o robô percorre mais distância entre leituras, então um limiar bem próximo dispara tarde demais.
  2. 2O limiar foi ajustado para uma velocidade mais baixa do que a que o robô está usando agora.
  3. 3O sensor é lido tão de vez em quando que, nessa velocidade, não dá tempo de pegar a parede.

Verificação de aprendizagem

Responda a estas perguntas para conferir se você consegue depurar bugs por família e provar que um robô é confiável.

  1. 1. Diagnostique o tipo de bug mais provável.

    Um robô seguidor de linha funcionou ontem. Hoje ele passa direto pela linha toda vez, mesmo sem o código ter mudado. Hoje a sala está bem mais clara.

  2. 2. O que é depurar?

  3. 3. Um robô andava reto na semana passada. O programa dele não mudou, mas agora ele faz curva para um lado em toda rodada. Qual família de bug é a mais provável?

  4. 4. O que é um contador?

  5. 5. Num ensaio de confiabilidade, o que é o "resultado esperado"?

  6. 6. Por que se roda a mesma tarefa três vezes num ensaio de confiabilidade?

0 de 6 respondidas

Refletir

As suas reflexões são salvas sozinhas.

O que vem na semana que vem

Semana que vem a gente coloca a confiabilidade para trabalhar: planejar uma missão autônoma completa que o robô cumpra com segurança sozinho.

  • Guarde o seu registro de teste de três rodadas e a folha do Detetive de Bugs: comportamento confiável é a base da missão da semana que vem.
  • Pense num trabalho que o seu robô poderia fazer do início ao fim sem ninguém pilotando.
  • Carregue o seu kit, salve o simulador nos favoritos, ou junte o seu robô de papelão e a sua pista.

Termine a semana 6

Conclua estes itens para encerrar a semana e desbloquear a próxima:

  • Diagnosticar e consertar pelo menos um bug de cada família, registrando o sintoma e a solução (not done yet)
  • Completar um ensaio de confiabilidade de três rodadas com o esperado x o real registrados (not done yet)
  • Usar uma variável contador para acompanhar os obstáculos desviados (not done yet)
  • Acertar pelo menos 4 de 5 na verificação de aprendizagem (not done yet)
  • Escrever a sua reflexão (not done yet)